From simple-bounces@ietf.org Thu Jul 1 03:38: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 DAA02084 for ; Thu, 1 Jul 2004 03:38: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 1Bfw8x-0002z9-DL for simple-archive@ietf.org; Thu, 01 Jul 2004 03:38:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bfw7z-0002Zp-00 for simple-archive@ietf.org; Thu, 01 Jul 2004 03:37:04 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bfw78-0001nL-00; Thu, 01 Jul 2004 03:36:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bfw4L-0004uE-JZ; Thu, 01 Jul 2004 03:33:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bfw1G-0004QB-Ga for simple@megatron.ietf.org; Thu, 01 Jul 2004 03:30:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01789 for ; Thu, 1 Jul 2004 03:30: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 1Bfw1E-0007cB-Dw for simple@ietf.org; Thu, 01 Jul 2004 03:30:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bfw0B-0007Du-00 for simple@ietf.org; Thu, 01 Jul 2004 03:29:00 -0400 Received: from cluster-a.mailcontrol.com ([80.69.8.190] helo=rly15a.srv.mailcontrol.com) by ietf-mx with esmtp (Exim 4.12) id 1BfvzW-0006d2-00 for simple@ietf.org; Thu, 01 Jul 2004 03:28:18 -0400 Received: from gbnewp0186s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92]) by rly15a.srv.mailcontrol.com (MailControl) with SMTP id i617RaGQ020636; Thu, 1 Jul 2004 08:27:36 +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, 1 Jul 2004 08:27:56 +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 Boundary header Date: Thu, 1 Jul 2004 08:27:33 +0100 Message-ID: <45730E094814E44488F789C1CDED27AE02BDF4E9@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [Simple] MSRP Boundary header Thread-Index: AcRe05Bp4aGy8oovRTavgcGbBGYOYwAaRf/A From: "Chris Boulton" To: "Ben Campbell" , "Vijay Kishen Hampapur Parthasarathy" X-Scanned-By: MailControl A-05-00-00 (www.mailcontrol.com) Content-Transfer-Encoding: quoted-printable 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=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable I agree with Ben - why do something twice. This only increases complexity and potential to provide conflicting + syntactically incorrect semantics. Chris. -----Original Message----- From: Ben Campbell [mailto:bcampbell@dynamicsoft.com]=20 Sent: 30 June 2004 19:35 To: Vijay Kishen Hampapur Parthasarathy Cc: Ted Hardie; Paul Kyzivat; seancolson@yahoo.com; simple@ietf.org Subject: Re: [Simple] MSRP Boundary header 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.=20=20 >=20 > Vijay >=20 > -----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 >=20 >=20 >=20 > Paul Kyzivat wrote: >=20 >=20 >> >>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=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? >> >> >>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 >=20 >=20 >>the expectation is that you would be using MSRP. >> >=20 >=20 > Or at one composed of a series of short, interactive messages. (Which is > probably what Paul meant to say. >=20 >=20 >>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 >=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. >=20 > 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. >=20 >=20 >> Paul _______________________________________________ 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 Jul 1 03:40: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 DAA02234 for ; Thu, 1 Jul 2004 03:40: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 1BfwBm-0004DC-El for simple-archive@ietf.org; Thu, 01 Jul 2004 03:40:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfwAo-0003nN-00 for simple-archive@ietf.org; Thu, 01 Jul 2004 03:39:58 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bfw9o-00031U-00; Thu, 01 Jul 2004 03:38:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bfw7o-0005bA-Vl; Thu, 01 Jul 2004 03:36:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bfw57-00050O-PO for simple@megatron.ietf.org; Thu, 01 Jul 2004 03:34: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 DAA01977 for ; Thu, 1 Jul 2004 03: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 1Bfw55-0001OK-Mi for simple@ietf.org; Thu, 01 Jul 2004 03:34:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bfw4G-00010o-00 for simple@ietf.org; Thu, 01 Jul 2004 03:33:13 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1Bfw3M-0000cc-00 for simple@ietf.org; Thu, 01 Jul 2004 03:32:16 -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 i617WF211510; Thu, 1 Jul 2004 10:32:15 +0300 (EET DST) X-Scanned: Thu, 1 Jul 2004 10:32:07 +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 i617W7d0024916; Thu, 1 Jul 2004 10:32:07 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00tKD2Ga; Thu, 01 Jul 2004 10:31:45 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 i617VhH15316; Thu, 1 Jul 2004 10:31:43 +0300 (EET DST) Received: from nokia.com ([172.21.42.108]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 1 Jul 2004 10:31:28 +0300 Message-ID: <40E3BDD0.6050702@nokia.com> Date: Thu, 01 Jul 2004 10:31:28 +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: "Henrik Albertsson (KI/EAB)" References: <342C4681F0D4A04CA50A97D74DA8FB9A0C0AC765@esealnt875.al.sw.ericsson.se> In-Reply-To: <342C4681F0D4A04CA50A97D74DA8FB9A0C0AC765@esealnt875.al.sw.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-OriginalArrivalTime: 01 Jul 2004 07:31:28.0082 (UTC) FILETIME=[6BE1CB20:01C45F3D] Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mgw-int1.ntc.nokia.com id i617VhH15316 Content-Transfer-Encoding: quoted-printable Cc: SIMPLE mailing list Subject: [Simple] Re: 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.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Hi Henrik: Thanks for your comment. To be honest with you, I don't really understand what is your=20 suggestion. To me, REQ-6 clearly states the requirement you are looking f= or: "REQ-6: The XCAP client MUST be able to search for the directory of=20 documents pertaining to a specific XCAP application usage. " So how are you suggesting to change this requirement? Regards, Miguel Henrik Albertsson (KI/EAB) wrote: > Hi,=20 >=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 >=20 >=20 > A question for the requirement section of the document:=20 >=20 > I think that a valid requirement is that it is possible to only retriev= e the lists associated with a specified AUID(s). For example a client int= erested in X-list does not want to receive Y-lists and Z-lists.=20 >=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 >=20 >=20 > Regards > /Henrik =20 >=20 >=20 >=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 --=20 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 Jul 1 04:00: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 EAA03041 for ; Thu, 1 Jul 2004 04:00: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 1BfwUR-0003xe-HG for simple-archive@ietf.org; Thu, 01 Jul 2004 04:00:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfwTZ-0003YM-00 for simple-archive@ietf.org; Thu, 01 Jul 2004 03:59:21 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BfwSm-00035m-00; Thu, 01 Jul 2004 03:58:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfwQn-0008TG-52; Thu, 01 Jul 2004 03:56:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfwQM-0008M8-P4 for simple@megatron.ietf.org; Thu, 01 Jul 2004 03:56: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 DAA02830 for ; Thu, 1 Jul 2004 03:56: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 1BfwQK-0002HC-K7 for simple@ietf.org; Thu, 01 Jul 2004 03:56:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfwPK-0001sz-00 for simple@ietf.org; Thu, 01 Jul 2004 03:54:58 -0400 Received: from [62.119.82.41] (helo=mailserver.hotsip.com) by ietf-mx with esmtp (Exim 4.12) id 1BfwON-00019C-00 for simple@ietf.org; Thu, 01 Jul 2004 03:54:04 -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 Date: Thu, 1 Jul 2004 09:53:24 +0200 Message-ID: Thread-Topic: Small nit on I-D ACTION:draft-ietf-simple-iscomposing-02.txt Thread-Index: AcRJL45XSSGkhA2XR6uwkiplBl85bAWDxmbA From: "Christian Jansson" To: , Content-Transfer-Encoding: quoted-printable Subject: [Simple] Small nit on 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.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable In "3.2 Message Composer Behavior", top of page 5 reads: "the idle timeout SHOULD have a default value of fifteen seconds." Wouldn't it be better to chage that to: "the idle timeout SHOULD have a default value of 15 seconds." as it would make it easier to spot the numeric value when browsing the text? / Christian Jansson, Hotsip _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jul 1 04:40: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 EAA05087 for ; Thu, 1 Jul 2004 04: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 1Bfx7J-0004Zc-4P for simple-archive@ietf.org; Thu, 01 Jul 2004 04:40:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bfx5z-00045w-00 for simple-archive@ietf.org; Thu, 01 Jul 2004 04:39:04 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bfx57-0003Ix-00; Thu, 01 Jul 2004 04:38:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfwwQ-0004bG-TG; Thu, 01 Jul 2004 04:29:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfwsR-0003qL-Qj for simple@megatron.ietf.org; Thu, 01 Jul 2004 04: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 EAA04471 for ; Thu, 1 Jul 2004 04:25:02 -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 1BfwsP-0006Jv-HX for simple@ietf.org; Thu, 01 Jul 2004 04:25:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfwrT-0005tL-00 for simple@ietf.org; Thu, 01 Jul 2004 04:24:03 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BfwqT-0005SS-00; Thu, 01 Jul 2004 04:23:01 -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 i618MtN07788; Thu, 1 Jul 2004 11:22:55 +0300 (EET DST) X-Scanned: Thu, 1 Jul 2004 11:22:34 +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 i618MYAH021795; Thu, 1 Jul 2004 11:22:34 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00ybZw4K; Thu, 01 Jul 2004 11:22:33 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 i618MPH01118; Thu, 1 Jul 2004 11:22:25 +0300 (EET DST) Received: from esebe014.NOE.Nokia.com ([172.21.138.53]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 1 Jul 2004 11:22:19 +0300 Received: from trebe003.NOE.Nokia.com ([172.22.232.175]) by esebe014.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 1 Jul 2004 11:22: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: Xcap authorization rules - Multiple URIs in Identity Date: Thu, 1 Jul 2004 11:22:16 +0300 Message-ID: Thread-Topic: [Simple] RE: Xcap authorization rules - Multiple URIs in Identity Thread-Index: AcRNbzNDUkZGncHASQKQJegu1udQbQABYxTQBHJ2O9A= To: , , X-OriginalArrivalTime: 01 Jul 2004 08:22:18.0399 (UTC) FILETIME=[86033AF0:01C45F44] Content-Transfer-Encoding: quoted-printable Cc: geopriv@ietf.org, 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, Jonathan Rosenberg wrote:=20 > > Also, note that the common policy doc needs to say that, when=20 > > the element has multiple conditions (such as=20 > > ), the rule matches only if ALL conditions match=20 > > (i.e., its an AND at that level). > >=20 > that's correct.=20 >=20 > ciao > hannes=20 I totally agree with you to have multiple URIs in the , but I = was wondering whether it makes sense to allow multiple same XML elements = in the , e.g., having two elements, because of = the AND type of operation? Assuming that a user defines e.g. two elements. The rule = matches only when both the elements match at the same time - = basically meaning that only the overlapping part of the is = the one which ever matters. The same applies to all other elements. If there were a restriction defined for having only one XML element of = the same name as direct child elements of the it might help = the implementation (needs only be prepared to have fixed amount of = pre-defined XML elements). What do you think? BR, Eva _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jul 1 05:00: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 FAA06326 for ; Thu, 1 Jul 2004 05:00: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 1BfxQG-00052t-F7 for simple-archive@ietf.org; Thu, 01 Jul 2004 05:00:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfxPH-0004eG-00 for simple-archive@ietf.org; Thu, 01 Jul 2004 04:58:59 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BfxO6-0003sR-00; Thu, 01 Jul 2004 04:57:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfxIr-0008Ee-93; Thu, 01 Jul 2004 04:52:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfxI5-00082r-Up for simple@megatron.ietf.org; Thu, 01 Jul 2004 04:51: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 EAA05941 for ; Thu, 1 Jul 2004 04:51: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 1BfxI3-0001VW-OT for simple@ietf.org; Thu, 01 Jul 2004 04:51:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfxHC-00013v-00 for simple@ietf.org; Thu, 01 Jul 2004 04:50:39 -0400 Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx with esmtp (Exim 4.12) id 1BfxFx-0000ZG-00; Thu, 01 Jul 2004 04:49:21 -0400 Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by goliath.siemens.de (8.11.7/8.11.7) with ESMTP id i618nKd26740; Thu, 1 Jul 2004 10:49:20 +0200 (MEST) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail1.siemens.de (8.11.7/8.11.7) with ESMTP id i618nIn16182; Thu, 1 Jul 2004 10:49:18 +0200 (MEST) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Thu, 1 Jul 2004 10:48:12 +0200 Message-ID: <2A8DB02E3018D411901B009027FD3A3F0468629F@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'eva-maria.leppanen@nokia.com'" , jdrosen@dynamicsoft.com, christian-schmidt@siemens.com Subject: RE: [Simple] RE: Xcap authorization rules - Multiple URIs in Iden tity Date: Thu, 1 Jul 2004 10:48:47 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Cc: geopriv@ietf.org, 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 hi eva, i assumed that the 'and' was a typo. it cannot be 'and' since only a single entity can send the request. have you looked at section 7.1 of the draft update? http://www.tschofenig.com/snapshot/draft-ietf-geopriv-common-policy-01_20Jun e2004.txt ciao hannes > -----Original Message----- > From: eva-maria.leppanen@nokia.com > [mailto:eva-maria.leppanen@nokia.com] > Sent: Thursday, July 01, 2004 10:22 AM > To: Tschofenig Hannes; jdrosen@dynamicsoft.com; > christian-schmidt@siemens.com > Cc: geopriv@ietf.org; simple@ietf.org > Subject: RE: [Simple] RE: Xcap authorization rules - Multiple > URIs in Identity > > Hi, > > Jonathan Rosenberg wrote: > > > 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 > > I totally agree with you to have multiple URIs in the > , but I was wondering whether it makes sense to > allow multiple same XML elements in the , e.g., > having two elements, because of the AND type of operation? > > Assuming that a user defines e.g. two elements. > The rule matches only when both the elements match > at the same time - basically meaning that only the > overlapping part of the is the one which ever > matters. The same applies to all other elements. > > If there were a restriction defined for having only one XML > element of the same name as direct child elements of the > it might help the implementation (needs only be > prepared to have fixed amount of pre-defined XML elements). > > What do you think? > > BR, Eva > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailman-bounces@ietf.org Thu Jul 1 07:01: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 HAA14364 for ; Thu, 1 Jul 2004 07: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 1BfzJa-0006LK-27 for simple-archive@ietf.org; Thu, 01 Jul 2004 07:01:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfzIV-0005wG-00 for simple-archive@ietf.org; Thu, 01 Jul 2004 07:00:08 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BfzHb-0005BX-00 for simple-archive@ietf.org; Thu, 01 Jul 2004 06:59:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bfxg4-000226-Jo for simple-archive@ietf.org; Thu, 01 Jul 2004 05:16:20 -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: Thu, 01 Jul 2004 05:03:47 -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. ********************************************************************** NOTE WELL: Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: o the IETF plenary session, o any IETF working group or portion thereof, o the IESG, or any member thereof on behalf of the IESG, o the IAB or any member thereof on behalf of the IAB, o any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, o the RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 3667 and RFC 3668. Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 3667 for details. ******************************************************************************* 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 simple-bounces@ietf.org Thu Jul 1 09:37: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 JAA24765 for ; Thu, 1 Jul 2004 09: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 1Bg1kf-0004wm-Fp for simple-archive@ietf.org; Thu, 01 Jul 2004 09:37:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bg1jY-0004VR-00 for simple-archive@ietf.org; Thu, 01 Jul 2004 09:36:13 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bg1iW-0003kT-00; Thu, 01 Jul 2004 09:35:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfyWV-0003s7-JU; Thu, 01 Jul 2004 06:10:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfxYc-0005dU-Qj for simple@megatron.ietf.org; Thu, 01 Jul 2004 05: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 FAA06635 for ; Thu, 1 Jul 2004 05:08:36 -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 1BfxYa-0000Sg-Ei for simple@ietf.org; Thu, 01 Jul 2004 05:08:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfxXD-0007is-00 for simple@ietf.org; Thu, 01 Jul 2004 05:07:12 -0400 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1BfxWO-0007K8-00 for simple@ietf.org; Thu, 01 Jul 2004 05:06:20 -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 i61962614123; Thu, 1 Jul 2004 12:06:02 +0300 (EET DST) X-Scanned: Thu, 1 Jul 2004 12:05: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 i6195u2M012206; Thu, 1 Jul 2004 12:05:56 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00RHujbs; Thu, 01 Jul 2004 12:05: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 i6195nH22215; Thu, 1 Jul 2004 12:05:49 +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); Thu, 1 Jul 2004 12:05: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="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] RPID: what does tuple-type really mean? Date: Thu, 1 Jul 2004 12:05:42 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF01D17359@esebe004.ntc.nokia.com> Thread-Topic: [Simple] RPID: what does tuple-type really mean? Thread-Index: AcRaJk8y2GKYqEAxRmmYH9Tu8M8BGAFIcRVw To: X-OriginalArrivalTime: 01 Jul 2004 09:05:42.0260 (UTC) FILETIME=[9608E340:01C45F4A] 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 > > Ok, let's try to sort this out. As far as I know attributes in XML=20 > > don't belong to any namespace. This means that if we want=20 > to have id=20 > > attribute in we need to separately define it=20 > within .=20 > > This id also has (in XML) nothing to do with id. Now, if=20 > > somebody would define a new element which would also have id =20 > > attribute (with different semantics) client would have no way to=20 > > distinguish this from id or from id. This more or=20 > > less means that client must be explicitly aware of element. >=20 > I don't think that has to be the case. If you got an update that=20 > indicated that the document changed through the deletion of=20 > an element=20 > with id 3, the client could go through its current version of the=20 > document, select all elements under that have an "id"=20 > attribute with value 3, and delete them. This would work no=20 > matter what=20 > the name of those elements are. Right, but what about the case when the watcher doesn't understand the element. Does watcher always parse elements if they belong to a namespace that it doesn't recognize?=20 If it doesn't then watcher will probably ignore that particular element. This should not cause any troubles until that kind of element is removed because 'id' element reported in element doesn't exist in local copy. This can probably be specified so that if 'id' doesn't exist in local copy watcher should ignore that 'id' value.=20 > Similarly, when an element shows up in a partial document, the client=20 > finds the matching one in its current document by matching=20 > the element=20 > name and id value, and updates it. This could also work without the=20 > client needing to understand the semantics of device. >=20 > For this to work though, I think the partial notification=20 > documents need=20 > to be clear that the algorithms apply to any child elements of=20 > , even ones not understood by the client, so long=20 > as they all=20 > have an "id" element. If the algorithm applies to elements which are direct child elements (only one level below) to then this can be made to work. Or did you intend this to work with _any_ element under ? - Mikko=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 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jul 1 11:10: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 LAA08351 for ; Thu, 1 Jul 2004 11:10: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 1Bg3DB-00025H-7V for simple-archive@ietf.org; Thu, 01 Jul 2004 11:10:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bg3Bs-0001dJ-00 for simple-archive@ietf.org; Thu, 01 Jul 2004 11:09:32 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bg3BA-0001D5-00; Thu, 01 Jul 2004 11:08:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bg2Do-0008Lh-87; Thu, 01 Jul 2004 10:07:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdbTj-0004Ol-5t for simple@megatron.ietf.org; Thu, 24 Jun 2004 17:09: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 RAA11378 for ; Thu, 24 Jun 2004 17:09: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 1BdbTh-0000Qo-J2 for simple@ietf.org; Thu, 24 Jun 2004 17:09:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bdaq6-0000r0-00 for simple@ietf.org; Thu, 24 Jun 2004 16:28:56 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BdaDq-0001Sc-00 for simple@ietf.org; Thu, 24 Jun 2004 15:49:22 -0400 Received: from smtp.spamarrest.com ([66.150.163.174] helo=spamarrest.com) by mx2.foretec.com with esmtp (Exim 4.24) id 1Bda34-0007Eb-0X for simple@ietf.org; Thu, 24 Jun 2004 15:38:14 -0400 Received: from [128.104.192.100] (account vanderhe@smtp.spamarrest.com HELO NC6000BAK) by spamarrest.com (CommuniGate Pro SMTP 4.2b1) with ESMTP id 3098525; Thu, 24 Jun 2004 12:38:12 -0700 From: "Gregg Vanderheiden" To: "'Paul Kyzivat'" Subject: RE: [Simple] RE: [Sipping] RE: text/T140 and audio/t140was:[avt]Comments/questions on draft-ietf-av Date: Thu, 24 Jun 2004 14:38:11 -0500 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: <40DB2A59.2030609@cisco.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Thread-index: AcRaIT0tHq7KC8HaSa+8Yv2qaQD12wAAJD7g Message-ID: Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 01 Jul 2004 10:07:21 -0400 Cc: fluffy@cisco.com, paulej@packetizer.com, 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.1 required=5.0 tests=AWL,MISSING_OUTLOOK_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sorry Paul I did not mean for it to apply to phones that had voice only. Good catch. How about this form (changed "voice" to "voice+text" in #3 and added "for people who rely on text to communicate" to #4) ---- 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 - as long as interactive text is always available where voice+text is available. 4 - Voice with IM alone is not sufficient for people who must rely on text and is the concern. 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). 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? 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. Gregg -- ------------------------------ Gregg C Vanderheiden Ph.D. Professor - Ind. Engr. & BioMed Engr. Director - Trace R & D Center University of Wisconsin-Madison _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jul 1 11:13: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 LAA08460 for ; Thu, 1 Jul 2004 11:13: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 1Bg3G9-0002vM-Cl for simple-archive@ietf.org; Thu, 01 Jul 2004 11:13:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bg3Cl-00021c-00 for simple-archive@ietf.org; Thu, 01 Jul 2004 11:10:28 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Bg3Bk-0001bv-01; Thu, 01 Jul 2004 11:09:24 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Bg2HU-0007fr-A0; Thu, 01 Jul 2004 10:11:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bg2Dn-0008L0-KT; Thu, 01 Jul 2004 10:07:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdZrk-0006WN-Hp for simple@megatron.ietf.org; Thu, 24 Jun 2004 15:26: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 PAA17125 for ; Thu, 24 Jun 2004 15:26: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 1BdZrj-0004tQ-9f for simple@ietf.org; Thu, 24 Jun 2004 15:26:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdZQ1-0007C6-00 for simple@ietf.org; Thu, 24 Jun 2004 14:57:55 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BdZ7E-0003Ku-01 for simple@ietf.org; Thu, 24 Jun 2004 14:38:28 -0400 Received: from smtp.eweka.nl ([81.171.101.3]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BdZ0F-0003WP-58 for simple@ietf.org; Thu, 24 Jun 2004 14:31:15 -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 i5OJAVdT052321; Thu, 24 Jun 2004 19:10:43 GMT (envelope-from a.vwijk@viataal.nl) Message-Id: <200406241910.i5OJAVdT052321@smtp.eweka.nl> From: "Arnoud van Wijk" To: "'Gregg Vanderheiden'" , "'Paul Kyzivat'" , "'Guido Gybels'" Subject: RE: [Simple] RE: [Sipping] RE: text/T140 and audio/t140was:[avt]Comments/questions on draft-ietf-av Date: Thu, 24 Jun 2004 20:29:22 +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 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 thread-index: AcRZ7wNDql9y4WfPTi6G4RbpYyS+CgAFnLkgAATqA9A= Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 01 Jul 2004 10:07:21 -0400 Cc: fluffy@cisco.com, paulej@packetizer.com, simple@ietf.org, 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.2 required=5.0 tests=AWL,MISSING_OUTLOOK_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Gregg, Excellent points and could not be clearer imho. Cheers Arnoud -----Original Message----- From: Gregg Vanderheiden [mailto:gv@trace.wisc.edu] Sent: donderdag 24 juni 2004 19:32 To: 'Paul Kyzivat'; 'Guido Gybels' Cc: gunnar.hellstrom@omnitor.se; fluffy@cisco.com; simple@ietf.org; paulej@packetizer.com; toip@snowshore.com; smundra@telogy.com; a.vwijk@viataal.nl Subject: RE: [Simple] RE: [Sipping] RE: text/T140 and audio/t140was:[avt]Comments/questions on draft-ietf-av 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 - as long as interactive text is always available where voice is available. 4 - Voice with IM alone is not sufficient and is the concern. 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). 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? 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. Thanks Gregg -- ------------------------------ Gregg C Vanderheiden Ph.D. Professor - Ind. Engr. & BioMed Engr. Director - Trace R & D Center University of Wisconsin-Madison _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jul 1 11:13: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 LAA08481 for ; Thu, 1 Jul 2004 11:13: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 1Bg3GB-0002wm-35 for simple-archive@ietf.org; Thu, 01 Jul 2004 11:13:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bg3Cn-00021z-00 for simple-archive@ietf.org; Thu, 01 Jul 2004 11:10:30 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Bg3Bl-0001bv-00; Thu, 01 Jul 2004 11:09:25 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Bg2H7-0007fe-20; Thu, 01 Jul 2004 10:10:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bg2Dn-0008Kl-3x; Thu, 01 Jul 2004 10:07:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdYAt-0007wn-9S for simple@megatron.ietf.org; Thu, 24 Jun 2004 13:38: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 NAA03857 for ; Thu, 24 Jun 2004 13:38: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 1BdYAr-0006UN-LW for simple@ietf.org; Thu, 24 Jun 2004 13:38:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdY83-0005Pt-00 for simple@ietf.org; Thu, 24 Jun 2004 13:35:16 -0400 Received: from smtp.spamarrest.com ([66.150.163.174] helo=spamarrest.com) by ietf-mx with esmtp (Exim 4.12) id 1BdY53-0004Dm-00 for simple@ietf.org; Thu, 24 Jun 2004 13:32:09 -0400 Received: from [128.104.192.100] (account vanderhe@smtp.spamarrest.com HELO NC6000BAK) by spamarrest.com (CommuniGate Pro SMTP 4.2b1) with ESMTP id 3095935; Thu, 24 Jun 2004 10:31:38 -0700 From: "Gregg Vanderheiden" To: "'Paul Kyzivat'" , "'Guido Gybels'" Subject: RE: [Simple] RE: [Sipping] RE: text/T140 and audio/t140was:[avt]Comments/questions on draft-ietf-av Date: Thu, 24 Jun 2004 12:31:41 -0500 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: <40DAD5E1.4010007@cisco.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Thread-index: AcRZ7wNDql9y4WfPTi6G4RbpYyS+CgAFnLkg Message-ID: Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 01 Jul 2004 10:07:21 -0400 Cc: fluffy@cisco.com, paulej@packetizer.com, simple@ietf.org, 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=MISSING_OUTLOOK_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit 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 - as long as interactive text is always available where voice is available. 4 - Voice with IM alone is not sufficient and is the concern. 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). 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? 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. Thanks Gregg -- ------------------------------ Gregg C Vanderheiden Ph.D. Professor - Ind. Engr. & BioMed Engr. Director - Trace R & D Center University of Wisconsin-Madison _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jul 1 11:13: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 LAA08502 for ; Thu, 1 Jul 2004 11:13: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 1Bg3GC-0002xm-GI for simple-archive@ietf.org; Thu, 01 Jul 2004 11:14:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bg3Cp-00022E-00 for simple-archive@ietf.org; Thu, 01 Jul 2004 11:10:32 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Bg3Bl-0001bv-01; Thu, 01 Jul 2004 11:09:26 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Bg2Fo-0007Y4-P1; Thu, 01 Jul 2004 10:09:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bg2Dm-0008Kf-Jz; Thu, 01 Jul 2004 10:07:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdR0B-0001h0-0L for simple@megatron.ietf.org; Thu, 24 Jun 2004 05:58: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 FAA20507 for ; Thu, 24 Jun 2004 05:58: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 1BdR08-0004n1-9l for simple@ietf.org; Thu, 24 Jun 2004 05:58:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdQzF-0004Qs-00 for simple@ietf.org; Thu, 24 Jun 2004 05:57:41 -0400 Received: from smtp.eweka.nl ([81.171.101.3]) by ietf-mx with esmtp (Exim 4.12) id 1BdQyi-000446-00 for simple@ietf.org; Thu, 24 Jun 2004 05:57:08 -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 i5OAaadT048120; Thu, 24 Jun 2004 10:36:42 GMT (envelope-from a.vwijk@viataal.nl) Message-Id: <200406241036.i5OAaadT048120@smtp.eweka.nl> From: "Arnoud van Wijk" To: "'Guido Gybels'" , , , Subject: RE: [Simple] RE: [Sipping] RE: text/T140 and audio/t140was:[avt]Comments/questions on draft-ietf-av Date: Thu, 24 Jun 2004 11:55: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: AcRZyRF+GqMqbzYsSxa5lFv+c3zBuwAB3o4A Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 01 Jul 2004 10:07:21 -0400 Cc: fluffy@cisco.com, paulej@packetizer.com, toip@snowshore.com, simple@ietf.org, 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.3 required=5.0 tests=AWL,EXCUSE_16, MISSING_OUTLOOK_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Guido and all, AMEN! And as I mentioned in a previous e-mail. Do you want to try how well IM is for every call? Try for a week or month not to place a phonecall (voice). Just use IM in that case. Then you can see the limitations that IM has when you need to communicate in real-time, discuss things or even simply to reach the other person directly on the other side of the line. Greetings from an Interactive text AND IM user who will use BOTH every day. Arnoud -----Original Message----- From: owner-toip@snowshore.com [mailto:owner-toip@snowshore.com] On Behalf Of Guido Gybels Sent: donderdag 24 juni 2004 10:41 To: pkyzivat@cisco.com; gunnar.hellstrom@omnitor.se; gv@trace.wisc.edu Cc: fluffy@cisco.com; simple@ietf.org; paulej@packetizer.com; toip@snowshore.com; smundra@telogy.com; a.vwijk@viataal.nl Subject: RE: [Simple] RE: [Sipping] RE: text/T140 and audio/t140was:[avt]Comments/questions on draft-ietf-av 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. 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 Jul 1 11:14: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 LAA08524 for ; Thu, 1 Jul 2004 11:14: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 1Bg3GE-0002z0-6O for simple-archive@ietf.org; Thu, 01 Jul 2004 11:14:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bg3Cs-00022Z-00 for simple-archive@ietf.org; Thu, 01 Jul 2004 11:10:34 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Bg3Bm-0001bv-00; Thu, 01 Jul 2004 11:09:26 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Bg2F8-0007Xm-7S; Thu, 01 Jul 2004 10:08:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bg2Dm-0008KP-0M; Thu, 01 Jul 2004 10:07:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdQsN-0001FL-Hk for simple@megatron.ietf.org; Thu, 24 Jun 2004 05:50: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 FAA20046 for ; Thu, 24 Jun 2004 05:50: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 1BdQsK-0001ox-PA for simple@ietf.org; Thu, 24 Jun 2004 05:50:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdQrO-0001Se-00 for simple@ietf.org; Thu, 24 Jun 2004 05:49:35 -0400 Received: from smtp.eweka.nl ([81.171.101.3]) by ietf-mx with esmtp (Exim 4.12) id 1BdQqQ-000168-00 for simple@ietf.org; Thu, 24 Jun 2004 05:48:34 -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 i5OATPdT048048; Thu, 24 Jun 2004 10:29:30 GMT (envelope-from a.vwijk@viataal.nl) Message-Id: <200406241029.i5OATPdT048048@smtp.eweka.nl> From: "Arnoud van Wijk" To: "'Gunnar Hellstrom'" , "'Dean Willis'" Subject: RE: [Simple] RE: [Sipping] RE: text/T140 and audio/t140 was: [avt]Comments/questions on draft-ietf-avt-rfc2793bis-04 Date: Thu, 24 Jun 2004 11:48:19 +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: AcRZZwom9q/7gcKUSsq6yf/bgp121QAZyROA Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 01 Jul 2004 10:07:21 -0400 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.2 required=5.0 tests=AWL,MISSING_OUTLOOK_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit I as another Interactive text user fully agree with Gunnar. Dean, RTP in RFC 2793 excellent for text transport. It works like a gem.. I will show you at the upcoming IETF if you like. But trust me. It works! Interactive text is a real-world application, used by more and more people. I also want to stress the uses for IM and Interactive text (T140/RTP). IM is a wonderful application. I am using it and I will always use it. But in situations where you prefer to use IM instead of calling the person directly. In my case, when you want to use the telephone to place a voice call the other person directly, I will use Interactive text (t140/RTP). Because for me as a deaf person, this is the most close I can get to a real conversation. And in that case, I do not mind the slow typing, corrections, changes in the story in real-time. Since you don't mind the changes in the dialogue, stutters, hickups, mispronounciations, distractions because the baby is crying etc in a voice phone call. That is part of a phone call..it is normal. So, what do we have? You can put the use of Interactive text (t140/RTP) as follows, from Real-time to non real-time: Interactive text (t140/RTP, RFC 2793)**** Instant Messaging**** E-mail They are all 3 different ways for text communication. They all have their strong and weak points. Just use them for the best situations. I encourage the IM people to use the same application for Interactive text! Some interface changes perhaps, but then you have 1 application that can switch between IM and text/t140. And to people who say that IM is enough for communications and that Interactive text is not necessary. Please e-mail me. And then promise never to touch a telephone and use IM to communicate. I guarantee that you will get crazy. Welcome in my world then! Greetz Arnoud -----Original Message----- From: owner-toip@snowshore.com [mailto:owner-toip@snowshore.com] On Behalf Of Gunnar Hellstrom Sent: woensdag 23 juni 2004 23:11 To: Dean Willis 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 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 -------------------------------------------- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jul 1 11:14: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 LAA08549 for ; Thu, 1 Jul 2004 11:14: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 1Bg3GH-00031p-5T for simple-archive@ietf.org; Thu, 01 Jul 2004 11:14:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bg3Cv-000234-00 for simple-archive@ietf.org; Thu, 01 Jul 2004 11:10:38 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Bg3Bn-0001bv-00; Thu, 01 Jul 2004 11:09:27 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Bg2EX-0007XR-Su; Thu, 01 Jul 2004 10:08:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bg2Dl-0008K9-HG; Thu, 01 Jul 2004 10: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 1BdC3g-0002Kq-Ns for simple@megatron.ietf.org; Wed, 23 Jun 2004 14:02:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22877 for ; Wed, 23 Jun 2004 14: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 1BdC3f-0007By-AF for simple@ietf.org; Wed, 23 Jun 2004 14:01:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdBBr-0006Z6-00 for simple@ietf.org; Wed, 23 Jun 2004 13:05:40 -0400 Received: from smtp.spamarrest.com ([66.150.163.174] helo=spamarrest.com) by ietf-mx with esmtp (Exim 4.12) id 1Bd9r7-0004zj-00 for simple@ietf.org; Wed, 23 Jun 2004 11:40:09 -0400 Received: from [68.31.68.150] (account vanderhe@smtp.spamarrest.com HELO NC6000BAK) by spamarrest.com (CommuniGate Pro SMTP 4.2b1) with ESMTP id 3074428; Wed, 23 Jun 2004 08:39:35 -0700 From: "Gregg Vanderheiden" To: "'Gregg Vanderheiden'" , "'Paul Kyzivat'" , "'Gunnar Hellstrom'" 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 10:39:24 -0500 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 Thread-index: AcRZKlJzcvwEhVHiS8WMWHm0SO0A2wACPd4QAAEVn5A= Message-ID: Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 01 Jul 2004 10:07:21 -0400 Cc: "'Cullen Jennings'" , "'Paul E. Jones'" , simple@ietf.org, "'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.2 required=5.0 tests=AWL,MISSING_OUTLOOK_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Forgot one On number 1 - it should also read... "And for those who are deaf but can speak, the keypad is not needed for character entry except on rare occasion. They just need to be able to see the text displayed on the screen and can speak in response." I added it below. Gregg -- ------------------------------ Gregg C Vanderheiden Ph.D. Professor - Ind. Engr. & BioMed Engr. Director - Trace R & D Center University of Wisconsin-Madison -----Original Message----- From: Gregg Vanderheiden [mailto:gv@trace.wisc.edu] Sent: Wednesday, June 23, 2004 10:25 AM To: 'Paul Kyzivat'; 'Gunnar Hellstrom' Cc: 'Cullen Jennings'; 'Toip list'; 'Mundra, Satish'; 'Arnoud van Wijk'; 'Paul E. Jones'; 'simple@ietf.org' Subject: RE: [Simple] RE: [Sipping] RE: text/T140 and audio/t140 was:[avt]Comments/questions on draft-ietf-avt-rfc2793bis-04 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. (And for those who are deaf but can speak, the keypad is not needed for character entry except on rare occasion. They just need to be able to see the text displayed on the screen and can speak in response.) 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 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jul 1 11:14: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 LAA08570 for ; Thu, 1 Jul 2004 11:14: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 1Bg3GI-00032t-KY for simple-archive@ietf.org; Thu, 01 Jul 2004 11:14:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bg3Cx-00023J-00 for simple-archive@ietf.org; Thu, 01 Jul 2004 11:10:39 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Bg3Bn-0001bv-01; Thu, 01 Jul 2004 11:09:27 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Bg2EG-0007XK-Ev; Thu, 01 Jul 2004 10:07:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bg2Dk-0008Ju-TW; Thu, 01 Jul 2004 10:07:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdBsJ-0007z1-1N for simple@megatron.ietf.org; Wed, 23 Jun 2004 13:50: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 NAA19942 for ; Wed, 23 Jun 2004 13: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 1BdBsH-0004qv-BZ for simple@ietf.org; Wed, 23 Jun 2004 13:49:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdAlY-0003WT-00 for simple@ietf.org; Wed, 23 Jun 2004 12:38:29 -0400 Received: from smtp.spamarrest.com ([66.150.163.174] helo=spamarrest.com) by ietf-mx with esmtp (Exim 4.12) id 1Bd9ea-00032b-00 for simple@ietf.org; Wed, 23 Jun 2004 11:27:12 -0400 Received: from [68.31.253.12] (account vanderhe@smtp.spamarrest.com HELO NC6000BAK) by spamarrest.com (CommuniGate Pro SMTP 4.2b1) with ESMTP id 3074149; Wed, 23 Jun 2004 08:26:40 -0700 From: "Gregg Vanderheiden" To: "'Paul Kyzivat'" , "'Gunnar Hellstrom'" 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 10:25:08 -0500 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 Thread-index: AcRZKlJzcvwEhVHiS8WMWHm0SO0A2wACPd4Q In-reply-to: <40D97E0D.1030906@cisco.com> Message-ID: Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 01 Jul 2004 10:07:21 -0400 Cc: "'Cullen Jennings'" , "'Paul E. Jones'" , simple@ietf.org, "'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,MISSING_OUTLOOK_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit 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 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jul 1 11:14: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 LAA08594 for ; Thu, 1 Jul 2004 11:14: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 1Bg3GL-000353-8M for simple-archive@ietf.org; Thu, 01 Jul 2004 11:14:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bg3D0-00023l-00 for simple-archive@ietf.org; Thu, 01 Jul 2004 11:10:42 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Bg3Bo-0001bv-00; Thu, 01 Jul 2004 11:09:28 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Bg2E2-0007XG-5U; Thu, 01 Jul 2004 10:07:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bg2Dk-0008JI-B3; Thu, 01 Jul 2004 10:07:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bdl9x-0007qB-D3 for simple@megatron.ietf.org; Fri, 25 Jun 2004 03:30: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 DAA13763 for ; Fri, 25 Jun 2004 03:30: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 1Bdl9v-0007dn-8O for simple@ietf.org; Fri, 25 Jun 2004 03:30:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bdl91-0007JG-00 for simple@ietf.org; Fri, 25 Jun 2004 03:29:07 -0400 Received: from [217.158.120.227] (helo=rnidmail.rnid.org.uk) by ietf-mx with esmtp (Exim 4.12) id 1Bdl8U-0006sc-00 for simple@ietf.org; Fri, 25 Jun 2004 03:28:34 -0400 Received: from rnid.org.uk (unverified) by rnidmail.rnid.org.uk (Content Technologies SMTPRS 4.2.5) with SMTP id for ; Fri, 25 Jun 2004 08:27:25 +0100 Received: from RNIDMAIL-Message_Server by rnid.org.uk with Novell_GroupWise; Fri, 25 Jun 2004 08:15:33 +0100 Message-Id: X-Mailer: Novell GroupWise 5.5.2 Date: Fri, 25 Jun 2004 08:15:16 +0100 From: "Guido Gybels" To: , Subject: RE: [Simple] RE: [Sipping] RE: text/T140 and audio/t140was:[avt]Comments/questions on draft-ietf-av Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Thu, 01 Jul 2004 10:07:20 -0400 Cc: fluffy@cisco.com, paulej@packetizer.com, simple@ietf.org, 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.2 required=5.0 tests=AWL,EXCUSE_16 autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Gregg, <> No, I think you summarised it very well. Thanks! Guido ************************************************************************ 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 =20 Registered Office 19-23 Featherstone Street=20 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 Jul 1 11:14: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 LAA08619 for ; Thu, 1 Jul 2004 11:14: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 1Bg3GO-00038Q-Fd for simple-archive@ietf.org; Thu, 01 Jul 2004 11:14:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bg3D3-00024L-00 for simple-archive@ietf.org; Thu, 01 Jul 2004 11:10:46 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Bg3Bq-0001bv-00; Thu, 01 Jul 2004 11:09:30 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Bg2Bp-0007RU-4t; Thu, 01 Jul 2004 10:05:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bg2Dj-0008Ii-OQ; Thu, 01 Jul 2004 10:07:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdVxO-0004zv-WB for simple@megatron.ietf.org; Thu, 24 Jun 2004 11:16: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 LAA20638 for ; Thu, 24 Jun 2004 11:16: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 1BdVxO-0003uX-3x for simple@ietf.org; Thu, 24 Jun 2004 11:16:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdVvy-0003VW-00 for simple@ietf.org; Thu, 24 Jun 2004 11:14:38 -0400 Received: from [217.158.120.227] (helo=rnidmail.rnid.org.uk) by ietf-mx with esmtp (Exim 4.12) id 1BdVur-0002mV-00 for simple@ietf.org; Thu, 24 Jun 2004 11:13:29 -0400 Received: from rnid.org.uk (unverified) by rnidmail.rnid.org.uk (Content Technologies SMTPRS 4.2.5) with SMTP id for ; Thu, 24 Jun 2004 16:06:05 +0100 Received: from RNIDMAIL-Message_Server by rnid.org.uk with Novell_GroupWise; Thu, 24 Jun 2004 15:53:45 +0100 Message-Id: X-Mailer: Novell GroupWise 5.5.2 Date: Thu, 24 Jun 2004 15:53:35 +0100 From: "Guido Gybels" To: Subject: Re: [Simple] RE: [Sipping] RE: text/T140 and audio/t140 was:[avt]Comments/questionson draft-ietf-av Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Thu, 01 Jul 2004 10:07:20 -0400 Cc: fluffy@cisco.com, paulej@packetizer.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.2 required=5.0 tests=AWL,EXCUSE_16 autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Paul, <> I might have missed something too, but I don't recall actually making the s= tatement that was what people wanted to do. I merely pointed to some import= ant points re text messaging versus interactive text - not in the least bec= ause experience shows that unless people know about issues like relay conve= rsations etc. they not always appreciate them fully. In my job, I am confro= nted with this continuously, so it seems useful to reiterate them... <> In the interest of brevity, I will have to refer to previous contributions = here, but I'll summarise them very quickly by saying that the agenda of inc= lusion is not going to be met by putting deaf and hard of hearing people in= a niche in the market (or moving them from one niche to another): http://www.ictrnid.org.uk/euc/txtgg.html=20 <> But in a context where the ability and the availability of the communicatio= n is critical for the individual to integrate in society, making sure that = the facility is available in the *mainstream* and fully interoperable, is v= ital to success. For hearing people, it is a matter of *choice*, for deaf p= eople it's the difference between inclusion and exclusion. <> Agreed. 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 ************************************************************************ 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 =20 Registered Office 19-23 Featherstone Street=20 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 Jul 1 11:14: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 LAA08640 for ; Thu, 1 Jul 2004 11:14: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 1Bg3GP-00039O-Mc for simple-archive@ietf.org; Thu, 01 Jul 2004 11:14:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bg3D5-00024a-00 for simple-archive@ietf.org; Thu, 01 Jul 2004 11:10:48 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Bg3Br-0001bv-00; Thu, 01 Jul 2004 11:09:31 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Bg2AA-0007Ok-D5; Thu, 01 Jul 2004 10:03:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bg2Dj-0008Hz-3B; Thu, 01 Jul 2004 10:07:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdQ1A-0006Nc-KE for simple@megatron.ietf.org; Thu, 24 Jun 2004 04:55:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16618 for ; Thu, 24 Jun 2004 04:55: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 1BdQ17-0004k8-Ta for simple@ietf.org; Thu, 24 Jun 2004 04:55:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdQ0C-0004O3-00 for simple@ietf.org; Thu, 24 Jun 2004 04:54:37 -0400 Received: from [217.158.120.227] (helo=rnidmail.rnid.org.uk) by ietf-mx with esmtp (Exim 4.12) id 1BdPzO-0003es-00 for simple@ietf.org; Thu, 24 Jun 2004 04:53:46 -0400 Received: from rnid.org.uk (unverified) by rnidmail.rnid.org.uk (Content Technologies SMTPRS 4.2.5) with SMTP id for ; Thu, 24 Jun 2004 09:52:34 +0100 Received: from RNIDMAIL-Message_Server by rnid.org.uk with Novell_GroupWise; Thu, 24 Jun 2004 09:40:47 +0100 Message-Id: X-Mailer: Novell GroupWise 5.5.2 Date: Thu, 24 Jun 2004 09:40:43 +0100 From: "Guido Gybels" To: , , Subject: RE: [Simple] RE: [Sipping] RE: text/T140 and audio/t140 was:[avt]Comments/questions on draft-ietf-av Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=_FEDF699F.11705B30" X-Mailman-Approved-At: Thu, 01 Jul 2004 10:07:20 -0400 Cc: fluffy@cisco.com, paulej@packetizer.com, simple@ietf.org, toip@snowshore.com, 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.2 required=5.0 tests=AWL,EXCUSE_16 autolearn=no version=2.60 This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=_FEDF699F.11705B30 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Gregg, I agree with all you say and I'd like to add an important point. It seems w= e are going back to discussions we had a year ago. Messaging can NOT replac= e 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 re= lay service for text-to-speech, like for example RNID Typetalk, messaging s= imply does not work at all. Streamed, character by character text is a MUST= for that type of conversation. 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.=20 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.=20 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.=20 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.=20 =20 Gregg -- ------------------------------=20 Gregg C Vanderheiden Ph.D.=20 Professor - Ind. Engr. & BioMed Engr. Director - Trace R & D Center=20 University of Wisconsin-Madison=20 - This list is maintained by Snowshore Networks - http://www.snowshore.com=20 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=20 ************************************************************************ 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 =20 Registered Office 19-23 Featherstone Street=20 London EC1Y 8SL No. 454169 (England) Registered Charity No. 207720 ************************************************************************ --=_FEDF699F.11705B30 Content-Type: application/pdf Content-Disposition: attachment; filename="Text communications for deaf and hard of hearing people.pdf" Content-Transfer-Encoding: base64 JVBERi0xLjIgDSXi48/TDQogDTE0IDAgb2JqDTw8DS9MZW5ndGggMTUgMCBSDS9GaWx0ZXIgL0Zs YXRlRGVjb2RlIA0+Pg1zdHJlYW0NCkiJzFfLkttGEvyC+Ye+7chBQniT8G1trb1zkDbComPDEXNp Ak2yLQDNxYMU/95Z/QBAcDga7clySMYMie6qrKysrJ82D5nPVknihWvGNh8efEb/NXv28P4XnwWp 59Pvdw9L3/OjVYrnnA2PZ/a4EV87lquq6muZ806qumU71bBC8N2CHXhTMLVjB8EbWe8ZrwvWHoXI D8t3bPMnblsGay+M6WpGV4SRu2EdmQtkdeSyEQU7CnUshTe8l3hBqN97/0vA9KOJMljbI4JobY74 tZeFYr9etqJsF+wDTss7hIi4Pokz2yCaWpVqLwU+/e3T0wd3RZR4ibsCWASeH+tb6BLfQmFueKq7 RhV9TvkPAQbj2yEL/CmSceqQDAL9JULyIFvWHlTTsSM/iobJuhN10bJOsWOjTrIQrFWVwO9buT90 9Lli3UEQorncyZzVAjgR+vRqwxHOSbAOFdIxbX7QEMfZcHeU2Sr+PwWcFUZfEa59L0lZTP+4zFMv XlvYdJUG0AL9SuRFKVtevTFi9WjKvQzXkZeFbBnGjizXFaG8kiCweYVBFkzYyVuEzcT/ennipag7 AvSkZC7eUqkkyBxaK/2IU/9twTCJs74VjLMTfie6C4F1hSZrL20nKlBrq7oDMzDFmZdqGOjKaHZl uI6mMOWqPomm1YfxUr+fZBSwfyfkdBW7kH39iEPY86NOGWwoxfGg6suCPf3288LAG/kZ1WYChCZK MvRiYk4hDiqkV+9EI+ocGCyY6HLv+R2BfBZlSf/XZwZxNI1xnmOUBNMca1UvX8hztXotzzgeiJzG lshM1aJFsp8/fkZoFZflglWibfleAH+QudURP7/z2OYgLLlCzaN59mk0oJhZIalEd1AFFbwgEo11 FmiXo25WFJxaEslQ3y2muNiP+FaWsoPY6GY6NsKAiZ9Bne4wZaXRZB1OMiYb22gQRtN67KlmIBb0 4qyQ3o9aIzqJpBlAYGeJy7fQiH4HhZCg/4Kd8W2BgKR7M+ctaR89Q14QmFESkhdefrltE82yNHQB rVMrYYWW1vLCrDCZ04+86UA3o0ttx5ErIKQGmlFy0PYwMo1tU/eHFgzDbCKWR3RhLqkFSaH4SR+J NlS9I2GkK3uPhEk2MNw8UolVYSpx1cT6tCzz1vFdNg6Da2WZyE9gH98iOqpzflCqNQrK+BF6juCJ N+CrZWHke+v1HOUkTAYWui40VKOzwChLNH3HyCxdwy/iwnZcjzpUuq8L0AXo6zepOi9OC6PJaUix +EMYUWSKTc/r1PKP7qWznh+HEbO0b86zSIOhgvHKvW2rDvF4y7xhcyPAfif+IxMOA8LrWnVaie8o u87Cd2H4mW8nRNfwQhrJAW9BImHbm0AdYjRsSnwaZW8bbuG3h5tGZmS2pc1MV84SQ0Nw5K+byWP/ hEno88NiFiFKbioQJBHRdF4BTUubuq2Asw0680pwMxmhFUQOfbptIh3x3WkVXU2rcczql+PgNQVP kkFjV0k0AmB0YToQvsNTLjGoMV3nAIxzPHBz/IZRG8Uq/gUS2M0cA647E89MYNI4pMOVDbgpSNW3 3cs8jB1V3CNiUTuMgemV+tU0Jb9zD3o/W02h3wne9Y0wPIhCTMX7wEdDOw96BY2ADFRa/Ezt1uPl posHX7FK45fMiYT/wVwxKBVKaO96DZM1dEGcejgDs9cbZ1wauQtCf/BaRtb5S5zQvUHjDiJKRclB DciYaCR18PZCc6yvtkJb/cEkO5h+HIoTjqYyngG1StdTiJ/DdGWwoZZ26CaTl/xhDKysTLou8uL7 wyMOB4EMXEGeapCssuwv1VnPa8ztktF0h+qCjyXGeMd2jap005Ij+AfmIhBCtqTncDsnUTMJZ0Fr jm12fMq/ANY7Mpm6VrGPJJM0byV5GLzOy0rhWoplSbE8v7NFXf8twExH55a4BecP1dOQMKOu6Y/d +y1v9rRLMU7NDkw6bn629m2g2d8qt3CwgfYR7/18tW7Q6HfE6M5qeeZ2esWkim8bXpEbJbSmLMOV d298xdlgAgOXBkS0ECW418xEVHwFMSVZ3cV3b5fzMX/Hk442w453oxp6rG8FGsH4TmPn4K9f2U+G cZEkrgduLUGSeOn6PhH9QTBTp2ce+08trNNnedPnEg3tJEn/fj7WTeqShtCODA8fFfTaab2UhZP5 KLTmcdDI5fayHH6wiGhC3NWoaDWg69zTlpPSDv5R1R77rLTmNBdIhjaaFDySuBzxTb2NwP6i3vBz lSjIA0NRzGpkEjNR3OyiA9H8xI7MNm+opDh/3DUE2WD8PVHZdQvTooevWIgpFADciIquBclU05Hx Qd9XWhJfMn43PEvicSMJ0rnxoaH3LbeAtU3DwstWUZuMkdBmRrPtcGFPHx3jO3IlBOXLy2G0zqbt 2yg3Z292qXiMPHDa/mk6oxu63KigbFgj94eOVZI227PqS9pX1VHBZiNHvlWlbA/zLQ6NlnNy4jfr 7BWCo/OLrfMTX2XbkTzQm3YxvZI20LWuRdmyUgKOJ71LduyjaFu+N4vI00dsEwBbVNi9tFcmaiDQ E4mAcUabH2wEA5390I7cihdoSmhns6CGQ30IfLzeQ72kjoisBi4YGGe0NYvJbb1NXOO3bQaxGyg4 2W1cHvtErYV7SyS90N7HCaTWuLbf7wVALOC+3HxfBtmKoL8xxEMFgsBW4NjAI7XUGbptzweyDh1V wVi571Vt6j1htyoUi+KakXgaUDTOksi2ODqgPWjebd1eptAhx5LnYtap1ul0+Pr+QK2j/SfVD5Q9 ycKsNbu+zkevit/YUWJJEYduIYOLsIrZ6zWzFqKgdIwNMrqnrFkoedvCWFay7esCXwYti0H79PFh nFG9702bJLgyD9wtnLH3issJRzl2/NWQLE1wZB6pSlctZAgRppG3utmQ4tVg+zI38sgyvYC86XhS NVpFte1s592mjmLXk9nE2C+5rEFXNwu0ohFwCFTbr7K8pxKju7DVeH78E3uVVYBJka9DG8VoKr06 zgXbopsbbrrZjlRMkaKQhhisUgVJ0JQXketF86QXnwmsEB1qAiMZpnR++NrmFiRXkoC2wQAlv248 Y+itwruFT8KxccPIFZ6g5VqdBcSrIsAx5Xg1DueT7RhDjxdoEcSxl93SYj3oUOi2vvYCjanMNAc9 +Alqy7eloQRVtsInOFcbmm+JBptbPVnP5oaddOR5/XSK21k1ZTFOutjZc3+I2MLz6h/9/iob3OD9 r+tv/mvzkPkMdpeKEpBXJ6WHtdg9/GQ+SjOy8DjqgaqXmPl7OwgCIw0eUF1GE4u98rSrphf8yBab KuH7tivZfw9SW2KwrVB5X5Hp2OGhJQtZzy0kFeV7i0DNKpATb5yzouZh+0b1x9aqiA48M0mZ6oTx 0CYra4s0MckN0F1bUYuddAvrdZS6oylU8ZVXRAMKeVvCejhePD8a975tQDfKXzRwJnBQz+8GDiSj GX4F+fANyIfZkIzvaPRUs0KSZAht1PaO4kR5zcXF5HMTnirVXrv4UUPxOT1c5+/R4XSOnpMklviY PkFJdRF2sEbXwEfpAHwwAh9ZSdD3NOZO3rLN5g8cetbEsUvu7391Xja7CcNAEH4Vi0svKUoCKuTa a1X1QF/AQNJaShoUG9G+fWd3beenRILeQIq1/tmZ/eaF79swR1Eo031R2jGXhEnjrgHVaoHTGNjG Ah9WLqCQPzzmK6zetpjUZJ+1vfNFVre8yFM4ZB4e5P0C1NY/feKVzvrkkdU9WAbaU8nuR9GkmVID OaZrD23tb/mrJlypq8fjGS33LcNCWyEF/mQUoOaUkIWtZmkaBkbMWmLAsTBQs1J7iEzmEyelEGqs ph2bJuoxWG6nTwbavRh34Ji1L92FwtARGmbA4XF7RthBO/Lx65hlhp2zKrLoLxLwGAMJmNggFM1w JZchFoBxXnam5IYZEpcMP0PSJT/iWMhX6Vff1w/rW7wxLeLes7VPpOqNkOfcWTEQtp2p7Xk/IVfa ve4SSQsJcAI/3QGHrluXqJ4zrqyTfkCrE0ga0igtgtba5aw7Fr2VZ7nHmWe0FxfShDEsKc/wVmY6 Qyv6Rv7N7kTKU6AMAXI+oHEvqUHa6q51RraJciu264DC+iNoHkXH6UygwA6RrCESpGJEz2w2FHV7 IEnGappK5C+jpBOZ5ZHLtpt8xCb/GXrLMN9/ARATBS8NZW5kc3RyZWFtDWVuZG9iag0xNSAwIG9i ag0zMTQ1DWVuZG9iag00IDAgb2JqDTw8DS9UeXBlIC9QYWdlDS9QYXJlbnQgNSAwIFINL1Jlc291 cmNlcyA8PA0vRm9udCAyMCAwIFINL1Byb2NTZXQgMiAwIFINPj4NL0NvbnRlbnRzIDE0IDAgUg0+ Pg1lbmRvYmoNMjAgMCBvYmoNPDwNL0YwIDYgMCBSDS9GMSA4IDAgUg0vRjIgMTAgMCBSDS9GMyAx MiAwIFINL0Y0IDE2IDAgUg0vRjUgMTggMCBSDT4+DWVuZG9iag0yMiAwIG9iag08PA0vTGVuZ3Ro IDIzIDAgUg0vRmlsdGVyIC9GbGF0ZURlY29kZSANPj4Nc3RyZWFtDQpIicxX0a7bNhL9gvsPRF62 WdiqZMmyvW+bpgGCRdOidbsveaEl+pq5kqiK0nX89z0zJCXL17dAHwo0ARLZFsnhzJlzzrzbP+xi scnjaCvE/v1DLOhv9ygevv2QiCSOYvr++LDEU7bZ4bkQcZTE/HgW37xX8rgQJ9mVwhzFSclON49C NqWwrVLFSei6lbpTpWiVaSslOvX7gM9Cil597cVBWlUuRIEdZNGrbnm4LMcPi7di/wUhLZMkWq8o PkFxrNMsxLHOfBy6wftYpJ/VQhyHqhLlgOO+isLU9dDoQvbaNMJebK9qIa04K7xD/+tS2bZTshSy KJS1ojcIrat1Iyt8OMle2KFtTddzNPt/cwxptvIx+EeKoV8Iq2tdyY42OdPSZ6MLhf0q1Z5Mc0GS jqrjM0KufF50w6daSuNxaAoKV1a6vywE3820uN9B0zfXcWRpGnKR8yPioOzLZ4k4rt5HFldptMk5 i99+iAVyGmdjbfM03GeVpf4+eyrQFDpt+7Oq5EX8orpnXMu+LM+3H1Y3oFnvkhBgxo8eNOHepRGN 6YVpqstVrRTq0p+E6U+qE+X0eiT2J3URjQKgkMMXC/A+EGZnpVonmxDBKt+4CJBkevVsugro+zLY XlT6CahsLqZRQlUWR31sxBGQWvCrPpe3pxam6XUzmMFWLkMKBWYY4rO2szhW6xG2/Ig4kOFO1fxu TRCTTU9IMEMnalOqrkEQR9PVDr2/mEIrhwih6rYyl1o1BDp8Lyvc4AjwK0JLL3VDvwnVF9E8iDEZ 8dYnY2+wSB4q5VpyqvhgPVZf5NnBmn/n9KCh1VeNLHYMEOsBsnBZxQ2uY8izsX/TPAv9a3F57Pnz p4/vxf7Sql5WT9wVSP6v/+P1SbqL8q3IonU+oi2PMgc2Kq/b1u245iVplOZiOVtxS2r5RGq5WypM 55F0dRnXusDdAQ3QonV7rvcP332MxHdD11G2OX+8ig9fJllKTXbLX6vQs/Eu90eGjFFOxWmoJUBA Hd+bzpOQoyiQFkXmCkVf0yffIJ0FRnqkznEYfpjKxLHyb69w6liSbL11IR1k8RQ24hN4n3M4dOQv 2aEtrLxYbk68FVrFNZm9yaPFZgUuY/HUyVaX1YzQ1tnEFyvPF9p168TxtHsJpm20xQERaMkiGqhN IbtOo0Zm6KlODCaQPMVI4UjR6gps89Mv+0/Ljz+JRwD6LC9XKVltx5RkeZA7AMPLTNuZL2hvCJ4V 9mTOjSvCffm6CthXTFvBZ63WOWEw9phMbzHJUYxIbhTpkuxcnNQD48pbNOdJQHOcjmhGDQlVLxDt 5HW52q2pq24BkY9E4bmKyfis/U7Xd2tkP3TK15so8RlYdJRVaivbFsWxwG5twBDgEhA5SOYSjcKU QXVeEab1JghTstl4YaLyiRt1sn9Bk7JNQDs40BPQjyhlJ0vtdJcRcrV7o3poxZNdzO7tapmkY0Gc 3Iw0vwmpo+JTr2gCf4WlxCODpa/oJzqDYLwfn31leOubwmSToI5yRuUlvaiF7S/M48WpMZV5ZL3y RwL9+PdClksXL7EZaI4XvGLq7nNHNrVssvIROfe3vHF/kfiveETv96IZ6gNCwvalZl4N7DnlHL3W m8LAhMmO/RHdUhadIY92UjPSiEPO493a59xrexAgMSrMx/2vy734LQK7fP6GIemBO5Vi0p3Z0s9v obUKSQRAXC9uyDdPtd+l6+vGfSeH0jgvsnSvvnCyo3sblfAZ2ebeAdjewaQukzhdTEHj+f3+hw8k UYikEd+/3wM4RtTyiRoThbJkayycAKo7jJFmWbT9M8bJrwPX1KLkH1wg/gZuiyuWvOP24qsLub0K 2fgas3UgdwOH9YYyWgJhb8g/DBaet2Ozx/TAdh2Qg+8BSllY0DpEGyfTSarXCI5FMPOvzQrbkcY2 XtikdZrmgUeSdEB/K2STk9/07MIpzHAME34tS+Cwd11UMICtqR265tiduZ2JD/KAzbvG6tgpMoLs r5QsvPuNxP/ZXl05Lnjm5l+9K/9JPnPLouQISh4gfLPxIN6MjbHy7Hnv3oHf2PmE4WcxdYQ/uHA+ B1HyuY3BaIRAq6F4isSPTZCAufvOJrryEKeq1m3PGZBl2dHUBU6oYAp61mobWhL5hy+tydMPVQ8e 8Y1Z4vKVadni+ldDhyTbud8dy5+G5NcHyGAlRYDgnQJGvFEY/KzY3NCUS8oVQ8Fd4dMzDZNCzgJY j/4yWfuWqAnH7thGPZpeO7R78WwUD3+YP+AwK2umKCRPq3BNzSOnenIaVvXWx4xGgTEhlpqFkY+J yHIPhLHV3DA1Nj3fpjjplnZ1BNgzB0/TCmVDFygJLTxqGjhdF9L/vw+6p5db1VjIy2z+yLYjHJIw fky0S4fIipzuxXXZuAlV3E0UNC16FDjAHFQhvb+58A5vID40EL0RCqEwSGapSMeGTAMmUDb92ChX E6+TvAtuib7vnhTGrANMJae4kC2PSyS5Xp64GWvTUQUtGoSnRychoPE98ccshknE82QXYmBMIwjp jmkr2dPw5wbQ33THdM6+55PrVwgYOpgA8NSQGR2akmwnqkbEojoeCxsJjnq3n1VhN7JivNtOZXgP rS76z2+dq+WBx7pYjkNTOGtE3vvKUlNonj0i8aEzNX8DInqGAgE3Z11Vji1QJ7Dla157zEea+IAc zaLGnTfZfsh6VA0NRuQubxyDdmERMGUHlB4reXacgXnqQiSCkvauW1nHVXV5RTZWV7y5CbxpZfkM dZCPPMRgIqKNbm2Sczr/Gb1tGm3C7JndqOUmn/n8z/BzvIzH1SDV66tF8TiQBC1z6g6fmGWvDgXZ Zpw3t0n+ounYVk2kohviBeSXEB4oEn1njj1BXMmGbun0IKgAmsY0SHiFmQxscj+nSXp92UB0NMs5 f5GQt1hNk8Br2frb8rTJRo7cZZ4j94FU5nT01yL+u+s7kYl7xLqPZO8b6aeZQlaVnz9cGblaLZw0 V1kfxcGQ62jK1miyPw4TV0AIpuCfdfE4Gddl2V01IbUg0cR15bPUFfM2CKEdDpA+olgWlZMBi1hH tEys/MNCqL6IFuJ80nA5BP0746WzvaPIp3ka6BwE4cjA9YnLPLrlLC833u8fldV0Nw5TaZyObUAz GHJa8cSEW3jSD+7kjolimQZu2M0BgeZMGHTjSJxMIdCh8XYzG0AIvrQ9Viz8+OGW3GQ+DTlBEbKr tSP0S+2wv+AmIJP2yH6T9D50hRMSV20+bLXaUhk4sSFJeZT5rMLJXseau/hWWU5rlqtNlOavpHa9 naxHcGE/kDTN7a51+kkIgfEhYQdc6Pcj3J4Tw5fKN3lzwryE5NHYCi9V38dsthmdWJp61mALa5E4 Z3agsjSSyStHNb4hSH5NS5Grr9r2LpHHDo6sGzB4dsoFeoZXoICCm0LOZ+PReuzhZB0c4cyNwUN8 Rk2LaijpDONsFeSH/CAsIEwTDAu9OUXp1GmwtOCOG4xCRtIsSl1GQqskviriT//w+s0uWnkEv/46 v/n9/mEXi2S9i3KREOwJSkjQ8eGd/wVmiDZ6IMisUZu7QFs7bEYYo5Zp9Efl1bLbJhBFf2WaTVvJ Qg4UbHfXh1R1kS7iLLMZwySgAIPANPHf95w7D5w0rdqdsWy4cznPBWObZJf6P6wzjzDhhievAixr O48sEJU+rVRW5PzA6xNSi5O96x/fv6qb02COun3AdC1UKmw5VhuK2uq3yCN5ajAGIokSoREiK698 nhoy8i7wglkg38Yx0yBO0nw5CjIBmBsejge5fW+YGNfhFllanC/niAAzlVYwElqtkGQZLlGfypLc 92y6fnZGdlEIhIMOUMYLr3FTSJaYxZ3IzYIjXaZhnnSTnh3Jw0gaQI/AME440d4/6ovtq4b6hM4W N46GAMeyiPAqW68VigDoZ8cpgjUP7P0rSIp/AElaBLtCKPOqqb7tr0Tg1b1FNzVPmnWQy38kjWs9 MPowKrjEbyqR9f8FRDTlg5HKqx9M/0eQZFGh1kURxZ3OiRBWhRJANaxZECkaTKz35qM62ZlxRs2D Eljp6FdySf/Cv38yC8AtdCmf3ep2GRe94CzPFkblnlJEFucP5nf7bjSd6Q4GZNpf7bFIfyh3sxdA icvf+lNxIVTLN7fvE/XZ91nvCWeaXxt8LcR1HauRMvY8SjCs8L05mexoI83kLaGdn2akWHHq2sg7 xZV5pNgHlJ1PerkkgTzzJNW9AoUgoqyWixvAQ+3I8olp7uaW6VKaWDNwJjqsxeBv4bu2bMwRInSe j3BG/qiEW4lmH/Q4NuQh7mZlwzgde2dfLXMuQEEQCnOmQfQwxF3TUu1ZPF9faGcPjWTbl15qGjE+ 2VpMjU41OuIN2rCKpQeH08qX1bmbTsx3CbhuXl3ph0i9bQgsup2suriR1xUHkgx7kQT/+AWM/QPN DWVuZHN0cmVhbQ1lbmRvYmoNMjMgMCBvYmoNMzMyMg1lbmRvYmoNMjEgMCBvYmoNPDwNL1R5cGUg L1BhZ2UNL1BhcmVudCA1IDAgUg0vUmVzb3VyY2VzIDw8DS9Gb250IDI0IDAgUg0vUHJvY1NldCAy IDAgUg0+Pg0vQ29udGVudHMgMjIgMCBSDT4+DWVuZG9iag0yNCAwIG9iag08PA0vRjAgNiAwIFIN L0YxIDggMCBSDS9GMiAxMCAwIFINL0YzIDEyIDAgUg0vRjQgMTYgMCBSDS9GNSAxOCAwIFINPj4N ZW5kb2JqDTI2IDAgb2JqDTw8DS9MZW5ndGggMjcgMCBSDS9GaWx0ZXIgL0ZsYXRlRGVjb2RlIA0+ Pg1zdHJlYW0NCkiJxFfLkttGEvyC+Ye+rbVBQsQb9GVDWlmxE2tLDokOX+bSAJpkWyCaxmMo/v1m VXeDIGdG0m3tg2EO0F2PrMyst5u79Urk2SoohNi8u1sJ+rfbibvX70MRroIV/b69W+Ipzem5Eqsg zFY5Hk/ip81e96Iau061g+hVp83YN2dR617Wj7Id5E63O9HrYZSDNq3Ymk7USm6FbGuxl10tzFbs lezotaMyx0aJSrbCtDilVK/E5i/EtAzDII0oQEGBxFniAllFcWgD6fWu1VuNbwd8qQ/HzjyqWuit 0O2gOlkN+lEtRIU78ay6ZXleTv8jBvV1EJU5HMYWR1CkPYdRKlF2ZtztB45k80++P0mm+7Misffj FiMOUrf90Cl5wInVvjWN2Z0DsdmrTgkUqjUnIUXVIF9hjkfTDbhvOAt8Whtx7FSle4Xwh70cFqI8 48AvXL+xU/MA0jj1nUjC1AawHQe8Je5/F6XskXmrhpPpvvRC4tdaUX3w60kPexyPWHQrDrqtA/FW VXLsFX5VAv/thPp6RCNVW3ErWjP4RvjbV7G/PYwLV37TUOC12mq6BofTcSgt7pCNkI1pUf0W3efO ur+7GBdCD1QedA2dokZxBURpONjpvRkaomJCQxr6aDwWCFvz620NSkWlnCqh26oZe9zV+A4Bm4hR tmeBRgALqq0voP2Mwg6qUce9ac/PwzJdTZGERWZDqdWjrlQvfvvj80YM8ostc6f+HnWncMPQ0wDQ RCyejAOl0R8VgESVkfig5gZR7wYz70icuo64/KvKjO0Q+DCjhGN8/X4lEPEqmSY6T3Mf8Tp1E/0n VR5oPCkA0hwNkCF7jho9Hqke/3qa/uv30Q1ZZKv11JbCQfQec93VNG5GyLruVG8Pxj1low697fqP F8PxxVYCqZ3GkNKALa6gmmZTFKtsjg666EJS3JYDZrMEEg/AgVCPqgOeJWMVTHDfAgUHi4fPptIK Y3viuaYMZKkbO8hXt6+nGqz5EbdfSAYFBVE0KAIGgucScEdxXFZ7VL0kHGIKu7HSsllQTwjJjTFM C4TLHi9gntvd/OIsny7OE5c2GI4Qh7saKtVJccEeMLm2GkjcMR7q2zA2UWL8oWoIA2hZa0CR/fDw CoHsNTUCg8UgQdQYD4+P58c0ySesgbVtTA8/IUkiQiIs3EDJgPP6v0fwQI3fGrWT1Vn0w7jdPrxi EJjtlkbgBSKfkb3gOOI8DPKMJ8PGEcXRfFaI+X31lu7l27leT5EnazclwBx1XKueyQMK1+7QtAPq Q/UDswNXwpR/KRsLdRMJllzIA6TpuzB/nmOSyCvPKnLC85QabOb5Oohc3jz511qeWgljtHiI/Pbm /sPnzadf3vzmTohnJ9wOeBL70VoVceaLORc9yaRO48Gcf5IsdCXnyeOGUTpCCZ0mWY1ZhmkUJE9a kE/UmkWO5UEfA5WOLoA6NDXNY8s4Boy43ETY16oeiI8tCyzePOmmoaczDXsLh9LgL6r9y5wt3cnD C/4jWU/yG61TP16TaJK4QXmY2eWj1I1jh4VFJ42L5wtut+pIIzyweRhvHFFtLlweWwK3kWQezEGY xg4Qb1n+DStsf601zCClarTyErsBplcCeOQJBkhnCv7p/b+jfB1fAqNv++EHxM8NCea612D2iRkC cc+Y6JliFkLJ/rwczHJiHPz0LE1RnWxXEbNseMwcHeGXK84tJnMSudagrwuEQMg4mfYfA7kqxToP b4PKSwqx1pQl98+WDgyjjyAgGAR7KQ5Rmhl63uApdDlRnyfhi03yLslcf0vhB+JPYodHqi0wWUka Z1hZOyPWRgK8jXen1i2yk+gHdexZBMpRNzV9oq8iSEMvA6t16PTHN7Uf2X+yumEMLu6RDI7qf566 HAWTfUhuKCDPijmVPkRZzp8lQZpNvJHOPlr5cPLcVcQSTRgHsNQvMk0xsxIujbkbE1cmyyfmE6X6 wJE3y0EfFBt9xzMFJff/zSyNkymzdfiNzD7/5+Mfv76bcpOCRN+wZur2ONoBgZ85NkSytMwMe95b GOb25Z+fH9wsnga38Aaa8DQsAQ1/JB3/RZ2PEsTS0VNpIFyYKshcTRJ2YgkyHT+Qp7Fcx9aMd77L Qa9Ndz2wE4XlhaOwywX41Gei4ZVPqrwcfOkjSNE5jadb62VVSh0ffFK7sZGDAac1+ovzCVlKR1xs wsy/JpmTt49bDCG7JJsLFUJ02HxoimY6Y2cX3Aslr2gpxQKjaqtIe3q5HrElQg9kb3Owlz+xHdEF HK4wJ4VZJSvh9kJmAF48iQ9ogmmYpym2EnczEd9fCy5WLYpyx+VkcnTfj6RTky2zB//IOpAmxUTL YeI3DY3SzR2k3Vy9WjxxD7iZ3YPd435wS3jBjU6TBwC6eJzYzl2JPxct04+6HmmXdLsrNtodrTIg 8wX9gNpztUtKaSa6dkbxWmXaFm7wBUvhK75aex1XX3XPWPr98+aDLznN9tRba5uAs1adAAHdAlVY KWb9r8duUpJOtr22+2xnDvMRTNYTDa0iR198KULHWa0a4K++eKfruzM4g1caGwfew1IDQabjaWWS HSQUAgZlgX4djW7Zrz1qdSLoCwLzFRMkF59dOCZyqycLPqu9gkyzpV4wPAzZXst4lm/TNRA2EW58 u5V6K29P3yFgAMtOYZwF+ct2N04mwCQTxZeoDKk2hcgFI/w9qZjUB9HvzdjUjrHWaVA8tbirCQJ5 4fYjuy5w52j7dMw+qYNtt/P8reRFg+UDb/m/yYGj45ujIqcbXyoOhn1enNJ0NXyfrU34jU0gyy+W K3eRe2PuKoFmBSpwS1ZYUKFv048vhziu45m6gS6Ofa7QbIh6ouVKza3yi6qQ5H57CfGP5yO0sla9 s19ygvqCrCPQdlnsUG+H53Gwg8BENa17ePnDxw2/prqjwm4xWIQ8P/1xMYEr8lTfD+dG3XTc4onc OtE81eBm4dwZTJqdC14ymXikjck2MkqDzOscbZFJ7PfAMEpiv8Z9ZeKh5MjiDk6m3MdPtqGJulIX O2SQdQ5hzHbKb26H8ggZkNXeVpOZdLaVWRvud8QnbJ7Gk1jnsXOIJNGUxFYrrIbsQb4jGUsvGW7t sjOTJ4Sb57DvoDoNjAXeL5u7oiCbGIW0yCZAO31PkAect3dvN3drCO7a+2o7ek4el/Mqbvzc4ojo YiJXt9KaTVDOvVP5ZM4AwgfeSfBwD2XQwzhYL/YOdRC/X1IM8zCIs5fGO4ov54f+fPHwE3+aBnn2 YmB5kc3L8+nD/Ttb0vSbnjj3tmdV5K4SD688VhrZ7UhjKrSRdqFOHTsoYOtNl1iLA7DjV7FlFK2C p4jN4umKzGGewMFYuMWHcwVO9f/4byDe9GzADyXYkXZEF8sCgsZcD9QDyBqQJScga1rfmvPzk59m F5tZZJ71B0yt+BvQpxTJb+mtmiD8jSh5mazJZZIun6+2SfqqMWVJQ3GlulF0aa8Ttke9MzDdfYOk cEwndc9HnGSnWjL3uJlC4WcOx4XRmL7nTzDM8EvsUVVndxh6z3n5+f2w1xP0k9RZsd5UWjYLVJmr Z7/930DFB5gHinFQ4wKe4QBRxfGbDWVuZHN0cmVhbQ1lbmRvYmoNMjcgMCBvYmoNMjY5MA1lbmRv YmoNMjUgMCBvYmoNPDwNL1R5cGUgL1BhZ2UNL1BhcmVudCA1IDAgUg0vUmVzb3VyY2VzIDw8DS9G b250IDI4IDAgUg0vUHJvY1NldCAyIDAgUg0+Pg0vQ29udGVudHMgMjYgMCBSDT4+DWVuZG9iag0y OCAwIG9iag08PA0vRjAgNiAwIFINL0YxIDggMCBSDS9GMiAxMCAwIFINL0YzIDEyIDAgUg0vRjQg MTYgMCBSDS9GNSAxOCAwIFINPj4NZW5kb2JqDTYgMCBvYmoNPDwNL1R5cGUgL0ZvbnQNL1N1YnR5 cGUgL1RydWVUeXBlDS9OYW1lIC9GMA0vQmFzZUZvbnQgL1RpbWVzTmV3Um9tYW4sQm9sZA0vRmly c3RDaGFyIDMyDS9MYXN0Q2hhciAyNTUNL1dpZHRocyBbIDI1MCAzMzMgNTU1IDUwMCA1MDAgMTAw MCA4MzMgMjc4IDMzMyAzMzMgNTAwIDU3MCAyNTAgMzMzIDI1MCAyNzggDTUwMCA1MDAgNTAwIDUw MCA1MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCAzMzMgMzMzIDU3MCA1NzAgNTcwIDUwMCANOTMwIDcy MiA2NjcgNzIyIDcyMiA2NjcgNjExIDc3OCA3NzggMzg5IDUwMCA3NzggNjY3IDk0NCA3MjIgNzc4 IA02MTEgNzc4IDcyMiA1NTYgNjY3IDcyMiA3MjIgMTAwMCA3MjIgNzIyIDY2NyAzMzMgMjc4IDMz MyA1ODEgNTAwIA0zMzMgNTAwIDU1NiA0NDQgNTU2IDQ0NCAzMzMgNTAwIDU1NiAyNzggMzMzIDU1 NiAyNzggODMzIDU1NiA1MDAgDTU1NiA1NTYgNDQ0IDM4OSAzMzMgNTU2IDUwMCA3MjIgNTAwIDUw MCA0NDQgMzk0IDIyMCAzOTQgNTIwIDc3OCANNTAwIDc3OCAzMzMgNTAwIDUwMCAxMDAwIDUwMCA1 MDAgMzMzIDEwMDAgNTU2IDMzMyAxMDAwIDc3OCA2NjcgNzc4IA03NzggMzMzIDMzMyA1MDAgNTAw IDM1MCA1MDAgMTAwMCAzMzMgMTAwMCAzODkgMzMzIDcyMiA3NzggNDQ0IDcyMiANMjUwIDMzMyA1 MDAgNTAwIDUwMCA1MDAgMjIwIDUwMCAzMzMgNzQ3IDMwMCA1MDAgNTcwIDMzMyA3NDcgNTAwIA00 MDAgNTQ5IDMwMCAzMDAgMzMzIDU3NiA1NDAgMjUwIDMzMyAzMDAgMzMwIDUwMCA3NTAgNzUwIDc1 MCA1MDAgDTcyMiA3MjIgNzIyIDcyMiA3MjIgNzIyIDEwMDAgNzIyIDY2NyA2NjcgNjY3IDY2NyAz ODkgMzg5IDM4OSAzODkgDTcyMiA3MjIgNzc4IDc3OCA3NzggNzc4IDc3OCA1NzAgNzc4IDcyMiA3 MjIgNzIyIDcyMiA3MjIgNjExIDU1NiANNTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAgNzIyIDQ0NCA0 NDQgNDQ0IDQ0NCA0NDQgMjc4IDI3OCAyNzggMjc4IA01MDAgNTU2IDUwMCA1MDAgNTAwIDUwMCA1 MDAgNTQ5IDUwMCA1NTYgNTU2IDU1NiA1NTYgNTAwIDU1NiA1MDAgDV0NL0VuY29kaW5nIC9XaW5B bnNpRW5jb2RpbmcNL0ZvbnREZXNjcmlwdG9yIDcgMCBSDT4+DWVuZG9iag03IDAgb2JqDTw8DS9U eXBlIC9Gb250RGVzY3JpcHRvcg0vRm9udE5hbWUgL1RpbWVzTmV3Um9tYW4sQm9sZA0vRmxhZ3Mg MTY0MTgNL0ZvbnRCQm94IFsgLTI1MCAtMjE2IDExNjggMTAwMCBdDS9NaXNzaW5nV2lkdGggMzI0 DS9TdGVtViAxMzYNL1N0ZW1IIDEzNg0vSXRhbGljQW5nbGUgMA0vQ2FwSGVpZ2h0IDg5MQ0vWEhl aWdodCA0NDYNL0FzY2VudCA4OTENL0Rlc2NlbnQgLTIxNg0vTGVhZGluZyAxNDkNL01heFdpZHRo IDk3Mw0vQXZnV2lkdGggNDI3DT4+DWVuZG9iag04IDAgb2JqDTw8DS9UeXBlIC9Gb250DS9TdWJ0 eXBlIC9UcnVlVHlwZQ0vTmFtZSAvRjENL0Jhc2VGb250IC9UaW1lc05ld1JvbWFuLEJvbGRJdGFs aWMNL0ZpcnN0Q2hhciAzMg0vTGFzdENoYXIgMjU1DS9XaWR0aHMgWyAyNTAgMzg5IDU1NSA1MDAg NTAwIDgzMyA3NzggMjc4IDMzMyAzMzMgNTAwIDU3MCAyNTAgMzMzIDI1MCAyNzggDTUwMCA1MDAg NTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCAzMzMgMzMzIDU3MCA1NzAgNTcwIDUwMCAN ODMyIDY2NyA2NjcgNjY3IDcyMiA2NjcgNjY3IDcyMiA3NzggMzg5IDUwMCA2NjcgNjExIDg4OSA3 MjIgNzIyIA02MTEgNzIyIDY2NyA1NTYgNjExIDcyMiA2NjcgODg5IDY2NyA2MTEgNjExIDMzMyAy NzggMzMzIDU3MCA1MDAgDTMzMyA1MDAgNTAwIDQ0NCA1MDAgNDQ0IDMzMyA1MDAgNTU2IDI3OCAy NzggNTAwIDI3OCA3NzggNTU2IDUwMCANNTAwIDUwMCAzODkgMzg5IDI3OCA1NTYgNDQ0IDY2NyA1 MDAgNDQ0IDM4OSAzNDggMjIwIDM0OCA1NzAgNzc4IA01MDAgNzc4IDMzMyA1MDAgNTAwIDEwMDAg NTAwIDUwMCAzMzMgMTAwMCA1NTYgMzMzIDk0NCA3NzggNjExIDc3OCANNzc4IDMzMyAzMzMgNTAw IDUwMCAzNTAgNTAwIDEwMDAgMzMzIDEwMDAgMzg5IDMzMyA3MjIgNzc4IDM4OSA2MTEgDTI1MCAz ODkgNTAwIDUwMCA1MDAgNTAwIDIyMCA1MDAgMzMzIDc0NyAyNjYgNTAwIDYwNiAzMzMgNzQ3IDUw MCANNDAwIDU0OSAzMDAgMzAwIDMzMyA1NzYgNTAwIDI1MCAzMzMgMzAwIDMwMCA1MDAgNzUwIDc1 MCA3NTAgNTAwIA02NjcgNjY3IDY2NyA2NjcgNjY3IDY2NyA5NDQgNjY3IDY2NyA2NjcgNjY3IDY2 NyAzODkgMzg5IDM4OSAzODkgDTcyMiA3MjIgNzIyIDcyMiA3MjIgNzIyIDcyMiA1NzAgNzIyIDcy MiA3MjIgNzIyIDcyMiA2MTEgNjExIDUwMCANNTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAgNzIyIDQ0 NCA0NDQgNDQ0IDQ0NCA0NDQgMjc4IDI3OCAyNzggMjc4IA01MDAgNTU2IDUwMCA1MDAgNTAwIDUw MCA1MDAgNTQ5IDUwMCA1NTYgNTU2IDU1NiA1NTYgNDQ0IDUwMCA0NDQgDV0NL0VuY29kaW5nIC9X aW5BbnNpRW5jb2RpbmcNL0ZvbnREZXNjcmlwdG9yIDkgMCBSDT4+DWVuZG9iag05IDAgb2JqDTw8 DS9UeXBlIC9Gb250RGVzY3JpcHRvcg0vRm9udE5hbWUgL1RpbWVzTmV3Um9tYW4sQm9sZEl0YWxp Yw0vRmxhZ3MgMTY0ODINL0ZvbnRCQm94IFsgLTI1MCAtMjE2IDExNTAgMTAwMCBdDS9NaXNzaW5n V2lkdGggMzE5DS9TdGVtViAxMzENL1N0ZW1IIDEzMQ0vSXRhbGljQW5nbGUgLTExDS9DYXBIZWln aHQgODkxDS9YSGVpZ2h0IDQ0Ng0vQXNjZW50IDg5MQ0vRGVzY2VudCAtMjE2DS9MZWFkaW5nIDE0 OQ0vTWF4V2lkdGggOTU4DS9BdmdXaWR0aCA0MTINPj4NZW5kb2JqDTEwIDAgb2JqDTw8DS9UeXBl IC9Gb250DS9TdWJ0eXBlIC9UcnVlVHlwZQ0vTmFtZSAvRjINL0Jhc2VGb250IC9UaW1lc05ld1Jv bWFuDS9GaXJzdENoYXIgMzINL0xhc3RDaGFyIDI1NQ0vV2lkdGhzIFsgMjUwIDMzMyA0MDggNTAw IDUwMCA4MzMgNzc4IDE4MCAzMzMgMzMzIDUwMCA1NjQgMjUwIDMzMyAyNTAgMjc4IA01MDAgNTAw IDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAgMjc4IDI3OCA1NjQgNTY0IDU2NCA0NDQg DTkyMSA3MjIgNjY3IDY2NyA3MjIgNjExIDU1NiA3MjIgNzIyIDMzMyAzODkgNzIyIDYxMSA4ODkg NzIyIDcyMiANNTU2IDcyMiA2NjcgNTU2IDYxMSA3MjIgNzIyIDk0NCA3MjIgNzIyIDYxMSAzMzMg Mjc4IDMzMyA0NjkgNTAwIA0zMzMgNDQ0IDUwMCA0NDQgNTAwIDQ0NCAzMzMgNTAwIDUwMCAyNzgg Mjc4IDUwMCAyNzggNzc4IDUwMCA1MDAgDTUwMCA1MDAgMzMzIDM4OSAyNzggNTAwIDUwMCA3MjIg NTAwIDUwMCA0NDQgNDgwIDIwMCA0ODAgNTQxIDc3OCANNTAwIDc3OCAzMzMgNTAwIDQ0NCAxMDAw IDUwMCA1MDAgMzMzIDEwMDAgNTU2IDMzMyA4ODkgNzc4IDYxMSA3NzggDTc3OCAzMzMgMzMzIDQ0 NCA0NDQgMzUwIDUwMCAxMDAwIDMzMyA5ODAgMzg5IDMzMyA3MjIgNzc4IDQ0NCA3MjIgDTI1MCAz MzMgNTAwIDUwMCA1MDAgNTAwIDIwMCA1MDAgMzMzIDc2MCAyNzYgNTAwIDU2NCAzMzMgNzYwIDUw MCANNDAwIDU0OSAzMDAgMzAwIDMzMyA1NzYgNDUzIDI1MCAzMzMgMzAwIDMxMCA1MDAgNzUwIDc1 MCA3NTAgNDQ0IA03MjIgNzIyIDcyMiA3MjIgNzIyIDcyMiA4ODkgNjY3IDYxMSA2MTEgNjExIDYx MSAzMzMgMzMzIDMzMyAzMzMgDTcyMiA3MjIgNzIyIDcyMiA3MjIgNzIyIDcyMiA1NjQgNzIyIDcy MiA3MjIgNzIyIDcyMiA3MjIgNTU2IDUwMCANNDQ0IDQ0NCA0NDQgNDQ0IDQ0NCA0NDQgNjY3IDQ0 NCA0NDQgNDQ0IDQ0NCA0NDQgMjc4IDI3OCAyNzggMjc4IA01MDAgNTAwIDUwMCA1MDAgNTAwIDUw MCA1MDAgNTQ5IDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAgDV0NL0VuY29kaW5nIC9X aW5BbnNpRW5jb2RpbmcNL0ZvbnREZXNjcmlwdG9yIDExIDAgUg0+Pg1lbmRvYmoNMTEgMCBvYmoN PDwNL1R5cGUgL0ZvbnREZXNjcmlwdG9yDS9Gb250TmFtZSAvVGltZXNOZXdSb21hbg0vRmxhZ3Mg MzQNL0ZvbnRCQm94IFsgLTI1MCAtMjE2IDExNTIgMTAwMCBdDS9NaXNzaW5nV2lkdGggMzIwDS9T dGVtViA3Mw0vU3RlbUggNzMNL0l0YWxpY0FuZ2xlIDANL0NhcEhlaWdodCA4OTENL1hIZWlnaHQg NDQ2DS9Bc2NlbnQgODkxDS9EZXNjZW50IC0yMTYNL0xlYWRpbmcgMTQ5DS9NYXhXaWR0aCA5NjAN L0F2Z1dpZHRoIDQwMQ0+Pg1lbmRvYmoNMTIgMCBvYmoNPDwNL1R5cGUgL0ZvbnQNL1N1YnR5cGUg L1RydWVUeXBlDS9OYW1lIC9GMw0vQmFzZUZvbnQgL1RpbWVzTmV3Um9tYW4sSXRhbGljDS9GaXJz dENoYXIgMzINL0xhc3RDaGFyIDI1NQ0vV2lkdGhzIFsgMjUwIDMzMyA0MjAgNTAwIDUwMCA4MzMg Nzc4IDIxNCAzMzMgMzMzIDUwMCA2NzUgMjUwIDMzMyAyNTAgMjc4IA01MDAgNTAwIDUwMCA1MDAg NTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAgMzMzIDMzMyA2NzUgNjc1IDY3NSA1MDAgDTkyMCA2MTEg NjExIDY2NyA3MjIgNjExIDYxMSA3MjIgNzIyIDMzMyA0NDQgNjY3IDU1NiA4MzMgNjY3IDcyMiAN NjExIDcyMiA2MTEgNTAwIDU1NiA3MjIgNjExIDgzMyA2MTEgNTU2IDU1NiAzODkgMjc4IDM4OSA0 MjIgNTAwIA0zMzMgNTAwIDUwMCA0NDQgNTAwIDQ0NCAyNzggNTAwIDUwMCAyNzggMjc4IDQ0NCAy NzggNzIyIDUwMCA1MDAgDTUwMCA1MDAgMzg5IDM4OSAyNzggNTAwIDQ0NCA2NjcgNDQ0IDQ0NCAz ODkgNDAwIDI3NSA0MDAgNTQxIDc3OCANNTAwIDc3OCAzMzMgNTAwIDU1NiA4ODkgNTAwIDUwMCAz MzMgMTAwMCA1MDAgMzMzIDk0NCA3NzggNTU2IDc3OCANNzc4IDMzMyAzMzMgNTU2IDU1NiAzNTAg NTAwIDg4OSAzMzMgOTgwIDM4OSAzMzMgNjY3IDc3OCAzODkgNTU2IA0yNTAgMzg5IDUwMCA1MDAg NTAwIDUwMCAyNzUgNTAwIDMzMyA3NjAgMjc2IDUwMCA2NzUgMzMzIDc2MCA1MDAgDTQwMCA1NDkg MzAwIDMwMCAzMzMgNTc2IDUyMyAyNTAgMzMzIDMwMCAzMTAgNTAwIDc1MCA3NTAgNzUwIDUwMCAN NjExIDYxMSA2MTEgNjExIDYxMSA2MTEgODg5IDY2NyA2MTEgNjExIDYxMSA2MTEgMzMzIDMzMyAz MzMgMzMzIA03MjIgNjY3IDcyMiA3MjIgNzIyIDcyMiA3MjIgNjc1IDcyMiA3MjIgNzIyIDcyMiA3 MjIgNTU2IDYxMSA1MDAgDTUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDY2NyA0NDQgNDQ0IDQ0NCA0 NDQgNDQ0IDI3OCAyNzggMjc4IDI3OCANNTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDU0OSA1 MDAgNTAwIDUwMCA1MDAgNTAwIDQ0NCA1MDAgNDQ0IA1dDS9FbmNvZGluZyAvV2luQW5zaUVuY29k aW5nDS9Gb250RGVzY3JpcHRvciAxMyAwIFINPj4NZW5kb2JqDTEzIDAgb2JqDTw8DS9UeXBlIC9G b250RGVzY3JpcHRvcg0vRm9udE5hbWUgL1RpbWVzTmV3Um9tYW4sSXRhbGljDS9GbGFncyA5OA0v Rm9udEJCb3ggWyAtMjUwIC0yMTYgMTE1MiAxMDAwIF0NL01pc3NpbmdXaWR0aCAzNzQNL1N0ZW1W IDczDS9TdGVtSCA3Mw0vSXRhbGljQW5nbGUgLTExDS9DYXBIZWlnaHQgODkxDS9YSGVpZ2h0IDQ0 Ng0vQXNjZW50IDg5MQ0vRGVzY2VudCAtMjE2DS9MZWFkaW5nIDE0OQ0vTWF4V2lkdGggOTYwDS9B dmdXaWR0aCA0MDINPj4NZW5kb2JqDTE2IDAgb2JqDTw8DS9UeXBlIC9Gb250DS9TdWJ0eXBlIC9U cnVlVHlwZQ0vTmFtZSAvRjQNL0Jhc2VGb250IC9TeW1ib2wNL0ZpcnN0Q2hhciAzMA0vTGFzdENo YXIgMjU1DS9XaWR0aHMgWyA2MDAgNjAwIDI1MCAzMzMgNzEzIDUwMCA1NDkgODMzIDc3OCA0Mzkg MzMzIDMzMyA1MDAgNTQ5IDI1MCA1NDkgDTI1MCAyNzggNTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAg NTAwIDUwMCA1MDAgNTAwIDI3OCAyNzggNTQ5IDU0OSANNTQ5IDQ0NCA1NDkgNzIyIDY2NyA3MjIg NjEyIDYxMSA3NjMgNjAzIDcyMiAzMzMgNjMxIDcyMiA2ODYgODg5IA03MjIgNzIyIDc2OCA3NDEg NTU2IDU5MiA2MTEgNjkwIDQzOSA3NjggNjQ1IDc5NSA2MTEgMzMzIDg2MyAzMzMgDTY1OCA1MDAg NTAwIDYzMSA1NDkgNTQ5IDQ5NCA0MzkgNTIxIDQxMSA2MDMgMzI5IDYwMyA1NDkgNTQ5IDU3NiAN NTIxIDU0OSA1NDkgNTIxIDU0OSA2MDMgNDM5IDU3NiA3MTMgNjg2IDQ5MyA2ODYgNDk0IDQ4MCAy MDAgNDgwIA01NDkgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2 MDAgNjAwIDYwMCA2MDAgDTYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2 MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCANNjAwIDYwMCA2MDAgNjIwIDI0NyA1NDkgMTY3IDcxMyA1 MDAgNzUzIDc1MyA3NTMgNzUzIDEwNDIgOTg3IDYwMyANOTg3IDYwMyA0MDAgNTQ5IDQxMSA1NDkg NTQ5IDcxMyA0OTQgNDYwIDU0OSA1NDkgNTQ5IDU0OSAxMDAwIDYwMyANMTAwMCA2NTggODIzIDY4 NiA3OTUgOTg3IDc2OCA3NjggODIzIDc2OCA3NjggNzEzIDcxMyA3MTMgNzEzIDcxMyANNzEzIDcx MyA3NjggNzEzIDc5MCA3OTAgODkwIDgyMyA1NDkgMjUwIDcxMyA2MDMgNjAzIDEwNDIgOTg3IDYw MyANOTg3IDYwMyA0OTQgMzI5IDc5MCA3OTAgNzg2IDcxMyAzODQgMzg0IDM4NCAzODQgMzg0IDM4 NCA0OTQgNDk0IA00OTQgNDk0IDYwMCAzMjkgMjc0IDY4NiA2ODYgNjg2IDM4NCAzODQgMzg0IDM4 NCAzODQgMzg0IDQ5NCA0OTQgDTQ5NCA2MDAgXQ0vRm9udERlc2NyaXB0b3IgMTcgMCBSDT4+DWVu ZG9iag0xNyAwIG9iag08PA0vVHlwZSAvRm9udERlc2NyaXB0b3INL0ZvbnROYW1lIC9TeW1ib2wN L0ZsYWdzIDYNL0ZvbnRCQm94IFsgLTI1MCAtMjIwIDEyNDEgMTAwNSBdDS9NaXNzaW5nV2lkdGgg MzMxDS9TdGVtViAxMDkNL1N0ZW1IIDEwOQ0vSXRhbGljQW5nbGUgMA0vQ2FwSGVpZ2h0IDEwMDUN L1hIZWlnaHQgNTAzDS9Bc2NlbnQgMTAwNQ0vRGVzY2VudCAtMjIwDS9MZWFkaW5nIDIyNQ0vTWF4 V2lkdGggMTAzNA0vQXZnV2lkdGggNjAwDT4+DWVuZG9iag0xOCAwIG9iag08PA0vVHlwZSAvRm9u dA0vU3VidHlwZSAvVHJ1ZVR5cGUNL05hbWUgL0Y1DS9CYXNlRm9udCAvQXJpYWwNL0ZpcnN0Q2hh ciAzMg0vTGFzdENoYXIgMjU1DS9XaWR0aHMgWyAyNzggMjc4IDM1NSA1NTYgNTU2IDg4OSA2Njcg MTkxIDMzMyAzMzMgMzg5IDU4NCAyNzggMzMzIDI3OCAyNzggDTU1NiA1NTYgNTU2IDU1NiA1NTYg NTU2IDU1NiA1NTYgNTU2IDU1NiAyNzggMjc4IDU4NCA1ODQgNTg0IDU1NiANMTAxNSA2NjcgNjY3 IDcyMiA3MjIgNjY3IDYxMSA3NzggNzIyIDI3OCA1MDAgNjY3IDU1NiA4MzMgNzIyIDc3OCANNjY3 IDc3OCA3MjIgNjY3IDYxMSA3MjIgNjY3IDk0NCA2NjcgNjY3IDYxMSAyNzggMjc4IDI3OCA0Njkg NTU2IA0zMzMgNTU2IDU1NiA1MDAgNTU2IDU1NiAyNzggNTU2IDU1NiAyMjIgMjIyIDUwMCAyMjIg ODMzIDU1NiA1NTYgDTU1NiA1NTYgMzMzIDUwMCAyNzggNTU2IDUwMCA3MjIgNTAwIDUwMCA1MDAg MzM0IDI2MCAzMzQgNTg0IDc1MCANNTU2IDc1MCAyMjIgNTU2IDMzMyAxMDAwIDU1NiA1NTYgMzMz IDEwMDAgNjY3IDMzMyAxMDAwIDc1MCA2MTEgNzUwIA03NTAgMjIyIDIyMiAzMzMgMzMzIDM1MCA1 NTYgMTAwMCAzMzMgMTAwMCA1MDAgMzMzIDk0NCA3NTAgNTAwIDY2NyANMjc4IDMzMyA1NTYgNTU2 IDU1NiA1NTYgMjYwIDU1NiAzMzMgNzM3IDM3MCA1NTYgNTg0IDMzMyA3MzcgNTUyIA00MDAgNTQ5 IDMzMyAzMzMgMzMzIDU3NiA1MzcgMjc4IDMzMyAzMzMgMzY1IDU1NiA4MzQgODM0IDgzNCA2MTEg DTY2NyA2NjcgNjY3IDY2NyA2NjcgNjY3IDEwMDAgNzIyIDY2NyA2NjcgNjY3IDY2NyAyNzggMjc4 IDI3OCAyNzggDTcyMiA3MjIgNzc4IDc3OCA3NzggNzc4IDc3OCA1ODQgNzc4IDcyMiA3MjIgNzIy IDcyMiA2NjcgNjY3IDYxMSANNTU2IDU1NiA1NTYgNTU2IDU1NiA1NTYgODg5IDUwMCA1NTYgNTU2 IDU1NiA1NTYgMjc4IDI3OCAyNzggMjc4IA01NTYgNTU2IDU1NiA1NTYgNTU2IDU1NiA1NTYgNTQ5 IDYxMSA1NTYgNTU2IDU1NiA1NTYgNTAwIDU1NiA1MDAgDV0NL0VuY29kaW5nIC9XaW5BbnNpRW5j b2RpbmcNL0ZvbnREZXNjcmlwdG9yIDE5IDAgUg0+Pg1lbmRvYmoNMTkgMCBvYmoNPDwNL1R5cGUg L0ZvbnREZXNjcmlwdG9yDS9Gb250TmFtZSAvQXJpYWwNL0ZsYWdzIDMyDS9Gb250QkJveCBbIC0y NTAgLTIxMiAxMjA1IDEwMDAgXQ0vTWlzc2luZ1dpZHRoIDI3NQ0vU3RlbVYgODANL1N0ZW1IIDgw DS9JdGFsaWNBbmdsZSAwDS9DYXBIZWlnaHQgOTA1DS9YSGVpZ2h0IDQ1Mw0vQXNjZW50IDkwNQ0v RGVzY2VudCAtMjEyDS9MZWFkaW5nIDE1MA0vTWF4V2lkdGggMTAwNA0vQXZnV2lkdGggNDQxDT4+ DWVuZG9iag0yIDAgb2JqDVsgL1BERiAvVGV4dCAgXQ1lbmRvYmoNNSAwIG9iag08PA0vS2lkcyBb NCAwIFIgMjEgMCBSIDI1IDAgUiBdDS9Db3VudCAzDS9UeXBlIC9QYWdlcw0vTWVkaWFCb3ggWyAw IDAgNTk1IDg0MiBdDT4+DWVuZG9iag0xIDAgb2JqDTw8DS9DcmVhdG9yIDxGRUZGMDA0RDAwNjkw MDYzMDA3MjAwNkYwMDczMDA2RjAwNjYwMDc0MDAyMDAwNTcwMDZGMDA3MjAwNjQwMDIwMDAyRDAw MjAwMDU0MDA2NTAwNzgwMDc0MDAyMDAwNjMwMDZGMDA2RDAwNkQwMDc1MDA2RTAwNjkwMDYzMDA2 MTAwNzQwMDY5MDA2RjAwNkUwMDczMDAyMDAwNjYwMDZGMDA3MjAwMjAwMDY0MDA2NTAwNjEwMDY2 MDAyMDAwNjEwMDZFMDA2NDAwMjAwMDY4MDA2MTAwNzIwMDY0MDAyMDAwNkYwMDY2MDAyMDAwNjgw MDY1MDA2MTAwNzIwMDY5MDA2RTAwNjcwMDIwMDA3MDAwNjUwMDZGMDA3MDAwNkMwMDY1MDAyRTAw NjQwMDZGMDA2Mz4NL0NyZWF0aW9uRGF0ZSAoRDoyMDAzMTAwOTE1NTkwMikNL1RpdGxlIDxGRUZG MDA1NDAwNjUwMDc4MDA3NDAwMjAwMDYzMDA2RjAwNkQwMDZEMDA3NTAwNkUwMDY5MDA2MzAwNjEw MDc0MDA2OTAwNkYwMDZFMDA3MzAwMjAwMDY2MDA2RjAwNzIwMDIwMDA2NDAwNjUwMDYxMDA2NjAw MjAwMDYxMDA2RTAwNjQwMDIwMDA2ODAwNjEwMDcyMDA2NDAwMjAwMDZGMDA2NjAwMjAwMDY4MDA2 NTAwNjEwMDcyMDA2OTAwNkUwMDY3MDAyMDAwNzAwMDY1MDA2RjAwNzAwMDZDMDA2NTAwMkUwMDUw MDA0NDAwNDY+DS9BdXRob3IgPEZFRkYwMDQxMDA2NDAwNkQwMDY5MDA2RTAwNjkwMDczMDA3NDAw NzIwMDYxMDA3NDAwNkYwMDcyPg0vUHJvZHVjZXIgKEFjcm9iYXQgUERGV3JpdGVyIDQuMDUgZm9y IFdpbmRvd3MgTlQpDT4+DWVuZG9iag0zIDAgb2JqDTw8DS9QYWdlcyA1IDAgUg0vVHlwZSAvQ2F0 YWxvZw0+Pg1lbmRvYmoNeHJlZg0wIDI5DTAwMDAwMDAwMDAgNjU1MzUgZiANMDAwMDAxODMyMCAw MDAwMCBuIA0wMDAwMDE4MTkxIDAwMDAwIG4gDTAwMDAwMTkwNjEgMDAwMDAgbiANMDAwMDAwMzI2 MyAwMDAwMCBuIA0wMDAwMDE4MjIyIDAwMDAwIG4gDTAwMDAwMTAwNjAgMDAwMDAgbiANMDAwMDAx MTE1OSAwMDAwMCBuIA0wMDAwMDExNDI5IDAwMDAwIG4gDTAwMDAwMTI1MzAgMDAwMDAgbiANMDAw MDAxMjgwOCAwMDAwMCBuIA0wMDAwMDEzODk5IDAwMDAwIG4gDTAwMDAwMTQxNjAgMDAwMDAgbiAN MDAwMDAxNTI1NiAwMDAwMCBuIA0wMDAwMDAwMDE5IDAwMDAwIG4gDTAwMDAwMDMyNDIgMDAwMDAg biANMDAwMDAxNTUyNiAwMDAwMCBuIA0wMDAwMDE2NTkyIDAwMDAwIG4gDTAwMDAwMTY4NTAgMDAw MDAgbiANMDAwMDAxNzkzNyAwMDAwMCBuIA0wMDAwMDAzMzcyIDAwMDAwIG4gDTAwMDAwMDY4Nzkg MDAwMDAgbiANMDAwMDAwMzQ1OCAwMDAwMCBuIA0wMDAwMDA2ODU4IDAwMDAwIG4gDTAwMDAwMDY5 ODkgMDAwMDAgbiANMDAwMDAwOTg2NCAwMDAwMCBuIA0wMDAwMDA3MDc1IDAwMDAwIG4gDTAwMDAw MDk4NDMgMDAwMDAgbiANMDAwMDAwOTk3NCAwMDAwMCBuIA10cmFpbGVyDTw8DS9TaXplIDI5DS9S b290IDMgMCBSDS9JbmZvIDEgMCBSDS9JRCBbPDI1NDllYThkMWRmZjExNDg3OThjMmU0NDQ4ZDcx MTBlPjwyNTQ5ZWE4ZDFkZmYxMTQ4Nzk4YzJlNDQ0OGQ3MTEwZT5dDT4+DXN0YXJ0eHJlZg0xOTEx MA0lJUVPRg0= --=_FEDF699F.11705B30 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --=_FEDF699F.11705B30-- From simple-bounces@ietf.org Thu Jul 1 11:14: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 LAA08708 for ; Thu, 1 Jul 2004 11:14: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 1Bg3Gc-0003BV-BJ for simple-archive@ietf.org; Thu, 01 Jul 2004 11:14:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bg3DQ-00028L-00 for simple-archive@ietf.org; Thu, 01 Jul 2004 11:11:10 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Bg3Bx-0001dw-00; Thu, 01 Jul 2004 11:09:37 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Bg29C-0007MU-Df; Thu, 01 Jul 2004 10:02:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bg2BJ-0006dY-4K; Thu, 01 Jul 2004 10:04:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bfzlv-0004Vu-P7 for simple@megatron.ietf.org; Thu, 01 Jul 2004 07: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 HAA16010 for ; Thu, 1 Jul 2004 07: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 1Bfzlv-00029T-6v for simple@ietf.org; Thu, 01 Jul 2004 07:30:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bfzkv-0001j0-00 for simple@ietf.org; Thu, 01 Jul 2004 07:29:31 -0400 Received: from smtp.eweka.nl ([81.171.101.3]) by ietf-mx with esmtp (Exim 4.12) id 1Bfzk6-0001Jv-00 for simple@ietf.org; Thu, 01 Jul 2004 07:28:38 -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 i61BSDb0004248; Thu, 1 Jul 2004 13:28:18 +0200 (CEST) (envelope-from a.vwijk@viataal.nl) Message-Id: <200407011128.i61BSDb0004248@smtp.eweka.nl> From: "Arnoud van Wijk" To: "'Gunnar Hellstrom'" , , , Subject: RE: [Simple] Using MSRP for real time text conversation Date: Thu, 1 Jul 2004 13:28:10 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Thread-Index: AcRe6d4cVxC6bY2nSreqGrJPWo2negAdC6Nw 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.8 required=5.0 tests=AWL,MAILTO_TO_SPAM_ADDR, MISSING_OUTLOOK_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable I prefer to stay with the 300 ms buffer and not the 500 ms. Right now I have splendid results with text/t140 using 300 ms. More becomes too much staggered..too slow..sirupy like. Greetz Arnoud And yes. I am using text/t140 every day now. And I cannot live without = it. And that while I only can communicate with right now 2 people. But it is increasing. :-) -----Original Message----- From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf = Of Gunnar Hellstrom Sent: woensdag 30 juni 2004 22:51 To: hisham.khartabil@nokia.com; dean.willis@softarmor.com; bcampbell@dynamicsoft.com Cc: stf267@etsi.org; adam@dynamicsoft.com; toip@snowshore.com; simple@ietf.org Subject: RE: [Simple] Using MSRP for real time text conversation 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 discussed 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 = 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 = 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" 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 = has been out of question so far. We know by experience that we have a fully functional = RTP specification that easily flows with its companion media, and presents with = satisfactory reliability. But Cullen=B4s challenge was too tempting, so we did the feasability = study, 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 = text 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 = quality. At 500 ms, I still thought it was well usable even if a bit gluish, while he = definitely did not like the non-direct feeling, but could of course converse through it without = real 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 pseudo-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 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 > >> >> 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 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jul 1 11: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 LAA08771 for ; Thu, 1 Jul 2004 11:14: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 1Bg3H1-0003Dq-Os for simple-archive@ietf.org; Thu, 01 Jul 2004 11:14:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bg3Dn-0002EH-00 for simple-archive@ietf.org; Thu, 01 Jul 2004 11:11:31 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bg3C5-0001as-00; Thu, 01 Jul 2004 11:09:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bg2Do-0008ML-Sa; Thu, 01 Jul 2004 10:07:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bf4Fh-0004MN-Bm for simple@megatron.ietf.org; Mon, 28 Jun 2004 18:05: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 SAA13966 for ; Mon, 28 Jun 2004 18: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 1Bf4Ff-0004yI-UY for simple@ietf.org; Mon, 28 Jun 2004 18:05:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bf47N-0003DC-00 for simple@ietf.org; Mon, 28 Jun 2004 17:56:50 -0400 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 1Bf3wi-0000uD-00 for simple@ietf.org; Mon, 28 Jun 2004 17:45:48 -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 i5SLhjbq003692; Mon, 28 Jun 2004 16:43:45 -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 KZRBQJ2Y; Mon, 28 Jun 2004 16:43:44 -0500 Message-ID: <40E0910E.2030306@dynamicsoft.com> Date: Mon, 28 Jun 2004 16:43:42 -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] RE: [Sipping] RE: text/T140 and audio/t140 was:[avt]Comments/questions on draft-ietf-av References: <200406242315.i5ONFkgd020933@berlin.arid.us> <40DC36EE.3080206@cisco.com> In-Reply-To: <40DC36EE.3080206@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 01 Jul 2004 10:07:20 -0400 Cc: fluffy@cisco.com, "Paul E. Jones" , toip@snowshore.com, simple@ietf.org, gv@trace.wisc.edu, "'Guido Gybels'" , 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 Kyzivat wrote: > 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. Perhaps nobody except for me. > Most people seem to think that network administrators won't want to > let IM thru the firewall without logging it. I certainly have higher hopes for MSRP than use exclusively in enterprise applications. I don't think that it's unrealistic to believe that, at some point in the future, ISPs will include SIP registrars as readily as they currently do SMTP MTAs. If that happens, I can't imagine that residential users of MSRP clients will do anything *but* point-to-point. /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jul 1 11:15: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 LAA08828 for ; Thu, 1 Jul 2004 11:15: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 1Bg3Hh-0003M9-Ic for simple-archive@ietf.org; Thu, 01 Jul 2004 11:15:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bg3E0-0002HT-00 for simple-archive@ietf.org; Thu, 01 Jul 2004 11:11:45 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Bg3C8-0001dw-00; Thu, 01 Jul 2004 11:09:48 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Bg26T-0007FM-HA; Thu, 01 Jul 2004 09:59:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bg24J-0001gH-Ms; Thu, 01 Jul 2004 09:57:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfzV6-0007Ke-Dy for simple@megatron.ietf.org; Thu, 01 Jul 2004 07:13: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 HAA14916 for ; Thu, 1 Jul 2004 07: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 1BfzV5-0003AU-RA for simple@ietf.org; Thu, 01 Jul 2004 07:13:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfzU6-0002mA-00 for simple@ietf.org; Thu, 01 Jul 2004 07:12:07 -0400 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1BfzT3-0002Hp-00 for simple@ietf.org; Thu, 01 Jul 2004 07:11:02 -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 i61BB1600320 for ; Thu, 1 Jul 2004 14:11:01 +0300 (EET DST) X-Scanned: Thu, 1 Jul 2004 14:10:56 +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 i61BAux6015961 for ; Thu, 1 Jul 2004 14:10:56 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00QpJ0yO; Thu, 01 Jul 2004 14:10:54 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 i61BAjH15954 for ; Thu, 1 Jul 2004 14:10:45 +0300 (EET DST) Received: from nokia.com ([172.21.42.108]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 1 Jul 2004 14:10:29 +0300 Message-ID: <40E3F125.1050507@nokia.com> Date: Thu, 01 Jul 2004 14:10: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: SIMPLE mailing list Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Jul 2004 11:10:29.0812 (UTC) FILETIME=[04F6A740:01C45F5C] Content-Transfer-Encoding: 7bit Subject: [Simple] Double specification: text and schema X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org 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 want to point out an issue I have found when reviewing a few I-Ds that define XML schemas. The problem is that many documents do double normative specification: on one side, they introduce normative text when they describe the various elements that are part of the XML schema; on the other side, the XML schema is normative by itself. An example: draft-ietf-simple-filter-format-01.txt says in section 3.2 The MUST have an 'id' attribute. The value of the 'id' attribute MUST be unique within the element. The MAY have an 'uri' attribute. The value of the 'uri' attribute is the URI of the resource which the filter applies to. The MAY have an 'domain' attribute. The value of the 'domain' attribute is the domain of the resources that the filter applies to. The "uri" attribute and the "domain" attribute MUST NOT appear together in a filter. Then, the XML schema indicates that MUST have a required 'id' attribute: The schema also says that MAY have a 'uri' attribute (optional): And so on. The problem: We have two normative statements (one in the text, another in the XML schema) indicating the same thing. This is not a big problem as long as both statements indicate the same thing. But what happens if the document evolves, and then we it is decided to make mandatory some attribute that previously was optional, and what happen if the change is reflected only in the textual form and not in the schema; or vice versa. Then we run into trouble. Therefore, I would like to propose that, in the sake of interoperability of implementations, documents indicating XML schemas MUST specify the normative part as much as possible in the XML schema definition. Only those bits that cannot be specified in the schema MUST be specified in the text. According to this suggestion, the above paragraph would be re-written as: The has an 'id' attribute. The value of the 'id' attribute MUST be unique within the element. The has an 'uri' attribute. The value of the 'uri' attribute is the URI of the resource which the filter applies to. The has an 'domain' attribute. The value of the 'domain' attribute is the domain of the resources that the filter applies to. The 'uri' attribute and the 'domain' attribute MUST NOT appear together in a filter. Note that the text above still indicates a couple of normative sentences that cannot be expressed (to my knowledge) in the schema. Comments? Can we agree this way of working from now on? - 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 Thu Jul 1 11:16: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 LAA08925 for ; Thu, 1 Jul 2004 11:16: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 1Bg3IJ-0003bu-Lj for simple-archive@ietf.org; Thu, 01 Jul 2004 11:16:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bg3EQ-0002Ml-00 for simple-archive@ietf.org; Thu, 01 Jul 2004 11:12:11 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bg3CG-0001cO-00; Thu, 01 Jul 2004 11:09:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bg2Dp-0008PA-LE; Thu, 01 Jul 2004 10:07:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfZZT-0005AE-Tr for simple@megatron.ietf.org; Wed, 30 Jun 2004 03:31:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28743 for ; Wed, 30 Jun 2004 03:31:54 -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 1BfZZR-00050j-In for simple@ietf.org; Wed, 30 Jun 2004 03:31:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfZYS-0004bp-00 for simple@ietf.org; Wed, 30 Jun 2004 03:30:53 -0400 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1BfZXS-00048I-00 for simple@ietf.org; Wed, 30 Jun 2004 03:29:50 -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 i5U7Tn628938 for ; Wed, 30 Jun 2004 10:29:49 +0300 (EET DST) X-Scanned: Wed, 30 Jun 2004 10:29:39 +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 i5U7Tdi2013393 for ; Wed, 30 Jun 2004 10:29:39 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00OaxWug; Wed, 30 Jun 2004 10:29:31 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 i5U7TUH05933 for ; Wed, 30 Jun 2004 10:29:30 +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 10:29:30 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C45E73.FB3A3670" Date: Wed, 30 Jun 2004 10:29:30 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797CE0@esebe019.ntc.nokia.com> X-MS-Has-Attach: yes Thread-Topic: LS for OMA PAG dependencies on SIP based SIMPLE I-Ds Thread-Index: AcRaWp3l4UL9RkUPREuTjjgv7LX2EwEGVP5Q To: X-OriginalArrivalTime: 30 Jun 2004 07:29:30.0294 (UTC) FILETIME=[FB430560:01C45E73] X-Mailman-Approved-At: Thu, 01 Jul 2004 10:07:20 -0400 Subject: [Simple] FW: LS for OMA PAG dependencies on SIP based SIMPLE I-Ds X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org 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,NO_REAL_NAME autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C45E73.FB3A3670 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C45E73.FB3A3670" ------_=_NextPart_002_01C45E73.FB3A3670 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable FYI. -----Original Message----- From: ext Guirguis, Ihab A [NTK] = [mailto:Ihab.A.Guirguis@mail.sprint.com] Sent: 25.June.2004 05:18 To: rsparks@dynamicsoft.com; Khartabil Hisham (Nokia-TP-MSW/Helsinki) Cc: OMA-PAG@mail.openmobilealliance.org; Mark Cataldo; = susanna.kooistra@etsi.org; omaliaison@3gpp2.org Subject: LS for OMA PAG dependencies on SIP based SIMPLE I-Ds Hi Robert and Hisham,=20 Attached is the LS from OMA Presence and Availability group (PAG) to = inform you with our specifications dependencies on SIP based SIMPLE = I-Ds. <>=20 Please let me know if you have any questions or concerns, Thanks,=20 Ihab A. Guirguis P.E. Industry Standards - Sprint Senior Manager - Services and Service Architecture Phone: (913) 794-3780 email: = Ihab.A.Guirguis@mail.sprint.com=20 ------_=_NextPart_002_01C45E73.FB3A3670 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable LS for OMA PAG dependencies on SIP based SIMPLE I-Ds
FYI.
-----Original Message-----
From: ext Guirguis, Ihab = A [NTK]=20 [mailto:Ihab.A.Guirguis@mail.sprint.com]
Sent: 25.June.2004=20 05:18
To: rsparks@dynamicsoft.com; Khartabil Hisham=20 (Nokia-TP-MSW/Helsinki)
Cc: = OMA-PAG@mail.openmobilealliance.org;=20 Mark Cataldo; susanna.kooistra@etsi.org;=20 omaliaison@3gpp2.org
Subject: LS for OMA PAG dependencies on = SIP=20 based SIMPLE I-Ds

Hi Robert and Hisham,
Attached is the LS=20 from OMA Presence and Availability group (PAG) to inform you with our=20 specifications dependencies on SIP based SIMPLE I-Ds.

<<OMA-TP-2004-0233-OMA-IETF-SIMPLE-LS.zip>>=20
Please let me know if = you have any=20 questions or concerns,
Thanks, =
Ihab A. Guirguis P.E.
Industry = Standards -=20 Sprint
Senior Manager - Services and Service = Architecture
Phone: (913) = 794-3780
email: Ihab.A.Guirguis@mail.sprint.com=20


------_=_NextPart_002_01C45E73.FB3A3670-- ------_=_NextPart_001_01C45E73.FB3A3670 Content-Type: application/x-zip-compressed; name="OMA-TP-2004-0233-OMA-IETF-SIMPLE-LS.zip" Content-Transfer-Encoding: base64 Content-Description: OMA-TP-2004-0233-OMA-IETF-SIMPLE-LS.zip Content-Disposition: attachment; filename="OMA-TP-2004-0233-OMA-IETF-SIMPLE-LS.zip" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 UEsDBBQAAAAIAJhW2DBcPzq23LYAAAB2AQAnAAAAT01BLVRQLTIwMDQtMDIzMy1PTUEtSUVURi1T SU1QTEUtTFMuZG9j7Fx7dFvFmZ9r2ZbtWH7EdhLynDjBcVJLcR5wONk0jSxLsYItCUnOg1LCtXRt K5EloSvFSU8BBwKntCmkUFIgsAcW2kKAEBJKu91slwKb7UJPYPtHFthDS5Y9hLIJNKVks4eA9zcz 98pXihQb4gNpl8n5aTSvb77XfPNdSc4rL9e++eBTU4+SnLKCmMgnw+Wk1NBXBDyjN2oI+TkqCfhk eHiYdT0N/BQY/rL8xZTjP/oV6V5ZXkzI6Yn/lLEsCgz/xExCqkjPxp6Nj+9+fHeuhxBSXjyJbHyD kMMnBR6pFv3F5rPnEu4X1aO+18u3+evpKpKpje8L1fUGCpUa0afp2fVlqI+jXo66eTYh7Yb5N3gJ uQ2uvgX9pXDv6xsJ+QH6J84R47n1d5oICaL+Heq5qIvmCT6+5RAn5nqHmGesXahfQH1HCSFr3KJ+ xyPWW/yE+LFwA4i6sH8l+GnIo01d7lfm5xlEWd00Uq80zNNrRjcfPb3W5dMLa19mImQ21kElZE+L 6M+tGf0jeejktr/lyKavr/+0RZdHp8foJA30plsJmQo9/tdKQn5Dzpbzs5aWNlHr8kThL5V84KMV r61/QdLn6X734wWE/BL1Pjv4MdAZAp0zqB1e4Y83aHZ5EfN6UP+oW7TDXyHkPa29VNvfqDLdf/V6 tPOSW/R99KLPW4d9mlFPgl9vR30v6qvJiH5Po92Juh2Tdkhk1MLo5Kt1f8zUBnkeLoPeJiOylI/Q 8WP/deRsudk8VoqINAZuvixflv/PpTMiR9R4jAZSckoZUGIpiyUYSUWVZWZvl5367KtoWEkosbAS C0UUlbKZbh/tkVUljHddvk4ndVvbVXMddXn9XY4Op+PyNu86KjVQX7onGglRXs4adcRjvREQTUXk qNkcjC8zu51Bl05x7SqLP96jJFM0kJCTm1S6PKnyNyvDW2PyQCSkxntTtlB8YIWlI6L2ywP08n45 mZJ7IlG6vJ/32DbpPStj8U0Rmc82mx2OZeYlq3w+GgysogE7dfTLkeSAHKMWT0SJqtSnpJQktUPe pKrE6PI62rHe5/R3uj2X08YBORJNxZfxmXziBn3iSmc6GU8oS1ptA3HOWCOV6scyr2GFxcL4WcwY sq4T/FjalJS6lV4eCQ8qUUikbBLvVkbTIahMEyUQTydDsJMvqYBySKFyLEztm8EjkzqS2krXxpOb 6KpkPJ2gzbDkfBrvpal+hXphUNoVxyyF2qPRiIzVoAcrU7+SiDI7p5hF+uUeuiodSfalI2qLYK2F ucQENmKz2/SxlUwxNjWRjAjmKPQcj6XkUKpZnb/MbDbbU2j0M+9Sl5ljC2Wz2btZSW6OKIOWYAF+ aDP8bz6NqPC/zUo0nojE+ijoK0x/SbkHUwfEisLyq2yPEKQR7grfZdKH0skkOKGDTDsR0ac5n69F 88AWTgwdPrdnlZjZx/So2ig4BlMDykCcMcc4gm3DUBiF5APpWCSEg8SaBrrcqTkBKtNoRE3plhg5 S1mnLNUvp6h+/kLxmBph7kNllYaSkRR2iNLeeJJGBhJRfmblVATC6dZl60bXCRvRp6uhfiWchi4Z 1RSTT5sGcX1QeFyVo8JSGk+ZBQk+qrMMjzzX1gklFOll+gG3MIrCNAYJUhC/ZytnhrkgxFh6xeLW 1qUtVIWOmaHS0TCbPhCH5nqUmAIiiBtMyf3yZoWv7IGPDOZukUMfHKYiA0yorGPdn0olli1cODg4 aIsoqV5bPNm3kHtaTElZw0m5N6Uu5JWVDVtVrnZrQpPTuqjVltqSYgfeoHfnZuZiPjm0Se7T1Qpz K6rKLOWOwYrCaFBvKh6KR2kzfGF+w3hwprC9rczNrK1LBW9gbdS9NZ498VRGg9S5Be7NlzER/IrK Yw7tBG2Vgtnz1yKCNExpjbFdt1pbF3N+pfrRuVWyWPMJOtncw5MyBnHHMG2A94+LknXGE5Fwr1WQ trYu0j0h37a0XU7JVDQRj93trvk5+tWFcPE546Je8BGSE6oV2tLZk+q7VXbH9TFrO+SEfjxHeMG5 KiyAyyjAePCYhAqtrUs03vygu4z6I6F+w2HSOVP1uDp29s7f0qEIZzBjW4ebs6jdcFkcRGKjcjYu LPWmU+mkYuApiLAWHgeFsenuWFjcYXnXCD9FHGbh3cX5oGx3TALXm+WoOi4SDkawJw4Zj5/W1ktG QuxaOYXLJ5nFlIhcQQVLwbj1iwm7gmU9FCzNcJyJoixn6UIWiyygU471pRmLzeu6OufTNp4CaJZg XOcRcnwcBwmsksww2XpeTOa5L1ycPlK1ceU2HQsZmXWxNnZDpGxHeEtGEnq0PzdHFr9ybVpRWTpg 5wSQnfKsBklMX1LzEZFEqQp/qmHHwe9yUBUZVlqlgxHkRjEtUQlF40wfmUwoYkjOtEOnpR+M7LmT soCebRlzLJEvJgXPWoLFc7OIwfORFaXkTQoLPdhUDoXiaWggnGYScx607Jllidmy2aibN3F+ZUDZ gsQ/hGxLDoncibERwoMRI88EkqEfHHumA044r9Ky868WCvHhNcxbBuVkWMhgYN9msUfVeAtLbLm6 GSNsn74YNMsUH0sP4DEQhAYFlzzvBzMRqD8dVqCdXgjAdMpVDouwZVmWGiUdzmLYRtcqWroZjQix Nf0L1g0sZfPK6BrSf/44wDaGYGocCkKNNJmfLpsFNwe4Z4qD98mxTXR9PN1iyf+0pTmDxWKyWIr1 17I66ne6aIcih4O42OlV/TgV7fHQHDbdGvRZWfaMXGrJEivrYA8hVvEQYu0MTPAmI32RmKxlxexx bvEiujodo2wVTokg7orHU4z4IkH9UT6a/0mtMxW2UdbEtd3XD1dFngiHVsK28gYfix91bBcnrV/c QJvhKnXU093FegKsa/6E7A0Xiw272eEacTYlORAx+to5OEmzZ20+Bwd/gD81sfMLctwj2BNlPJRm B8JW/nWuMP3e0D4LyXwUwvWIf5d+A2opGx8FWyweL+T1+Z0BpydoD7q9ngD1+ulau99v9wTdUErz 2g5nsMPpp851bBofZsTdzvb51O530i57u5O2raeYRL0+p4d2edvceMK0d3a67R6Hky2we9bnH+ty drWBNqMZDFC7y+XGQBDb+p2r7P529rzL17o4ebfPf0dghF9nO/V6+MCdzDMxStudjk67XwjyA9rp DgRbqNvj6OxmpFpoW3eQerxBDHS52fKgly+3OxzdfrtjPRzdy/QWdHogaQtdY+90t7uD6xl/fmen c42QR2PGwz5F4ltxlWlqwlu2Q6Db0UH97lUdTCxoCfTAsdveKSZ4rJkOm6Wg5twBjVt7G7pdXJHt FLs4oe92dwCyursCXEPtbr/TwYXV3/m6Pe6ge42zhQZ8Tgc24ppwtzNDdzJJPQHnFd2ChxbGlXOd E8Lb/SBm7+IHwu53B5gJvFAbpGZW8rCFHmzAxF7rDnZwXXQHuFravY7uLlAMcD5zlYSFQbvbA7W7 hdUy020WjUCwAyLr3cypmKaYbYWfBJhGAt1tq7E/sx0UpVsj6PR3iW2xDWwmPNmV4c6+yu90cqrN 0biIigihhdKCOM6z+EBH1k4zTxIQBuy4ZvhxtPWnBqIsAfgMyxrmc07dLrre20077Guc3M6cx4xT ConyidDCl7V7+SK+mk3hzsYWYy4zr4+7Lbwk6HfD753ZymVeZ9Q13vv83jVwD36o7B7aaGfqbuS1 fY3d3cmcsJEz3sgNz7Tvsnd3BjGpzR5ww4yfMTBnxeVF+ePyhRWCLShf9Iflf42llJCJZYTUAVOB DsANrAXWAeuBXqAPSAObgUFgO3AzcCvwLPA+8AFQXk7ILIAC64Erga8DNwBDwDbgJuDnwN8DvwCe AyoqCJkGnPnwxJmjJ3579MTRE88fPXHmxJl/OPDkw/d+78Z70/d+7+EnN8royhGgdlL/jk0t5Kqy bQMdM4pVoL6h35l+n4j+gY5ydJYXkynG3tbVjRgxY8RcTBqKyraZNh6SoIwySYx3l0k581tH5teZ NrKNR0YwO2dPbWapaJMqUXtXm8gVAGsHrvkN0RkmMzgH/UTjgI3pc0FbjJICo5N1bnL6q7J7iEW0 l5Vtc6wuY5yx1px89jfa9m7Nvu8BHxnVftzYOGJsPF9wZMPY1qwv2OA6mEUmzZXcvfzL3RAhm8Kv MPHnSpP13qJdKik74iIms7S3VJl2eRMp/UlJLhlS+rP6s/versjtqj8Fkg2XSpNPQYdT2MvUI+xr /mEd07Kb07ObM7KbS4+UEqnENIPwNxUmlcinTN+UyMRZxHKotGhv6QtVpHo7nHo7GZHyajSuYV+9 N8wiprlFo0+U5xZVs6lS/cMPkKZwqala8h0qGxoaIqUmCaMSMTWRuoexooLZ/5HJhDw+k5CPPz5L IV+Wv9pSXEwkqei9nNh9oxaf79Li817jkruMjRvOt3EhlIaxnLu+cPUqBJopYz992gofi05rpHzR qZUUsehUKDbdPyu3K18cgs30GJR5O33k7YyRt4Xijtl4B5dXjNzDWXa/29i42dhYWnBabuG66DJd wLoY9xgsZH6j6AKWuYTZeg2wFggBYUCpyLnes377mWX/rGlZzpBbuC6sxRewLj61Zf/xL9+bz7I/ s30S2AwMAqeQvvwPsBoPX5cDncBtwO3ATuD7wNvAMeBvqghZDnwVWAHcBewCfgh8APwZ+JDV7x97 69hbr791+NCBw48dfmz37ezfdfErr1t9XZwpZKbITVmO7l1dhOy1iFwNZDL5+TwfrijNyofFPOS9 xqlTs0ezqMzJzpvzrp+UnxMyy7jWOKqtrxoZ4fMv5hxbSgwcr1ggtS2o1OYn+ofI0Mgqm1g1OXsX m069NptnPPlo2TzJzfnLRRszGvQnDlIcA5hw6TKJTM+19xCweAIhs2HzPxi9NCtdz4oBbcbGyoKN AkWaSRwziPPQkEQksnHPLU35frQ5lh9ynvePPfmZvv9CjlDjf0OVMjsvqBTnnJ3nr2pn9L5qmK+G kN8DyVpCghMJMdcR8hiwHg9O/w0cBw4apf5FwcYzF3Dj8ytwA/7UNSafLxoDwfP2+Wpm61NAEPbu BtYA9wK7q4UP3A/8CfgA+DOwAv7wtRrhG3bgNuB2YCfwBvA7zWfeBFrhN4uAxUACuLZW+JIKvACc PHbk5IsnD+45eNeem/egSrDq5LEN6DzmfZGxN1qcnc3jKq0ofBOIu+Ir5aPfFWO7dZrKRqc0lpvl XDdToVtHSFtnLszBxLOpkmnn4IbMZHb4Z+AQ4McZD0wUZ70beALYCzwJlODcl9aJGFAGbACuAWTg UWCPFhseB4oRF0qAUmAtsK5exIwrgaeAd18//Prhg3vvOXjrwb0H96ZEtUFUn859hU2mV41uEzFz smW8/KCm8sLNPhYIWScYOGxbUJQzKdG/BJfNdGaP/cAB4A/MNobYzj4XehR4jH0+BOwFngSeAvYD TwM/BZ4B/gX4NfCvwGHgJFA9hZAaoBaYCNQBFwNNwDzgamADEAYU4N1Xf/3qwWf27/mx+Ldrxy1b d9ySvmXHLft33NK/A/VVI5bPyY0mEgcA0S7isu+uMciujbDPYrf8jBAxoznPjIqR1shnvIbxmcY+ tHOTKezAH/ur9XmsJXbm2VnFiMUKnvHRvG8sfiM8dE716B5KGpmd2Z+X3TAJcRk2ux64FfjJZGH/ PZr9n9Dsv0+z/xjv/cGxTctqpI0N9XxHRGEXpdQyhlu3OE9fPmLnVcZ0/5s+D04szJYHtLOsn9Pm ixBZgWuBJHBqKiH/O42Q6AxCngX2zIRPzBSfGbO/Ec362DjrS4KTBUfeNTbeMTZeK7jm2c/QyNrn o4KNX5IvosAPLmpGsk6qtu9Enr4T2WEzqQes7UTqOsS+ixh+++23UX0Dg1cD8lxSXY2HALP0eJN0 zbyipnCpxD/cv+eee0gp+4M3iQW2GsOUimqSZxbh54HUsLi7CYgCA0AMUIEUcD1wAzAEbANuBG4C tgO7gB8CdwMfA5+wuA5fmaf5zgJgIeAHEpofMR9KTIdfAfuBA8DTwOnjvz9++jh/fe3l1557+ek9 D7x833e2D22/75tqn7quz6iy6Ty23VxriG3L2TdaNSy0kUnG6Gjot2T1ZOI8U5V2Kxhjf2Oe2J8n 1vOYXqffr9WO1RW4VHft2nVWH9P61BFq+tN5JgiLG6mm9uwbKd8tlOEU7nGR/h2kuP90JtM53woa 7seq7B7K9H8MeGf6yPk+A3wMmHC2i4ESoBSYAFQCk4DJwBTgImAqMA0YArbNPDs+nHr3rTf+/aXn X3oGeP6lR196/qG7vrvtuq3Xfa5nLVP0W3o8LZhrE3hUHpsUtlaOVQpmN0YvNXpxtn8XOgW1I7mF 1kum2EhFq1TfOrHJJ5FZ+15ZSPe9+dXZ+y4rbgTm7HygZO7OoeKL94GjfSuLpgAPuGb8cfH9iBUf Rp/723nf3f3u8Yfu3D3zgVnDw68Ov0lqVrvcLiIVSVILiy7DJyb4fP3xVFztjyfoElsruazN3WUS 3+DXsBkIREV6zcaKxW882C28hc/9gLfLdOPxOeI7Wkm05on/rqAicxdyOqYP+fsOsrC3FyNRvJZq q0TPg/fcm+lZzF+vJCTTcwl/tY70cJqn+ftEof/gwsSvsfEf4zILDdQIuYtWCmhj9RmdVfI2/yv0 8mfFXMYvmYe3PkKWtKL/YTKFSNnWgp46wMEnpMnFfswzmIykUkqM/XrRHo73KDRjw0foJbbW4fdI Fe8n4SG2x/B/kO2ksqysrLyssry8snZCxYTahurKyuqGKXV1DXV1U2oredGq/EWyTJhgqbLUVFXV 1FdVVdWzl6p6saR2LASGnyW1ZRA0YZIaSVGtZKqVht+AUszDL0hfA5clEi+ak5ggdnFJqbmsvGKC lDsIXzTpgzVEKpZMRcVFJebSshJT5RIM1pqKZ09cVGK/Qq5rvHbb4tL67z/4VNucuQ3+X/UsWZq8 8d8c5ovvCPzx6MmQesmkv9t/U1P7ncGw87mHUpdO/m33fyp/OrD9/9j7D7golq1fGG6yioCKgEgY FAQDQUVAQRgRyQJKVsIoCIhEiRJHRUFFQEBERRglB8k5jhIlKzkPOcOQZ5j4duPe+7jP2ec85733 u+c+97vv8Bump7tr1apVK/xXVXVNTaf7xLqKyOvEpwVRtV2TG0mFdd1Tm4bWHoFvkovqe6a3ZFSN bDyDolOKG3pncPsBWlqQW/odnpgYGaR2WDhy5gA9yMH9o+wMZx+FH4Q4+Kr7Y0VSyGLM5XGEkh6H peu51WOMEANMwlLVHSATCVx3lA2k3azG/2Dhn3Mg8jcWqAPAXrqdOvcDcGDTwEQODmOMdJ9c4nsv hPqWU1VCti/++NL7zEmr/htysdLa9Wdeyez7NjJTOdLuLaHamrFgc4WbK39xq3A5vSffMKiYzO3Z Yfl+OkWTt15B9vtiatNFff/UU1TgkNn+frFPmxgT09Ea1/fDIUJLuKV8//Ype7PLkzwU8dP+Pc2o aLtZVlY/hkyej20Yg6rpnqlcZI82KuTtGQcPjEc1lm7D/WoDb0Q512RzTP8G8QoVuDnsrpTuvhzc Qaej15pysEKT2/Khz8PlJvQH5NbNlB7Zh3OxIpKppVUpfbN5WG3L+5aag+ZYj+HVQi8q0JWd/trP 2lGnR+ezVf8bK9PpXkOcVGLOUl4DwdGOLA3f9LV3GAnRN9iAzR+txfFJLsC7KZk2CZ35c9/Kdh8M Un6lEL5h3+9EZkitWF/I7hKPftrxeUF+d9jX5rkfr25oDhcUPuEaNMfB8odftnf2EOCunblhm+yb mM9esaokw9D4iXxBEWvxG7dDfnj2uxQt9Re+08ocad8w8rY9MRe7OTEf7KLQ5l0kvf14ifLFdw3+ lgp85QhN2oyZpwIaHGS0wnutTE791sEP07AEu1PZfqGZmDnpLKcEZDA6wwtheF+rgMt6yvJs57vS r0t59cxMiT2lhXnpH6iAFY+fPKqNEBxLBTiRhmVGZo7WCMOUJSWejuT3H2bs6QsqJwuzcLmZrtxa yNauCJT2XCwiafMeC1nmZEX6wO36YroCylIIwaCcMFta2md8aLmxrariHjdPZuHXEHry/tLVjejY 27eMNp1Idy03lt/MGD2NUZfWVXfum18T3fCEuw4NYOscCuHb9U4b6JhrzfXFC8W9pNDYKMuMuVhB Vy2H+4ynxNJbUe+b1/Jg2PK5fE6U1jH5EIQ5JWXQJnkkI7SzfqYkF7219CkK2WmS6Wr6ffrVzSuP peg5WqyQwU7pMhOy73PapF4pSaQ3y19C+o0kjAyiNwS7b8DGa2QkeATTyTeaPNOIZztsj3o883uL 6zXHJuhkGGXrwcc+q+tQv89WlZIRTfN+lzP6dtvZ7b3j0d3mSdadk+XSctKcO18iBhw2lmnwRPmF UjqHnndrazqLnc+f/xKC1hBy6idlZrAnbIq+wG4MzZhpbrMKvUGNWGMJr4cqpg7dfiVFHOZSZXl+ Vf7sOizLT1K2Cv1qy3KA4LJVzt1dgHYNvtl8aDimqH/BcSuLmOouYllioKcUZ1JSskKzpjfXL33n XLQdL0pKWjSI+yztRrKggA6bPrefnEia34385KkSo+iowLuFpMABwtYFgp9wXnednxKhO/j7vW+E 4s0noSj/Y21SVe0JEnKLyQ1hdkg1rGEw+t23huK+ymO3/KznMEaSsGvzw/Cl3kWfgfknpk0nxWQG F842iW/YureQOQy9szeRSsrpZyu/EDY3ZxIHO8Tn+PhXUe/iFNomwggqhWFHimR85IswPnyzPwwQ Yxzwz2ZHKSGUk2lfGzuFTAyKC/ztlsp73W9yOW746ah6rnFpdcjqdPmHu3tuzK/2+wznxQytOzxB byA+oo9soS2HsKobOhtkne+nYq0xGf1k2TLCW2sdnW8lRkP5XXfdo7CiA9NUQGaRCmRSCBo6m55U gJ0sSQV2/6ACcX0l7atSVEBkE44nUIH1TiPLp10Eg/OHWpPvfooy7OkYVUyKe5tbOCI/Ev1Jux1B ZsJbIZIsyTdmnfLZU7rN2bK2aIUeWTa6cwQ6uVYO9s9RAUf0xvMT07LZVCBqOZoKPG2geLcbiDfB dalAPae2tSuvt80NVs+snsiCi0W9peU2Xf7iSkgtTbjmlh0ZiZfqvehn+o3w1dEut3jT/AOPceMy jR358918z9yiRfIxcyqgt2Ge1SwvJ38ZmzGsyd1XeVXPTyBi3unu6WksOyuB0z+UCmg6VbVrYFW3 yw/oacqRbvkZ1tc7dE33vnNIykzhD2IynrlQXYSlApeG23BlS8FxhGAqENz+GbP6hgostWbY0M33 du0VfWNladm1YGLJbZLpF804sJSVmWmtuZRVHjNvsF2VpJCE+GbywIwp8ZbNnZmx8bwPFdVmka7W 5qYTds2JSzjjpcYT1B+bBnqdc/W484fJtriHY5KkZMra9iOhYzUpHA9uKm/4x7UkMPYWL7HZ8TPG LaU4UZSNP+qevJvglKwQ2nnENy/ilPKNAUx6lPgnHc2CXuKlHmYZhUpsn0eBP2r9XVUIuuOk5yyC wu1bG6HuH3kIacRtyRCWhPPOKsq3eoj28ml+3+65bp6Wv+nhH0RhOdxUxtW/sKkN7//K/wYnc4dw +/NgyZLn/KA08mv2uwh1nY4tSzcm7+maq7LyyI5L5ENscmOU9h+LRFWCNzLRO0qkKu7hwoIML/JG EZNR6RIrpnTwliPOP6qdDCMor8uqnyB4ds7JoTLP2nshS5DnPQiDhQRkK/ZSXnaGf6p7ClcXq2eH q4jrB/LABYwOMpOs04mslnivC9VrtOk20Gt830/RVbr5LVvWYT8+EYJqIhbfGqzlmx6hgaT272C5 n/iTaQcBgwCFOr7XWF1JCXFNV0dF/aryzhY3e9Wu2jo60YLY0MHRzUVX9bKA8Y2bAkxtAC0A7d92 BgBuW7o6a+mpQLtUAerKSgKu4E1/Toq2en7i504xtWsCAsD/u9d+S2cXt58IE5C8Y+UKJlc00ESk vaebM3R+BTw+aGEHHdNCKPWgC8ggeHwIOrb5eSy6c8/PYwjZHrzj4HgHPIZ4dr7jcAc6rgWPn3m4 W4HHdNCOQ4HQDhLgcRd4LGTv7mALHkMY/aCD1W1XEBBDOFjIzcryLnh8GkLHLvq6SuDxRTCh2Gvz y7HFL8duVg/coEYpOTl7uUDL5gWOW54QOHPhwnkBNStPeys3t5/Pl7rcEVBycnC+7egFAD/bvPM6 AMlWABSy9JkL0tJiZ8XP/CKof3nx33xBffvzaP36z2Eczpa/nfur+5ziwTwBzIfoXv3tnMU7ACh+ CuZ/A387J/QR2JksLmr/pT2ckL786fFNS3FIoH+8/ssb/o3XL/WJQ+T+EI/AFSvr2+72bgKQ3Cyd 7KENJlydb1taCYj9vRL/Dxf8az5Edf94tNAQ1DLocUolJ8c7tr8/5/1POvF/sNjfvX7qNQDNFlOA gwhxYF/7QYBuqQWgZ2cG6EzjwCs0f/Tb1d2G0NIFwAg281Pvd15/MTJMGwb9c7W12SmnpKsPbYXi 8fPazrA3A5hFswEHAW6AHxAEjoP571lABpADLgHKgAagA+gDNwBzwBK4CzgALoAn4As8AgKBYOAV EAW8B1BAIpAGZAF5QDFQAXwF6oFm4DvQDQwCo8AUsACsAFsAEUyymGhYaNhpuGlgNMdoTtGcpTlP o0CjTHOVRpfmBs0tGhsaRxp3Gl+aAJpgmgia9zSfaNJocmlKab7SNNL8oOmnGaOZo1mjIdDS0e6l PUjLRytMK0F7nlaRVpNWn9aM1ob2Pq037RPaUNq3tPG0n2mLaL/SNtN2047SLtBu0gF0zHScdEfo xOjO0ynR6dDdpLOmc6Hzp3tB94Yuni6Lroyuga6TbpRukW6bnpGenV6AXoxejl6N3oDekv4+vT/9 S/r39Kn0RfS19J30Y/Qr9BQGFgZehlMMsgzqDMYMNgyeDIEMbxiSGQoZ6hi6GaYYthgZGTkZRRhl GNUYbzDeY/RhfMkYy5jN+IXxB+ME4yYTExM30ykmeSYdpttMbkyBTO+YPjOhmTqYppjwu5h3wXad 3aWy6+Yux12Pd73Zlb6ralfHrpldxN37dh/bLbtbZ/ed3V67w3Yn7i7b3b57ajdxz/49Invk9+jv ubfn0Z63e7L21O0Z2rPOzMx8lPkC83VmW+aHzG+Zc5i/MY8xb+89sPfkXqW9pnvd94buTdn7ZW// 3nUWFhZhlkssN1ncWEJZ0lhqWEZY8KzsrOKs6qx3WJGsMaxFrB2sy2y72Y6xKbKZs3mzvWHLZ2tn W9y3e5/wPqV9t/f574vZV7qvd9/mfvb9Z/br7HfY/3J/+v7G/bMHmA4IH1A+cOfAkwMJB2oOTLDT sQuyK7FbsgewJ7LXsU8dZDwoclD94L2DwQczD7YdXOE4wHGOw5DjAUcMRyXHKCcdpzCnOqc9Zxhn HmcPJ4GLj0uRy4rrOVcWVwcX7hDPoUuHrA69OJR9qPsQgVuAW5nbjjucu5h7+DD94ZOHrx/2PBx3 uO7wIs9BHjkeS54XPHk8A7y0vCd5dXl9eBN4W3g3+fj5VPmc+d7x1fAt8nPyX+K/x/+av4p/DsYO U4DZwl7D0LB5AQ4BRQF7gbcCtQIrR3iPqB1xP/LpSNsR4lGRowZHHx/NPjosuEfwvKC14GvBasEV IZiQlpCvUIbQwLHdx84fu3ss+ljDMZywiLCRcJBwsfCsyCERdRFvkQyRoeMsx+HH7x+PP951gvHE +RN2J2JPfD9Je1Lq5N2TMSfbT9Gekj5leyr21A9RBtELoo6i8aK9YnvFFMU8xDLExsQ5xa+KPxYv Fl+WEJK4KREu0SBBOS112v504unBMwfOaJx5fKbszNrZk2ctz8ac7ZJkkVSRREqWSK6eO3XO6lzc uT4pdiktqSCpaimytIy0i3SW9JyMkMwtmQ8yvecPnr92/uX5bxcYLly+gLxQcWFbVlrWTTZPFisn Jmcnly43e1HkotXFxIsT8kflb8t/kh9VEFC4pfBRYRR+BH4bHg8fvyR46c6l5EsziicU7yl+Vly+ fPqyy+XCyzglWSU/pS9X6K6oXnlxpU35gLKB8nvlEZWjKjYqGSorqlKqPqpf1BjUNNXC1XrV+dQt 1dPUVzRkNPw0ajX3auppvtccv3ryqsvVMi1aLQ2tSK0h7WPajtrFOoCOuk6kzvA1kWv3r5VfZ7x+ 7XrM9WndM7q+ug167HoIvXS9Lf3L+mH6gwbHDdwNqg3ZDE0N0wxxRleMIoxGjSWM/Yybbxy+YXuj 5CbTTcObyTc3TZRNokymTKVMA017zETMHpg1mh82tzevRLAhbiPybzHcMrqVfot0W+d2/O1NC3WL DxYrlkqW0ZYLdy7deX1nzkreKsJqxlreOsJ61kbeJtJm7i787pu7i7ZKtu9tV++p3UPdw9np2KXY Ue2N7LMddjnccih1POBo51jrxO/0wOmH8ynnQOfR+7L3o+6vuGi6JLvSuJq5lrgdBMFUi/tx96fu Yx4KHjEeeE9Dz/wH+x84PmjxOun13GvGW8U7yYfex9Kn2veI7yPfMT9Fv0/+NP4W/tVIQeQT5NRD 1Yepj/Y8snvU+vj044jHGwFGAWVP+J48fDLxVPVpRiBroEtgb5BcEOoZ/TPbZ23PJZ+/e055cedF U/Dp4DfBpJeWL5tCzoS8DaGGWoe2hUmHxb1ifOX4qiccHp4asT/CO2IiUiuy6LXA6xevN6IQUY1v zr1BRe+Jdo8efXv1bck7oXev3pHe333fHXM5JvsD74fnH3Cxd2I74i7FZaH4UMEowkfbj32fVD8V xQvHv0lgTPBImE40TGxIOp+Ulnw4OTiZnOKYMpqqm1qbJpOWls6bHpZBm+GeMffZ9PP3zCuZJVli WZ+yObODc4Ac95z53Fu5PXmaedX55/OzCo4VfChkL3xRRFPkVbRSfLd4tORGyY9SjdLqMrmywnLx 8pSKIxUxlRyVYVV7qp5UUdHe6M0vzl8Wv9p8nahGVA/WGNd01V6vbavTrPtWr1Jf06DYgP4m/62i UbaxtOl8U3GzdHNRi1RLYatUa2GbdFtRu0x7yfcL38t+XPxR1QHv+Np5pbO+S72ruVu7+0ePQU9f r2nvaN+dvtl++/7VAY8B4uDDIYahF8P7ht+M8I7EY05gskelRyvHroy1jOuND05YTixMuk6Spp5M s0y/mYHNpM2ena2YU5n7Pm8yP7XgvEBcDFzav/Rh+fhyAfYStmXFeGVq1WWVuvZynXs9ZePcRvXm tc2RLYctIu4Fnhufun1+u4FgRJghepKYSG/JJ8hlFE3KENWBSv0fGP29BPw++kvz779o//ai++P1 p+s0v175N18/R3+baNXpaPb/OvqrQa2lAeEvwEhL9wsiYtrFyEC/m24PLQ3ADD31R0fzy1ah4CU6 JtpdNLsBaPSXloaOnoaODuKIlnG3Ow0tHf1+hgOMR5jYjwK7zhxUPCvIsfv6Zc7bQpJcuvcfHbII P6b0KXdF+JzLHu6vP6RExvSkH69GxF/Rd1VWkVG1PG5gaHQ4r7pjfO1OgFvkE6uE/JrOiRPnrdfd T16QVVPXAEGdzV3bex6eD7y8nwYGPXv+4nXUm+i3794nJiWnpKalFxQWFZeUltXW1Td8a2zq6u7p 7esfmJyanpmdm9/Y3MLhtwn7IZah0WIGenp6RkYGB5Dl/fRHDjCcYQSOsiteZzp7++D9XZcfCYZz 6H6y4JTcnSv09YeSywrX2ONzxyL0DlleWY3PE5bi1pdWviOyxzUgUsUN4tfAyt1Q5snTHYbXTxx+ nVgADRtH/Rw3Pq5qZH3+j6Hjv41cqxnfffDsbWrJt75Z/AX1G7Zez9+llTb2z22flNW4ec/7xfv0 sqaBecKfB5gxE5gynDluubK3kpjtjvVfGPb5/078myeo3/8N6amCX7rC/tmVnS+C/90a9h8S34// Qnww8ItxI6K9kxyWN7pnM98pI4yARmlJXbAXYyMxZ8cnUoGAEkQ2YcwPg3vcUP8QmTHVg3ZplTa8 SFEiiXUwiQ3zWQZRgUcx+azo0bOXqMAPRO8gsjIeNov6RgViEm434XT3HZZFFsE2uNTTKGobTcgW 2+AZiqMMHMuPI45InIBHE/mcCJElaqcfo+5SgY9BxvD+d7PzGn4Gw2FFueitgmZAh7DUqDBHXIaN UQE2Ml0PFXB2ogJrIVTgcBjl8Zzmo+Us1FDKkseMxWJFZtXzkKGNtRzSioUdGdkwjParbXiYTag0 ylRoqPrY1dNNPMdOpBH5ZP0+6d7BVwpxXZmL4ndTSPDp2Y/HqsO6bvq35Zn6MRW/MfBGiX/YPe0d tUyW+W/Tnf+5E9SO/0JxWPMSdRU/k1XpCMxs4DUO1t7lp4Pn0JMGDzEkOHwhfIlx9Oo91zB8VtCg fz+77OMAo+yl7U1dswaMXHo+Poj4oRE5MzG3fBGNPpMLTFBOTXWFFy+e/hYAG9umAprp6EUF/LB+ lCHlQgQVgOHOkB1ViZgcLNaGAp+iNOhGBZ28vHwSDd2rE/+pjKK//PnC0eALERRBKnAUvYnDjrST kM3k0EQ5/iuFb84MhrV3UYEaWRFifrkPzwMD5JvlD9EzFAQcW7rFRyZKrFKBI1Tg0uZR/7E+OAbR pkNgTvQfwcTMOEyd2R4Snx96uxhEzlJAI/DZaH9yNJ4KvAI11Ru3zBdA3iRNgsdlZejHsNaGEmnp 2QZ7//a2O55xdEKsb5oepamPz9Y6+73cGh43vHUqgNLenMrzoTI6f3DpvR4fr7OC5fHTV1u1FWId qEA3OSRgUSszbAivUZcZJkDDWZzyRrrwIcDmciyk4cULO0MqELzA4pXctYhj2xP6VQNZ748ZnzXY Qv6A6cr/D3WzGwu2bWouq+C5Ub5PWLZst0Mq33blVlZ3yS1RJazs20OP4fUj5N4y4B76HdeXwxrB 8NawF7fIogqKm+yZVWi9qlf+8BS0+/LT2KdrqAmju99UzUlP5/hWgFKtpAGihAtsa/8PwxYdIh0S rPcQ6t9mT1GBvBSasiArlbY40r1AKf5o1ZXv1LpUuJV++uho9AjHwV4hP/Ea8EblXgpv0CjbkF80 UQ52cBNUhq1bhBc9BP9sbG8nOQhkLWikdFkhZnGAM31BvGehqv5lmN6i/EKhzI1r8GNbVspK+xsI UAu5/f6On45TrliWjLxclrjhwUinJVNRDXZ88mSr7tLQ6ZIuuEfR3XggjSDpwgZW8YJitP3Cl7W6 ixxqMu1U5314kPXYNl3XLq/iLRWCNRPq00UfnPnspQVMFPIw8dH7yM9VSm5ZlGwDsDetvy7FRpWZ NdA2nbgXp0IFIlRBei+zwX+V2GGfbLDcAsQd7p+diMdVVWmTHiwcRN/CNWjZW8P7MWbv8rYaYdu9 JgdQWxTwViYqMNaEjqYC5GkqUIsiH1f4SAUWcWAzL/s3bzutIvMaiCugX5ZeoqN4aY/0DQZQCgy7 XEHiCfu1KLeQrxdICxurFAxYQO/vhfSnTkNQO/+5y+hhJPiszOeQzOhig6KJJ69TiGRc5wjhgMkL EYOAIZNIUr4gxayBZDdHwfSdpQKj8PmNecMBdAFsfk3egMneUWPhDhyDrCouWaYC49BFywF4HqKd JJK+vDjU0E8mZ6Cze8m4Df4a/0p1Thg3FTDKvgJ3nlZYPxFOBfwoNSvyxDTWmjHEpvcGCrf8kgBJ MKUDlp/RQI7yhC/6x2Hvkz+BpV7NxgoIDwVQPm8WgRHGFus7sjLQt5RpelalL+TyVs54LxVwWL40 FUB4AJ/PcA8yX7502PLznr0zi0Hy9rc1qQBNNGUPcqSyiWwJ0/33Xe9ZA8Pr1zsON/UcPKfBgJ0j jPTuOc8Jia0QDoePqWG4KWcn18muq9HMimspxblaJMETUXXWVKB8+FRx2xNmChVAdfYpsmZJF7+Z DPAXAzsvU6vqKhWQxU5rrsWlVwV4kYKHKr3y14yKEW7v5M8Uy6tM3uuj3wq6JQHTwT4t4QcV5TNv NsZR4/NTj3vlx159Y9v2scqHjUiSwT53w6RQ3lIBDLIY4hk9dYoCrFPWKTuGcxHGTwXe2bS3v9g0 pgIbHGsJRR5bmHpmKpAw3A8WUhu2A72j6i1Ic+86BcBX0kIySlK+2iPiYn3Uewsp8ieG+QwUxUcH +ZVFlZxiEzk12iolnD+75wDOxZUg/UH4Z6JqFjHM+pYPz2fPN8OLYgGluaonng4P6knyI52sb0nr CUnsj5iHX2NsIEAQcI//XxnMUYy0vw/JHc/U7R6LWmPylj526lvdEkvGE8W4RfnNko1D44n9MRJN HfpNh97IOsD4s+x5QBlyUlyoQHUwxcP3Q7PNVoOKDbxfdf4IcrSvCt2CrNdopXNW2VhuMzxj6YSb c7nEJbQOVpkuNHTh5TSpaVLGcKPNUWum5Cxi9UGzY0sDLsxlEIQvkCsU2aACnTAidsdArzksVrna TLG62tucNfF0toRPLRWsw4ZbW6nAJ7QCeEMZ9ikVWPmIRSE5Xd4OidxefrSWndI137Sk3d8cUGpk 35eVGTyMudZjIVG2nQsVGHEaNVrnxv8g1RL6sNohw2caUIPmUoviWcNnNWIDcqb3fz7zIv26AV2z jlCnbdjFpAkf72ei58B+tiMWl3vnT3iaLo+MLPvNFXsTs6W1+da2YwfLXIJ5ryXeuyTKV+hin6DV KLyVI+ST7Z7o2Y7B66Hct7T1jvXCaVccflT6qtcUeziSVHGReZK9VzTtK18CZiGJKqJ3uqoxCLDt dtcH+b4OmWHjKJueqvc8VF0d96JIleXMD5z4GiiboAA/opfgc8HkCYoU1IG618mxhgrlZBzxPqSK 7jbo/egPOutMeIfIjzxMaBkuS/etiwz+KcukkkWHvCaJOUc45nHyTEha3XMQN4D1OTGQ8pCxqAbE 9CkdNnP9b8Mia5f3mn9u0Fh+WUHjSU9jddYx7v2IE2fc1/iOSwxsr6TCOIXAeh5Aggz/e5/7uKpt Sbx8Tv5d3KJ/30iMa7Y0Y38dFTjY5jjc+zaYpjjne9oJL3NDpWRSzuEYAoSL7kmsx1A4YIH1Cq63 SPsX7vlNxjM+JeYXnFlTevRK7ZXpYlvCS6VXZxsu2jcRo+YesVl8gErZiayxb7/xJW1fNwCBhhbs pJzd/Wt30NPsAz41ZN7NbMojPiTk/uFGVICWCkwKQozaUoFkOA6zRIacSm48FYjidSI2kPRAZ6MC T6RYkQrxU7p2spKTCPdNixyBsa3klRER+5yL+zwujD6GAlmRON6TCuyJwy49NwodwMjIFvOMDF5i RiaFptawli9GMJ9wwk0GuydTgVs0tA02rI6KkL83eeirvf1uNWM62lzkjq/r4pCExW0J3hsv77+m At7S2qO01vuc5OMI8x4GV6zcbd2VLXoZRyEowIv+K0+IpHb9YxT5I7+75ZSCZs1gq/vht/QI9/qj K4W4jvXbLVYnCLgb89UFEuu/IV8hdVZJsM3KAAkKHSVbO8khg6hIyRbsvrVVB9vWwVOQPTg+DEmV bB571Ud1SxMEkE82bwzHqFIBOirwDQ2aaC4BdRttnhjM9pIKZPTGw6MTiBoVQURsCvFHMdr9SJ/v KUq2eUwlMUFhx8WYrCI9SyjfwXu/uX1y+ProGUJnhVxp70eK3jrmiXsfWHFrTTOsAxkcGV2iy7B8 SUZw6FHTtjJsfnz4dm/5yiOh7Os3LbeU1hcchpAkRp3NQTJ2KLvnyKbMv4eU0FYeCg3zIcFlRPac YpVT1vZ8kYEXhvvLXM0/cPI41XPfibPWzA6tUzxissk2zwR2cpUnsrV9e2Yruq0leXQOE+Y+GJle BYs6JF0771feR16w9hSrnLA+Kbv9rtEhlxATcqXPBHRqdL9WLIPkBkNlFMmTiN1mBpnQPheFAtEW SecXrzvfAI8OWj+3LUEqlWPHt+tboytiTUrzL22pqlmtH/PoIeSWsCSGLTPdlvlRfGHs9StFeqh/ /Y5VcZG+z8HiYtkeYePCWhrCB0s5D/n9KFy7m+K8yPeDJ3+ZHFsx9vpbrr6u8+6i6BynRmUQWy38 aqPPU1qR0X4mK3YT6Fu+L5Yesw70n/c49EFYbJ+jGLY00Um4Y4BH5ZzVjfT0ZNH4CY21S+RLYLvW RreD1nDlVU64Is+q8nYZkpJ8SZc41/7GQR/2e4+oAL/1N6E3IiStRlAQP27/Dp8xuNfwtUowD21v RtaBENxtTJNyA3Tu4chK4m8swSiSvjHLEs/4BvOJuPhiI5wPctG3lJMKvHWSK6QCMy8xR6nAuvg2 RHeGYotsdc0HA6qTxejj61Zl+R+lDU8M3nX78C7TyvOEp8NcGe4tjZEfNt3A78zRh+kXpoLPgKJO /h2XyZA3uUjZlsgR+HgVWLVzYgaxHd9LbPitX1JYKkslY5zki3GGfW13ipZXBy+ETRj7FomcIQ8N lYj9oALyb3eclh8vMjx63ThsZkb9juxC0ZrxbJXeRqj4e/Fa3dnwLcf+bk1NzUG3nGeXNLyjaYzv jb01dtEAWciB/6IAs+9I37a9OpC7ynhcPHt9rMcalviKuYP3BzUoTw/5DLo22VBmF5di9kbWdzpp 5O9Jl+iK8w/oBOXaGrAdRAUkEeGIFqdc7dnFlhEdx03/gVbOef6I2mn1QR9eVCN8/ZrcXj/GWcLO o+tgIDI1/z3qGxltIVfRONQ/0dONYQpxFj4e9wtIAO+ZCGuswuIfDZogKxTgTr7RZluM/blUIN9O rojhWX/5BMWfyYyC7IW6vUNu+zpSij+LYlUpfyMmKalhMQvXV3W83Cl98PSd89JiOrSOlUlSykrt 13PvDWcefMO7Upt7GKyt+B/cHbX7D0/XdZ9SXGDNxHt+c/7ueruxzbtrPg4JJUkc8Ldz+Z4HeD+w FZOGGW5oz8y3qOjgpW18bq9uIz41VKntZiNapJAnfTj4DYaEQswctAPmv+osiplXEpuG76caLVIB yyQVkQcOZvXFNTZn+pn93CKQ8AW2O8Wmaa77hO8+g52UwfNkhrSx7sGMUQEZjc2LgyPvHWD75oSU yhMDF2pfNOlKUHDtnQtYraLM9WtFyO51/ljYF3cxpv3dD3D81VlE06Dt3TPkyUcU3OKRksttmcrt JCMlseTtA9dqZ8gBa/MFcpZZbF3XqEA2iBcnKmvuerqGbVoSzK7GaG/vEYGtkECg2G2zVV+TTYx5 z+OvkBCDasf7SHzG1FBYk7XQ7o9l+DBj26SyTEprnzv+3uen7iyMahNUIIWIbUAbOoFcM+nyhZ0Z OEqTsS3TTpAHnfgaF7EhB/tcZIUKnPkehnMozsYj23vRkxK4MP9VIQpsWha3POiEAC+jPgWkyCIv DPE00xTeTXUxopyhTOt0rjfAdCxYUmzDhQ41TM36+9HiWtcG2vqJq2GC8+gfCpVOfCtKEyFM2u5+ zEVcR16231FJFr0E0NhF3r+9bN0/6qZ1UYco1sNMjG4NHxqKeo4O3wgm0HVmiCVRgdOoFT3K5uJ1 6TuO8e3iiXkIMo7k1H9ly/qyGxg/tjdzuhY40DXkmYH2dMQmss79JomwCX3HVKUhu6kAR2/G+rxO sWzvXweGdlfKwROkrnzYsXJX+Ep70rrAhoSKY2JA7vr5ipI1j5QHn0Rz75Uj6y/Ov5FxdTErFf56 CXRSN7J/o2EihhRH4LUlkL7JdUuUrm3Nd40k+3ne12mv6xyO1dVWYiqlm9Pz3r2MOLHw3T17D/fi l6cQSBpYn8CuKVNuwnlt72r34gvz5Jjlw67dHvYbhBFshkZXXY+p3vJrUTZZneX8ichgh+EvUfyp s1X1QR8JKkG8ivAaHd3FZirQWBAPb9iAHKHVMmJKh1QhNx8+58MzhlOaNL+LZdVxsH/mjYUzvDVD edoL1/fm5hytg7BOJroNi9f88PbFHko1nq7C5UbLU9aigAmcvc2r6F25ZtIIN3So8UwXdm6Y1rj6 WPPQUyixQplgbi9nFY/IBWT5MN1b1npXIS1tiRdfGfDJZ/vpDcnIUhgEWEWgOqzQTRPboVinqbo1 HZqBcwEiJQRPNxNmjLyXB2Ji0EzNCRt+UtGxej7G+9FYEP0+B8gJpiIRW5zdS2LhBUSeW9Z3PRmb MYe0yiuks+z4lb5GD5qU6sbHubZmirq8EfLb89CLCUrJbX7zSZkAfOwaTHyhXGZKvA0fUiT50J0K NGTGDw56jlXXB0iODC5ShvYIGlx+TXa429XnLfkueAjKPjLNoLCUszBSjOH7ipZGGmyGdjc6KXzB XAgbHYTbjiOniGXw7E6ot7eREmi8NqwOGRajR1NWZby0KNKYtbWacWe1PMvaP6rfleN1gY+M5dtu z8Q9lwFiwvKNmuKkc49HFobNySJ18JDXxrlP4vG4HwfPi0lT2CnPioxCMRPxT0AHNVcCSrjbm5RH Ucc0oycpgsc4LT9u9eph37+/EcMxQBYMDs7CafMlPD98ws4iPkXes0oo9dX+lPsdLQx4xEeodx6j W2y2PT251iawBvPL1Rl+mAKZ8xSpLvm0kBqaYs+ifsaWkE+x0kwWGffdRVPmd3OKgBhl7feoLLyJ MNri8tqy7pjnTxvkZsH0x4ZH2at0DuB7doUv6zPEDr99ekWZN8IewkPF03gWKrC7Bh+2inUcxek0 xqY82b4+vD++yKDY9POwWKBLnqRwW1+9QEwHx/GMbLft/hqUhi09lCIcQr1AcW31yOCF2SbaL3+3 vEQFgrUlU4uuItcsfsDmdkI607YtKQIdjWkWQ79qmC7TsXGH3TJcCOMY5JMISFloxbyIrs9TsfKG MQivAEMwIQscLHkIpL2+TrmFoZEL3vbAVSLVPDxXlmqK1z5aEzCFq8a65a6+S66W1nrfFq8jt6DU /Sj0TxbWPDiV7DqKaQkN2+Z+mtWI9NxqW6Ew9x+KgI8Tu4kLFDgKh9m8BUmpB8F+Q/Fdw7Xe7z1U YP/Hb8ebLM/StnxObnmqWAycIZAdoXGo15B1a1uffbtUGJzZMn0qNbevws1GMKrxjvyZKw/33RlN /3TtIx2eQAMp+1uJ9SCKFU/GdhAptn16pb+JCmyZlgUR2/O9Je/F52WNDlpdcpjnGFExr15yBgxE 3VKrg/sgnJi0A5vU1c3epjd8/3FtMu/C3jjQEGEcz2uoQB2OXAiZX6HMGgEE6i0eKU6WK3yf1mNc rGXl7t45N51beaqAnSJpaKZmTQWQbdsWrPV2RzauCDmrdQECEAS7W/WCooNqDv54/G7kLV+deXuK Kj+f5bB8CphTX+V507KrIEqO1Hv2NKVZ+DH8E8kn280N3m+Nx26hwOq/y2ghWYtJJlTgR1wbAZm9 xQ/HQTD14MgERQ/ZnF2Z1u85U+MY+MZWT99LvjhvznvGRcnRXXp5YULR8MvgrDHEAQL2Hr4SRZLX YtTzJrEtVmSdklo40cnXG0NZX4o5ennAw3r1zgvLi6GLBx0NUjWPNZ8QgNCsTtvovHgHngr0eS1/ WtaKKikj5kuPBzU5OHQ+3/vyM90pQbGaU3TOyl+ZIIYYoa6SogJ7FW54oL5iImLoJo30ENgiBUsy heeqtdqgz0IG1m89X1F3zyv/Jy5s0O2E/A0JV3tkhJlMj9lgT+FC1MJIywAP0suBNzYoKy7xzR7d yWG13chvTASwFbMuf07Sev6ALt/N+s3CCgnZVo4s2Ir1Q4vaw4OH3jRbubw7y3HgnAXdPlGGDQoN gYh8k4nyeH/cIiv5omIS030hihJde6ZZxzlRZ3m4zU073z7Kg8q0vkHUkYDZ9MU3rQOHBnkNbTgc HL/QeORwjbJ5RTX6Nw4gbgpGiR3BvyVdvbd97p2fPLw/DMfytfubXhg+O9qA7s227QhP2AmSY77v nSr0yy9g/rl1ARUpVhA3xFZMCZi9QBxATFCUSMN8rIGUu351PZtKWE9tzaPwACrAOEO6QCLLB2WV nuxQTIqn912Y0pnbxI6sgTFrDTa9cB8VgDqzhWrkCypeitEgD/RFeam8kupzdQFKZVWFqYDOg7T2 iixpFdsjH192JMz0o55X9HkRNk9+8anyg81FG0+Qi4lOm+iUEox95QG2vSQlcuTcjyGHlESFsYGD F15o+sNT8OZUALFJTlq58uGBWxzz9PPASEp2/4/7Q3CO2TwwR8ikAvZIDGI4sJv9oS0Ftr6BZCSf 1DtPQs/yP2pCT/Xn5nMITdv5XfS7QAVMwqyUogQurIHwalbhyczQqbfpSvoUxGZ2Whgpx1/SQLfn uqFlXksej6kV9zvlqkSkDWpeHktIYTgPi4YRmNNlymRy5/bU6EBWcLNM0KyO9IhA5/lifrlwJCYm yyW07ImGwQrn0Ul81Lu6oJ7e4jzBJs7NGst1KvCRwC+CLn8TPl7t7vsC+YZtLS64rRG03XUxTm1i ZwnyGQjekkX224Hh3rCw8rvLaxGyKiVgDgxewyy7RaZSKP2EEkwojKYMOTFymleamY90yZQKHOz0 EAyvi3mEXNkSDrAOlT43ASbuqI/wc8R37p7cBrJGbR+9s0kSUz+wSUmh7+Xi9EHASXagoHv7Ho8M 1driy57D9TxeNZ9oJwRFwYNSvXxzavXo7OJUidjswlcf36UPn0ibFWj2ILPwGeH9keNw/lppoqnj 61bZTW8dXZwBTZpAz2O2CXyJABXIuQi7SwWcw3Q2kZXu8xsiS9oN1Y6y5qcUwdoGJe0jBD7fnwfF 3i9vr9f+SbNf5Oa86t+PRqYgZtTXXcrHYF8df2Dk4JI6Ycvi9UzJsj4NQrryCosYpRrxjT0Hv2V2 x+zVdzzr5NRPBdh3nGxoNsEeGs4eBI1PCxo8HDKhsNeQPp0uD+YuRr+FN4akKSIuVV1QEFvkzTp0 UtRCZ/tDWeKLK+Fm0dqtzNZqjXZpP5BgzHP5yzH6CkTbzLa6AyI2VvX1UlZyteV9lIRsze5z5aoS YXcn+HILfySIdRK/Gr6XKOmxFrG9gOyPa7Y4PAEy9iHJjM+dz6iv58ed3H627S4qUExA6vyOK9uQ 1cYU+x4PCT2PoGqxpTipbUrYqofRNe/3mNkGv8YU78VCJTemdCK/JvtXeMMXmZxisJDH78LaZiet Lb5Y7t5uXafLzUBOC28fGYARQZE4b8lAsy9IaOQKrPFJOsmw3km8D4uJLiVI3qA8pwLllSa9UdzX PZOHYtbeILEFq3Sztnq38V9YNnkegiYLjQ7a/toviRIzw6vWQZPYtfnlk/O8pxudqEDY+SfY5bLG YbGDMYfsMLIhX7vI94XvmKBSi7sg7z5tqwrNBv4uS0fQCe/WxWcGtjjqvIKdKz52tGdSujOloS3e xW3uWR62lWQ4GmIFf0yD/CRDMoGEU/zr2EUqD+Wg5CqCbU1m293jzWZSvarMLd97vcNyqiKkY77h DmUP5mxxBBXOunHKaFB4f2Cm8bXzoxCB6TGoHQZU4I0uWbUXmo0xgk8p9nMMo0klCjxOnyuaXAxi uQpPv5MzvhdzJ2PRyF8UgA+f3U2KgAZtPhuBJW5OUoHqiCorQ19XvKKI+uJQlzGldtvurX/q9Ymw ZrYb5V7FxOcHTcXsxRgHT7KR0I8uhsqDvdMDSQGzwk7ezHbawvycdCvOB7sDNNDjL2E6i34p6ymT 5p0XzJdHSt7m+XEX4qTFZaJTCSMfG1I88Upc5vVLh72udHB1Jgvrflp2AwVZ9JcTYOmw7SwqcGok l2IZe8LkSXqDhceMn/0H/dYflWkkaSrwRWaf1AHx/uFgFslC7er08MhGnrMPD+Uce5oEyQdWueU/ vxAyVSE7k+PsJVbex8PzwDEkukI6zoRiapJi4edhDM36IaEuAbFLtRHFeNIzWhWHrKlsfXegZ8Nx LThfdhzO63J2M5mY9hArn3Xx87494vUsYp/VLwyGXkKD5byIv7CLpvb+ESN7kuEr8bCo/vd7zD6t xlhZ2+WGRCqP8FTE9+F1KUKVjzo+khUeorxgS6wdljHzsVx19x+fn+s8xmA3o0Fp104YsXb8wsS2 ZZSpFTRDDqrILV98qr9KBe6485vch89vLoTlLaftWLMzrMlostvJlPSwn6hdfiHC3lFPXEWAt/Ir vfFjNhjqfkNpT9WxxLSjATx79s+f2if4Kfv4EIOzKowgkUk5Y5Dxuv66UUffMZfd4khgAU3cn0j8 6jfAGGoYWAFvouHTTFYWTnk41tmOdotOgwBn2O9Dfb/7t1TIIzVcq37/7hmBmW0LzMQlQJNgF+9d OqOk/ooKiI8ys20GddSsyIdIkyt6Asim/n5cbpdkGkAzq/vyAgu26QUZ2ecTLip6SKKdIjHTW0aX Tiy4TgWaPInYrZFaxKUR1Dy5ksstpx8udOo+98UHxBFWyzkycpCY4VDXHf4mXZmNkNGz3t3uFnb3 u4dKv+nT3ZXP6ci5cE1XpDPyrANCm9C7x1l1UQGt8MS9jk0JlaOVu6vWmQpcn69U2yr/mz+8yQbq QIaCUmulv74bW32FtaLQIFmx12VL2on3BR1f7zB7s46Q6ICiAsujXDMvAu8qBRpw60ZAY+3oMZGG w5hojCiBbkL+yLfUpZGG8/ZtiIP2p+WMkWic3wFHgC7LQ7WXAGn3gmCetGPfQmvKwz6iIHPolyW+ 2KAvS2Ypz+tuqMAc6zjO7astpgLS8VKchdjkaVIkCLj+YVbiD1OZbqACe0TxAcqr0dsPl1nW80+X NLE8WstgF3EdaxMwwXPdZbpdJa7wvuF2GFbOJOTGuh3UfU/IO/MqjdmTu/BTpFaF406Wxq8Psaz2 M3fKlZzvSnDwDGYJ5tnffqJ/zy7SY3FopcGm5u8BZLV3G0YFrDjWlMAY1QAGRqwNGsrB2CBbmJUD vaFF7fcfYN9XEt8VE181kZKXRFr4z5/ILyOA+CxrxwVK/Wo3j0NHB93kytPklOzu6G6YBGXjHGEn /Z/4jfSnPoFtvpGBNA8/owsqRQQVqOJFfv598NOPjwqMSZar4kXWChdImMF0BSqwRMENb3PYuZ7E XpCWgc0HsLyioQJQvpL55Ne5bGWTaUP+SGffS9u3n2Qn9yq/ws+NnG6kiAnXjIABP7d0L3xn6O+b 0gH/tWiwufeg6fGUnZFSdXQ4hlwWPcZFOSpJBSoD16HUNxfqjBl1sDOclptGvlEs8SOfGbSH8bhO ouXep45cxOaqdhzOu8/vwctRSIhZ0ZATzt6+TFJM3M5YJyYSkPevZal+Lqo3KJcr9n2yq/ezx2mB i8VWCuJdi3rkPjueuXYeU0hq87EMJ3WTzuoFHw0GI89JQxw0mEgF/ukc/UU4Xq+9gRd2jbQ4GNtQ dLcnmG/NLlPFSezooySinCXbsjDuvqWTkSnv/olg1BwkKHtIO3wwKzFVXZkLYdNJOdK52YJ8I3z3 +4dt3o36sduwkHMfwsalpaB6NtL/nCb8XLx39d3N1Rd1PT0D44+Yg9fnNqhART90z3onxbG8qjyX cgNL7rxhRgGRYTAVYKiJQTz6gosxH3AIH9xlAdtzHPbqAJt5QpaVlK4OIa/SwHN6ZFpr8rUGK3xD 5zq5mBOa6zfzUeyWhdTnZVithuj0xDZPN/7i8UbkvkYsW7LImW34uNOizLIp3dxbGkp63Y+U40Ps YqqEHFAvq97H6B0occh+UsNJzA2pSxb7ED6vr6/CRNp1ia1i1xC3cEXsl47EF34P9bZX5628wgIL 2jV1rPwk/vnCjHeuVGDVFkTrj8MIImDz9WvW4A+QTOnf2NAU1FJQ6Xj1VyVfKjBO8eNy1yPHDKCn EF2UC2gwwcXyN2xx7v7kg+xGocxns6fKkaSMIxSTTSrAj6xZoPDXYi6j50EhzZahFWJW5dEUgzAq IEZAhsEnQKGy+RM4QFmQEObZ7RnZFFOEIBXAbJO7M7NgNWuWoXCR9Q3c7vW2oXimJY5khZEmrw1B Jnl7wQ1cWCfL2WJCRVmvrvzbX9ozlU1aL37qQaLYYU6fAoHX4REehNUYFbhor/UuBz0OGZAe5PH7 nSgHmns2TGq2A7HLNZm6NWn+55c/VwkF35Rvryr2r+/7NDDJB59dvUQFTHcmeZj/5TqSm3HI6hzv fFg0Pnq1t+Ry+p2yTrRKW5Si8KAP0t4MK/oBmZ0PWvGO+itBY5fnHZYazYrWB5Hu142QpSz5bweI nayQl9pSHnjXh5MeHNze4LywKI1pHsC8D+fNpgBg6+ZsoGaGor9RAeJxbAQMHyenSgWQ0hQopYVD 1z7ZkI4FU4Zzy+GrtnJGVODBciUUypt/nTpI5gM9LufVdnKGFRX4ZAU1pT76FBXguhhEzoKPQ5Oq MZD9bICa9mQcOZhEgYNOamwErHS7eAa8mm3562qsmxRDMHE47Qt6tlrmATSx1nHHlH39VxGr9mBN AyiKEMQ7tPQJoes06UkFHJPwylTg2UtQeW5XQFXZQzMh25pUQMah0awC/o4KtJKmHNwzR4gJVgP1 GGwtSPIQmCCGQGEkHQM1aQK5EqEQ/zGtzbcdS5gXk8IPGRlsZPGhubw82/AjC+0KeX1nIFcw+K/7 zRZZXXY8NdrGd39Lnx8VwDVX5QJh7ZE2i0agE32BwkN9b6sOEsqQoGh5WdUhpSSeSDmYpCEq21he k3c5RKOVTlABOkj26e2/Ghb1ByYnFADznk2cSXgqAO+uSVTw40RH+UxJi2gtt7xL2y3yRASfHiuq R7YLsyGyBLQKfPzCBHfw97MN4938CG+52Y4VXv1mA59fgY8ge0nE9lNOS0yEirDrF0GrMSD5PRsb 9WYbQt5Fdk/1VkabDOK9zqcQ4QqFvUiEhZzPkxBAhHxj2z2riIWihGGx89Es10EuvxSORfV4UliR 3K0/LNx5KJwjq+sj2paBmpeDj/HlKKhuhLgk0EbNq03ZMammmSJ/IBSKH6NhCz41dQlNk84HoXmL vZNHjdIUlv7F+q5U99OMD1NJEJbqhcRnl0Kq1sGxu91Bzs/gYVi0wkyWRskNIVr0fMKGiSuY00Rv y/aCKWq5yNLJaFIZxhxq7bdDDpv1J2rIcQHrJKV4zBtMFMYdlHMpKNCNLdsO8Up19KmqBQoTsgrs JmisB+8rvtw+Sg4pRjeXUM6A3sdpkav1zVmzSwQF87i0df5YsYBxeSeunpgnjn6xxa6gFgYHivHe 3+5CZs+MHF7XeldQHnf2/DXU1led7MunLAeiNuR3VzWXnf6jaVXXMK0dr3SpABgyY1sUQtbkXF/p wEDfXwnhkQrIdguxJKG8vMAwMClpIuwHLWov6srS1UbKG7k+UypQBA1gYST+5RR5Jox00iMVxAli 9iwiMyJrMRmRZAc5uRwJyprfTvCBbkynAqMiFEUoCaqqHRbUsC2zS569F5pe4XnDvS8yDGfvo/JG AN5nex+aJwyGzI4PGU4Ftq5jhOCrFz3CKBQHMrRmBcobEJfb8Zpc5HJLD+R4h0c2ZXXYB7Ka6F+X Zl6VC6OIvkMRDZupwOVmqMtDxI0o4l5sRFNkLTQ5IgO5tbnbIG4CDbVYk4SkAjU1laA1rTu1g5fN G36dYi0kgVEm79b2MdADcBUicc+GIX+MJ4+jx/vByFAIJ6mBjeyEUrKqRMw3LGVYcwWU8n5uKjBS A2Ur832QpNbuUmw2kF+pwFt02x5YO1GK75OdH3xiHYaFfMkRqNdGEJQDlgZq/rKkigQ9ys3KzYIa Vi/LrnN1alQASP+55qQ47F+uW9RG4I1USc1hARh8ePkg6E9bgyDxCEGdYQn2sgRlxGcFRJGccHtk LVRgvvNXWtQOTPE6tnbenU9gbT4D/V56hbK/q+u8YvuqChXwyqMCmcv6k3L7ZYfVVLlPEOl8G7JN fG1h4gU1y7zy7tZ6R5HwRTiGzcvTgfwRDJLh88KosVmUVZGfO5/RQTgWCboni/MP+ANwsAHYppfb VxJ/BcgTG7Eh/1SwW8huOrLx9qb50+UP82hs4GzDD0OyDnFi8cL9+2OjFqhF3zIMQrF9arsTb/4R v5B/9/hxlYuTZ44vomOFQMcPe3CmfXAjOvLpWY8knnUBNsVJedlvZlm1l2OD9RBrKJQq+toJCpFA DCtaz7yB7p7pKab9Fo+aHwNxnNPGzL9eA6KHWnedb8eKaMUuKKtnCz7PQy1sMMUgH+FO+jh5HJ6s 1lZly78ayznM2ntuY0FDq/8G7t3FR5nS0BjSaiPunZxBSQTQ0E6amfnujXzmFroVlOgH1aFD9HQx cvgcp1D2opwiZkMRCWsoDL7NN1zaBe9GFHi7FcGebVb2rmVhkRtLq0iGCI7ba3I2ws6lt2+76Eve pAKI67hA8yWHZqty7ku1zzK2swP9dCLdjhbJh4fJxn2mAkOWP4L+aMf6USrwdM9m30L7dO6a+PXL 8CCPQOZ0ouZe1Y72vMBaXswcJdwDstA0aCmTEejfdldh72knUGzK4bbdRlmSsDWe1HKJzybXunju f05De1iAMCgm3N7jOgUNaX5k1b9aQpspiR67EduuzNqE/7RaHSYQEtmIFfsx/G5RF+AiovMMPKRb b734eLRZHN/2zanRnhvyPB0J0FxdkLa97HLXsjlqvkKMjfhqsW10nhwdREC2uIOqMwjVs3hBVVn1 eUJ8fMLh4/ebnbIyAJasS4ShSCh7gKzZ150Cgo5+VV8wOa5dHYCDoABi69FO1Pdjho+JIraWQvpB /6oOooEGdyw01GX6a/+fXobj86yRSyYSZGYJqLHnShH40kn40n0qsG9n6SbU5qQgkgg7ZRha5g4G PFYciAtb0ZBb8uH/dTFx71oxpTFgMpoiYN4NeghBT8gXTeBeQAuV4RRQHVehp2i0oTKESKQgmugu US1BumJDBXxYZqC4bgGx1sK+TXS/MY+ezl9zNeBM529pWjJvq5UZjd3M22JpJ/LX9XNBOdIFSEB2 SLwG/ME1h7BwhKDC+TtnOYOLy2Yctjy6w7RqiWGJMvobxGXh3MPKuFm7dYIDNKHWQ1D4l715ATlm BlsXV2BDjqtgncgT0jDwSkE4VCPoEY+jiV7Yr2wkY3Iu6AYhAhk6f0IanZgagk8uPjrRTw+3fjaB ckazeFYhEFToLf6pLHWz02zvoLX+DmU9ATmEicX5POlPaCK/6IWZUPnJl1zNGSJkRH4qdi7oLehi lmazHfk/E0zIYHc+UKj1wC0k8MLHKWY+c0EpBLSTFj4ORWzK8AvbQE9QhJAIu8zs3hp+9CpSPHhp VGDD2f+8G3zEQ7q9kga9GrYCW4ODPSq5TFcLn1/Tib7M4+NBW9BOQrRnzsiCPX2GR+bud1iy5D4Q 8kc8vIjMcXqg1BXUAc3z/tdPBvyAg/YZdmI1pZhBR5A7Dyeuj/xqqaXB1Dmb0ocezEDFDy3Z4QvD 8C1BM92Os5ZCsCMU7SqP7XuYiiY/UKMcnFZApVrAym5d6Jnv3zNpQxLb8naHYaiAHSVbsRNZEIvY kW3DQDN8EbYGWu9cOeUUJVu7yAMExWtOpk/6WZf7pdyjlpRCG/Qcv+ch1IgvnqU1EkxfCY361IV5 sC0IfBQqRhGMCftdwNBrSTZ36OkyH616Iv/HyPVb2EoGOoTDHdRRXv9bt2YL9+qbhH0kcgedtHjb WFXEzTg9eSgfvbizMFoMQtoC7m9Iw2bwvmHkQKyfGUnugXvcCpg22Eyhs2b70KtQWuF3S4GL9Hkh OwZ5mNA86fg19ZnDcuPADwU9DmdsgczF09WDDbb6F64tiMlfEjAt3nWY1OeT7ebyV9J2CxmSC6Mr XHEvT5FBvKwbLaKITktyX337/e0H4Hmi5zGl0xuX/ZOHXF2dIJ+QBX+f0np/HTuNuYt7yuJ4xX2z /YY7Q6bTxu3cRhFyKXwERQoj/g6TfKjASmz2yygMCLHfIRDY9wMw3AzJpmY5braFrXEY4Hue+xBN TwWgdY3GO4ar//tgC36BBFpEXuj2ESrwfKIACSIMiHE6CEIQOJHVxuilQZ58MB5HgsgidAEDXrMv /dXmbg8hV++0gFlJEYLACa2U8LV1Qa+6fkMOTFCgudc5NASKNNnw2iLkMgSY3FP4+bAgKzH+EMrb +lVSytlTTuRIpkYJ0qXKDCpQoYKFRNeABR05ZwuSnAZmy9Ag44edsSdhiipyax7xBIF/1k7Z4mkH yxvWQT17HMytbsB4TzHqjVOBZtIx/nR6rWZQQ/PEFVLrcCM1MrQNGzaqsM6dZAUCut98r2wfKauC kd7MUYFIE0mKOJ9iBTzE+gx8vXIAB00ot8yAVw4tQA0xDn21LF6yzdItx1Yu2yypVFLEdGcsYcRH Sex+strU6HmBx+fOFlKegNHvMjSlff6vQNDcq+7vHQYvBA0VqICAY8Jjx/hewFkBik9ddBSOH1Tg 7MQojiLkCOL9EcnbUE+pQ6DQmAqsgbitOI60jwrUhQ3CVne6suDP481dmPI1+UUqcBc9vzbHFH1F Zpqzlici4nH+4qbtaBwc8HOgKEw5qkTdlAk2u6GzluA+ze82/4rInE5ZA3PiQXIQccEnygEbl1AO ZjtuPASnTWTqhtHaMLwuBMRBRBqkxSGJkbcTlOzomz+vTTyf06kAEfRDuI41Z28HgwAvBQGPVhNb 6jqdCvmmDH4wpC4ife9vYiydxt4Fk+G9M0OerXKPLi9idnFQNNdmFemBF6xFrHW6e25qHINdA+Pm 06+4l8O7CK7/9InOPxkW75Z4d7DvYgimYIFtm3N8gBjAfJxu9p7lXUEZKsATtjXSIl3aGttyQGTf xNa+L1RAsFt87YkvurW3zXUSadDrhnPxQJr2fL+DxuS/HYZ9hZ5xyMTKkvNLZDya1LNJpmiblEs8 VGAJ2T0rSy//3t1xpyNhdqJgjoVsJokkY/HZhErZwZRthg0VS0v3UMrS0AQz9sOXuvGDZF/nvFz4 ikkfbJM8Hl0umdKjbM+zyXYf9qOTH3n2zBb/E9MquEYVYrHYhIv4xHvf5u+tu9I7PVO3lLAOH0e7 kmwwB+qUlPp9DFZKPjQ6590q1juR2u+Tc+VRTKNW5VGVHIZEA/QmFBK34VvFhljH54tLVKCT/O7J tyUyuWcQ7bo4PBysy23ierrkZPVogM/jHW27BDkQMLV6zbZuMgxrDihYM/Hx/hC4gm/oL7WoDC7M fT49dF6rZcA3Fl0g0PM4xaeLgfmc8ms1VNStz1WgaxQgaFaVISdTzEZ9nBLk6Bw9ohGO+ixBwzFG wnmdGplfrynqucOvfUV+2Q8l8kESvz5YZSfxpn5p0czDTspMKbRu4vrau6uB2opjtdUGjq0ps5xb jBPkECjLKYBTvOHtTPvXFALu+57DP0V5U141Wk1+8QxzGZv2CCq47QV6h9JBUW9dh+cSLw+onSpX Xap1W7CV7y3rdv1dSTpct5lJuzPwN1ZquGMxfY9eLGMj2B2WWxZ9kRFCpvwMtv3SKk3Xj/yQ1as5 lzUK05xWgydCaof4fSHW/98OER2BtbCNC7PPMNU6LuKX3hIP7w3ED7ifdeBtGX0zSI4s5JuXNlx4 9ol2tasBNs901RcBLS/Lfr211U/MyMS9WVmI+/p1sgh7y95hrEzafKV2Cj1VV7ol0RsMeX4YhAa3 KJrINtVjpCqcPFId5695okRB0Mk033q/b4fNOvlIaWyCl4xHC3OmUbbQKlDufCLiVEQFpyE0bYDs qYzsHW7IP833vJuY4LjFhnD0tVl1yCj3qLJyJXrKMDPSqh0LnVerbJAhkCEJPoX/imdEtoPWkRMN X9o+ZS+zvZLrll4+01VXsFUmx9db5XlAxZAvIV86JkxKWTOKFtNPH1H7KAMMHo7wSNQ62zLbtAxp RK65wEeIJTdHeqZWrPvZHCXV9KOcjeVSw3LcU08vjktMOVMu7igd+rXzgsM+n9ErWWHb0TAm9Kqg ZzFlNYYNCi9qkIGB3fEaQa7AjQZRRP37wC6AOrE75e/WAEM9pVY5V9TpPH6Kw1bCLLnRhfVjwsqD UjrwgkFDf6yw/wL2KdP3MFzYFmXaxG9AWioT2b3lxrdiEj9s1KGSl0EBkPspqDBcld8zMdyDarCj g2bI/JWjxZp8Sd9xYPB8yIs8RPmArPObpwK+wepYiuoUmT+ToVT0DCV7sDvIDWeI9JhDNh9/CO8d cip3ujf2REcFLjiroPSJft/cTfbQl5+vHS8mOZGQDUN+G2dONGwj239cMcwTV2uYovgn9ZkMo3O/ 8PEq9xVchB6XtvvXzy1+Yv8CXyA6TlWcDQPDXGSiwH2+67B1eYrpOTMwVnPzZKfer/EMsK/c7jq/ aXzAv2qNZ5DNlbGO+4Xl01E/1XkbosxFk6lutY0FPXL/annBFr/eESWTQhfEsiQZXTqB+4BoIIVt lzH50WPmU7YJl3TtxbAmBt4X+TVGyMQ2iQmKKmnYZ1aYChjA27ujfYUoN2OTRsqx/J4q7IIhg33V koi65x3iWg9LpUu39kyjnDOvsrYfN2g4HCa1+dLbPYOZyYj+JbKORBg2SS3Lp+sycy/2kOZ/E3jR f7heVH2iYVdjjrVwkxf8ulM2/6rqW5kaL0+xxq6D32lMLR4X0L6bV8wnn+9WJZRsnPU5vuD3p+iW IbEOYqTrBkhRaTAQSlBkl6Sztnl6D3kG5BTxi+meJ/ZmCjjttf2oVifHnHmZW+BikPluvUQZUNtA VPBFtuouchw1QdlZswqNIs32+l7fzlyLGTNclcNMyDg7ildmN75yPRRI57IZ5x5VmIbhgYU7V+88 wiO9oUo6JeHWMT6bWqVF0vzUPpnIKVecKBM++IUtqdfCQyCCA74tDXmAhJ1prTQ8vS1N1jz69XnS K07KoUEZa04qcAvZcboQ8lGGPtEUjpCe1wU3RJ0asM/lFpx783atXsjqHhnUsx99ESJEV0BYJd5L H8dcw81A1jLu20dxoAIy/j4vQ+lKfbSKZgynuN+6BelbYJw24+fhKd4L1hRKfXFe1nxe6igAocCb vy/4LwqkXEI2sYussfktYWPQR4rir21I17Uqx87LJ7ytORW6uphp3+BVYR3PpF2+cOx5fEj9pwrT QCsrwx0IRfOrZlaBqRSYQC0mVKkhxx8swcikQSLI3iUQs4IXn6JW3kgQPepBhFWXuIQgT5RBD9Ga iP9K4a0njHRDEr6VGU15Gg154MOmIIpYg22VgNYPRWmnnaBUQ2F/Dvpl6Dly0FaDQBAPon0oaFT+ Cnl+2G2bUIE7X9c0wQxP4h540/5yyH2vEuuQdfnQNCQSH/5vTERCzHXqUA4iSMkZMi+sq/xJ7oPM JqgGi6SgyV6z8dX9n9qXHpDy4vqeWiYlhSnzye6vYHgZoac6eeyZBxTOXv/+RGXoTA1mGrbONJrs Zk2R9WRUdVoivbExNMkG0zLsxIL94M2vkVbMZ2WH+t/UIiE1tK/5jln5/P3M23m2SMQBl1OmjB/q 5+dYRuwZAmN5YDmiL8CYybqjVSi9Ha3ae0alYJOrSeUbsi11cSn6M/K5YG4UG6EHaosjKRyEh8Ye /tMNd05jDlDOTxDWvwtSqICnv4tWI6pjlyAZz0PTcvgp2ghXbISHsLGx+fb27mEqcIJ4GF1AubSV vLVkBibIBCtPc0uK6EVj+8qQPPg0KhRSqBwm0jERygjDCAyfQkwB47yEEjTECh5Ul8GnTX35wYAb MoIh1ttDscYWeuIuA0a5jtxaxzyG4XOJlhRocARh+Ken3H9bJ3kd7Da30GaHMt4vJOghs/E4rFN5 Y6oNNKuQnRLWSYLPzPHodffNpO4tuKfcWHIUg/VvHx3uV7mJyicN283tzO5tE2bUi1YeOK0tWCJ7 0TlLW0TxgGFUM+TJ6ZnTAxIpiLIihaH0gwalLZ5440cgSoGjMdOrbKv+5gEEeZiS/bmH9+AKcUUz bu4jk/eOqKIa5O1CaUaDA3z2idNQAcSwNMWH0DnWGUaEf+eP1Z1wutscHrW2OXs7MPF8LsmHfxDe VQsjm+r0z/0QwiSr8WltgSEOeuIn8R9mLSi/fcldUcX79NovdOztTYVNGviaglg6SAa2RCbOCgWN nYPNb28u8m4wYDEvh+FohbVimcJcdC0fcnz62gKiscvdj6mzL74XJcPsfsXn4yrN1dTspQ5kc0en Lfv+K42zQrUkplleZcRIcm89J4X19BblQPGPbafsoyM9MiXR55YuZL+FbWZnMgsJP0TCt7ylfHQs l+Rj1U5Ij7DzvVDcpBwuuwDXyc7jyViIiSRkuXnvY8LLluSFnpbTAd0wXNNMieAjEtdtk5wAxsie bye2Nk8NE/7xwYubBaDfyp5kKPQ3nlxHH1MQRnqWFU++udLwZoRH86TwV/cGz8hDR5IilG9IS1NE i9gHWpEGzyyhbJWTGJRarhqP6/HJKI++g9XOxJTfN1iLMXEbVxlRVaGJ6ko7EvWoRPAxlEweIv5V MlnDHpTVPHUGf1GMVVOw5KxX2GiJvbYIC3liqBSzBYNWgZnYI09i8drSC5gLIaUYeAszXUR/OR3P W+7KpNVPzcLjGM35Ddz17w2Wi4KJ4QW9s0ypwVnZ7svF9744tLB2132/5dxnb81EU7wqsv9pneWZ BU5mjkfPr33eH//5PsOZahra6prwRsitmfxf4kaDrsUnv3tI4IFtYdZ23IABCYMekyttehmHnGxY 2xiYOUJSRwdvwetMLZ5F9b+/JhOklmphqKzPNShtPJRzYrMDzE46E8SCsmqmzh662MN2rNiT8TSS ocXCpQ+5PD311Q85vWsG8ojJf72Iw3E3Fdj9GB+8JmHtqXPb9+uIvMOrAbNjVWUw580gs2W/gQkH afwQBw/2lpO6UB+Rt+G4f5VxkWae4+XElsZPXpM+2W5S/1MO7W+L2jrdjhuA3NzELLVSAQXcffWH dGRTWe9lDTEmGD7rneS2W40FZe0zjVMqrDfAkvKFKFAypPw8A3rOCWb+eslj6ZTNMypgkx6+zbd2 ryhD+PQDjaFniJUJ8iiYg7OXYlDxJc8Ds1cIIIpmnr876GVa26UP+CPgc25XXAZr5N6mZxMHFqPx /kg41nx13I9kqlEL01lBJvHHqvn4fzfQh23ep0Rr4TMbY2q6LSlN5ceoACrYnNK8nKLp1aNI+UzT wbz07NsTmkhKw0ZZDgZEzRLrbqWyLGH93R+/T9bl9FuIITMfSQv34l7H9fp8csg3+cwe197eozfF juS6Xj/VuJYvWR9Qm3zee68RgjVz+X26bNN1A615Q/4YigN+YuSGMr0k7hS0JBp+bcrUn3ez8Yfa DAR5xygKrRxPTpH39z7tU7osScmO1qss7tlR/ITf7Tz0qAEhDt4DX0X4HG8I0m70OrxqT0FOz0oP 8cwHPrHl+EiH52XDp1T6nUNBKFc4xj3kgSVIOyYxRJjEEWVIHJXYhmFhvf2oh8ig7Q1YIFkTmUEa PjUnIzHip7oBW4UrYjHayIDtjSOPt89lshHQNhqL1vpqu6wmyEhcNj7M4eJt0vqPsC7VBQps3e3j DMFHp7sqHg49NReTZt7/Xw3MXK/SIUniu9dh1izBa4IpWza2o/TsVGCXb9tukaHz3IbHzjTnF3tf dI8R25To4DK7Er5ZWNlb1sM2mUI6xsP8KjWjjaS4LRI5KHbyXEC2v6IFzMUhidmfda1vVbcnCN5Z 0wDhRv3uftRKLGq6tJdDajro41a7nWXMxlRZTImHQ8x6/bdFtmwiZNOc82GTS6TOE/Puqit6VZOI TfXn/Z/hkx+hkf9AfjTlMrrV07dLsrj2ZXLrHineItB1mX/8coaOrKHa17KM/AhAFnCzoQGB15Bx Wt5TJot5TQWOFYV+SbiyZrUVpnrLJAfHTt6lv8jfsPLjngxpSRFy7+8UuJEndZ7CGe92lMd72/HH rF05a0W0RDYRsQVrLV1Z6MKKk0fv9GdPuZxz6Bt96ayRCwHS/L8cqb871o9ciWqPGCTmlyv5fiel zF51Z8QvOgxX5uCRy9br1l/AvA5XjBvR3wjUnRPhpMesQhPWiTAy7e01FGWt9xN8g2UEueEE4WV9 yjUETXH02gQ+N3JWjFhVNGO5bIp2dMxqlsu2sZCRHhrMF14ZkOPfbcms69i8d/BKoHDT7sJle7/e smLkL9x1chq+unMmakOQopf7Er3oFkUFvHogJJXAgCAJtU+JWRlnwsW8OUlkaW1QM3327KxLvgaf ZWcD5Yd7Uwk6j4+OoHkkQDPAhUxrhXi7UgV6XykwSQ2J6fVYWqICJdLWmnl5/fLdhas66sVTDkuV p2TKaXROh+qfvFf3HIh0mmXbWTn3q+rt8TT8mr7oGLu0XFbbfX1iDcQcWTjz5ro7kx0/OovWB9x5 1IUsN3T5FS19nNE7Y8E616lAtYaCbofe92yidOXudLl7dFZOTu1Ha5Oj0Xho5X0WFfhrtovZ1rbx vaWUI6QLs2wviQ1uE55x4/PyH6UpRu4OnzX1HBYnQlqljO9aRtEHS4ReO7Tvc/wkJQ4Upbz530Xz +c8UexCpop6iFI6HeN7flBYPKIjc1xy0HBsm6FDVUpN/KZDrTRLXEi59W9HIrPHg/O7DlybZ3JcL X25zgDFBa5unODGr0dcUW1W8tJftOYy7wMeSTcRs+ZiL/N0gC2U207MJdNZ3v+fkFo/6ZLvrDweQ XlCB98u16VRADO9VWcy12ey+vDo33LBJBZqgGcqP6xykWPAWK1MqYKe6YoSmRyKEEez50uODcy69 hdk7sL0DvfK+fdpmgOOgVsVWtB7J+4uQg8iq9pdF9yG5qIKw79LWtY59T82eTeilUpJ7odDdzzTa ThJhG2uo9w1lyiU25UuuYQruvztS4jyTc1p1d68xX+1t2/dq0qIqagvGYg8pa4fDTACjGCgCW6Zr aNw8dCLNNi3K4tq5h0wfgd3WIuvQCGNq9nYP8qR5J8Wm3PLjabLNgJxghtU8b8qdKVcWtPNg/vnS TQxLrsaV57npHNF15NbK54Tzha1fQKkHIv+yY8EEB3RX1XZVyiSDbc/vCMFikUb/6OFD/HGLWpWV a3h76bYR5tJiOr1XmfsirEPpPf25TI5fjOmDlCWz5depDcQvOxh2id2iAplkJIbN3li6BMQuRuwd p54zy2YTKspOIk/IPBzgOVARED7pbBQTzNY+TRmXuC/DlPvq6XkqkI0UXPhOBd44dHdFfEQRTqUf abZWscjA+hPxzylnwPzAhOB3AY7wXRrGJr+PsoflE+DieSLzlydfIjOmOt3DiqX90A2N8Pnl7c1s DD8fbdgmsmJzWTUPb03oVKJkr3i7WXhy+HqhNr3d52+W60O/MVKD2mzP/yaW8ugUDzKAlJJJm117 f77XX5KUzMQVNjD4vuAATZHBw8Jvhc8FItsrcrZShm/g0nou8BSQ4yJhx6Px3k9ltLVD9HPMR8+Q SnD8n53YS2Zdz6E9tXSzUL2r2yRbTlwU14HnH41edlJE3Xkxix0mTfsjw96SqvxE5bNmY/5II8LL M/wdzD5pZkjFNEw44S1E4SIP1SBvKSz/dM1pGf3No0GE0IcIy/w2urp4Sey78/wplGfEE8MEMkL8 IUH7m5S7gKERMhtUbDZcmMfKwQ1FhcXR1SR499z3Ry9GuGbAiNeA2uLvxWt236ry0/wAQpSp76iH Q0gUWGS8wqfvufe+r/5uq2B/Lc5+WVpEk0zqqMAgmMmBl+WD2hT59lZ4zl5NTq0AcagihbiwlKxR 6J1TcmvX3PqA+BO+/w77+f0vPYH4ZZvJTpdPqzQU4iYyeymD4/sTZEZ7sudp0+O8yPEyYZRk0aC1 bLSgiYbdpqVy22P/ADVefr9a83GHJT/hxENUwAL+dmNeeZLlq6i6oeAFfnRolWpvuiSuHYOZvnga FD+x/cZFp+55mnZClZknpPTDiuSJcEh93U1LF0aay5R2QoDIYtiabK6PH7KGjOb14XV5g012V7ix s8OL6seRhRXQJLqj3ZaJmbVphp+/5Q3UnqaHbX6loHS8njddbEujPX6Plwo8pQKfui6Up+f/eChI OZWAe9j0slA6B/4FQw4jUKYGPY6leu8yu5LboTynoRBADiNi8vsUaH5cQXMpo8t93D04j+/Zx+Cv +pS0cn5ibdeWxUGAKUWxddDZ6MULZPf1tfkcT9ap1mWNcLP32Y13VDdxVZ8yB/LkVdnwWTF+g5k7 k0GiHluWAQ0bBGStj0lvJhXY2Q2Nmw/9FlTkLcwqP0l2n+KK2x2PKJuRPWwLG1tPtt2kgsZn/UHl /GJFBV6hx/1SYp7NKtl9RSrE+SXNNvzXG8p91CnxwSR583DKwDw9ehGb1oxGMLtXi37dxdL1Z3VT Pw0E+ibmak8Z8ylnW1dCj3l3yCQr3PC9s818sfE78gghrHQ+XtzlUFvJYmVw2anc1dpWHvUbysGf L3yzpD2r6MYfw7ExB+Vk74O1Hx7MBUo2ubmz+AJoOyKmW9hEyEGQUTf+y53v7qVbPR1xuH5vjWav Y/0bmmsF9Srv8z6alhizL1jQMhujUsBEM8XAN2TWcfUb1hSu4zFdvfiy13QqpRpLYAkpm1t3N9GR 0Tlys4k3SpR1PoxPI0cGOOCwWQw97xz7aWDYrlNOU65fPr/Ko91ks60/UaO1t0rGA+G0tJT0LCGm Jpl32NHwk8hjDdTp47uAoMpFCBYZLvJh8+VEbBzIuN6YBCcnrfCyM3OvB+VS7lml5sd4Sr6Imrzp /dlQj7ddVU/73EHZ3atlry+mQcKDZsiNhV5d1gz/WjxDYtrZq0nxKdNd9zYbpCNr2Zct1vYWD+GB Q/PD/b0PMjEF1iM+Vqfuu90QtVzmy6VfKl3NvZPT/XrzvtQVu8mkOBmlcTd0Ge6yu2Tiq8/hpW6u gowKiJaw+8Taxjm7UIeNUZrboCh3nt1RdcxsfTzwYLEe6Wq9Ooh0Gjsu1GQjeWMoi2v/88G+B0c8 0obYe3oIaWMpd06lW7Bfgz+UAG1ePqhSGmnhICq93scDtRMVG+j9kn9uoPQF7xazpA6DldbBbv0b 9nbyLCZ7ymwPOHEfvdD9PWanpeW/QrQXI3I1dvZXDVVdnUIangzw6HDTdVkVM84033bu0zAef45o FLNW/H7CwNz3JVpbHFq18ZEp1d+epIwl9SjZb2Q3jkQuhdS9eKOWsWIimVsU6HRKS8CFHmGpLnh1 LT3cmQkCmipycmWn5eRoEKUy1jeDHJZIUizWejIfhrh5tU/xBNb9oN28wJvk1n3tut71y08dx55d a06vhbIv1jYMSFM6WcLPnq+7GJfc2qanc+PpsBxCQvH9F6u0tPSTx+eFPzZf09dS1OPlcMurnbpz 5FhI1Gf9R6DvE2crlkW7OGXWdPcpfOkvNW8eMMa7lGdkrxKjmREV0iOyXicsQoulHsZnpX6znLta mPMp4soufn1dxya2Mpxm59XQtYon347RcPMd6Tjamfj1/r7wMVePI+9KLfGQezUdC6s53JD5Qfxj 0huhk0+fq1XX8F5/8nyXQR5GjUtoCOW+nPdX40T/5olfdnztsjP2ScwcO55iIqDZEKSeWRf4aeh8 2aKUu8TSpODJXmBkQDsP8xjYUlUYKZ7R3IPa9G1IuUnoLcA/AEPnpPdH2Cs+sXfz8hiE2mujwX4T XoWbOAEqoOT0iQvXTkFO0uR1hQVTKqlADQ++rNEsxYPrRUR9N9Mzcsn5r3yA/0RmwEajHiU7OO3o F7trau0khBlRdBYNbQU3hSA5RUKA7yk5JQjuHgbDokeqAvomLPofqyXCNq+jk77buSeHbfqWXeTz Ud9SojAh5lorJzlr7Jv3tRPSMQqflgYlwIRbtSbbjibhI7SzbDAZ2YuLdPb1Y3Rk0I1lLjQQsHSn qBVvTuO2jhbhacCgw/9M/MyR+dTyGQmSpdcd1Q0SWYz8YGZ1sTn1pt/XSZZhqDq6xmJoXcmRuIiI Q+4NI4TsnVAYKpxPSqUCOWCgIvllLvRQgQG2TS/+l6xdhVbGYJYDgo6fPty1jHjwpO7z1sVg8PbP 4jpdPpfq3806ABmdnzY1qj9Cu+c0DFgwv3c78tB2l8JIMlHnl/WTfxmWQfT6AXVceqaGLRgloKDj aH+/9ftGg7GVzBM5X9XDse3vxO8T9RyFRp9/bXK8YJEw8YikRIKW2KQGbfuBaUiLUatDSiEVeCux bqRBBSL85kbeuo3EIrt9MuRKmMzdRr4MSTY5H7pozQQTPfca7VV8ICJdi67e6l1j+Rk6MDFgWKfb ZvW902x/r6oRL1VkiXdfa8+0zYupSZVjS8Fxzg32NRarsPPdu6rgyaF1MXzK1uWarpB2+sdoUa1t QbC8JOlDlfsyBoRi+0942tyb6OTDVHJUyKA0PQsZpBXQ3IoRi1pPXr9ecdxlu/Z583vR+GDpHo05 5hs37wW5Hea+BAJ7pybkjAGpUoHXQ9wo2UenJO8Cf/fg0uhQDDy7SHsU018ZLXbxtGzID6XgkI81 Gde1DiZ00amMtffMgLUjV3Wmw+rbY+SYycd8bZbEKvvLDeOyTrJ8JYknpwe7OHxYgPHqy4U59Ioa 4J/fCT29wPuF6WVGVuHOqieG9VPbz3yv4Pme11graHv0MN/Wd1RND3BwuHfRX0+uTy534nXddXL3 YB+w7SXIsWfgfYOJeQPk91VrkNPNK57TlNnmzZkrnnsNKkPCut/HfMZRmJw3sy3bixOeuneNbVUt PhZtW3gee1jlfurxmLDL0MOyoQgvT+w1ks1CSOsgeb3qtJ9NL4+HdGqjI8sPE/r9ohZS5zZKjG0F KWfCv11VM0zJV8u7p19xD8qdM4gTIuvVFFO0qJxscKp3c5nL+bYvraLo4b2eVkt83T195FXaC8+T Bgx84s/PSsaPpufIeJozQYlc8T2h1c6jc1GinfuEb0r5nOs4bXEcSOr4Muy2ph9ingHNQLJsa6It 5rEhaAEfvm+9vWSR/sExGlJRV79Xy4AJSek65HpUdSaFiNFjns3IALlo9+7Pfjak1iqJLe2jEYVN 6RNE9iwfZi/e09Y+Hw/dEy8K/TBkjPSB1oF2VyOrH8+0+IaNoAH0G+G6Fv2JdZSwTz6sLzbwNXo6 1Xsw404k18GPq646ZZJnJ8HcLgNS70A4XosTl9VCBUTtWbuatAykENdx2a6bEttWFfq7XzYVWyVe buh4PeN/qB0ftgIhlZxtPdI8PDq6VrsuY167f3lPRe+dCY5Qy2zCurUj65d2h/aDp5v5VMYTaxvE xMW5EuMufB+6F3gJ2gPOfTmkuLb9PZK7yn4RvhGwGlngzBdTnHaqqv2+nuW9+bsynF1ZSIGDcpH2 Rk++jduIfxB6eOqKwfc8aDQ6EymNaHQMxSNJM/APSH/c9PzHBcfcQfkzq1xOhjahbEfCMzLbDJZC MsXP7vWHOzYIW6vPJERwnHR742LMJ8007JNxAx9NmoQ2/m0xrzOPn6vCpH1a2t1q+lbsaX+MpgcY 3CoFxC62h/dFOml4n89//R49fFdddOBShwSEETCt2TJhgwimctX71gr6HkE1h/eIJtcEmpMXWD69 AuFOYKrf4pFIJ+V86fHDe5ou5msIxMWf3au29Hme08l9+QkqqvOY6lr7No8e/1T2SHgX6eDii7fF b3RPvveNW3qRkCwj9MPRN0TsFoe+wTZ+yKCVjvAxwhK2BSXeDMijODeKLoLpxtWXDRlruV85i5OS 2cVxI3oF3VHH3QtOHUB9FOxQiYDufYdFzbSS8qvkPMx10ottPHsc/cYev9fw65HttFlWaK5e8k26 EHLKosUq9+bsXd0XhqdOvHz18nNioC5TGc5QYhUzSQWu+GYvvDRyJPksLpX2k5FvPlyvK5Gu0vhc yXqrS11TjNGIyVgwrUFHx4BHZbXlwh2LT9Fd8r1lZ/RTD+wreiZd+jLwUO31itZzIRffM/2Yept/ hpQrsrMPEwL5PvkALAbVGjTWvta7xEtB8KzqcXTFRE85+Sxd5PcklusMMB2OaWcvlA6c6j6nJBWa 2rj4SPkoo9m5bQuGb6AXSvRc96fcQLNQJHw120hf8fdzPNrrdcLhbAse2DsOLNgu7v0Fp9aNScIr g3JKp4pkAt+xraqlUE7h2jSGk+sZZgwawEb+6K/Mj8KGTS70+3W/C4yLFhmgAs3oBx6cuhF7bEfP lcb2Q1ufR7foyWks8SbHlSUllAE0enho5F89e1IDTMlOSDzJzNxgTWkWeKmaLI/AtA60Cqo53nE5 xFD4EAjLhGY2r/mfZISvJEhMe6RiuZ1eIGGBJRNrah8tZHNjlJf39+s/rOVh36iEgJ+Dv/tyE1/5 uuT2/dsL/jZbng3vcBIujiV3ZSUt7b2KpZmnjpnCqwfkUyrPFrzoGD99bl9Zh0EpQ0JSqss5gqlP truVWeyQvM0POTZvD5QLNja/V94n5/RGvx/IL6vh+0jmJw1v7grE+WnYdXjPNdXoaHPeuGd9J5Qh QuVIZW9Zil8+FdhziWIYE+z1fck7tHlxKelh05RQ7Xg5wmujnvDFXeWyuyuva/Lsm8f30jV29zHr GKjSXz/RfSJEEQxKGWXJQ2+Hqk5xlHhQTNjeDnp9OHdj0dGVz4xTJeDEk88JV58KuzIbhEk5T82a h6pNvay96r6/7XOEsTdY9Uf5CbBqodlUGZUt/xf4mrX2KSPNTXPd4v39aEFZnaxOqS4fb1P9c90X 0ssuvng+n+88bntyPPX1pS+Zoo8NadQgh1uqE4w54e05DdNa0ibMamEUK2UHH3QYtIY0pURE5AUf URK6fsfZS5YppApzJChOh894zfyEfZJXCRgM8/zBIC6PfVHJN1Qe9LFs0MI3aNtqcPBAsgbLZoH/ mc08pyHzvqaaG6wKviqe0ieligzf2CbZzqUeiL8Jz0eWrjLqiJThVCmoqbbaOpK902u/Tk6TCayZ 5Vbb8BDxcUzBG/ni6EEb+SLp5cmbeyPUDdRlVm9qLM5Vv2AKatu+e1Na+zzIRNw8FRi7wnetL83H jm8laKbKZjxEtFvi+lo6KmX+08JAbOmLtMavr4fyvvfWsGqb5Wtk6HPGRx1Su/ZwIX4O9PhzG0zI zZTGkcIB+fYOYjNfJaHZ+4dm1CAxgIPuckQNu7q6yaNWywwzFzzfj8ff/LutpK7cr3BR0Y+PAPHA rGtHBcGoS92RSSj4ADJNMGwTQkp1E6o63F1pcznPRw7Qnrba8+OsbGZPLZ3F+YvQ+PlnZtXDT2nV 7fcLuokGch+5cmLsXB3Luet5AxShy/YXCBjQT/5ps+m/2gCdkYcKWNwq56EzedLy/XtvECftJe3I umyfVw5kvwCvyOjDy8NpFCcpyquNOY/2ymfWX5f4TX3DNrzTHJfw0eT2dI6+6xRFSiW6BxfM27o0 XLteFE5hU6YCgZuSDrxDz/l1COXoTz/gGX3uXVGIFUYqEIZPwfs8xYUkTwFC94nwhPV55RJM/H0t YxIF8WNOsbjoAfEzUgA2R8GQg8od9msEaKNWkJofl+rmJQ+wILsUzA6xVBZRgcb7E2F41BZGx0I+ 6Pb7C4+OPvGLCyGLB3S2HXe9uWGzpcJ7/YM7mgv3qpwluGEXvR5FrMqPaVnkJiqayMfLl6S65VYA W4RjkLk42ZpVN2bU2Kx5elKlBGzVHN4DAutqGkqWPFOKlIt3mvhyDRXYNcxNt3WRAs8mLhDPzp+Y 9rH8uDVBeba9wYbMBPE+/81qzcg5SrupHzaBH5J1EucIWOpQ0/4t+AIy22mL0otfmOtZdDRfetwp Qka92pjFbqIMenqQ0YbfqUBF331KPSbMW2ZXfOLmEWOXZtMstAQePRemHeohsl8pKLnzSlWMOW6U ChSRiGzuR91w/1bqlP6S8sCMvVwB7A5RKhAl7557PN1lsCnMxsKHiS6w/odQP+9ipU25dLGFvgNB 5djLQndn+62IDzccIg/Sr8RTFobF4K9xTXHF23YrIhOh+D7319UpDu5vGhba6gbPFQpHnskpp7Mc t90y1NkfkcgCG+yQMgSa1V3cr1/UsXQBQ5iqTikx7PYGTN+pambxM0WEKdcbw/B2yCTh2Ku352h5 hRW8a1M+vX7IYtpNW2trcUz0fC7oxTLvI8OrnapK8Hykaop7z5jLoTJYuHz2muZkttZoAcGFKHLb QobBHzOUi9qUi5YzkT8OMzv/UQcPem9ZKlD9QOGie5bIqPnAttzbmgkZES9SzHDluwE+1IDXVQXG FHjMt4YBnxm7OqOgIY4zftP8QaeCa5WEcipeCHlaA4+T/HrL9q7y6FmTblGBp3xL5mh875MGB/ni tZgxYSwGLlRGtO++ZrHyYGmpaF0uDp3l+cTE/KFfFJ+5Ocvz63z66U4GRnERSaFp0L4RV9oZ+rZL 0e+R6yrbDKX+J5exH2AnvSWKvG3i/U9uZJ2xzdNbNC8fwsdVN9wmPjbl/aHJ2LZgzyG+58SaXLDi ik5F8vXEvjD35Wi+9u/EICscWwN8Oog0S0xh6yL28GMGeE5NoOqpQNCg9q41Y7GaMhcqMGLKOIyJ LX2kssRa/+J9jINS+lWlXZ+e1uqufQDlYw+Pk2ZjH0CfgEdyNTgshJk1dJJb1w/npfjay38NS0XZ LiOXa2OO/+D78fJzp3EpbLl+rtGy8e3uG2uTJfSvQFhRB8aIqwsK+V+ogHgZK/aLwxDj4CImrLKh myco3TOLzU41eMjkZobMh2j6Boc2QcPQF0JRZ8XpOOgOsU3uTJC0hpgZRfbHGAm+2lV6mIx+/rkx XbbENFZrr+SdqH5A72zvxcc6szgmaELTUHUdvSi8AJ9CrNu41sEHDNFaPUs3ZbrgTYKYmEjbxRv6 lEu9ZW6DZOipztSE6ZQGEladCghJTOmsZWSf6InOVaBRWsWVnBARTb81GFvmMcStoq3o6UcOH4ww prOiJ0ObK77EfHXYDKJYotrpJmdazTJMY4ITFYR9fReqXs2lJ7876lpJPHrRcbxVI9VPN1PQothB zthbkxbZAKIfxJrfsBwqSRa7vbgp3qFuizNqCItACeAwZuNptO/DSofk9ArStu7U8ki1qhon0G1w QsNaZ5ErH0bC5krg0VlN2EVzGF0pRQlnvrQU277Ghey2LNr0p2g3JQ97meWH9wtKmvD0ODTtf1l7 KT722Y3424L7sl6CnbAnz0fJ0vcOqJ+8m4zME3EisAJn2HH/k06+VKCJ5VHO4QDHMYFG+6ZKKvB+ QK6s+O6Eoexh2dKzPNKSRqKX/MimEfounZCE4SS3QR/+bMrBI6QWDy77W6e5G4t1VHzvLS0FP2wf i48IOwFHjEq38hlu1+3WNX7v66F6RIhVTbCVB3rkQw7ajKmsON0jrLoVvWbD/KLBAf7ajGPIT0qi vpJY6LGhT1xLeTDjGTcweMEhVzlSeW8XW5FAaEWg9fe3zh+hnRVnr4JNoO+ZWkM02pTm8Tx+I8u7 aV9JZ/DhUwgJZfUWVUhou5rE2143n2b3Xm2aEpEBldn2fUIFivU9dSiSgx5UAPu4BVrInOBtgvSA 9pqvNj9BpEu9J5y06JC7UuPb/PCzxrNZHicxD9yI2wW+YRanhTC8sGyyRo8wZtUhZxwHUiwgSQRM Fn3Dx37HHEJHoWrEYrUil+FhMSKF5TPbQbhpGadl/szUEflsIVcnm1o9g4W0ZdG4rtbJe6vwr1MR mR9j+I6KcyZLSZ0FDQzk6DVKxdcIL7XmOsVVk1mJkU8aQUq6lus5euAaT4gM9g2ndeijrN8Shq7K exbmHuB7XuzqJkUupNdUj1xp5gxSs527feUR6IT6iIdNOyReBb7SMuSlAnbXMj6cjo6Icz/acZec 6fljFnryONOkymyTtQeLxl9bbpiTJ/LfS7Dcwq59WwwtGv4+6rL0LJPHzrPH47DhgNvmPZE9WzlC SKWdzWt9Kdaob67bPr56eO41EzQhgGmgwC+km0jHFjvIIReWN9k6vv/sYL7T6HWG/SnK+8/dU5et Sph1hHa+cuTzT4K/kpLVuHszGT51P/xp3IvJww/8ZScnXqrVujTr55PPg2onBA0zuJKeX3EgpVZx SBedVe0yuHvkzrXcxNhHlbHplvfnbxtet5Qhdd6nKCwMH9R5eVQaVAUOpOSDKY+QY/ji1SZpd2Vn pWvuyqN+iCtZsMnJUKRn2AIU4pAyKKIXFVgTpAJ1bxfDyPUL0DNpqmBxZr1bxQzwtZ4++a/hKI5V VT/fjYWL8G+E4oz3Abvw9PHZ52Xlm83YT3aMpTy2j9EUjD2zixTfejgHVJ8xynU3G2Us6llsbucg OluaA6EH1122VxC5W8XOrFq0ulur+OTEIHz4vZrteEJ178SpHsZ6dTXBN3uevqxWgnbr7eZHiokR yyXhKzGkLRuJ6KZuKw9EXXb024ucLhr4tLVzeL9wo4GcpReyFyOunj2Yb7/ocND5R/6usRfSgedE HdmHfRIiSU+lKYdR2+okpf23PtoME089mCk2OGvp3K6uoHN/K46QkpnSmh1i3fri/K2DEkJxSlv6 387nQN0pRFHKLs2hAlzw98s/FnYdvjccsq4zJTw0L1/4OkJRSz262n1kIH5QX1ev7m5OwY2Ts3db ukYF9yTo3U6XKS7DaaDxVzXd8kg8w/oxLikcBms3gyt8bPavPU6RQFyVU0jwmcAdzFQ3ik3IVMcd tYAHdgsk2YYflTqayJwHLYnxBEUvKuydPYa+svueZIHZKa01YupxirL+9UwHZdkNsotRx+TZ7bLz ExxSh4wlo/Rfjw2JOphc3H+i95zGyMKwlCMiBCav4IP0PiMfOVzONIpYq64WH6u15wtYRdxfsq8i LmdFDHBwdPnI+Dr6T3zk5ksqJDS4LVWEfzMctYiQjX9Vdn6POv/C8GHEZFgfksMTc2XLegB/G8wa 7280NGS9xbZ96TPRcV4WHSqPR5XlZ+goaaGWSGKOuipNFii4+rNEqfvCbxXmk+/sMb6AcF/O+uc/ KvZXP/ygtIsL2iF7MFD51f6pjvOLLw4HULIHOz1M2JWjk84ZBOjGPSiBr+qk5JV6xHi1GiODSGQe JaFw/exqbyGzzNWoU/P+xN1XdlEBOmT7dO0jJ2fUWaKXfe48Hd3SJgJvc7ncj3ADFoaHz/I/PGz+ ObvGgG0N1j6BwqFXFCYGHdWf8764RUbDwRtP+cy4H0XPtzcnUUb6kNe3YFg0L5G9b/F0/eijmiXo F8sydZzdVlMIVW1BfEn5rVykj+vk3QSKfNii6AEhYC/0xACrjty9bTfLIrJIf6cJGTdDObHoxFRn /iJL63K2Js0GbBE5Qn4mgGe6cpZkxsGKn2/Hip3ITIjngpkrFsM6SX5v0+jvp81ytGxNKIL1sGY0 nArKqrU6e1CqgNffC9odRWGpy89hVy9i02vjA64quOyaw1JxzAi3ktLTT4134Nkk6NHP+VrZhIkp 1sGkm4vfxMLh30OZ8n64CrtCY9jh0hQjTcv0UioQTAnfnO2sUd+7O3nfQaSSiwJ6zMlfsnQi/Dul v2NXrT9iFemUrUteSJH953uR/Xoiebv7sJn4xwypXmVJjWTVoOrVnn1CeyOujLqwd9bhocD9kX+J ouZuLD4xDBOER8OaFdrx3P0mmDPiNrkeHh0pPDEJuC0X41uPq9AXcod7l1Iy0p8mf2DeTk+M0PSG hiBg15FC/lRgW7DEmVtiOoRULScz1Ytw2Fup4MTwo1zmXkNn5Q2zV59QzZrSy/GhKpFHX2MPz+ke /FaVvQStvZmgXF3yK8/z3+cbPMCjya78aFDOaYLJ5XbOA18X+vgGy7uyAe6KWpraAJfahE6Xo+nw cyHoB7FuDlABMdRT5FmfjG0XX5klzHNYyykvklFWZCrxVOb6sKO0gcStzWXD5JhJiXs2XF573dYF x4qH+ViMQ6O6TfQVTYjQKiBQ4FPrpJyilBqW7n4/LLrcyYeE2r49tHlcTmYSdudHsoyzzlNjQxSs qKhHTDGYR+VemsVamoW55tCRMdBDXCENUAyQi9We1uzTqvXIVybosYYWEuthsYRXy/zo+s7lynJ0 0Ya+fl//VrGl/Q2bF3zfuty61LUj5rsPnk4thHaxnBWaQ0yO9d0Y2VhAhWNaVKedbvsOYciCr7n9 X/Vt4u/5BXdWIkve6Jx19F56t3fM08/s/EnVSJ3Bb/Vww8fQQJyzv60vQ/r27TX20SBfxQHbHMwY wtnQo7bkhUNiTLgc7dUqzbuGBg6bXicv9ml4P98qIdfaCmnd84K2Fp4Duy3W91jMdgBJexjF/Wnx fnfuMktrXjEXLl4+gZVyU6qfJ5ot7hBm+UmEMotzagRK9fUB20YYtONlwmbBGbbirSrM4Jq+38To mYPnJU2Sz1dt3J7r5C1M3nVjPOleXfKBt/rhNE6HRKD1fs8k1i/jTSIot+DsOEz9Xk9b/niz/g99 24tFCzyXxUisXI42c66b51MGXCpsTYQvO5SkR7A/2O7YDXmmy3EkfEKhnNy4ts0YZS47LdK6181D IilGkOPA1wdb07QspaGtmee0v3dVVD8+Gan2uXFXhUxJCSjdMuRJnanCAirwhqmhouHqLZlY1bvW nuaUZuxwf+V80RCPtvd8Y+oZHsS9DioAhKobRlxk/T547tCYgEzqwXhLy2OQOwwaN1pbgHNR7viO basqD5wjljv4Ng6ZeLoYbiYO6oqZOEk+s6+yTos5b9V986zUhe30g7K2SuKo+Mcg2hHmCdsW9TTS 2FKhYKhAs85MDwlv8GjJ9MNgQi7hXvEdh7ja+YrQxdSkwL1x2Nprk+e6x1ycDIWjgk0PpwndcoOM PMGBhAZz3NAWPKICRwX8nZZHMKiTCje30INK6CqlLT8WVviF6yEaGt7Xi7YCJfgZGOG7Xh+8VndY UDp1XFdNhmnYJxUOR0cV9W37VBHWJ+GGOHMyHrXWnpxql1OJxJhpTdgmDrobZEtpN4+8zQibKIho PsL6JLrjXN8QDRiFPecxk9jBQWJZWWcF/O1MK8vUunVGQt59a9mYtKP9p93h18dkpE4pC8Mf2Ehn XlxnmXn3KfHuy0h5dBMdFbjLAUYwWNj0jZV0JxR6H5F5fMPsKeVFr/8daSkfJ7WtAvnA1zU2WDUZ ScuJAfcDNbwb6+8NDCKNFjOOF0aCPa8Eu0vyj8ypEnaCvQxyKxL3m/juExNfv3XoWQbmkKvZ7dgF r+LH481v05JXrXwDWQyDSH3S0CYX3++vzIyzMo/PVI+k4t1LXQ+aVT7pl0e+W7Cv9zzx9NA9+YnA oRvyNVFD5274mt7uiGYxCG6Zc+auyE6ryoLSp/R8NlK0gj7JPWv4EGyqn9QmpzNOBRqGF0pdtt3n Qmq6iXq5K2SPdxql8+lU4MeIznGB9AbLqx1NG58JBkejGJpSoXHDHOQUjlRYVjNqxklpvLYc2zps NjjodWFdvgZDDtdRZKQCmBspaY/vzp7ZeH0wMIwrv6q3PnPv2bxtQdEW43BYGc7wvlrZiXEl7mA1 q9Ubl+usb48/OxmPP0o+08d2aeeX48SmSOhIEG9uMa3DIvMTE3lEJgKNJkh+12JuHj2bt3yx7fKZ smg/rzcZ+8X2LD+OjxPyiFQdNQVT7yBYLIorZjqsjn8V38i6Lu/v4+SgVBz9IGuYe+ZLo3KZR9zY 1ZKBTTZenghDB3T8Bc34NCcdLqhROtd84XFBo3zwrxMVselMde+xIc0DzEWWZz81uvtPLdgM2wWI jSdFnM9DOQt0z65FMdaGL1d25I/q1GVvaVYd30ip9/JUx6y5LbdlDDJXTlaDECG99X1l47t2gzN1 H29r7rpwvPphy51wM0oyFMnovAO2keo9iBb4ZHs7tw9Lfo5vyLxCzgJNt6TD+dWuGI3o7Fw5GJvU zelr5Qbkbum2nlcc16zdZTaCQdOVmGb64lWlT0rCy6wdk+NPsFJeQRXgPC2pgPutge+TyA7RGDR3 Tpp/y7RVOKuCBnzZIr7l08tjj4oTEaDhqa8hxts1SXWzw2OrxEn+1gCPzXpcoPDner+W16X2rNrh PSkcJR4jHmxrLeLT1UYB8lKmwrMt376Oe6qCkS1VNnibY4yA8bIvW8KuE6cxbu5suj36kwTPT0T2 3LR0b6LVFBV40ju6RbbWiD3i7dfM2ZvUKHldj1x48MTZI50fDw2CPKSt9m67uqPqMY8vIB7GePo6 tfb3bGeiBmLEM9yXGaqVyns5hjgGIzLut7OocHGH1DUYaJdHdcAGc0LpS7puxAz7fMoYl6irfLfS OaFzk3Rr4UPRSru9f1r9TC6Ppwj63njr8uEy0zjXCyUpF05WuJ0Wu3IC8T781uErZRyXeF3BfmMf Q35tK8MrqWL0/exKfE7B2Xxx5ttYre+DRMmQtu4JT5VFU8+h6/bY3KTQaFhxb/XI+ZPuV9s4JzRi wOh0tcoAeRQdBBeRM7rvGXrqyDCK1wfp2ylqMuFDslncM5KTObLf60jEyaV2RXq7pzEX6LyQ3udr U5aPiWammgz7ZBzWeVlpa7aaFwwa352xdJ/IjLvSyox1TbpbsVoK4+3LvuLyR4xd5IIkrx1Nymjf bWvoHntVh3e1QTjRjgPsgnfoWV54yIOtRnv5yjXEDD/dRLJ1fOqUwoXb5VUPypp8OdzCjmn3shtE vk+pbpR6Fsilm/7RT6FqYdic7bIb3JBkvaAV3OF3JD/Ng83Ifu8xheFBHicutYWQAD4dPiU6qRQO p3cRxt0zWZ+NpLg6WFPMwJyPNe6fwTH0L7869CcMDj2j5l4d/0FNgoLZefJDfTH5e7VV0PKPJDDj NKWjDEGxOjDM0nLu/MFbVOCzKpGmjvymMwHGLe+NTBhc0NyAo+bll2ONGrRfH9wYP4PcwqwqtHgr 9kKPlyivUIEqdLFb6DPKhw3u5dDkgfK3yDcTd9G9ZwbJs8RPiLdz+fbd47J70xRE3Vv51I7obBZz UQGfDrZKfz8n3D4qYETm+N5d5MHaM6A/cPrtPV5jwchDsAX/vAewBZ+yV5JXN6369yNZTMgIhWiF wVlcGv//2CoY6ETASFMfXrup3wSdXXxFKsrE1XepZaRpaN94nsOLbyzF5fddbudVySYdibA9Gt6t RqDbkBYAtYybdA3f3o1mKxO87es2d8++EHbD/Skngr3oRP47o9YpyzCRUkm5sFM4rwu0lUrSrpK6 Tbv4zx0RPQfhr3pBpms1s06UFTWwzRDnU//vuf7fdAL9y29B/PPlKIo9SAzyW+XHj3Ncz4Zdf34Z CUi5qDKPKIw9sUMsuGEDV1W5sUpAZmxtLkO/K4xNCeskI4qzvZHdyAqYf3uKPqFgA1qEuzCC2kRg mTD5c71VmfLwbqJsFNYM8d9BGv/hE788jvXfYR3w/2EnflmZ/9+Gp/9zTlD7gf+Wr7vg+8r/JA0q +LKiBYCDO99o/kP1/PXrCcApRMMlRKNuDfFB88ab5ogHQHeXRqqHAaChS2EAP2lo6YoPgp+0dHTT ewQ9AJoUBkEPGtrig4IetOAZWUNmgPaNK3BwC6TAIU1zaIsOAP5Z8XM9jAANAx0fsHOwh84VuL1F 503j+Fdc0P49F7Gwv9UeC/s36o2F/ZP6uGj+56ULfG+c99oua9v/8jGQDmimMYOSBrjA9zHwrQ3Y AlaAPeAKXAM/3cC3C4AAFAFH4M7OsSv43xG4BCgD7uA3J8AZ/C4JnAbEAQfwmxv4aQl+OoCURv+u FmPwnANwG6RvD97nBMj+/7Cu/3Q3/H/1/Z9dHxn4X2RGdH+h+C8ByCu6gX/OoNJLgH+eO3/iO+rv BliDR06ggtuAV2xBVf5pCI4718RAU3ABjcYaPHYFr//tm9gfpcXAK7agGTiDpmQFfnMG77H6zXgs d86c2TEaN+AB+AaA3f+rfMhfNf7tf7zxt8G73MBzt8EzYiAlp51v1oAX+O00cPYXQbD/JwUR/79Z EM7g0Z2d+6x36oFcsduOSM78IhKG/6RIXv/HRfLTMCzBO53BTzHw24O/EMIm8B8UwpP/sBBcftME qNGSvzQa959sdOB/uNGW4Le/NfvXvt7+Tzb72X+42dYgcHLbAU9W/9Bwpv+kpb/5Dzfcc4cK5Oh+ OkJLwA78b/ObGKT+b3F4v4rh773+uf9bdMH6t4wDovKPYjj9f4su/L0Y3HfQ4T8KwRX4nxfCrr8S wi7wvRt8q4Es3AZZ1v8t+gIgK/8Lq9wDvlVASUIw8Pcqz/zvqPQseE75f2X6fg74Zxr1M3V23Emb LXb0wGoHFdrvoMOfWcLftM1gJ3dQBI+huGEFlrLa0T/xHeoOYKl/1Oa7/8G6/7/X/8jrIKj1BwAa 4APAtuOPfr4uAsClVSot+Ln3j3OMgPYfTtJ+5zuYKiU+APYBCDUaege13btcwbeb2m76ewDNTul7 v5Te/YeBQ17LBhDYsTZ+sGZGIRomIZo9wgCzyi6ApR5M1OOP0R4ECV8SBmCA1K5HShpCgI4GLXAd fP9WFT1YFT1UFWg2tJf2A7Tg57+qCzIydvAuJiFgjzANVBH7TgU0AD2gpCEAlqa7dOS/pCIJnt0H SmmPMO1PEhdBErRMP3nkBUUG0F86A1K59C+pQPa4F6x3jzAds8pukALdbxQOQXJnuKQI/Fnu/0hB aocCA0iB/icFeqgVnIApwHiJBixt+kvpvf9QWhoQBa1GGrzGBvYhIyR6hp9kGABuiJPLJ/dBzPwu ckjM7qD30gWYdqjr/kveZADI6zD9pMsI0d3p0sA9IH1GgPUnfdrfaV8Ddu3QvPYvaZ7f6b1dP2ky QTR/qgcT2IIdyXH+wSxIafe/QfHCDsXdPynu+hvFXb9T/FvzQZ1QvLRG/QTpxh9D25zgNyswWt4G 4wUUPQXA+m7vRFubnf/OoIQFdly9404oAwBDwPbSOjUf/Pwblb1gELgNej/I9wn8nXUJANBAFhc0 ePXbYBXw+2CVPTRYBYBtZAbvOw7YXdqgfgU//zbwzrRDSwC4CrbXdad+2t+kYQzAQOmsgZ+/2vXv 0oEwAADaHNvPPvssTMueCADCd+hpAJpr9VAAo9LTgLUcgGT0u3xMdz0yBz/0AQFI7jT6f6L8e7D7 SZkHtJ7fKQvtUNX+L6ia7niIAzSmf5Ka0s7w7u8xQOAXyMAH7AfohOhY6lkB+hcMKgcuc+XwQGUO Jq4At4XowLK/V2CnNkkvDpy4FA8coRH/hWfmnZ60+a1H3MFaLH7jHgrdFB0a4CyNyi/30wKXdzzZ IVCfwJrZnsjQ7n/SSDYHP2+Bn2ClbH9hSRCdyzS6f6oXwlsCIDUnsCe8fmkTI+ijDyYOgdL7VdF/ dYIQzXMgzVWqLs25P/EGB/9AAAtwAGeEgL956j9KyoKlrtPo0sj+UophpxT8N6/JAOo6aCV/YRcK gAgQD9ynUfilb/b/Q9/o7tiJ1U7c/hnVgR2fuw/UQUgKj2l+1cVdoF0pgzTUAT3wrQP2AGRrhyDJ 7gQImh07BdsCyvUQxJHCSZpf3MlvwijboRxBU/YnXVQE6er/QdUf9HUgVQYhGsbfgg8dqJtMNHdp aCSZvrA9kWTa/0SABLn4g+Bb6A4jDSPNMeg/vfDOscjOMcgJqMJUiD6owjq/H9ID1/529vrfzpqD ZG+BZEHuOX56Qsa/142XIO/hNPE0L3/hnR7UCKcdjA+A78PADru0P03pLg0j2xN9mv1PPlMgJpl3 mGTeYZJ5h0lmesjIHv7B4c/DHQ5/P3v9b2fNQVq3QFpglLt8khn0vBSdTzR5NOf/1EfaOzYNRc3f udoNaucOV/TATklGMILp7Pjhi3+KRdq/eQOBv/PIEDTmBX5K+wH4zWVHm8dpXP6kl4o7vlZtx96O gbb+e88xgiVXdkqKgXBAqx6C2dSWlhao1PGfct79U3XpQVnT/2EFziA8fQj8ags0wPifbGH3b3X+ PfLh38EPu/4wBvOdsms05n+yaJWd6SnIDrR2Esvf/eAR0MeygDKnzWKsZaUF2J7UgMomj4ecrTl4 fAs8Bkv/4gqBn7zR0sr+SSsu70Sfn95H4Kf8mUDC9DTn6UGi32nNwTcAehWo7AHa03+yhp9l7Xey QqidR36WZ4CuXgIMIL9I+/c4xmsHs7vsYHRHwA48ywHI7HqocBLscVq9kw9vHAec70oCVMg38IG9 f5b2V9/A8kc0cPxDC/7m5fYAgr/0/7WfHpL22p+8mT7IAxiPACHQcml+Wu7PIgWAlBAgIwScFwIu XKEF1CD/QMP8azwBTgJ7d/TxJMDyS5xU/21S8cFv6I52Z7IT8kyrNBa0f/ZMPzVBH2y7247cIH8q DHECqQLENlgnH1Sn7K5Hl57xAz9h6//D3rWAV1Vd6XXuOy9yL0gIT6/I8JLEJIICfZBIhCAgkUTA FuGG5GKuTXJDEgwqrVeNVqtVxEcVrUVrfSKCMr6GVlQ647QzjjOO/ew3tuJ8OkMd68R3mQKZf629 z8nJfSS50CKtd99vnde++9977bP22mvvs84+SuKkO0Pb4PZkGG0Oe3vKRjuKyPRzkzwGbdZS4oF+ HXb/ZNGWQ2kLUr5tXOnY0qc9zUNZkqdeCcmHfhvSdRNEYRdxd5sP3YCta6IcT5Jj6IY777yTXEo3 qEPRDebVc3uvXgCsVcCC9sqVMpk9yUVKOvvY+y7UVyt+LJ1n0BS7lZ8NGc02Wn2O3d7QJI8jv2s3 xL9SxP8EMamRC6Jwyex1uCKdqEhYPdzSbnZwi0vMi/urabjDppXPGXkcIWdoEuqgyxno2giFvovN /lU4DeHUL9a/1YrPdkjffK+jr5Vr4rOEnIKf2P/ZvS1tNNTvu4eVGEzmIcEqXArhkty7MWhPE9Ge XuD2ZMne0CStIVlf6aSqqQbk/k7YQf/mqKJcd+/dP1OPmKOiZeytyUFFsBq4lzUlkMWvDufzaBnK 8rYDNozLRApIWRRSJzAakrb1XJLONre1MQatuYnCbEk6NtnqKYB0tdB1i8QebhNueqfVOgSZ6CsY z+f9fRn5b3VO9u7Orh7yTmDD8NyRW8dMD7588spJ3VO7igvLts0on0VxgQWEWIu7qRp0LmgVyJTC aXQ4eh8ZzmlSohu+NU3aVpPY5WzPrZYSbND2OIfHCpgr3B5SviXqvvDIgNDLkmgbfg5zNeg6ED+0 3AP6APS/oI9JPTW9EnQV6DbQs6DnQC+CsqB3skGjQctAy0H1oAYQ+7G0gS4GdYJioDLI90m4K1NB n4E24V5/DcPsT0F3e1FQ2AdvgdqyiGrRyXkxAHgUdD6Y+B/Q+8x4HtHlQ4ja82HjgK4DPQh6CPQI 6DFQwA8+QZMDRFNA60BtoM/A/AEw3zQcfIIeQf1sL1B8TyzRlRbTpE847sQUcQ8nxJniv/WI4+7k XXyc62gw+ytn/zwcP2U5nnjIYKbCvIM8wbFJ24pqY+P6aWOp4xjT+BNjxvOQiTu6OL5HjiRxR3vf nYPH9MmZkXacCob7MqPE5M8gu5dnk7e/uE3lRPnxmH+QE0nniEt3x/irqbxmgqTzJ09n5Nnyc9jS dZR+4pXe3EzXN0i6ZPltQzp7nIkJM0byo3L05iU70as2otdcbYPsW5a+vF/RT1x/6WKG3I44HjZs fjrby0MW+nLYKDtAT6Zpqzx6VPYK9aPXg0ccl7o/OFLM/srZPw/HT1mOJx4ymKkwj629MrBNkrFX jlVcKnslxX1Q9sMAcUnslf7S0dHF5SexEVR+Nd4/R9yW8tR2zkDpUtg5/abbPEB+CbaMLd3kFOm2 JItToZ84o08542yZ5PxRIn99013t5Tn8vjbQ1VQZbMoxbSCWJI8mdh/KtdFFmq4A4C9ATqTweNWf RwP4U9gee2FD7DwBNk4h0a4xsDnG8XwuP20iGknKtuJHh7hMJ5JK+wHq8NkshREGncT2DDB2jlDp ASl2Gb+fBJNEvG8AT4CnsRpj2zhlv7Hdxq++rAVdzHmgnN8AXW4ou2oh7Kob3cq++i/QVzzKzrod 9LG2t84DT1u8yu76GPR1n7K/bgL9RtthpShva5ayx34OWpqt7LLtIHeOss9CoIe1neYGT8tzlb32 BOh3uWqebNj82yYIrTihZ3iXbXtDwpU0tjAExci+UN+x74CeAu0GvQT6OeiXoF+B3gD9Bymr9juo pZdRSzmomTmgWtTGN0EXgOpBLaBWj7rrw5z/3nPbDbKNDTuplrejZKuuq9LYrsPo7FZzhJ5uLpsj V0kbd4pma3Jocop0GN0817iUvN0TsHe7mz9tevGeSdff9d77P77lrnFbT+yh2T9U/y8pV7JcTuM+ ZGlTc449FIvF2NPab+STo7vQwZXi6/bpDBw+dtVwdjNCPrm6J0shsrr9lBgclC3puLnzTDH/fx/2 T7jUdUO7odVTTvcOHF6O9thFrgpmyv3CKlIPBDFUeKkY2+edQQpRNUXEJVA5DAdlQpgnm9vEUavd muQ1nSuWUwXSzMPRAnn4xa4IS2gxrvIj5RJ524KdzEtlQt2NovporZ5+5f09SyGStUTm3ryujvzd LjJVRcA6jufT8VfCJ8XxSSwgmzlaC4joTZcSkBJKQ0BcvQJyJrFO0gLCOUE/1qDiWPc9b3Bev5S8 ewyWK5eT9e0cpyF59xaNNS9rXG5zXP2XQW2+CXZ2TsJoDqLbIbJv6Jh9OmaXFdPTw0hZqMJFdBZG 2YtQrefQQlSfL8E5NCuJ72bitTLRsjxq5BHiaD06JOptw9y8OkGt+M/n+M/D+j89Pcyjh577Xpb8 e+O8breH/k6fTf/N+zjbjTOug2n3foizn0qcgzb6P8HZz/TZwcgHOHtep2sY8tUcD+3RZ/f7T8fZ C/rsHTl7UWNOCJyec8CmaHh0zqPkMMrZg+7DM0xRLz/qz+rvTrmi7otbth7ZeiVWmoe6lw5Fk0G3 56tacAN1iKZkteUiJTeMyHg+fW2ZvjY1tr6tZXZ7fWO4ua69qDlS3xZtj67tKKqPNs+Orl0bqQ/P bm+ua+voqLuwPTtWHW5rj7acU9ccLow1dnS0zj711M7OzmIrWTGSzdQ5pIPsijXUdYQpNlOXMr20 cyMdl1BsFinLIp207lhrU109MkZjEP3CVeKKlZWUTHfEykqN2OnOWGXdJe7Y4mhLR6Mrdn64jjtm nZM2bSSRuXVJrZsP/Zz6bph9UWJaDnuod/6H53n+Fe359SG9cyzmPAvTo5p4zmW7nnfZqededoFe AX2Yr+ZgVoMaQC2gdtAVoFMhM0tBB9F6PJCXHNBI21yMF2X3orxeWEFelNklZ+Y+kcyf/dhhcfV7 G1dHwk0qLq70J3IwKikX/XOgfqf1OVKlN+fqrrNxwPNv5tzbcj2/Zs6tmfNk7fl9OX04CbfbBsHx YdCkgJpHu6JAaTqTO7fFn3nUlxwihSbXziR8u+Wq2+I23fvSW8+pahcaq4dbhB89Qpt4PFxK/Bbj 2+h6p5HynvyW+I4P9j8LqFG8L4PosIuxnY+OPyLPitdLWrYfIpX7vKF/+Oyznnz+cf14UBaftLjK Ydmjx3w6b88pFB8MOjT+1hkvv3vpRyeRStn789P7tS0VwfLNPzVEU9vjiCZO+0XFwV+9UjgyGWZk S+01q7ZtiUfkdPfkRup/dmDbc4VJ0v1t8eORp/7xk1vHJpQFdnbtxkvGT927aQpNpVPiyrLswprL gp0fbAom4cGtseODEwXI7/qDEejyHR7O7ml/MDyrcB7CeXSyCEexFhHDmZjYQOKQM9C19aAkDjmR OOQM4RyJnZLY0LkaTndCcnalmukKdL38R0k+04XkM10hnCO5Wyfn/C0IbzyEExB+d6Cr+/8Ewu8G hN8dwjkgvDaIYpSnFyYrDoa9QvYDplDB7GeY/YApZJisOJhiCLgNKsdes06/G1A7sgNdKw6uwj6E PSByk0AUg8XiPkB5fcrkAdBDuVbt7POjTA/l6toZkhLQEw+abwf1AnTrkEDXTAW6YxhAtw4J4Ryg /n5BvQnAARuwD8D7/IGukKrBWAGA9/lDOAfw0AGBfRp8RLyQIeSIkO7xBLr2KSGF3l+F8xDOl5zt oXNByMSgmd0CYTOjGw07xKuOQNcdCuJVh4e97UI4X3K2AQhDQTw9AMRWtwWxlYVkq1tBeAHhVRBR xcimVBCtPgui1QeIVp+C8AHCpyAe7O4fojzHgijPAUR5TipGUkL4h1gQ/iHcaIakzQjfbg0hwsm3 O01GdgyzIEQUdwxLm5FYgQUhQhcrSJuR6pEWRPVIQFSPTMKIUj1HqELNdpOYOKNCMypUA//ZVWij Ycl5Iwtpo6HkPAtynqXk/L3u/k2FMGTtLsV4mGUtDFm764+SlPqRck76ms9K+hrrvdd8OunAUs7J K/Ks5BV5SF6Rp5MPTsoZ4vGABfF4ABCPBzTE4KWcYcYWWDBj+R6NLdAwg5DyOKjrR1lQ148C1PWj NFROitudWtYZbnrQkp7pQcBND2rpyUsBx9KTWtIZ8r4JFuR9EwB53wQNmd8PJAtkajmX7meKBeuf wgpnioYNDADLcn5kUm7T5m9069IlQKjS7QBEte6WGGIHIKoPDyjlrMvLYWPsOaS6ZrYxymFj7Dk0 aF3OJkrJob4mSsmhtHR5yt4kPV3eDRi/gulmmG7A+A+mLeWsy2NQGjEl5TFWGjEojdiRSbmnv87q yKTcq806LY6WWXeUUs7avAQ266sHBLbEA9gS2KyvHkhDyp3yCnr8XTatyE2f97UiN30udaqc38Py qkREXpXImCDHwARx+ZKpE3fKcYcYhx6a8pdsaqQcJ7FAaJYtgUjTsPd5LQifFxA+b9qG/RtZFsQb WYB4IyvtEQqbjxrioVxtPqbJyIZ8C2JDPiA25KfNSNVQC6JqKCCqhqbNSOFwC6JwOCAKh6fNyP4R FsT+Edy2RqTNyDOjLIhn2OB5ZlQSRljn8QwZ2QLPptnPeebNfs6ze33+P/7WGfZznlWzn/Nsmf2c Z/ns5zyTaD/nmTf7ec+gQ6IGNxHMmKH02+33vTYQjj3tUHpgge9hJ2W53CADlOxYPVHK8nlkjQOO sY58buuaOuL/MvHzoXd1Lqz7+b2c/Pn1dMOGp6km9E8699T+rHY/1iP1W03mV8rz4ubzLdLldBi9 dM+f6Ph2La5GEuopX7myemHN8iXLSmetXFizpLqqsmRG0YzK08pK6ZxwyYzZ1BlpaW+NRptoRbgt uiFYGa1f3xxu6QjOxaYtHJx+WlmwuoZW4ldNC6mGltMSWkalNAtX+HwJrldRpSxuVQSqpNOoTN7J swfD5XC/SU+5anq4XFfSe9lRXwPxO98rHNxTr3BwL7kohdwdWTBsewclM51VqF66YNl/JvfnPqqg Zsr9k/jH+96YvY5UaUxb5yPDTysXOqlxbu8jeiMJB4fm3JFvtske/Oz/SPb/TPjrDB/hVs9asXQF C1ZpyYoVA/2f30EuEPEY4eR9obMY26FyxZDHyhtk2yTbsFzvdM7DXtbJpRtl22iwD9qF8p+IXLlI tq1yZZ0ct8l2s2xvke2tEpsn22a5cp1sT5DtcONKUnoNrUG2LtnmyzYgW79sb5Dt92V7qTOE/UZp V9+WLXvIJWvUqa4XJLmmwuaUMV9kyGjk9ENGI2fCsQoZjfxl08jOmCF+NEwls/blcmt/UE+O8L68 a89lDnP6gR2e97CPSDkPq7h+vHSeLIPQIksktJBbFneJyFJN/A9fkiwNnZYDD7ccpruv7ZiV0fyC TTxYcHicbpfb4XR9dzYF7Tg9Wi/V6uU92oldWcIoBy8ZEZXlFVoQPwM4DnK7DYfh9TisWTG7F2iM NzUoMy9rFZXFbE6bKLnneFwODilzrxB+1QI4FTqN24MUTqSJU9A/ovg0XGJeiKFN6g9ltXIF0y4g XEoncfl8Vq6G5rmOGjWPRAuQKmYrqx7J/m6OlWpOQr583yLyRYgG8epdDP6JVntQV/mG4TFUSFVX i2VpDXYqVQtiBJE6Kguos4PQN2Spt7WyBAv7BK+RhS44Zs4M4c/rzHI43A4X8xfsy5/a83JZ66W0 vNiGeV/Z3V/uJcWFhPIt1zmbCylx3rOUHDghB+4sj9eZOm0YJbanHM9zmL5rC6n7Vcd/u9RMyyuP XTOx/YVrrul4csMDXvo6qeH20jzTodRFV/nHJFwdozNadzJ1+7vi2ciEwYWfePZ4d9Eu3K6h0/kG jpQFVNg57N58RUcTehttbtlV6/g+vfVWwnS+LVRJN+nr7kHfwg3tHZdMW12einiKp4e9lRHWoI3M FqOYNcBaveBrO66sA0/t4i1fgjP1rKFJWmydOO+ppW0q5awO/1gscYzSLkgduFYrS8K2ymIvHRpX eeIXJcQVybKIdeLix9g1gtthW1S2yPLeL5VPZPDy6A2iA3wJaIE4tGASPA5OXZ7BuB0mBl4ylJ0f lemaizaWK0s6OmUhUV4KNBfxuWh5uShjLmXZFuUZIBzuIfHwjA/c9vdd/aOPDixp9D96s49OmfTk r9kO2G2o+TqOv0ML0VZSlvguUnN+r5LyWH5TF3s/Ke/kT0jNs002lM9ypcaqNhRrTQbJI7wNhnqb oMsQF1hiVcreFXcbJA/Q7jeUNttmqHnDXYYqBwskv7PA2LXh5tYm9gFHFfM1zmdRpC7SHm0J1nQg gufRcFvH6TIvWVwhx6Lzkhyfov5TZOIWaTALq6ispKSstLSktLgh2kFRTsNPSBY01q0JVhQH56+P tF24PtJOSDNO19sZVLeGj9nGWmz6lQeXR9sagqUlxSVqYaJPzn6Y60yOr32n87eNLxlyPH3yivwV e9Xxmf8y/tfn7zVM73DeszrmPavk/hp1JmRCJmRCJmRCJmRCJmRCJmRCJnw5Qqrxv7xJ/vo/v353 8Wj/LT/A+H/age2VuOaOv6adWfLUjlpJjdF5FW8eV/PcH88F8NdOeS6Av2/F4+K7Sflc309qzL+N 1Jie5xB4TM8rgPAzhr2ksNlTiOcE3qa+Y31z7C5j3K+qsS5PPvLeq/c8Ucb7y/zZZLoTp9qP8ys+ +swh5PpVpuM0E7WRjqaw9TI2+XLNd7B55XJ10afnJPjZi/g95aiy3pqj6mNrjoLam6PK+U6Omhs5 qM8dmt/V1QsqV1ctWnDOwhrB4bmC1RUNVdH6peGLI+HOuZfUN4UXVAo219/qc8KdthjJi+dOVp/V XBdpqlm/5qJwfYfknCdI6zsao20SJ9kWxl2sjLSjCi7hN/SleDz3uFrhR1ourI1Gm9prGqOdLUta 6sPWfanAvoPXmdH1P5pGyX4y9c5FmG+189o6Z9Px+c2zE6n3KTiXtwOl5P3fpOBj4RfMR+pP2CXy UkUXyH78cXJPBvtNwng+TqKZehWe4+OeDP4Tk4m8FAPDrr/ieak85vKV+juh8WU/A2mdWkEkK/vc Y1z21J92TSz7chor+4IUZT/zGJc91bd448s9Fr0W74cdJ214sB9SjufDh16T9/4UfJx7zPk4km9k J/J1OvLjfV4KvhZ9wXz19xH0eF6C0LS8z07BS9Ux5iVMF1uP65r0d84G6itW6rWRvCl4mPcFtRfz ax9F8rgxdflXoeTmGkzJys+r0DXLw0i2CqLg4RzJuwl5VEsZuLyrYZ+16K+9qbzL6SzR8uqbnKdJ GZpFNorFcaI5SVlCWrbzU5TlWH51NL5sz/5+yTDr+R2MVT4eqQ4j7eGGYNn0mUtLSoNFwRVzK6qD i2oIufF/2DurprGuLdoyr3xttKkp2lnXyitQEf4zTvOq4oPz2iINzXUt1Grlg+uUCZnwFxZMb99U a7vxuJZ1Po+P9ZJUMp7ktsD9NY/lzfd3zHVP2Y4y1z61r6VqroNqrqkaJBKvLx6DnAzi1TN5bDUR xO6/PF6cQvztLvX8nfVbEbGdTNAMyi+RPaf5u0+8xCLrHH5Ji79tyt8h5dXfeBW32cRfHZLpAfoa kTgxsaNYOamxKtt3bJ+yfX0WqX5gPqk+bQEpO4rHEdxfLwbx9wOXkBrrs22ylEicyni8ex6ptfCW k1rf9XxiNzGibxL3P4RRF+tx9RWBEIjd2tYQL1RJ4tzD33ziNWF5RVT+ejK/ZMYro/IXmFjXsS5m Z7/DPT09PNeyjki+98WOI+ZHs3k9WXYi26D/dyn2/HLaRtC3Sa2yejkpL7ArQOxBehX1vnd1Dei7 oGtJvYP1PdD1pOZwvg+6EXQTiN/Ku5mUx+ctpOZ2bgPxp9x/QMo/hNcX3wK6i9Sczw9B95ByEdwK uhd0H+jHuqw/wf4B0IOgh0itBf8I6FEd/xj220GPg3hhz52gJ0BP6vhDmp7W5yZlQvKwVK+ZGYTk c7/aRn1eSxwwFJDbMLFkTeas3tX6SDUlK+yYO3wO+6n8/3YyII6Bhi3sIhdwMTAxIvuHGD35QHwK si4NWH4g7uAlB/AB7QeVoaAyk1j7QSF8MxTCDge3dFLAd2kmg++bRSwaIwZIAe0HhTgrCfaDQNZd CM0KLLlKwTe2JoLj3hM6egHr5UAW4OEGGmSEP2jMF7YclRXD56S5xwJoPwsDYv8sMfavQbKfEXpj bQGwRE8Cl7SkASHwUm7S/A8CpNuEG5BjPwyA0u5o+ThyASMw9pm5IGkIvewGtd/Q1iXCdiCD24S+ wSAxoBA4M4HYejB5PQuGL5abCqmVwkcBrQAAUEsBAhQAFAAAAAgAmFbYMFw/OrbctgAAAHYBACcA AAAAAAAAAAAgACAAAAAAAE9NQS1UUC0yMDA0LTAyMzMtT01BLUlFVEYtU0lNUExFLUxTLmRvY1BL BQYAAAAAAQABAFUAAAAhtwAAAAA= ------_=_NextPart_001_01C45E73.FB3A3670 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_001_01C45E73.FB3A3670-- From simple-bounces@ietf.org Thu Jul 1 11:17: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 LAA09109 for ; Thu, 1 Jul 2004 11:17: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 1Bg3Jz-0003rA-QM for simple-archive@ietf.org; Thu, 01 Jul 2004 11:17:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bg3FO-0002i0-00 for simple-archive@ietf.org; Thu, 01 Jul 2004 11:13:11 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bg3Ca-0001ef-00; Thu, 01 Jul 2004 11:10:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bg2Dq-0008Pf-E2; Thu, 01 Jul 2004 10:07:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfZZW-0005Dn-0b for simple@megatron.ietf.org; Wed, 30 Jun 2004 03:31: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 DAA28751 for ; Wed, 30 Jun 2004 03:31: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 1BfZZT-00050z-Me for simple@ietf.org; Wed, 30 Jun 2004 03:31:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfZYV-0004cJ-00 for simple@ietf.org; Wed, 30 Jun 2004 03:30:56 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1BfZXX-0004ED-00 for simple@ietf.org; Wed, 30 Jun 2004 03:29:55 -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 i5U7Tn211939 for ; Wed, 30 Jun 2004 10:29:49 +0300 (EET DST) X-Scanned: Wed, 30 Jun 2004 10:29:24 +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 i5U7TO9h012329 for ; Wed, 30 Jun 2004 10:29:24 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00XIa8Eu; Wed, 30 Jun 2004 10:29:12 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 i5U7TBH05623 for ; Wed, 30 Jun 2004 10:29:11 +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 10:29:11 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C45E73.EF9ED52C" Date: Wed, 30 Jun 2004 10:29:10 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797CDF@esebe019.ntc.nokia.com> X-MS-Has-Attach: yes Thread-Topic: OMA LS regarding XCAP Dependencies Thread-Index: AcRaWCKZ3UL0p5DUQB6AyRFSfJzH5QEG77oQ To: X-OriginalArrivalTime: 30 Jun 2004 07:29:11.0140 (UTC) FILETIME=[EFD85A40:01C45E73] X-Mailman-Approved-At: Thu, 01 Jul 2004 10:07:20 -0400 Subject: [Simple] FW: OMA LS regarding XCAP Dependencies X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org 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,NO_REAL_NAME autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C45E73.EF9ED52C Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C45E73.EF9ED52C" ------_=_NextPart_002_01C45E73.EF9ED52C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable FYI. -----Original Message----- From: ext Guirguis, Ihab A [NTK] = [mailto:Ihab.A.Guirguis@mail.sprint.com] Sent: 25.June.2004 05:00 To: rsparks@dynamicsoft.com; Khartabil Hisham (Nokia-TP-MSW/Helsinki) Cc: OMA-PAG@mail.openmobilealliance.org; Mark Cataldo; = susanna.kooistra@etsi.org; omaliaison@3gpp2.org Subject: OMA LS regarding XCAP Dependencies Hi Robert and Hisham,=20 Attached is the LS from OMA Presence and Availability group (PAG) to = inform you with our specifications dependencies on your current draft. <>=20 Please let me know if you have any questions or concerns,=20 Thanks,=20 Ihab A. Guirguis P.E.=20 OMA-PAG Chair Industry Standards - Sprint Senior Manager - Services and Service Architecture Phone: (913) 794-3780 email: = Ihab.A.Guirguis@mail.sprint.com=20 ------_=_NextPart_002_01C45E73.EF9ED52C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable OMA LS regarding XCAP Dependencies
FYI.
-----Original Message-----
From: ext Guirguis, Ihab = A [NTK]=20 [mailto:Ihab.A.Guirguis@mail.sprint.com]
Sent: 25.June.2004=20 05:00
To: rsparks@dynamicsoft.com; Khartabil Hisham=20 (Nokia-TP-MSW/Helsinki)
Cc: = OMA-PAG@mail.openmobilealliance.org;=20 Mark Cataldo; susanna.kooistra@etsi.org;=20 omaliaison@3gpp2.org
Subject: OMA LS regarding XCAP=20 Dependencies

Hi Robert and Hisham,

Attached is the LS from OMA Presence = and=20 Availability group (PAG) to inform you with our specifications = dependencies on=20 your current draft.

<<OMA-TP-2004-0232-OMA-IETF-XCAP-Liaison-Statement-.zip>= ;>=20

Please let me know if you have any = questions or=20 concerns,
Thanks, =
Ihab A. Guirguis P.E.
OMA-PAG Chair
Industry Standards - Sprint
Senior = Manager -=20 Services and Service Architecture
Phone: (913) 794-3780
email: Ihab.A.Guirguis@mail.sprint.com=20


------_=_NextPart_002_01C45E73.EF9ED52C-- ------_=_NextPart_001_01C45E73.EF9ED52C Content-Type: application/x-zip-compressed; name="OMA-TP-2004-0232-OMA-IETF-XCAP-Liaison-Statement-.zip" Content-Transfer-Encoding: base64 Content-Description: OMA-TP-2004-0232-OMA-IETF-XCAP-Liaison-Statement-.zip Content-Disposition: attachment; filename="OMA-TP-2004-0232-OMA-IETF-XCAP-Liaison-Statement-.zip" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 UEsDBBQAAAAIAIxW2DChp6gNB7QAAABqAQA1AAAAT01BLVRQLTIwMDQtMDIzMi1PTUEtSUVURi1Y Q0FQLUxpYWlzb24tU3RhdGVtZW50LS5kb2PsWw10G8Wdn5VsS/6QHcd2IAGTwYR8cLbifHFcHk2z lmVbwZYUSc7HHV9raW1vImuV3VWc9LWvhKaU9669CyHlICl9IYSD9ngQ6BXaa/sKIeTuUQohFMK1 TY8QLlx75PgqlIOA7zezu/JKsRNDQy/cMXk/zc7Mf2b+3zMrxQeern3xjgemHSFFZQlxkw9HykmZ o88F7LEbkwh5EJUAfDgyMsK67gPuB0Y+K5+a8updj5LepeUlhLw7+ad5y6LA8NsaCakmfWv61ty7 494dxR5CSHnJFLLmECFPvWHifZ/Zf6vnZFrC/aLmtM92uZF/fr2a5Gvn83h1vWOFnVa/t/Hk+jLU S1EvRG2gvtxB/1w3Ie1w9R+jfzvaKy4g5HrUL1xgjhfXKy4iZBfqdy8y11k4gxCKeu9SM2L2LTXp nHUH6gqRkK2lhHyrw6z92BdTydQIITFMXLscdAivGPobTtLPqNzds8YYZPw0jdZXO+jsmq071np2 bctnF9am8JMBzJuP9rRLzP7imq3//BjrFLf3Li1c357/UYstj70eW6fLsV4f6mnQ4yVLCHmSnCzn xy3a583almcP/KUK9YF3vuz/19X7BJvO9rum2YQ8gfod8DHNsc5+rHMC9W3dpv88Z9llEvr7UD8Q M9uvzjb1ytoLrf2bHevY/rtzAnEyVrH3sYtN923sg61JAs65FfUx1INkVL/hizGGehfq7wrktIWt M1Zt+6NdO+WZgWy0D8Hd7h1dZ+8cQlaRk+XeZyUBFxEmwM1n5bPy/7l0K5KiqxkaNyRDHpIzhs+X UIy0vNgT1dQBTdZ1BaP9qkZXBcQoDbXrnjraEYn1BLqCgSvaIquo0ECjub60kqS8nDwaUDP9SgpL K1Kadsc9noS62BMKJjpoPNQT7Q7SlZ2+mNonawaNZyVtrU4v13T+sDS1MSMNKUld7Tf8SXVoia9L 0QelIXrFoKQZUp+SppcP8h7/WrtnaUZdq0ic2uMJBBZ7FnRGozQR76RxkQYGJUUbkjLUF1bktE6j siFrVMykZE2XM/TyOtq1OhqMdYfCV9CmIUlJG+piTskJr7EJlwZzmpqVF7T6h1TOWBMV6idC17DE 52P8zGcMtawy+fG1yYa+kV6hpIblNCSS15pPS9O5JLRmiRJXc1qSm0XGykmZSpkUFdeDRya1Ymyk K1VtLe3U1FyWzo6KnXOo2k+NQZlGshCtRwWVTMV0WpEwG+vJmB+Ts2lF1qnBLDIo9dHOnKIN5BS9 2WStmWKhSjbiF/322FKmGL+e1RSTOQo9qxlDShqz9TmLPR6PaKAxyJxJX+zJzJU8nsh6WVuvyMO+ xDj80NmRHnEOVXSaktfLaTWrZAYo1peZ/jSpD6RD5ozx5dfZHklI0yfpcorCbZn0yZymgRM6zLSj mH2W80WbLQ9s5ouhIxoKd5qUA0yPup+CLcaVJud0xhKfaUYCYy4jG7Rdk/oNnYdIUlMMJQkv789l kgYCR8/bAMucnnM/9IPNhuQhlW3K5IcnpWAeCj0P5TJY3JBZ0yEFDyHOLpVoWtENe087YNGQDJMD sRMLZXSFuSeVdAfD4F4ZyqZ5CpAY6x+Ncz5ik+vJQTmVg63YqgaTyCLzU18kp9EcDw8DU7iVLQa5 OKbIuiUx+DEsOWC5uJxFikKeoPNbWxc2076cYc5UDDokbaSGtFZmQqVVrIpaVzbAaTLGIF9Ozch0 oyxpBUszjmMdASge2S6r6lLa9FBLV3lBsnxUtjhFJJ5KJVk5qfQzS3EH6JPz26Vo30a+JQs9qHfh clMQXWUiDKu5dIqRD6mwYZ+ckbEIS5lgeFBaL4/atGiHouXBoKEMMV0nbCc5nSdgB8am7QxKJpnO pcwN+9V0Wh3mrt+uL/b5CjLkoGFkF8+dOzw87Fdko9+vagNzFSsuWlI8LubyqoUNt+jcw1o2JKVs S+t8v7HBaKL1jMngBlhdV1iU9yDvw5O7pcxAThpAXljV0z3HPEIGcprpmWISHofkramGmlTToIF8 c2hD5ZliLisl12LzltZ5FpMinM88CUMZKMlkY3R/ZI45NLiepZmoOZW7fo+aypvJHNatkDhTIvdI GcxI0XY1meP59gwqgaWSlpzO9WAbS8ycIcZ7dVtJ+UDqxn5niP+stWaLhuDVW1pbLfbze4k5Y1DV lC+YPMYY1Zl0HyXV34JbhpLNpfkOthpbPzk19uS3Q6jm5bT9gq1mmP7x0SPYEnNA0pCOCgRNKZqc NFRtY1404ZOQDXMcHt5ub9rgC6uGvJjG1SHZOq10uTg5soMBuS0l49KRkqAJdrKBUtObrTMrZxJp 8jrcb5DPUymFTeV50DriTUVYaRLZUdWyKpiXU0iyO30xzJR1ln9FfujjFsRTb9Zxgc6zN5qKVXby UByDBjgYVnBOZqzDIZlW2QUmf/oojoPaOvutnM+WPvUBHbdPXue5Zt4WNJNv61Tg57SSgb6HTLNA VHaiZpgaVColk2oO6kvlNOZhjAfrpsb9C/Ixyfw0xAVlegTkDbheJnG2SdZtiDGQxPWbH9VsVWgH hx2Tni9ZpLIxTrtmCrlxv2OOMSxpKesGMMq33yemdbWZXQCYmhkbbJeBDDTKFJ7JsSsE1hk2eeR3 S7BiH3qa3A/2mS65qmEJfkNwWug0V6ICfv10pWwd7WnFFNrSu8m5g6VCXtm6jksfvwSyjdnFRoV6 UONKwqPM70NAgXumNnielFlLV6u5Zt/YN3rLCXw+t89XYn96vQiwi9hYSyLawq4lSPoL5rewDnaF aGGmaLFeFlvyL4uVEU0ZUDKSdflgLwvz59FluQy/orHbQizYQTtU1UjIG4x59MpBZIjv8MGxXwO6 DcQUa9KYMjAI34zJ7O6ISCtviLJ8UMc2CdL6+Q10NjykjoZ7e1hPnHXNqSzccL65YS+LplEfk7Uh xRmVp+CE31Q5DTLBEL8ys4DFctwV2OuKlZf85X/FlScjLkFgqyqvKa5T/Lv0qrOLmwbY/hMxfTgC U0RjwXgwnBAToUg4TiMxulKMxcRwIgR7zV7ZFUx0BWM0uIqR8WH2MhMKts+hYixIe8T2IG1bTUFE I9FgmPZE2kJ41xG7u0NiOBBkE8Tw6rHHeoI9bVibrZmIU7GjI4SBBLaNBTvFWDt7z+NzO/jyoWhs a3yU32A7jYT5wM0sWjBK24OBbjFmCrKNdofiiWYaCge6e9lSzbStN0HDkQQGekJseiLCp4uBQG9M DKxG8EXYe1oiGIakzXSF2B1qDyVWM/5iwe7gClMei5kw+waFb8VVZqkJj2yHeG+gi8ZCnV1MLGgJ 64HjkNhtEoRb8h14mxxPc6G4xa3Yhu4Orsh2il2C0Hd7KA5ZQz1xrqH2UCwY4MLaT9HecCgRWoG3 5ng0GMBGXBOhdmbobiZpOB5c3mvy0My4Cq4KQngxhsXEHh6rYiwUZyaIQG2QmlkpzCaGsQETe2Uo 0cV10RvnammPBHp7sGKc81msJExMiKEw1B4yrZYn9/usBRJdENnuZk7FNMVsa/pJnGkk3tu2DPsz 20FRtjUSwViPuS22gc1MT+7Icyd2xoJBvurstGpmaqT18S5ZKoLb/CJDskKbX7mQE0QcfDyw/IPG UJrdpD7GtIY5nNNQB10d6aVd4oogtzPnMe+UpkRjidDMp7VH+CQ+m5FwZ2OTQcvMG+VuCy9JxELw +2ChcpnXOXWN52gssgLuwYNKDNMmkam7idfiCjHUzZywiTPexA3PtN8h9nYnQNQmxkMw48c8MwqO jHljHxlnVz72ofxJvwAuI2Syl5A6YBqwAFgItAEBr/mLy3IgBlwLSEAfoAMGsAG4H/gN8BLwLlBd TkgN0AWEgGVABlCBLKABdwP3AN8BHgD+G6ioIOTE28dPHDl+8MjxI8cfO3L8xPETP/re/bu3f+P6 7bnt39h9/xoJXUUC1E4ZXDf1BnKld9NQV2OJDtQ3DAZzrxGzf6irHJ3lJeRcZ2/rsiaMeDDiKSEN Lu8m95r9ApThFczxXq9QRN86Sl/nXsM2Hh0BddGeFmWZ2SbVZh1Z5ibLAdZ+JbqE2AyTRs4B+1WN c8DGbFqsbY6ScUbPsbkp6q8u7CE+s73YuymwzMs4Y62LxrK/07Zfs+x7GHjfqfZXnY3nnY3Hxh25 ZmJzVo/b4DqYTqbMEEL9/Me9JCFrUweY+DOEc+xe1y068T7fQdwe4b4y+bwrZpKyu0uLlyFlD9ef 3Hesorir/h0s2XCpcM470OG57GPa8+xn3hEb5xU2zy9sNhY2Fz5fRoRSdyPhDxVunUjvuL8gkMnT iW9/meu+sn3VpGYznHozGZXyajSuBUjDdOKe4To9oTTDVcNIhfrdO8nMVJm7Roju91533XWkzC1g VCDumaRuN2ZUMPu/30DIzY2EfPDBSQr5rPyfLSUlRBBch4ty9zorP2+28vN9zinfdDa+/Mc2zobS MJG4G0g9vuhKBP/Eo8+aEWXZaYUwVnZqJS6WncbLTbdPL+4aKw+x/w1h5aD84/mjj42jj+PlHY/z DH7XcQ4X2P1WZ+OrzsbCccmKC9dFj/ss1sUZz8GmzIddZ7HMpczWQaADiAFxIFFRdLwX/N+/AvsX kBU4Q3HhumgpOYt18ZEt+5NPvzefZH9mewmQgX7g13gbaa0mZB5wHbAJ+BnwJPBz4Cng4hpCZgIH gGeAg8CzQMskQvzAFuAmYCtwM/AqcByoqCWkEqgCfIAB5IDXgTeAN4G3gMhkQn7/2itHXzn6y6MH 9z60d9febeN8PvTFXafyQUeZ67w1L7lEaLvEFVnmwk3Zxe7OV6NiLw7ZQaZl9vowzb5NmzQ2AX+z mDnWKicvQaaYdIFl5xIJyM+f7uSFjYIDJ0H+bcGiry3kBW8+1m2eFN/5y802KBrsNUhJBmDr5LwC mVNsbxX420q8p+Ha6oXta32mD8ytNv2A2eQnsIdYR8hvnQotuM4X5IivOBubJtb4OHO+NG6jgCxf oB9+BxYuABqtDHX72ZyhzvwJVc1iKwosB34E/HjyqH0Ddea7wQngQ2AEEKZAJ0AJUAp4AO8U5mnM +wj5HLAEuBK4CrgauAZ4+ckfPLnnnm/duuXr5r8vrkldtToVu7WrSHF1hbEwmcVCVcNgNhC0+tib K2uRfC9vVZg1m0Ga7DXsHqxR7PgXOPcZYxy78CtcjU3HWqCzI228WC6O1epCugnnio+anxbx7wh8 pY7vCCYwi0y17bwSeBYvxPth42eAXwPvNZj2/8CyP5li2t9t2b/Msr9tZxfkcwOrgNXAH5yGfdvZ eGvcxgTJChpvOBuvfXIjh8cdKUh+v3A2Hh93TnGpqUFwe4R7ZwrXznLhpV3gL+233XYbKWP/kVnA gVk2yUEy+ZT0AykeFizehebRHOfBPpv/rJblvatRkyksNtcBGqAD3wX+AdgDPAA8DPwA+CHwT8BP gUeAJ4CfAU8CPweeAp4GDgAvAUdZzAOhcwhZBmjAIeC940ffO/reoacP7QWePvT9Q0/ff/T+XUf/ 5kvp2LiaWUC8m0YTgn24JbsEkmJfmeU/kz+8od8OPCp4N5WAopT3mrPbLqkJLKsg2cFbbrmFkFNS MDWSWWNQODmw95rKY++mMkfsWVmnwm7hVJ1q5qNWjLBRO+Eg2Uy1v0k8acTKHvYIKfiuz+7FPmNl TZOr80/F1WRyHrPJCwBBvApW/JYA5cBlwF8AK614fnEans9DfAO3AduBHcBTwNNA/HxC7gaOAi8D vwP+E3gVOA68CbwFfAB8CPz24L/se/Deu+64d9+ObTdu23hj9sZtO+5NXZmKAFemmEB/vGZq7Z4m cjn75nMSOZ/rpczj0Is1AnIyxbmOo99X0JPX4KRTnEe2jkfPI4cNxjhv+LkyliWb8/5v+efYrm/5 9YSpmY9fwOx6eKppW9t+NyFRbG00vxNkfwN2zBmME2z8m7NxeNzGr8YN+s/KqQrP56ToRJg6Gxc/ Ur15C3L8FtxtZ5N6oKWdCD372ffaI8eOMRtdhcGrAWkGrm4sDkcA0mgeEC5gABhsPNkP3jz2mxee eOShB+978H9X+E9Lse+Q+dge4xgq7mNBOW38o4Y4T5SJ5sDxTx5S4ScVrUJ96+SZUYFM33NgLt3z 4ucu3HNZSRNw0ZadpTO2XFdy8R6svWep61xgZ0fj6/NvJ2To7fTeb8/66x2/e/XOm3dcsHP6yMgL Iy+SScs6Qh1EcAlCM7t1jByvjEYHVUPVB9UsXeBvJZe1hXrc5i94kxgFnNhl12ysxPzxEy9hZAOn NS96+T/74jTmbzSC2Zpl/rlqBbH/2Iuv4zbvkV1kbn8/RtL4LLNmmT133LY93zOff/4lIfmeRfyz ZbSHr/kuf86O9wfO7v9gw2d+jMtsamCSKbdrqQlrrD6vsyreZr84kfJHTFrGL5mFR7zeLmhF/24c 9UKhtaAnvIeNfEhmdrBfuYc1xTDkDPtvPWJK7ZNp3ob30EX+1pH/ItW8n6SuY3uM/IpsJlVer7fc W1VeXlVbWVFZ21BTVVXTcG5dXUNd3bm1VbxY1dhF8FVW+qp9k6qrJ9VXV1fXs4/qenNK7UQWGHmE 1HohaNYtNBFXreCuFUYOQymekX3C58FlqcCL5SRuiF1SWubxlldUCsWD8EW3PTiJCCWC21XiKvWU eUvdVQswWOsuuXDyvFJxuVTXtG7T/LL6m+54oO2iGQ2xR/sWLNSufybguXhr/PUjbyT1RVN2PfiV me03J1LBvXcal55zsPcl+c3vbX7s2dzRtzpmbdv91X/85r5fvPz7u77/+HP//vaK/vU33PL3D+1/ /tg7f965cmD4a39398P/fOiVP9QSlwvclnCePGWlizgLF86bXAIO1jXVlc7fdFM94+DR2DOvL5jR d0S7fmsg3pDUF75xcRljwDNz0d6DYOLOc1LB3ksN+aU8C+NzMGuUhZFfkio337OWfP5/2PsPuKbW dV8YHXQVARUBkRIUBAtFRUBBiIh0AaUrJQoCIlWq1KioqAgIiKgIQXqR3muUKl3pPfQOoSek3jFw Fufac629vnPu2d8+9+7BL2S0tz31/7wtwKaBiRwcxhjhPrnE90EI9S2nqoRsXxz3yvvMSav+G3Ix 0tr1Z17L7Ps2MlM50u4todqasWBzhZsrf3GrcDm9J98wsJjM7dlh+WE6RZO3XkH2+2Jq00V9/9RT VOCQ2f5+sU+bGBPT0RrXD8PBQku4pXz/9il7s8uTPBTx0/49zagou1lWVj+GTJ64NoxB1XTPVC6y RxsV/O6MgwfGoxpLt+F+tYE3vJxrsjm6f4N4hQrcHHZXSndfDuqg09FrTTlYoclt+dDn4XIT+iNy 62ZKj+zDuRgRydTSqpS+2TystuV9S81Bc6zH8GqhFxXoyk5/42ftqNOj89mq/62V6XSvIU4qMWcp r4HgaEeWhm/62juMBOsbbMDmj9bi+CQX4N2UTJuEzvy5b2W7DwYqv1YI27DvdyIzpFasL2R3iUc9 7fi8IL879Gvz3I/XNzSHCwqfcA2a42D5w6/aO3sIcNfO3NBN9k3MZ68YVZJhSPxEvqCItfiN28E/ PPtdipb6C99rZY60bxh5256Yi9mcmA9yUWjzLpLefrxE+eK7Bn9HBb5yhCRtRs9TAQ0OMlrhg1Ym p37r4MdpWILdqWy/kEzMnHSWUwIyCJ3hhTC8r1XAZT1lebbzfenXpbx6ZqbEntLCvPSPVMCKx08e 1UYIiqECnEjDMiMzR2uEYcqSEk9H8oePM/b0BZWThVm43ExXbi1ka1c4SnsuBpG0eY+FLHOyIn3g dn0xXQFlKZhgUE6YLS3tMz603NhWVXGPmyez8GswPXl/6epGVMztW0abTqS7lhvLb2eMnkarS+uq O/fNr4lueMJdhwawdQ6F8O16pw109LXm+uKF4l5SSEykZcZcjKCrlsN9xlNi6a2oD81reTBs+Vw+ J0rrmHwwwpySMmiTPJIR0lk/U5KL3lr6FInsNMl0Nf0+/frmlcdS9BwtVsggp3SZCdkPOW1Sr5Uk 0pvlLyH9RhJGBtEbgt03YOM1MhI8gunkG02eacSzHbZHPZ77vcP1mmMTdDKMsvXgY5/VdajfZ6tK yYimeb/LGX277ez23vHobvMk687Jcmk5ac6dLxEDDhvLNHii/EIonUMvurU1ncXO589/CUZrCDn1 kzIz2BM2RV9iN4ZmzDS3WYXeokassYQ3QxVTh26/liIOc6myvLgqf3YdluUnKVuFfr1lOUBw2Srn 7i5AuwbdbD40HF3Uv+C4lUVMdRexLDHQU4o1KSlZoVnTm+uXvnMuyo4XJSUtGsh9lnYjWVBAh02f 209OJM3vRn7yVIlRVOSzu4WkZwOErQsEP+G87jo/JUJ30Pd73wjFm09CUP7H2qSq2hMk5BaTG0Lt kGpYwyD0+28NxX2Vx275Wc9hjCRh1+aH4Uu9iz4D809Mm06KyQwunG0S37B1byFzGHpnbyKVlNPP Vn4hbG7OJA52iM/x8a+i3scqtE2EElQKQ48UyfjIF2F8+GZ/GCDGOOCfzY5Sgikn0742dgqZGBQX +Nstlfe63+Ry3PDTUfVc49LqkNXp8g9z99yYX+33Gc6LHlp3eILeQMShj2yhLYewqhs6G2Sd76di rDEZ/WTZMsI7ax2dbyVGQ/ldd90jsaID01RAZpEKZFIIGjqbnlSAnSxJBXb/oAKxfSXtq1JUQGQT jidQgfVOI8unXQSD84dak+9+ijTs6RhVTIp9l1s4Ij8S9Um7HUFmwlshkizJN2ad8tlTus3ZsrZo hR5ZNrpzPHNyrRzsn6MCjuiNFyemZbOpQORyFBV42kDxbjcQb4LrUoF6Tm1rV15vmxusnlk9EQUX i3pLy226/MWVkFqacM0tOzISL9V70c/0G+Gro11u8ab5Rx7jxmUaO/Lnu/meuUWL5GPmVEBvwzyr WV5O/jI2Y1iTu6/yqp6fQPi8093T01h2VgKnfwgV0HSqatfAqm6XH9DTlCPd8jOsr3fomu5975CU mcIfyGQ8c6G6CEsFLg234cqWgmIJQVQgqP0zZvUtFVhqzbChm+/t2iv61srSsmvBxJLbJNMvinFg KSsz01pzKas8et5guypJIQnxzeSBGVPiLZs7M2PjeR8rqs0iXK3NTSfsmhOXcMZLjSeoPzYN9Drn 6nHnD5NtcQ/HJEnJlLXtR0LHalI4HtxU3vCPbUlg7C1eYrPjZ4xdSnGiKBvH6Z68m+CUrBDSecQ3 L/yU8o0BTHqk+CcdzYJe4qUeZhmFSmyfR4E/av19VTC646TnLILC7Vsbru4fcQhpxG3JEJqE884q yrd6iPbyaf7Q7rlunpa/6eEfSGE53FTG1b+wqQ3v/8r/Fidzh3D782DJkuf8oDTya/b7cHWdji1L Nybv6ZqrsvLIjkvkQ2xyY5T2H4tEVYI3MtE7UqQq9uHCggwv8kYRk1HpEiumdPCWI84/sp0MIyiv y6qfIHh2zsmhMs/aeyFLkOc9CIOFBGQr9lJedoZ/qnsKVxerZ4eriOtH8sAFjA4yk6zTiayW+KAL lWu06TbQa3zfT9FVuvkdW9ZhPz4RgmoiFt8apOWbHq6BpPbvYLmf+JNpBwGDAIU6vtdYXUkJcU1X R0X9qvLOFgd71a7aOjrRgtjQwdHNRVf1soDxjZsCTG0ALQDt33MGAG5bujpr6alAuzQA6spKAq7g S38NVbZ6fuLnTjG1awICwP+zY7+ls4vbT4QJSN6xcrUEz6GBCHtPN2fo/gp4ftDCDjqnhVDqQRew gj+7i4GDNj/PRXfe+XkOIduDdxwc74DnUJ2d7zjcgc5rwfPnHu5W4DkdtEnEM2hJMXgOdbgK2bs7 2ILnEEY/6GB12xUExBAOFnKzsrwLnp+G0LGLvq4SeH4RDCj22vxybvHLuZvVAzeoUUpOzl4u0HxS geOWJwTOXLhwXkDNytPeys1NbGeNn8sdASUnB+fbjl4A8LPNO8cBiLYCIJGlz1yQlhY7K37mF0L9 y4f/5gHx9ufZ+vWf3bucLX/e+7v3nOLBOAGMh+he/3nP4j0AFD8FgEMDf94TigN2BouK2n9pDyck L39ZJWYpbnn3l3L+0xf+jeOX8sSh7P4gj8AVK+vb7vZuAhDdLJ3soZW3rs63La0ExP5RiP+XE/59 PUR1/1gHZAhKGbTmScnJ8efSMGh67z9h4v9isn84fso1AI1PUoCDCHFgX/tBgG6pBaBnZwboTGPB JzR/8O3qbkNo6BIwgs38lPud42+2PqENhf652trspFPS1YfWxnv8fAapJcAARtFswEGAG+AHBIHj YPx7FpAB5IBLgDKgAegA+sANwBywBO4CDoAL4An4Ao+AZ0AQ8BqIBD4AKCARSAOygDygGKgAvgL1 QDPwHegGBoFRYApYAFaALYAIBllMNCw07DTcNDCaYzSnaM7SnKdRoFGmuUqjS3OD5haNDY0jjTuN L00ATRBNOM0Hmk80aTS5NKU0X2kaaX7Q9NOM0czRrNEQaOlo99IepOWjFaaVoD1Pq0irSatPa0Zr Q3uf1pv2CW0I7TvaeNrPtEW0X2mbabtpR2kXaDfpADpmOk66I3RidOfplOh06G7SWdO50PnTvaR7 SxdPl0VXRtdA10k3SrdIt03PSM9OL0AvRi9Hr0ZvQG9Jf5/en/4V/Qf6VPoi+lr6Tvox+hV6CgML Ay/DKQZZBnUGYwYbBk+GZwxvGZIZChnqGLoZphi2GBkZORlFGGUY1RhvMN5j9GF8xRjDmM34hfEH 4wTjJhMTEzfTKSZ5Jh2m20xuTM+Y3jN9ZkIzdTBNMeF3Me+C7Tq7S2XXzV2Oux7versrfVfVro5d M7uIu/ftPrZbdrfO7ju7vXaH7k7cXba7fffUbuKe/XtE9sjv0d9zb8+jPe/2ZO2p2zO0Z52Zmfko 8wXm68y2zA+Z3zHnMH9jHmPe3ntg78m9SntN97rvDdmbsvfL3v696ywsLMIsl1husrixhLCksdSw jLDgWdlZxVnVWe+wIlmjWYtYO1iX2XazHWNTZDNn82Z7y5bP1s62uG/3PuF9Svtu7/PfF72vdF/v vs397PvP7NfZ77D/1f70/Y37Zw8wHRA+oHzgzoEnBxIO1ByYYKdjF2RXYrdkD2BPZK9jnzrIeFDk oPrBeweDDmYebDu4wnGA4xyHIccDjmiOSo5RTjpOYU51TnvOUM48zh5OAhcflyKXFdcLriyuDi7c IZ5Dlw5ZHXp5KPtQ9yECtwC3Mrcddxh3MffwYfrDJw9fP+x5OPZw3eFFnoM8cjyWPC958ngGeGl5 T/Lq8vrwJvC28G7y8fOp8jnzveer4Vvk5+S/xH+P/w1/Ff8cjB2mALOFvYGhYfMCHAKKAvYC7wRq BVaO8B5RO+J+5NORtiPEoyJHDY4+Ppp9dFhwj+B5QWvBN4LVgitCMCEtIV+hDKGBY7uPnT9291jU sYZjOGERYSPhQOFi4VmRQyLqIt4iGSJDx1mOw4/fPx5/vOsE44nzJ+xOxJz4fpL2pNTJuyejT7af oj0lfcr2VMypH6IMohdEHUXjRXvF9oopinmIZYiNiXOKXxV/LF4sviwhJHFTIkyiQYJyWuq0/enE 04NnDpzROPP4TNmZtbMnz1qejT7bJckiqSKJlCyRXD136pzVudhzfVLsUlpSgVLVUmRpGWkX6Szp ORkhmVsyH2V6zx88f+38q/PfLjBcuHwBeaHiwrastKybbJ4sVk5Mzk4uXW72oshFq4uJFyfkj8rf lv8kP6ogoHBLIU5hFH4EfhseDx+/JHjpzqXkSzOKJxTvKX5WXL58+rLL5cLLOCVZJT+lL1forqhe eXmlTfmAsoHyB+URlaMqNioZKiuqUqo+ql/UGNQ01cLUetX51C3V09RXNGQ0/DRqNfdq6ml+0By/ evKqy9UyLVotDa0IrSHtY9qO2sU6gI66ToTO8DWRa/evlV9nvH7tevT1ad0zur66DXrsegi9dL0t /cv6ofqDBscN3A2qDdkMTQ3TDHFGV4zCjUaNJYz9jJtvHL5he6PkJtNNw5vJNzdNlE0iTaZMpUyf mfaYiZg9MGs0P2xub16JYEPcRuTfYrhldCv9Fum2zu3425sW6hYfLVYslSyjLBfuXLrz5s6clbxV uNWMtbx1uPWsjbxNhM3cXfjdt3cXbZVsP9iu3lO7h7qHs9OxS7Gj2hvZZzvscrjlUOp4wNHOsdaJ 3+mB0w/nU87PnEfvy96PvL/ioumS7ErjauZa4nYQBFMt7sfdn7qPeSh4RHvgPQ098x/sf+D4oMXr pNcLrxlvFe8kH3ofS59q3yO+j3zH/BT9PvnT+Fv4VyMFkU+QUw9VH6Y+2vPI7lHr49OPwx9vBBgF lD3he/LwycRT1acZz1ifuTzrDZQLRD2nf277vO2F5Iv3Lygv77xsCjod9DaI9MryVVPwmeB3wdQQ 65C2UOnQ2NeMrx1f94TBw1LD94d7h09EaEUUvRF48/LNRiQisvHtubeoqD1R7lGj766+K3kv9P71 e9KHux+6oy9HZ3/k/fjiIy7mTkxH7KXYLBQfKghFiLON6/uk+qkoXjj+bQJjgkfCdKJhYkPS+aS0 5MPJQcnkFMeU0VTd1No0mbS0dN700AzaDPeMuc+mn79nXsksyRLL+pTNmR2UA+S458zn3srtydPM q84/n59VcKzgYyF74csimiKvopXiu8WjJTdKfpRqlFaXyZUVlouXp1QcqYiu5KgMrdpT9aSKivZG b35x/rL41ebrRDWierDGuKar9nptW51m3bd6lfqaBsUG9Df5bxWNso2lTeebipulm4tapFoKW6Va C9uk24raZdpLvl/4Xvbj4o+qDnjH184rnfVd6l3N3drdP3oMevp6TXtH++70zfbb968OeAwQBx8O MQy9HN43/HaEdyQecwKTPSo9Wjl2ZaxlXG98cMJyYmHSdZI09WSaZfrtDGwmbfbsbMWcytz3eZP5 qQXnBeLis6X9Sx+Xjy8XYC9hW1aMV6ZWXVapa6/WuddTNs5tVG9e2xzZctgi4l7iufGp2+e3GwhG hBmiJ4mJ9I58glxG0aQMUR2o1P+F3t9LwO+9vzT//kH750H3x/GX5zS/Pvk3j5+9v0206nQ0+3/t /dWg1tJAUwIZael+QURMuxgZ6HfT7aGlAZihVT90NL9sFQc+omOi3UWzG4B6f2lp6Ohp6OigGtEy 7nanoaWj389wgPEIE/tRYNeZg4pnBTl2X7/MeVtIkkv3/qNDFmHHlD7lrgifc9nD/fWHlMiYnvTj 1fD4K/quyioyqpbHDQyNDudVd4yv3Qlwi3hilZBf0zlx4rz1uvvJC7Jq6hogqLO5a3vPw/OBl/fT Z4HPX7x8E/k26t37D4lJySmpaekFhUXFJaVltXX1Dd8am7q6e3r7+gcmp6ZnZufmNza3cPhtwn6o ylBvMQM9PT0jI4MDWOX99EcOMJxhBI6yK15nOnv74P1dlx8JhnHofrLglNydK/T1h5LLCtfY43PH wvUOWV5Zjc8TluLWl1a+I7LHNSBCxQ2qr4GVu6HMk6c7FV4/cfhNYgHUbRz5s9/4uKqR9fk/uo7/ 7LlWM7774Pm71JJvfbP4C+o3bL1evE8rbeyf2z4pq3HznvfLD+llTQPzhL92MGMmMGU4c9xyZW8l Mdsd678w7PM/N/7NG9Tv/wb1VMGLrtB/9mTnQvC/W8P+i8j34z8hHwy8MG5EtHeSQ/NG92zmO2WE EtAoLakL9mJsJObs+EQqEFCCyCaM+WFwjxvqHyIzpnrQLq3ShhcpSiSxDiaxYT7LQCrwKDqfFT16 9hIV+IHoHURWxsNmUd+oQHTC7Sac7r7Dssgi2AaXehpFbaMJ2WIbNENxlIFj+XHEEYkT8CginxMh okTt9GPUXSoQF2gM738/O6/hZzAcWpSL3ipoBnQIS40Kc8Rl2BgVYCPT9VABZycqsBZMBQ6HUh7P aT5azkINpSx5zFgsVmRWvQge2ljLIa1Y2JGRDcNov9qGh9mESqNMhYaquK6ebuI5diKNyCfrD0n3 Dr5WiO3KXBS/m0KCT8/GHasO7brp35Zn6sdU/NbAGyX+cfe0d+QyWea/DTv/625QO/4TwWHNS9RV /ExWpSMws4HPOFh7l58OnkNPGjzEkODwhbAlxtGr91xD8VmBg/797LKPA4yyl7Y3dc0aMHLp+fhA 4sdG5MzE3PJFNPpMLjBBOTXVFVa8ePpbAGxsmwpopqMXFfDD+pGGlAvhVACGO0N2VCVicrBYGwp8 itKgGxl48vLySTT0rk78pzKK/vLnC0eDLoRTBKnAUfQmDjvSTkI2k0MS5fivFL49Mxja3kUFamRF iPnlPjwPDJBvlz9GzVAQcGzpFh+ZKLFKBY5QgUubR/3H+uAYRJsOgTnRfwQTPeMwdWZ7SHx+6N1i IDlLAY3AZ6P9yVF4KvAalFRv3DJfAHmTNAmel5WhH8NaG0qkpWcb7P3b2+54xtIJsb5tepSmPj5b 6+z3amt43PDWqQBKe3Mqz8fKqPzBpQ96fLzOCpbHT19t1VaIcaAC3eTggEWtzNAhvEZdZqgADWdx ylvpwocAm8ux4IaXL+0MqUDQAotXctcijm1PyFcNZL0/ZnzWYAv5A6Yr/7/EZjcWbNvUXFbBC6N8 n9Bs2W6HVL7tyq2s7pJbokpY2XeHHsPrR8i9ZcA99HuuL4c1guCtoS9vkUUVFDfZM6vQelWv/eEp aPflpzFP11ATRne/qZqTns7xrQClWkkDRAkX2Nb+H4YtOkQ6JFjuIdS/XT1FBfJSSMqCrFTa4kj3 AqU4zqor36l1qXAr/fTR0agRjoO9Qn7iNeCLyr0U3sBRtiG/KKIc7OAmKAxbtwgvewj+2djeTnIg WLXAkdJlhejFAc70BfGehar6V6F6i/ILhTI3rsGPbVkpK+1vIEAt5Pb7h/p0nHLFsmTk5bLEDg9G OC2Zimqw45MnW3WXhk6XdME9iu7GA2kESRc2sIiXFKPtl76s1V3kEJNppzrvw4Osx7bpunZ5FW+p EKyZUJ8u+uDMZy8tYCKRh4mPPkR8rlJyy6JkG4DctP66FBNZZtZA23TiXqwKFQhXBfN7lQ3+q8QO +2SD6Rag2uH+2Y14XFWVNunBwkH0LVyDlr01vB9j9j5vqxG23WtyALVFAV9logJjTegoKkCepgK1 KPJxhTgqsIgDm3nZv3nbaRWZ10BcAe2y9BIdxUt7pG8wgFJg2OUKZp6wX4tyC/lmgbSwsUrBgAn0 /pFIf2Eagtr5z01GDyPBZ2U+h2RGFxMYRTx5nUIk4zpHCAdMXooYBAyZRJDyBSlmDSS7OQqm7ywV GIXPb8wbDqALYPNr8gZM9o4aC3fgGGRVcckyFRiHHloOwPMQ7SSR9OXFoYZ+MjkDnd1Lxm3w1/hX qnPCuKmAUfYVuPO0wvqJMCrgR6lZkSemsdaMITa9N1C45VcEiIIpHbD8jAZypCd80T8We5/8CUz1 ejZGQHgogPJ5swj0MLZY35GVgb6lTNOzKn3Bl7dyxnupgMPypakAwgP4fIZ7oPnypcOWn/fsnVkM lLe/rUkFaKIoe5AjlU1kS5juv296zxoYXr/ecbip5+A5DQbsHGGkd895TohshXA4fEwNw005O7lO dl2NYlZcSynO1SIJnoiss6YC5cOnitueMFOoAKqzT5E1S7r47WSAvxjIvEytqqtUQBY7rbkWm14V 4EUKGqr0yl8zKka4vZc/UyyvMnmvj34r8JYETAf7tIQfFJTPvNkYR43PTz3ulR97/Y1t28cqHzYi SQZ57oZJobyjAhhkMVRn9NQpCrBOWafsKM5FGD8VeG/T3v5y05gKbHCsJRR5bGHqmalAwnA/mEht 2A60jqq3IMm96xQAX0kLzihJ+WqPiI3xUe8tpMifGOYzUBQfHeRXFlVyiknk1GirlHD+7J4DOBdX gvkPwj8TVbOIoda3fHg+e74dXhQLKM1VPfF0eFBPkh/pZH1LWk9IYn/4PPwaYwMBgoB7/P9OYY5i pP19SO54pm73GNQak7f0sVPf6pZYMp4oxi7Kb5ZsHBpP7I+WaOrQbzr0VtYBxp9lzwPSkJPiQgWq gygevh+bbbYaVGzg/arzR5CjfVXoFmS9Riuds8rGcpvhGUsn3JzLJS6hdbDIdKGhC6+mSU2TMoYb bY5aMyVnEasPmh1bGnChLoMgfIFMocgGFeiEEbE7CnrNYbHK1WaK1dXe5qyJp7MlfGqpYB023NpK BT6hFcAXyrBPqcBKHBaF5HR5NyRye/nRWnZK13zTknZ/c0CpkX1fVmbQMOZaj4VE2XYulGDEadRo nRv/g1RL6MNqBw+faUANmkstimcNn9WICciZ3v/5zMv06wZ0zTpCnbahF5MmfLyfi54D+WxHLC73 zp/wNF0eGVn2myv2JmZLa/OtbccMlrkE8V5LvHdJlK/QxT5Bq1F4K0fIJ9s90bMdg9dDuW9p6x3r hdOuOPyo9FWvKfZwJKniIvIke69o2le+AsyCE1VE73RVYxBg2+2uD/J9HTLDxlI2PVXveai6Ou5F kSrLmR848TVQNkECxqGX4HNB5AmKFMRA3evkGEOFcjKOeB8SRXcb9H70R511JrxDRBwPE1qGy9J9 6yKDf8oyqWTRIa9JYs4RjnmcPBOcVvcCxA1geU4MpDxkDKoBMX1Kh81c/9uwyNrlveafGzSWX1XQ eNLTWJ11jP0w4sQZ+zW+4xID22upUE4hsJwHECHD/tHmPq5qWxIvn5N/H7vo3zcS7ZotzdhfRwUO tjkO974LoinO+Z52wsvcUCmZlHM4mgDhonsS69EUDtizegXXW6T9C/f8JuMZnxLzC86sKT16rfba dLEt4ZXS67MNF+2biJFzj9gsPkKp7ETW2Lff+pK2rxuAQEMLdlLO7v61O+hp9gGfGjLvZjblER8S Mv9wIypASwUmBaGK2lKBZDgOs0SGjEpuPBWI5HUiNpD0QGOjAk+kWJEK8VO6drKSkwj3TYscgbGt 5JUREfuci/s8Low+hhxZkTjekwrsicUuvTAKGcDIyBbzjAxeYkYmhaTWsJYvhjOfcMJNBrknU4Fb NLQNNqyOipC9N3noq739fjVjOspc5I6v6+KQhMVtCd4br+6/oQLe0tqjtNb7nORjCfMeBles3G3d lS16GUchKMCL/jtLiKR2/Ucv8kd8d8spBc2awVb3w2/pEe5NnCuFuI712y1WJwi4G/PVPSPWf0O+ RuqskmCblQESFDpKtnaSQwZRkZIt2H1rqw62rYOnIHtwfBiSKtk85qqP6pYmCCCfbN4YjlalAnRU 4BsaVNFcAuo22jwxiO0VFcjojYdHJRA1KgKJ2BTij2K0+5E+31OUbPPoSmKCwo6JMVlFepZQvoPv fnP75PD10XOEzgq50t6PFLV1zBP34VnFrTXN0A5kUERUiS7D8iUZwaFHTdvKsPnx4du95SuPhLKv 37TcUlpfcBhCkhh1NgfJ2KHsniObMv8eUkJbeSg0zAcHlRHZc4pVTlnb80U8uzDcX+Zq/pGTx6me +06stWZ2SJ3iEZNNtnkmkMlVnsjW9u2Zrai2luTROUyo+2BEehUs8pB07bxfeR95wdpTrHLC+qTs 9vtGh1xCdPCVPhPQqNH9WrAMkht0lZEkTyJ2mxmshPa5SBSItkg6v1jd+QZ4VOD6uW0JUqkcO75d 3xpdEWNSmn9pS1XNav2YRw8ht4QlMXSZ6bbMj+ILY29eK9JD/PU7VsVF+j4Hi41he4SNDW1pCBss 5Tzk96Nw7W6K8yLfD578ZXJMxdibb7n6us67i6JynBqVQWy18KuOvkhpRUb5mazYTaBv+b5cesw6 0H/e49BHYbF9jmLY0kQn4Y4BHpVzVjfS05NF4yc01i6RL4HtWhvdDlzDlVc54Yo8q8rbZUhK8iVd 4lz7Gwd92O89ogL81t+E3oqQtBpBQvy4/Tt8xuDewNcqwTi0vRlZB0JwtzFNyg3QuIchK4m/VQlG kfSNXpZ4zjeYT8TFFxvhfJCLvqWcVOCdk1whFZh5hTlKBdbFt6F8Zyi2yFbXfNChOlmMPr5uVZYf J214YvCu28f3mVaeJzwd5spw72iM/LDpBn5njj5MvzAVdAYkdfLvuEyGvMlFyrZEjsDHq8CinRMz iO34XmLDb3xJYakslYx2ki/GGfa13SlaXh28EDph7FskcoY8NFQi9oMKyL/bMVp+vMiwqHXj0JkZ 9TuyC0VrxrNVehsh4h/Ea3Vnw7Yc+7s1NTUH3XKeX9LwjqIxvjf2zthFA6xCDvwXAZh9T/q27dWB 3FXG4+LZ62M91rDEV8wdtD+wQXl6yGfQtcmGMru4FL03or7TSSN/T7pEV6x/QCdI19aA7UAqIIkI Q7Q45WrPLraM6Dhu+g+0cs7zh9dOqw/68KIa4evX5Pb6Mc4Sdpaugo7I1Px3r29ktIVcReNQ/0RO N4YpxFn4eOwvIAF8ZyK0sQqLfzRogqxQgDv5RpltMfbnUoF8O7kihuf95RMUfyYzCrIXYnuH3PZ1 pBR/FsWqUv5GdFJSw2IWrq/qeLlT+uDpO+elxXRoHSuTpJSV2q/n3hvOPPiWd6U29zBYWvF/MHfU 7j8sXdd9SnGBNRPv+c35u+vtxjbvr/k4JJQkccDfzeV7HuD9yFZMGma4oT0z36Kig5e28bm9uo34 1FCltpuNaJFCnvTh4DcYEgo2c9AOmP+qsyhmXklsGr6farRIBSyTVEQeOJjVF9fYnOln9nMLR8IX 2O4Um6a57hO++xx2UgbPkxncxroHM0YFZDQ2Lw6OfHCA7ZsTUipPfLZQ+7JJV4KCa+9cwGoVZa5f K0J2r/PHwL64izHt736A46/OIpoGbu+eIU8+ouAWj5RcbstUbicZKYklbx+4VjtDDlibL5CzzGLr ukYFskG8OFFZc9fTNXTTkmB2NVp7e48IbIUEAsVum636mmxi9Acef4WEaFQ73kfiM6aGwpqshXZ/ LMOHGdsmlWVSWvvc8fc+P3VnYVSboAIpRGwD2tAJrDWTLl/omYGjNBnbMu0EedCIr3ERG3KwL0RW qMCZ76E4h+JsPLK9Fz0pgQv1XxWiwKZlccuDTgjwMepTQIos8sIQTzNN4d1UFyPKGcq0Tud6A0zH giXFNkzoUMPUrL8fLa51baCtn7gaKjiP/qFQ6cS3ojQRzKTt7sdcxHXkVfsdlWTRSwCNXcT928vW /aNuWhd1iGI9zMSo1rChocgX6LCNIAJdZ4ZYEhU4jVrRo2wuXpe+4xjfLp6YhyDjSE79V7asL7uB /mN7M6drgQNdQ54ZaE9HbCLr3G+SCJvQNaYqDdlNBTh6M9bndYple//eMbS7Ug6eIHXlw46Vu8JX 2pPWBTYkVBwTA3LXz1eUrHmkPPgkmnuvHFl/cf6tjKuLWanw10ugkbqR/VseJmJIcQReWwLpm1y3 ROna1nzfSLKf532T9qbO4VhdbSWmUro5Pe/9q/ATC9/ds/dwL355CoGkgfUJ7Joy5Sac1/audi++ ME+OWT702u1hv0EYwWZodNX1mOotvxZlk9VZzp+IDHYY/grFnzpbVR8YR1AJ5FWE1+joLjZTgcaC eHjDBmQIrZYRUzqkCrn5sDkfnjGc0qT5XSyrjoP9c28snOGdGcrTXri+NzfnaB2EdTLRbVi85sd3 L/dQqvF0FS43Wp6yFgVM4OxtXkftyjWTRrihQ4xnurBzw7TG1ceah55CgRXKBHN7Oat4RC4gy4fp 3rLW+wppaUu8+MqATz7bT2tIRpbCIMAqApVhhW6a2A7BOk3VrenQDJwLECkheLqZMGPkvTwQE4Nm ak7YsJOKjtXz0d6PxgLp9zlARjAVidji7F4SCysg8tyyvuvJ2Iw5pFVeIZ1lx6/0NWrQpFQ3Pta1 NVPU5a2Q356HXkxQSG7zm03KBOBj12DiC+UyU+Jt+OAiyYfuVKAhM35w0HOsuj5AcmRwkTK0R9Dg 8huyw92uPm/J90FDUPSRaQa5pZyFkWIM31e0NNJgM6S70UnhC+ZC6Ogg3HYcOUUsg2d3QtzeRkqg 8dqwOmRotB5NWZXx0qJIY9bWasad1fIsa//IfleONwU+Mpbvuj0T91wGiAnLN2qKk849HlkYNieL 1MGD3xjnPonH434cPC8mTWGnPC8yCsFMxD8BDdRcCUjhbm9SHkUd04yepAge47SM2+rVw374cCOa Y4AsGBSUhdPmS3hx+ISdRXyKvGeVUOrr/Sn3O1oY8Ig4iDuP0S02256eXGsTWIP55eoMP0yBzHmK VJd8WnANTbFnUT9jS/CnGGkmi4z77qIp87s5RUCMsva7VxbeRBhtcXltWXfM86cNcrNg+mPCIu1V OgfwPbvClvUZYobfPb2izBtuD+Gh4mk8CxXYXYMPXcU6juJ0GmNSnmxfH94fX2RQbPp5WOyZS56k cFtfvUB0B8fxjGy37f4alIYtPRQiHEK9RHFt9cjghdkm2i9/t7xEBYK0JVOLriLXLH7A5nZcOtO2 LSkcHYVpFkO/bpgu07Fxh90yXAjlGOSTCEhZaMW8jKrPU7HyhjEIrwBDMCELHCx5CMx7fZ1yC0Mj F7TtgatEqnl4rizVFK/FWRMwhavGuuWuvkuultZ63xavI7eg0P0o9E8W1jw4lew6imkJCd3mfprV iPTcaluhMPcfCoePE7uJCxQ4CofZvAVRqQfBfkPxfcO13u89VGB/3LfjTZZnaVs+J7c8VSwGzhDI jlA/1BtIu7Wtz75bKgzKbJk+lZrbV+FmIxjZeEf+zJWH++6Mpn+6FkeHJ9BAwv5OYj2QYsWTsR1I immfXulvogJbpmWBxPZ8b8l78XlZo4NWlxzmOUZUzKuXnAEDUbfU6qA+CCcm7cAmdXWzd+kN339c m8y7sDcWVEQYx4saKlCHIxdC6lcos0YAgXqLR4qT5Qrfp/VoF2tZubt3zk3nVp4qYKdIGpqpWVMB ZNu2BWu93ZGNK0LOal2AAATB7la9pOigmoPijt+NuOWrM29PUeXnsxyWTwFj6qs8b1t2FUTKkXrP nqY0Cz+GfyL5ZLu5wfut8dgtFFj8dxktJGsxyYQK/IhtIyCzt/jhOAimHhyZoOghm7Mr0/o9Z2oc n7211dP3ki/Om/OecVFydJdeXphQNPwyOGsM1QAB+wBfiSTJazHqeZPYFiuyTkktnOjk642mrC9F H7084GG9euel5cWQxYOOBqmax5pPCEBoVqdtdF68A08F+ryWPy1rRZaUEfOlxwObHBw6X+x99Znu lKBYzSk6Z+WvTFCFGCFWSVGBvQo3PFBfMeHRdJNGeghskYIlmcJz1Vpt0GchA+u3nq+ou+e1/xMX Nuh1Qv6GhKs9MtxMpsdssKdwIXJhpGWAB+nlwBsTmBWb+HaP7uSw2m7kNyYC2IpZl78GaT1/QJfv Zv1moYWEbCtHFmzF+qFF7eHBQ2+brVzen+U4cM6Cbp8owwaFhkBEvs1EeXw4bpGVfFExiem+EEWJ rj3TrOOcqLM83OamnW8f5UFlWt8g6kjAbPri29aBQ4O8hjYcDo5faDxyuEbZvCIb/RsHEDcFI8WO 4N+Rrt7bPvfeTx7eH4pj+dr9TS8Unx1lQPd223aEJ/QEyTHf904V+tUXMP7cuoCKECuIHWIrpgTM XiAOICYoSqRhPtZnlLt+dT2bSlhPbc2j8AAqwDhDukAiywdmlZ7sUEyKp/ddmNKZ28SOrIE+aw02 vXAfFYA6s4Vq5AssXorWIA/0RXqpvJbqc3UBSmVVhamAzoO09oosaRXbI3GvOhJm+lEvKvq8CJsn v/hU+cHmoownyMVEp010SgnGvvIA216SEjli7seQQ0qiwtjAwQsvNf3hKXhzKoDYJCetXPn4wC2W efrFswhKdv+P+0Nwjtk8MEbIpAL2SAxi+Fk3+0NbCmx9A8lIPql3noSe5X/UhJ7qz83nEJq287vo d4EKmIRaKUUKXFgD4dWswpOZoVPv0pX0KYjN7LRQUo6/pIFuz3VDy7yWPB5TK+73ylWJSBvUvDyW kMJwHhYFIzCny5TJ5M7tqdGBtOBmmaBZHekRgc7z5fxy4Uh0dJZLSNkTDYMVzqOT+Mj3dYE9vcV5 gk2cmzWW61QgjsAvgi5/GzZe7e77EvmWbS02qK0R1N11MU5tYmcJ8jkI3pJF9tuB7t6wsPK7yxsR siolYA50XsMsu0WmUij9hBJMCIymDDkxcppXmpmPdMmUChzs9BAMq4t+hFzZEg6wDpE+NwEG7qg4 +Dnie3dPbgNZo7Y472ySxNQPbFJSyAe5WH0QcJIdKOjevscjQ7W2+LIXcD2P180n2gmBkfDAVC/f nFo9OrtYVSI2u/B13Pv04RNpswLNHmQWPiO8P3Iczl8rTTR1fNMqu+mto4szoEkT6HnMNoEvEaAC ORdhd6mAc6jOJrLSfX5DZEm7odpR1vyUIljaoKR9uMDn+/Mg2fvl7fXaP2n2i9ycV/3H3sgUxIz6 ukv5GOyr4w+MHFxSJ3RZvJ4pWdanQUhXXmERo1QjvrHn4LfM7ui9+o5nnZz6qQD7jpENySbYQ93Z g6DyaUGdh0MmFPYa0qfT5UHcxeh38MbgNEXEpaoLCmKLvFmHTopa6Gx/LEt8eSXMLEq7ldlardEu 7QcS9Hkuf9tHX4Fom9lWd0DExKi+WcpKrra8j5KQrdl9rlxVIvTuBF9u4Y8EsU7iV8MPEiU91iK2 F5D9sc0WhyfAin1MMuNz5zPq6/lxJ7efbbuLChQTkDq/48o2ZLUxxb7HQ0LPI7BabClWapsSuuph dM37A2a2wa8xxXuxUMmNKZ3Ir8n+Fd7wRSanGEzk8TuxttlJa4svl7u3W9fpcjOQ08LbRwZgRJAk zlsy0OgLEuq5Akt8kk4yrHcS78NiokoJkjcoL6hAeaVJbyT3dc/koei1t0hswSrdrK3ebfwXlk2e h6DKQr2Dtr/yJVFiZnjVOnASuza/fHKe93SjExUIPf8Eu1zWOCx2MPqQHUY2+GsX+b7wHRNUanEX ZN2nbVWh0cDfaekIGuHduvjMZy2OOq9h54qPHe2ZlO5MaWiLd3Gbe56HbSUZjgZbwR/TID/JkEwg 4hT/2neRykM5KLmKYFuT2Xb3eLuZVK8qc8v3Xu+wnKoI6ZhvmEPZgzlbHEGFs26cMhoY1v8s0/ja +VEog+kxqB0GVOCtLlm1FxqNMYJPKfZzDKNJJQo8Tp8rmlwMYrgKT7+XM74XfSdj0chfFIAPn91N Coc6bT4bgSluTlKB6vAqK0NfV7yiiPriUJcxpXbb7p1/6vWJ0Ga2G+VexcQXB03F7MUYB0+ykdCP LobIg9zpgaiAWWEnb2Y7bWF+DroV54PsABX0+CuYzqJfynrKpHnnBfPlkZJ3eX7chThpcZmoVMJI XEOKJ16Jy7x+6bDXlQ6uzmRh3U/LbiAhi/52ACwdtp1FBU6N5FIsY06YPElvsPCY8bP/qN/6ozKN JE0Fvsjskzog3j8cxCJZqF2dHhbRyHP24aGcY0+TIPrAKrf85xeCpypkZ3KcvcTK+3h4HjgGR1VI x5pQTE1SLPw8jKFRPyTEEhC7VBtRjCc9o1RxyJrK1vcHejYc14LyZcfhvC5nN5OJaQ+x8lkXP+/b I17PIvZZ/cJgyCU0mM6L+Et10dTeP3xkTzJ8JR4W2f9hj9mn1Wgra7vc4AjlEZ6K+D68LkWo8lFH HFnhIcoLtsTaYRk9H8NVd//x+bnOYwx2MxqUdu2EEWvHL0xsW0aZWoEz5MCK3PLFp/qrVOCOO7/J ffj85kJo3nLajjY7w5qMJrudTEkP+4na5RfC7R31xFUEeCu/0hs/ZoOh7jeU9lQdS0w7GsCzZ//8 qX2Cn7KPDzE4q8IIEpmUMwYZb+qvG3X0HXPZLY4EFtDE/YnEr34DjCGGzyrgTTR8msnKwikPxzrb 0W5RaRDgDP29q+93+5YKWaSGa9Uf3j8nMLNtgZG4BKgS7OK9S2eU1F9TAfFRZrbNwI6aFflgaXJF TwDZ1N+Py+2STAOoZnVfXmLBNr0kI/t8wkRFD0m0UyRmesvo0okF16lAkycRuzVSi7g0gponV3K5 5fTDhU7d5774gDjCajlHRg4SMxzqusPepiuzETJ61rvb3ULvfvdQ6Td9urvyBR05F67pinRGnnVA aBN69zirLiqgFZ6417EpoXK0cnfVOlOB6/OValvlf9rDm2ygDGQoKLVW+uu7sdVXWCsKDZIVe122 pJ14X9Lx9Q6zN+sIiQ4oKrA8yjXzIvCuUqAOt24E1NeOHhNpOIyJwogS6Cbkj3xLXRppOG/fhjho f1rOGInG+R1wBOiyPFR7CZB0LwjmSTv2LbSmPOwjCjKHfFniiwn8smSW8qLuhgrMsY7j3L7aYiog HS/FWYhNniZFgIDrP4xK/KEq0w1UYI8oPkB5NWr74TLLev7pkiaWR2sZ7CKuY20CJniuu0y3q8QV PjTcDsXKmQTfWLeD2PeEvDOu0pg9uQs/RWpVOO5kafzmEMtqP3OnXMn5rgQHzyCWIJ797Sf69+wi PRaHZhpsav7uQFZ7t2FUwIpjTQn0UQ2gY8TaoKEYjA3ShVk50Bpa1H7/AfK+kvi+mPi6iZS8JNLC f/5EfhkBxGdZOyZQ6le9eRwyOugmV54mp2R3R3fDJDAb5wg76f/Eb6Q/9Qls860MJHn4GV1QKMKp QBUv8vPvnZ9+fFRgTLJcFS+yVrhAwgymK1CBJQpueJvDzvUk9oK0DGw+gOU1DRWA4pXMJ7+OZSub TBvyRzj7Xtq+/SQ7uVf5NX5u5HQjRUy4ZgR0+Lmle+E7XX/flA74r0WBzb0HDY+n7PSUqqPDMOSy qDEuylFJKlD5bB0KfXMhZsyog8xwWm4a+UaxxI98ZtAexuM6iZZ7nzpyEZur2nE47z6/B69GISJm RUFGOHv7MkkxcTtjnZhIQN6/lqX6uajeoFyu2PfJrt7PHqcFLhZbKYh3LeqR++x45tp5TCGqzccw nNRNOqsXdDQI9DwnDXFQZyIV+Kdj9BfheL32Bl7YNdLiYExD0d2eIL41u0wVJ7Gjj5KIcpZsy8K4 +5ZORqa8+yeCUHMQoewh6fDBrERXdWUuhE4n5UjnZgvyjfDd7x+2eT/qx27DQs59CBuXloLK2Uj/ a5jwc/Le1fc3V1/W9fQMjD9iDlqf26ACFf3QO+udFMfyqvJcyg0sufOGGQVEhkFUgKEmGvHoCy7a fMAhbHCXBWzPcdjrA2zmCVlWUro6hLxKA8/pkWmtyTcarPANnevkYk5orN/MR7FbFhKfV6G1GqLT E9s83fiLxxuR+xqxbMkiZ7bh406LMsumdHPvaCjpdT9Sjg+xi6kSckC5rPoQrXegxCH7SQ0nMTe4 LlnsY9i8vr4KE2nXJbaKXUPcwhUxXzoSX/o91NtenbfyCn1W0K6pY+Un8c8nZrx3pQKrtiBafxxK EAGbr1+zBn+AZEr/xoamoJYCS8ervyr5UoFxih+Xux45egA9heiiXECDAS6Wv2GLc/cnH2Q3CmU+ mz1VjiRlHKGYbFIBfmTNAoW/FnMZPQ8SabYMrRC9Ko+mGIRSATECMhQ+ARKVzZ/AAdKChDDPbs/I ppgiBKkAZpvcnZkFq1mzDIGLrG/gdq+3DcUzLXEkK4w0eW0IMsnbC27gQjtZzhYTKsp6deXf/dKe qWzSevFTDxLFDnP6FAi8Do/wIKzGqMBFe633OehxSIH0IIvf70Q50NyzYVKz/Qy7XJOpW5Pmf375 c5VQ0E359qpi//q+TwOTfPDZ1UtUwHRnkIf5X84juRmLrM7xzodF4aNWe0sup98p60SrtEUqCg/6 IO3NsKIfkdn5oBbviL8S1Hd53mGp0axofRDpft0IWcqS/26A2MkKWakt5YH3fTjpwcHtDc4Li9KY 5gHMhzDebAoAtm7OBmpmCPobFSAex4bD8LFyqlQAKU2BQlo49OyTDelYEGU4txy+aitnRAUeLFdC rrz516GDZD7Q4nJebSdnWFGBT1ZQU+qjTlEBrouB5Cz4ODSoGg3pzwYoaU/GkYNJFDhopMZGwEK3 i2fAp9mWv87GukkxBAOH076gZatlHkATax13VNnXfxWxag+WNICiCEF1h6Y+IXSdJj2pgGMSXpkK PH8FCs/tCqgoe2gkZFuTCsg4NJpVwN9TgVbSlIN75ggxwWqgHoOtBbM8BAaIwZAbScdATZpAroQr xMeltfm2YwnzYlL4ISODjSw+NJeXZxt+ZKFdIa/vDGQKBv8132yR1WXHU6NsfPe39PlRAVxzVS4Q 2h5hs2gEGtGXKDzEe1t1MKMMCYqWl1UdUkriiZSDSRqiso3lDXmXQxRa6QQVoINon97+q2JRf2By QgAw7tnEmYSlAvDumkQFP050pM+UtIjWcsv7tN0iT0Tw6TGiemS7UBsiS0CrQNwXJriDv59tKO9m HLzlZjtWePWbDXx+BT6C7CUR2085LTERKkKvXwS1xoDk93xs1JttCHkX2T3VWxllMoj3Op9ChCsU 9iIRFnI+T4IBEfKNbfesIhaKEobFzkezXAe5/Eo4BtXjSWFFcrf+sHDnoXCOrK6PaFs+07wcdIwv R0F1I9glgTZyXm3Kjkk1zRT5A6FQ/BgNW/CpqUtomnQ+CI1b7J08apSmsPQv5nelup9mfJhKgrBU L0Q+uxRStQ6O3e0Ocn4GD8OiFWayNEpuCNGi5xM2TFzBmCZqW7YXDFHLRZZORpHKMOZQa78dctis P1FDjg1YJynFY95iIjHuIJ1LQYJubNl2iFeqo09VLVCYkFUgm6C+Hryv+HL7KDm4GN1cQjkDWh+n Ra7Wt2fNLhEUzGPT1vljxALG5Z24eqKfOPrFFLuCUhj0TIz3/nYXMntm5PC61vuC8tiz56+htr7q ZF8+ZTkQuSG/u6q57PQfTau6hmnteK1LBUCXGdOiELwm5/paBwba/koIj1RAuluIJQnl5T0LBYOS JsJ+UKP2oq4sXW2kvJXrM6UCRVAHFkbiXw6RZ8JIJz1SQZwgZs8iMiOyFp0RQXaQk8uRoKz57Tgf 6MV0KjAqQlGEgqCq2mFBDdsyu+TZeyHpFZ433PsiQnH2PipvBeB9tvehccIgSO34kGFUYOs6Rgi+ etEjlEJxIENzVqC4AXG5Ha/JRS639ECOd3hkU1aHfSCtifp1auZVuVCK6HsU0bCZClxuhlgeLG5E EfdiI5oia6HBERnIrM3dBnETqKjFmiQkFaipqQS1ad2pHXxs3vDrEGshCfQyebe2j4EWgKsQiXs+ DNljPHkcPd4PeoZCOEkNbGQnFJJVJWK+YSnDmisglfdzU4GRGihame+DKLV2l2KzgfxKBd6h2/bA 2olSfJ/s/OAT6zAsZEuOQFwbQVAOWBqo+cuSKhL0KDcrNwtqWL0su87VqVEBIP3nnJPi0H85b1Eb gTdSJTWHBmDwYeWDoD1tDYTIIwQxwxLksgRlxGcFRJGccHtkLZRgvvPXvKgdmOJ1bO28O5/A2nwG +oP0CmV/V9d5xfZVFSrglUcFMpf1J+X2yw6rqXKfINL5NmSb+NrCxAtqlnnl3a31jiLhi3AMm5en AzkOdJJh88KosVmUVZGfO5/RQTgWCZoni/MP+ANwsAHYppfbVxJ/BVgnNmJD/qkgt+DddGTj7U3z p8sf59HYZ7MNPwzJOsSJxQv374+NWqAWfcswCMX2qe1OvHkcfiH/7vHjKhcnzxxfRMcIgYYf9uBM ++BGVMTTsx5JPOsCbIqT8rLfzLJqL8cE6SHWUChV9LUTFCKBGFq0nnkD3T3TU0z7LR41PwbiOKeN mX89B0QPte46344V0YpZUFbPFnyRh1rYYIpGPsKd9HHyODxZra3Kln81hnOYtffcxoKGVv8N3PuL jzKloT6k1UbcezmDknCgoZ00M/PdG/ncLWQrMNEPKkOH6Oli5PA5VqHsZTlFzIYiEtpQGHSbb7i0 C96NKPB2K4I936zsXcvCIjeWVpEM4Ry31+RshJ1Lb9920Ze8SQUQ13HPzJccmq3KuS/VPs/Yzn7m pxPhdrRIPixUNvYzFRiy/BH4RzvWj1KBp3s2+xbap3PXxK9fhgd6PGNOJ2ruVe1oz3tWy4uZo4R5 QBqaBk1lMgLt2+4q7D3tBIpNOdy22yhLErbGk1ou8dnkWhfP/c9paA8LEAZFh9l7XKegIcmPqPpX U2gzJdFjN2LalVmb8J9Wq0MFgiMasWI/ht8v6gJcRHSegYd0662XcUebxfFt35wa7bkhy9ORAI3V BWrbyy53LZuj5ivE2IivF9tG58lRgQRkizsoOoNQOYsXVJVVXyTExyccPn6/2SkrA2DJukQYioCi B0ibfd0pIOjoV/UFg+Pa1QE4CAqgaj3a8fp+zPAxUcTWUnA/aF/VQTTQ4I6FurpMf+X/6WU4Ps8a uWQiQWaWgBp7rhSBL52EL92nAvt2pm5CbU4KJImwU4ahae6gw2PFgbiwFQ2ZJR/+XycT964VUxoD JqMoAubdoIUQ9IRs0QTuJTRRGU4BxXEVWkWjDaUhRCAF0UR3iWoJ0hUbKuDDMgP5dQuoai3s20T3 G/Po6fw1VwPOdP6WpiXztlqZ0ZjNvC2WdiJ/XT8XFCNdgAhkh8RrwB9ccwgNQwgqnL9zljOouGzG YcujO1SrlhiaKKO/QVwWzj2sjJu1Wyc4QANqPQSFf8nNC8gxM9i6uAIbclwF60SekIaBTwrCoBJB i3gcTfTCfmUjGZNzQTMIZZCh8xek0YmpIfjk4qMS/fRw62cTKGc0i2cVnoECvcU/laVudprtPTTX 36GsJyCHMLE4nyf9CU3kF70wEyI/+YqrOUOEjMhPxc4FvgNNzNJstiP/Z4IJGWTnA4VaD9xCAi98 nGLmMxeYQkA7aeFjUcSmDL/QDfQERQiJsMvM7q3hR68ixYOWRgU2nP3Pu8FHPKTbK2nQq6ErsDU4 yFHJZbpa+PyaTtRlHh8P2oJ2EqI9c0YW5PQZHpm732HJkvtAyB/+8CIyx+mBUldgBzTO+5+vDPgB B/Uz9MRqSjGDjiB3Hk5cH/nVUkuDqXM2pQ89mIGKH1qywxeG4lsCZ7odZy2FYEco2lUe2/cwFU1+ oEQ5OK2AQrWAld260DPfv2fShiS25e0Ow1ABO0q2YieyIAaxQ9uGgWb4ImwN1N65csopSrZ2kQcI itecTJ/0sy73S7lHLimFNOg5fs9DqBFfPk9rJJi+Fhr1qQv1YFsQiBMqRhGMCftdQNdrSTZ36Oky H616Iv9Hz/U72EoGOpjDHZRRXv9bt2YL9+qbhMYRuQNPWrxrrCriZpyePJSPXtyZGC0GIW0B97ek YTN43zByIMbPjCT3wD12BQwbbKbQWbN96FUorPC7pcBF+ryQHY08TGiedPya+txhuXHgh4IehzO2 QObi6erBBlv9C9cWxOQvCZgW7zpM6vPJdnP5O2q7BQ/JhdIVrriXp8ggXtWNFlFEpyW5r777/u4j 8CLR85jS6Y3L/slDrq5OkE3Ign9Iab2/jp3G3MU9ZXG84r7ZfsOdIdNp43Zuowi5FD6CIoUSf4dJ PlRgJSb7VSQGhNjvEQjshwEYboZkU7McO9vC1jgM8L3IfYimpwLQvEbjHcXV/72zBb9AAjUiL2T7 CBV4MVGABBEGVHE6CEIQOJHVxuilQZ580B9HgMgiZAEDPrMv/VXnbg8hV++0gFFJEYLACc2U8LV1 Qa+6fkMOTFCgsdc5NASKNNnw2iLkMgQY3FP4+bBgVaL9IZS39SullLOnnMgRTI0SpEuVGVSgQgUL ka4BCxpyzhYkOQ2MlqFOxo87fU/CFFXk1jziCQL/vJ2yxdMOpjesgzh7HIytbsB4TzHqjVOBZtIx /nR6rWZQQvPEFVLrcCM1MrQNGzaqsM6dYAUCut98r2wfKauCkd7OUYEIE0mKOJ9iBTzY+gx8vXIA Bw0ot8yATw4tQA0xDnm9LF6yzdItx1Yu2yypVFLEdGcsYcRHSex+strU6HmBx+fOFlKegN7vMjSk ff7vQNDc6+7vHQYvBQ0VqICAY8Jjx/hewFkB8k9ddBSOH1Tg7MQojiLkCOL9EcnbEKfUIVBoTAXW QNxWHEvaRwXqQgdhqzusLPhrf3MXpnxNfpEK3EXPr80xRV2Rmeas5QkPf5y/uGk7GgsH/BwoClOO KpE3ZYLMbuisJbhP87vNvyYyp1PWwJh4kBxIXPCJdMDGJpSD0Y4bD8FpE5m6YbQ2DK8LBnEQkQZp cUhi5N0EJTvq5s9nEy/mdCpABP0QrmPN2dvBIMBLQcCj1MSWuk6nQrYpgx90qYtI3/ubGEunsfdB ZHjvzJBnq9yjy4uYXRwUzbVZRXrgJWsRa53unpsax2DXQL/59Cvu1fAugus/XdH5F8Xi3RLvDvJd DMYULLBtc44PEAOYj9PN3rO8KyhDBXhCt0ZapEtbY1oOiOyb2Nr3hQoIdouvPfFFt/a2uU4iDXrd cC4eSNOe73fQmPx3w7Cv0BqHTKwsOb9ExqNJPZtkirZJucRDBZaQ3bOy9PIf3B13GAmzEwVjLGQz SSQZi88mVMoOpmwzbKhYWrqHUJaGJpixH7/UjR8k+zrn5cJXTPpgm+TxqHLJlB5le55NtvuwH538 yLNntvifmFbBNaoQi8UmXMQn3vs2f2/dld7pmbqlhHX4ONqVZIM5UKek1O9jsFLysdE571ax3onU fp+cK4+iG7Uqj6rkMCQaoDchl7gN3yo2xDq+WFyiAp3k90++LZHJPYNo18Xh4SBdbhPX0yUnq0cD fB7vSNslyICAodUbtnWTYVhzQMGaiY/3x2cr+Ib+UovKoMLcF9ND57VaBnxj0AUCPY9TfLoYmM8p v1FDRd76XAWaRgGCZlUZcjLFbNTHKUGOztEjCuGozxI4HG0knNepkfn1mqKeO/zaV+SX/VAgHyjx 68IqO4m39UuLZh52UmZKIXUT19feX32mrThWW23g2Joyy7nFOEEOhqKcAjjFG97OtH9NIeC+7zn8 U5Q35XWj1eQXz1CXsWmPwILbXqB1KB0U9dZ1eCHx6oDaqXLVpVq3BVv53rJu19+FpMN1m5m0OwN/ Y6WGOwbT9+jlMjac3WG5ZdEXGS5kys9g2y+t0nT9yA9ZvZpzWaMwzWk1eCIkdojfJ2L9/2wX0RFY C9u4MPsMU63jIn7pHfHw3mf4AfezDrwto28HyRGFfPPShgvPP9GudjXA5pmu+iKg6WXZb7a2+okZ mbi3KwuxX79OFmFv2TuMlUmbr9ROoafqSrckeoMgyw+D0OAWRRPZpnqMVIWTR6rj/DVPlCgIOpnm W+/37bBZJx8pjUnwkvFoYc40yhZaBcqdT4SfCq/gNISGDZA9lRG9ww35p/ledBMTHLfYEI6+NqsO GeUeVVauRE8ZZkZatWMh82qVDTIEMkTBp/Bf8YzIduA6cqLhS9un7GW213Ld0stnuuoKtsrk+Hqr PA+oGPIl5EtHh0opa0bSYvrpw2sfZYDOwxEegVpnW2abliGNyDUX+Aix5OZIz9SKdT+fo6SaxsnZ WC41LMc+9fTiuMSUM+XijtKhXzsvOOzzGb2SFbodBWNCrwp6FlNWo9kg96IGKRjIjjcIcgVuNJAi 6t8HsgBiYnfKP8wBhjilVjlX1Ok8forDVsIsudGFNS5h5UEpHfjAoKE/Rth/AfuU6XsoLnSLMm3i NyAtlYns3nLjWzGJHzbqUMnLoADI/RRUKK7K77kY7kE1yOjAGTJ/5WixJl/SdxzoPB/yIg9RPiLr /OapgG+QOpaiOkXmz2QoFT1DyR7sDnTDGSI95pDNxx/Ce4ecyp3ujT3RUYELzioofaLfN3eTPeTV 52vHi0lOJGTDkN/GmRMN28j2H1cM88TVGqYo/kl9JsPo3C98vMp9BReh5dJ2/3rd4if2L/AFouNU xdlQ0M1FJArc57sOW5enmJ4zA301N0926v0azwD7yu2u85vGB/yr1ngG2VwZ67hfWj4d9VOdtyHK XDSZ6lbbWNAj96+WF2zx6x1RMil0QSxLktGlE7iPiAZS6HYZkx89Zj5lm3BJ114Ma2LgfZFfY4RM bJOYoKiShn1mhamAAby9O8pXiHIzJmmkHMvvqcIuGDzYVy2JqHvRIa71sFS6dGvPNMo58ypr+3GD hsOhUpuvvN0zmJmM6F8h60iEYZPUsny6LjP3Yg9p/rfPLvoP14uqTzTsasyxFm7ygl93yuZfVX0n U+PlKdbYdfA7janF4wLa9/OK+eTz3aqEko2zPscX/P7i3TIk1kGMdN0AKSoNOkIJiuySdNY2T+8h z4CcIn4x3fPE3kwBp722cWp1csyZl7kFLgaa79ZLlAGlDUQFX2Sr7iLHUROUnTmrUC/SbK/v9e3M tegxw1U5zISMs6N4ZXbja9dDz+hcNmPdIwvTMDywMOfqnSU80huqpFMSbh3js6lVWiTNT+2TiZxy xYkyYYNf2JJ6LTwEwjng29KQBUjYGdZKw9Pb0mTNo9+cJ73mpBwalLHmpAK3kB2nCyEbZegTReEI 7nlTcEPUqQH7Qm7BuTdv1+qFrO6RQT370ZfBQnQFhFXivfRxzDXcDKQt4759FAcqIOPv8yqErtRH q2jGcIr7nVugvgXGaTN+Hp7ivWBNodQX52XN56WOAhAKvPn7hP+iZ5RLyCZ2kTU2vyVsNPpIUfy1 Dem6VuWYefmEdzWnQlYXM+0bvCqs45m0yxeOvYgPrv9UYfrMyspwB0LR/CqZVWAoBQZQiwlVasjx B0swMmmQCFbvEohZwYdPUStvJYge9SDCqktcQpAnyqBFtCbiv+bwzhNGuiEJ38qMojyNgizwYVMQ RazBtkpA7Ye8tNOOU6qhsL8A7TK0jhzU1UAQxINoH3Ialb9Cnh922yZU4M7XNU0wwpO4B760vxwy 36vEOmRdPjQMicSH/RsDkVDlOnUoBxGk5AyZl9ZV/iT3QWYTVINFUuBkr9n46v5P7UsPSHmxfU8t k5JClflk91cwvArXU5089twDcmdvfl9RGTJTg5mGrTONJrtZU2Q9GVWdlkhvbQxNssGwDDuxYD94 82uEFfNZ2aH+t7VISAzta75jVj5/P/Nuni0CccDllCnjx/r5OZYRe4ZnMTywHNGXoM9k3ZEqlN6O VO09o1KwydWk8g3Zlrq4FPUZ+UIwN5KN0AO1xZEUBsJDYw//6YY7pzEHKOcnCOvfBSlUwNPfRasR 1bFLkIznoWk5/BRthCs2wkPY2Nh8e3v3MBU4QTyMLqBc2kreWjIDA2SClae5JUX0orF9ZXAefBoV AglUDhPpmAhlhGEEhk8hpoB+XkIJ6mIFT6rL4NOmvvygww0ewRDr7SFfYwutuMuAUa4jt9Yxj2H4 XKIlBeocQRj+ZZX7b/Mkr4Nscwtpdijj/UKCFpmNx2KdyhtTbaBRheyU0E4SfGaOR6+7byZ1b8E9 5caSoxisf/vocL/KTVQ+adhubmd0b5swo1608sBpbcES2YvOWdoiigcMo5ohS07PnB6QSEGUFSkM pR80KG3xxBs/AlEKHI2ZXmVb9TcPIMjDlOzPPbwHV4gtmnFzH5m8d0QV1SBvF0IzGhTgs0+chgog hqUpPoTOsc5QIvw7f4zuhNPd5rDItc3Z288Sz+eSfPgH4V21MLKpTv/cDyFMshqf1hbo4qAVP4n/ YdSC8ttF7ooq3qfXfqFjb28qbNLA1xTE0oEysCUycVYocOwcbH57c5F3gwGLeTUMRyusFcsU5qJr +ZDj09cWEI1d7n5MnX3xvSgZZvcrPnGrNFdTs5c6kM0dnbbs+680zgrVkphmeZURI8m99ZwU1tNb lAPFP7adso+O9MiURJ1bupD9DraZncksJPwQCd/ylvLRsVySj1E7IT3CzvdScZNyuOwCXCc7jydj ITqCkOXmvY8JL1uSF3JaTgc0w3BNMyWCj0hst01yAugje76d2No8NUz4jwsvbhaAdit7kqHQ33hy HX1MQRjpWVY8+fZKw9sRHs2Twl/dGzwjDh1JCle+IS1NES1iH2hFGjy3hKJVTmJgarlqPK7HJ6M8 6g5WOxNTft9gLdrEbVxlRFWFJrIr7UjkoxLBx1AweYj4d8FkDXtgVvPUGfxFMVZNwZKzXqGjJfba IizkiaFSzBYMmgVmYo88icVrSy9gLgSXYuAtzHTh/eV0PO+4K5NWPzULj2M05zdw1783WC4KJoYV 9M4ypQZlZbsvF9/74tDC2l33/ZZzn701E03xqsj+p3WWZxY4mTkevbj2eX/85/sMZ6ppaKtrwhoh s2by/ydmNPBafPL7hwQe2BZmbccMGJAw6DG50qZXscjJhrWNgZkjJHV00Ba8ztTieWT/h2sygWqp FobK+lyD0sZDOSc2O8DopDNBLDCrZursoYs9bMeKPRlPIxlaLFz6kMvTU1/9kNO7ZiCLmPz3kzgc d1OB3Y/xQWsS1p46t32/jsg7vB4wO1ZVBnPeDDRb9huYcJDGD3HwYG85qQv1EXkbjvtXGRdp5jle Tmxp/OQ16ZPtJvW/ZdD+nNTW6XbcAKzNTcxSKxVQwN1Xf0hHNpX1XtYQY4Lhs95LbrvVWFDWPtM4 pcJ6AywpX4gCJUPKLzKgdU4w8zdLHkunbJ5TAZv0sG2+tXtFGcKnH2gMPUesTJBHwRicvRSDii95 8Sx7hQCiaOb5u4NeprVd+oA/Aj7ndsVlsEbuXXo2cWAxCu+PhGPNV8f9SKYatTCdFWQSf4yaj/93 A33Y5n1KlBY+szG6ptuS0lR+jAqggswpzcspml49ipTPNB3MS8+/PaGJoDRslOVgQNQsse5WKssS 2t8d932yLqffQgyZ+UhauBf3JrbX55NDvsln9tj29h69KXYk1/X6qca1fMn6gNrk8957jRCsmcsf 0mWbrhtozRvyR1Mc8BMjN5TpJXGnoCnR8GtTpv68m40/1GYgyDtGUWjleHKKvL/3aZ/SZUlKdpRe ZXHPjuAn/K7nIUcNCLHwHvgqwud4Q6B2o9fhVXsKcnpWeohn/tkTW444OjwvGz6l0u8cCkK5wtHu wQ8swbyjE4OFSRyRhsRRiW0YFtbbj3qIDNzegD0jayIzSMOn5mQkRvxUN2CrcEUsRhsZsL1x5PH2 uUw2AtpGY9FaX22X1QQZicvGhzpcvE1a/xHapbpAga27xc0QfHS6q+Lh0Kq56DTz/v+sY+Z6lQ5J Et+9DrNmCVoTTNmysR2lZ6cCu3zbdosMnec2PHamOb/Y+6J7tNimRAeX2ZWwzcLK3rIetskU0jEe 5tepGW0kxW2RiEGxk+cCsv0VLWAuDknM/qxrfau6PYHwzpoGCDfqd/ejVmJQ06W9HFLTgXFb7XaW 0RtTZdElHg7R6/XfFtmyiZBOc86HTi6ROk/Mu6uu6FVNIjbVX/R/hk/GQT3/z/jRlMvoVk/fLsni 2lfJrXukeItA02Ue9+UMHVlDta9lGRkHQBpws6EBgdeQcVreUyaLeUMFjhWFfEm4sma1Fap6yyQH x07epb/I37Dy454MaUkRMu/vFbiRJ3WewhnvdpTHe9vxR69dOWtFtEQ2EbEFay1dWejCipNH7/Rn T7mcc+gbfeWskQsB0vy/7am/O9aPXIlsDx8k5pcr+X4npcxedWfELzoMV+bgkcvW69ZfwLgOV4wb 0d94pjsnwkmPWYUGrBNhZNrbayjKWu8n+AbLCHLDCcLL+pRrCJriqLUJfG7ErBixqmjGctkU7eiY 1SyXbWMhIz00mC+8MiDHv9uSWdexee/glWfCTbsLl+39esuKkb/UrpPT8PWdM5EbghS93FfoRbdI KuDVAyGpBAYESah9SszKOBMu5s1JIktrg5Lps2dnXvI1+Cw7G0g/3NtK0HjEOYLqkQCNABcyrRXi 7UoV6H2lwCA1OLrXY2mJCpRIW2vm5fXLdxeu6qgXTzksVZ6SKafROR2if/Je3QsgwmmWbWfm3K+i t8fT8Gv6omPM0nJZbff1iTUQc2ThzJvr7kx2/OgsWh9w51EXstzQ5Ve09HFG7/QF61ynAtUaCrod et+zidKVu9Pl7tFZOTm1H61NjkLjoZn3WVTg76tdzLa2je8tpRwhXZhle0VscJvwjB2fl4+Tphi5 O3zW1HNYnAhulTK+axlJHyQRcu3Qvs/xk5RYkJTy5v/gzec/U+xBpIp6ilI4Hux5f1NaPKAgYl9z 4HJMqKBDVUtN/qVnXG+TuJZw6duKRmaNB+d3H740yea+XPhqmwP0CVrbPMWJWY2+ptiq4qW9bC9g 3AU+lmwiZsvHXOTvBloos5meTaCzvvs9J7d41CfbXX84gPSSCnxYrk2nAmJ4r8pirs1m9+XVueGG TSrQBI1Qxq1zkGLAV6xMqYCd6ooRmh6JEEaw50uPD8659BZm78D2DvTKh/ZpmwGOg1oVW1F6JO8v Qg4iq9pfFt2H5CILQr9LW9c69j01ez6hl0pJ7oVcdz/TaDtJhG2sod43hCmX2JQvuYYpuP/+SInz TM5p1d29xny1t20/qEmLqqgtGIs9pKwdDjUBjKIhD2yZrqFx89CJNNu0SItr5x4yxQG7rUXWoR7G 1OztHuRJ806KTbll3GmyzYCcYIbVPG/KnSlXFrTzYP750k0MS67GlRe56RxRdeTWyheE84WtX0Cq P0P+LWPBAAc0V9V2Vcokg23P7wjBYpFG/6jhQ/yxi1qVlWt4e+m2EebSYjq915n7wq1D6D39uUyO X4zug4Qls+XXoQ3ELzsYdondogKZZCSGzd5YugTELkbsHadeMMtmEyrKTiJPyDwc4DlQERA26WwU HcTWPk0Zl7gvw5T7+ul5KpCNFFz4TgXeOnR3hcehCKfSjzRbq1hkYP2J+BeUM2B8YELwuwBH+C4N Y5M/RNrD8glw8TyR+cuTr5AZU53uocXSfuiGRvj88vZmNoafjzZ0E1mxuayah7cmdCpRsle83Sw8 OXy9UJve7vM3y/Wh3xipQW22538TS3l0igcZQErJpM2uvT/f6y9JSmbiCh0Y/FBwgKbI4GHht8IX AhHtFTlbKcM3cGk9F3gKyLERsONReO+nMtrawfo55qNnSCU4/s9O7CWzrufQnlq6Waje1W2SLScu kuvAizijV50UUXdezGKHSdP+iNB3pCo/Ufms2eg/woiw8gx/B7NPmhlS0Q0TTngLUbjIQzXIWgrL P11zWkZ/82gQIfQhQjO/ja4uXhL77jx/CuUZ/sQwgYwQf0jQ/iblLmBohMwGBZsNF+qxcnBDUWFx dDUJ3j33/dHLEa4Z0OM1oLb4e/Ga3beq/DQ/ghBl6jvq4RASBSYZr/Dpe+G976u/2yrIr8XZL0uL aJJJHRUYBCM58LF8YJsi394Kz9mryakVIA5VpBAXlpI1Cr1zSm7tmlsfEH/C999hP7//ozcQv2wz 2enyaZWGQtxEZi9lcHx/gsxoT/Y8bXqcFzleJoySLBq0lo0SNNGw27RUbnvsH6DGy+9Xaz7usOQn nHiICljA323MK0+yfBVVNxS8wI8OqVLtTZfEtWMw0xdPg+Qntt+46NQ9T9NOqDLzhIR+WJE8EQaJ r7tp6cJIc5nSjgsQWQxdk8318UPWkNG8Prwub7HJ7go3dnZ4UY0bWVgBVaI7ym2ZmFmbZvj5W95A 7Wl62OZXCkrH60XTxbY02uP3eKnAUyrwqetCeXr+j4eClFMJuIdNrwqlc+BfMORQAmVq0ONYqvcu syu5HcpzGgoB5FAiJr9PgebHFTSXMrrcx92D8/iefQz+qk9JK+cn1nZtWRwEmFIUWwedjV6+RHZf X5vP8WSdal3WCDP7kN14R3UTV/UpcyBPXpUNnxXtN5i5Mxgk6rFlGdCwQUDW+pj0ZlKBnd3QuPnQ 70BB3sKs8pNk9ymuuN3xiLQZ2cO2sLH1ZNtNKnB81h8Uzi9WVOA1etwvJfr5rJLdV6RCrF/SbMN/ vqFcnE6JDybJm4dTBubp0YvYtGY0gtm9XvTrLpauP6ub+mngmW9irvaUMZ9ytnUltMy7QyZZ4Ybv nW3mi43fkUcIoaXz8eIuh9pKFiuDyk7lrta28qjfUA76fOGbJe1ZRTf+aI6NOSgm+xCk/fBgLlCy yc2dxRdA2xE+3cImQg6ElLrxX+58dy/d6umIw/V7azR7Hevf0lwrqFf5kBdnWmLMvmBBy2yMSgED zRQD3+BZx9VvWFO4jsd09eKrXtOplGosgSW4bG7d3URHRufIzSbeSFHW+VA+jRwZ4IDDZjG03jnm 08CwXaecply/fH6VR7vJZlt/okZrb5WMB8JpaSnpeUJ0TTLvsKPhJ5HHGqjTx3cBgZWLECwyXOTD 5suJ2DiQcb3RCU5OWmFlZ+beDMql3LNKzY/2lHwZOXnT+7OhHm+7qp72uYOyu1fL3lxMg4gHjZAb C72+rBn2tXiGxLSzV5PiU6a77m02SEfWsi9brO0tHsIDh+aH+3sfZGIKrEd8rE7dd7sharnMl0u/ VLqaeyen+83mfakrdpNJsTJK427oMtxld8nE15/DSt1cBRkVEC2h94m1jXN2IQ4bozS3QVLurN1R dcxsfTzwYLEe6Wq9Ooh0Gjsu1GQjeWMoi2v/i8G+B0c80obYe3oIaWMpd06lW7Bfgz+UAHVePrBS GmnhICq93scDtRMV88z7Ff/cQOlL3i1mSR0GK62D3fo37O3kWUz2lNkecOI+eqH7e/ROS8t/hWgv R+Rq7OyvGqq6OgU3PBng0eGm67IqZpxpvu3cp2E8/gLRKGat+P2EgbnvK7S2ODRrI44p1d+epIwl 9SjZb2Q3jkQsBde9fKuWsWIimVv0zOmUloALPcJSXfDqWnqYMxMENFXk5MpOy8nRIEplrG8GOiyR pFis9WQ+DnHzap/ieVb3g3bzAm+SW/e163rXLz91HHt+rTm9Foq+WNswYJ7SyRJ+9nzdxbjk1jY9 nRtPh+UQEoofvlilpaWfPD4vHNd8TV9LUY+Xwy2vdurOkWPBkZ/1H4G2T5ytWBbt4pRZ092n8KW/ 1Lx5wBjvUp6RvUqMYkZUSI/Iep2wCCmWehiflfrNcu5qYc6n8Cu7+PV1HZvYynCanVdD1iqefDtG w813pONoZ+LX+/vCxlw9jrwvtcRD5tV0LLTmcEPmR/G4pLdCJ5++UKuu4b3+5MUugzyMGpfQEMp9 Oe/v+on+zRu/7PjaZWfsk5g5djzFRECzIVA9s+7Zp6HzZYtS7hJLk4Ine4GRAe08zGNgS1VhpHhG cw9q07ch5SahtwD/AHSdk95xsNd8Yu/n5TEItTdGg/0mvAo3cQJUQMnpExeunYKcpMnrCg2iVFKB Gh58WaNZigfXy/D6bqbn5JLzX/kA/4nMgI1GPUp2UNrRL3bX1NpJCDOi6Cwa2gpuCkFyioAA31Ny SiDcPRSGRY9UBfRNWPQ/VkuEbV5HJ323c08O3fQtu8jno76lRGFCzLVWTnLW2DfvayekYxQ+LQ1K gAG3ak22HU1CHLSzbBAZ2YuLcPb1Y3Rk0I1hLjQQsHSnqBVvTuO2jhbhaUCnw/9c/MyR+dTyGQmS pdcd1Q0SWYz8YGZ1sTn1pt/XSZZhqDi6xmJoXsmR2PDwQ+4NI4TsHVcYIpxPSqUCOaCjIvllLvRQ gQG2TS/+V6xdhVbGYJQDgo6fNty1jHjwpO6L1sUg8PXP4jpdPpfq3886ABmdnzY1quOg3XMaBiyY P7gdeWi7S2Ekmajzy/zJv3XLIHr9iDouPVPDFoQSUNBxtL/f+n2jwdhK5omcr+rhmPb34veJeo5C oy++NjlesEiYeERSIkFTbFIDt/3AMKTFqNUhpZAKvJNYN9KgAuF+cyPv3EZikN0+GXIlTOZuI1+G JJucD120ZoKJnnuD9io+EJ6uRVdv9b6x/AwdGBgwrNNts/reaba/V9WIlyqyxLuvtWfa5kXXpMqx peA45wb7GotV2PnuXVXw5NC6GDZl63JNV0g7PS5KVGtbEEwvSfpY5b6MAaHY/hOeNvcmOvkwlRwV MihNz0IGaQU0t2L4otaTN29WHHfZrn3e/F40Pli6R2OO+cbNe4Fuh7kvgcDeqQk5Y0CqVOD1EDdK 9tEpybvA3z24NDoUDc8u0h7F9FdGiV08LRv8QykoOK4m47rWwYQuOpWx9p4ZsHTkqs50aH17tBwz +ZivzZJYZX+5YWzWSZavJPHk9CAXh48LMF59uVCHXlED/Is7IacXeL8wvcrIKtyZ9cSwfmr7ue8V PN+LGmsFbY8e5tv6jqrpAQ4O9y7668n1yeVOvKm7Tu4e7AO2vQQ59gx8aDAxb4DsvmoNcrp5xXOa Mtu8OXPFc69BZXBo94fozzgKk/NmtmV7ccJT966xrarFx6JtCy9iDqvcTz0eHXoZWiwbgvDyxF4j 2SwEtw6S16tO+9n08nhIpzY6svwwod8vaiF1bqPE2FaQcibs21U1w5R8tbx7+hX3oNg5gzghsl5N MUWLyskGpXo3l7mcb/vSKooe3utptcTX3dNHXqW98CJpwMAn/vysZPxoeo6MpzkTFMgV3xNa7Tw6 FynauU/4ppTPuY7TFseBpI4vw25r+sHmGdAIJMu2JtpiHhuMFvDh+9bbSxbpHxyjIRV19Xu1DJiQ lK5DpkdVZ1KIGDXm2YwMkIty7/7sZ0NqrZLY0j4aXtiUPkFkz/Jh9uI9be0Td+ieeFHIxyFjpA80 D7S7Gln9eKbFN3QEDaDfCte16E+so4R98mF9Mc/eoKdTvQcz7kRwHYxbddUpkzw7CcZ2GZB4P4Pj tThxWS1UQNSetatJy0AKcR2X7bopsW1Vob/7VVOxVeLlho43M/6H2vGhKxBSydnWI83Do6Jqtesy 5rX7l/dU9N6Z4AixzCasWzuyfml3aD94uplPZTyxtkFMXJwrMfbC96F7zy5Be8C5LwcX17Z/QHJX 2S/CNwJWIwqc+aKL005Vtd/Xs7w3f1eGsysLKXBQLsLe6Mm3cRvxj0IPT10x+J4H9UZnIqURjY4h eCRpBv4R6Y+bno9bcMwdlD+zyuVkaBPCdiQsI7PNYCk4U/zsXn+4Y4OwtfpMQjjHSbe3LsZ80kzD Phk38FGkSWjj3xbzOvP4uSpM2qel3a2m78Se9kdreoDOrVJA7GJ7WF+Ek4b3+fw3H9DDd9VFBy51 SEAYAdOaLRM6iGAqV71vraDvEVhzeI9ocs0zc/ICy6fXINx5luq3eCTCSTlfevzwnqaL+RoCsfFn 96otfZ7ndHJffoKK7Dymuta+zaPHP5U9EtZFOrj48l3xW92TH3xjl14mJMsI/XD0DRa7xaFvsI0f MmilI8SFW8K2oMCbAXkU50bRRTDduPqqIWMt9ytncVIyuzhuRK+gO/K4e8GpA6g4wQ6VcOjd91jU TCspv0rOw1wnvdjGs8fRb+zxBw2/HtlOm2WF5uol36QLwacsWqxyb87e1X1peOrEq9evPic+02Uq wxlKrGImqcAV3+yFV0aOJJ/FpdJ+MvLtx+t1JdJVGp8rWW91qWuKMRoxGQumNejoGPCorLZcuGPx KapLvrfsjH7qgX1Fz6VLXz07VHu9ovVc8MUPTD+m3uWfIeWK7OzDhEB+SD4Ai0a1Bo61r/Uu8VIQ PKt6HF3RUVNOPksX+T2J5ToDTIej29kLpZ9NdZ9TkgpJbVx8pHyU0ezctgXDN9AKJXqu+1NuoFko Er6abaSv+Ps5Hu31OmFwtgUP7B0HFmwX9/6CU+vGJOGVQTmlU0Uyz96zraqlUE7h2jSGk+sZZgwa wEb+6K/Mj8SGTi70+3W/fxYbJTJABZrRDzw4dcP32I6eK43ph7Y+j2rRk9NY4k2OLUtKKANo9PBQ z7969qQGGJKdkHiSmbnBmtIs8Eo1WR6BaR1oFVRzvONyiKHwIRCaCY1sXvM/yQhfSZCY9kjFcju9 RMKelUysqcVZyOZGKy/v79d/WMvDvlEJAT8Hf/flJr7ydcnt+7cX/G22PBve4yRcHEvuykpa2nsV SzNPHTOFVw/Ip1SeLXjZMX763L6yDoNShoSkVJdzBFOfbHcrs5gheZsfcmzeHigXbEx+r7xPzumN fj+wvqyGHyKYnzS8vSsQ66dh1+E911Sjo8154571nRCGcJUjlb1lKX75VGDPJYphdJDX9yXvkObF paSHTVNCtePlCK+NesIXd5XL7q68rsmzbx/fS9fY3cesY6BKf/1E94lgRdApZZQlD70bqjrFUeJB MWF7N+j18dyNRUdXPjNOlYATTz4nXH0q7MpsECrlPDVrHqI29ar2qvv+ts/hxt5g0XHyE2DRQrOp Mipb/i/xNWvtU0aam+a6xfv70YKyOlmdUl0+3qb657ovpJddfPliPt953PbkeOqbS18yRR8b0qhB BrdUJwhzwttzGqa1pE2Y1cIoVsoOPugwaA1uSgkPzws6oiR0/Y6zlyxTcBXmSGCsDp/xmvkJ+ySv EtAZ5vmDTlwe+7KSb6g8MK5s0MI3cNtqcPBAsgbLZoH/mc08pyHzvqaaG6wKviqe0ieligzf2ibZ zqUeiL8Jz0eWrjLqiJThVCmoqbbaOpK90xu/Tk6TCayZ5Vbb8BDxcXTBW/niqEEb+SLp5cmbe8PV DdRlVm9qLM5Vv2QKbNu+e1Na+zxYidh5KjB2he9aX5qPHd9K4EyVzXiwaLfE9bV0VMr8p4WBmNKX aY1f3wzlfe+tYdU2y9fI0OeMjzykdu3hQvwcaPHnNpiQmymNI4UD8u0dxGa+SkKz9w/NyEFiAAfd 5fAadnV1k0etlhlmLni+H4+/+XdbSV25X+Gioh8fDuKBWdeOCoJRl7ojk1DQAWSaYOgmhJTqJlR1 uLvS5nJejBygPW2158dZ2cyeWjqL8xeh/vPPzKqHn9Kq2+8XdBN9xn3kyomxc3Us567nDVCELttf IGBAO/mXzab/bgN0Rh4qYHGrnIfO5EnL9++9gZy0l7Qj6rJ9XjuQ/QK8IqIOLw+nUZykKK835jza K59bf13iN/UN3fBOc1zCR5Hb0zn6rlMUKZXoHlwQb+vScO16URiFTZkKPNuUdOAdesGvQyhHf/oB z+hz74pErDBSgVB8Ct7nKS44eQoQuk+EJ6zPK5dg4u9rGZMoiB9zisVFD4ifkQKwOQqGHFjusF8j QBu1gtSMW6qblzzAguxSMDvEUllEBRrvT4TiUVsYHQv5wNsfLjw6+sQvNpgsHtDZdtz15obNlgrv 9Y/uaC7c63KWoIZd9HoUsSo/pmWRm6goIh8vX5LqllsBbBGOQebiZGtW3ZhRY7Pm6UmVErBVc3gP CKyraShZ8kwpUi7eaeLLNVRg1zA33dZFCjybuEA8O39i2scybmuC8nx7gw2ZCeJ9/pvVmhFzlHZT P2wCP0TrJM4RMNWhpv1b8AVkttMWpRe/MNez6Gi+9LhThIx6vTGL3UQZ9PQgowy/U4GKvvuUekyo t8yu+MTNI8YuzaZZaAk8ei5UO8RDZL9SYHLnlapoc9woFSgiEdncj7rh/q3QKf0V5YEZe7kCyA5R KhAp7557PN1lsCnUxsKHie5Z/Q+hft7FSpty6WILfQeCyrFXhe7O9lvhH284RBykX4mnLAyLwd/g mmKLt+1WRCZC8H3ub6pTHNzfNiy01Q2eKxSOOJNTTmc5brtlqLM/PJEFNtghZQg0q7u4X7+oY+kC ujBVnVJi6O0NmL5T1cziZ4oIU643huHdkEnCsdfvztHyCit416Z8evOQxbSbttbW4pjo+VzQimXe R4ZVO1WV4PlI1RT3njGXQ2WwMPnsNc3JbK3RAoILUeS2hQyDP2YoF7UpFyVnIn8cZnY+TgcPWm9Z KlD9QOGie5bIqPnAtty7mgkZES9S9HDl+wE+1IDXVQXGFHj0t4YBnxm7OqPAIY4zftP8gaeCapWE cipeCnlaA4+T/HrL9q7y6FmTblGBp3xL5mh875MGB/nitegxYSwGLlRGtO++ZrHyYGmpaF0uFp3l +cTE/KFfJJ+5OcuL63z66U4GRrHhSSFp0L4RV9oZ+rZL0R+Q6yrbDKX+J5exH2EnvSWKvG3i/U9u ZJ2xzdNbNC8fwsdWN9wmPjbl/aHJ2LZgzyG+58SaXJDiik5F8vXEvlD35Si+9u/EQCscWwN8OpA0 S0xh6yL28GMGeE5NoOqpQOCg9q41Y7GaMhcqMGLKOIyJKX2kssRa//JDtINS+lWlXZ+e1uqufQTp Yw+PlWZjH0CfgEdwNTgshJo1dJJb1w/npfjay38NTUXZLiOXa6OP/+D78epzp3EpbLl+rtGy8d3u G2uTJfSvQVhRB/qIqwsK+V+ogHgZK/aLwxDj4CImtLKhmycw3TOLzU41aMjkZobMxyj6Boc2QcOQ l0KRZ8XpOOgOsU3uDJC0BpsZRfRHGwm+3lV6mIx+8bkxXbbENEZrr+SdyH5A72zvxcc6szgmaEDT UHUdvSi8AJ9CrNu41sEHDNFaPUs3ZbrgTYKY6AjbxRv6lEu9ZW6DZGhVZ2rCdEoDCatOBYQkpnTW MrJP9ETlKtAoreJKToiIpt8ajCnzGOJW0Vb09COHDYYb01nRk6HNFV9hvjpsBlIsUe10kzOtZhmm 0UGJCsK+vgtVr+fSk98fda0kHr3oON6qkeqnmyloUewgZ+ytSYtsANEPYs1vWA6VJIvdXtwU71C3 xRk1hIajBHAYs/E02g+hpUNyegVpW3dqeaRaVY0T6DY4oW6ts8iVjyOhcyXwqKwm7KI5jK6UooQz X1qKaV/jQnZbFm36U7Sbkoe9zPLD+gUlTXh6HJr2v6q9FB/z/Eb8bcF9Wa9AJuzJ81Gy9L0Dyifv JiPzRKwIrMAZdtz/pJMvFWhieZRzOMBxTKDRvqmSCnwYkCsrvjthKHtYtvQsj7SkkeglP7JpuL5L J0RhOMlt0Ic/m3LwCKnFg8v+1mnuxmIdFd97S0tBD9vH4sNDT8ARo9KtfIbbdbt1jT/4eqgeEWJV E2zlgZZ8yEGbMZUVp3uEVrei12yYXzY4wN+YcQz5SUnUVxILPTb0iWspD2Y8YwcGLzjkKkco7+1i KxIIqXhm/f2dcxy0s+LsVbAJ9D1Ta4hGm9I8nsdvZXk37SvpDD5+CiahrN6hCgltV5N42+vm0+w+ qE1TwjOgNNu+T6hAsb6nDkVy0IMKYB+3QBOZE7xNkB7QXvPV5ieIdKn3hJMWHXJXanybH37WeD7L 4yTmgRtxu8A3zOK0EIoXlk3W6BHGrDrkjOPAHAtIEgGTRd/wMd8xh9CRqBqxGK2IZXhotEhh+cx2 IG5axmmZPzN1RD5byNXJplbPYCFtWTS2q3Xy3ir861R4Zlw031FxzmQpqbOggoE1eoNS8TXCS625 TnHVZFZi5JNGkJKu5XqOHrjGEyKDfcNpHfoo63eEoavynoW5B/heFLu6SZEL6TXVI1aaOQPVbOdu X3kEGqE+4mHTDonXz15rGfJSAbtrGR9PR4XHuh/tuEvO9PwxC608zjSpMttk7cGi8deWG+bkifz3 Eiy3sGvfFkOKhr+Puiw9z+Sx8+zxOGw44LZ5T2TPVo4QUmln81pfijXqm+u2j68ennvNBE0IYBoo 8AvuJtKxxQxyyIXmTbaO7z87mO80ep1hf4ry/nP31GWrEmYdoZ2vHPn8k+CvpWQ17t5Mhk/dD3sa +3Ly8AN/2cmJV2q1Ls36+eTzoNgJQd0MrqQXVxxIqVUc0kVnVbsM7h65cy03MeZRZUy65f3524bX LWVInfcpCgvDB3VeHZUGRYEDKflgyiP4GL54tUnaXdlZ6Zq78qgf4koWbHIyBOkZugC5OKQMiuhF BdYEqUDdu8VQcv0CtCZNFUzOrHermAG+1tMn/zUMxbGq6ue7sXAR/o1QnPEhYBeePj77vKx8sxn7 yY6xlMf20ZqCMWd2keJbD+eA4jNGue5mo4xFPY/J7RxEZ0tzIPTgusv2CiJ3q9iZVYtWd2sVn5wY hA9/ULMdT6junTjVw1ivrib4ds/TV9VK0G693fxIMTFiuSR8JZq0ZSMR1dRt5YGoy456d5HTRQOf tnYO7xdmNJCz9FL2YvjVswfz7RcdDjr/yN819lL62TlRR/Zhn4QI0lNpymHUtjpJaf+tOJth4qkH M8UGZy2d29UVdO5vxRJSMlNas4OtW1+ev3VQQihWaUv/2/kciJ1CFKXs0hwqwAX/sPxjYdfhe8PB 6zpTwkPz8oVvwhW11KOq3UcG4gf1dfXq7uYU3Dg5e7ela1RwT4Le7XSZ4jKcBhp/VdMtj8QzrB/t ksJhsHYzqMLHZv/a4xQJxFU5hQSfCdzBTHWjmIRMddxRC/izboEk27CjUkcTmfOgKTGeIOlFhb2z x9BXdt+TLDA7pbVGTD1OUda/numgLLtBdjHqmDy7XXZ+gkPqkLFkpP6bsSFRB5OL+0/0ntMYWRiW ckQEw+QVfJDeZ+QjhsuZRhFr1dXiY7X2fAGriPtL9lXE5azwAQ6OLh8ZX0f/iThuvqRCQoPbUkXY N8NRi3DZ+Ndl5/eo8y8MH0ZMhvYhOTwxV7asB/C3wajx/kZDQ9Y7bNuXPhMd52XRofJ4VFl+ho6S FmqJJOaoq9JkgYKrP0+Uui/8TmE++c4e4wsI9+Wsf/6jYn/3ww9Ku7igHbIHnym/3j/VcX7x5eEA SvZgp4cJu3JU0jmDAN3YByXwVZ2UvFKPaK9WY2QgicyjJBSmn13tLWSWuRp5at6fuPvKLipAh2yf rn3k5Iw6S/Syz52no1vaROBtLpf7EW7AQvHwWf6Hh80/Z9cYsK3B2idQOPSKwsSgo/oL3pe3yGg4 +OIpnxn3o+j59uYkykgf8voWDIvmJbL3LZ6uH31UswT9YlmmjrPbagqhqi2QLym/lYsUt07eTaDI hy6KHhAC9kIrBlh15O5tu1kWkUX6O03IuBnKiUUnpjrzl1lal7M1aTZgi8gR8nMBPNOVsyQzDlb8 fDtW7ERmQjwXzFyxGNZJ8nuXRn8/bZajZWtCESyHNaPhVGBWrdXZg1IFvP5e0O4oCktdfg67ehGb XhsfcVVBZdccloqjR7iVlJ5+arwDzyZBSz/na2UTJqZYB5NuLn4TC4N/D2HK++Eq7Ar1YYdJU4w0 LdNLqUAQJWxztrNGfe/u5H0HkUouCugxJ3/J0omw75T+jl21/ohVpFO2LnkhRfaf70X2643k7e7D ZuJxGVK9ypIayaqB1as9+4T2hl8ZdWHvrMNDjjuOf4mi5m4sPjEME4RHwZoV2vHc/SaYM+I2uR4e HSk80Qm4LRfjW4+r0Bdyh3uXUjLSnyZ/ZN5OTwzX9Ia6IGDXkUL+VGBbsMSZW2I6mFQtJzPVi3DY W6ngxPCjXOZeQ2flDbPXn1DNmtLL8SEqEUffYA/P6R78VpW9BM29maBcXfIrz/Pf5xs0wKPJrvxo UM5pgsnlds4DXxf6+AbLu7IB7opamtoAl9qETpej6fALIegHsW4OUAEx1FPkWZ+MbRdfmSXMC1jL KS+SUVZEKvFU5vqwo7SBxK3NZcPk6EmJezZcXnvd1gXHiof5WIxDIrtN9BVNiNAsIJDgU+uknKKU Gpbufj8sutzJh4Tavj20eVxOZhJ250eyjLPOU2NDFKyoqEdMMYhH5V6axVqahbnm0JEx0EJcIQ1Q DJCL1Z7W7NOq9cjXJuixhhYS62GxhNfL/Oj6zuXKcnTRhr5+X/9WsaX9DZuXfN+63LrUtcPnuw+e Ti2EdrGcFZpDTI713RjZWECFYVpUp51u+w5hyIJvuP1f923i7/kFdVYiS97qnHX0Xnq/d8zTz+z8 SdUIncFv9XDDx1BHnLO/rS9D+vbtNfbRQF/FAdsczBjC2dCjtuSlQ2J0mBzt1SrNu4YGDpteJy/2 aXi/2Coh19oKad3zgrYWngPZFuN7LHo7gKQ9jOL+tHi/O3eZpTWvmAsXL5/ASrkp1c8TxRZ7CLP8 JFyZxTk1HKX65oBtIwza8TJhs+AMW/FWFWZwTd9vYvTMwfOSJsnnqzZuz3XyFibvujGedK8u+cA7 /TAap0Mi0Hy/5xLrl/Em4ZRbcHYcpn6vpy1/vFn/x77txaIFnstiJFYuR5s5183zKQMuFbYmwpcd StLD2R9sd+yGLNPlWBI+oVBOblzbZowyl50WYd3r5iGRFC3IceDrg61pWpbSkNbMc9rfuyqqH5+M UPvcuKtCpqQEpG4Z8qTOVGEBFXjL1FDRcPWWTIzqXWtPc0ozdri/cr5oiEfbe74x9QwP4l4HFQBC 1A3DL7J+Hzx3aExAJvVgvKXlMcgcBo4brS3AuSh3fMe2VZUHzhHLHXwbh0w8XQw3Ewd1xUycJJ/b V1mnRZ+36r55VurCdvpBWVslcVT8YxDtCPOEbot6GmlsqVAwVKBZZ6aHhDd4tGT6cTAhl3Cv+I5D bO18RchiatKzvbHY2muT57rHXJwMhSODTA+nCd1yg5Q8wYGEBmPckBY8ogJHBfydlkcwqJMKN7fQ g0roKqUtPxZW+IXrwRoa3teLtp5J8DMwwne9OXit7rCgdOq4rpoM07BPKhyOjizq2/apIqxPwg1x 5mQ8aq09OdUupxKJMdOasE0cdDfIltJuHnmXETpREN58hPVJVMe5viEa0At7zmMmsYODxLKyzgr4 u5lWlql164yEvPvWstFpR/tPu8Ovj8lInVIWhj+wkc68uM4y8/5T4t1XEfLoJjoqcJcD9GCw0Okb K+lOKPQ+IvP4htlTyste/zvSUj5OalsF8s/e1Nhg1WQkLScG3A/U8G6sfzAwiDBazDheGAFyXgl2 l+QfkVMl7AR7FehWJO438d0nOr5+69DzDMwhV7PbMQtexY/Hm9+lJa9a+T5jMQwk9UlDm1x8v78y M87KPD5TPZKKdy91PWhW+aRfHvl+wb7e88TTQ/fkJ54N3ZCviRw6d8PX9HZHFItBUMucM3dFdlpV FhQ+peezkaIU9EnuWcOHYFP9pDY5nXEq0DC8UOqy7T4XXNNN1MtdIXu81yidT6cCP0Z0jgukN1he 7Wja+EwwOBrJ0JQK9RvmIKdwpMKymlEzTkrjteWY1mGzwUGvC+vyNRhymI4iIxXA3EhJe3x39szG m4PPQrnyq3rrM/eezdsWFG0xDoOV4Qzvq5WdGFfiDlKzWr1xuc769vjzk/H4o+QzfWyXdn45TmyK hI4A8eYW0zosIj8xkUdk4pnRBMnvWvTNo2fzli+2XT5TFuXn9TZjv9ie5cfxsUIeEaqjpmDoHQiL QXFFT4fW8a/iG1nX5f19nByUiqMeZA1zz3xpVC7ziB27WjKwycbLE27ogI6/oBmf5qTDBTVK55ov PDZwlA/+daIiJp2p7gM2uHmAucjy7KdGd/+pBZthuwCx8aTw83koZ4Hu2bVIxtqw5cqO/FGduuwt zarjGyn1Xp7qmDW35baMQebKyWoQIqS3fqhsfN9ucKYu7rbmrgvHqx+23AkzoyRDnozOO2Abqd6D aIFPtrdz+7Dk5/gGzyvkLNB0SzqcX+2K1ojKzpWDsUndnL5WbkDulm7rec1xzdpdZiMIVF2JaaYv XlX6pCS8zNoxOf4EK+UVVAHO05IKuN8a+D6J7BCNRnPnpPm3TFuFsSpowJct4ls+vTr2qDgRASqe +hpivF2TVDc7PLZKnORvDfDYrMc9E/5c79fyptSeVTusJ4WjxGPEg22tRXy62ihAXspUeLbl29dx T1XQs6XKBm1zjBEwXvZlS9h14jTGzZ1Nt0d/kuD5iciem5buTbSaogJPeke3yNYaMUe8/Zo5e5Ma Ja/rkQsPnjh7pDPu0CBYh7TV3m1Xd1Q95vEFxMNoT1+n1v6e7UzUQLR4hvsyQ7VSeS/HEMdgeMb9 dhYVLu7gugYD7fLIDthgTgh9SdeN6GGfTxnjEnWV71c6J3Rukm4tfCxaabf3T6ufyeXxFEHfG29d PlxmGut6oSTlwskKt9NiV04gPoTdOnyljOMSryvIN/Yx5Ne2MrySKkbfz67E5xSczRdnvo3V+j5I lAxu657wVFk09Ry6bo/NTQqJghX3Vo+cP+l+tY1zQiMa9E5XqwyQR9GBcBE5o/ueIaeODKN4fZC+ naImEz4km8U9IzmZI/u9joSfXGpXpLd7Gn2Bzgvpfb42ZfmYaGaqybBPxmGdV5W2Zqt5QaDy3RlL 94nIuCutzFjXpLsVo6Uw3r7sKy5/xNhFLlDy2tGkjPbdtobuMVd1eFcbhBPtOEAWvEfP8sKDH2w1 2stXriFm+Okmkq3jU6cULtwur3pQ1uTL4RZ6TLuX3SDiQ0p1o9TzZ1y66XF+ClULw+Zsl93ghiTr Ba2gDr8j+WkebEb2e48pDA/yOHGpLQQH8OnwKdFJpXA4vQ837p7J+mwkxdXBmmIGxnyssf8MjqF/ +dWhv2BwaI2ae3X8RzUJCmZn5Yf6YvL3aqvA5R9JYMRpSkcZgnz1s1BLy7nzB29Rgc+qRJo68tvO BBi3vDcyYXBBcwOOmpdfjjFq0H5zcGP8DHILs6rQ4q3YCy0vUV6hAlXoYreQ55SPG9zLIckD5e+Q byfuonvPDJJniZ8Q7+by7bvHZfemKYi6t/KpHdHZLOaiAj4dbJX+fk64fVTAiMzxvbvIg7VnQH/g 9Lt7vMaCEYdgC/55D2ALPmWvJa9uWvXvR7KYkBEKUQqDs7g0/v+1WTDQjYCRpj68dlO/CTq7+IpU pImr71LLSNPQvvE8h5ffWIrL77vczquSTToSbns0rFuNQLchLQBKGTfpGr69G81WJnjb123unn0h 7Ib7U04Ee9GJ/PdGrVOWoSKlknKhp3BeF2grlaRdJXWbdvGfOyJ6DsJf9YJM12pmnSgramCboZpP /T+v9f9LN9C//BbEP5+OotiDxCC/VcbFzXE9H3b9eTESkHJRZR5RGHNiJ7Oghg1cVeXGKgGZsbW5 DP2uMDYltJOMKM72RnYjK2D+7Sn6hIINaBLuwghqE4FlwuTP9VZlysO7ibKRWDPEfwdq/Bff+GU5 1n+HecD/l934ZWb+f5s6/d9zg9oP/Lc87oKfK/+beVDBw4oWAA7uXNH8F5Xz98cTgFOIhkuIRt0a qgfNW2+aIx4A3V0aqR4GgIYuhQH8pqGlKz4IftPS0U3vEfQAaFIYBD1oaIsPCnrQgndkDZkB2reu wMEtMAcOaZpDW3QA8M+Sn+thBGgY6PiAnZM9dK7A7S06bxrHv6sF7T/WIgb2Z+kxsH+j3BjYPymP i+Z/n7rA98Z5r+2ytv2vHgPpgGYaM0hpgAv8HAM/2oAtYAXYA67ANfDbDfy4AAhAEXAE7uycu4L/ HYFLgDLgDl45Ac7gtSRwGhAHHMArN/DbEvx2AHMa/YdSjMF7DsBtMH978D0nQPb/i2X9V7Phf8r7 v7s8tv9TakT3N4IfC0BW0Q38cwaFXgL889z5E98RfzfAGjxzAgXcBnxiC4ryT0Vw3HkmBqqCC6g0 1uC5607aP6/FwBS3wStLMNVt8MoV/HYAy7AHU4oBD8D7t8ErKAdb8C0r8Nptpxwv8N7pHTVyA99y A2vnDvzvk2PX35FjF/jZA35UwIIhjdUHqwEVeeb/jULPgveU/0/az3PAP2P0T9vluGO3LHYsoBXI HHvwD2KdI8gaq1+EwGDH8imC5xDbrMBUVjtiIb6TuwOY6j8K2d3/wrL/5/if43+O/zn+5/if43+O /0uOgyDoOgDG7B8Bth2U+vO4CACXVqm04PfeP+4xgoEZBAccdmACdA0A7IkPgH0AQo2G3kFt9y5X 8OOmtpv+HkCzk/reL6l3A2o7AOPODpa1AQR2wB4/WDKjEA2TEM0eYYBZZRfAUg8C9fhjtAfBjC8J AzBAatcjJQ0hQEeDFrgOfn4rih4sih4qCkRttJf2A7Tg978qC8J47OBbTELAHmEaqCD2nQJoAHpA SUMATE136ch/moskeHcfSKU9wrQ/s7gIZkHL9LOOvCDJAPpLZ8BcLv3LXCA4uBcsd48wHbPKbjAH ut9yOATRneGSIvBXuv/HHKR2cmAAc6D/mQM91ApOwBRgvEQDpjb9JfXe/5BaGhAFQZs0+IwN5CEj RHqGn9kwANxQTS6f3AdV5neSQ2R2B8GzLsC0k7vuv6ybDACBXqaf+TJC+e6w9NkeMH9GgPVn/rS/ 530N2LWT57V/mef5He7t+pknE5TnT/FgAluwQznOPyoL5rT738jxwk6Ou3/muOvPHHf9nuOfzQdl QvHSGvUTJBt/dG1xgldWYLR1GwxXoG4LAbC82zsRmM3Of2eQwgI7kYbjTiQFAIaA7aV1aj74/Wcu e8EY5DYIviHoLfAP2iUAQIEsFxS8/hasAr8Hq/ZQsAqAbWQG3zsO2F3aoH4Fv//seGPayUsAuAq2 13WnfNrfqGEMwEDqrIHfv+r179SB4ksA1Dm2nzz7LEzLnggAwnfoaQCaa/VQ/ESlpwFLOQDR6Hf6 mO56ZA5+6QMCEN1p9P+S8++x1s+ceUDt+T1noZ1ctf+TXE13LMQBGtO/UE1pp3vn9xBE4I9IDgD4 gP0AnRAdSz0rQP+SQeXAZa4cHijNwcQV4LYQHZj29wLs1CbpxYETl+KBIzTiv9SZeYeTNr9xxB0s xeK32kORI0WHBjhLo/LL+7TA5R1LdgiUJ7BkticytPufNJLNwe9b4DdYKNvfaBKUz2Ua3b+UC8Xe AmBuTiAnvH5pEyNoow8mDoHU+1XQfzWCUJ7nwDxXqbo05/5SNzj4B4CWggM4IwT8aan/SCkLprpO o0sj+0sqhp1U8N+sJgMo66CW/I1eKAAiQDxwn0bhF97s/w+80d3RE6udsPFnUAns2Nx9oAxCVHhM 86ss7gL1ShnMQx3QAz86IAcgXTsEUXbHQdDs6CnYFpCuh6AaKZyk+cWc/EaMsp2cw2nK/iKLimC+ +n/k6g/aOjBXBiEaxt+cDx0om0w0d2loJJm+sD2RZNr/RIAEmfiD4EfoDiMNI80x6D+98M65yM45 WBNQhKlQ/qAI6/x+Sg9c+/Pu9T/vmoPZ3gKzBWvP8dMSMv6jbLwC6x5GE0/z6pe604MS4bTT8wOA n8PATnVpf6rSXRpGtif6NPuffKZAlWTeqSTzTiWZdyrJTA8p2cM/avjzdKeGv9+9/uddczCvW2Be oJe7fJIZtLwUnU80eTTn/8Ij7R2dhrzm77XaDUrnTq3ogZ2UjKAH09mxwxf/4ou0f7MGAv9gkaGe GV7gJ7UfgFcuO9I8TuPyF7lU3LG1ajv6dgzU9d85xwimXNlJKQbCAa16qJeH2tLSAqU6/pPOu3+K Lj1Ia/o/tMD5LgC2+1ddoAHG/6ILu38r8x+RD/8Oftj1hzKY76RdozH/i0ar7HRPQ3qgBaZ0+8MO HgFtLAtIc9osxlpWWoDtSQ0obPJ4yNiag+e3wHMw9S+mEPhZN1pa2b9IxeUd7/PT+gj8pD8TmDE9 zXl6MNPvtObgBwCtCpT2AO3pv2jDz7T2O72JUDuP/EzPAD29BBhAdpH2H3GM106XkctOF5EjYAfe 5QBkdj1UOAlynFbv5MMbxwHnu5IAFbINfCD3z9L+ahtY/vAGjn9IwZ9Wbg8g+Av/r/20kLTX/mLN 9ME6gP4IEAI1l+an5v5MUgBICQEyQsB5IeDCFVpADbIPNMy/+hPgJLB3Rx5PAiy/+En13wYVHvyG 7mh3Bjsgy7RKY0H7V8v0UxL0wba77dANsqfCUE0gUYCqDZbJB5Upu+vRpef8wE/Y+lPidtwZqBuQ PtHQuND+qk97QD2C/LQlmOvtnb7an1LCCNpX9sTjO9byAPABTDlG85j2w1/0SQWsy9+nNgUlH7Rv rE9CQVEoACB3ywbaBvA/vfDOucjOOWgb3r9/D9D/tA0/T3dsw+93r/951wzMyxzMC7Ree3fq9Lsn ufdTOv+C9+lBejmDf5B0ygAnfkX5e0AZ3UPjvIu2gumWCCMt25MKUPyv7Ij/wR1IDZYCPgJv/e51 IELSgYQEUQ+kaWG0kMb9x7IgfyUKcvh3lA8VxEh7i+6WCEiDJ3T7n/iCBr0Agv3m4OUt8HLfDvr/ Q4s1aHd88yfav6Lc3/OHJOQU+LeD//f8qWk8oPmdovwUg+NQSGAO3roF3trhHS+oT8KgPn2F9OkP 2TvwN9rwd76SDlA7SQPK/XsQB3XQqgF7Gf7k/uXfOmyddqzMr9pEC4iBqAHysr9LICR+t8Frlf9P e1cDHlV1pr87/xMmyQQkBBQcaVZBSZwE2ALdXRMJmAiYSLIQuxQyJAMZN8mEzKQBbbezNUVbbIuo 1fUHs9Qq/lTwp63btS3dum53+1jp0h/7PGppV7esj9aRR4tUYfb9zjn35mYyd5IJ+FOdb57v3Hvu mfOe853z3fPz3XPPpTXIy29tGMM4dKQSkReJNACMjoz3uo9EZ+vr7Uyg1SxHOe2h123lI1qVuHF3 VIkr8+hkdA9p9nniX1umbxf63iXGyjzG2iAk36rGyEw3TRVW+iV8zs97ZVnxaJ3Q85GogxiYY3BL cS14H/h58Avg34Hf4rRQ0n3gQfBe8H3gh8FvgY+DC9AmLAOjH6XV4GZwCzgE5mfMm8BR8Fehc70o KQ/KvQT8HPhCTH2D4KNeou8hs7UYiC8FrwUfgqBPFRL9DPwc+E/gmyHTrdxyBZWQCcXKw2FnW4Td NypMV6GhCYf9Ex/Swxyngpktn9ll+ODk5YMkQx7TCvNWcgVmZrmPZmUMo1MI4/S0XONpWcLcY4XR BMMmhsny2SaEaR3GmPbTjGkdxs6fex/xNvgEmIrQ54Nd4E+B14NtflwDt4KvAD9fQnQYAjefQXQv +Ab0L7umnko/Q1nux8CEw6zv44liZstndhk+OHn5IMmQx7TCtO5nsrX72fqgscKs+plTwcwelrlP GDtsYphW/YwFpkd6s4dZ9jOndyzgV2E1mNFkls/9boUVp4e9NRxm2acjzJ85HmUMM8WzSE8bK705 WeKNCpOUJUwbM15mGbLnU6hNkEZQ/bpjRV41hmBNcinGNTFn1bldsQcqvB58C2Lc5pZ/LkD/3oj+ eEMp0a+mEZ08C/PYmfx8jS1kchHYdJJjk7NIxnkemdnrlXFbeHyAwcsVZTIeq5s+nuG1zoAlBNGZ Ku6NM3nOLsc5S8GXg0PgIjQfDeAeTY49EuCfgJ8G/wXyehD83+AKpL0TvAv8CrgA+fCB4+CkV45Z mpCnfy2Q8/Epl9xcLrj1jNTUQeFen9Ud5JIaIDnq+hb4CfD3wU+CnwH/DPxz8BGwE6W5DiOmu8CH wEeQ29fAr4OPgW3IsUOV9hT7z1M3J6ac08LuDOHKKzJnpuso+6S0KriSAbg2n6xfNp9wK6SpIzM3 +WeTlpxH4ilnspz/5+x+s+vfdp+34/aXX/n6jbfPGjo7RUvulBjBJVJ3amjW61xX0kqRokQiQcdQ fVox2ZL8zwB5kh6VgN3DCmFPHrHx0ZGcIzLhTfppNNmoQMTjho4zzP8/jOMjDnldU2sZ22lScj9O PwctHyRHLQvl/OF6kmZ9omt+VAn3B/YAtVETRcRSz35hXgoIsw6bjPrEar8YbVImbv0R6VqqRZzl OGsQJmx+oNhIq3CVHwzxwyp251OVUEMnsuqhTcpgw8fdq4naWoj0o35dnvmTDlX4UGVxrmWQ0/Yh kZNMcmaqT/uHRE7NJKfolvlG2MXB6kbgP2gOeSMEKYcbwTFccBcTt47qRuCUMENqRsHN4qLROK2f iHykNL5/HHZuyS+yayLtYVXjNp2nW9yec8vCqnb12ZiPQaSHzyPaj+vxGlKVwyGHVchjRohmGZJK cdfgRQGvpGW0AW4DXUYrULg++OrFk4SP00LwfBT7fJxZh1SnhXDYAvyqceYxnqPptl9vhkXVo69V i0re4ZX8mlfOL3kuaVPzSJLlVAORalCVNbrqct8YBV/vlcxx1yLuC4i7U8VNpQrEP+/7klegdGyf Dt/9yne38D0AH9fJi8L3oAizUfm17Pum8nUI30MqXvmZbzhdtE9HEb79ethZ7HtYT0/4HlEp3A3f EYjymmKe1fOs+3LozUrk/H/Rlb6qeFhy2T/IHsIurkjNcQrXJVy3cEVDRTLHf0C0Y4qnIfL/IZ11 RbKEXgH+m4pNJUz6+wHmEmZkD8lRCF9fo66dn+jv61kSa+8Md4diFd2R9r5oLLopXtEe7V4S3bQp 0h5eEusO9cXjoc2xgkRTuC8W7bks1B0uS3TG471LLrxwYGCg0ohWiWiLVKq5IDsSHaF4mBKLVC5z i7s0Et9GicWyxcsprjPR2xVqR8I+HiGqonIkqoPBBbZEdZWW+Et7oi60zZlYFe2JdzoSV4RDfQWi nKUrpw1uk+s0xgSkakFTJW4bM3Q0MpPZzsT2JBuiu8Dl0IQ5JluPbu9hPqmYWzJN2X8cygbkVjag B8D7wd8F/wD8NPgZ/j80639w770KPsqDRZMtyI28u5FfN0adkm3C5zCOI1n/mc9thlTPmaQ6nVL8 NIskWkZpxiPF/FE+Kcm1JikeNtn5litbnm7D0211T6XZ6CYisS5d51TZRuoSSXmcSrJ0zi6lw/gX U645Gy5TqzRsaMVZ0wsxRIhgANEvXskL0CWmd4u4r22gTrGGLYCBRKUI7xfvFW0Wx5i4QyJ1h91t //HHP6aK+ccSu5CCR7RudVMKzjzrzeUHLqB00ujE7JsW/vilq46eQzLm8M9Pr7T01AZqdn1PE+2z OYzo3Hn/VfvOL39aNj0TZuS2lu3rH7wtHZHj7fZF2r9//MHvlmWI963KfZFv/+cbmJ6NjvdEy2e2 zT7/yZ1z6Xy6IC0vazY3Xx0Y+MPOQAYZnAo7nezIQPHgW1rJoOfkVF7k85bmWg9/G/zROaLKK1XF a/bRkTVEbrOXDA69IyK32RG5zd4GPyLbRWRNparZnaOi84KURY6SwR+/LaIvciD6Ikcb/IjuVNE5 fQPCnQ5hB4TfWTKY/JOA8DsB4Xe2wQ8ItwmiEvkZhvGmwfCz9SOAKZMwRxjmCGDKGMabBlMJtTVB TTKXrN3vBNT+gpLB1nfW49iGIyB8GSAqIWLlCKDCEXlyAWivzyidw37kaa9PlU6RJaArHbTYDOoG 6FBRyeAiCbp/CkCHitrgB6g/K6h7FHCJCdgD4MP+ksE2WYKJUgAf9rfBD+DJYwJ7FPi0dCUDTRJK esBVMnhYKilal/Xwt8HfeKmTLgcjEY0WJQWEaXjfqZkhDtpKBm+VEAdtLl6z1AZ/46UaIDQJ8Z0x IIacBsQQK8mQU0K4AOGSEFEpyE4riF6PAdHrAUSvR0K4AeGWEPcms0PUTDIgaiYBomaSlSCWEP4i A8JfxDdNUc6CcHUrCKGcXN05CrJ/igEhVHH/lJwFSZQaEELpEqU5C9I03YBomg6IpukZBJFNzwSb UP2+GR0534Tmm1AF/K43oZ2aoeedrKSdmtRzD/TcI/X85WT2oUIYuna7FDzMuhaGrt3+tohKWbSc ox7yGFEPcbt3yKOijq3lHL220IheW4jotYUq+vi0nCH2lRgQ+0oAsa9EQYxfyxlmZqkBM5PraGap ghmHlqdB7ZhhQO2YAagdMxTUJIvqttZ1hlsQMLRnQQBwCwJKewot4Fh7rDWdIfeUG5B7ygG5p1xB FmeBZIW01nPR/cw1YP1zucGZq2BLxoBlPZ+Ylpta82eTKnejIGTu9gOiSXVLDLEfEE0nx9Rybstr MMY4cEJ2zTzGqMEY48CJcbflPEQJnhg5RAmeyKktt+xNcmvLk4DxS5gkwyQB438nZy3ntjyBRiMh tTzBjUYCjUZiYlruytZZTUzL3WpYp9TRGNadopZzax7EmPXgcQEbdAE2iDHrweM5aLldWX1Glqk+ itx5bOQocucxUaZyCXFYLDiPiAXn+SHIezAEcXgyNSdOy3mHGBy6aO6f81DDcp7ECqFENhQix4G9 x21AeNyA8LhzHtg/6zUgnvUC4llvzjMUHj4qiL0+NXzMUZCtxQbE1mJAbC3OWZD6yQZE/WRA1E/O WZCyqQZE2VRAlE3NWZAj0wyII9P43pqWsyCPzzAgHucBz+MzMgjCbR5byMhEbE0z+9nyZvazdW/E /2fftNDsZ6ua2c/WMrOfrXxmP1sSzX62vJn9qXHT6BZcR9BDJtMLD+05NBaOOe5kuqfBc5+dvA4n WANnOpfPkbwel3hTnEOMM4/TuCbP+L/M/HzhJZUKt/2/b/ob6l26jP594Tr1VkX2FbDmla8TXema aYUqW7j1Z1mk8mnThnn3aTr/mlJXLQOnatata1rRvLZxTdXidSuaG5vq64ILKxbWza+uosvCwYVL aCDSE+uNRruoNdwX3Rqoi7b3d4d74oGlcPrCgQXzqwNNzbQOvyZaQc20lhppDVXRYlxhfyOu11Md BWkhVYDrxLPZqjTN0Rw253P0bUdzivP1eXq5IOrpIH5zttXGPXWrjXvJlRZ6NzHSTEcbZRo6S2pa 3bDmd0GLwFMgaSn3n8c/Pg6HPGmziqOPdY5qflq3wk6dS4eXSGgZJDhx0a3F+j2Zws/8j0z/z9OH k46iqhe3rm5lxaoKtraO9X9+k7NUqMc0Ox/L7JVwJ4srmnh8vFW4XcINi+sD9uU4it0G6SvC7eRH kLRZ/Ccirlwp3F5xZYs47xPuLuHeKNybRGihcLvFlS8K9wzhTtU+T7Jdw90gXIdwi4VbIly/cK8X 7peFe5W9DcfPiPvqs8Llh6SZbmqr66WWZbXLMuT9pHyLnDvlW+Q8vVeUb5E/ai2ylhi+u+u/c01x +t1eM3jgaptufuCl40O8RqSGp1VcPm76W/EyeY940bwn6+ISjuGh0aQpLCaeftn05demc7YqXVK6 kycPNpfd6XDa7I5rlyABE6VUzlvUpgkx4g1/wsgXv4gfFZt99CB8IXBs5HRqNs3tshlWMvNq1QQ7 zbRNbBYUFVuEzD9XpD7J5bAxWaZeC3kjaluRWhXH6UIMO+KkNdh3UXoczjGXWJ8oT+TVSBVCO4Bw FZ3D+fMYqWpK5hB1KhmJNrggYbGmuTRJVhKuEtsM8DJSuTlAADLzGuO4mGp+Umx7tUlsR8ErjjeK LU845KKFIlduu9dmc9ocnKvAyFzJI28d1C9k440H9Nog+oRL1ACl0aj8rVUp65vKcNqLZe3ZUXtO r8ttt44bRo7NMWezJdJzXRklD9p+75D2kivv335u7Ifbt8cf3XqPW7zSUYo6emmSvhjUQdf4R1/V lyFt+Rgl/YPpYuRpfPQN1wH3Y/QYqmvyAq7A6agtWbZvFEo+FRq+1XzV12zhevrNb0YZ5U1ULzo7 TzLFTeBFRC86hPHpc8xskNbPdWZjTSo1WcTdiHtkiRja8n27Se29HMOVLZApJtbiB+GTTwy6xDr/ kNhaQ27zUSd8IfxjlQhjlJhAiuNai9iduVdsshFXuHKdf8WosAqxRVxILNRj7GaBGzft71xhvBtQ hV8QXCk2o4qjbU5HK0lDC2TAY7Kr/Ixn8eBo4u0Ted2vHID6cI/5xPZ2drGpIm+L6EO4D3eeD3n0 oS/wZcTJk6CTKV6HOnpqwO3d4S/cdfR4Y6f/gRs8dMF5j/6aRzBPaNLSyOH8riTHHCI5h3iMpLXy IMlV07ximKuK3/LihvANkhbCOZrsousUVpMmq7NLI/Hwcasm38/g9/L5vubug9eF3KHJd+ru1mQL /qAmLZ6PaTIffBPyWyCM3RLu7u3iVepQK77G6ayMhCKxaE+gOY4AtgBClWepPDeuqhXnop3PcH6B /E+FjluhwAysiupgsLqqKlhV2RGNU5Tj8LOdhs7QxkBtZeCS/kjf5v5IjBBnliq3j1NoI5/z6HCV vvI9sDba1xGoClYGedxE9MuSf+CyFefXvTjwQuePNHE+76kjd659Up5f/MzsX1/xpKavUOcjd0F8 5G4oW0OWpzzlKU95ylOe8pSnPOUpT3n6aJDV/F+8+f6Lp39xR+WZ/htvwfx/3vGH6nDNmX5NLcMp lAfqJTlH51VHPK9meyfbAq4naQu4ieS8+A6Sq8XvJjnnf5DknJ5tCDyn5x1j+OkI7xjD2LyZN9sE fksj5/r63F3Mcf9KznXZKMhHtzqycZCPV/sLSF8IbXWc5ZdyjLAh+Pwy0VlKiJZIvCtsvBBOt7rl /5ma1EWPsknwUyP+41lumddytyyPoFtBuWU+425pG7le+W1K3g1NDXUb6lc2XLaiWeCwrWBDbUd9 tH11+NOR8MDSbe1d4YY6gc3lt+Gy8IApRKTFtpMNy7pDka7m/o1XhtvjIuVCgdQf74z2iTCRbFna xbpIDEWwjfcQENnjot0g8SM9m1ui0a5Yc2d0oKexpz1s1Est14tLPvHiPJ9H/dImQcO2CP3N+rO5 /uiD/iVEmU/NlPcG/OxKVzPJ9MnTKJNZIj22tTS9uN4h/iEfYUVwpV8ZaaUJuQL+mPrKRbqk6XIy gl3pViY5V77HcvaKmooZO2RXwN+vDOhjyVJGy8Sx0EKWVe9bnXWpL7Wk10x1Vh2cBkn4WGAhz6Xv ow6GcP73JkmqstRLC80Y0V6ny3Hx+ybHyBpIz/d65FjfuSVTvnk/sXfr08bpeWmDbHz0WeTlvfwI aXre/uXVximGPR2dB59Pl6eRWLgjUL1g0epgVaAi0Lq0timwspl3GOL/8DqP5s5QX7Rnec2maFdX dCDUy3vWEP7D4cVGeGB5X6SjO9RDvUY6uE55ylOe8pSnPOUpI+nrlLPtQMfjS54f63sm8nyS+16e E/Bc3rxXLffZPM/juT1PJvV9b/k1MN77dibJaTSPEQJEYn3abPDHwLzvKq8RPZd4zsjf7iKaS/zt Jvn8ncdTFcSvQRJGInJ+yWu++bs//MYTj3H49TL+tiV/h5L3p+N95ni71k+QMA/QXxN/nYrEd/Fq SM5VeXzJ++iyfWMZ8Xf+iC4B89emGkiOo1eQnOvwHIG/H8dzVp7r8967q4mX//E4ljA+krv1rSX+ jhTRFSTngn9HvJ6d6FPE40ZMoonHbHLf3o0k9xbmBU38zZ9NYP4mGn+8nV+PuxLMX+A5mUqleOzH yxJ5D0a2tWwhEt97iqnwfhw/TXL3XbbB8OtxV4H5tbrPgD9L/O073mJUrnz7RzCvfb2GpK3mC2B+ n4z3SbsO/EXwl8A7SNpwvgz+CvirYH6f8AaSa1VvJGnbuRn8NfAtJNeH8B7rt4FvJ2nzuVPlkxcz DoH/GbwH/HWStqBvqPB7cdxLcj/8+8EPkLQRfVOFn1D8sPLrnKfcaLXaGTQAzedxfB+NeKFyTCol p6Zjif2zvdKWeEAGLzf/t+nq3ZW8TuVRGt6WW1/MNlEqIJtmlmc8cXiOoi8BrTJ9g3UiVIT0uQ3l NnO86fNc8qXV8nytmFl1iG8ptovvjQ4vlBsPzUD6cq/K8afPdOWv5NGJlqtffLEzJOqeNwfWtw4e thhZ05wJlP9udvx6+umS55afRUjfQcNv/o4n/XtM6Wvqi6W9aNE3ipY2N5osFp3nJj9T7ilZ00TS 14l1N99ufnRJQ+3bC6QOpbfdPH5LW5eovzstxoSrmvkaLombic8r9fDKRfTG4ke2nC4Nz9O7Rf8P UEsBAhQAFAAAAAgAjFbYMKGnqA0HtAAAAGoBADUAAAAAAAAAAAAgACAAAAAAAE9NQS1UUC0yMDA0 LTAyMzItT01BLUlFVEYtWENBUC1MaWFpc29uLVN0YXRlbWVudC0uZG9jUEsFBgAAAAABAAEAYwAA AFq0AAAAAA== ------_=_NextPart_001_01C45E73.EF9ED52C 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_001_01C45E73.EF9ED52C-- From simple-bounces@ietf.org Thu Jul 1 11:19: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 LAA09202 for ; Thu, 1 Jul 2004 11:19: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 1Bg3LU-00044b-19 for simple-archive@ietf.org; Thu, 01 Jul 2004 11:19:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bg3GU-0003AK-00 for simple-archive@ietf.org; Thu, 01 Jul 2004 11:14:20 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bg3DG-00021q-00; Thu, 01 Jul 2004 11:10:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bg2Dr-0008Q0-49; Thu, 01 Jul 2004 10:07:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfvwP-0001Tm-P1 for simple@megatron.ietf.org; Thu, 01 Jul 2004 03:25: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 DAA01656 for ; Thu, 1 Jul 2004 03:25: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 1BfvwN-0005eG-MK for simple@ietf.org; Thu, 01 Jul 2004 03:25:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfvvZ-0005GJ-00 for simple@ietf.org; Thu, 01 Jul 2004 03:24:13 -0400 Received: from [217.158.120.227] (helo=rnidmail.rnid.org.uk) by ietf-mx with esmtp (Exim 4.12) id 1Bfvug-0004SK-00 for simple@ietf.org; Thu, 01 Jul 2004 03:23:18 -0400 Received: from JUPITER-MSG.rnid.org.uk (unverified) by rnidmail.rnid.org.uk (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 1 Jul 2004 08:22:10 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message Subject: RE: Tiny ant vs big Mammoths, was RE: [Simple] Using MSRP for realtime text conversation Date: Thu, 1 Jul 2004 08:26:51 +0100 Message-ID: <4818CE251FC66942A7EF35B92695246E01B2212F@JUPITER-MSG.ad.rnid.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: Tiny ant vs big Mammoths, was RE: [Simple] Using MSRP for realtime text conversation Thread-Index: AcRejngaO5tJpaNkRY2Mor+yDLjZwQArRKUQ From: "Guido Gybels" To: "RNIDMAIL.GWIA.\"A.vWijk@viataal.nl\"" , , , , Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Thu, 01 Jul 2004 10:07:20 -0400 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.2 required=5.0 tests=AWL,EXCUSE_16 autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable All, <> Arnoud is, as usual, right. The very last thing we should even contemplate = is introducing competing solutions for deaf people's communication needs. R= emember what has happened in the PSTN and how as a direct result of that de= af andf hard of hearing people have hugely lost out in society. As far as t140/RTP is concerned: that was not randomly chosen, but after ca= reful analysis of the problem in combination with looking at real-world con= straints in terms of bandwidth, cost, practicality, etc. For all clarity: so far there is *NO* scientific data whatsoever that shows= there is a more bandwidth effective solution than t140/RTP. So, if people = don't want to agree with that, can I respectfully suggest they submit relev= ant data from repeatable experiments that we can peer review. There is a lot of misunderstanding about t140/RTP it seems. Arnoud and Gunn= ar are doing a great job in educating the community, so keep it up! Best wishes, Guido Guido Gybels Director of New Technologies RNID, 19-23 Featherstone Street London EC1Y 8SL, UK Tel +44(0)207 294 3713 Fax +44(0)207 296 8069 ************************************************************************ 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 =20 Registered Office 19-23 Featherstone Street=20 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 Jul 1 11:21: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 LAA09441 for ; Thu, 1 Jul 2004 11:21: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 1Bg3Ne-0004xd-Gu for simple-archive@ietf.org; Thu, 01 Jul 2004 11:21:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bg3Ju-0003qY-00 for simple-archive@ietf.org; Thu, 01 Jul 2004 11:17:52 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bg3FO-0002UB-00; Thu, 01 Jul 2004 11:13:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bg2Dr-0008QE-O8; Thu, 01 Jul 2004 10:07:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdnFg-0000xj-07 for simple@megatron.ietf.org; Fri, 25 Jun 2004 05:44: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 FAA20148 for ; Fri, 25 Jun 2004 05: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 1BdnFd-0004pK-GA for simple@ietf.org; Fri, 25 Jun 2004 05:44:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdnEb-0004Ps-00 for simple@ietf.org; Fri, 25 Jun 2004 05:43:01 -0400 Received: from smtp.eweka.nl ([81.171.101.3]) by ietf-mx with esmtp (Exim 4.12) id 1BdnDZ-0003yB-00 for simple@ietf.org; Fri, 25 Jun 2004 05:41:57 -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 i5PALidT057431; Fri, 25 Jun 2004 10:21:56 GMT (envelope-from a.vwijk@viataal.nl) Message-Id: <200406251021.i5PALidT057431@smtp.eweka.nl> From: "Arnoud van Wijk" To: "'Paul Kyzivat'" , "'Gregg Vanderheiden'" Subject: RE: [Simple] RE: [Sipping] RE: text/T140 and audio/t140was:[avt]Comments/questions on draft-ietf-av Date: Fri, 25 Jun 2004 11:40:26 +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 In-Reply-To: <40DB2A59.2030609@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 thread-index: AcRaIPY/nhXe9pgSRwexSIHJBvsWKAAdjBcA Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 01 Jul 2004 10:07:21 -0400 Cc: fluffy@cisco.com, paulej@packetizer.com, 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=1.0 required=5.0 tests=AWL,MISSING_OUTLOOK_NAME, MORTGAGE_BEST,YOU_WON autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Hi Paul, Is there a possibility that we can talk with Cisco and work out a strategy for the IP phones? Viataal and RNID and Trace are quite willing to help defining a good strategy that helps manufacturers to satify all users. If there are enough IP phones in every price range that supports Interactive Text, then I do not care whether EVERY phone has it. Not all phones support caller ID, but there are plenty phones who supports it anyway. I would indeed focus in 2 ways. 1. If an IP phone supports IM, it MUST also support Interactive text. There is no excuse whichsoever, no argument to explain why interactive text is then skipped! 2. For every price range, there MUST be IP phones with Interactive text capabilities. Regardless they also support IM or not. A voice only cheap IP phone to be used for your teenage daughter or in the basement, etc. there is no need for text support there. If possible, great.. As long that user who need Interactive text can buy such phones at any Wallmart or other shop. And that other users can just as easily buy an IP phone with interactive text without having to rob a bank, or take a second mortgage. Ofcourse, I do want to see Interactive text in EVERY phone. I also want to win the lottery jackpot. And marry a supermodel. Greetz Arnoud -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: donderdag 24 juni 2004 21:24 To: Gregg Vanderheiden Cc: 'Guido Gybels'; gunnar.hellstrom@omnitor.se; fluffy@cisco.com; simple@ietf.org; paulej@packetizer.com; toip@snowshore.com; smundra@telogy.com; a.vwijk@viataal.nl Subject: Re: [Simple] RE: [Sipping] RE: text/T140 and audio/t140was:[avt]Comments/questions on draft-ietf-av 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 Jul 1 11:22: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 LAA09590 for ; Thu, 1 Jul 2004 11:22: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 1Bg3OK-00054v-HW for simple-archive@ietf.org; Thu, 01 Jul 2004 11:22:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bg3L0-0003y5-00 for simple-archive@ietf.org; Thu, 01 Jul 2004 11:18:58 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bg3Fy-0002jg-00; Thu, 01 Jul 2004 11:13:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bg2Ds-0008QJ-95; Thu, 01 Jul 2004 10:07:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdnOM-0003wJ-08 for simple@megatron.ietf.org; Fri, 25 Jun 2004 05:53:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20624 for ; Fri, 25 Jun 2004 05:53: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 1BdnOJ-0007fn-4t for simple@ietf.org; Fri, 25 Jun 2004 05:53:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdnNL-0007ND-00 for simple@ietf.org; Fri, 25 Jun 2004 05:52:04 -0400 Received: from smtp.eweka.nl ([81.171.101.3]) by ietf-mx with esmtp (Exim 4.12) id 1BdnMR-00073m-00 for simple@ietf.org; Fri, 25 Jun 2004 05:51:07 -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 i5PAW6dT057499; Fri, 25 Jun 2004 10:32:10 GMT (envelope-from a.vwijk@viataal.nl) Message-Id: <200406251032.i5PAW6dT057499@smtp.eweka.nl> From: "Arnoud van Wijk" To: "'Paul E. Jones'" , "'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 11:50:47 +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 In-Reply-To: <200406242315.i5ONFkgd020933@berlin.arid.us> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 thread-index: AcRZ7oAhxcB0CC6GT5qLh6XIsdQ+iQAT8qmAABaV8PA= Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 01 Jul 2004 10:07:21 -0400 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.3 required=5.0 tests=AWL,MISSING_OUTLOOK_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Good point Paul! Also..I want to point it out again... WE ARE NOT TALKING ABOUT REPLACING INSTANT MESSAGING WITH INTERACTIVE TEXT! Most of you already know that. But just today I met another person who still thinks Interactive text is to replace IM. I do not understand the hostility from several IM people. Interactive text is even going to make IM better! See it as an additional valuable service for IM. Users exchange IM messages, and then a discussion starts, they switch over into real-time chat mode. Discuss things, work out plans in real-time. Then end the real-time chat mode. And the next 2 hours they exchange a few IM messages. 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. Cheers Arnoud -----Original Message----- From: owner-toip@snowshore.com [mailto:owner-toip@snowshore.com] On Behalf Of Paul E. Jones Sent: vrijdag 25 juni 2004 1:16 To: 'Paul Kyzivat'; 'Guido Gybels' Cc: gunnar.hellstrom@omnitor.se; gv@trace.wisc.edu; fluffy@cisco.com; simple@ietf.org; toip@snowshore.com; smundra@telogy.com; a.vwijk@viataal.nl Subject: RE: [Simple] RE: [Sipping] RE: text/T140 and audio/t140 was:[avt]Comments/questions on draft-ietf-av 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 - 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 Thu Jul 1 11:22: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 LAA09704 for ; Thu, 1 Jul 2004 11:22: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 1Bg3Om-00057u-0k for simple-archive@ietf.org; Thu, 01 Jul 2004 11:22:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bg3Lg-000498-00 for simple-archive@ietf.org; Thu, 01 Jul 2004 11:19:41 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bg3Gk-00031l-00; Thu, 01 Jul 2004 11: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 1Bg2Ds-0008Qm-SU; Thu, 01 Jul 2004 10:07:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bdncw-0006EX-JR for simple@megatron.ietf.org; Fri, 25 Jun 2004 06:08: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 GAA21082 for ; Fri, 25 Jun 2004 06:08: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 1Bdncu-0004VF-53 for simple@ietf.org; Fri, 25 Jun 2004 06:08:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bdnc0-0004DK-00 for simple@ietf.org; Fri, 25 Jun 2004 06:07:14 -0400 Received: from smtp.eweka.nl ([81.171.101.3]) by ietf-mx with esmtp (Exim 4.12) id 1Bdnba-0003uq-00 for simple@ietf.org; Fri, 25 Jun 2004 06:06:46 -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 i5PAlqdT057627; Fri, 25 Jun 2004 10:47:57 GMT (envelope-from a.vwijk@viataal.nl) Message-Id: <200406251047.i5PAlqdT057627@smtp.eweka.nl> From: "Arnoud van Wijk" To: "'Gunnar Hellstrom'" , "'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 12:06:34 +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 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 thread-index: AcRafev/fnnTPFKnT8S9cQ9Yjw4yKAAHPaBw Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 01 Jul 2004 10:07:21 -0400 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.2 required=5.0 tests=AWL,MISSING_OUTLOOK_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Reading Gunnar here.. I do have a very BIG worry here. "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" Yes..but here we have a big risk that those gateways and such are unable to communicate with each other, since the transport is again...different. So..WHY should we add yet another real-time text transport method? And perhaps it is a good idea to start some certification organization that certifies that gateway A can interwork with gateway B for T140. But would manufacturers care??? I propose text/t140 to work with SIMPLE IM. And not to add yet another form of text transport using MSRP. I am 100% pro for working close with SIMPLE to use text/t140, RFC2793. Best of Both worlds....... Greetz Arnoud -----Original Message----- From: owner-toip@snowshore.com [mailto:owner-toip@snowshore.com] On Behalf Of Gunnar Hellstrom Sent: vrijdag 25 juni 2004 8:29 To: Cullen Jennings Cc: 'Paul E. Jones'; simple@ietf.org; 'Toip list' Subject: RE: [Simple] RE: [Sipping] RE: text/T140 and audio/t140 was:[avt]Comments/questions on draft-ietf-avt-rfc2793bis-04 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 > > - 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 Thu Jul 1 11:23:40 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09799 for ; Thu, 1 Jul 2004 11:23: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 1Bg3PZ-0005YO-SS for simple-archive@ietf.org; Thu, 01 Jul 2004 11:23:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bg3MS-0004Wg-00 for simple-archive@ietf.org; Thu, 01 Jul 2004 11:20:29 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bg3Hx-0003FR-00; Thu, 01 Jul 2004 11:15:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bg2Dt-0008Qr-Cx; Thu, 01 Jul 2004 10:07:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdtBO-0004iC-2P for simple@megatron.ietf.org; Fri, 25 Jun 2004 12:04:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18398 for ; Fri, 25 Jun 2004 12:04: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 1BdtBM-0002or-MZ for simple@ietf.org; Fri, 25 Jun 2004 12:04:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bdt9a-0002PD-00 for simple@ietf.org; Fri, 25 Jun 2004 12:02:15 -0400 Received: from smtp.spamarrest.com ([66.150.163.174] helo=spamarrest.com) by ietf-mx with esmtp (Exim 4.12) id 1Bdt7W-0001V9-00 for simple@ietf.org; Fri, 25 Jun 2004 12:00:06 -0400 Received: from [128.104.192.100] (account vanderhe@smtp.spamarrest.com HELO NC6000BAK) by spamarrest.com (CommuniGate Pro SMTP 4.2b1) with ESMTP id 3112744; Fri, 25 Jun 2004 08:59:35 -0700 From: "Gregg Vanderheiden" To: "'Paul Kyzivat'" , "'Paul E. Jones'" Subject: RE: [Simple] RE: [Sipping] RE: text/T140 and audio/t140was:[avt]Comments/questions on draft-ietf-av Date: Fri, 25 Jun 2004 10:59:31 -0500 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: AcRawZ/VtD9KUUkKQc6Vn+Bndn5QNQACycYQ Message-ID: Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 01 Jul 2004 10:07:21 -0400 Cc: fluffy@cisco.com, 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.1 required=5.0 tests=AWL,MISSING_OUTLOOK_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Hey Paul, You raise an interesting point that has previously gone unnoticed. (at least by me). Phone calls are not routinely recorded and it is illegal to record calls without permission. However IM can, and as you say, is being logged. And email is too. I think deaf people would like their text phone conversations to be as wire-tap free as voice phone conversations. This is something that has not been on the radar screen before now. We need to add this to TTY equivalency list - since TTY calls also have phone tap restrictions on them equivalent to voice phone tap restrictions I believe. Gregg -- ------------------------------ Gregg C Vanderheiden Ph.D. Professor - Ind. Engr. & BioMed Engr. Director - Trace R & D Center University of Wisconsin-Madison 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. Paul (K) _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jul 1 11: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 LAA09843 for ; Thu, 1 Jul 2004 11: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 1Bg3Pp-0005aG-5G for simple-archive@ietf.org; Thu, 01 Jul 2004 11:23:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bg3Mi-0004dk-00 for simple-archive@ietf.org; Thu, 01 Jul 2004 11:20:45 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bg3IT-0003U2-00; Thu, 01 Jul 2004 11:16:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bg2Dt-0008Qw-SP; Thu, 01 Jul 2004 10:07:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Be9h9-0002dx-4t for simple@megatron.ietf.org; Sat, 26 Jun 2004 05:41: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 FAA00331 for ; Sat, 26 Jun 2004 05:41: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 1Be9h6-0005yS-QU for simple@ietf.org; Sat, 26 Jun 2004 05:41:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Be9gE-0005jZ-00 for simple@ietf.org; Sat, 26 Jun 2004 05:41:03 -0400 Received: from ns.ivd.nl ([193.67.37.226]) by ietf-mx with esmtp (Exim 4.12) id 1Be9fs-0005U8-00 for simple@ietf.org; Sat, 26 Jun 2004 05:40:40 -0400 Received: (from root@localhost) by ns.ivd.nl (8.9.3c/8.6.12) id LAA78302 for ; Sat, 26 Jun 2004 11:44:49 +0200 (CEST) Received: by ns.ivd.nl (TUNIX txp2/smap) for id sma078211; Sat, 26 Jun 04 11:44:11 +0200 Received: from IVD-Message_Server by gw-server.viataal.nl with Novell_GroupWise; Sat, 26 Jun 2004 11:39:40 +0200 Message-Id: X-Mailer: Novell GroupWise 5.5.5 Date: Sat, 26 Jun 2004 11:39:12 +0200 From: "A vWijk" To: , , , 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 X-Mailman-Approved-At: Thu, 01 Jul 2004 10:07:21 -0400 Subject: [Simple] 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.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable 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 use = VoIP. Thus will support RTP. I am NOT happy to add yet another way of transporting t140. And even = causing 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 analogue = 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 = 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. 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. 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 -------------------------------------------- - 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 Thu Jul 1 11:24: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 LAA09903 for ; Thu, 1 Jul 2004 11:24: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 1Bg3Q9-0005iV-EX for simple-archive@ietf.org; Thu, 01 Jul 2004 11:24:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bg3N8-0004sC-00 for simple-archive@ietf.org; Thu, 01 Jul 2004 11:21:11 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bg3J9-0003hf-00; Thu, 01 Jul 2004 11: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 1Bg2Du-0008RG-C4; Thu, 01 Jul 2004 10:07:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BeFLd-000056-1l for simple@megatron.ietf.org; Sat, 26 Jun 2004 11:44: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 LAA14122 for ; Sat, 26 Jun 2004 11:44: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 1BeFLc-0001Hj-8S for simple@ietf.org; Sat, 26 Jun 2004 11:44:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BeFKe-00012i-00 for simple@ietf.org; Sat, 26 Jun 2004 11:43:09 -0400 Received: from smtp.eweka.nl ([81.171.101.3]) by ietf-mx with esmtp (Exim 4.12) id 1BeFJn-0000nr-00 for simple@ietf.org; Sat, 26 Jun 2004 11:42:16 -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 i5QGNmdT065710; Sat, 26 Jun 2004 16:23:52 GMT (envelope-from a.vwijk@viataal.nl) Message-Id: <200406261623.i5QGNmdT065710@smtp.eweka.nl> From: "Arnoud van Wijk" To: "'Gunnar Hellstrom'" , , , Date: Sat, 26 Jun 2004 17:42:16 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 In-Reply-To: Thread-Index: AcRbccD2LE/XlMlZTgW8CP9BFkg0swAIgNvA Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Thu, 01 Jul 2004 10:07:21 -0400 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.8 required=5.0 tests=AWL,MAILTO_TO_SPAM_ADDR, MISSING_OUTLOOK_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Gunnar, I am always open for alternatives. Even just to learn from it. If choices are to be made..let it be on the right rationale and valid reasons. And not beliefs and uninformed choices and politics. I love to learn. :-) Greetz Arnoud -----Original Message----- From: owner-toip@snowshore.com [mailto:owner-toip@snowshore.com] On = Behalf Of Gunnar Hellstrom Sent: zaterdag 26 juni 2004 13:35 To: A vWijk; stf267@etsi.org; simple@ietf.org; toip@snowshore.com Subject: RE: Betr.: Using MSRP for real time text conversation Arnoud, I agree that the best opportunity to widespread implementation and interoperability is to have one good standardised method for real time text conversation per network type. We have just avoided (?) the threat for fragmentation even on the RTP = side 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 = good idea to standardise the MRSP option. So far, it seems to me that going with VoIP and IP Multimedia = conversation is the more logical route to keep on. The bandwidth requirements for MSRP was not encouraging. 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 = like 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 = components? 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 = use VoIP. >Thus will support RTP. > >I am NOT happy to add yet another way of transporting t140. And even causing 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 = analogue 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 = 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. 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. > >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 >-------------------------------------------- > > > >- >This list is maintained by Snowshore Networks - = http://www.snowshore.com >All comments on this list a > > - 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 Thu Jul 1 11:24: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 LAA09966 for ; Thu, 1 Jul 2004 11:24: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 1Bg3Qe-000602-LP for simple-archive@ietf.org; Thu, 01 Jul 2004 11:24:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bg3Nb-0004x4-00 for simple-archive@ietf.org; Thu, 01 Jul 2004 11:21:39 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bg3Jo-0003ll-00; Thu, 01 Jul 2004 11:17:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bg2Du-0008SA-UK; Thu, 01 Jul 2004 10:07:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bf4NN-0007pf-Vv for simple@megatron.ietf.org; Mon, 28 Jun 2004 18:13: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 SAA15731 for ; Mon, 28 Jun 2004 18:13: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 1Bf4NM-00073g-Jm for simple@ietf.org; Mon, 28 Jun 2004 18:13:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bf4KD-00069W-00 for simple@ietf.org; Mon, 28 Jun 2004 18:10:05 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx with esmtp (Exim 4.12) id 1Bf4Hc-0005E1-00 for simple@ietf.org; Mon, 28 Jun 2004 18:07:24 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 28 Jun 2004 18:14:27 -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 i5SM6n6m026044; Mon, 28 Jun 2004 18:06:51 -0400 (EDT) Received: from cisco.com ([161.44.79.239]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AJT61842; Mon, 28 Jun 2004 18:06:48 -0400 (EDT) Message-ID: <40E09677.8010305@cisco.com> Date: Mon, 28 Jun 2004 18:06:47 -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] RE: [Sipping] RE: text/T140 and audio/t140 was:[avt]Comments/questions on draft-ietf-av References: <200406242315.i5ONFkgd020933@berlin.arid.us> <40DC36EE.3080206@cisco.com> <40E0910E.2030306@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 01 Jul 2004 10:07:21 -0400 Cc: fluffy@cisco.com, "Paul E. Jones" , toip@snowshore.com, simple@ietf.org, gv@trace.wisc.edu, "'Guido Gybels'" , 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 Adam, I hope you are right! Perhaps I am being overly pessimistic. However it seems like many of those residential users may end up needing a relay for NAT/FW traversal. Paul Adam Roach wrote: > Paul Kyzivat wrote: > >> 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. > > > > Perhaps nobody except for me. > >> Most people seem to think that network administrators won't want to >> let IM thru the firewall without logging it. > > > > I certainly have higher hopes for MSRP than use exclusively in > enterprise applications. I don't think that it's unrealistic to believe > that, at some point in the future, ISPs will include SIP registrars as > readily as they currently do SMTP MTAs. If that happens, I can't imagine > that residential users of MSRP clients will do anything *but* > point-to-point. > > /a > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jul 1 11: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 LAA10021 for ; Thu, 1 Jul 2004 11: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 1Bg3Qo-00062b-5n for simple-archive@ietf.org; Thu, 01 Jul 2004 11:24:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bg3Nr-0004zm-00 for simple-archive@ietf.org; Thu, 01 Jul 2004 11:21:56 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bg3K5-0003oI-00; Thu, 01 Jul 2004 11:18:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bg2Dv-0008Su-L8; Thu, 01 Jul 2004 10:07:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bfldl-0005q3-9x for simple@megatron.ietf.org; Wed, 30 Jun 2004 16:25: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 QAA13785 for ; Wed, 30 Jun 2004 16:25: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 1Bfldh-0002ej-HT for simple@ietf.org; Wed, 30 Jun 2004 16:25:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BflVm-0000eg-00 for simple@ietf.org; Wed, 30 Jun 2004 16:16:55 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BflPC-0006fb-00 for simple@ietf.org; Wed, 30 Jun 2004 16:10:06 -0400 Received: from av1-2-sn4.m-sp.skanova.net ([81.228.10.115]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BflBR-0002Fc-U4 for simple@ietf.org; Wed, 30 Jun 2004 15:55:54 -0400 Received: by av1-2-sn4.m-sp.skanova.net (Postfix, from userid 502) id 0E39937EBF; Wed, 30 Jun 2004 21:55:21 +0200 (CEST) Received: from smtp2-1-sn4.m-sp.skanova.net (smtp2-1-sn4.m-sp.skanova.net [81.228.10.183]) by av1-2-sn4.m-sp.skanova.net (Postfix) with ESMTP id 00FEE37E74; Wed, 30 Jun 2004 21:55:21 +0200 (CEST) Received: from vit (h53n2fls31o265.telia.com [217.208.189.53]) by smtp2-1-sn4.m-sp.skanova.net (Postfix) with SMTP id 96D5137E44; Wed, 30 Jun 2004 21:55:20 +0200 (CEST) From: "Gunnar Hellstrom" To: "Christer Holmberg (JO/LMF)" , "Ben Campbell" , "Cullen Jennings" Subject: RE: [Simple] Re: MSRP: Max message size indication Date: Wed, 30 Jun 2004 21:55:19 +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: Importance: Normal Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Thu, 01 Jul 2004 10:07:21 -0400 Cc: Adam Roach , hisham.khartabil@nokia.com, simple@ietf.org, alex.audu@alcatel.com, Paul H Kyzivat , Toip list , 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 Thanks Cullen, for helping to make the goals and intentions of the real t= ime text conversation work more known to all by telling "T.140 jokes". :-) ---------snip----------- > >And if it is set to 1 it means you are in character by character T.140 m= ode >:-) The previos line is a joke I'm not suggesting that > ---------snip------------ Appreciated. 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 Thu Jul 1 11:41: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 LAA11937 for ; Thu, 1 Jul 2004 11:41: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 1Bg3gv-0005bW-GR for simple-archive@ietf.org; Thu, 01 Jul 2004 11:41:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bg3fs-0005Ar-00 for simple-archive@ietf.org; Thu, 01 Jul 2004 11:40:33 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bg3eu-0004MD-00; Thu, 01 Jul 2004 11:39:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bg2gQ-0006HK-TS; Thu, 01 Jul 2004 10:37:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bg1LS-0008Gr-MA for simple@megatron.ietf.org; Thu, 01 Jul 2004 09:11: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 JAA22202 for ; Thu, 1 Jul 2004 09:11: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 1Bg1LS-0002gd-0u for simple@ietf.org; Thu, 01 Jul 2004 09:11:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bg1Kd-0002JK-00 for simple@ietf.org; Thu, 01 Jul 2004 09:10:27 -0400 Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1Bg1K9-0001vT-00 for simple@ietf.org; Thu, 01 Jul 2004 09:09:57 -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 i61D9tPA027662 for ; Thu, 1 Jul 2004 15:09:56 +0200 (MEST) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 1 Jul 2004 15:09:55 +0200 Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Thu, 1 Jul 2004 15:09:55 +0200 Message-ID: <342C4681F0D4A04CA50A97D74DA8FB9A0C0AC798@esealnt875.al.sw.ericsson.se> From: "Henrik Albertsson (KI/EAB)" To: "'Miguel.An.Garcia@nokia.com'" , simple@ietf.org Date: Thu, 1 Jul 2004 15:09: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: 01 Jul 2004 13:09:55.0901 (UTC) FILETIME=[B4490ED0:01C45F6C] Content-Transfer-Encoding: quoted-printable Subject: [Simple] XCap Directory: Large respons ? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org 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, The current version of the XCAP Directory does not contain any limit of = the size of the response. An XCAP Directory can potentially be very = large if it collects all list for a user, especially in a mobile = environment this would be problem. Any ideas how to limit the response? = Regards /Henrik=20 =20 =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 Thu Jul 1 12:08: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 MAA13979 for ; Thu, 1 Jul 2004 12:08: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 1Bg46X-0000bg-Kn for simple-archive@ietf.org; Thu, 01 Jul 2004 12:08:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bg440-0007PX-00 for simple-archive@ietf.org; Thu, 01 Jul 2004 12:05:29 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Bg41r-0006PP-00; Thu, 01 Jul 2004 12:03:15 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Bg2xm-0008Qh-5I; Thu, 01 Jul 2004 10:54:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bg3MW-0000fG-2y; Thu, 01 Jul 2004 11:20:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bg2JY-0003fN-Q8 for simple@megatron.ietf.org; Thu, 01 Jul 2004 10:13: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 KAA00919 for ; Thu, 1 Jul 2004 10:13: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 1Bg2JX-0003B7-T3 for simple@ietf.org; Thu, 01 Jul 2004 10:13:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bg2Ib-0002nD-00 for simple@ietf.org; Thu, 01 Jul 2004 10:12: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 1Bg2Ht-0002If-00 for simple@ietf.org; Thu, 01 Jul 2004 10: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 i61EBBLp020280 for ; Thu, 1 Jul 2004 09:11:11 -0500 From: Robert Sparks To: simple@ietf.org Content-Type: text/plain Message-Id: <1088691054.2183.6.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Date: Thu, 01 Jul 2004 09:10:55 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Burst of delayed messages X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org 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 You'll note a burst of old messages arriving on list today. Several messages got trapped in the moderator queue for being to large, we had an unusual burst of posts from non-subscribers, and I fell unusually behind on processing the queue. My apologies to those whose messages were delayed. RjS _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jul 1 12:13: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 MAA14474 for ; Thu, 1 Jul 2004 12:13: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 1Bg4Bj-00032h-HX for simple-archive@ietf.org; Thu, 01 Jul 2004 12:13:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bg4Ak-0002dc-00 for simple-archive@ietf.org; Thu, 01 Jul 2004 12:12:26 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bg49i-0001u2-00; Thu, 01 Jul 2004 12:11:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bg3pa-0008Qr-6W; Thu, 01 Jul 2004 11: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 1Bg3IO-0007j3-DJ for simple@megatron.ietf.org; Thu, 01 Jul 2004 11:16: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 LAA08959 for ; Thu, 1 Jul 2004 11:16: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 1Bg3IN-0003ek-HB for simple@ietf.org; Thu, 01 Jul 2004 11:16:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bg3EV-0002Nx-00 for simple@ietf.org; Thu, 01 Jul 2004 11:12:16 -0400 Received: from ns.execdsl.net ([208.184.15.238] helo=EXECDSL.COM) by ietf-mx with esmtp (Exim 4.12) id 1Bg3CH-0001em-00 for simple@ietf.org; Thu, 01 Jul 2004 11:09:57 -0400 Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 7135028; Thu, 01 Jul 2004 11:09:56 -0400 Message-Id: <5.1.0.14.0.20040701110539.023d8090@localhost> X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 01 Jul 2004 11:09:40 -0400 To: Miguel Garcia , SIMPLE mailing list From: "Joel M. Halpern" Subject: Re: [Simple] Double specification: text and schema In-Reply-To: <40E3F125.1050507@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 I would agree that this can be a problem. I would like to phrase the solution differently. (I am not sure whether I am disagreeing with Miguel's proposal or not.) While I like reading the schema, I really want the text to be clear and sufficiently precise. Hence, I would prefer not to weaken the use of MUST, etc. in the text. Rather, I would suggest that we simply state in a paragraph in the introduction, after the citation for the terms MUST, SHOULD, ... that in the case of conflict between the text and the XML schema, any requirements or prohibitions defined in the schema take precedence over conflicting text. Yours, Joel M. Halpern At 02:10 PM 7/1/2004 +0300, Miguel Garcia wrote: >The problem: We have two normative statements (one in the text, another in >the XML schema) indicating the same thing. This is not a big problem as >long as both statements indicate the same thing. But what happens if the >document evolves, and then we it is decided to make mandatory some >attribute that previously was optional, and what happen if the change is >reflected only in the textual form and not in the schema; or vice versa. >Then we run into trouble. > >Therefore, I would like to propose that, in the sake of interoperability >of implementations, documents indicating XML schemas MUST specify the >normative part as much as possible in the XML schema definition. Only >those bits that cannot be specified in the schema MUST be specified in the >text. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jul 1 12:37:40 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15740 for ; Thu, 1 Jul 2004 12:37: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 1Bg4ZB-0004mh-JM for simple-archive@ietf.org; Thu, 01 Jul 2004 12:37:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bg4YK-0004N7-00 for simple-archive@ietf.org; Thu, 01 Jul 2004 12:36:50 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bg4XT-0003su-00; Thu, 01 Jul 2004 12:35:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bg4By-0002sD-JF; Thu, 01 Jul 2004 12:13:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bg3rK-00026A-Cr for simple@megatron.ietf.org; Thu, 01 Jul 2004 11:52: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 LAA12923 for ; Thu, 1 Jul 2004 11:52: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 1Bg3rJ-0002U4-Gy for simple@ietf.org; Thu, 01 Jul 2004 11:52:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bg3qM-00026e-00 for simple@ietf.org; Thu, 01 Jul 2004 11:51:23 -0400 Received: from salvelinus.brooktrout.com ([204.176.205.6]) by ietf-mx with esmtp (Exim 4.12) id 1Bg3pT-0001iR-00 for simple@ietf.org; Thu, 01 Jul 2004 11:50:27 -0400 Received: from nhmail2.needham.brooktrout.com (nhmail2.eng.brooktrout.com [204.176.205.242]) by salvelinus.brooktrout.com (8.12.5/8.12.5) with ESMTP id i61FjYV0012945; Thu, 1 Jul 2004 11:45:36 -0400 (EDT) Received: by nhmail2.eng.brooktrout.com with Internet Mail Service (5.5.2653.19) id ; Thu, 1 Jul 2004 11:43:52 -0400 Message-ID: From: Eric Burger To: Arnoud van Wijk , "'Gregg Vanderheiden'" Subject: RE: [Simple] RE: [Sipping] RE: text/T140 and audio/t140was:[avt]C omments/questions on draft-ietf-av Date: Thu, 1 Jul 2004 11:43:43 -0400 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=AWL,YOU_WON autolearn=no version=2.60 I disagree that the tie-in is voice and real-time-text. I believe the tie-in is between IM and real-time text. If we say, "If you have voice, you MUST have real-time-text", it just won't happen, unless mandated by law. If we say, "If you have voice, you SHOULD have real-time-text", it really won't happen, unless someone is making a really high-end set. If we say, "If you have IM, you SHOULD/MUST have real-time-text", we will see real-time-text deployed in a big way. It is so easy to add it in that environment that it will probably "just happen." Moreover, even mid-priced telephony sets will probably include real-time-text, which was the goal of tying voice to real-time-text in the first place. > -----Original Message----- > From: Arnoud van Wijk [mailto:a.vwijk@viataal.nl] > Sent: Friday, June 25, 2004 5:40 AM > To: 'Paul Kyzivat'; 'Gregg Vanderheiden' > Cc: 'Guido Gybels'; gunnar.hellstrom@omnitor.se; fluffy@cisco.com; > simple@ietf.org; paulej@packetizer.com; toip@snowshore.com; > smundra@telogy.com > Subject: RE: [Simple] RE: [Sipping] RE: text/T140 and > audio/t140was:[avt]Comments/questions on draft-ietf-av > > > Hi Paul, > Is there a possibility that we can talk with Cisco and work > out a strategy > for the IP phones? Viataal and RNID and Trace are quite > willing to help > defining a good strategy that helps manufacturers to satify all users. > If there are enough IP phones in every price range that > supports Interactive > Text, then I do not care whether EVERY phone has it. > > Not all phones support caller ID, but there are plenty phones > who supports > it anyway. > > I would indeed focus in 2 ways. > > 1. If an IP phone supports IM, it MUST also support > Interactive text. There > is no excuse whichsoever, no argument to explain why > interactive text is > then skipped! > 2. For every price range, there MUST be IP phones with > Interactive text > capabilities. Regardless they also support IM or not. > > A voice only cheap IP phone to be used for your teenage > daughter or in the > basement, etc. there is no need for text support there. If > possible, great.. > > As long that user who need Interactive text can buy such phones at any > Wallmart or other shop. And that other users can just as > easily buy an IP > phone with interactive text without having to rob a bank, or > take a second > mortgage. > > Ofcourse, I do want to see Interactive text in EVERY phone. I > also want to > win the lottery jackpot. And marry a supermodel. > > Greetz > > Arnoud > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: donderdag 24 juni 2004 21:24 > To: Gregg Vanderheiden > Cc: 'Guido Gybels'; gunnar.hellstrom@omnitor.se; fluffy@cisco.com; > simple@ietf.org; paulej@packetizer.com; toip@snowshore.com; > smundra@telogy.com; a.vwijk@viataal.nl > Subject: Re: [Simple] RE: [Sipping] RE: text/T140 and > audio/t140was:[avt]Comments/questions on draft-ietf-av > > > > 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 > > > - > 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 Thu Jul 1 12:39: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 MAA15855 for ; Thu, 1 Jul 2004 12:39: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 1Bg4ax-0005YO-45 for simple-archive@ietf.org; Thu, 01 Jul 2004 12:39:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bg4a2-0005B4-00 for simple-archive@ietf.org; Thu, 01 Jul 2004 12:38:35 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bg4ZG-0004fd-00; Thu, 01 Jul 2004 12:37:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bg4Nb-0001rd-MJ; Thu, 01 Jul 2004 12:25:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bg3tO-0004pn-1w for simple@megatron.ietf.org; Thu, 01 Jul 2004 11:54: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 LAA13028 for ; Thu, 1 Jul 2004 11:54: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 1Bg3tN-0003Fc-8P for simple@ietf.org; Thu, 01 Jul 2004 11:54:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bg3sP-0002sP-00 for simple@ietf.org; Thu, 01 Jul 2004 11:53:30 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx with esmtp (Exim 4.12) id 1Bg3rk-0002Tm-00 for simple@ietf.org; Thu, 01 Jul 2004 11:52:48 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 01 Jul 2004 11:51: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 i61FqEaG021947; Thu, 1 Jul 2004 11:52:15 -0400 (EDT) Received: from cisco.com ([161.44.79.239]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AJV69996; Thu, 1 Jul 2004 11:52:13 -0400 (EDT) Message-ID: <40E4332D.80802@cisco.com> Date: Thu, 01 Jul 2004 11:52: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: Guido Gybels Subject: Re: Tiny ant vs big Mammoths, was RE: [Simple] Using MSRP for realtime text conversation References: <4818CE251FC66942A7EF35B92695246E01B2212F@JUPITER-MSG.ad.rnid.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: "RNIDMAIL.GWIA.\"A.vWijk@viataal.nl\"" , stf267@etsi.org, 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 Guido Gybels wrote: > All, > > < incompatibilities. So that is why I am negative about just using MSRP for > interactive text.>> > > Arnoud is, as usual, right. The very last thing we should even contemplate is introducing competing solutions for deaf people's communication needs. Remember what has happened in the PSTN and how as a direct result of that deaf andf hard of hearing people have hugely lost out in society. > > As far as t140/RTP is concerned: that was not randomly chosen, but after careful analysis of the problem in combination with looking at real-world constraints in terms of bandwidth, cost, practicality, etc. > > For all clarity: so far there is *NO* scientific data whatsoever that shows there is a more bandwidth effective solution than t140/RTP. So, if people don't want to agree with that, can I respectfully suggest they submit relevant data from repeatable experiments that we can peer review. > > There is a lot of misunderstanding about t140/RTP it seems. Arnoud and Gunnar are doing a great job in educating the community, so keep it up! I don't have any data to add to this, but based on all the discussion here on the subject I am inclined to accept it. So I will return to what I proposed several days ago: I think we should assume that text/t140 (or perhaps audio/t140c) will be used for the transport of real time text. And what we should be discussing are the mechanisms by which the desire and ability to use it can be *effectively* and *efficiently* negotiated. I also think that it makes sense that endpoints that are prepared to exchange text via MSRP should also be prepared to exchange it via text/t140 and visa versa. That is the path that will lead to the most ubiquitous availability of text communication between those that prefer one or the other of the modes. I doubt we can standardize this as a requirement in ietf, but we can define the signaling negotiations that support it, so that device vendors will know how to build something that can interoperate effectively. What I think would *not* be effective is to expect every IM client to offer both MSRP and text/t140 every time it seeks to establish an IM session, just in case the called party prefers to use real time text. Similarly, I don't think we should expect a text capable voice client to offer both audio and text/t140 when audio is preferred and there is no particular reason to expect use of text. It might make sense for such a device to offer audio/t140c, but maybe there is a better solution. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jul 1 12:40: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 MAA15905 for ; Thu, 1 Jul 2004 12:40: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 1Bg4bv-0005wK-AO for simple-archive@ietf.org; Thu, 01 Jul 2004 12:40:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bg4b2-0005Z7-00 for simple-archive@ietf.org; Thu, 01 Jul 2004 12:39:37 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bg4aZ-0005BQ-00; Thu, 01 Jul 2004 12:39:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bg4O7-0002Hx-9n; Thu, 01 Jul 2004 12:26:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bg3vD-0005xV-PV for simple@megatron.ietf.org; Thu, 01 Jul 2004 11:56: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 LAA13097 for ; Thu, 1 Jul 2004 11:56: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 1Bg3vC-00042U-VE for simple@ietf.org; Thu, 01 Jul 2004 11:56:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bg3uF-0003dS-00 for simple@ietf.org; Thu, 01 Jul 2004 11:55:25 -0400 Received: from salvelinus.brooktrout.com ([204.176.205.6]) by ietf-mx with esmtp (Exim 4.12) id 1Bg3tK-0003FK-00 for simple@ietf.org; Thu, 01 Jul 2004 11:54:26 -0400 Received: from nhmail2.needham.brooktrout.com (nhmail2.eng.brooktrout.com [204.176.205.242]) by salvelinus.brooktrout.com (8.12.5/8.12.5) with ESMTP id i61FiiV0012868; Thu, 1 Jul 2004 11:44:47 -0400 (EDT) Received: by nhmail2.eng.brooktrout.com with Internet Mail Service (5.5.2653.19) id ; Thu, 1 Jul 2004 11:43:02 -0400 Message-ID: From: Eric Burger To: Arnoud van Wijk , "'Gunnar Hellstrom'" , "'Cullen Jennings'" Subject: RE: [Simple] RE: [Sipping] RE: text/T140 and audio/t140 was:[avt] Comments/questions on draft-ietf-avt-rfc2793bis-04 Date: Thu, 1 Jul 2004 11:42:53 -0400 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=AWL autolearn=no version=2.60 I have what might be a stupid, stupid question, that might better be raised on AVT, but here I go anyway. I think Dean is 100% correct in his assertion that RTP redundancy makes the congestion problem worse and is wasteful when there is no congestion. How is this for a counter-proposal: Just use TCP with Nagle turned off. You would get character-by-character, or however much you want to buffer. You get in-order delivery. ACKs would definitely get bundled, especially if we suggest decent window sizes. Easily negotiable in TCP. It would become the dominant mode just by virtue of the number of devices supporting it. What about Arnoud's point of all the different transport mechanisms for T.140? Over half of them are tied to the transport mechanism. Can't fight physics. As for the IP-oriented ones. Yes, RFC2793/bis is *specified* for them, but how many implementations are there really? Yes, it might be used for 80% of deployed IP systems, but that is still a tiny fraction of the goal of getting real-time text into every IM device (which I think is realistic). > -----Original Message----- > From: Arnoud van Wijk [mailto:a.vwijk@viataal.nl] > Sent: Friday, June 25, 2004 6:07 AM > To: 'Gunnar Hellstrom'; 'Cullen Jennings' > Cc: 'Paul E. Jones'; simple@ietf.org; 'Toip list' > Subject: RE: [Simple] RE: [Sipping] RE: text/T140 and audio/t140 > was:[avt]Comments/questions on draft-ietf-avt-rfc2793bis-04 > > > Reading Gunnar here.. > I do have a very BIG worry here. > "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" > > Yes..but here we have a big risk that those gateways and such > are unable to > communicate with each other, since the transport is again...different. > > So..WHY should we add yet another real-time text transport method? > > And perhaps it is a good idea to start some certification > organization that > certifies that gateway A can interwork with gateway B for T140. > But would manufacturers care??? > > I propose text/t140 to work with SIMPLE IM. And not to add > yet another form > of text transport using MSRP. > > I am 100% pro for working close with SIMPLE to use text/t140, RFC2793. > > Best of Both worlds....... > > Greetz > > Arnoud > > > -----Original Message----- > From: owner-toip@snowshore.com > [mailto:owner-toip@snowshore.com] On Behalf > Of Gunnar Hellstrom > Sent: vrijdag 25 juni 2004 8:29 > To: Cullen Jennings > Cc: 'Paul E. Jones'; simple@ietf.org; 'Toip list' > Subject: RE: [Simple] RE: [Sipping] RE: text/T140 and audio/t140 > was:[avt]Comments/questions on draft-ietf-avt-rfc2793bis-04 > > 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 > > > > > > > - > 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 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 Thu Jul 1 12:44: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 MAA16191 for ; Thu, 1 Jul 2004 12:44: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 1Bg4fL-0007CW-C6 for simple-archive@ietf.org; Thu, 01 Jul 2004 12:44:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bg4eI-0006lA-00 for simple-archive@ietf.org; Thu, 01 Jul 2004 12:42:59 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bg4dI-0006B4-00; Thu, 01 Jul 2004 12:41:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bg4O7-0002Ia-Uy; Thu, 01 Jul 2004 12:26:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bg3vG-0005xd-IN for simple@megatron.ietf.org; Thu, 01 Jul 2004 11:56: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 LAA13111 for ; Thu, 1 Jul 2004 11:56: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 1Bg3vF-00042p-Qh for simple@ietf.org; Thu, 01 Jul 2004 11:56:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bg3uL-0003eA-00 for simple@ietf.org; Thu, 01 Jul 2004 11:55: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 1Bg3tP-0002t6-00 for simple@ietf.org; Thu, 01 Jul 2004 11:54:31 -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 i61FrwLp020945; Thu, 1 Jul 2004 10:53:59 -0500 Message-ID: <40E43399.2020909@dynamicsoft.com> Date: Thu, 01 Jul 2004 10:54:01 -0500 From: Ben Campbell User-Agent: Mozilla Thunderbird 0.7 (Macintosh/20040616) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Burger Subject: Re: [Simple] MSRP: delivery reports and transaction responses References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: Adam Roach , 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 One area I am not sure we are communicating: The "positive" report says _nothing_ about whether the user has seen the message. It merely confirms that the message was received by the terminating device in the path. Does that still make it mirror a MDN? Eric Burger wrote: > Do I look blue in the face yet??? > > The reason for all of this bizarre flag / indicator interaction is we are > STILL trying to squeeze two different report notifications into one. > > Let's look at the requirements. > > #1: There is a need for positive acknowledgement, by sender's request, that > a message was delivered. This is an end-to-end issue, mirroring the MDN. > Note that local policy or security policy means the recipient MUST be able > to deny the sender's request for acknowledgement. > > #2: There is a need, by sender's request, for notification of transport > failure. This occurs when a relay can't send the message on, or is queuing > it for later delivery. This is a transport network (hop-by-hop) issue, > mirroring the DSN. > > Is there any reason not to have these two things separate, orthogonal > requests? > > Instead of nine-element matrixes with incompatible states, we end up with: > > MDN Requested, tell me only failures or tell me failure/success > DSN Requested, tell me only failures > > Experience with SMTP says, MUST NOT have every hop report positive DSN's. > Positive DSN's have no value, other than exposing the relay network to > potentially bad people. The thing of value is that the end user got the > message (MDN). > > Do I need to do _more_ text? > > > >>-----Original Message----- >>From: Adam Roach [mailto:adam@dynamicsoft.com] >>Sent: Thursday, June 17, 2004 6:13 PM >>To: Mike Hammer >>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 >> >> >>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 Thu Jul 1 13:08: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 NAA17742 for ; Thu, 1 Jul 2004 13:08: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 1Bg53A-0001mx-GS for simple-archive@ietf.org; Thu, 01 Jul 2004 13:08:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bg525-0001K4-00 for simple-archive@ietf.org; Thu, 01 Jul 2004 13:07:34 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bg511-0000TH-00; Thu, 01 Jul 2004 13: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 1Bg4Wc-0007c9-6S; Thu, 01 Jul 2004 12:35:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bg46x-0000j1-8x for simple@megatron.ietf.org; Thu, 01 Jul 2004 12:08: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 MAA14065 for ; Thu, 1 Jul 2004 12:08: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 1Bg46w-0000st-2M for simple@ietf.org; Thu, 01 Jul 2004 12:08:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bg44V-0007Wy-00 for simple@ietf.org; Thu, 01 Jul 2004 12:06:00 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Bg41w-0006Q2-01 for simple@ietf.org; Thu, 01 Jul 2004 12:03:21 -0400 Received: from salvelinus.brooktrout.com ([204.176.205.6]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Bg2up-0008Lt-Dp for simple@ietf.org; Thu, 01 Jul 2004 10:51:55 -0400 Received: from nhmail2.needham.brooktrout.com (nhmail2.eng.brooktrout.com [204.176.205.242]) by salvelinus.brooktrout.com (8.12.5/8.12.5) with ESMTP id i61FhDV0012376; Thu, 1 Jul 2004 11:43:15 -0400 (EDT) Received: by nhmail2.eng.brooktrout.com with Internet Mail Service (5.5.2653.19) id ; Thu, 1 Jul 2004 11:41:31 -0400 Message-ID: From: Eric Burger To: "Christer Holmberg (JO/LMF)" , "'Paul Kyzivat'" Subject: RE: [Simple] MSRP: Ending a session Date: Thu, 1 Jul 2004 11:41:23 -0400 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'" , "'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.0 required=5.0 tests=AWL,NEW_DOMAIN_EXTENSIONS autolearn=no version=2.60 I agree with Christer. If you really want this behavior, extend SIP. I don't want this behavior codified. In the real world, the media resources are long gone by the time the BYE hits. I really, really don't want to write-in an enormous denial-of-service opening by requiring the resources to stay around for 200 OK's that will never come. > -----Original Message----- > From: Christer Holmberg (JO/LMF) > [mailto:christer.holmberg@ericsson.com] > Sent: Monday, June 07, 2004 2:24 PM > To: 'Paul Kyzivat' > Cc: 'simple@ietf.org'; 'bcampbell@dynamicsoft.com' > Subject: RE: [Simple] MSRP: Ending a session > > > > 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 > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jul 1 13:08: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 NAA17775 for ; Thu, 1 Jul 2004 13:08: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 1Bg53H-0001nt-5F for simple-archive@ietf.org; Thu, 01 Jul 2004 13:08:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bg52B-0001Ky-00 for simple-archive@ietf.org; Thu, 01 Jul 2004 13:07:40 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bg517-0000Tx-00; Thu, 01 Jul 2004 13:06:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bg4Wd-0007ck-0s; Thu, 01 Jul 2004 12:35:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bg471-0000kf-PG for simple@megatron.ietf.org; Thu, 01 Jul 2004 12:08: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 MAA14086 for ; Thu, 1 Jul 2004 12:08: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 1Bg470-0000xf-Ul for simple@ietf.org; Thu, 01 Jul 2004 12:08:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bg44d-0007Zi-00 for simple@ietf.org; Thu, 01 Jul 2004 12:06:07 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Bg41y-0006PP-00 for simple@ietf.org; Thu, 01 Jul 2004 12:03:22 -0400 Received: from salvelinus.brooktrout.com ([204.176.205.6]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Bg2u7-0008L5-Hy for simple@ietf.org; Thu, 01 Jul 2004 10:51:11 -0400 Received: from nhmail2.needham.brooktrout.com (nhmail2.eng.brooktrout.com [204.176.205.242]) by salvelinus.brooktrout.com (8.12.5/8.12.5) with ESMTP id i61FeWV0011693; Thu, 1 Jul 2004 11:40:35 -0400 (EDT) Received: by nhmail2.eng.brooktrout.com with Internet Mail Service (5.5.2653.19) id ; Thu, 1 Jul 2004 11:38:50 -0400 Message-ID: From: Eric Burger To: Adam Roach Subject: RE: [Simple] MSRP: delivery reports and transaction responses Date: Thu, 1 Jul 2004 11:38:47 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Cc: 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 Do I look blue in the face yet??? The reason for all of this bizarre flag / indicator interaction is we are STILL trying to squeeze two different report notifications into one. Let's look at the requirements. #1: There is a need for positive acknowledgement, by sender's request, that a message was delivered. This is an end-to-end issue, mirroring the MDN. Note that local policy or security policy means the recipient MUST be able to deny the sender's request for acknowledgement. #2: There is a need, by sender's request, for notification of transport failure. This occurs when a relay can't send the message on, or is queuing it for later delivery. This is a transport network (hop-by-hop) issue, mirroring the DSN. Is there any reason not to have these two things separate, orthogonal requests? Instead of nine-element matrixes with incompatible states, we end up with: MDN Requested, tell me only failures or tell me failure/success DSN Requested, tell me only failures Experience with SMTP says, MUST NOT have every hop report positive DSN's. Positive DSN's have no value, other than exposing the relay network to potentially bad people. The thing of value is that the end user got the message (MDN). Do I need to do _more_ text? > -----Original Message----- > From: Adam Roach [mailto:adam@dynamicsoft.com] > Sent: Thursday, June 17, 2004 6:13 PM > To: Mike Hammer > 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 > > > 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 Thu Jul 1 13: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 NAA18915 for ; Thu, 1 Jul 2004 13: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 1Bg5Ey-0006tm-82 for simple-archive@ietf.org; Thu, 01 Jul 2004 13:20:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bg5DE-0005yM-00 for simple-archive@ietf.org; Thu, 01 Jul 2004 13:19:04 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Bg5Bc-00056F-00; Thu, 01 Jul 2004 13:17:24 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Bg49V-0001OB-Lw; Thu, 01 Jul 2004 12:11:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bg4Wg-0007fS-Fu; Thu, 01 Jul 2004 12:35:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bg47T-0000vf-Ot for simple@megatron.ietf.org; Thu, 01 Jul 2004 12:09: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 MAA14185 for ; Thu, 1 Jul 2004 12:09: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 1Bg47S-00014y-U1 for simple@ietf.org; Thu, 01 Jul 2004 12:09:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bg45Y-00008L-00 for simple@ietf.org; Thu, 01 Jul 2004 12:07:05 -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 1Bg42r-0006u5-00 for simple@ietf.org; Thu, 01 Jul 2004 12:04:17 -0400 Received: from [63.110.3.195] (dhcp195.dfw.dynamicsoft.com [63.110.3.195]) (authenticated bits=0) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id i61G4Cq0019749 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Jul 2004 11:04:12 -0500 Message-ID: <40E435EC.3080304@softarmor.com> Date: Thu, 01 Jul 2004 11:03:56 -0500 From: Dean Willis User-Agent: Mozilla Thunderbird 0.7 (Windows/20040616) X-Accept-Language: en-us, en MIME-Version: 1.0 To: A vWijk Subject: Re: Tiny ant vs big Mammoths, was 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, adam@dynamicsoft.com, simple@ietf.org, hisham.khartabil@nokia.com, toip@snowshore.com, gunnar.hellstrom@omnitor.se, 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=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit A vWijk wrote: > My comment marked with *** > *** 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 generations 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. > No, let's put it in the right perspective. Assume real-time text drives 2kb/s of bandwidth, or approximately 3 packets per second. Assume 20,000,000 users are running real-time-text sessions concurrently. This is approximately peak load for a really big mobile operator, and well below peak load for the Internet as a whole. Assume that real-time text continues to operate without the sort of congestion control that forces it to "back off" in the event of network congestion. We now have 40 billion (40E9) bits per second of non-bandwidth-controlled traffic out there, or approximately 60E6 packets per second. Will any of this ever traverse a link that is also trying to carry nice friendly TCP traffic? Will that link ever get congested? Will the real-time text "starve out" the TCP traffic when it does? The answers here are most likely "yes" . . . How can you assure us that this will never happen? Are operators going to build dedicated networks for real-time text? Are we going to use DS-markings to make real-time text low priority and discardable? Or, otherwise said, what gives real-time-text the "right" to cheat the rules and unfairly consume scarce network resources? Does any application have that right? -- Dean _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jul 1 13:20: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 NAA18938 for ; Thu, 1 Jul 2004 13:20: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 1Bg5F0-0006u5-9n for simple-archive@ietf.org; Thu, 01 Jul 2004 13:20:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bg5DG-0005yj-00 for simple-archive@ietf.org; Thu, 01 Jul 2004 13:19:07 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Bg5Be-00056F-00; Thu, 01 Jul 2004 13:17:26 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Bg49C-0001Nb-GQ; Thu, 01 Jul 2004 12:10:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bg4Wf-0007ew-GQ; Thu, 01 Jul 2004 12:35:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bg47G-0000ms-4n for simple@megatron.ietf.org; Thu, 01 Jul 2004 12:08: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 MAA14139 for ; Thu, 1 Jul 2004 12:08: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 1Bg47E-00012F-SC for simple@ietf.org; Thu, 01 Jul 2004 12:08:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bg44t-0007eE-00 for simple@ietf.org; Thu, 01 Jul 2004 12:06:24 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Bg422-0006Q2-00 for simple@ietf.org; Thu, 01 Jul 2004 12:03:26 -0400 Received: from salvelinus.brooktrout.com ([204.176.205.6]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Bg2te-0008Jm-0A for simple@ietf.org; Thu, 01 Jul 2004 10:50:42 -0400 Received: from nhmail2.needham.brooktrout.com (nhmail2.eng.brooktrout.com [204.176.205.242]) by salvelinus.brooktrout.com (8.12.5/8.12.5) with ESMTP id i61Fg4V0011919; Thu, 1 Jul 2004 11:42:07 -0400 (EDT) Received: by nhmail2.eng.brooktrout.com with Internet Mail Service (5.5.2653.19) id ; Thu, 1 Jul 2004 11:40:22 -0400 Message-ID: From: Eric Burger To: Andrew Allen Subject: RE: [Simple] MSRP: DSN lifetime open issue Date: Thu, 1 Jul 2004 11:40:21 -0400 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=AWL autolearn=no version=2.60 I would humbly beg to differ that IM/MSRP has different expectations than SMS. The whole point (originally) was that IM was to *replace* SMS. Carriers and users don't care that SMS is a relay service (SMPP anyone?) and IM could be point-to-point. Is there anyone that is implementing SIP MESSAGE that doesn't also to store-and-forward? If you think that IM will not replace SMS, why are we bothering? SMS, from a user perspective, would be infinitely more useful if IM doesn't, *in practice*, have comparable features. Note that I did not say that IM necessarily has to work the same as SMS. Note too that making it work the same is NOT a protocol issue -- it is an implementation issue. PLEASE feel free to not do this -- that will leave more room in the market :) > -----Original Message----- > From: Andrew Allen [mailto:aallen@rim.com] > Sent: Friday, May 28, 2004 2:18 AM > To: Paul.D.Smith@dataconnection.com; simple@ietf.org > Subject: Re: [Simple] MSRP: DSN lifetime open issue > > > > 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. > > 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 > Data Connection Ltd (DCL) > Tel: +44 20 8366 1177 Email: paul.d.smith@dataconnection.com > 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 > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jul 1 13:20: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 NAA18970 for ; Thu, 1 Jul 2004 13:20: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 1Bg5F4-0006un-6a for simple-archive@ietf.org; Thu, 01 Jul 2004 13:20:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bg5DL-0005ze-00 for simple-archive@ietf.org; Thu, 01 Jul 2004 13:19:12 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Bg5Bg-00056F-00; Thu, 01 Jul 2004 13:17:28 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Bg48c-0001L4-F1; Thu, 01 Jul 2004 12:10:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bg4We-0007eK-M2; Thu, 01 Jul 2004 12: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 1Bg47E-0000mq-UX for simple@megatron.ietf.org; Thu, 01 Jul 2004 12:08: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 MAA14133 for ; Thu, 1 Jul 2004 12:08: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 1Bg47D-000123-UT for simple@ietf.org; Thu, 01 Jul 2004 12:08:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bg44r-0007do-00 for simple@ietf.org; Thu, 01 Jul 2004 12:06:22 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Bg422-0006PP-00 for simple@ietf.org; Thu, 01 Jul 2004 12:03:26 -0400 Received: from salvelinus.brooktrout.com ([204.176.205.6]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Bg2tg-0008Jm-4r for simple@ietf.org; Thu, 01 Jul 2004 10:50:44 -0400 Received: from nhmail2.needham.brooktrout.com (nhmail2.eng.brooktrout.com [204.176.205.242]) by salvelinus.brooktrout.com (8.12.5/8.12.5) with ESMTP id i61FfMV0011833; Thu, 1 Jul 2004 11:41:26 -0400 (EDT) Received: by nhmail2.eng.brooktrout.com with Internet Mail Service (5.5.2653.19) id ; Thu, 1 Jul 2004 11:39:40 -0400 Message-ID: From: Eric Burger To: Orit Levin Subject: RE: [Simple] MSRP: delivery reports and transaction responses Date: Thu, 1 Jul 2004 11:39:32 -0400 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=AWL autolearn=no version=2.60 I would offer that DSN report generation is a matter of local policy. If I were a privacy advocate on the IESG, REQUIRING DSN reporting would be a no-no. I would make the MUST a SHOULD. > -----Original Message----- > From: Orit Levin [mailto:oritl@microsoft.com] > Sent: Friday, June 18, 2004 11:58 AM > To: Mike Hammer; 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 > > > 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 > >>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 > > _______________________________________________ > Simple mailing 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 Jul 1 13:47: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 NAA20765 for ; Thu, 1 Jul 2004 13:47: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 1Bg5ev-0002KA-8C for simple-archive@ietf.org; Thu, 01 Jul 2004 13:47:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bg5e5-0001vp-00 for simple-archive@ietf.org; Thu, 01 Jul 2004 13:46:50 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bg5dP-0001U8-00; Thu, 01 Jul 2004 13:46:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bg5TV-0007XZ-Ii; Thu, 01 Jul 2004 13:35:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bg5HY-0008KM-UQ for simple@megatron.ietf.org; Thu, 01 Jul 2004 13:23: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 NAA19282 for ; Thu, 1 Jul 2004 13:23: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 1Bg5HX-0000N5-PC for simple@ietf.org; Thu, 01 Jul 2004 13:23:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bg5Gm-0007mJ-00 for simple@ietf.org; Thu, 01 Jul 2004 13:22:45 -0400 Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx with esmtp (Exim 4.12) id 1Bg5Fy-000799-00 for simple@ietf.org; Thu, 01 Jul 2004 13:21:54 -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 i61HCaTL006636 for ; Thu, 1 Jul 2004 12:12:37 -0500 (CDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Thu, 1 Jul 2004 18:12:35 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB00C290139@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'Miguel Garcia'" , "'SIMPLE mailing list'" Subject: RE: [Simple] Double specification: text and schema Date: Thu, 1 Jul 2004 18:12:34 +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 Although I am not an author of these drafts, I agree strongly with Miguel here. In fact we already had a similar discussion in the floor control design team in XCON (BNF versus text rather than XML versus text) and came to the same conclusion. regards Keith > -----Original Message----- > From: Miguel Garcia [mailto:Miguel.An.Garcia@nokia.com] > Sent: 01 July 2004 12:10 > To: SIMPLE mailing list > Subject: [Simple] Double specification: text and schema > > > Hi: > > I want to point out an issue I have found when reviewing a > few I-Ds that > define XML schemas. > > The problem is that many documents do double normative > specification: on > one side, they introduce normative text when they describe > the various > elements that are part of the XML schema; on the other side, the XML > schema is normative by itself. > > An example: > > draft-ietf-simple-filter-format-01.txt says in section 3.2 > > The MUST have an 'id' attribute. The value of the 'id' > attribute MUST be unique within the element. The > MAY have an 'uri' attribute. The value of the 'uri' > attribute is the URI of the resource which the filter applies to. > The MAY have an 'domain' attribute. The value of the > 'domain' attribute is the domain of the resources that the filter > applies to. The "uri" attribute and the "domain" > attribute MUST NOT > appear together in a filter. > > Then, the XML schema indicates that MUST have a > required 'id' > attribute: > > > > The schema also says that MAY have a 'uri' attribute > (optional): > > > > > And so on. > > The problem: We have two normative statements (one in the > text, another > in the XML schema) indicating the same thing. This is not a > big problem > as long as both statements indicate the same thing. But what > happens if > the document evolves, and then we it is decided to make > mandatory some > attribute that previously was optional, and what happen if > the change is > reflected only in the textual form and not in the schema; or > vice versa. > Then we run into trouble. > > Therefore, I would like to propose that, in the sake of > interoperability > of implementations, documents indicating XML schemas MUST specify the > normative part as much as possible in the XML schema definition. Only > those bits that cannot be specified in the schema MUST be > specified in > the text. > > According to this suggestion, the above paragraph would be > re-written as: > > The has an 'id' attribute. The value of the 'id' > attribute MUST be unique within the element. The > has an 'uri' attribute. The value of the 'uri' > attribute is the URI of the resource which the filter applies to. > The has an 'domain' attribute. The value of the > 'domain' attribute is the domain of the resources that the filter > applies to. The 'uri' attribute and the 'domain' > attribute MUST NOT > appear together in a filter. > > Note that the text above still indicates a couple of > normative sentences > that cannot be expressed (to my knowledge) in the schema. > > Comments? Can we agree this way of working from now on? > > - 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 > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jul 1 13:49: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 NAA20953 for ; Thu, 1 Jul 2004 13:49: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 1Bg5gv-0003AO-PI for simple-archive@ietf.org; Thu, 01 Jul 2004 13:49:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bg5g6-0002lZ-00 for simple-archive@ietf.org; Thu, 01 Jul 2004 13:48:55 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bg5fE-0002Iv-00; Thu, 01 Jul 2004 13:48:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bg5Tg-0007Zl-EX; Thu, 01 Jul 2004 13:36:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bg5JV-0000ut-A3 for simple@megatron.ietf.org; Thu, 01 Jul 2004 13:25: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 NAA19393 for ; Thu, 1 Jul 2004 13: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 1Bg5JU-00018Y-B2 for simple@ietf.org; Thu, 01 Jul 2004 13:25:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bg5IZ-0000lW-00 for simple@ietf.org; Thu, 01 Jul 2004 13:24:36 -0400 Received: from smtp.eweka.nl ([81.171.101.3]) by ietf-mx with esmtp (Exim 4.12) id 1Bg5Hz-0000OI-00 for simple@ietf.org; Thu, 01 Jul 2004 13:24:00 -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 i61HNib0007415; Thu, 1 Jul 2004 19:23:50 +0200 (CEST) (envelope-from a.vwijk@viataal.nl) Message-Id: <200407011723.i61HNib0007415@smtp.eweka.nl> From: "Arnoud van Wijk" To: "'Dean Willis'" Subject: RE: Tiny ant vs big Mammoths, was RE: [Simple] Using MSRP for real time text conversation Date: Thu, 1 Jul 2004 19:23:34 +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 In-Reply-To: <40E435EC.3080304@softarmor.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Thread-Index: AcRfhSgGp69wz7mdQc2STF2vk1RzZAACN3aQ Content-Transfer-Encoding: 7bit Cc: stf267@etsi.org, adam@dynamicsoft.com, simple@ietf.org, hisham.khartabil@nokia.com, toip@snowshore.com, gunnar.hellstrom@omnitor.se, 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.8 required=5.0 tests=AWL,MAILTO_TO_SPAM_ADDR, MISSING_OUTLOOK_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Dean, I said this to indicate that the method Interactive text is using for redundancy will only slightly increase the bandwidth. There are generally no more packets per second being sent with redundancy, the redundant generation is sent with the normal next batch of typed characters in the following packet! Think of a bus with 10 characters in it or a bus with 20 characters in it. It is then the same bus. It is not 1 packet per character! Unless you t y p e s o s l o w that there is a second or more between every character or so. :-) And if there is a congestion like you described with so many Interactive text streams. Normal congestion mechnism that are used for other RTP traffic will also apply for Interactive text. Also as stated in the 07 version of the RFC 2793 bis draft, if there is a good mechanism that prevents dropped packets..then that can be used instead of the 2 generations redundancy. So, I do not see the problem. Greetz Arnoud -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com] Sent: donderdag 1 juli 2004 18:04 To: A vWijk Cc: bcampbell@dynamicsoft.com; hisham.khartabil@nokia.com; gunnar.hellstrom@omnitor.se; adam@dynamicsoft.com; stf267@etsi.org; simple@ietf.org; toip@snowshore.com Subject: Re: Tiny ant vs big Mammoths, was RE: [Simple] Using MSRP for real time text conversation A vWijk wrote: > My comment marked with *** > *** 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 generations 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. > No, let's put it in the right perspective. Assume real-time text drives 2kb/s of bandwidth, or approximately 3 packets per second. Assume 20,000,000 users are running real-time-text sessions concurrently. This is approximately peak load for a really big mobile operator, and well below peak load for the Internet as a whole. Assume that real-time text continues to operate without the sort of congestion control that forces it to "back off" in the event of network congestion. We now have 40 billion (40E9) bits per second of non-bandwidth-controlled traffic out there, or approximately 60E6 packets per second. Will any of this ever traverse a link that is also trying to carry nice friendly TCP traffic? Will that link ever get congested? Will the real-time text "starve out" the TCP traffic when it does? The answers here are most likely "yes" . . . How can you assure us that this will never happen? Are operators going to build dedicated networks for real-time text? Are we going to use DS-markings to make real-time text low priority and discardable? Or, otherwise said, what gives real-time-text the "right" to cheat the rules and unfairly consume scarce network resources? Does any application have that right? -- Dean _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jul 1 14:03: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 OAA21624 for ; Thu, 1 Jul 2004 14:03: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 1Bg5ua-0000lU-3p for simple-archive@ietf.org; Thu, 01 Jul 2004 14:03:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bg5tO-0000Mc-00 for simple-archive@ietf.org; Thu, 01 Jul 2004 14:02:39 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bg5sb-0007cw-00; Thu, 01 Jul 2004 14:01:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bg5Wc-0007yg-QH; Thu, 01 Jul 2004 13:39:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bg5OF-00041C-H9 for simple@megatron.ietf.org; Thu, 01 Jul 2004 13:30:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19509 for ; Thu, 1 Jul 2004 13:30: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 1Bg5OE-0002xT-HQ for simple@ietf.org; Thu, 01 Jul 2004 13:30:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bg5NJ-0002bB-00 for simple@ietf.org; Thu, 01 Jul 2004 13:29:30 -0400 Received: from web41510.mail.yahoo.com ([66.218.93.93]) by ietf-mx with smtp (Exim 4.12) id 1Bg5Mz-0002Ex-00 for simple@ietf.org; Thu, 01 Jul 2004 13:29:10 -0400 Message-ID: <20040701172836.1339.qmail@web41510.mail.yahoo.com> Received: from [131.107.3.73] by web41510.mail.yahoo.com via HTTP; Thu, 01 Jul 2004 10:28:36 PDT Date: Thu, 1 Jul 2004 10:28:36 -0700 (PDT) From: Sean Olson Subject: RE: [Simple] MSRP Boundary header To: Chris Boulton , Ben Campbell , Vijay Kishen Hampapur Parthasarathy In-Reply-To: <45730E094814E44488F789C1CDED27AE02BDF4E9@gbnewp0758m.eu.ubiquity.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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 Simple. You have two different usage scenarios. One way is appropriate for one usage and the other way is appropriate for the other usage. This is no different than HTTP which supports both mechanisms (today). The "complexity" of supporting both is very minimal and in fact the hybrid approach I suggested makes this trivial and transparent to the implementor. --- Chris Boulton wrote: > I agree with Ben - why do something twice. This > only increases > complexity and potential to provide conflicting + > syntactically > incorrect semantics. > > Chris. > > > -----Original Message----- > From: Ben Campbell > [mailto:bcampbell@dynamicsoft.com] > Sent: 30 June 2004 19:35 > To: Vijay Kishen Hampapur Parthasarathy > Cc: Ted Hardie; Paul Kyzivat; seancolson@yahoo.com; > simple@ietf.org > Subject: Re: [Simple] MSRP Boundary header > > 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 > > > 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 Jul 1 14:10: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 OAA22192 for ; Thu, 1 Jul 2004 14:10: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 1Bg61Q-0003is-9U for simple-archive@ietf.org; Thu, 01 Jul 2004 14:10:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bg60I-0003Hk-00 for simple-archive@ietf.org; Thu, 01 Jul 2004 14:09:47 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bg5zV-0002pr-00; Thu, 01 Jul 2004 14:08:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bg5hV-00058u-JE; Thu, 01 Jul 2004 13:50:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bg5UD-0007lP-4i for simple@megatron.ietf.org; Thu, 01 Jul 2004 13:36: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 NAA19823 for ; Thu, 1 Jul 2004 13:36: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 1Bg5UC-0005Nw-4o for simple@ietf.org; Thu, 01 Jul 2004 13:36:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bg5TN-0004zt-00 for simple@ietf.org; Thu, 01 Jul 2004 13:35:46 -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 1Bg5So-0004Ya-00 for simple@ietf.org; Thu, 01 Jul 2004 13:35:10 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 01 Jul 2004 10:33:59 -0700 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i61HYb4N003182; Thu, 1 Jul 2004 10:34:37 -0700 (PDT) Received: from [171.71.208.148] (dhcp-171-71-208-148.cisco.com [171.71.208.148]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id AQF66086; Thu, 1 Jul 2004 10:34:36 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Thu, 01 Jul 2004 10:34:34 -0700 Subject: Re: [Simple] Re: MSRP: Max message size indication From: Cullen Jennings To: Ben Campbell Message-ID: In-Reply-To: <40E2C22C.8050800@dynamicsoft.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit 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.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit On 6/30/04 6:37 AM, "Ben Campbell" wrote: > I don't want to solve that problem just yet. _But_, do you really > consider a real time text usage of MSRP by sending one character per > chunk to be acceptable? Talk about a bandwidth explosion. I think we > will need something more complicated for that to work. I don't think this would it be used across 300 baud modems - no. Would anyone care if I did it across my broadband DSL/Cable connection? I really doubt it. The same can be said of voice or video over a network. This media has different bandwidth usage characteristics and will be used where appropriate. I find the whole bandwidth argument on this uninteresting - the bandwidth used is more than traditional IM and less than voice - that's about all you can say on the bandwidth. Would it be used on a cell phone network? I don't know - depends on much per byte they change and what the value of this mode is. I point out, it is less bandwidth than voice no matter how you count it. On a compressed link, it will compress to very little bandwidth. The the MSRP draft allows you send very short message, like one character. I send one and two character IMs all the time. We are already somewhat doing this - what we are talking about is a hint about if a chunk should be displayed before the whole message is received or not. Cullen _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jul 1 14:15: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 OAA22489 for ; Thu, 1 Jul 2004 14: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 1Bg65t-0005dG-1D for simple-archive@ietf.org; Thu, 01 Jul 2004 14:15:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bg650-0005GL-00 for simple-archive@ietf.org; Thu, 01 Jul 2004 14:14:40 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bg64Y-0004t4-00; Thu, 01 Jul 2004 14:14:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bg5wf-00040Z-F0; Thu, 01 Jul 2004 14:06:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bg5XA-0008Bm-NB for simple@megatron.ietf.org; Thu, 01 Jul 2004 13:39: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 NAA20049 for ; Thu, 1 Jul 2004 13:39: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 1Bg5X9-0006fs-OI for simple@ietf.org; Thu, 01 Jul 2004 13:39:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bg5WD-0006F9-00 for simple@ietf.org; Thu, 01 Jul 2004 13:38:42 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx with esmtp (Exim 4.12) id 1Bg5VB-0005Pa-00 for simple@ietf.org; Thu, 01 Jul 2004 13:37:37 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 01 Jul 2004 13:45:08 -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 i61HamaG016044; Thu, 1 Jul 2004 13:36:49 -0400 (EDT) Received: from cisco.com ([161.44.79.239]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AJV78944; Thu, 1 Jul 2004 13:36:47 -0400 (EDT) Message-ID: <40E44BAF.30302@cisco.com> Date: Thu, 01 Jul 2004 13:36:47 -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: Eric Burger 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'" , "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=1.0 required=5.0 tests=AWL,NEW_DOMAIN_EXTENSIONS autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Eric Burger wrote: > I agree with Christer. If you really want this behavior, extend SIP. I > don't want this behavior codified. In the real world, the media resources > are long gone by the time the BYE hits. > > I really, really don't want to write-in an enormous denial-of-service > opening by requiring the resources to stay around for 200 OK's that will > never come. I've lost the beginning of this thread, so I don't have a record of exactly what was proposed. So I will shoot from the hip. I certainly don't want to *require* resources to be held after BYE. It would be especially stupid to do that when the UA will have nothing better to do with incoming media than drop it in the bit bucket. OTOH, I think it at least ought to be permissible for a UA to try to get the last bit of media that might trickle in after the session is closed, and to process it if that has meaning for the device. There clearly is a problem with the chapter 15.1.1 of 3261 in this regard: "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." Its reasonable to require that media not be sent. But at least in the case of connection oriented media, it makes sense to permit any media remaining in the connection to be processed. (Its a little dicier with non-connection-oriented media because input to the same port may not be from the same source.) Details about the interpretation of this may need to be media specific. In the absence of this, when using MSRP, if I want to ensure that all my messages have been processed before ending the session I will have to send a last message with a requested positive acknowlegment before ending the session. (I guess this could be an empty message if I have nothing left to send when I want to end the session.) There may be a more interesting case to consider than the BYE of a simple call. Consider a case when A & B are directly connected, but there is a need to move to a mixer to establish a conference. In this case lets assume for simplicity that both A and B receive an INVITE/Replaces from the new focus, offering a new MSRP session. We presumably want the switch to be graceful with no messages lost. How do A and B manage the use of their old and new MSRP connections, and the termination of their old call in order to achieve this? I believe both A and B will want to stop sending and suck the old connection dry, before beginning to use the new connection. This will require closing the old stream for output but continuing to read till eof. Upon eof, switchover to the new stream can occur. But somebody has to send a BYE on the old call too. And neither A nor B will know what is really going on. So neither knows the other has been told to stop sending. To ensure they will stop receiving input, both A and B will want to send a BYE. With current rules, they will have to stop receiving at that time, messing things up. Paul >>-----Original Message----- >>From: Christer Holmberg (JO/LMF) >>[mailto:christer.holmberg@ericsson.com] >>Sent: Monday, June 07, 2004 2:24 PM >>To: 'Paul Kyzivat' >>Cc: 'simple@ietf.org'; 'bcampbell@dynamicsoft.com' >>Subject: RE: [Simple] MSRP: Ending a session >> >> >> >>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 >> > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jul 1 14:22: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 OAA22790 for ; Thu, 1 Jul 2004 14: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 1Bg6D3-0000Zd-Fp for simple-archive@ietf.org; Thu, 01 Jul 2004 14:22:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bg6By-000089-00 for simple-archive@ietf.org; Thu, 01 Jul 2004 14:21:50 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bg6Av-0007DG-00; Thu, 01 Jul 2004 14:20:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bg5x9-0004m1-Qu; Thu, 01 Jul 2004 14:06:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bg5Y7-00014R-Ql for simple@megatron.ietf.org; Thu, 01 Jul 2004 13:40: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 NAA20122 for ; Thu, 1 Jul 2004 13:40: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 1Bg5Y6-00076f-Pt for simple@ietf.org; Thu, 01 Jul 2004 13:40:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bg5X9-0006fx-00 for simple@ietf.org; Thu, 01 Jul 2004 13:39:40 -0400 Received: from smtp.eweka.nl ([81.171.101.3]) by ietf-mx with esmtp (Exim 4.12) id 1Bg5WE-0006FE-00 for simple@ietf.org; Thu, 01 Jul 2004 13:38:42 -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 i61HcUb0007457; Thu, 1 Jul 2004 19:38:39 +0200 (CEST) (envelope-from a.vwijk@viataal.nl) Message-Id: <200407011738.i61HcUb0007457@smtp.eweka.nl> From: "Arnoud van Wijk" To: "'Paul Kyzivat'" , "'Guido Gybels'" Subject: RE: Tiny ant vs big Mammoths, was RE: [Simple] Using MSRP for realtimetext conversation Date: Thu, 1 Jul 2004 19:38:23 +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 In-Reply-To: <40E4332D.80802@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Thread-Index: AcRfid+dCA10P8HLT5SQEbPACHZCUAABnO1A Content-Transfer-Encoding: 7bit Cc: "'RNIDMAIL.GWIA.\"A.vWijk@viataal.nl\"'" , stf267@etsi.org, 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.8 required=5.0 tests=AWL,MAILTO_TO_SPAM_ADDR, MISSING_OUTLOOK_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit I keep it short: Audio/t140c is ONLY and ONLY and again ONLY for PSTN trunking gateways. And NOT and NOT and again...NOT for end-terminals! And look at this: An IP phone is able to be used with IM. It has a keyboard and a nice screen. In that case, using Interactive text (text/t140) is so easy to implement. Especially when that IP phone is able to use RTP, because it allows voice over IP). Adding text/t140 here cost nothing. And I will have zero understanding if text/t140 is then skipped. I am not even saying that the IM client must work with text/t140. No..as long the same device also supports text/t140..I am happy. It is up to Cisco and other IP phone manufacturers how to make the interface and such. Seamlessly combined with the IM client or as a separate client. And true, not everybody is forced to use Interactive text. If you want audio only..fine... Just ensure that when you DO need Interactive text (being deaf or even something silly as spelling the address of a street or a russian name). Just make it available...and people WILL use it. Greetz Arnoud -----Original Message----- From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: donderdag 1 juli 2004 17:52 To: Guido Gybels Cc: RNIDMAIL.GWIA."A.vWijk@viataal.nl"; stf267@etsi.org; toip@snowshore.com; gunnar.hellstrom@omnitor.se; simple@ietf.org Subject: Re: Tiny ant vs big Mammoths, was RE: [Simple] Using MSRP for realtimetext conversation Guido Gybels wrote: > All, > > < incompatibilities. So that is why I am negative about just using MSRP for > interactive text.>> > > Arnoud is, as usual, right. The very last thing we should even contemplate is introducing competing solutions for deaf people's communication needs. Remember what has happened in the PSTN and how as a direct result of that deaf andf hard of hearing people have hugely lost out in society. > > As far as t140/RTP is concerned: that was not randomly chosen, but after careful analysis of the problem in combination with looking at real-world constraints in terms of bandwidth, cost, practicality, etc. > > For all clarity: so far there is *NO* scientific data whatsoever that shows there is a more bandwidth effective solution than t140/RTP. So, if people don't want to agree with that, can I respectfully suggest they submit relevant data from repeatable experiments that we can peer review. > > There is a lot of misunderstanding about t140/RTP it seems. Arnoud and Gunnar are doing a great job in educating the community, so keep it up! I don't have any data to add to this, but based on all the discussion here on the subject I am inclined to accept it. So I will return to what I proposed several days ago: I think we should assume that text/t140 (or perhaps audio/t140c) will be used for the transport of real time text. And what we should be discussing are the mechanisms by which the desire and ability to use it can be *effectively* and *efficiently* negotiated. I also think that it makes sense that endpoints that are prepared to exchange text via MSRP should also be prepared to exchange it via text/t140 and visa versa. That is the path that will lead to the most ubiquitous availability of text communication between those that prefer one or the other of the modes. I doubt we can standardize this as a requirement in ietf, but we can define the signaling negotiations that support it, so that device vendors will know how to build something that can interoperate effectively. What I think would *not* be effective is to expect every IM client to offer both MSRP and text/t140 every time it seeks to establish an IM session, just in case the called party prefers to use real time text. Similarly, I don't think we should expect a text capable voice client to offer both audio and text/t140 when audio is preferred and there is no particular reason to expect use of text. It might make sense for such a device to offer audio/t140c, but maybe there is a better solution. 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 Thu Jul 1 14:24: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 OAA22914 for ; Thu, 1 Jul 2004 14:24: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 1Bg6ET-0001On-N3 for simple-archive@ietf.org; Thu, 01 Jul 2004 14:24:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bg6DJ-0000c3-00 for simple-archive@ietf.org; Thu, 01 Jul 2004 14:23:14 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bg6CF-00005w-00; Thu, 01 Jul 2004 14: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 1Bg5yP-0005Nz-4h; Thu, 01 Jul 2004 14: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 1Bg5bH-00031X-8O for simple@megatron.ietf.org; Thu, 01 Jul 2004 13:43: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 NAA20465 for ; Thu, 1 Jul 2004 13:43: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 1Bg5bG-0000gN-8W for simple@ietf.org; Thu, 01 Jul 2004 13:43:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bg5a0-0007la-00 for simple@ietf.org; Thu, 01 Jul 2004 13:42: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 1Bg5YX-00076G-00 for simple@ietf.org; Thu, 01 Jul 2004 13:41:05 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 01 Jul 2004 10:39: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 i61HeXgI029486; Thu, 1 Jul 2004 10:40:33 -0700 (PDT) Received: from [171.71.208.148] (dhcp-171-71-208-148.cisco.com [171.71.208.148]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id AQF66726; Thu, 1 Jul 2004 10:40:32 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Thu, 01 Jul 2004 10:40:30 -0700 Subject: Re: [Simple] MSRP: Surpression of duplicates From: Cullen Jennings To: Ben Campbell Message-ID: In-Reply-To: <40E2C2F8.8040907@dynamicsoft.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" 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.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sounds good to me - more inline On 6/30/04 6:41 AM, "Ben Campbell" 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. > Yep - makes sense. > 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. Fine with me. I think the thing we need to be clear on in the messasgeID needs to be unique across all the session on a single endpoint. I don't care if two different endpoint end up with a sending a message with the same message ID. Do other see issue with this? _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jul 1 14:29:40 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23300 for ; Thu, 1 Jul 2004 14:29: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 1Bg6Ja-0003aQ-HS for simple-archive@ietf.org; Thu, 01 Jul 2004 14:29:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bg6IL-000377-00 for simple-archive@ietf.org; Thu, 01 Jul 2004 14:28:26 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bg6HB-0002H4-00; Thu, 01 Jul 2004 14:27:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bg5yg-0005Tl-Mj; Thu, 01 Jul 2004 14:08:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bg5fs-0004qK-3z for simple@megatron.ietf.org; Thu, 01 Jul 2004 13:48: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 NAA20832 for ; Thu, 1 Jul 2004 13:48: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 1Bg5fr-0002ja-41 for simple@ietf.org; Thu, 01 Jul 2004 13:48:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bg5et-0002Jx-00 for simple@ietf.org; Thu, 01 Jul 2004 13:47:40 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1Bg5ds-0001Wb-00 for simple@ietf.org; Thu, 01 Jul 2004 13:46: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 i61HjULp021489; Thu, 1 Jul 2004 12:45:30 -0500 Message-ID: <40E44DBD.7050806@dynamicsoft.com> Date: Thu, 01 Jul 2004 12:45:33 -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: > Sounds good to me - more inline > > On 6/30/04 6:41 AM, "Ben Campbell" 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. >> > > > Yep - makes sense. > > >>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. > > > Fine with me. > > I think the thing we need to be clear on in the messasgeID needs to be > unique across all the session on a single endpoint. I don't care if two > different endpoint end up with a sending a message with the same message ID. > Do other see issue with this? Makes sense to me. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jul 1 14:35: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 OAA24057 for ; Thu, 1 Jul 2004 14:35: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 1Bg6PM-0006AX-HZ for simple-archive@ietf.org; Thu, 01 Jul 2004 14:35:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bg6OT-0005lw-00 for simple-archive@ietf.org; Thu, 01 Jul 2004 14:34:46 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bg6NX-00054O-00; Thu, 01 Jul 2004 14:33:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bg61v-0006fi-PA; Thu, 01 Jul 2004 14:11:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bg5rS-0007IZ-CB for simple@megatron.ietf.org; Thu, 01 Jul 2004 14:00: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 OAA21452 for ; Thu, 1 Jul 2004 14:00: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 1Bg5rR-0007OP-BF for simple@ietf.org; Thu, 01 Jul 2004 14:00:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bg5qW-00070Z-00 for simple@ietf.org; Thu, 01 Jul 2004 13:59:41 -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 1Bg5pr-0006cA-00 for simple@ietf.org; Thu, 01 Jul 2004 13:58:59 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 01 Jul 2004 10:57:48 -0700 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 i61HwPSc002700; Thu, 1 Jul 2004 10:58:26 -0700 (PDT) Received: from cisco.com ([161.44.79.239]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AJV81094; Thu, 1 Jul 2004 13:58:24 -0400 (EDT) Message-ID: <40E450C0.4030302@cisco.com> Date: Thu, 01 Jul 2004 13:58:24 -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: Tiny ant vs big Mammoths, was RE: [Simple] Using MSRP for realtimetext conversation References: <200407011738.i61HcUb0007457@smtp.eweka.nl> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: "'RNIDMAIL.GWIA.\"A.vWijk@viataal.nl\"'" , stf267@etsi.org, simple@ietf.org, "'Guido Gybels'" , toip@snowshore.com, gunnar.hellstrom@omnitor.se X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org 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: 7bit Arnoud van Wijk wrote: > I keep it short: > Audio/t140c is ONLY and ONLY and again ONLY for PSTN trunking gateways. And > NOT and NOT and again...NOT for end-terminals! > > And look at this: > An IP phone is able to be used with IM. It has a keyboard and a nice screen. > In that case, using Interactive text (text/t140) is so easy to implement. > Especially when that IP phone is able to use RTP, because it allows voice > over IP). > > Adding text/t140 here cost nothing. > > And I will have zero understanding if text/t140 is then skipped. It does cost something. It requires that the port to receive the text be established. If there are NAT/FW issues, then it may be necessary to use ICE/STUN to make the port accessible. And if QoS is required, then additional actions are required to enable that. If every phone is required to do that on every audio call, even though the text/t140 stream is only used in .01% of all calls, then I think there will be many objections. The advantage of audio/t140c in this regard is that another stream would not be required. But I am not trying to say that is the right answer. Only that there should be some answer that doesn't have the problems I just mentioned above. Paul > I am not even saying that the IM client must work with text/t140. No..as > long the same device also supports text/t140..I am happy. It is up to Cisco > and other IP phone manufacturers how to make the interface and such. > Seamlessly combined with the IM client or as a separate client. > > And true, not everybody is forced to use Interactive text. If you want audio > only..fine... Just ensure that when you DO need Interactive text (being deaf > or even something silly as spelling the address of a street or a russian > name). Just make it available...and people WILL use it. > > Greetz > > Arnoud > > -----Original Message----- > From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf Of > Paul Kyzivat > Sent: donderdag 1 juli 2004 17:52 > To: Guido Gybels > Cc: RNIDMAIL.GWIA."A.vWijk@viataal.nl"; stf267@etsi.org; toip@snowshore.com; > gunnar.hellstrom@omnitor.se; simple@ietf.org > Subject: Re: Tiny ant vs big Mammoths, was RE: [Simple] Using MSRP for > realtimetext conversation > > > > Guido Gybels wrote: > >>All, >> >><>incompatibilities. So that is why I am negative about just using MSRP for >>interactive text.>> >> >>Arnoud is, as usual, right. The very last thing we should even contemplate > > is introducing competing solutions for deaf people's communication needs. > Remember what has happened in the PSTN and how as a direct result of that > deaf andf hard of hearing people have hugely lost out in society. > >>As far as t140/RTP is concerned: that was not randomly chosen, but after > > careful analysis of the problem in combination with looking at real-world > constraints in terms of bandwidth, cost, practicality, etc. > >>For all clarity: so far there is *NO* scientific data whatsoever that > > shows there is a more bandwidth effective solution than t140/RTP. So, if > people don't want to agree with that, can I respectfully suggest they submit > relevant data from repeatable experiments that we can peer review. > >>There is a lot of misunderstanding about t140/RTP it seems. Arnoud and > > Gunnar are doing a great job in educating the community, so keep it up! > > I don't have any data to add to this, but based on all the discussion > here on the subject I am inclined to accept it. > > So I will return to what I proposed several days ago: > > I think we should assume that text/t140 (or perhaps audio/t140c) will be > used for the transport of real time text. And what we should be > discussing are the mechanisms by which the desire and ability to use it > can be *effectively* and *efficiently* negotiated. > > I also think that it makes sense that endpoints that are prepared to > exchange text via MSRP should also be prepared to exchange it via > text/t140 and visa versa. That is the path that will lead to the most > ubiquitous availability of text communication between those that prefer > one or the other of the modes. I doubt we can standardize this as a > requirement in ietf, but we can define the signaling negotiations that > support it, so that device vendors will know how to build something that > can interoperate effectively. > > What I think would *not* be effective is to expect every IM client to > offer both MSRP and text/t140 every time it seeks to establish an IM > session, just in case the called party prefers to use real time text. > > Similarly, I don't think we should expect a text capable voice client to > offer both audio and text/t140 when audio is preferred and there is no > particular reason to expect use of text. It might make sense for such a > device to offer audio/t140c, but maybe there is a better solution. > > 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 Thu Jul 1 14:46: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 OAA24496 for ; Thu, 1 Jul 2004 14:46: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 1Bg6aA-0002bj-J0 for simple-archive@ietf.org; Thu, 01 Jul 2004 14:46:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bg6Z6-0002Bg-00 for simple-archive@ietf.org; Thu, 01 Jul 2004 14:45:45 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bg6YS-0001mm-00; Thu, 01 Jul 2004 14:45:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bg6Gf-0004ii-R0; Thu, 01 Jul 2004 14:26:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bg5ya-0005Rk-Ez for simple@megatron.ietf.org; Thu, 01 Jul 2004 14: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 OAA22026 for ; Thu, 1 Jul 2004 14:07: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 1Bg5yZ-0002TU-EQ for simple@ietf.org; Thu, 01 Jul 2004 14:07:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bg5xX-00022D-00 for simple@ietf.org; Thu, 01 Jul 2004 14:06:56 -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 1Bg5wA-0001Cc-00 for simple@ietf.org; Thu, 01 Jul 2004 14:05:30 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 01 Jul 2004 11:04:55 -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-1.cisco.com (8.12.10/8.12.6) with ESMTP id i61I4v4N002811; Thu, 1 Jul 2004 11:04:57 -0700 (PDT) Received: from [171.71.208.148] (dhcp-171-71-208-148.cisco.com [171.71.208.148]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id AQF69580; Thu, 1 Jul 2004 11:04:56 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Thu, 01 Jul 2004 11:04:55 -0700 Subject: Re: [Simple] MSRP Boundary header From: Cullen Jennings To: Chris Boulton , Ben Campbell , Vijay Kishen Hampapur Parthasarathy Message-ID: In-Reply-To: <45730E094814E44488F789C1CDED27AE02BDF4E9@gbnewp0758m.eu.ubiquity.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Cc: Ted Hardie , Paul H 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.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit This whole discussion is premised on the idea that framing by finding a length header is somehow much more efficient, faster, etc than the boundary framing. I like to poke at that a little. This efficiency is probably only relevant on relays or things dealing with lots of messages and these run on machines where the CPU has a cache. The experiments I have been playing with show that given the boundary recommendations that we are making that allow you to check for a "----" 4 bytes at a time allow you look for boundary at the same rate that the memory can be copied. Basically the bandwidth from main memory to cache is the bottleneck and the extra check if the 4 byte value is "----" takes no extra time - the CPU is mostly idle waiting for the cache to fill. If you send a message which consisted of a special constructed message that looked very similar to the boundary, this might slow down but this is an artificial corner case I can't get worked up about. I know of no reason for MSRP to prefer the length to the boundary scheme. If someone has one, let's get that on the table and establish if there is a real need to do both. The downside about both is interoperability issues when people only implement one. I point out that I can find boundaries at the same rate I can copy memory and this is way way way beyond the total network bandwidth that can flow in or out of my machine. I'm missing what the argument for doing both is. Cullen On 7/1/04 12:27 AM, "Chris Boulton" wrote: > I agree with Ben - why do something twice. This only increases > complexity and potential to provide conflicting + syntactically > incorrect semantics. > > Chris. > > > -----Original Message----- > From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] > Sent: 30 June 2004 19:35 > To: Vijay Kishen Hampapur Parthasarathy > Cc: Ted Hardie; Paul Kyzivat; seancolson@yahoo.com; simple@ietf.org > Subject: Re: [Simple] MSRP Boundary header > > 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 > > > 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 Thu Jul 1 15:32: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 PAA28147 for ; Thu, 1 Jul 2004 15:32: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 1Bg7IO-0005A4-9c for simple-archive@ietf.org; Thu, 01 Jul 2004 15:32:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bg7HO-0004n2-00 for simple-archive@ietf.org; Thu, 01 Jul 2004 15:31:31 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bg7Gk-0004CH-00; Thu, 01 Jul 2004 15:30:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bg77b-0005jq-Nk; Thu, 01 Jul 2004 15: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 1Bg6oc-0006b8-Gi for simple@megatron.ietf.org; Thu, 01 Jul 2004 15:01: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 PAA25379 for ; Thu, 1 Jul 2004 15:01: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 1Bg6ob-0000tM-52 for simple@ietf.org; Thu, 01 Jul 2004 15:01:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bg6ng-0000V3-00 for simple@ietf.org; Thu, 01 Jul 2004 15:00:49 -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 1Bg6n0-00004W-00 for simple@ietf.org; Thu, 01 Jul 2004 15:00:06 -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 <20040701185936.MXJO1294.oe-im2.bizmailsrvcs.net@mm-ismta4.bizmailsrvcs.net>; Thu, 1 Jul 2004 13:59:36 -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 <20040701185935.FABM29389.mm-ismta4.bizmailsrvcs.net@opwvmdasari1>; Thu, 1 Jul 2004 13:59:35 -0500 From: "Murty Dasari" To: "'Cullen Jennings'" , "'Chris Boulton'" , "'Ben Campbell'" , "'Vijay Kishen Hampapur Parthasarathy'" Subject: RE: [Simple] MSRP Boundary header Date: Thu, 1 Jul 2004 11:59:35 -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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Thread-Index: AcRfm4KqxrRXY7SIRamsjL9WKXOEaAAAGzZw In-Reply-To: Message-Id: <20040701185935.FABM29389.mm-ismta4.bizmailsrvcs.net@opwvmdasari1> Content-Transfer-Encoding: 7bit Cc: "'Ted Hardie'" , "'Paul H 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.2 required=5.0 tests=AWL,MISSING_OUTLOOK_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Hi Cullen, As you pointed out the content-length is useful for relays and processes that deal with lots of messages. One use case is multiparty MSRP server based on SIP based conference (draft-ietf-sipping-conferencing-framework-01) ideally the multiparty MSRP server doesn't have to really parse the data to determine the boundary of the message. I agree that checking for 4 byte value of "----" is much faster than normal string comparison but it wouldn't be as fast as reading the content-length bytes from the stream and passing it over to other MSRP endpoints. Thanks - Murty -----Original Message----- From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf Of Cullen Jennings Sent: Thursday, July 01, 2004 11:05 AM To: Chris Boulton; Ben Campbell; Vijay Kishen Hampapur Parthasarathy Cc: Ted Hardie; Paul H Kyzivat; seancolson@yahoo.com; simple@ietf.org Subject: Re: [Simple] MSRP Boundary header This whole discussion is premised on the idea that framing by finding a length header is somehow much more efficient, faster, etc than the boundary framing. I like to poke at that a little. This efficiency is probably only relevant on relays or things dealing with lots of messages and these run on machines where the CPU has a cache. The experiments I have been playing with show that given the boundary recommendations that we are making that allow you to check for a "----" 4 bytes at a time allow you look for boundary at the same rate that the memory can be copied. Basically the bandwidth from main memory to cache is the bottleneck and the extra check if the 4 byte value is "----" takes no extra time - the CPU is mostly idle waiting for the cache to fill. If you send a message which consisted of a special constructed message that looked very similar to the boundary, this might slow down but this is an artificial corner case I can't get worked up about. I know of no reason for MSRP to prefer the length to the boundary scheme. If someone has one, let's get that on the table and establish if there is a real need to do both. The downside about both is interoperability issues when people only implement one. I point out that I can find boundaries at the same rate I can copy memory and this is way way way beyond the total network bandwidth that can flow in or out of my machine. I'm missing what the argument for doing both is. Cullen On 7/1/04 12:27 AM, "Chris Boulton" wrote: > I agree with Ben - why do something twice. This only increases > complexity and potential to provide conflicting + syntactically > incorrect semantics. > > Chris. > > > -----Original Message----- > From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] > Sent: 30 June 2004 19:35 > To: Vijay Kishen Hampapur Parthasarathy > Cc: Ted Hardie; Paul Kyzivat; seancolson@yahoo.com; simple@ietf.org > Subject: Re: [Simple] MSRP Boundary header > > 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 > > > 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 Thu Jul 1 15:39: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 PAA28484 for ; Thu, 1 Jul 2004 15:39: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 1Bg7PC-00003x-Jh for simple-archive@ietf.org; Thu, 01 Jul 2004 15:39:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bg7OH-0007Vh-00 for simple-archive@ietf.org; Thu, 01 Jul 2004 15:38:38 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bg7No-000792-00; Thu, 01 Jul 2004 15:38:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bg7Au-0000Ew-2u; Thu, 01 Jul 2004 15:24:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bg6sR-00027s-GN for simple@megatron.ietf.org; Thu, 01 Jul 2004 15:05: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 PAA25782 for ; Thu, 1 Jul 2004 15:05: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 1Bg6sQ-0002Uv-6Q for simple@ietf.org; Thu, 01 Jul 2004 15:05:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bg6rX-00026d-00 for simple@ietf.org; Thu, 01 Jul 2004 15:04:48 -0400 Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx with esmtp (Exim 4.12) id 1Bg6qf-0001ZR-00 for simple@ietf.org; Thu, 01 Jul 2004 15:03:53 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.175); Thu, 1 Jul 2004 12:03:33 -0700 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 1 Jul 2004 12:03:40 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 1 Jul 2004 12:03:19 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Thu, 1 Jul 2004 12:03:14 -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: Thu, 1 Jul 2004 12:03:18 -0700 Message-ID: Thread-Topic: [Simple] MSRP Boundary header thread-index: AcRfm4KqxrRXY7SIRamsjL9WKXOEaAAAGzZwAAB0LzA= From: "Vijay Kishen Hampapur Parthasarathy" To: "Murty Dasari" , "Cullen Jennings" , "Chris Boulton" , "Ben Campbell" X-OriginalArrivalTime: 01 Jul 2004 19:03:14.0476 (UTC) FILETIME=[0F9EE6C0:01C45F9E] Content-Transfer-Encoding: quoted-printable Cc: Ted Hardie , Paul H 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=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Exactly my point, for endpoints which need to just demarcate the boundary of the message and then pass it on to the application to render in whatever method appropriate, it saves the time spent in looking at the message content to ensure non repetition of the boundary characters or scanning for "----".=20 Thanks Vijay=20 -----Original Message----- From: Murty Dasari [mailto:murty.dasari@openwave.com]=20 Sent: Thursday, July 01, 2004 12:00 PM To: 'Cullen Jennings'; 'Chris Boulton'; 'Ben Campbell'; Vijay Kishen Hampapur Parthasarathy Cc: 'Ted Hardie'; 'Paul H Kyzivat'; seancolson@yahoo.com; simple@ietf.org Subject: RE: [Simple] MSRP Boundary header Hi Cullen, As you pointed out the content-length is useful for relays and processes that deal with lots of messages. One use case is multiparty MSRP server based on SIP based conference (draft-ietf-sipping-conferencing-framework-01) ideally the multiparty MSRP server doesn't have to really parse the data to determine the boundary of the message. I agree that checking for 4 byte value of "----" is much faster than normal string comparison but it wouldn't be as fast as reading the content-length bytes from the stream and passing it over to other MSRP endpoints. Thanks - Murty -----Original Message----- From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf Of Cullen Jennings Sent: Thursday, July 01, 2004 11:05 AM To: Chris Boulton; Ben Campbell; Vijay Kishen Hampapur Parthasarathy Cc: Ted Hardie; Paul H Kyzivat; seancolson@yahoo.com; simple@ietf.org Subject: Re: [Simple] MSRP Boundary header This whole discussion is premised on the idea that framing by finding a length header is somehow much more efficient, faster, etc than the boundary framing. I like to poke at that a little. This efficiency is probably only relevant on relays or things dealing with lots of messages and these run on machines where the CPU has a cache. The experiments I have been playing with show that given the boundary recommendations that we are making that allow you to check for a "----" 4 bytes at a time allow you look for boundary at the same rate that the memory can be copied. Basically the bandwidth from main memory to cache is the bottleneck and the extra check if the 4 byte value is "----" takes no extra time - the CPU is mostly idle waiting for the cache to fill. If you send a message which consisted of a special constructed message that looked very similar to the boundary, this might slow down but this is an artificial corner case I can't get worked up about. I know of no reason for MSRP to prefer the length to the boundary scheme. If someone has one, let's get that on the table and establish if there is a real need to do both. The downside about both is interoperability issues when people only implement one. I point out that I can find boundaries at the same rate I can copy memory and this is way way way beyond the total network bandwidth that can flow in or out of my machine. I'm missing what the argument for doing both is. Cullen On 7/1/04 12:27 AM, "Chris Boulton" wrote: > I agree with Ben - why do something twice. This only increases=20 > complexity and potential to provide conflicting + syntactically=20 > incorrect semantics. >=20 > Chris. >=20 >=20 > -----Original Message----- > From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] > Sent: 30 June 2004 19:35 > To: Vijay Kishen Hampapur Parthasarathy > Cc: Ted Hardie; Paul Kyzivat; seancolson@yahoo.com; simple@ietf.org > Subject: Re: [Simple] MSRP Boundary header >=20 > Because having two ways to do the same thing adds complexity to both=20 > the >=20 > implementation and the specification. >=20 > Vijay Kishen Hampapur Parthasarathy wrote: >=20 >> Can you comment on the initial question on why not allow both methods >> for message framing. >>=20 >> Vijay >>=20 >> -----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=20 >> Parthasarathy; simple@ietf.org >> Subject: Re: [Simple] MSRP Boundary header >>=20 >>=20 >>=20 >> Paul Kyzivat wrote: >>=20 >>=20 >>>=20 >>> Ted Hardie wrote: >>>=20 >>>=20 >>>> At 7:48 PM -0700 6/29/04, Sean Olson wrote: >>>>=20 >>>>=20 >>>>> Why not allow both methods? >>>>> It seems clear that there are probably two common use cases: >>>>>=20 >>>>> 1) Simple, brief messages as in today's IM conversations >>>>> 2) Larger, more complex, richer messages as forseen in 3G and=20 >>>>> other environments >>>>=20 >>>>=20 >>>>=20 >>>> 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=20 >>> are having a conversation composed of simple brief messages then I=20 >>> believe >>=20 >>=20 >>> the expectation is that you would be using MSRP. >>>=20 >>=20 >>=20 >> Or at one composed of a series of short, interactive messages. (Which > is >> probably what Paul meant to say. >>=20 >>=20 >>> At least that is my expectation. One subject that has yet to be=20 >>> 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. >>>=20 >>=20 >>=20 >> This is true. We have had discussions indicating that we need to say=20 >> something about when to use each, and how to transition between them. >>=20 >> 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. >>=20 >>=20 >>> Paul >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 >=20 > This message has been scanned for viruses by MailControl - www.mailcontrol.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 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jul 1 16: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 QAA29438 for ; Thu, 1 Jul 2004 16: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 1Bg7oM-00020h-Rj for simple-archive@ietf.org; Thu, 01 Jul 2004 16:05:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bg7nS-0001da-00 for simple-archive@ietf.org; Thu, 01 Jul 2004 16:04:39 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bg7mF-0000vE-00; Thu, 01 Jul 2004 16:03:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bg7WX-0000yW-27; Thu, 01 Jul 2004 15:47:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bg7O9-0005hX-SZ for simple@megatron.ietf.org; Thu, 01 Jul 2004 15:38: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 PAA28426 for ; Thu, 1 Jul 2004 15:38: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 1Bg7O8-0007UQ-FL for simple@ietf.org; Thu, 01 Jul 2004 15:38:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bg7NB-00078B-00 for simple@ietf.org; Thu, 01 Jul 2004 15:37:30 -0400 Received: from av5-2-sn3.vrr.skanova.net ([81.228.9.114]) by ietf-mx with esmtp (Exim 4.12) id 1Bg7MI-0006Q8-00 for simple@ietf.org; Thu, 01 Jul 2004 15:36:34 -0400 Received: by av5-2-sn3.vrr.skanova.net (Postfix, from userid 502) id 88D6537E91; Thu, 1 Jul 2004 21:36:02 +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 7934637E50; Thu, 1 Jul 2004 21:36:02 +0200 (CEST) Received: from vit (h53n2fls31o265.telia.com [217.208.189.53]) by smtp1-2-sn3.vrr.skanova.net (Postfix) with SMTP id 036943800C; Thu, 1 Jul 2004 21:36:00 +0200 (CEST) From: "Gunnar Hellstrom" To: "Paul Kyzivat" , "Arnoud van Wijk" Subject: RE: Tiny ant vs big Mammoths, was RE: [Simple] Using MSRP for realtimetext conversation Date: Thu, 1 Jul 2004 21:35:58 +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 Importance: Normal In-Reply-To: <40E450C0.4030302@cisco.com> Content-Transfer-Encoding: 7bit Cc: "'RNIDMAIL.GWIA.\"A.vWijk@viataal.nl\"'" , stf267@etsi.org, toip@snowshore.com, simple@ietf.org, "'Guido Gybels'" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org 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: 7bit Paul, Please do not consider audio/t140c to be a text transport with IP terminals. Its default form does not allow simultaneous voice and text. You need to go into use of multiple SSRC:s in the same session to make it behave as Multimedia should behave. That again introduces a multitude of options. It is purely intended for transport of textphone text alternating with voice between gateways. I cannot see why real time text would be less popular than IM. Deploy it in proper form and it will be a natural part of a telephone call to take a part of it in text. And IM will look unpersonal and chunky in comparison, but still have its market. I also cannot imagine that the number of ports would cause any real frustration. There are so many extra ports set up without big concern, so why not the text ports that really carry part of the kernel communication. Would you like to do video as well on same ports as audio? 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: Paul Kyzivat [mailto:pkyzivat@cisco.com] >Sent: Thursday, July 01, 2004 7:58 PM >To: Arnoud van Wijk >Cc: 'Guido Gybels'; 'RNIDMAIL.GWIA."A.vWijk@viataal.nl"'; >stf267@etsi.org; toip@snowshore.com; gunnar.hellstrom@omnitor.se; >simple@ietf.org >Subject: Re: Tiny ant vs big Mammoths, was RE: [Simple] Using MSRP for >realtimetext conversation > > > > >Arnoud van Wijk wrote: >> I keep it short: >> Audio/t140c is ONLY and ONLY and again ONLY for PSTN trunking gateways. And >> NOT and NOT and again...NOT for end-terminals! >> >> And look at this: >> An IP phone is able to be used with IM. It has a keyboard and a nice screen. >> In that case, using Interactive text (text/t140) is so easy to implement. >> Especially when that IP phone is able to use RTP, because it allows voice >> over IP). >> >> Adding text/t140 here cost nothing. >> >> And I will have zero understanding if text/t140 is then skipped. > >It does cost something. It requires that the port to receive the text be >established. If there are NAT/FW issues, then it may be necessary to use >ICE/STUN to make the port accessible. And if QoS is required, then >additional actions are required to enable that. > >If every phone is required to do that on every audio call, even though >the text/t140 stream is only used in .01% of all calls, then I think >there will be many objections. > >The advantage of audio/t140c in this regard is that another stream would >not be required. But I am not trying to say that is the right answer. >Only that there should be some answer that doesn't have the problems I >just mentioned above. > > Paul > >> I am not even saying that the IM client must work with text/t140. No..as >> long the same device also supports text/t140..I am happy. It is up to Cisco >> and other IP phone manufacturers how to make the interface and such. >> Seamlessly combined with the IM client or as a separate client. >> >> And true, not everybody is forced to use Interactive text. If you want audio >> only..fine... Just ensure that when you DO need Interactive text (being deaf >> or even something silly as spelling the address of a street or a russian >> name). Just make it available...and people WILL use it. >> >> Greetz >> >> Arnoud >> >> -----Original Message----- >> From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf Of >> Paul Kyzivat >> Sent: donderdag 1 juli 2004 17:52 >> To: Guido Gybels >> Cc: RNIDMAIL.GWIA."A.vWijk@viataal.nl"; stf267@etsi.org; toip@snowshore.com; >> gunnar.hellstrom@omnitor.se; simple@ietf.org >> Subject: Re: Tiny ant vs big Mammoths, was RE: [Simple] Using MSRP for >> realtimetext conversation >> >> >> >> Guido Gybels wrote: >> >>>All, >>> >>><>>incompatibilities. So that is why I am negative about just using MSRP for >>>interactive text.>> >>> >>>Arnoud is, as usual, right. The very last thing we should even contemplate >> >> is introducing competing solutions for deaf people's communication needs. >> Remember what has happened in the PSTN and how as a direct result of that >> deaf andf hard of hearing people have hugely lost out in society. >> >>>As far as t140/RTP is concerned: that was not randomly chosen, but after >> >> careful analysis of the problem in combination with looking at real-world >> constraints in terms of bandwidth, cost, practicality, etc. >> >>>For all clarity: so far there is *NO* scientific data whatsoever that >> >> shows there is a more bandwidth effective solution than t140/RTP. So, if >> people don't want to agree with that, can I respectfully suggest they submit >> relevant data from repeatable experiments that we can peer review. >> >>>There is a lot of misunderstanding about t140/RTP it seems. Arnoud and >> >> Gunnar are doing a great job in educating the community, so keep it up! >> >> I don't have any data to add to this, but based on all the discussion >> here on the subject I am inclined to accept it. >> >> So I will return to what I proposed several days ago: >> >> I think we should assume that text/t140 (or perhaps audio/t140c) will be >> used for the transport of real time text. And what we should be >> discussing are the mechanisms by which the desire and ability to use it >> can be *effectively* and *efficiently* negotiated. >> >> I also think that it makes sense that endpoints that are prepared to >> exchange text via MSRP should also be prepared to exchange it via >> text/t140 and visa versa. That is the path that will lead to the most >> ubiquitous availability of text communication between those that prefer >> one or the other of the modes. I doubt we can standardize this as a >> requirement in ietf, but we can define the signaling negotiations that >> support it, so that device vendors will know how to build something that >> can interoperate effectively. >> >> What I think would *not* be effective is to expect every IM client to >> offer both MSRP and text/t140 every time it seeks to establish an IM >> session, just in case the called party prefers to use real time text. >> >> Similarly, I don't think we should expect a text capable voice client to >> offer both audio and text/t140 when audio is preferred and there is no >> particular reason to expect use of text. It might make sense for such a >> device to offer audio/t140c, but maybe there is a better solution. >> >> 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 Thu Jul 1 16:32: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 QAA00349 for ; Thu, 1 Jul 2004 16:32: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 1Bg8Ej-00048f-I7 for simple-archive@ietf.org; Thu, 01 Jul 2004 16:32:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bg8Dx-0003l0-00 for simple-archive@ietf.org; Thu, 01 Jul 2004 16:32:02 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bg8D6-0003Im-00; Thu, 01 Jul 2004 16:31:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bg8AF-0006TL-F8; Thu, 01 Jul 2004 16:28:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bg7jY-0004tk-J5 for simple@megatron.ietf.org; Thu, 01 Jul 2004 16:00: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 QAA29277 for ; Thu, 1 Jul 2004 16:00: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 1Bg7jX-0000AH-BK for simple@ietf.org; Thu, 01 Jul 2004 16:00:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bg7ib-0007Zi-00 for simple@ietf.org; Thu, 01 Jul 2004 15:59:38 -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 1Bg7hX-0006qP-00 for simple@ietf.org; Thu, 01 Jul 2004 15:58:31 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 01 Jul 2004 12:57:22 -0700 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i61Jvx4N028836; Thu, 1 Jul 2004 12:57:59 -0700 (PDT) Received: from [171.71.208.148] (dhcp-171-71-208-148.cisco.com [171.71.208.148]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id AQF81668; Thu, 1 Jul 2004 12:57:58 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Thu, 01 Jul 2004 12:57:56 -0700 Subject: Re: [Simple] MSRP Boundary header From: Cullen Jennings To: Murty Dasari , "'Chris Boulton'" , "'Ben Campbell'" , "'Vijay Kishen Hampapur Parthasarathy'" Message-ID: In-Reply-To: <20040701185935.FABM29389.mm-ismta4.bizmailsrvcs.net@opwvmdasari1> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Cc: "'Ted Hardie'" , Paul H 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.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit No - this is exactly the opposite of what I what I said. On 7/1/04 11:59 AM, "Murty Dasari" wrote: > Hi Cullen, > > As you pointed out the content-length is useful for relays and processes > that deal with lots of messages. No I said it was NOT useful for this because it was NOT faster > > One use case is multiparty MSRP server based on SIP based conference > (draft-ietf-sipping-conferencing-framework-01) ideally the multiparty MSRP > server doesn't have to really parse the data to determine the boundary of > the message. I agree that checking for 4 byte value of "----" is much faster > than normal string comparison but it wouldn't be as fast as reading the > content-length bytes from the stream and passing it over to other MSRP > endpoints. No I did not say it was faster than string compare. I said it was EXACTLY as fast as coping the memory using the content length approach. You need to copy the memory to send it or use even if you are using the length approach. I also said that even if this was slower, this was not a relevant limiting factor of any system I have considered because it was so much higher than the network bandwidth and the other things that devices need to do. I would be happy to see any data suggesting otherwise (for a message that was not already in the cache) > > Thanks > - Murty > > > -----Original Message----- > From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf Of > Cullen Jennings > Sent: Thursday, July 01, 2004 11:05 AM > To: Chris Boulton; Ben Campbell; Vijay Kishen Hampapur Parthasarathy > Cc: Ted Hardie; Paul H Kyzivat; seancolson@yahoo.com; simple@ietf.org > Subject: Re: [Simple] MSRP Boundary header > > > This whole discussion is premised on the idea that framing by finding a > length header is somehow much more efficient, faster, etc than the boundary > framing. I like to poke at that a little. This efficiency is probably only > relevant on relays or things dealing with lots of messages and these run on > machines where the CPU has a cache. > > The experiments I have been playing with show that given the boundary > recommendations that we are making that allow you to check for a "----" > 4 bytes at a time allow you look for boundary at the same rate that the > memory can be copied. Basically the bandwidth from main memory to cache is > the bottleneck and the extra check if the 4 byte value is "----" takes no > extra time - the CPU is mostly idle waiting for the cache to fill. If you > send a message which consisted of a special constructed message that looked > very similar to the boundary, this might slow down but this is an artificial > corner case I can't get worked up about. > > I know of no reason for MSRP to prefer the length to the boundary scheme. If > someone has one, let's get that on the table and establish if there is a > real need to do both. The downside about both is interoperability issues > when people only implement one. > > I point out that I can find boundaries at the same rate I can copy memory > and this is way way way beyond the total network bandwidth that can flow in > or out of my machine. I'm missing what the argument for doing both is. > > Cullen > > > > On 7/1/04 12:27 AM, "Chris Boulton" wrote: > >> I agree with Ben - why do something twice. This only increases >> complexity and potential to provide conflicting + syntactically >> incorrect semantics. >> >> Chris. >> >> >> -----Original Message----- >> From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] >> Sent: 30 June 2004 19:35 >> To: Vijay Kishen Hampapur Parthasarathy >> Cc: Ted Hardie; Paul Kyzivat; seancolson@yahoo.com; simple@ietf.org >> Subject: Re: [Simple] MSRP Boundary header >> >> 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 >> >> >> 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 Thu Jul 1 16:47: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 QAA01045 for ; Thu, 1 Jul 2004 16:47: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 1Bg8TI-0001yc-Qe for simple-archive@ietf.org; Thu, 01 Jul 2004 16:47:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bg8SL-0001aG-00 for simple-archive@ietf.org; Thu, 01 Jul 2004 16:46:54 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bg8Rk-0001C5-00; Thu, 01 Jul 2004 16:46:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bg8CT-00019C-7N; Thu, 01 Jul 2004 16:30:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bg87h-0005PO-H4 for simple@megatron.ietf.org; Thu, 01 Jul 2004 16:25: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 QAA29959 for ; Thu, 1 Jul 2004 16:25: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 1Bg87g-0001T5-Ac for simple@ietf.org; Thu, 01 Jul 2004 16:25:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bg86k-00016y-00 for simple@ietf.org; Thu, 01 Jul 2004 16:24:35 -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 1Bg85o-0000P5-00 for simple@ietf.org; Thu, 01 Jul 2004 16:23:37 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 01 Jul 2004 13:22:27 -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 i61KN44N000725; Thu, 1 Jul 2004 13:23:04 -0700 (PDT) Received: from cisco.com ([161.44.79.239]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AJV96270; Thu, 1 Jul 2004 16:23:03 -0400 (EDT) Message-ID: <40E472A7.5080804@cisco.com> Date: Thu, 01 Jul 2004 16:23:03 -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] MSRP: Surpression of duplicates References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: hisham.khartabil@nokia.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 Cullen Jennings wrote: > > I think the thing we need to be clear on in the messasgeID needs to be > unique across all the session on a single endpoint. I don't care if two > different endpoint end up with a sending a message with the same message ID. > Do other see issue with this? I'm not sure "single endpoint" quite captures the requirement, but I agree we don't need global uniqueness. What we need is uniqueness across a media streamand all its possible successor streams- assuming we can define what constitutes a successor stream. I think that means a stream initially established via an offer/answer and associated with a particular m-line position in the offer/answer, plus additional streams established by changes to that m-line and its attributes. That is a pretty clumsy definition, but I can't come up with a simpler one offhand. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jul 1 17: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 RAA01907 for ; Thu, 1 Jul 2004 17: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 1Bg8sK-0003wk-Sy for simple-archive@ietf.org; Thu, 01 Jul 2004 17:13:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bg8ra-0003Yy-00 for simple-archive@ietf.org; Thu, 01 Jul 2004 17:12:59 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bg8qp-00037L-00; Thu, 01 Jul 2004 17:12:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bg8h9-0005o1-Bs; Thu, 01 Jul 2004 17:02:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bg8an-00035I-DM for simple@megatron.ietf.org; Thu, 01 Jul 2004 16:55:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01410 for ; Thu, 1 Jul 2004 16:55: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 1Bg8am-00050A-7G for simple@ietf.org; Thu, 01 Jul 2004 16:55:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bg8Zs-0004e3-00 for simple@ietf.org; Thu, 01 Jul 2004 16:54:41 -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 1Bg8ZW-0004Hb-00 for simple@ietf.org; Thu, 01 Jul 2004 16:54:18 -0400 Received: from india-core-1.cisco.com (64.104.129.221) by ind-iport-1.cisco.com with ESMTP; 02 Jul 2004 02:24:28 +0530 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by india-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i61KrI8I018015; Thu, 1 Jul 2004 13:53:20 -0700 (PDT) Received: from cisco.com ([161.44.79.239]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AJV98732; Thu, 1 Jul 2004 16:53:25 -0400 (EDT) Message-ID: <40E479C5.9060100@cisco.com> Date: Thu, 01 Jul 2004 16:53:25 -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: Tiny ant vs big Mammoths, was RE: [Simple] Using MSRP for realtimetext conversation References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: "'RNIDMAIL.GWIA.\"A.vWijk@viataal.nl\"'" , stf267@etsi.org, simple@ietf.org, "'Guido Gybels'" , toip@snowshore.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.5 required=5.0 tests=AWL,NO_COST autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Gunnar Hellstrom wrote: > Paul, > Please do not consider audio/t140c to be a text transport with IP terminals. > > Its default form does not allow simultaneous voice and text. You need to go into use of > multiple SSRC:s in the same session to make it behave as Multimedia should behave. That > again introduces a multitude of options. It is purely intended for transport of textphone > text alternating with voice between gateways. Fine. I don't care. Forget I ever mentioned t140c. > I cannot see why real time text would be less popular than IM. Maybe you can't. I can. It will be for the market to decide. Today lots of people have IM and don't have RTT. You have to get over a hurdle for it to be possible for them to interact with RTT in any way. That will be easier if the hurdle is lower. > Deploy it in proper form > and it will be a natural part of a telephone call to take a part of it in text. I believe for most people who use both voice and IM, the two are mutually exclusive - they aren't typically both used on the same "call". There are lots of reasons for that: - the protocols used are different, and managed independently within the devices - the ergonomics of the device often make it difficult to use both simultaneously. - many IM users don't have (or don't use) voice on the same device that they use IM. IM on the PC, voice on the phone. At the least, the ergonomics will disfavor using both on lots of devices regardless of how well the the software is integrated. > And IM > will look unpersonal and chunky in comparison, but still have its market. That's an opinion. I think they are almost different media, in the same way that IM and email are different media. For many purposes, like the one right here, I prefer email. I don't consider it clunkier - just different. It gives me a little time to consider what I what to say before committing to it. Similarly IM still gives me a little time to consider, just not at much. With IM I often type half a line and the reconsider and delete it. With RTT you see all that - which often I would prefer you did not. > I also cannot imagine that the number of ports would cause any real frustration. There are > so many extra ports set up without big concern, so why not the text ports that really > carry part of the kernel communication. > Would you like to do video as well on same ports as audio? Note that I threw that out as a possibility, but I admitted it was perhaps not a good one. And, I already explained all the other costs associated with using another port. The alternative is to find a way to establish the session without the t140 stream that *might*, but probably *won't* be used. And yet, at the same time communicate the willingness to use t140 if desired. *If* only a small fraction of all endpoints actually want to use t140, then they can offer it on every call where they initiate the offer. And when they receive an offer with just voice, they can accept it and then counter offer adding T.140. This is probably a good strategy for video today as well, where there are similar issues. That means the vast majority of calls experience no cost for the support, because it isn't used. The calls where it is attempted and refused experience a small incremental cost, but presumably are willing to pay it for benefit. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jul 1 18:08:40 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04398 for ; Thu, 1 Jul 2004 18:08: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 1Bg9jV-00010U-6k for simple-archive@ietf.org; Thu, 01 Jul 2004 18:08:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bg9iP-0000eP-00 for simple-archive@ietf.org; Thu, 01 Jul 2004 18:07:34 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bg9hL-0007kJ-00; Thu, 01 Jul 2004 18: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 1Bg9Nu-0005e9-8T; Thu, 01 Jul 2004 17:46:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bg9HU-0003Fl-PL for simple@megatron.ietf.org; Thu, 01 Jul 2004 17:39: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 RAA02915 for ; Thu, 1 Jul 2004 17:39: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 1Bg9HT-0005rG-As for simple@ietf.org; Thu, 01 Jul 2004 17:39:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bg9Gc-0005UL-00 for simple@ietf.org; Thu, 01 Jul 2004 17:38:51 -0400 Received: from smtp.eweka.nl ([81.171.101.3]) by ietf-mx with esmtp (Exim 4.12) id 1Bg9Ff-00056L-00 for simple@ietf.org; Thu, 01 Jul 2004 17:37:51 -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 i61Lbfb0008839; Thu, 1 Jul 2004 23:37:51 +0200 (CEST) (envelope-from a.vwijk@viataal.nl) Message-Id: <200407012137.i61Lbfb0008839@smtp.eweka.nl> From: "Arnoud van Wijk" To: "'Henry Sinnreich'" , "'Dean Willis'" Subject: RE: Tiny ant vs big Mammoths, was RE: [Simple] Using MSRP for real time text conversation Date: Thu, 1 Jul 2004 23:37:31 +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 In-Reply-To: <0I060032PV8T47@dgismtp02.mcilink.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Thread-Index: AcRfhSgGp69wz7mdQc2STF2vk1RzZAACN3aQAARB+kAABIe6EA== Content-Transfer-Encoding: 7bit Cc: stf267@etsi.org, adam@dynamicsoft.com, simple@ietf.org, hisham.khartabil@nokia.com, toip@snowshore.com, gunnar.hellstrom@omnitor.se, 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.8 required=5.0 tests=AWL,MAILTO_TO_SPAM_ADDR, MISSING_OUTLOOK_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Henry, Do you know what the danger is? I already see it emerging. Here at the IETF many are wonderful and quite supporters for Interactive text. But their bosses..higher up pointed haired bosses are just dumb and only see what they know. Interactive text is scary for them. They do not believe that many will use it under condition that it is available in as many phones as possible! All mobile phones offer SMS (Europe, Asia). But most do not use it. But a significant group does. Even though text input is very clumsy using numerical key combinations. Too many say right now EXACT the same thing as with Interactive text. SMS/Interactive text? Hardly anybody is interested in it. Why send text while you can just as quickly place a voice call? There is no need for SMS/Interactive text. People won't use it Don't like it. (sounds familiar?) My message to the vendors is simple: implement interactive text. Text/t140. If you have a phone with IM capabilities, add interactive text! Try interactive text in as many phones you produce! People will be grateful for it and buy your products. I am not saying that every phone must have it. But in every price range, have enough models with text/t140. It is cheap to implement, it adds value to your phone for the buyers. And those who don't care, will likely later appreciate interactive text as soon they discover it. And keep buying your IP phones for their kids, family members..new phone etc etc. We, the IETF cannot mandate this. But we are a bunch of smart people. So, we do know what we do. Greetz Arnoud -----Original Message----- From: Henry Sinnreich [mailto:Henry.Sinnreich@mci.com] Sent: donderdag 1 juli 2004 21:53 To: 'Arnoud van Wijk'; 'Dean Willis' Cc: bcampbell@dynamicsoft.com; hisham.khartabil@nokia.com; gunnar.hellstrom@omnitor.se; adam@dynamicsoft.com; stf267@etsi.org; simple@ietf.org; toip@snowshore.com Subject: RE: Tiny ant vs big Mammoths, was RE: [Simple] Using MSRP for real time text conversation Arnoud, I have to agree with Dean's arguments and add that in dealing with real vendors and program managers, even what is 100% consensus in the IETF is "in the next generation" (in a next life probably) under consideration for them. So let's do a reality check and come back with these issues after we had a couple of months to check with vendors and program managers, so we don't spin our wheels here in the list. Henry Henry Sinnreich MCI 400 International Parkway Richardson, Texas 75081 USA -----Original Message----- From: owner-toip@snowshore.com [mailto:owner-toip@snowshore.com] On Behalf Of Arnoud van Wijk Sent: Thursday, July 01, 2004 12:24 PM To: 'Dean Willis' Cc: bcampbell@dynamicsoft.com; hisham.khartabil@nokia.com; gunnar.hellstrom@omnitor.se; adam@dynamicsoft.com; stf267@etsi.org; simple@ietf.org; toip@snowshore.com Subject: RE: Tiny ant vs big Mammoths, was RE: [Simple] Using MSRP for real time text conversation Dean, I said this to indicate that the method Interactive text is using for redundancy will only slightly increase the bandwidth. There are generally no more packets per second being sent with redundancy, the redundant generation is sent with the normal next batch of typed characters in the following packet! Think of a bus with 10 characters in it or a bus with 20 characters in it. It is then the same bus. It is not 1 packet per character! Unless you t y p e s o s l o w that there is a second or more between every character or so. :-) And if there is a congestion like you described with so many Interactive text streams. Normal congestion mechnism that are used for other RTP traffic will also apply for Interactive text. Also as stated in the 07 version of the RFC 2793 bis draft, if there is a good mechanism that prevents dropped packets..then that can be used instead of the 2 generations redundancy. So, I do not see the problem. Greetz Arnoud -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com] Sent: donderdag 1 juli 2004 18:04 To: A vWijk Cc: bcampbell@dynamicsoft.com; hisham.khartabil@nokia.com; gunnar.hellstrom@omnitor.se; adam@dynamicsoft.com; stf267@etsi.org; simple@ietf.org; toip@snowshore.com Subject: Re: Tiny ant vs big Mammoths, was RE: [Simple] Using MSRP for real time text conversation A vWijk wrote: > My comment marked with *** > *** 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 generations 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. > No, let's put it in the right perspective. Assume real-time text drives 2kb/s of bandwidth, or approximately 3 packets per second. Assume 20,000,000 users are running real-time-text sessions concurrently. This is approximately peak load for a really big mobile operator, and well below peak load for the Internet as a whole. Assume that real-time text continues to operate without the sort of congestion control that forces it to "back off" in the event of network congestion. We now have 40 billion (40E9) bits per second of non-bandwidth-controlled traffic out there, or approximately 60E6 packets per second. Will any of this ever traverse a link that is also trying to carry nice friendly TCP traffic? Will that link ever get congested? Will the real-time text "starve out" the TCP traffic when it does? The answers here are most likely "yes" . . . How can you assure us that this will never happen? Are operators going to build dedicated networks for real-time text? Are we going to use DS-markings to make real-time text low priority and discardable? Or, otherwise said, what gives real-time-text the "right" to cheat the rules and unfairly consume scarce network resources? Does any application have that right? -- Dean - 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 Thu Jul 1 21:28: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 VAA13190 for ; Thu, 1 Jul 2004 21:28: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 1BgCrE-000456-1o for simple-archive@ietf.org; Thu, 01 Jul 2004 21:28:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgCqJ-0003jT-00 for simple-archive@ietf.org; Thu, 01 Jul 2004 21:27:57 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BgCpv-0003NZ-00; Thu, 01 Jul 2004 21:27:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgCjE-0006cq-AK; Thu, 01 Jul 2004 21:20:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgCdk-0002Jt-5x for simple@megatron.ietf.org; Thu, 01 Jul 2004 21:14: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 VAA12683 for ; Thu, 1 Jul 2004 21: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 1BgCdi-00070H-GY for simple@ietf.org; Thu, 01 Jul 2004 21:14:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgCd3-0006ef-00 for simple@ietf.org; Thu, 01 Jul 2004 21:14:14 -0400 Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx with esmtp (Exim 4.12) id 1BgCcK-0006Ck-00 for simple@ietf.org; Thu, 01 Jul 2004 21:13:28 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.175); Thu, 1 Jul 2004 18:12:59 -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, 1 Jul 2004 18:12:59 -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: Thu, 1 Jul 2004 18:13:06 -0700 Message-ID: Thread-Topic: [Simple] MSRP Boundary header Thread-Index: AcRfm4K58Th5rBe3ScyrYnM1O9ttSgALvzCg From: "Orit Levin" To: "Cullen Jennings" , "Chris Boulton" , "Ben Campbell" , "Vijay Kishen Hampapur Parthasarathy" X-OriginalArrivalTime: 02 Jul 2004 01:12:59.0075 (UTC) FILETIME=[B6AC1130:01C45FD1] Content-Transfer-Encoding: quoted-printable Cc: Ted Hardie , Paul H 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.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable The argument below about copying in parallel with checking is true for single-purpose devices whose only or main job is to processes MSRP messages. In general-purpose OS, copying occurs in lower layers (e.g. network drivers) and by the time the data reaches the application, it is already out of the cache. After some investigation, below are the facts: =20 The described behavior has been noted by OS vendors and some of them already use special version of copy instruction that does not pollute the cache when copying network data (e.g. using movnti on X86). Furthermore, there are protocols under development (CISCO along with Microsoft are by the way among the founders of RDMA consortium - www.rdmaconsortium.org) that facilitate DMA directly from the wire into the application data buffers (so-named Remote DMA). This obviously completely bypasses the cache and makes the bottleneck argument obsolete. Finally, if one is implementing a gateway between MSRP and other protocols, it may need to copy the whole data only to insert additional escape sequences on the output path. To summarize this, I would say that it will be strange if SIMPLE comes up with a brand new protocol which is "optimized" for - Dedicated HW devices - Encourages lazy implementation where the data is not being chunked into reasonably sized blocks so that the relays in the middle have hard time to decide whether they will be able to process a single chunk or not - and still being called the protocol for Instant Messaging=20 Orit. > -----Original Message----- > From: simple-bounces@ietf.org=20 > [mailto:simple-bounces@ietf.org] On Behalf Of Cullen Jennings > Sent: Thursday, July 01, 2004 11:05 AM > To: Chris Boulton; Ben Campbell; Vijay Kishen Hampapur Parthasarathy > Cc: Ted Hardie; Paul H Kyzivat; seancolson@yahoo.com; simple@ietf.org > Subject: Re: [Simple] MSRP Boundary header >=20 >=20 > This whole discussion is premised on the idea that framing by=20 > finding a length header is somehow much more efficient,=20 > faster, etc than the boundary framing. I like to poke at that=20 > a little. This efficiency is probably only relevant on relays=20 > or things dealing with lots of messages and these run on=20 > machines where the CPU has a cache. >=20 > The experiments I have been playing with show that given the=20 > boundary recommendations that we are making that allow you to=20 > check for a "----" > 4 bytes at a time allow you look for boundary at the same=20 > rate that the memory can be copied. Basically the bandwidth=20 > from main memory to cache is the bottleneck and the extra=20 > check if the 4 byte value is "----" takes no extra time - the=20 > CPU is mostly idle waiting for the cache to fill. If you send=20 > a message which consisted of a special constructed message=20 > that looked very similar to the boundary, this might slow=20 > down but this is an artificial corner case I can't get worked=20 > up about. >=20 > I know of no reason for MSRP to prefer the length to the=20 > boundary scheme. If someone has one, let's get that on the=20 > table and establish if there is a real need to do both. The=20 > downside about both is interoperability issues when people=20 > only implement one. >=20 > I point out that I can find boundaries at the same rate I can=20 > copy memory and this is way way way beyond the total network=20 > bandwidth that can flow in or out of my machine. I'm missing=20 > what the argument for doing both is. >=20 > Cullen >=20 >=20 >=20 > On 7/1/04 12:27 AM, "Chris Boulton" wrote: >=20 > > I agree with Ben - why do something twice. This only increases=20 > > complexity and potential to provide conflicting + syntactically=20 > > incorrect semantics. > >=20 > > Chris. > >=20 > >=20 > > -----Original Message----- > > From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] > > Sent: 30 June 2004 19:35 > > To: Vijay Kishen Hampapur Parthasarathy > > Cc: Ted Hardie; Paul Kyzivat; seancolson@yahoo.com; simple@ietf.org > > Subject: Re: [Simple] MSRP Boundary header > >=20 > > Because having two ways to do the same thing adds=20 > complexity to both=20 > > the > >=20 > > implementation and the specification. > >=20 > > Vijay Kishen Hampapur Parthasarathy wrote: > >=20 > >> Can you comment on the initial question on why not allow=20 > both methods=20 > >> for message framing. > >>=20 > >> Vijay > >>=20 > >> -----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=20 > >> Parthasarathy; simple@ietf.org > >> Subject: Re: [Simple] MSRP Boundary header > >>=20 > >>=20 > >>=20 > >> Paul Kyzivat wrote: > >>=20 > >>=20 > >>>=20 > >>> Ted Hardie wrote: > >>>=20 > >>>=20 > >>>> At 7:48 PM -0700 6/29/04, Sean Olson wrote: > >>>>=20 > >>>>=20 > >>>>> Why not allow both methods? > >>>>> It seems clear that there are probably two common use cases: > >>>>>=20 > >>>>> 1) Simple, brief messages as in today's IM conversations > >>>>> 2) Larger, more complex, richer messages as forseen in 3G and=20 > >>>>> other environments > >>>>=20 > >>>>=20 > >>>>=20 > >>>> Sorry to ask such a potentially silly question, but aren't the=20 > >>>> messages in case one to be handled by SIP/SIMPLE, rather=20 > than MSRP? > >>>=20 > >>>=20 > >>> No. Maybe if you have a one-shot message it should be. But if you=20 > >>> are having a conversation composed of simple brief=20 > messages then I=20 > >>> believe > >>=20 > >>=20 > >>> the expectation is that you would be using MSRP. > >>>=20 > >>=20 > >>=20 > >> Or at one composed of a series of short, interactive=20 > messages. (Which > > is > >> probably what Paul meant to say. > >>=20 > >>=20 > >>> At least that is my expectation. One subject that has yet to be=20 > >>> dealt with is the relationship (and possibly migration)=20 > between page=20 > >>> mode and session mode. The fact that you ask the question=20 > you did is=20 > >>> an indication that this isn't a solved problem. > >>>=20 > >>=20 > >>=20 > >> This is true. We have had discussions indicating that we=20 > need to say=20 > >> something about when to use each, and how to transition=20 > between them. > >>=20 > >> I personally think that sort of thing belong in the SIMPLE > > architecture > >> draft effort, which we have not been putting much effort=20 > into of late. > >>=20 > >>=20 > >>> Paul > >=20 > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > >=20 > >=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 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jul 2 01:51: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 BAA23749 for ; Fri, 2 Jul 2004 01:51: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 1BgGxp-0002NS-0N for simple-archive@ietf.org; Fri, 02 Jul 2004 01:51:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgGwq-00022y-00 for simple-archive@ietf.org; Fri, 02 Jul 2004 01:50:58 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BgGwL-0001iR-00; Fri, 02 Jul 2004 01:50:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgGuQ-0002lX-O4; Fri, 02 Jul 2004 01:48:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgGt0-00023D-5p for simple@megatron.ietf.org; Fri, 02 Jul 2004 01:46: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 BAA23662 for ; Fri, 2 Jul 2004 01:46: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 1BgGsy-0000jv-2C for simple@ietf.org; Fri, 02 Jul 2004 01:46:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgGs1-0000Pi-00 for simple@ietf.org; Fri, 02 Jul 2004 01:45:58 -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 1BgGrI-0007Yt-00 for simple@ietf.org; Fri, 02 Jul 2004 01:45:13 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 01 Jul 2004 22:44:41 -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-5.cisco.com (8.12.10/8.12.6) with ESMTP id i625iXgI023566; Thu, 1 Jul 2004 22:44:37 -0700 (PDT) Received: from [10.0.1.4] (sjc-vpn3-1392.cisco.com [10.21.69.112]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id AQG19991; Thu, 1 Jul 2004 22:44:32 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Thu, 01 Jul 2004 22:44:26 -0700 Subject: Re: [Simple] MSRP Boundary header From: Cullen Jennings To: Orit Levin , Ben Campbell , Vijay Kishen Hampapur Parthasarathy 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 H 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.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit This is a very strange argument, I think you exactly support my point but then you seem to draw the opposite conclusion. I will respond to you points inline but this whole argument does not make sense to me. I can scan for boundary at the speed of the memory bandwidth on any any machine anyone is likely to run a relay on. This is many giga bits per second worth of data. I can not imagine that this will represent a significant percentage of time for any relay and removing it will not make a relevant difference. More inline On 7/1/04 6:13 PM, "Orit Levin" wrote: > The argument below about copying in parallel with checking is true for > single-purpose devices whose only or main job is to processes MSRP > messages. In general-purpose OS, copying occurs in lower layers (e.g. > network drivers) and by the time the data reaches the application, it is > already out of the cache. > > After some investigation, below are the facts: > > The described behavior has been noted by OS vendors and some of them > already use special version of copy instruction that does not pollute > the cache when copying network data (e.g. using movnti on X86). Yep - any my point was you could transfer it from block A in memory to block B in exactly the same time that you can transfer it and check it. If I used the non cache polluting instructions to transfer the data into a register, check it, then transfer out, I can still do this at the full bandwidth of the memory bus. > > Furthermore, there are protocols under development (CISCO along with > Microsoft are by the way among the founders of RDMA consortium - > www.rdmaconsortium.org) that facilitate DMA directly from the wire into > the application data buffers (so-named Remote DMA). This obviously > completely bypasses the cache and makes the bottleneck argument > obsolete. > Yes very familiar with this. Let's see what would happen, a fragment of UDP packet arrives on the Ethernet card and you are going to know where to DMA the right portion of this fragment into a buffer in user space that represents the correct portion of a TCP data stream. I don't think so. If this protocol ran over UDP, you might be able to use this to improve performance beyond the current vector IO stuff that NT supports. However, it does not run over UDP and the DMA trick is not going to help for this. Even if it did, your performance would be total limited by the bandwidth of the NIC cards - lets say you somehow had really a lot of of really fast NIC cards, you are going to hit the limit of the PCI bus to DMA it to memory. This time to scan it is going to be a drop in the bucket because the CPU memory bandwidth is so much better than the memory to NIC bandwidth which is probably much greater than the actual bandwidth the NIC cards can put onto the network. > Finally, if one is implementing a gateway between MSRP and other > protocols, it may need to copy the whole data only to insert additional > escape sequences on the output path. Uh, perhaps, if you implement TCP and MSRP in VLSI on the NIC card but otherwise I think the machine is going to copy it to memory. > > To summarize this, I would say that it will be strange if SIMPLE comes > up with a brand new protocol which is "optimized" for > - Dedicated HW devices I'm lost how it is "optimized" for this > - Encourages lazy implementation where the data is not being chunked > into reasonably sized blocks so that the relays in the middle have hard > time to decide whether they will be able to process a single chunk or > not Again - don't see how you get to this conclusion. > - and still being called the protocol for Instant Messaging Let's say the type of IM you are interested in results in an average MSRP message that is 256 bytes long. If we take a 3Ghz P4 with 800 MHz frontside and good DDR memory, how many million of these messages do you think I can boundary scan per second? How many million messages per second do you think you can relay on a single host? Do you think this result in dropped performance? I don't think it will drop performance at all because you can't relay from one stream to another stream with zero copies but even if you did implement it as another pass over the data just to do this, I doubt it can make any real difference. > > Orit. > >> -----Original Message----- >> From: simple-bounces@ietf.org >> [mailto:simple-bounces@ietf.org] On Behalf Of Cullen Jennings >> Sent: Thursday, July 01, 2004 11:05 AM >> To: Chris Boulton; Ben Campbell; Vijay Kishen Hampapur Parthasarathy >> Cc: Ted Hardie; Paul H Kyzivat; seancolson@yahoo.com; simple@ietf.org >> Subject: Re: [Simple] MSRP Boundary header >> >> >> This whole discussion is premised on the idea that framing by >> finding a length header is somehow much more efficient, >> faster, etc than the boundary framing. I like to poke at that >> a little. This efficiency is probably only relevant on relays >> or things dealing with lots of messages and these run on >> machines where the CPU has a cache. >> >> The experiments I have been playing with show that given the >> boundary recommendations that we are making that allow you to >> check for a "----" >> 4 bytes at a time allow you look for boundary at the same >> rate that the memory can be copied. Basically the bandwidth >> from main memory to cache is the bottleneck and the extra >> check if the 4 byte value is "----" takes no extra time - the >> CPU is mostly idle waiting for the cache to fill. If you send >> a message which consisted of a special constructed message >> that looked very similar to the boundary, this might slow >> down but this is an artificial corner case I can't get worked >> up about. >> >> I know of no reason for MSRP to prefer the length to the >> boundary scheme. If someone has one, let's get that on the >> table and establish if there is a real need to do both. The >> downside about both is interoperability issues when people >> only implement one. >> >> I point out that I can find boundaries at the same rate I can >> copy memory and this is way way way beyond the total network >> bandwidth that can flow in or out of my machine. I'm missing >> what the argument for doing both is. >> >> Cullen >> >> >> >> On 7/1/04 12:27 AM, "Chris Boulton" wrote: >> >>> I agree with Ben - why do something twice. This only increases >>> complexity and potential to provide conflicting + syntactically >>> incorrect semantics. >>> >>> Chris. >>> >>> >>> -----Original Message----- >>> From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] >>> Sent: 30 June 2004 19:35 >>> To: Vijay Kishen Hampapur Parthasarathy >>> Cc: Ted Hardie; Paul Kyzivat; seancolson@yahoo.com; simple@ietf.org >>> Subject: Re: [Simple] MSRP Boundary header >>> >>> 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 >>> >>> >>> 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 From simple-bounces@ietf.org Fri Jul 2 03:33: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 DAA12398 for ; Fri, 2 Jul 2004 03: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 1BgIXg-0007Ku-Ca for simple-archive@ietf.org; Fri, 02 Jul 2004 03:33:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgIWe-0006yI-00 for simple-archive@ietf.org; Fri, 02 Jul 2004 03:32:01 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BgIVh-0006IQ-00; Fri, 02 Jul 2004 03:31:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgITX-0003V1-9c; Fri, 02 Jul 2004 03:28:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgIIB-00082X-6R for simple@megatron.ietf.org; Fri, 02 Jul 2004 03:17: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 DAA11934 for ; Fri, 2 Jul 2004 03:17: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 1BgII9-0001tF-2D for simple@ietf.org; Fri, 02 Jul 2004 03:17:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgIH8-0001Y5-00 for simple@ietf.org; Fri, 02 Jul 2004 03:15:59 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BgIGH-0001DM-00 for simple@ietf.org; Fri, 02 Jul 2004 03:15:05 -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 i627F4N15299; Fri, 2 Jul 2004 10:15:04 +0300 (EET DST) X-Scanned: Fri, 2 Jul 2004 10:14:47 +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 i627ElQX009079; Fri, 2 Jul 2004 10:14:47 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00gM7ji1; Fri, 02 Jul 2004 10:14:45 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 i627EhH20737; Fri, 2 Jul 2004 10:14:43 +0300 (EET DST) Received: from nokia.com ([172.21.42.108]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 2 Jul 2004 10:14:42 +0300 Message-ID: <40E50B62.7070608@nokia.com> Date: Fri, 02 Jul 2004 10:14:42 +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: "Henrik Albertsson (KI/EAB)" References: <342C4681F0D4A04CA50A97D74DA8FB9A0C0AC798@esealnt875.al.sw.ericsson.se> In-Reply-To: <342C4681F0D4A04CA50A97D74DA8FB9A0C0AC798@esealnt875.al.sw.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-OriginalArrivalTime: 02 Jul 2004 07:14:42.0946 (UTC) FILETIME=[3F2FF620:01C46004] Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mgw-int1.ntc.nokia.com id i627EhH20737 Content-Transfer-Encoding: quoted-printable Cc: simple@ietf.org Subject: [Simple] Re: XCap Directory: Large respons ? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org 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 Henrik: I think you got a good point. I think we need to add a new requirement=20 to the draft that reads something like: - The XCAP client MUST be able to limit the amount of information=20 returned by the XCAP server, so that the XCAP directory document does=20 not flood the client. As for a possible solution... I need to think about it... Most likely we=20 will need to define some sort of convention, kind of adding a parameter=20 to the URI to limit the number of entries in the response. Something like= : GET http://xcap.example.com/services/directory/users/ bill/directory.xml?entries=3D50 HTTP/1.1 I am open to hear suggestions. Regards, Miguel Henrik Albertsson (KI/EAB) wrote: > Hi, >=20 > The current version of the XCAP Directory does not contain any limit of= the size of the response. An XCAP Directory can potentially be very larg= e if it collects all list for a user, especially in a mobile environment = this would be problem. Any ideas how to limit the response?=20 >=20 > Regards > /Henrik=20 >=20 > =20 > =20 > Henrik Albertsson=20 > System Manager > IMS Service Layer >=20 > =20 >=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 >=20 --=20 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 Fri Jul 2 03:38: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 DAA12637 for ; Fri, 2 Jul 2004 03:38: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 1BgIco-0001NI-P3 for simple-archive@ietf.org; Fri, 02 Jul 2004 03:38:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgIbi-00010R-00 for simple-archive@ietf.org; Fri, 02 Jul 2004 03:37:15 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BgIb6-0000dU-00; Fri, 02 Jul 2004 03:36:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgITf-0003X2-6g; Fri, 02 Jul 2004 03:28:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgINv-0001M0-Re for simple@megatron.ietf.org; Fri, 02 Jul 2004 03:23: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 DAA12121 for ; Fri, 2 Jul 2004 03:22: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 1BgINt-0003w6-M2 for simple@ietf.org; Fri, 02 Jul 2004 03:22:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgIMt-0003bA-00 for simple@ietf.org; Fri, 02 Jul 2004 03:21:56 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1BgILn-0002xj-00 for simple@ietf.org; Fri, 02 Jul 2004 03:20:47 -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 i627Kf201812; Fri, 2 Jul 2004 10:20:42 +0300 (EET DST) X-Scanned: Fri, 2 Jul 2004 10:20:22 +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 i627KMgg032545; Fri, 2 Jul 2004 10:20:22 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00eDqUeJ; Fri, 02 Jul 2004 10:20: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 i627KDH25561; Fri, 2 Jul 2004 10:20:13 +0300 (EET DST) Received: from nokia.com ([172.21.42.108]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 2 Jul 2004 10:20:09 +0300 Message-ID: <40E50CA8.2050100@nokia.com> Date: Fri, 02 Jul 2004 10:20:08 +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: "Joel M. Halpern" Subject: Re: [Simple] Double specification: text and schema References: <5.1.0.14.0.20040701110539.023d8090@localhost> In-Reply-To: <5.1.0.14.0.20040701110539.023d8090@localhost> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Jul 2004 07:20:09.0107 (UTC) FILETIME=[01982E30:01C46005] Content-Transfer-Encoding: 7bit Cc: SIMPLE mailing list X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org 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 Joel: I don't agree with you. We can't avoid the XML schema. I believe you agree with me. Since the XML schema already needs to indicate whether an element or attribute is mandatory or not, there is no point in repeating the same information in the text. What for? If you are implementing the draft, you need to implement the XML schema. If you just look at the text, then we will have interoperability problems. If you are just a curious reader, then you most likely don't look at the XML schema, but you don't care whether an element MUST be present or MAY be present (and if you care, look at the XML schema). You most likely care about the existence of an element. Therefore, I don't support having a disclaimer like: "we try to have 100% quality in this document, but if we didn't achieve 100% quality, the XML shema takes precedence". - Miguel Joel M. Halpern wrote: > I would agree that this can be a problem. > I would like to phrase the solution differently. (I am not sure whether > I am disagreeing with Miguel's proposal or not.) > > While I like reading the schema, I really want the text to be clear and > sufficiently precise. Hence, I would prefer not to weaken the use of > MUST, etc. in the text. > > Rather, I would suggest that we simply state in a paragraph in the > introduction, after the citation for the terms MUST, SHOULD, ... that in > the case of conflict between the text and the XML schema, any > requirements or prohibitions defined in the schema take precedence over > conflicting text. > > Yours, > Joel M. Halpern > > At 02:10 PM 7/1/2004 +0300, Miguel Garcia wrote: > >> The problem: We have two normative statements (one in the text, >> another in the XML schema) indicating the same thing. This is not a >> big problem as long as both statements indicate the same thing. But >> what happens if the document evolves, and then we it is decided to >> make mandatory some attribute that previously was optional, and what >> happen if the change is reflected only in the textual form and not in >> the schema; or vice versa. Then we run into trouble. >> >> Therefore, I would like to propose that, in the sake of >> interoperability of implementations, documents indicating XML schemas >> MUST specify the normative part as much as possible in the XML schema >> definition. Only those bits that cannot be specified in the schema >> MUST be specified in the text. > > -- 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 Fri Jul 2 03:40: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 DAA12772 for ; Fri, 2 Jul 2004 03:40: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 1BgIeX-00029U-5M for simple-archive@ietf.org; Fri, 02 Jul 2004 03:40:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgIdS-0001kF-00 for simple-archive@ietf.org; Fri, 02 Jul 2004 03:39:04 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BgIcP-00011H-00; Fri, 02 Jul 2004 03:37:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgITg-0003XE-Bj; Fri, 02 Jul 2004 03:28:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgINx-0001M1-Sl for simple@megatron.ietf.org; Fri, 02 Jul 2004 03:23: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 DAA12131 for ; Fri, 2 Jul 2004 03:22: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 1BgINv-0003wG-J3 for simple@ietf.org; Fri, 02 Jul 2004 03:22:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgIMv-0003bQ-00 for simple@ietf.org; Fri, 02 Jul 2004 03:21:58 -0400 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1BgILr-00035q-00 for simple@ietf.org; Fri, 02 Jul 2004 03:20: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 i627Kh624365; Fri, 2 Jul 2004 10:20:43 +0300 (EET DST) X-Scanned: Fri, 2 Jul 2004 10:19:11 +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 i627JBo2028037; Fri, 2 Jul 2004 10:19:11 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00SYUCtg; Fri, 02 Jul 2004 10:19:10 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 i627J3H24293; Fri, 2 Jul 2004 10:19:03 +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, 2 Jul 2004 10:19:01 +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: Tiny ant vs big Mammoths, was RE: [Simple] Using MSRP for real time text conversation x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Date: Fri, 2 Jul 2004 10:19:00 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7023EEA8B@esebe019.ntc.nokia.com> Thread-Topic: Tiny ant vs big Mammoths, was RE: [Simple] Using MSRP for real time text conversation Thread-Index: AcRfhSgGp69wz7mdQc2STF2vk1RzZAACN3aQAARB+kAABIe6EAAUstnA To: , , X-OriginalArrivalTime: 02 Jul 2004 07:19:01.0395 (UTC) FILETIME=[D93C2630:01C46004] Content-Transfer-Encoding: quoted-printable Cc: stf267@etsi.org, adam@dynamicsoft.com, simple@ietf.org, toip@snowshore.com, gunnar.hellstrom@omnitor.se, 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.8 required=5.0 tests=AWL,MAILTO_TO_SPAM_ADDR, NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Arnoud, You speak as if you have done the market research already for all of us = :) How do you know that people will appreciate it once they discover it? = How do you know that people will use it? How do you know that it adds = value to the phone instead of just implementing something that no one = will use? How do you know that if I like interactive text, then my mum = and dad will and buy a phone like mine just to use interactive text???? = How do you know...? Did people complain to you that IM the way it is these days in annoying = to use? or are you just stating your opinion? And about mobile phones. If you can type an SMS faster than 2 characters = a second, you're a genius. Even if you can, I don't believe operators = would want to floor they scarce air interface with IP packets that carry = 2 characters at a time. Thanks, Hisham > -----Original Message----- > From: ext Arnoud van Wijk [mailto:a.vwijk@viataal.nl] > Sent: 02.July.2004 00:38 > To: 'Henry Sinnreich'; 'Dean Willis' > Cc: bcampbell@dynamicsoft.com; Khartabil Hisham=20 > (Nokia-TP-MSW/Helsinki); > gunnar.hellstrom@omnitor.se; adam@dynamicsoft.com; stf267@etsi.org; > simple@ietf.org; toip@snowshore.com > Subject: RE: Tiny ant vs big Mammoths, was RE: [Simple] Using MSRP for > real time text conversation >=20 >=20 > Henry, > Do you know what the danger is? > I already see it emerging. >=20 > Here at the IETF many are wonderful and quite supporters for=20 > Interactive > text. But their bosses..higher up pointed haired bosses are=20 > just dumb and > only see what they know. >=20 > Interactive text is scary for them. They do not believe that=20 > many will use > it under condition that it is available in as many phones as possible! > All mobile phones offer SMS (Europe, Asia). But most do not=20 > use it. But a > significant group does. Even though text input is very clumsy using > numerical key combinations. >=20 > Too many say right now EXACT the same thing as with Interactive text. > SMS/Interactive text? Hardly anybody is interested in it. Why=20 > send text > while you can just as quickly place a voice call? There is no need for > SMS/Interactive text. People won't use it Don't like it. >=20 > (sounds familiar?) >=20 > My message to the vendors is simple: implement interactive=20 > text. Text/t140. > If you have a phone with IM capabilities, add interactive text! > Try interactive text in as many phones you produce! People=20 > will be grateful > for it and buy your products. > I am not saying that every phone must have it. But in every=20 > price range, > have enough models with text/t140. > It is cheap to implement, it adds value to your phone for the=20 > buyers. And > those who don't care, will likely later appreciate=20 > interactive text as soon > they discover it. And keep buying your IP phones for their=20 > kids, family > members..new phone etc etc. >=20 > We, the IETF cannot mandate this. But we are a bunch of smart=20 > people. So, we > do know what we do. >=20 > Greetz >=20 > Arnoud >=20 >=20 >=20 >=20 > -----Original Message----- > From: Henry Sinnreich [mailto:Henry.Sinnreich@mci.com]=20 > Sent: donderdag 1 juli 2004 21:53 > To: 'Arnoud van Wijk'; 'Dean Willis' > Cc: bcampbell@dynamicsoft.com; hisham.khartabil@nokia.com; > gunnar.hellstrom@omnitor.se; adam@dynamicsoft.com; stf267@etsi.org; > simple@ietf.org; toip@snowshore.com > Subject: RE: Tiny ant vs big Mammoths, was RE: [Simple] Using=20 > MSRP for real > time text conversation >=20 > Arnoud, >=20 > I have to agree with Dean's arguments and add that in dealing=20 > with real > vendors and program managers, even what is 100% consensus in=20 > the IETF is "in > the next generation" (in a next life probably) under=20 > consideration for them. >=20 > So let's do a reality check and come back with these issues=20 > after we had a > couple of months to check with vendors and program managers,=20 > so we don't > spin our wheels here in the list. >=20 > Henry >=20 > Henry Sinnreich > MCI > 400 International Parkway > Richardson, Texas 75081 > USA > =20 > -----Original Message----- > From: owner-toip@snowshore.com=20 > [mailto:owner-toip@snowshore.com] On Behalf > Of Arnoud van Wijk > Sent: Thursday, July 01, 2004 12:24 PM > To: 'Dean Willis' > Cc: bcampbell@dynamicsoft.com; hisham.khartabil@nokia.com; > gunnar.hellstrom@omnitor.se; adam@dynamicsoft.com; stf267@etsi.org; > simple@ietf.org; toip@snowshore.com > Subject: RE: Tiny ant vs big Mammoths, was RE: [Simple] Using=20 > MSRP for real > time text conversation >=20 > Dean, >=20 > I said this to indicate that the method Interactive text is using for > redundancy will only slightly increase the bandwidth. There=20 > are generally no > more packets per second being sent with redundancy, the=20 > redundant generation > is sent with the normal next batch of typed characters in the=20 > following > packet!=20 > Think of a bus with 10 characters in it or a bus with 20=20 > characters in it. > It is then the same bus. >=20 > It is not 1 packet per character! Unless you t y p e s =20 > o s l o w > that there is a second or more between every character or so. :-) >=20 > And if there is a congestion like you described with so many=20 > Interactive > text streams. Normal congestion mechnism that are used for=20 > other RTP traffic > will also apply for Interactive text. > Also as stated in the 07 version of the RFC 2793 bis draft,=20 > if there is a > good mechanism that prevents dropped packets..then that can=20 > be used instead > of the 2 generations redundancy. >=20 > So, I do not see the problem. >=20 > Greetz >=20 > Arnoud >=20 >=20 >=20 > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com]=20 > Sent: donderdag 1 juli 2004 18:04 > To: A vWijk > Cc: bcampbell@dynamicsoft.com; hisham.khartabil@nokia.com; > gunnar.hellstrom@omnitor.se; adam@dynamicsoft.com; stf267@etsi.org; > simple@ietf.org; toip@snowshore.com > Subject: Re: Tiny ant vs big Mammoths, was RE: [Simple] Using=20 > MSRP for real > time text conversation >=20 > A vWijk wrote: > > My comment marked with *** > > *** The discussion about MSRP is only to play with the idea=20 > of using MSRP > for interactive text. > > The idea to lift with the instant messaging revolution on=20 > 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=20 > using MSRP for > interactive text. > >=20 > > So... t140/RTP is a great solution and the redundancy usage of 2 > generations are indeed sent by the next packet that would be=20 > sent anyway. So > there is hardly any load increase at all. > > And I had yesterday a call with interactive text (t140/RTP)=20 > along with > audio and video, the connection was not so good, 20% packets=20 > drop with peaks > to about 40% lost packets. Sound was bad (according the=20 > hearing person, > video was also bad with blocks in it..but the interactive=20 > text worked just > flawlessly. When disabling the interactive text, the audio=20 > and video staryed > just as crappy as they were. > > We talk about 2-3 kbit/sec out of 384 kbit total bandwidth=20 > used!!! THAT is > now we are talking about (yes with redundancy on!)..a tiny=20 > little ant along > the Mammoths. > >=20 > > Just to bring it into the right perspective. :-) > >=20 > > So, there is nothing wrong with RFC2793 interactive text.=20 > Except perhaps > that a device that does not support RTP cannot use T140/RTP. > >=20 >=20 > No, let's put it in the right perspective. >=20 > Assume real-time text drives 2kb/s of bandwidth, or approximately 3=20 > packets per second. >=20 > Assume 20,000,000 users are running real-time-text sessions=20 > concurrently. This is approximately peak load for a really big mobile=20 > operator, and well below peak load for the Internet as a whole. >=20 > Assume that real-time text continues to operate without the sort of=20 > congestion control that forces it to "back off" in the event=20 > of network=20 > congestion. >=20 > We now have 40 billion (40E9) bits per second of=20 > non-bandwidth-controlled traffic out there, or approximately 60E6=20 > packets per second. >=20 > Will any of this ever traverse a link that is also trying to=20 > carry nice=20 > friendly TCP traffic? Will that link ever get congested? Will the=20 > real-time text "starve out" the TCP traffic when it does? The answers=20 > here are most likely "yes" . . . >=20 > How can you assure us that this will never happen? Are=20 > operators going=20 > to build dedicated networks for real-time text? Are we going to use=20 > DS-markings to make real-time text low priority and discardable? >=20 > Or, otherwise said, what gives real-time-text the "right" to=20 > cheat the=20 > rules and unfairly consume scarce network resources? Does any=20 > application have that right? >=20 > -- > Dean >=20 >=20 >=20 > - > This list is maintained by Snowshore Networks -=20 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 Fri Jul 2 03: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 DAA13488 for ; Fri, 2 Jul 2004 03: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 1BgIut-0000WC-8C for simple-archive@ietf.org; Fri, 02 Jul 2004 03:57:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgItu-00008l-00 for simple-archive@ietf.org; Fri, 02 Jul 2004 03:56:03 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BgIsv-0007Fy-00; Fri, 02 Jul 2004 03:55:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgIlC-0001lh-GJ; Fri, 02 Jul 2004 03: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 1BgIhm-00086X-IE for simple@megatron.ietf.org; Fri, 02 Jul 2004 03:43: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 DAA12990 for ; Fri, 2 Jul 2004 03:43: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 1BgIhe-0003JC-Uq for simple@ietf.org; Fri, 02 Jul 2004 03:43:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgIga-0002x3-00 for simple@ietf.org; Fri, 02 Jul 2004 03:42:16 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1BgIg1-0002at-00 for simple@ietf.org; Fri, 02 Jul 2004 03:41:41 -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 i627fcJ17225; Fri, 2 Jul 2004 10:41:38 +0300 (EET DST) X-Scanned: Fri, 2 Jul 2004 10:41:32 +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 i627fWgc017739; Fri, 2 Jul 2004 10:41:32 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 002wyhcq; Fri, 02 Jul 2004 10:41:31 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 i627fPH13950; Fri, 2 Jul 2004 10:41:25 +0300 (EET DST) Received: from nokia.com ([172.21.42.108]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 2 Jul 2004 10:41:21 +0300 Message-ID: <40E511A1.10403@nokia.com> Date: Fri, 02 Jul 2004 10:41:21 +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: "Drage, Keith (Keith)" Subject: Re: [Simple] Double specification: text and schema References: <475FF955A05DD411980D00508B6D5FB00C290139@en0033exch001u.uk.lucent.com> In-Reply-To: <475FF955A05DD411980D00508B6D5FB00C290139@en0033exch001u.uk.lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Jul 2004 07:41:21.0752 (UTC) FILETIME=[F8266580:01C46007] Content-Transfer-Encoding: 7bit Cc: "'SIMPLE mailing list'" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org 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 Keith: Just to clarify that I was just pointing out one example draft, but I believe the problem is spread out across most of the drafts this working group is producing. Therefore, I will urge the working group to take a resolution ASAP that could be applied immediately. - Miguel Drage, Keith (Keith) wrote: > Although I am not an author of these drafts, I agree strongly with Miguel here. > > In fact we already had a similar discussion in the floor control design team in XCON (BNF versus text rather than XML versus text) and came to the same conclusion. > > regards > > Keith > > >>-----Original Message----- >>From: Miguel Garcia [mailto:Miguel.An.Garcia@nokia.com] >>Sent: 01 July 2004 12:10 >>To: SIMPLE mailing list >>Subject: [Simple] Double specification: text and schema >> >> >>Hi: >> >>I want to point out an issue I have found when reviewing a >>few I-Ds that >>define XML schemas. >> >>The problem is that many documents do double normative >>specification: on >> one side, they introduce normative text when they describe >>the various >>elements that are part of the XML schema; on the other side, the XML >>schema is normative by itself. >> >>An example: >> >>draft-ietf-simple-filter-format-01.txt says in section 3.2 >> >> The MUST have an 'id' attribute. The value of the 'id' >> attribute MUST be unique within the element. The >> MAY have an 'uri' attribute. The value of the 'uri' >> attribute is the URI of the resource which the filter applies to. >> The MAY have an 'domain' attribute. The value of the >> 'domain' attribute is the domain of the resources that the filter >> applies to. The "uri" attribute and the "domain" >>attribute MUST NOT >> appear together in a filter. >> >>Then, the XML schema indicates that MUST have a >>required 'id' >>attribute: >> >> >> >>The schema also says that MAY have a 'uri' attribute >>(optional): >> >> >> >> >>And so on. >> >>The problem: We have two normative statements (one in the >>text, another >>in the XML schema) indicating the same thing. This is not a >>big problem >>as long as both statements indicate the same thing. But what >>happens if >>the document evolves, and then we it is decided to make >>mandatory some >>attribute that previously was optional, and what happen if >>the change is >>reflected only in the textual form and not in the schema; or >>vice versa. >>Then we run into trouble. >> >>Therefore, I would like to propose that, in the sake of >>interoperability >>of implementations, documents indicating XML schemas MUST specify the >>normative part as much as possible in the XML schema definition. Only >>those bits that cannot be specified in the schema MUST be >>specified in >>the text. >> >>According to this suggestion, the above paragraph would be >>re-written as: >> >> The has an 'id' attribute. The value of the 'id' >> attribute MUST be unique within the element. The >> has an 'uri' attribute. The value of the 'uri' >> attribute is the URI of the resource which the filter applies to. >> The has an 'domain' attribute. The value of the >> 'domain' attribute is the domain of the resources that the filter >> applies to. The 'uri' attribute and the 'domain' >>attribute MUST NOT >> appear together in a filter. >> >>Note that the text above still indicates a couple of >>normative sentences >>that cannot be expressed (to my knowledge) in the schema. >> >>Comments? Can we agree this way of working from now on? >> >>- 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 >> > > -- 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 Fri Jul 2 04:09: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 EAA13948 for ; Fri, 2 Jul 2004 04:08: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 1BgJ6R-0004lq-U8 for simple-archive@ietf.org; Fri, 02 Jul 2004 04:09:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgJ5U-0004RU-00 for simple-archive@ietf.org; Fri, 02 Jul 2004 04:08:00 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BgJ4p-0003mu-00; Fri, 02 Jul 2004 04:07:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgIz1-0006gp-8S; Fri, 02 Jul 2004 04:01:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgIt2-0003fv-A4 for simple@megatron.ietf.org; Fri, 02 Jul 2004 03:55: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 DAA13432 for ; Fri, 2 Jul 2004 03:55: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 1BgIt0-0007ad-0w for simple@ietf.org; Fri, 02 Jul 2004 03:55:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgIs4-0007FX-00 for simple@ietf.org; Fri, 02 Jul 2004 03:54:09 -0400 Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1BgIrE-0006uJ-00 for simple@ietf.org; Fri, 02 Jul 2004 03:53:16 -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 i627rHPA019104 for ; Fri, 2 Jul 2004 09:53:17 +0200 (MEST) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Fri, 2 Jul 2004 09:53:18 +0200 Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Fri, 2 Jul 2004 09:53:17 +0200 Message-ID: From: "Anders Lindgren C (HF/EAB)" To: simple@ietf.org, "'hisham.khartabil@nokia.com'" Date: Fri, 2 Jul 2004 09:53:11 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 02 Jul 2004 07:53:18.0919 (UTC) FILETIME=[A39D6570:01C46009] Subject: [Simple] simple-filter Max Size or Max number of element as filter criteri as? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org 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 Hi, The XML documents sent from the network to the client can be very large or it can contains a very long sequence of elements ( e.g a resource list with 1000 buddies) It will also exist different types of clients. Some clients can specify a very large resource list and it will exist clients that can not handle that large list. I have not found how a client can inform the network about how large documents is can handle or how many elements of a certain type it can handle. My question is now if this information can be regarded as filter criterias and includes in this filter specification? Best regards Anders Lindgren Ericsson AB Sweden _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jul 2 04:25: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 EAA14566 for ; Fri, 2 Jul 2004 04:25: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 1BgJM3-0002cl-Oz for simple-archive@ietf.org; Fri, 02 Jul 2004 04:25:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgJL4-0002ET-00 for simple-archive@ietf.org; Fri, 02 Jul 2004 04:24:06 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BgJK5-0001Vm-00; Fri, 02 Jul 2004 04:23:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgJ3r-0007wD-PT; Fri, 02 Jul 2004 04:06:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgIyo-0006V6-4i for simple@megatron.ietf.org; Fri, 02 Jul 2004 04:01: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 EAA13701 for ; Fri, 2 Jul 2004 04:01:04 -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 1BgIym-00020l-2U for simple@ietf.org; Fri, 02 Jul 2004 04:01:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgIxj-0001dZ-00 for simple@ietf.org; Fri, 02 Jul 2004 03:59:59 -0400 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1BgIwe-0000wF-00 for simple@ietf.org; Fri, 02 Jul 2004 03:58:53 -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 i627wl616590; Fri, 2 Jul 2004 10:58:47 +0300 (EET DST) X-Scanned: Fri, 2 Jul 2004 10:58: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 i627whfc022024; Fri, 2 Jul 2004 10:58:43 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00IW8jw4; Fri, 02 Jul 2004 10:58:42 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 i627waH29460; Fri, 2 Jul 2004 10:58:36 +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); Fri, 2 Jul 2004 10:58:35 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Tiny ant vs big Mammoths, was RE: [Simple] Using MSRP for realtime text conversation x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Date: Fri, 2 Jul 2004 10:58:36 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7023EEA8F@esebe019.ntc.nokia.com> Thread-Topic: RE: Tiny ant vs big Mammoths, was RE: [Simple] Using MSRP for realtime text conversation Thread-Index: AcRflnRGhBNmDq35Tv6r6MMC3ZXuVQAa4h/QAAIRnCA= To: , X-OriginalArrivalTime: 02 Jul 2004 07:58:35.0866 (UTC) FILETIME=[6087ABA0:01C4600A] 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.9 required=5.0 tests=AWL,EXCUSE_16,HTML_MESSAGE, MAILTO_TO_SPAM_ADDR,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Guido Gybels [mailto:Guido.Gybels@rnid.org.uk] > Sent: 02.July.2004 10:09 > To: RNIDMAIL.GWIA."gv@trace.wisc.edu"; bcampbell@dynamicsoft.com; > dean.willis@softarmor.com; gunnar.hellstrom@omnitor.se;=20 > Khartabil Hisham > (Nokia-TP-MSW/Helsinki); > IMCEAGWISE-RNIDMAIL+2EGWIA+2E+22A+2EvWijk+40viataal+2Enl+22@rn > id.org.uk > Cc: adam@dynamicsoft.com; simple@ietf.org; stf267@etsi.org; > toip@snowshore.com > Subject: RE: Tiny ant vs big Mammoths, was RE: [Simple] Using MSRP for > realtime text conversation >=20 >=20 > Gregg and others, >=20 > Thanks for, as always, a helpful and well formulated=20 > response. To clarify: >=20 > < technologies. I don't > see it as bad theoretically. Difference facilitates evolution.>> >=20 > But that is why I used the phrase "solutions for deaf=20 > people's communication needs". For them it's not a matter of=20 > competition in the mainstream market, with consumer choice=20 > and the economics that go with it. >=20 > For deaf people, the choice is between the ability to=20 > communicate and the INability to do so. Why are deaf people at a disadvantage if they need to use IM the way it = is today instead of real-time text for textual conversations? I believe you are talking about voice to text translation, and that is = not instant messaging. /Hisham > While IM is already=20 > becoming more and more mainstream, it does not meet their=20 > requirements, so making sure there is something streamed in=20 > place is of the greatest importance. And of course, once we=20 > do put somethign in place, we should not make the same=20 > mistakes as in the past and use different protocols, because=20 > precisely this is what has been disenfranchising deaf people=20 > in terms of availability, interoperability, choice and cost. >=20 > < failures>> >=20 > Agreed. >=20 > Best wishes, >=20 > Guido >=20 > Guido Gybels > Director of New Technologies >=20 > RNID, 19-23 Featherstone Street > London EC1Y 8SL, UK > Tel +44(0)207 294 3713 > Fax +44(0)207 296 8069 >=20 >=20 >=20 > ************************************************************** > ********** > 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. >=20 > If you are not the intended recipient you are advised that any > use, dissemination, forwarding, printing or copying of this > email is strictly prohibited. >=20 > If you have received this email in error please notify the RNID > Helpdesk by telephone on: +44 (0) 207 296 8282. >=20 > The Royal National Institute for Deaf People =20 > Registered Office 19-23 Featherstone Street=20 > London EC1Y 8SL No. 454169 (England) > Registered Charity No. 207720 > ************************************************************** > ********** >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jul 2 04:33: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 EAA14853 for ; Fri, 2 Jul 2004 04: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 1BgJTz-0005R5-7e for simple-archive@ietf.org; Fri, 02 Jul 2004 04:33:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgJSt-00054M-00 for simple-archive@ietf.org; Fri, 02 Jul 2004 04:32:11 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BgJSJ-0004hM-00; Fri, 02 Jul 2004 04:31:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgJKa-0004ZP-85; Fri, 02 Jul 2004 04:23:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgJ7g-0000DH-A6 for simple@megatron.ietf.org; Fri, 02 Jul 2004 04:10: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 EAA13984 for ; Fri, 2 Jul 2004 04:10:14 -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 1BgJ7e-000590-4N for simple@ietf.org; Fri, 02 Jul 2004 04:10:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgJ6a-0004mq-00 for simple@ietf.org; Fri, 02 Jul 2004 04:09:08 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1BgJ61-0004Rx-00 for simple@ietf.org; Fri, 02 Jul 2004 04:08:33 -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 i6288X227327; Fri, 2 Jul 2004 11:08:33 +0300 (EET DST) X-Scanned: Fri, 2 Jul 2004 11:08:17 +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 i6288HeI024708; Fri, 2 Jul 2004 11:08:17 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00QNEQSv; Fri, 02 Jul 2004 11:07: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 i6287DH16295; Fri, 2 Jul 2004 11:07:13 +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); Fri, 2 Jul 2004 11:07:08 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Date: Fri, 2 Jul 2004 11:07:08 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7023EEA91@esebe019.ntc.nokia.com> Thread-Topic: simple-filter Max Size or Max number of element as filter criterias? Thread-Index: AcRgCfE4TRVvM7frS4ej8BmuPaJFoQAAS9Ag To: , X-OriginalArrivalTime: 02 Jul 2004 08:07:08.0710 (UTC) FILETIME=[92357460:01C4600B] Content-Transfer-Encoding: quoted-printable Subject: [Simple] RE: simple-filter Max Size or Max number of element as filter criterias? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org 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 believe that you are asking for is outside the scope of the = simple-filter drafts. It can be done with filters, but not those ones. The current filter drafts talk about filtering unwanted or uninteresting = information sent in a NOTIFY. They also talk about triggering of = notifications when certain changes to the state of an event occur. Regards, Hisham > -----Original Message----- > From: ext Anders Lindgren C (HF/EAB) > [mailto:anders.c.lindgren@ericsson.com] > Sent: 02.July.2004 10:53 > To: simple@ietf.org; Khartabil Hisham (Nokia-TP-MSW/Helsinki) > Subject: simple-filter Max Size or Max number of element as filter > criterias? >=20 >=20 > Hi, > The XML documents sent from the network to the client can be=20 > very large or it can contains a very long sequence of=20 > elements ( e.g a resource list with 1000 buddies) > It will also exist different types of clients. Some clients=20 > can specify a very large resource list and it will exist=20 > clients that can not handle that large list. >=20 > I have not found how a client can inform the network about=20 > how large documents is can handle or how many elements of a=20 > certain type it can handle. > My question is now if this information can be regarded as=20 > filter criterias and includes in this filter specification? >=20 > Best regards >=20 > Anders Lindgren Ericsson AB Sweden >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jul 2 04: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 EAA14881 for ; Fri, 2 Jul 2004 04: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 1BgJUj-0005ms-70 for simple-archive@ietf.org; Fri, 02 Jul 2004 04:34:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgJTi-0005PB-00 for simple-archive@ietf.org; Fri, 02 Jul 2004 04:33:03 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BgJSb-0004ik-00; Fri, 02 Jul 2004 04:31:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgJKg-0004e1-LE; Fri, 02 Jul 2004 04:23:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgJ8Q-0000LS-Id for simple@megatron.ietf.org; Fri, 02 Jul 2004 04:11: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 EAA14005 for ; Fri, 2 Jul 2004 04:11: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 1BgJ8O-0005TT-96 for simple@ietf.org; Fri, 02 Jul 2004 04:11:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgJ7P-00057C-00 for simple@ietf.org; Fri, 02 Jul 2004 04:10:00 -0400 Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1BgJ6T-0004m6-00 for simple@ietf.org; Fri, 02 Jul 2004 04:09:02 -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 i62892PA023673 for ; Fri, 2 Jul 2004 10:09:02 +0200 (MEST) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Fri, 2 Jul 2004 10:09:02 +0200 Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Fri, 2 Jul 2004 10:09:02 +0200 Message-ID: <342C4681F0D4A04CA50A97D74DA8FB9A0C0AC79B@esealnt875.al.sw.ericsson.se> From: "Henrik Albertsson (KI/EAB)" To: "'Miguel Garcia'" Date: Fri, 2 Jul 2004 10:08:54 +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: 02 Jul 2004 08:09:02.0862 (UTC) FILETIME=[D63FAAE0:01C4600B] Content-Transfer-Encoding: quoted-printable Cc: simple@ietf.org Subject: [Simple] RE: XCAP Directory: Large response ? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org 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 Isn't this also a problem for XCAP in general - you do not know the = size of the list you are retrieving. You might select the wrong list = and fetch the global contact list containing all Nokia employees, then = you would at least need a way to get the list in manageable pieces. I = see the options from a requirement point as:=20 (1) You know the size of the document you are retrieving and then = decide to do it or not. Most basic is the data size of the list or more = advanced the number of elements in the list.=20 (2) You can indicate how many items of the list you want to retrieve, = you get for example the first 50 - then nothing more.=20 (3) You can indicate how many items you want in each "slice", then you = can iterative go and fetch the list in the sizes you want.=20 Any options I have missed?=20 /Henrik=20 -----Original Message----- From: Miguel Garcia [mailto:Miguel.An.Garcia@nokia.com] Sent: den 2 juli 2004 09:15 To: Henrik Albertsson (KI/EAB) Cc: simple@ietf.org Subject: Re: XCap Directory: Large respons ? Hi Henrik: I think you got a good point. I think we need to add a new requirement=20 to the draft that reads something like: - The XCAP client MUST be able to limit the amount of information=20 returned by the XCAP server, so that the XCAP directory document does=20 not flood the client. As for a possible solution... I need to think about it... Most likely = we=20 will need to define some sort of convention, kind of adding a parameter = to the URI to limit the number of entries in the response. Something = like: GET http://xcap.example.com/services/directory/users/ bill/directory.xml?entries=3D50 HTTP/1.1 I am open to hear suggestions. Regards, Miguel Henrik Albertsson (KI/EAB) wrote: > Hi, >=20 > The current version of the XCAP Directory does not contain any limit = of the size of the response. An XCAP Directory can potentially be very = large if it collects all list for a user, especially in a mobile = environment this would be problem. Any ideas how to limit the response? = >=20 > Regards > /Henrik=20 >=20 > =20 > =20 > Henrik Albertsson=20 > System Manager > IMS Service Layer >=20 > =20 >=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 >=20 --=20 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 Fri Jul 2 04:39: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 EAA15192 for ; Fri, 2 Jul 2004 04:39: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 1BgJZe-0007dY-CU for simple-archive@ietf.org; Fri, 02 Jul 2004 04:39:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgJYY-0007Ew-00 for simple-archive@ietf.org; Fri, 02 Jul 2004 04:38:03 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BgJXQ-0006Wq-00; Fri, 02 Jul 2004 04:36:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgJPb-0006Ne-0y; Fri, 02 Jul 2004 04:28:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgJHF-0002m7-Ci for simple@megatron.ietf.org; Fri, 02 Jul 2004 04:20: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 EAA14302 for ; Fri, 2 Jul 2004 04:20:07 -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 1BgJHD-0000ly-2N for simple@ietf.org; Fri, 02 Jul 2004 04:20:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgJGE-0000RD-00 for simple@ietf.org; Fri, 02 Jul 2004 04:19:07 -0400 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1BgJFf-00005z-00 for simple@ietf.org; Fri, 02 Jul 2004 04:18:31 -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 i628IE617572; Fri, 2 Jul 2004 11:18:23 +0300 (EET DST) X-Scanned: Fri, 2 Jul 2004 11:17: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 i628HTER004031; Fri, 2 Jul 2004 11:17:29 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00rvCZ4y; Fri, 02 Jul 2004 11:17:20 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 i628HIH16789; Fri, 2 Jul 2004 11:17:18 +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, 2 Jul 2004 11:17:05 +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: Tiny ant vs big Mammoths, was RE: [Simple] Using MSRP forrealtime text conversation x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Date: Fri, 2 Jul 2004 11:17:05 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7023EEA92@esebe019.ntc.nokia.com> Thread-Topic: Tiny ant vs big Mammoths, was RE: [Simple] Using MSRP forrealtime text conversation Thread-Index: AcRgCzvgWuRyKN4eSri9xhGoYZoPqwAAKrLg To: X-OriginalArrivalTime: 02 Jul 2004 08:17:05.0002 (UTC) FILETIME=[F5A064A0:01C4600C] 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.9 required=5.0 tests=AWL,EXCUSE_16, MAILTO_TO_SPAM_ADDR,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Guido, I agree with everything you say below. You misunderstood my point. What = I was saying is that we are standardising an Instant Messaging protocol. = So I did not understand why they are at a disadvantage when they want to = IM with someone. If a deaf person wants to have a "voice" call with someone, then s/he = would use the interactive text application. It is a different = application than the one s/he use if s/he wants to IM with someone. = (Just like when I want to make a phone call, I use a different = application than when I want to IM someone) But I guess what you are saying is that both those applications can be = one of the same, right? By replay to that is why? If interactive text to = deaf people is the "voice" communication and the IM is IM for them, then = those 2 applications need to be separated. Thanks, Hisham > -----Original Message----- > From: ext Guido Gybels [mailto:Guido.Gybels@rnid.org.uk] > Sent: 02.July.2004 11:02 > To: bcampbell@dynamicsoft.com; Khartabil Hisham=20 > (Nokia-TP-MSW/Helsinki); > gunnar.hellstrom@omnitor.se; dean.willis@softarmor.com; > A.vWijk@viataal.nl > Cc: adam@dynamicsoft.com; stf267@etsi.org; simple@ietf.org; > toip@snowshore.com > Subject: RE: Tiny ant vs big Mammoths, was RE: [Simple] Using MSRP > forrealtime text conversation >=20 >=20 > Hisham, >=20 > < IM the way it is > today instead of real-time text for textual conversations?>> >=20 > To be perfectly honest, we have been through this whole=20 > discussion many times in the past. I recently recirculated a=20 > paper that tries to summarise the issues. >=20 > Because it is not an alternative to voice. Hearing people use=20 > IM as a *different* tool, they have the *choice* to select=20 > between voice, email, SMS, IM, etc. Each one of these=20 > communication methods has its own characteristics, its own=20 > level of interactivity, etc. So, hearing people select=20 > amongst these offerings based on what they want to do, the=20 > circumstances, etc. Deaf people will behave the same:=20 > sometimes they will use email, they certainly use SMS a lot, etc. >=20 > However, deaf people can't use voice. >=20 > So, they have no access to one of the most important=20 > communication tools in the Information Society. That=20 > non-access disenfranchises them enormously, in employment,=20 > health, education, social life and entertainment alike. >=20 > Interactive text is the text equivalent of what voice is to=20 > hearing people. So, making it available is bringing deaf=20 > people on a more equal basis in society. >=20 > Just as much as IM is NOT a REPLACEMENT for voice for hearing=20 > people (but rather an ADDITIONAL communication method), it=20 > can NOT be a REPLACEMENT for interactive text for deaf=20 > people. No hearing people would get it in their right minds=20 > to suggest we scrap voice because of the existence of IM.=20 > Yet, that is precisely what some people suggest deaf people=20 > should accept. That would clearly not be the right way=20 > forward. The fact that deaf people do use other forms of=20 > communication, like email or SMS is no more an argument for=20 > getting rid of interactive texting as the use of email and=20 > SMS by hearing people is to get rid of voice telephony. >=20 > Best regards, >=20 > Guido >=20 > Guido Gybels > Director of New Technologies >=20 > RNID, 19-23 Featherstone Street > London EC1Y 8SL, UK > Tel +44(0)207 294 3713 > Fax +44(0)207 296 8069 >=20 >=20 >=20 >=20 > ************************************************************** > ********** > 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. >=20 > If you are not the intended recipient you are advised that any > use, dissemination, forwarding, printing or copying of this > email is strictly prohibited. >=20 > If you have received this email in error please notify the RNID > Helpdesk by telephone on: +44 (0) 207 296 8282. >=20 > The Royal National Institute for Deaf People =20 > Registered Office 19-23 Featherstone Street=20 > London EC1Y 8SL No. 454169 (England) > Registered Charity No. 207720 > ************************************************************** > ********** >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jul 2 05:33: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 FAA20260 for ; Fri, 2 Jul 2004 05:33: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 1BgKQT-0002p5-Cp for simple-archive@ietf.org; Fri, 02 Jul 2004 05:33:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgKPH-0002Qa-00 for simple-archive@ietf.org; Fri, 02 Jul 2004 05:32:32 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BgKOL-0001yY-00; Fri, 02 Jul 2004 05:31:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgK76-0005e3-D0; Fri, 02 Jul 2004 05: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 1BgJu3-0002BO-Tv for simple@megatron.ietf.org; Fri, 02 Jul 2004 05:00: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 FAA18477 for ; Fri, 2 Jul 2004 05:00: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 1BgJu1-0006TG-OG for simple@ietf.org; Fri, 02 Jul 2004 05:00:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgJqf-0005bU-00 for simple@ietf.org; Fri, 02 Jul 2004 04:56:46 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1BgJlA-0003zL-00 for simple@ietf.org; Fri, 02 Jul 2004 04:51:04 -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 i628p1J00949; Fri, 2 Jul 2004 11:51:01 +0300 (EET DST) X-Scanned: Fri, 2 Jul 2004 11:50:58 +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 i628owLr015242; Fri, 2 Jul 2004 11:50:58 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 004A4PSP; Fri, 02 Jul 2004 11:50:57 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 i628omH16519; Fri, 2 Jul 2004 11:50:48 +0300 (EET DST) Received: from nokia.com ([172.21.42.108]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 2 Jul 2004 11:50:43 +0300 Message-ID: <40E521E2.9010209@nokia.com> Date: Fri, 02 Jul 2004 11:50:42 +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: "Henrik Albertsson (KI/EAB)" References: <342C4681F0D4A04CA50A97D74DA8FB9A0C0AC79B@esealnt875.al.sw.ericsson.se> In-Reply-To: <342C4681F0D4A04CA50A97D74DA8FB9A0C0AC79B@esealnt875.al.sw.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-OriginalArrivalTime: 02 Jul 2004 08:50:43.0476 (UTC) FILETIME=[A8BB1540:01C46011] Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mgw-int2.ntc.nokia.com id i628omH16519 Content-Transfer-Encoding: quoted-printable Cc: Jonathan Rosenberg , simple@ietf.org Subject: [Simple] Re: XCAP Directory: Large response ? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org 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 Henrik (and Jonathan): I think you are right, the problem of the large lists is not only=20 applicable to the XCAP directory draft, but to the basic XCAP. Jonathan, do the basic XCAP or the resource list application usage have=20 a mechanism to limit the number of entries returned in the list? I think=20 this is a must in wireless environments. Henrik proposed three solutions, for which 2 and 3 are the same. I=20 believe we need to add some "range" parameter to XCAP fetch operations=20 to limit the result. So, if I send a GET xcapDocument.xml?range=3D1-50,=20 the XCAP server will return up to 50 entries in the list. Then I can do=20 a new GET with the next range, e.g., GET xcapDocument.xml?range=3D51-100,= =20 and so on. How about that? - Miguel Henrik Albertsson (KI/EAB) wrote: > Isn't this also a problem for XCAP in general - you do not know the siz= e of the list you are retrieving. You might select the wrong list and fet= ch the global contact list containing all Nokia employees, then you would= at least need a way to get the list in manageable pieces. I see the opti= ons from a requirement point as:=20 >=20 > (1) You know the size of the document you are retrieving and then decid= e to do it or not. Most basic is the data size of the list or more advanc= ed the number of elements in the list.=20 >=20 > (2) You can indicate how many items of the list you want to retrieve, y= ou get for example the first 50 - then nothing more.=20 >=20 > (3) You can indicate how many items you want in each "slice", then you = can iterative go and fetch the list in the sizes you want.=20 >=20 > Any options I have missed?=20 >=20 > /Henrik=20 >=20 > -----Original Message----- > From: Miguel Garcia [mailto:Miguel.An.Garcia@nokia.com] > Sent: den 2 juli 2004 09:15 > To: Henrik Albertsson (KI/EAB) > Cc: simple@ietf.org > Subject: Re: XCap Directory: Large respons ? >=20 >=20 > Hi Henrik: >=20 > I think you got a good point. I think we need to add a new requirement=20 > to the draft that reads something like: >=20 > - The XCAP client MUST be able to limit the amount of information=20 > returned by the XCAP server, so that the XCAP directory document does=20 > not flood the client. >=20 > As for a possible solution... I need to think about it... Most likely w= e=20 > will need to define some sort of convention, kind of adding a parameter= =20 > to the URI to limit the number of entries in the response. Something li= ke: >=20 > GET http://xcap.example.com/services/directory/users/ > bill/directory.xml?entries=3D50 HTTP/1.1 >=20 > I am open to hear suggestions. >=20 > Regards, >=20 > Miguel >=20 >=20 > Henrik Albertsson (KI/EAB) wrote: >=20 >>Hi, >> >>The current version of the XCAP Directory does not contain any limit of= the size of the response. An XCAP Directory can potentially be very larg= e if it collects all list for a user, especially in a mobile environment = this would be problem. Any ideas how to limit the response?=20 >> >>Regards >>/Henrik=20 >> >>=20 >>=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 >> >=20 >=20 --=20 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 Fri Jul 2 05:36: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 FAA20544 for ; Fri, 2 Jul 2004 05:36: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 1BgKT6-00042g-Fv for simple-archive@ietf.org; Fri, 02 Jul 2004 05:36:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgKSA-0003cj-00 for simple-archive@ietf.org; Fri, 02 Jul 2004 05:35:32 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BgKQx-0002p6-00; Fri, 02 Jul 2004 05:34:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgKEe-0000fm-P8; Fri, 02 Jul 2004 05:21:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgJxp-0003NE-Ay for simple@megatron.ietf.org; Fri, 02 Jul 2004 05:04: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 FAA18886 for ; Fri, 2 Jul 2004 05:04:06 -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 1BgJxm-0000Ju-V9 for simple@ietf.org; Fri, 02 Jul 2004 05:04:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgJwv-0007lG-00 for simple@ietf.org; Fri, 02 Jul 2004 05:03:14 -0400 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1BgJw2-0007Ly-00 for simple@ietf.org; Fri, 02 Jul 2004 05:02:18 -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 i6292H619343; Fri, 2 Jul 2004 12:02:18 +0300 (EET DST) X-Scanned: Fri, 2 Jul 2004 12:02:06 +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 i62926Br000620; Fri, 2 Jul 2004 12:02:06 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00HX89KR; Fri, 02 Jul 2004 12:02:05 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 i62925H27289; Fri, 2 Jul 2004 12:02: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); Fri, 2 Jul 2004 12:02:04 +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] RE: [Sipping] RE: text/T140 andaudio/t140 was:[avt]Comments/questions on draft-ietf-av x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Date: Fri, 2 Jul 2004 12:02:03 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7023EEA98@esebe019.ntc.nokia.com> Thread-Topic: [Simple] RE: [Sipping] RE: text/T140 andaudio/t140 was:[avt]Comments/questions on draft-ietf-av Thread-Index: AcRZ7oAhxcB0CC6GT5qLh6XIsdQ+iQAT8qmAABaV8PABXTxhMAABY1Ug To: X-OriginalArrivalTime: 02 Jul 2004 09:02:04.0694 (UTC) FILETIME=[3EC4B360:01C46013] 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 There is no hostility here. We are negotiating the usefulness of it. = Some people prefer IM, others prefer interactive text, so it might an = additional value service or a waste of implementer's time. No one knows. I would never, for example, use real time text since I, like many people = in the world, am a very slow typist, make many typos and change my mind = a lot about what I should say or how I should say it. One comment inline... > -----Original Message----- > From: simple-bounces@ietf.org=20 > [mailto:simple-bounces@ietf.org]On Behalf > Of ext Arnoud van Wijk > Sent: 25.June.2004 12:51 > To: 'Paul E. Jones'; 'Paul Kyzivat'; 'Guido Gybels' > Cc: fluffy@cisco.com; simple@ietf.org; gv@trace.wisc.edu; > toip@snowshore.com; gunnar.hellstrom@omnitor.se; smundra@telogy.com > Subject: RE: [Simple] RE: [Sipping] RE: text/T140 andaudio/t140 > was:[avt]Comments/questions on draft-ietf-av >=20 >=20 > Good point Paul! >=20 > Also..I want to point it out again... > WE ARE NOT TALKING ABOUT REPLACING INSTANT MESSAGING WITH=20 > INTERACTIVE TEXT! >=20 > Most of you already know that. But just today I met another=20 > person who still > thinks Interactive text is to replace IM. >=20 > I do not understand the hostility from several IM people.=20 > Interactive text > is even going to make IM better! See it as an additional=20 > valuable service > for IM. > Users exchange IM messages, and then a discussion starts,=20 > they switch over > into real-time chat mode. Discuss things, work out plans in=20 > real-time. Then > end the real-time chat mode. > And the next 2 hours they exchange a few IM messages. What makes this character-by-character (or x number of characters for = 300ms) more interactive than IM in the scenario you describe above = (besides the fact that you will see all my spelling mistakes, that I = typed a message then changed my mind and deleted it)? >=20 > And I do hear from many ICQ users who miss the real-time chat=20 > mode. That was > easier to use. And with SIP, server load is not an issue=20 > anymore, which > caused ICQ to scrap this option. >=20 > Cheers >=20 > Arnoud >=20 >=20 > -----Original Message----- > From: owner-toip@snowshore.com=20 > [mailto:owner-toip@snowshore.com] On Behalf > Of Paul E. Jones > Sent: vrijdag 25 juni 2004 1:16 > To: 'Paul Kyzivat'; 'Guido Gybels' > Cc: gunnar.hellstrom@omnitor.se; gv@trace.wisc.edu; fluffy@cisco.com; > simple@ietf.org; toip@snowshore.com; smundra@telogy.com;=20 > a.vwijk@viataal.nl > Subject: RE: [Simple] RE: [Sipping] RE: text/T140 and audio/t140 > was:[avt]Comments/questions on draft-ietf-av >=20 > Paul, >=20 > > I accept your point that IM isn't suitable for a bunch of the > > communication needs of the hearing impaired. (Among=20 > others.) But I also > > want you to accept that RTT isn't a suitable substitute for=20 > IM in the > > applications that millions (actually probably 10s or 100s=20 > of millions) > > of people use it everyday. >=20 > ICQ once had a mode wherein one could send=20 > character-at-a-time and it worked > pretty well (may still be in there). What was nice about it=20 > was that one > could begin his/her reply even before the other person=20 > finished his/her > message. I found the two-way exchange much better than=20 > today's IM systems, > as there was virtually no delay-- it was real-time. >=20 > One of the reasons why the IM systems today have problems in=20 > scaling is that > they have to interface with servers that handle message=20 > exchange between all > those users you spoke about. The farm of servers to run the=20 > existing IM > systems do a lot of work and it's not a trivial task. The=20 > problem with the > model is that farm of central servers that receive and=20 > dispatch messages. > (Perhaps SIMPLE has done something to improve on the current state of > technology, but I'll confess that I don't know.) >=20 > If we can solve the scalability issues required to handle=20 > lots of voice and > video streams flowing between users, then it would not take a=20 > great leap to > do the same thing for text (literally). There may be more=20 > text sessions, > but the only change in resource requirements from blocks of=20 > text and RTT are > the resources required to process messages (as there are more=20 > RTT packets). > For voice, those fifty or so packets per second would not flow through > centralized servers and neither should the text. If the=20 > system operated > allowing media to flow point-to-point, the RTT would scale. =20 > I guess the > question is whether we will be able to allow audio to flow=20 > point-to-point or > whether the FWs, NATs, "session border controllers", and such=20 > devices will > inhibit that. >=20 > Paul >=20 >=20 > - > This list is maintained by Snowshore Networks -=20 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 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jul 2 05:44: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 FAA21253 for ; Fri, 2 Jul 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 1BgKaq-0007HO-St for simple-archive@ietf.org; Fri, 02 Jul 2004 05:44:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgKZb-0006ow-00 for simple-archive@ietf.org; Fri, 02 Jul 2004 05:43:12 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BgKYP-00060x-00; Fri, 02 Jul 2004 05:41:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgKNl-00051G-UT; Fri, 02 Jul 2004 05:30:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgK6c-0005ZT-Q7 for simple@megatron.ietf.org; Fri, 02 Jul 2004 05:13: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 FAA19231 for ; Fri, 2 Jul 2004 05:13: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 1BgK6a-0003Qs-HC for simple@ietf.org; Fri, 02 Jul 2004 05:13:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgK5b-000359-00 for simple@ietf.org; Fri, 02 Jul 2004 05:12:11 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BgK4j-0002ji-00 for simple@ietf.org; Fri, 02 Jul 2004 05:11:17 -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 i629BGN02784; Fri, 2 Jul 2004 12:11:16 +0300 (EET DST) X-Scanned: Fri, 2 Jul 2004 12:11:15 +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 i629BF6h005853; Fri, 2 Jul 2004 12:11:15 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00KYN8LY; Fri, 02 Jul 2004 12:11: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 i629B7H01179; Fri, 2 Jul 2004 12:11:07 +0300 (EET DST) Received: from nokia.com ([172.21.42.108]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 2 Jul 2004 12:10:35 +0300 Message-ID: <40E5268A.9080203@nokia.com> Date: Fri, 02 Jul 2004 12:10:34 +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: "hisham.khartabil@nokia.com" Subject: Re: [Simple] RE: simple-filter Max Size or Max number of element as filter criterias? References: <2038BCC78B1AD641891A0D1AE133DBB7023EEA91@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB7023EEA91@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Jul 2004 09:10:35.0270 (UTC) FILETIME=[6F186A60:01C46014] Content-Transfer-Encoding: 7bit Cc: anders.c.lindgren@ericsson.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,TO_ADDRESS_EQ_REAL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Note that we are currently discussing the same problem applied to XCAP in a similar thread. I believe in XCAP there are no means to filter the number of entries returned in a list. The thread is named: "XCAP Directory: Large response?" - Miguel hisham.khartabil@nokia.com wrote: > I believe that you are asking for is outside the scope of the simple-filter drafts. It can be done with filters, but not those ones. > > The current filter drafts talk about filtering unwanted or uninteresting information sent in a NOTIFY. They also talk about triggering of notifications when certain changes to the state of an event occur. > > Regards, > Hisham > > >>-----Original Message----- >>From: ext Anders Lindgren C (HF/EAB) >>[mailto:anders.c.lindgren@ericsson.com] >>Sent: 02.July.2004 10:53 >>To: simple@ietf.org; Khartabil Hisham (Nokia-TP-MSW/Helsinki) >>Subject: simple-filter Max Size or Max number of element as filter >>criterias? >> >> >>Hi, >>The XML documents sent from the network to the client can be >>very large or it can contains a very long sequence of >>elements ( e.g a resource list with 1000 buddies) >>It will also exist different types of clients. Some clients >>can specify a very large resource list and it will exist >>clients that can not handle that large list. >> >>I have not found how a client can inform the network about >>how large documents is can handle or how many elements of a >>certain type it can handle. >>My question is now if this information can be regarded as >>filter criterias and includes in this filter specification? >> >>Best regards >> >>Anders Lindgren Ericsson AB Sweden >> > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > -- 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 Fri Jul 2 06:05: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 GAA24756 for ; Fri, 2 Jul 2004 06:05: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 1BgKvZ-0007jr-Tk for simple-archive@ietf.org; Fri, 02 Jul 2004 06:05:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgKsQ-0006Z1-00 for simple-archive@ietf.org; Fri, 02 Jul 2004 06:02:39 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BgKoj-0005Jv-02; Fri, 02 Jul 2004 05:58:50 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BgKdT-0003lB-RA; Fri, 02 Jul 2004 05:47:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgKQH-00069P-EX; Fri, 02 Jul 2004 05:33:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgKEC-0008Vi-SK for simple@megatron.ietf.org; Fri, 02 Jul 2004 05:21: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 FAA19541 for ; Fri, 2 Jul 2004 05:21: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 1BgKEA-0006BN-G2 for simple@ietf.org; Fri, 02 Jul 2004 05:21:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgKDA-0005qC-00 for simple@ietf.org; Fri, 02 Jul 2004 05:20:01 -0400 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1BgKC6-0005HG-00 for simple@ietf.org; Fri, 02 Jul 2004 05:18:54 -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 i629Is611427; Fri, 2 Jul 2004 12:18:54 +0300 (EET DST) X-Scanned: Fri, 2 Jul 2004 12:18:43 +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 i629IhBg016473; Fri, 2 Jul 2004 12:18:43 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00NEjObu; Fri, 02 Jul 2004 12:18:43 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 i629IeH13005; Fri, 2 Jul 2004 12:18:40 +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); Fri, 2 Jul 2004 12:18:27 +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: Tiny ant vs big Mammoths, was RE: [Simple] Using MSRPforrealtime text conversation x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Date: Fri, 2 Jul 2004 12:18:25 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7023EEA99@esebe019.ntc.nokia.com> Thread-Topic: Tiny ant vs big Mammoths, was RE: [Simple] Using MSRPforrealtime text conversation Thread-Index: AcRgE2p0UACCk1+9T7ytHvhSIDvDjAAAUOpg To: X-OriginalArrivalTime: 02 Jul 2004 09:18:27.0396 (UTC) FILETIME=[88812040:01C46015] 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.4 required=5.0 tests=AWL,EXCUSE_16,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Ok, I understand your point. You said that average users don't care = about the underlying technology and it is a UI issue, but then you argue = that MSRP should be enabled for real-time text. I'm confused. The issue here is if MSRP should be changed to enable rea-time text so = the deaf are not at a disadvantage. You just proved that it does not = since it is UI issue. I want ask another question: Do you believe that a hearing impaired = person talking to a person without that disability would use text end to = end. I mean a deaf person would send me text and receive it as text and = I sent him text. I see it a little different. I still use voice, but = transcoders would covert it to text. He uses text, but transcoders would = convert it to voice. Thanks, Hisham > -----Original Message----- > From: ext Guido Gybels [mailto:Guido.Gybels@rnid.org.uk] > Sent: 02.July.2004 12:00 > To: Khartabil Hisham (Nokia-TP-MSW/Helsinki) > Cc: simple@ietf.org > Subject: RE: Tiny ant vs big Mammoths, was RE: [Simple] Using > MSRPforrealtime text conversation >=20 >=20 > Hisham, >=20 > < then s/he would > use the interactive text application. It is a different=20 > application than the > one s/he use if s/he wants to IM with someone.>> >=20 > I remember the days when different email systems didn't talk=20 > to each other. It didn't have real mainstream appeal. When I=20 > got my first GSM mobile phone in 1994, SMS didn't work across=20 > network boundaries. It didn't have much appeal. >=20 > Now that email and SMS are, from a user's perspective, fairly=20 > seamless: they are available almost everywhere, even on the=20 > move, it's interoperable between handsets and it traverses=20 > network boundaries just fine, these have become mainstream=20 > provisions. IM has similar problems. So, the gradual=20 > convergence in that technology is good. I suspect that for=20 > quite a while though, there will be different, competing=20 > systems. However, because this is a mainstream technology,=20 > the pressure on various implementers and service providers to=20 > offer interoperability between their systems will increase=20 > and if IM is really to become as widespread as voice=20 > telephony or email, it will have to offer a similar=20 > experience in terms of interworking between various networks. >=20 > For interactive texting, something similar can be argued,=20 > with the big difference that if it is not available, it is=20 > not just an inconvenience, it is actually disenfranchising=20 > deaf and hard of hearing people who rely on text. >=20 > < applications can be one of > the same, right? By replay to that is why? If interactive=20 > text to deaf people > is the "voice" communication and the IM is IM for them, then those 2 > applications need to be separated.>> >=20 > You can use RTT as an alternative to IM. But not the other=20 > way around. That is not to say that I am not interested in=20 > IM. Just that if you have to make a choice, the more=20 > inclusive one of the two is RTT. How manufacturers build=20 > there devices, their UI etc is mostly up to them. Different=20 > manufacturers have different views on how to position devices etc. >=20 > As someone who has been working on UI issues for about 20=20 > years, I would argue that what users want is actually=20 > something which is easy to use, doesn't require different=20 > ways of working for different functions and meets their=20 > needs. IMHO that means that integrating text messaging into=20 > user friendly, mostly integrated applications is wise.=20 > Whether or not the marketing boys are bothered by that is=20 > another question of course! >=20 > Non technical users don't think segmented. They "use a mobile=20 > phone". Whether or not they talk into it or send SMS, such=20 > users don't really bother with the logical and technical=20 > analysis of how applications/protocols and the like are=20 > technically separated and implemented. From a user's=20 > perspective, they have a mobile phone and they use it for=20 > different things. Users want things that are intuitive and=20 > easy to use. Whether or not underneath it's using two modules=20 > and separate protocols, the user doesn't care. >=20 > To argue that because IM and RTT are different technologies,=20 > they should also be visible to the user as clearly different=20 > things is a techie/scientific viewpoint, it does not IMHO=20 > relate to average users at all. >=20 > Best regards, >=20 > Guido >=20 > Guido Gybels > Director of New Technologies >=20 > RNID, 19-23 Featherstone Street > London EC1Y 8SL, UK > Tel +44(0)207 294 3713 > Fax +44(0)207 296 8069 >=20 >=20 >=20 >=20 > ************************************************************** > ********** > 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. >=20 > If you are not the intended recipient you are advised that any > use, dissemination, forwarding, printing or copying of this > email is strictly prohibited. >=20 > If you have received this email in error please notify the RNID > Helpdesk by telephone on: +44 (0) 207 296 8282. >=20 > The Royal National Institute for Deaf People =20 > Registered Office 19-23 Featherstone Street=20 > London EC1Y 8SL No. 454169 (England) > Registered Charity No. 207720 > ************************************************************** > ********** >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jul 2 06: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 GAA26143 for ; Fri, 2 Jul 2004 06: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 1BgLHP-0000NL-CV for simple-archive@ietf.org; Fri, 02 Jul 2004 06:28:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgLGd-0007mp-00 for simple-archive@ietf.org; Fri, 02 Jul 2004 06:27:40 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BgLFf-0007KF-00; Fri, 02 Jul 2004 06:26:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgL22-00069j-Np; Fri, 02 Jul 2004 06:12:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgKwz-0003WU-AK for simple@megatron.ietf.org; Fri, 02 Jul 2004 06: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 GAA24959 for ; Fri, 2 Jul 2004 06:07: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 1BgKww-0000Nl-Us for simple@ietf.org; Fri, 02 Jul 2004 06:07:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgKur-0007bB-00 for simple@ietf.org; Fri, 02 Jul 2004 06:05:10 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BgKrD-00067V-00 for simple@ietf.org; Fri, 02 Jul 2004 06:01:23 -0400 Received: from dynamicsoft.com ([63.113.46.29]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i62A1Abo004688; Fri, 2 Jul 2004 06:01:10 -0400 (EDT) Message-ID: <40E53251.6000102@dynamicsoft.com> Date: Fri, 02 Jul 2004 06:00: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: Miguel Garcia References: <342C4681F0D4A04CA50A97D74DA8FB9A0C0AC79B@esealnt875.al.sw.ericsson.se> <40E521E2.9010209@nokia.com> In-Reply-To: <40E521E2.9010209@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: simple@ietf.org Subject: [Simple] Re: XCAP Directory: Large response ? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org 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: > Henrik (and Jonathan): > > I think you are right, the problem of the large lists is not only > applicable to the XCAP directory draft, but to the basic XCAP. > > Jonathan, do the basic XCAP or the resource list application usage have > a mechanism to limit the number of entries returned in the list? I think > this is a must in wireless environments. HTTP already provides a feature to do this, and since XCAP is just a usage of HTTP, that feature is inherited. The Range header field allows a client to request, amongst other things, a specific maximum number of bytes that it wants of the entity body. Quoting from RFC2616: > By its choice of last-byte-pos, a client can limit the number of > bytes retrieved without knowing the size of the entity. Byte ranges also allow the client to fetch a large resource in pieces, or to give up after obtaining the first piece. HTTP also provides the HEAD method, which returns all of the meta-data about an entity, including its length (I believe), but not the entity itself. Thus, if you were worried about this, you could do a HEAD for the resource, see how bit it is, and then GET it if you want it. > > Henrik proposed three solutions, for which 2 and 3 are the same. I > believe we need to add some "range" parameter to XCAP fetch operations > to limit the result. So, if I send a GET xcapDocument.xml?range=1-50, > the XCAP server will return up to 50 entries in the list. Then I can do > a new GET with the next range, e.g., GET xcapDocument.xml?range=51-100, > and so on. > > How about that? I would propose that we not put this functionality in xcap itself, but use the existing HTTP mechanisms. I will note that these mechanisms are *byte* oriented, and not XML oriented. Thus, you may cut an element off in the middle by asking for the first 50 bytes. However, if your main concern is bandwidth or latency, then bytes are much more significant of a measure than elements. If I say, "give me 30 elements", that could be 30 bytes or 30MB, depennding on the amount of data in each 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 Fri Jul 2 06:42: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 GAA27005 for ; Fri, 2 Jul 2004 06: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 1BgLUo-0005Wp-Uv for simple-archive@ietf.org; Fri, 02 Jul 2004 06:42:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgLTp-0005B0-00 for simple-archive@ietf.org; Fri, 02 Jul 2004 06:41:17 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BgLTG-0004oE-00; Fri, 02 Jul 2004 06:40:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgLFo-0004YM-Hc; Fri, 02 Jul 2004 06:26:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgL5f-0007tN-6R for simple@megatron.ietf.org; Fri, 02 Jul 2004 06:16: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 GAA25533 for ; Fri, 2 Jul 2004 06:16: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 1BgL5c-0003h2-Rj for simple@ietf.org; Fri, 02 Jul 2004 06:16:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgL4Z-0003MD-00 for simple@ietf.org; Fri, 02 Jul 2004 06:15:12 -0400 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1BgL3w-00031b-00 for simple@ietf.org; Fri, 02 Jul 2004 06:14:32 -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 i62AEQ620271; Fri, 2 Jul 2004 13:14:26 +0300 (EET DST) X-Scanned: Fri, 2 Jul 2004 13:14:20 +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 i62AEKCi013009; Fri, 2 Jul 2004 13:14:20 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00GMStMc; Fri, 02 Jul 2004 13:14:19 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 i62AEIH02107; Fri, 2 Jul 2004 13:14:18 +0300 (EET DST) Received: from nokia.com ([172.21.42.108]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 2 Jul 2004 13:14:17 +0300 Message-ID: <40E53579.1020305@nokia.com> Date: Fri, 02 Jul 2004 13:14:17 +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: ext Jonathan Rosenberg References: <342C4681F0D4A04CA50A97D74DA8FB9A0C0AC79B@esealnt875.al.sw.ericsson.se> <40E521E2.9010209@nokia.com> <40E53251.6000102@dynamicsoft.com> In-Reply-To: <40E53251.6000102@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Jul 2004 10:14:17.0863 (UTC) FILETIME=[5589D170:01C4601D] Content-Transfer-Encoding: 7bit Cc: simple@ietf.org Subject: [Simple] Re: XCAP Directory: Large response ? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org 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: > > I would propose that we not put this functionality in xcap itself, but > use the existing HTTP mechanisms. I will note that these mechanisms are > *byte* oriented, and not XML oriented. Thus, you may cut an element off > in the middle by asking for the first 50 bytes. However, if your main > concern is bandwidth or latency, then bytes are much more significant of > a measure than elements. If I say, "give me 30 elements", that could be > 30 bytes or 30MB, depennding on the amount of data in each element. > > -Jonathan R. > Jonathan, I think the HTTP byte ranges will not work. Let's say I request a long document, and I request bytes 1 to 10000. The HTTP server will cut the XML document exacltly when the number of bytes has reached the count, and will send it to the XCAP client. The XCAP client can't check if the document is well-formed, not even check if it is valid according to the XML schema. As a consequence, it won't display it to the user, or dare to do any operation on it. The only thing the XCAP client can do is to request the next byte range. I am concerned with the limited amount of memory a device might have, AND the bandwidth. The latter can be solved with byte ranges, but not the former. However, if we provide a mechanism to request ranges of entries in a list, this will solve the problem: the XCAP server create a valid XML document that complies with the schema and send it to the XCAP client. The client can request additional ranges once it has freed the memory. The drawback is that we cannot accurately control the bandwidth (we don't know how many bytes will come), but I don't think this is a big issue. - 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 Fri Jul 2 06:46: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 GAA27254 for ; Fri, 2 Jul 2004 06:46: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 1BgLYo-00071u-Fg for simple-archive@ietf.org; Fri, 02 Jul 2004 06:46:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgLXp-0006fd-00 for simple-archive@ietf.org; Fri, 02 Jul 2004 06:45:26 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BgLX8-0006Gl-00; Fri, 02 Jul 2004 06:44:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgLP9-0008MG-Ml; Fri, 02 Jul 2004 06:36:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgLEW-0003qi-T7 for simple@megatron.ietf.org; Fri, 02 Jul 2004 06: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 GAA25910 for ; Fri, 2 Jul 2004 06:25: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 1BgLEU-0006xN-Ar for simple@ietf.org; Fri, 02 Jul 2004 06:25:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgLDT-0006ZH-00 for simple@ietf.org; Fri, 02 Jul 2004 06:24:23 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BgLCf-00068K-00 for simple@ietf.org; Fri, 02 Jul 2004 06:23:33 -0400 Received: from dynamicsoft.com ([63.113.46.29]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i62ANKbo004714; Fri, 2 Jul 2004 06:23:20 -0400 (EDT) Message-ID: <40E53788.8020404@dynamicsoft.com> Date: Fri, 02 Jul 2004 06:23:04 -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] Double specification: text and schema References: <5.1.0.14.0.20040701110539.023d8090@localhost> <40E50CA8.2050100@nokia.com> In-Reply-To: <40E50CA8.2050100@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: "Joel M. Halpern" , SIMPLE mailing list X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org 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: > Hi Joel: > > I don't agree with you. We can't avoid the XML schema. I believe you > agree with me. > > Since the XML schema already needs to indicate whether an element or > attribute is mandatory or not, there is no point in repeating the same > information in the text. What for? I think that it can be useful for purposes of clarification. I would advise using non-normative terminology in the text. So, for example: "The element includes a single mandatory attribute, "bar", and always has two children, and ..." I think it also makes sense to have an explicit statement about the normative nature of the schema, and that any explanatory text is not normative. I routinely put such statements in "overview of operations" sections, which are not written with RFC2119-strentgh terms. -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 Jul 2 07:03: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 HAA27950 for ; Fri, 2 Jul 2004 07:03: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 1BgLp8-00059p-0Q for simple-archive@ietf.org; Fri, 02 Jul 2004 07:03:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgLoC-0004nl-00 for simple-archive@ietf.org; Fri, 02 Jul 2004 07:02:21 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BgLnL-000489-00; Fri, 02 Jul 2004 07:01:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgLYi-0004Ow-6J; Fri, 02 Jul 2004 06:46:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgLRz-0000wt-Oa for simple@megatron.ietf.org; Fri, 02 Jul 2004 06:39: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 GAA26909 for ; Fri, 2 Jul 2004 06:39: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 1BgLRx-0004T6-6g for simple@ietf.org; Fri, 02 Jul 2004 06:39:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgLQz-00046u-00 for simple@ietf.org; Fri, 02 Jul 2004 06:38:22 -0400 Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx with esmtp (Exim 4.12) id 1BgLQF-0003kg-00 for simple@ietf.org; Fri, 02 Jul 2004 06:37: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 i62AbaAh000333 for ; Fri, 2 Jul 2004 12:37:36 +0200 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Fri, 2 Jul 2004 12:37:36 +0200 Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Fri, 2 Jul 2004 12:37:36 +0200 Message-ID: <342C4681F0D4A04CA50A97D74DA8FB9A0C0AC7AA@esealnt875.al.sw.ericsson.se> From: "Henrik Albertsson (KI/EAB)" To: "'Miguel Garcia'" , ext Jonathan Rosenberg Date: Fri, 2 Jul 2004 12:37:31 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 02 Jul 2004 10:37:36.0507 (UTC) FILETIME=[9731F4B0:01C46020] Cc: simple@ietf.org Subject: [Simple] RE: XCAP Directory: Large response ? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org 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 agree with you Miguel that the "give me X byte" solution is not usable for the reasons you mentioned. However most likely the XCAP client will operate on a well known AUDI and have knowledge about what the structure of the XCAP document is so it can roughly estimate what size 30 elements would be. Is it so that when specifying a XCAP document we also need to define what element will be used for indexing when asking for a range of elements? Regards /Henrik > -----Original Message----- > From: Miguel Garcia [mailto:Miguel.An.Garcia@nokia.com] > Sent: den 2 juli 2004 12:14 > To: ext Jonathan Rosenberg > Cc: Henrik Albertsson (KI/EAB); simple@ietf.org > Subject: Re: XCAP Directory: Large response ? > > > Jonathan Rosenberg wrote: > > > > > I would propose that we not put this functionality in xcap > itself, but > > use the existing HTTP mechanisms. I will note that these > mechanisms are > > *byte* oriented, and not XML oriented. Thus, you may cut an > element off > > in the middle by asking for the first 50 bytes. However, if > your main > > concern is bandwidth or latency, then bytes are much more > significant of > > a measure than elements. If I say, "give me 30 elements", > that could be > > 30 bytes or 30MB, depennding on the amount of data in each element. > > > > -Jonathan R. > > > > Jonathan, I think the HTTP byte ranges will not work. Let's say I > request a long document, and I request bytes 1 to 10000. The > HTTP server > will cut the XML document exacltly when the number of bytes > has reached > the count, and will send it to the XCAP client. The XCAP client can't > check if the document is well-formed, not even check if it is valid > according to the XML schema. As a consequence, it won't display it to > the user, or dare to do any operation on it. The only thing the XCAP > client can do is to request the next byte range. > > I am concerned with the limited amount of memory a device might have, > AND the bandwidth. The latter can be solved with byte ranges, but not > the former. > > However, if we provide a mechanism to request ranges of entries in a > list, this will solve the problem: the XCAP server create a valid XML > document that complies with the schema and send it to the > XCAP client. > The client can request additional ranges once it has freed > the memory. > The drawback is that we cannot accurately control the bandwidth (we > don't know how many bytes will come), but I don't think this > is a big issue. > > - 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 Fri Jul 2 07: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 HAA28097 for ; Fri, 2 Jul 2004 07: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 1BgLss-0006WX-DM for simple-archive@ietf.org; Fri, 02 Jul 2004 07:07:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgLrp-0006BW-00 for simple-archive@ietf.org; Fri, 02 Jul 2004 07:06:06 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BgLqs-0005Wd-00; Fri, 02 Jul 2004 07:05:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgLnZ-0001Um-5F; Fri, 02 Jul 2004 07:01:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgLYn-0004P2-TB for simple@megatron.ietf.org; Fri, 02 Jul 2004 06:46: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 GAA27249 for ; Fri, 2 Jul 2004 06:46: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 1BgLYl-00071S-G2 for simple@ietf.org; Fri, 02 Jul 2004 06:46:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgLXn-0006fL-00 for simple@ietf.org; Fri, 02 Jul 2004 06:45:24 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1BgLX1-0006JQ-00 for simple@ietf.org; Fri, 02 Jul 2004 06:44:36 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i62AiSJ13275; Fri, 2 Jul 2004 13:44:28 +0300 (EET DST) X-Scanned: Fri, 2 Jul 2004 13:44: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 i62AiRkY000627; Fri, 2 Jul 2004 13:44:27 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00cFXUbb; Fri, 02 Jul 2004 13:44: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 i62AiOH00231; Fri, 2 Jul 2004 13:44:24 +0300 (EET DST) Received: from nokia.com ([172.21.42.108]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 2 Jul 2004 13:44:20 +0300 Message-ID: <40E53C84.4070703@nokia.com> Date: Fri, 02 Jul 2004 13:44:20 +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] Double specification: text and schema References: <5.1.0.14.0.20040701110539.023d8090@localhost> <40E50CA8.2050100@nokia.com> <40E53788.8020404@dynamicsoft.com> In-Reply-To: <40E53788.8020404@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Jul 2004 10:44:20.0834 (UTC) FILETIME=[88315C20:01C46021] Content-Transfer-Encoding: 7bit Cc: "Joel M. Halpern" , SIMPLE mailing list X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org 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: > > > Miguel Garcia wrote: > >> Hi Joel: >> >> I don't agree with you. We can't avoid the XML schema. I believe you >> agree with me. >> >> Since the XML schema already needs to indicate whether an element or >> attribute is mandatory or not, there is no point in repeating the same >> information in the text. What for? > > > I think that it can be useful for purposes of clarification. I would > advise using non-normative terminology in the text. So, for example: > > "The element includes a single mandatory attribute, "bar", and > always has two children, and ..." > > I think it also makes sense to have an explicit statement about the > normative nature of the schema, and that any explanatory text is not > normative. I routinely put such statements in "overview of operations" > sections, which are not written with RFC2119-strentgh terms. > > -Jonathan R. > As long as we don't use normative statements in the text, it is fine to me. I would go one step further to avoid the words "mandatory" and "optional" in the text, but I would accept Jonathan's proposal. I also like the idea to stress that the XML schema is normative (in case someone didn't realize yet). - 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 Fri Jul 2 07:17: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 HAA28537 for ; Fri, 2 Jul 2004 07:17: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 1BgM2X-0002Hy-OR for simple-archive@ietf.org; Fri, 02 Jul 2004 07:17:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgM1c-0001vt-00 for simple-archive@ietf.org; Fri, 02 Jul 2004 07:16:13 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BgM0a-0001HE-00; Fri, 02 Jul 2004 07:15:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgLxy-0005Hd-66; Fri, 02 Jul 2004 07:12:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgLru-0002v0-PE for simple@megatron.ietf.org; Fri, 02 Jul 2004 07:06: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 HAA28076 for ; Fri, 2 Jul 2004 07:06: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 1BgLrs-0006Bq-EY for simple@ietf.org; Fri, 02 Jul 2004 07:06:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgLr0-0005qE-00 for simple@ietf.org; Fri, 02 Jul 2004 07:05:15 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BgLps-0005Ab-00 for simple@ietf.org; Fri, 02 Jul 2004 07:04:04 -0400 Received: from dynamicsoft.com ([63.113.46.29]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i62B3nbo004767; Fri, 2 Jul 2004 07:03:50 -0400 (EDT) Message-ID: <40E54102.9090803@dynamicsoft.com> Date: Fri, 02 Jul 2004 07:03: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: Jari Urpalainen 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> <40E30A07.6090407@nokia.com> In-Reply-To: <40E30A07.6090407@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. Jari Urpalainen wrote: >> >>> >>> 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. Yes, you need error checking. This request must generate a 409. My point was, it is very easy to check for this condition *before* you go and do the insert. You just look at the attribute selector in the r-uri (@a="bar") and make sure it matches the attributes of the element in the body of the request. > > This will happen also with attribute updates like > put .../foo[@a="bar"]/@a with content "foobar" Right, good point. This check needs to happen too. > >>> 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. My point was, with the multiple-inserts technique, it is only allowing insertions; you can't also do a delete somewhere in there, and have the whole operation locked. That would require proper database-style locking mechanisms. Let me make a proposal. Lets keep multiple inserts out of the base spec. I will writeup the multiple inserts as an extension to xcap. Xcap base will have a basic capability discovery mechanism, allowing you to check what xcap extensions are supported by the server. The client can then figure out whether or not it can do the multiple inserts or not. The group can then debate the multiple-inserts feature separately as an extension. All clients would need to be able to operate against servers that didnt do multiple inserts. Is that OK? -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 Jul 2 07:20: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 HAA28683 for ; Fri, 2 Jul 2004 07:20: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 1BgM5U-0003Kr-FO for simple-archive@ietf.org; Fri, 02 Jul 2004 07:20:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgM4U-0002zT-00 for simple-archive@ietf.org; Fri, 02 Jul 2004 07:19:10 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BgM3g-0002KH-00; Fri, 02 Jul 2004 07: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 1BgLy2-0005Kl-1a; Fri, 02 Jul 2004 07:12:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgLsx-0003DY-KV for simple@megatron.ietf.org; Fri, 02 Jul 2004 07:07: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 HAA28121 for ; Fri, 2 Jul 2004 07:07: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 1BgLsv-0006Wu-1e for simple@ietf.org; Fri, 02 Jul 2004 07:07:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgLrt-0006CA-00 for simple@ietf.org; Fri, 02 Jul 2004 07:06:10 -0400 Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx with esmtp (Exim 4.12) id 1BgLrA-0005Wh-00 for simple@ietf.org; Fri, 02 Jul 2004 07:05:24 -0400 Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id i62B4rj0004393 for ; Fri, 2 Jul 2004 06:04:54 -0500 (CDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Fri, 2 Jul 2004 12:04:53 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB00C29013B@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'Jonathan Rosenberg'" , Miguel Garcia Subject: RE: [Simple] Double specification: text and schema Date: Fri, 2 Jul 2004 12:04:51 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Cc: "Joel M. Halpern" , SIMPLE mailing list X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org 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 This can be carried to extremes that create major problems, and I would support Jonathan to the extent that he has written below, but would not take this as license to add informative and descriptive material without further purpose. The main purpose of RFCs (of the type we are talking about) is to carry the normative requirements. Informative material is to support and explain those normative requirements. I see little point in a complete informative description of something that is correctly and appropriately defined in a normative fashion elsewhere. I have no problem with such duplicating informative statements that set the context for a normative requirement, thus, for example: "All messages contain foo. The sender MUST set the contents of foo to xxxx." but "All messages contain foo." with no further requirement should not occur. I believe that this is much as Miguel originally proposed. Additionally I have no problem with the reiteration of the normal rules regarding treatment of the MUST, SHOULD etc words when they appear, and there should definitely be a MUST associated with any XML or BNF specification. But I disagree with Joel's proposal to insert sentences that state when an RFC is in conflict with itself one clause has priority over another. Previous experience leads me to the conclusion that where such statements appear, when the standards organisation actually gets round to fixing the specification, the solution follows the lower priority documentation. Internal conflicts in specifications should always be treated as an error in the specification and appropriately fixed. regards Keith > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: 02 July 2004 11:23 > To: Miguel Garcia > Cc: Joel M. Halpern; SIMPLE mailing list > Subject: Re: [Simple] Double specification: text and schema > > > > > Miguel Garcia wrote: > > > Hi Joel: > > > > I don't agree with you. We can't avoid the XML schema. I > believe you > > agree with me. > > > > Since the XML schema already needs to indicate whether an > element or > > attribute is mandatory or not, there is no point in > repeating the same > > information in the text. What for? > > I think that it can be useful for purposes of clarification. I would > advise using non-normative terminology in the text. So, for example: > > "The element includes a single mandatory attribute, "bar", and > always has two children, and ..." > > I think it also makes sense to have an explicit statement about the > normative nature of the schema, and that any explanatory text is not > normative. I routinely put such statements in "overview of > operations" > sections, which are not written with RFC2119-strentgh terms. > > -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 Jul 2 07:43: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 HAA29483 for ; Fri, 2 Jul 2004 07:43: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 1BgMS3-0003Q5-WB for simple-archive@ietf.org; Fri, 02 Jul 2004 07:43:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgMR3-00033y-00 for simple-archive@ietf.org; Fri, 02 Jul 2004 07:42:30 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BgMQS-0002hw-00; Fri, 02 Jul 2004 07:41:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgMFm-0003aF-Uo; Fri, 02 Jul 2004 07:30:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgM6d-0000Ui-9a for simple@megatron.ietf.org; Fri, 02 Jul 2004 07:21: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 HAA28749 for ; Fri, 2 Jul 2004 07:21: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 1BgM6c-0003h2-Ob for simple@ietf.org; Fri, 02 Jul 2004 07:21:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgM5Z-0003LZ-00 for simple@ietf.org; Fri, 02 Jul 2004 07:20:18 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1BgM4r-00030n-00 for simple@ietf.org; Fri, 02 Jul 2004 07:19:33 -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 i62BJQ206561; Fri, 2 Jul 2004 14:19:26 +0300 (EET DST) X-Scanned: Fri, 2 Jul 2004 14:19:22 +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 i62BJMlP010661; Fri, 2 Jul 2004 14:19:22 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00ncohgw; Fri, 02 Jul 2004 14:19:04 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 i62BJ3H01347; Fri, 2 Jul 2004 14:19:03 +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, 2 Jul 2004 14:19:02 +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 5 Interim Summary: selecting multiple elements x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Date: Fri, 2 Jul 2004 14:19:02 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7023EEA9B@esebe019.ntc.nokia.com> Thread-Topic: [Simple] XCAP Issue 5 Interim Summary: selecting multiple elements Thread-Index: AcRgJhgxT55n94SOR7WRdmN74KjEgAAAD+WQ To: , X-OriginalArrivalTime: 02 Jul 2004 11:19:02.0617 (UTC) FILETIME=[61083C90:01C46026] 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: 02.July.2004 14:04 > To: Urpalainen Jari (Nokia-NRC/Helsinki) > Cc: Simple WG > Subject: Re: [Simple] XCAP Issue 5 Interim Summary: selecting multiple > elements >=20 >=20 > inline. >=20 > Jari Urpalainen wrote: >=20 > >> > >>> > >>> Jonathan, I have still this question in another thread, where > >>> idempotency is easily broken during replace (or modify)=20 > with single > >>> nodes too.=20 > >> > >> > >> > >> 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=3D"bar"] and with new content .=20 > So we would=20 > > find a single node and would replace the foo-node with new=20 > content and=20 > > therefore you can't get this new content with the same=20 > r-uri anymore. Of=20 > > course this can be avoided with a request like .../foo[1].=20 > The bad thing=20 > > here is that the request looks ok (unambiguous) but it is=20 > not idempotent=20 > > and you really need error-checking in the server. >=20 > Yes, you need error checking. This request must generate a=20 > 409. My point=20 > was, it is very easy to check for this condition *before* you=20 > go and do=20 > the insert. You just look at the attribute selector in the r-uri=20 > (@a=3D"bar") and make sure it matches the attributes of the=20 > element in the=20 > body of the request. >=20 > >=20 > > This will happen also with attribute updates like > > put .../foo[@a=3D"bar"]/@a with content "foobar" >=20 > Right, good point. This check needs to happen too. >=20 > >=20 > >>> Btw. could someonce explain how DELETE can be idempotent > >>> (rfc2616) ? > >> > >> > >> > >> Its a mystery to me. The second DELETE will generate a=20 > 404, since the=20 > >> previous one did a good job of deleting the resource. > >> > >>>> HTTP PUT operations. So long as you don't need the etag=20 > from the=3D20 > >>>> previous operation, this would work. Its bandwidth overhead is=20 > >>>> almost=3D20 > >>>> the same as multiple insertions that we've been=20 > proposing, and the=3D20 > >>>> latency is just about the same thing too. > >>>> =3D20 > >>> > >>> > >>> > >>> > >>> I'd rather say that pipelining could work in some cases,=20 > but it is NOT a > >>> solution for doing atomic conditional=20 > multi-insertions/deletions which I > >>> still would like to see in XCAP.=3D20 > >> > >> > >> > >> Well, again it comes back to what xcap is trying to do. It is not=20 > >> meant to be a general XML database protocol. I think its a=20 > feature of=20 > >> the design that it can be pushed towards that by adding=20 > features like=20 > >> multiple-inserts, but really its not our goal. > >> > >> Also, I'll note that if you want a sequence of insertions AND=20 > >> deletions to be done atomically, you can't do that with the=20 > >> multiple-inserts appraoch, since that only works with a=20 > single PUT (no=20 > >> DELETE). Thus, you would need proper transaction semantics=20 > that allow=20 > >> you to lock the document, make a bunch of changes, and=20 > cancel/rollback=20 > >> or commit when done, and that is, I think, well beyond=20 > what we want here. > >> > > I am not fully following here. In my implementation I will=20 > effectively=20 > > do a locking for the resource before doing any=20 > xml-operations, because=20 > > simultaneous requests (multithreaded implementation) would=20 > crash the=20 > > whole system. So with multi-inserts also the lock is held=20 > between all=20 > > the requests, which will be applied sequentially one by=20 > one. After this=20 > > adding some additional checking is needed to fulfil an unambiguos=20 > > request, first I'll check that I will still find the same=20 > nodes that I=20 > > inserted and if that is satisfied I'll check that nodes are not=20 > > related. To me this looks still very simple and is also trivial to=20 > > implement. >=20 > My point was, with the multiple-inserts technique, it is only=20 > allowing=20 > insertions; you can't also do a delete somewhere in there,=20 > and have the=20 > whole operation locked. That would require proper=20 > database-style locking=20 > mechanisms. >=20 > Let me make a proposal. Lets keep multiple inserts out of the=20 > base spec.=20 > I will writeup the multiple inserts as an extension to xcap.=20 > Xcap base=20 > will have a basic capability discovery mechanism, allowing=20 > you to check=20 > what xcap extensions are supported by the server. The client can then=20 > figure out whether or not it can do the multiple inserts or not. The=20 > group can then debate the multiple-inserts feature separately as an=20 > extension. All clients would need to be able to operate=20 > against servers=20 > that didnt do multiple inserts. >=20 > Is that OK? OK for me. /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 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jul 2 08:55: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 IAA02719 for ; Fri, 2 Jul 2004 08:55: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 1BgNZQ-0004QX-S5 for simple-archive@ietf.org; Fri, 02 Jul 2004 08:55:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgNYR-00044X-00 for simple-archive@ietf.org; Fri, 02 Jul 2004 08:54:11 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BgNXM-0003RA-00; Fri, 02 Jul 2004 08:53:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgNBK-0000to-1M; Fri, 02 Jul 2004 08:30:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgN5P-0006gR-Le for simple@megatron.ietf.org; Fri, 02 Jul 2004 08:24: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 IAA01619 for ; Fri, 2 Jul 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 1BgN5P-0001fc-4N for simple@ietf.org; Fri, 02 Jul 2004 08:24:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgN4S-0001MW-00 for simple@ietf.org; Fri, 02 Jul 2004 08:23:13 -0400 Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1BgN40-00013K-00 for simple@ietf.org; Fri, 02 Jul 2004 08:22:44 -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 i62CMhPA020103 for ; Fri, 2 Jul 2004 14:22:43 +0200 (MEST) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Fri, 2 Jul 2004 14:22:43 +0200 Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Fri, 2 Jul 2004 14:22:38 +0200 Message-ID: From: "Anders Lindgren C (HF/EAB)" To: "'hisham.khartabil@nokia.com'" , simple@ietf.org Date: Fri, 2 Jul 2004 14:22:35 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 02 Jul 2004 12:22:43.0681 (UTC) FILETIME=[46905510:01C4602F] Subject: [Simple] RE: simple-filter Max Size or Max number of element as filter cri terias? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org 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 Hi The question is what "unwanted" information" mean? Can it be that a XML document that is to large to handle can be regarded as "unwanted" information and therefore can be regarded as being inside the scope of the simple-filter draft. Regards Anders -----Original Message----- From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] Sent: den 2 juli 2004 10:07 To: Anders Lindgren C (HF/EAB); simple@ietf.org Subject: RE: simple-filter Max Size or Max number of element as filter criterias? I believe that you are asking for is outside the scope of the simple-filter drafts. It can be done with filters, but not those ones. The current filter drafts talk about filtering unwanted or uninteresting information sent in a NOTIFY. They also talk about triggering of notifications when certain changes to the state of an event occur. Regards, Hisham > -----Original Message----- > From: ext Anders Lindgren C (HF/EAB) > [mailto:anders.c.lindgren@ericsson.com] > Sent: 02.July.2004 10:53 > To: simple@ietf.org; Khartabil Hisham (Nokia-TP-MSW/Helsinki) > Subject: simple-filter Max Size or Max number of element as filter > criterias? > > > Hi, > The XML documents sent from the network to the client can be > very large or it can contains a very long sequence of > elements ( e.g a resource list with 1000 buddies) > It will also exist different types of clients. Some clients > can specify a very large resource list and it will exist > clients that can not handle that large list. > > I have not found how a client can inform the network about > how large documents is can handle or how many elements of a > certain type it can handle. > My question is now if this information can be regarded as > filter criterias and includes in this filter specification? > > Best regards > > Anders Lindgren Ericsson AB Sweden > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jul 2 09: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 JAA03496 for ; Fri, 2 Jul 2004 09: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 1BgNkT-0000fr-Tw for simple-archive@ietf.org; Fri, 02 Jul 2004 09:06:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgNjY-0000Jn-00 for simple-archive@ietf.org; Fri, 02 Jul 2004 09:05:41 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BgNim-0007hU-00; Fri, 02 Jul 2004 09:04:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgNXs-00016v-Bj; Fri, 02 Jul 2004 08:53:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgNMr-0004vG-Is for simple@megatron.ietf.org; Fri, 02 Jul 2004 08:42: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 IAA02260 for ; Fri, 2 Jul 2004 08:42:11 -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 1BgNMq-00007i-UY for simple@ietf.org; Fri, 02 Jul 2004 08:42:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgNLr-0007ZW-00 for simple@ietf.org; Fri, 02 Jul 2004 08:41:12 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1BgNKt-0007DG-00 for simple@ietf.org; Fri, 02 Jul 2004 08:40:11 -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 i62Ce9214267; Fri, 2 Jul 2004 15:40:09 +0300 (EET DST) X-Scanned: Fri, 2 Jul 2004 15:40:02 +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 i62Ce2NG001501; Fri, 2 Jul 2004 15:40:02 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00zoeh2U; Fri, 02 Jul 2004 15:40:00 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 i62CdxH11628; Fri, 2 Jul 2004 15:39:59 +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); Fri, 2 Jul 2004 15:39:58 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Date: Fri, 2 Jul 2004 15:39:55 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7023EEA9C@esebe019.ntc.nokia.com> Thread-Topic: simple-filter Max Size or Max number of element as filter criterias? Thread-Index: AcRgL45zq59jXNfsS/iXMFxmY1NMhwAAa1AA To: , X-OriginalArrivalTime: 02 Jul 2004 12:39:58.0696 (UTC) FILETIME=[AF7B1680:01C46031] Content-Transfer-Encoding: quoted-printable Subject: [Simple] RE: simple-filter Max Size or Max number of element as filter criterias? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org 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 You can reduce the size of the document delivered in the NOTIFY by using = the filters (but selecting the elements that you really want to be = delivered to you), but you cannot filter based on size. You cannot say = "send me a NOTIFY with a body no larger than 1000 bytes". If you want something like that, then this is outside the scope of the = filtering drafts in question. Regards, Hisham > -----Original Message----- > From: ext Anders Lindgren C (HF/EAB) > [mailto:anders.c.lindgren@ericsson.com] > Sent: 02.July.2004 15:23 > To: Khartabil Hisham (Nokia-TP-MSW/Helsinki); simple@ietf.org > Subject: RE: simple-filter Max Size or Max number of element as filter > criterias? >=20 >=20 > Hi > The question is what "unwanted" information" mean? Can it be=20 > that a XML document that is to large to handle can be=20 > regarded as "unwanted" information and therefore can be=20 > regarded as being inside the scope of the simple-filter draft. > Regards > Anders >=20 > -----Original Message----- > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > Sent: den 2 juli 2004 10:07 > To: Anders Lindgren C (HF/EAB); simple@ietf.org > Subject: RE: simple-filter Max Size or Max number of element as filter > criterias? >=20 >=20 > I believe that you are asking for is outside the scope of the=20 > simple-filter drafts. It can be done with filters, but not those ones. >=20 > The current filter drafts talk about filtering unwanted or=20 > uninteresting information sent in a NOTIFY. They also talk=20 > about triggering of notifications when certain changes to the=20 > state of an event occur. >=20 > Regards, > Hisham >=20 > > -----Original Message----- > > From: ext Anders Lindgren C (HF/EAB) > > [mailto:anders.c.lindgren@ericsson.com] > > Sent: 02.July.2004 10:53 > > To: simple@ietf.org; Khartabil Hisham (Nokia-TP-MSW/Helsinki) > > Subject: simple-filter Max Size or Max number of element as filter > > criterias? > >=20 > >=20 > > Hi, > > The XML documents sent from the network to the client can be=20 > > very large or it can contains a very long sequence of=20 > > elements ( e.g a resource list with 1000 buddies) > > It will also exist different types of clients. Some clients=20 > > can specify a very large resource list and it will exist=20 > > clients that can not handle that large list. > >=20 > > I have not found how a client can inform the network about=20 > > how large documents is can handle or how many elements of a=20 > > certain type it can handle. > > My question is now if this information can be regarded as=20 > > filter criterias and includes in this filter specification? > >=20 > > Best regards > >=20 > > Anders Lindgren Ericsson AB Sweden > >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jul 2 09:09: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 JAA03642 for ; Fri, 2 Jul 2004 09:09: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 1BgNn7-0001i1-RW for simple-archive@ietf.org; Fri, 02 Jul 2004 09:09:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgNmC-0001Lo-00 for simple-archive@ietf.org; Fri, 02 Jul 2004 09:08:25 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BgNlK-0000gP-00; Fri, 02 Jul 2004 09:07:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgNYP-0001NV-2t; Fri, 02 Jul 2004 08:54:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgNTk-0007ak-69 for simple@megatron.ietf.org; Fri, 02 Jul 2004 08:49:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02579 for ; Fri, 2 Jul 2004 08:49: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 1BgNTj-0002UF-Jc for simple@ietf.org; Fri, 02 Jul 2004 08:49:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgNSo-0002Ad-00 for simple@ietf.org; Fri, 02 Jul 2004 08:48:23 -0400 Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx with esmtp (Exim 4.12) id 1BgNSM-0001qA-00 for simple@ietf.org; Fri, 02 Jul 2004 08:47:54 -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 i62ClNou002525; Fri, 2 Jul 2004 07:47:23 -0500 (CDT) Received: by eamrcnt750.exu.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Fri, 2 Jul 2004 07:46:20 -0500 Message-ID: From: "George Foti (QA/EMC)" To: "Henrik Albertsson (KI/EAB)" , "'Miguel Garcia'" , ext Jonathan Rosenberg Subject: RE: [Simple] RE: XCAP Directory: Large response ? Date: Fri, 2 Jul 2004 07:39:09 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) 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.1 required=5.0 tests=AWL autolearn=no version=2.60 A potential solution is for a client to be able to ask either of the following questions: 1) Give me a *maximum* of X bytes ranges Z onwards 2) Give me a *maximum* of X bytes ranges Y-Z The XCAP server should return in a successfull response an XML document that is schema compliant that does not exceed the *maximum* range. The client can then perform operations on such a document. A request could fail for multiple reasons, no document meets the maximum length, server does not understand the schema, etcc.. The above implies that XCAP servers must understand different schemas, but that may be unavoidable for some operations. The other thing, I dont know if HTTP headers do allow for the above. Rgds/gf > -----Original Message----- > From: simple-bounces@ietf.org > [mailto:simple-bounces@ietf.org]On Behalf > Of Henrik Albertsson (KI/EAB) > Sent: Friday, July 02, 2004 6:38 AM > To: 'Miguel Garcia'; ext Jonathan Rosenberg > Cc: simple@ietf.org > Subject: [Simple] RE: XCAP Directory: Large response ? > > > I agree with you Miguel that the "give me X byte" solution is > not usable for the reasons you mentioned. However most likely > the XCAP client will operate on a well known AUDI and have > knowledge about what the structure of the XCAP document is so > it can roughly estimate what size 30 elements would be. > > Is it so that when specifying a XCAP document we also need to > define what element will be used for indexing when asking for > a range of elements? > > Regards > /Henrik > > > > > -----Original Message----- > > From: Miguel Garcia [mailto:Miguel.An.Garcia@nokia.com] > > Sent: den 2 juli 2004 12:14 > > To: ext Jonathan Rosenberg > > Cc: Henrik Albertsson (KI/EAB); simple@ietf.org > > Subject: Re: XCAP Directory: Large response ? > > > > > > Jonathan Rosenberg wrote: > > > > > > > > I would propose that we not put this functionality in xcap > > itself, but > > > use the existing HTTP mechanisms. I will note that these > > mechanisms are > > > *byte* oriented, and not XML oriented. Thus, you may cut an > > element off > > > in the middle by asking for the first 50 bytes. However, if > > your main > > > concern is bandwidth or latency, then bytes are much more > > significant of > > > a measure than elements. If I say, "give me 30 elements", > > that could be > > > 30 bytes or 30MB, depennding on the amount of data in > each element. > > > > > > -Jonathan R. > > > > > > > Jonathan, I think the HTTP byte ranges will not work. Let's say I > > request a long document, and I request bytes 1 to 10000. The > > HTTP server > > will cut the XML document exacltly when the number of bytes > > has reached > > the count, and will send it to the XCAP client. The XCAP > client can't > > check if the document is well-formed, not even check if it is valid > > according to the XML schema. As a consequence, it won't > display it to > > the user, or dare to do any operation on it. The only thing > the XCAP > > client can do is to request the next byte range. > > > > I am concerned with the limited amount of memory a device > might have, > > AND the bandwidth. The latter can be solved with byte > ranges, but not > > the former. > > > > However, if we provide a mechanism to request ranges of > entries in a > > list, this will solve the problem: the XCAP server create a > valid XML > > document that complies with the schema and send it to the > > XCAP client. > > The client can request additional ranges once it has freed > > the memory. > > The drawback is that we cannot accurately control the bandwidth (we > > don't know how many bytes will come), but I don't think this > > is a big issue. > > > > - 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 > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jul 2 09:25: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 JAA04456 for ; Fri, 2 Jul 2004 09:25: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 1BgO2b-0007Cd-72 for simple-archive@ietf.org; Fri, 02 Jul 2004 09:25:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgO0s-0006Z9-00 for simple-archive@ietf.org; Fri, 02 Jul 2004 09:23:35 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BgNzp-0006B7-02; Fri, 02 Jul 2004 09:22:29 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BgNvg-00009x-Nx; Fri, 02 Jul 2004 09:18:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgNlc-0006a4-Nv; Fri, 02 Jul 2004 09:07:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgNbc-0002bj-IH for simple@megatron.ietf.org; Fri, 02 Jul 2004 08:57: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 IAA02900 for ; Fri, 2 Jul 2004 08:57: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 1BgNbb-0005Ba-VN for simple@ietf.org; Fri, 02 Jul 2004 08:57:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgNao-0004qV-00 for simple@ietf.org; Fri, 02 Jul 2004 08:56:39 -0400 Received: from ns.execdsl.net ([208.184.15.238] helo=EXECDSL.COM) by ietf-mx with esmtp (Exim 4.12) id 1BgNZp-0004Sf-00 for simple@ietf.org; Fri, 02 Jul 2004 08:55:37 -0400 Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 7139255; Fri, 02 Jul 2004 08:55:26 -0400 Message-Id: <5.1.0.14.0.20040702084852.02276b38@localhost> X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 02 Jul 2004 08:55:05 -0400 To: Miguel Garcia From: "Joel M. Halpern" Subject: Re: [Simple] Double specification: text and schema In-Reply-To: <40E50CA8.2050100@nokia.com> References: <5.1.0.14.0.20040701110539.023d8090@localhost> <5.1.0.14.0.20040701110539.023d8090@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: SIMPLE mailing list X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org 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 From my view of history and pragmatics: 1) This is not a new problem. Many standards bodies have had this problem for a long time. The consistent answer has not been that whatever is formally specified should not be described in normative language in text. 2) For human being reading the text it is very helpful to comprehension if the text says exactly what is required and permitted. Sure, when it comes to final implementation the formal specification is the absolute rule. But human beings can find it hard to understand exactly what is meant by the formal spec. 3) If one leaves out the requirements for uniqueness, number of occurrences, and other properties from the english text, then one has an english portion that is likely misleading and frequently wrong. The practice of recognizing duplicative specification, and indicating which portion over-rides is long established and works. Why would we suddenly do something different. As far as I can tell, even the W3C follows this rule, with english text explaining the meaning, cardinalities, uniqueness, and other requirements for documents which are also specified by XML Schema. Yours, Joel M. Halpern At 10:20 AM 7/2/2004 +0300, Miguel Garcia wrote: >Hi Joel: > >I don't agree with you. We can't avoid the XML schema. I believe you agree >with me. > >Since the XML schema already needs to indicate whether an element or >attribute is mandatory or not, there is no point in repeating the same >information in the text. What for? > >If you are implementing the draft, you need to implement the XML schema. >If you just look at the text, then we will have interoperability problems. > >If you are just a curious reader, then you most likely don't look at the >XML schema, but you don't care whether an element MUST be present or MAY >be present (and if you care, look at the XML schema). You most likely care >about the existence of an element. > >Therefore, I don't support having a disclaimer like: "we try to have 100% >quality in this document, but if we didn't achieve 100% quality, the XML >shema takes precedence". > >- Miguel > >Joel M. Halpern wrote: > >>I would agree that this can be a problem. >>I would like to phrase the solution differently. (I am not sure whether >>I am disagreeing with Miguel's proposal or not.) >>While I like reading the schema, I really want the text to be clear and >>sufficiently precise. Hence, I would prefer not to weaken the use of >>MUST, etc. in the text. >>Rather, I would suggest that we simply state in a paragraph in the >>introduction, after the citation for the terms MUST, SHOULD, ... that in >>the case of conflict between the text and the XML schema, any >>requirements or prohibitions defined in the schema take precedence over >>conflicting text. >>Yours, >>Joel M. Halpern >>At 02:10 PM 7/1/2004 +0300, Miguel Garcia wrote: >> >>>The problem: We have two normative statements (one in the text, another >>>in the XML schema) indicating the same thing. This is not a big problem >>>as long as both statements indicate the same thing. But what happens if >>>the document evolves, and then we it is decided to make mandatory some >>>attribute that previously was optional, and what happen if the change is >>>reflected only in the textual form and not in the schema; or vice versa. >>>Then we run into trouble. >>> >>>Therefore, I would like to propose that, in the sake of interoperability >>>of implementations, documents indicating XML schemas MUST specify the >>>normative part as much as possible in the XML schema definition. Only >>>those bits that cannot be specified in the schema MUST be specified in >>>the text. > >-- >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 Fri Jul 2 09: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 JAA04849 for ; Fri, 2 Jul 2004 09: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 1BgO5Q-0000gz-QC for simple-archive@ietf.org; Fri, 02 Jul 2004 09:28:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgO3b-0007ke-00 for simple-archive@ietf.org; Fri, 02 Jul 2004 09:26:24 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BgO1l-0006kK-00; Fri, 02 Jul 2004 09:24:29 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BgO1l-0000LR-K9; Fri, 02 Jul 2004 09: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 1BgNtT-0002D8-P6; Fri, 02 Jul 2004 09:15:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgNgF-0004Lu-St for simple@megatron.ietf.org; Fri, 02 Jul 2004 09:02: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 JAA03095 for ; Fri, 2 Jul 2004 09:02: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 1BgNgF-0006vj-AL for simple@ietf.org; Fri, 02 Jul 2004 09:02:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgNfM-0006Zi-00 for simple@ietf.org; Fri, 02 Jul 2004 09:01:21 -0400 Received: from ns.execdsl.net ([208.184.15.238] helo=EXECDSL.COM) by ietf-mx with esmtp (Exim 4.12) id 1BgNeO-0006Cj-00 for simple@ietf.org; Fri, 02 Jul 2004 09:00:21 -0400 Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 7139277; Fri, 02 Jul 2004 09:00:20 -0400 Message-Id: <5.1.0.14.0.20040702085730.023c3fe0@localhost> X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 02 Jul 2004 09:00:00 -0400 To: Jonathan Rosenberg , Miguel Garcia From: "Joel M. Halpern" Subject: Re: [Simple] Double specification: text and schema In-Reply-To: <40E53788.8020404@dynamicsoft.com> References: <40E50CA8.2050100@nokia.com> <5.1.0.14.0.20040701110539.023d8090@localhost> <40E50CA8.2050100@nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: SIMPLE mailing list X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org 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 Part of what I am trying to avoid is telling authors that they must be extra careful never to use MUST words about things described in the schema. In a typical text description there will be explanatory text, there will be explanation of requirements that are also in the schema, and there will be explanation of requirements that are not in the schema. (Occasionally one gets lucky and the last category is empty.) As an author, I really don't want to have to try to change style from sentence to sentence in a section depending upon whether or not the particular behavior I am describing also occurs in the schema. Also, as I reader I would like to see a complete description in the text. Yours, Joel M. Halpern At 06:23 AM 7/2/2004 -0400, Jonathan Rosenberg wrote: >Miguel Garcia wrote: > >>Hi Joel: >>I don't agree with you. We can't avoid the XML schema. I believe you >>agree with me. >>Since the XML schema already needs to indicate whether an element or >>attribute is mandatory or not, there is no point in repeating the same >>information in the text. What for? > >I think that it can be useful for purposes of clarification. I would >advise using non-normative terminology in the text. So, for example: > >"The element includes a single mandatory attribute, "bar", and >always has two children, and ..." > >I think it also makes sense to have an explicit statement about the >normative nature of the schema, and that any explanatory text is not >normative. I routinely put such statements in "overview of operations" >sections, which are not written with RFC2119-strentgh terms. > >-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 Jul 2 09:29: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 JAA05099 for ; Fri, 2 Jul 2004 09:29: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 1BgO6i-0001MJ-Es for simple-archive@ietf.org; Fri, 02 Jul 2004 09:29:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgO5I-0000ds-00 for simple-archive@ietf.org; Fri, 02 Jul 2004 09:28:09 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BgO3Y-0007jP-00; Fri, 02 Jul 2004 09:26:20 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BgO3Y-0000Qj-73; Fri, 02 Jul 2004 09:26:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgNwe-0003Zc-It; Fri, 02 Jul 2004 09:19:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgNm9-0006iT-FK for simple@megatron.ietf.org; Fri, 02 Jul 2004 09:08: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 JAA03606 for ; Fri, 2 Jul 2004 09:08: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 1BgNm8-0001LK-O9 for simple@ietf.org; Fri, 02 Jul 2004 09:08:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgNlB-00010E-00 for simple@ietf.org; Fri, 02 Jul 2004 09:07:22 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1BgNkS-0000ff-00 for simple@ietf.org; Fri, 02 Jul 2004 09:06:37 -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 i62D6S222264; Fri, 2 Jul 2004 16:06:29 +0300 (EET DST) X-Scanned: Fri, 2 Jul 2004 16:02:58 +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 i62D2wKW028572; Fri, 2 Jul 2004 16:02:58 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 003WdR6z; Fri, 02 Jul 2004 16:02: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 i62D2iH00177; Fri, 2 Jul 2004 16:02:44 +0300 (EET DST) Received: from nokia.com ([172.21.42.108]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 2 Jul 2004 16:02:44 +0300 Message-ID: <40E55CF4.6040706@nokia.com> Date: Fri, 02 Jul 2004 16:02:44 +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: "George Foti (QA/EMC)" Subject: Re: [Simple] RE: XCAP Directory: Large response ? References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Jul 2004 13:02:44.0181 (UTC) FILETIME=[DD5F9050:01C46034] Content-Transfer-Encoding: 7bit Cc: Jonathan Rosenberg , 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 George: I don't like this solution. It requires the XCAP server to do a "trial and error" of the XML document that will be send to the user. Build an XML document with "n" entries, if the size of the document exceeds X bytes, start reducing the number entries, one by one, until the result is less than X bytes. That's awful. I believe we have two constraints here: one is the display size of the device and the other is the memory of the device. I believe a device may want to get a page of entries it can render in the display, then release the memory, and request a new page. I don't think this can be achieved by selecting the size in bytes, but with the number of entries in a list. - Miguel George Foti (QA/EMC) wrote: > A potential solution is for a client to be able to ask either of the following questions: > 1) Give me a *maximum* of X bytes ranges Z onwards > 2) Give me a *maximum* of X bytes ranges Y-Z > > The XCAP server should return in a successfull response an XML document that is schema compliant that does not exceed the *maximum* range. The client can then perform operations on such a document. > A request could fail for multiple reasons, no document meets the maximum length, server does not understand the schema, etcc.. > > The above implies that XCAP servers must understand different schemas, but that may be unavoidable for some operations. > The other thing, I dont know if HTTP headers do allow for the above. > > Rgds/gf > > > > >>-----Original Message----- >>From: simple-bounces@ietf.org >>[mailto:simple-bounces@ietf.org]On Behalf >>Of Henrik Albertsson (KI/EAB) >>Sent: Friday, July 02, 2004 6:38 AM >>To: 'Miguel Garcia'; ext Jonathan Rosenberg >>Cc: simple@ietf.org >>Subject: [Simple] RE: XCAP Directory: Large response ? >> >> >>I agree with you Miguel that the "give me X byte" solution is >>not usable for the reasons you mentioned. However most likely >>the XCAP client will operate on a well known AUDI and have >>knowledge about what the structure of the XCAP document is so >>it can roughly estimate what size 30 elements would be. >> >>Is it so that when specifying a XCAP document we also need to >>define what element will be used for indexing when asking for >>a range of elements? >> >>Regards >>/Henrik >> >> >> >> >>>-----Original Message----- >>>From: Miguel Garcia [mailto:Miguel.An.Garcia@nokia.com] >>>Sent: den 2 juli 2004 12:14 >>>To: ext Jonathan Rosenberg >>>Cc: Henrik Albertsson (KI/EAB); simple@ietf.org >>>Subject: Re: XCAP Directory: Large response ? >>> >>> >>>Jonathan Rosenberg wrote: >>> >>> >>>>I would propose that we not put this functionality in xcap >>> >>>itself, but >>> >>>>use the existing HTTP mechanisms. I will note that these >>> >>>mechanisms are >>> >>>>*byte* oriented, and not XML oriented. Thus, you may cut an >>> >>>element off >>> >>>>in the middle by asking for the first 50 bytes. However, if >>> >>>your main >>> >>>>concern is bandwidth or latency, then bytes are much more >>> >>>significant of >>> >>>>a measure than elements. If I say, "give me 30 elements", >>> >>>that could be >>> >>>>30 bytes or 30MB, depennding on the amount of data in >> >>each element. >> >>>>-Jonathan R. >>>> >>> >>>Jonathan, I think the HTTP byte ranges will not work. Let's say I >>>request a long document, and I request bytes 1 to 10000. The >>>HTTP server >>>will cut the XML document exacltly when the number of bytes >>>has reached >>>the count, and will send it to the XCAP client. The XCAP >> >>client can't >> >>>check if the document is well-formed, not even check if it is valid >>>according to the XML schema. As a consequence, it won't >> >>display it to >> >>>the user, or dare to do any operation on it. The only thing >> >>the XCAP >> >>>client can do is to request the next byte range. >>> >>>I am concerned with the limited amount of memory a device >> >>might have, >> >>>AND the bandwidth. The latter can be solved with byte >> >>ranges, but not >> >>>the former. >>> >>>However, if we provide a mechanism to request ranges of >> >>entries in a >> >>>list, this will solve the problem: the XCAP server create a >> >>valid XML >> >>>document that complies with the schema and send it to the >>>XCAP client. >>>The client can request additional ranges once it has freed >>>the memory. >>>The drawback is that we cannot accurately control the bandwidth (we >>>don't know how many bytes will come), but I don't think this >>>is a big issue. >>> >>>- 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 >> -- 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 Fri Jul 2 09:31: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 JAA05320 for ; Fri, 2 Jul 2004 09:31: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 1BgO8p-0002Ap-Tu for simple-archive@ietf.org; Fri, 02 Jul 2004 09:31:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgO7t-0001nZ-00 for simple-archive@ietf.org; Fri, 02 Jul 2004 09:30:50 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BgO6w-0001O7-00; Fri, 02 Jul 2004 09:29:50 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BgO6u-0000WO-Ey; Fri, 02 Jul 2004 09: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 1BgO3B-0006jE-OW; Fri, 02 Jul 2004 09:25:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgNvn-00039q-El for simple@megatron.ietf.org; Fri, 02 Jul 2004 09:18: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 JAA04028 for ; Fri, 2 Jul 2004 09: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 1BgNvm-0004kv-Mr for simple@ietf.org; Fri, 02 Jul 2004 09:18:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgNut-0004PT-00 for simple@ietf.org; Fri, 02 Jul 2004 09:17:24 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1BgNtz-00044D-00 for simple@ietf.org; Fri, 02 Jul 2004 09:16:28 -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 i62DGL209957; Fri, 2 Jul 2004 16:16:21 +0300 (EET DST) X-Scanned: Fri, 2 Jul 2004 16:16:17 +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 i62DGHKu009697; Fri, 2 Jul 2004 16:16:17 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 001eq7Ls; Fri, 02 Jul 2004 16:16:16 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 i62DGGH01797; Fri, 2 Jul 2004 16:16:16 +0300 (EET DST) Received: from nokia.com ([172.21.42.108]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 2 Jul 2004 16:16:11 +0300 Message-ID: <40E5601B.4000807@nokia.com> Date: Fri, 02 Jul 2004 16:16:11 +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: "Joel M. Halpern" Subject: Re: [Simple] Double specification: text and schema References: <40E50CA8.2050100@nokia.com> <5.1.0.14.0.20040701110539.023d8090@localhost> <40E50CA8.2050100@nokia.com> <5.1.0.14.0.20040702085730.023c3fe0@localhost> In-Reply-To: <5.1.0.14.0.20040702085730.023c3fe0@localhost> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Jul 2004 13:16:12.0002 (UTC) FILETIME=[BEDF4420:01C46036] Content-Transfer-Encoding: 7bit Cc: Jonathan Rosenberg , SIMPLE mailing list X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org 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 Well, here is the disagreement. I just want to tell authors: "don't use normative text when there is normative definition expressed in the schema". Believe me, and record my words for a future time: if we start doing double specification of normative requirements in RFCs, we will face interoperability problems. If you are not able to put a bit of effort when writing your documents, we all will pay in the future. - Miguel Joel M. Halpern wrote: > Part of what I am trying to avoid is telling authors that they must be > extra careful never to use MUST words about things described in the > schema. In a typical text description there will be explanatory text, > there will be explanation of requirements that are also in the schema, > and there will be explanation of requirements that are not in the > schema. (Occasionally one gets lucky and the last category is empty.) > As an author, I really don't want to have to try to change style from > sentence to sentence in a section depending upon whether or not the > particular behavior I am describing also occurs in the schema. > Also, as I reader I would like to see a complete description in the text. > > Yours, > Joel M. Halpern > > At 06:23 AM 7/2/2004 -0400, Jonathan Rosenberg wrote: > > >> Miguel Garcia wrote: >> >>> Hi Joel: >>> I don't agree with you. We can't avoid the XML schema. I believe you >>> agree with me. >>> Since the XML schema already needs to indicate whether an element or >>> attribute is mandatory or not, there is no point in repeating the >>> same information in the text. What for? >> >> >> I think that it can be useful for purposes of clarification. I would >> advise using non-normative terminology in the text. So, for example: >> >> "The element includes a single mandatory attribute, "bar", and >> always has two children, and ..." >> >> I think it also makes sense to have an explicit statement about the >> normative nature of the schema, and that any explanatory text is not >> normative. I routinely put such statements in "overview of operations" >> sections, which are not written with RFC2119-strentgh terms. >> >> -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 > > -- 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 Fri Jul 2 10: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 KAA06741 for ; Fri, 2 Jul 2004 10:05: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 1BgOfR-0005Id-Ev for simple-archive@ietf.org; Fri, 02 Jul 2004 10:05:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgOeK-0004w1-00 for simple-archive@ietf.org; Fri, 02 Jul 2004 10:04:21 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BgOdW-0004KQ-00; Fri, 02 Jul 2004 10:03:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgOOA-00071o-1C; Fri, 02 Jul 2004 09:47:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgOK3-0005gy-DD for simple@megatron.ietf.org; Fri, 02 Jul 2004 09:43: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 JAA05911 for ; Fri, 2 Jul 2004 09:43: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 1BgOK2-0006Aj-Nj for simple@ietf.org; Fri, 02 Jul 2004 09:43:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgOJF-0005rg-00 for simple@ietf.org; Fri, 02 Jul 2004 09:42:34 -0400 Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx with esmtp (Exim 4.12) id 1BgOIf-0005XY-00 for simple@ietf.org; Fri, 02 Jul 2004 09:41:57 -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 i62DfvAh006604 for ; Fri, 2 Jul 2004 15:41:57 +0200 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Fri, 2 Jul 2004 15:41:57 +0200 Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Fri, 2 Jul 2004 15:41:56 +0200 Message-ID: From: "Anders Lindgren C (HF/EAB)" To: "'hisham.khartabil@nokia.com'" , simple@ietf.org Date: Fri, 2 Jul 2004 15:41:49 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 02 Jul 2004 13:41:57.0185 (UTC) FILETIME=[57DF7B10:01C4603A] Subject: [Simple] RE: simple-filter Max Size or Max number of element as filter cri terias? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org 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 Ok Can I select the number of elements of a certain type I want to receive? Ie give my at the most 100 buddies in a resource list when subscribing to a list? Or is it that something complete new is needed or is it covered by some other spec? As I see it this is a general problem for all types of Subscribe for event packages if you can not control the size of what is send in the Notify. Regards Anders -----Original Message----- From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] Sent: den 2 juli 2004 14:40 To: Anders Lindgren C (HF/EAB); simple@ietf.org Subject: RE: simple-filter Max Size or Max number of element as filter criterias? You can reduce the size of the document delivered in the NOTIFY by using the filters (but selecting the elements that you really want to be delivered to you), but you cannot filter based on size. You cannot say "send me a NOTIFY with a body no larger than 1000 bytes". If you want something like that, then this is outside the scope of the filtering drafts in question. Regards, Hisham > -----Original Message----- > From: ext Anders Lindgren C (HF/EAB) > [mailto:anders.c.lindgren@ericsson.com] > Sent: 02.July.2004 15:23 > To: Khartabil Hisham (Nokia-TP-MSW/Helsinki); simple@ietf.org > Subject: RE: simple-filter Max Size or Max number of element as filter > criterias? > > > Hi > The question is what "unwanted" information" mean? Can it be > that a XML document that is to large to handle can be > regarded as "unwanted" information and therefore can be > regarded as being inside the scope of the simple-filter draft. > Regards > Anders > > -----Original Message----- > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > Sent: den 2 juli 2004 10:07 > To: Anders Lindgren C (HF/EAB); simple@ietf.org > Subject: RE: simple-filter Max Size or Max number of element as filter > criterias? > > > I believe that you are asking for is outside the scope of the > simple-filter drafts. It can be done with filters, but not those ones. > > The current filter drafts talk about filtering unwanted or > uninteresting information sent in a NOTIFY. They also talk > about triggering of notifications when certain changes to the > state of an event occur. > > Regards, > Hisham > > > -----Original Message----- > > From: ext Anders Lindgren C (HF/EAB) > > [mailto:anders.c.lindgren@ericsson.com] > > Sent: 02.July.2004 10:53 > > To: simple@ietf.org; Khartabil Hisham (Nokia-TP-MSW/Helsinki) > > Subject: simple-filter Max Size or Max number of element as filter > > criterias? > > > > > > Hi, > > The XML documents sent from the network to the client can be > > very large or it can contains a very long sequence of > > elements ( e.g a resource list with 1000 buddies) > > It will also exist different types of clients. Some clients > > can specify a very large resource list and it will exist > > clients that can not handle that large list. > > > > I have not found how a client can inform the network about > > how large documents is can handle or how many elements of a > > certain type it can handle. > > My question is now if this information can be regarded as > > filter criterias and includes in this filter specification? > > > > Best regards > > > > Anders Lindgren Ericsson AB Sweden > > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jul 2 10:18: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 KAA08282 for ; Fri, 2 Jul 2004 10:18: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 1BgOru-0001eP-Uf for simple-archive@ietf.org; Fri, 02 Jul 2004 10:18:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgOr4-0001KJ-00 for simple-archive@ietf.org; Fri, 02 Jul 2004 10:17:30 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BgOqD-0000jX-00; Fri, 02 Jul 2004 10:16:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgOga-0008UE-GJ; Fri, 02 Jul 2004 10:06:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgOdN-000605-59 for simple@megatron.ietf.org; Fri, 02 Jul 2004 10:03: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 KAA06509 for ; Fri, 2 Jul 2004 10:03: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 1BgOdM-0004cj-77 for simple@ietf.org; Fri, 02 Jul 2004 10:03:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgOcN-0004Jw-00 for simple@ietf.org; Fri, 02 Jul 2004 10:02:20 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BgObf-00041S-00 for simple@ietf.org; Fri, 02 Jul 2004 10:01:35 -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 i62E1XN11194; Fri, 2 Jul 2004 17:01:33 +0300 (EET DST) X-Scanned: Fri, 2 Jul 2004 17:01: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 i62E1Qag005753; Fri, 2 Jul 2004 17:01:26 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00PW6w85; Fri, 02 Jul 2004 17:01:00 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 i62E0xH18766; Fri, 2 Jul 2004 17:00:59 +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, 2 Jul 2004 17:00:43 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Date: Fri, 2 Jul 2004 17:00:39 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7023EEA9D@esebe019.ntc.nokia.com> Thread-Topic: simple-filter Max Size or Max number of element as filter criterias? Thread-Index: AcRgOoWAR7fyEky1S3K9x53JR4i9AQAAdi3A To: , X-OriginalArrivalTime: 02 Jul 2004 14:00:43.0353 (UTC) FILETIME=[F71F1490:01C4603C] Content-Transfer-Encoding: quoted-printable Subject: [Simple] RE: simple-filter Max Size or Max number of element as filter criterias? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org 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 Anders Lindgren C (HF/EAB) > [mailto:anders.c.lindgren@ericsson.com] > Sent: 02.July.2004 16:42 > To: Khartabil Hisham (Nokia-TP-MSW/Helsinki); simple@ietf.org > Subject: RE: simple-filter Max Size or Max number of element as filter > criterias? >=20 >=20 > Ok > Can I select the number of elements of a certain type I want=20 > to receive? Ie give my at the most 100 buddies in a resource=20 > list when subscribing to a list? No you cannot, but what you can do is list in the filter the buddies you = are interested in receiving information about. I think this is more = useful that using the filter to tell the server to send you the first x = buddies. /Hisham > Or is it that something=20 > complete new is needed or is it covered by some other spec? =20 > As I see it this is a general problem for all types of=20 > Subscribe for event packages if you can not control the size=20 > of what is send in the Notify. > Regards Anders >=20 > -----Original Message----- > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > Sent: den 2 juli 2004 14:40 > To: Anders Lindgren C (HF/EAB); simple@ietf.org > Subject: RE: simple-filter Max Size or Max number of element as filter > criterias? >=20 >=20 > You can reduce the size of the document delivered in the=20 > NOTIFY by using the filters (but selecting the elements that=20 > you really want to be delivered to you), but you cannot=20 > filter based on size. You cannot say "send me a NOTIFY with a=20 > body no larger than 1000 bytes". >=20 > If you want something like that, then this is outside the=20 > scope of the filtering drafts in question. >=20 > Regards, > Hisham >=20 > > -----Original Message----- > > From: ext Anders Lindgren C (HF/EAB) > > [mailto:anders.c.lindgren@ericsson.com] > > Sent: 02.July.2004 15:23 > > To: Khartabil Hisham (Nokia-TP-MSW/Helsinki); simple@ietf.org > > Subject: RE: simple-filter Max Size or Max number of=20 > element as filter > > criterias? > >=20 > >=20 > > Hi > > The question is what "unwanted" information" mean? Can it be=20 > > that a XML document that is to large to handle can be=20 > > regarded as "unwanted" information and therefore can be=20 > > regarded as being inside the scope of the simple-filter draft. > > Regards > > Anders > >=20 > > -----Original Message----- > > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > > Sent: den 2 juli 2004 10:07 > > To: Anders Lindgren C (HF/EAB); simple@ietf.org > > Subject: RE: simple-filter Max Size or Max number of=20 > element as filter > > criterias? > >=20 > >=20 > > I believe that you are asking for is outside the scope of the=20 > > simple-filter drafts. It can be done with filters, but not=20 > those ones. > >=20 > > The current filter drafts talk about filtering unwanted or=20 > > uninteresting information sent in a NOTIFY. They also talk=20 > > about triggering of notifications when certain changes to the=20 > > state of an event occur. > >=20 > > Regards, > > Hisham > >=20 > > > -----Original Message----- > > > From: ext Anders Lindgren C (HF/EAB) > > > [mailto:anders.c.lindgren@ericsson.com] > > > Sent: 02.July.2004 10:53 > > > To: simple@ietf.org; Khartabil Hisham (Nokia-TP-MSW/Helsinki) > > > Subject: simple-filter Max Size or Max number of element as filter > > > criterias? > > >=20 > > >=20 > > > Hi, > > > The XML documents sent from the network to the client can be=20 > > > very large or it can contains a very long sequence of=20 > > > elements ( e.g a resource list with 1000 buddies) > > > It will also exist different types of clients. Some clients=20 > > > can specify a very large resource list and it will exist=20 > > > clients that can not handle that large list. > > >=20 > > > I have not found how a client can inform the network about=20 > > > how large documents is can handle or how many elements of a=20 > > > certain type it can handle. > > > My question is now if this information can be regarded as=20 > > > filter criterias and includes in this filter specification? > > >=20 > > > Best regards > > >=20 > > > Anders Lindgren Ericsson AB Sweden > > >=20 > >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jul 2 10:32: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 KAA08853 for ; Fri, 2 Jul 2004 10:32: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 1BgP5Q-00066I-PN for simple-archive@ietf.org; Fri, 02 Jul 2004 10:32:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgP4Q-0005io-00 for simple-archive@ietf.org; Fri, 02 Jul 2004 10:31:20 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BgP3P-00055r-00; Fri, 02 Jul 2004 10:30:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgOie-0001RU-32; Fri, 02 Jul 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 1BgOfR-0007it-GE for simple@megatron.ietf.org; Fri, 02 Jul 2004 10:05:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06738 for ; Fri, 2 Jul 2004 10:05: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 1BgOfQ-0005IX-M0 for simple@ietf.org; Fri, 02 Jul 2004 10:05:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgOeJ-0004vt-00 for simple@ietf.org; Fri, 02 Jul 2004 10:04:20 -0400 Received: from zrtps06s.nortelnetworks.com ([47.140.48.50]) by ietf-mx with esmtp (Exim 4.12) id 1BgOdS-0004KO-00 for simple@ietf.org; Fri, 02 Jul 2004 10:03:26 -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 i62E2ie27635; Fri, 2 Jul 2004 10:02:45 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 2 Jul 2004 10:02:45 -0400 Message-ID: From: "Mary Barnes" To: "'Miguel Garcia'" , "Joel M. Halpern" Subject: RE: [Simple] Double specification: text and schema Date: Fri, 2 Jul 2004 10:02:09 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Cc: Jonathan Rosenberg , SIMPLE mailing list X-BeenThere: simple@ietf.org X-Mailman-Version: 2.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="===============1092286735==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org 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,HTML_20_30,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. --===============1092286735== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4603D.2A71A926" 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_01C4603D.2A71A926 Content-Type: text/plain I agree with Joel; I think we're getting back to the fundamental debate on whether one should comment code or whether good code is self documenting (or whether detailed design documents should have pseudo-code or real code, etc.) It is important to have good and accurate as possible textual descriptions along with the XML. And, I don't see a problem with it being normative, either (in fact that would be my preference). I don't consider myself an XML guru, but I can manage my way through with the appropriate normative text. That's how it's done for all the other specs; why should the XML based specs be any different? Certainly, there are issues with some of the current documents in the text that could be further clarified to ensure consistency with the XML schema, but I think that's along the lines of the last point you make below about putting a "bit of effort" in writing the documents. Regards, Mary. -----Original Message----- From: Miguel Garcia [mailto:Miguel.An.Garcia@nokia.com] Sent: Friday, July 02, 2004 8:16 AM To: Joel M. Halpern Cc: Jonathan Rosenberg; SIMPLE mailing list Subject: Re: [Simple] Double specification: text and schema Well, here is the disagreement. I just want to tell authors: "don't use normative text when there is normative definition expressed in the schema". Believe me, and record my words for a future time: if we start doing double specification of normative requirements in RFCs, we will face interoperability problems. If you are not able to put a bit of effort when writing your documents, we all will pay in the future. - Miguel Joel M. Halpern wrote: > Part of what I am trying to avoid is telling authors that they must be > extra careful never to use MUST words about things described in the > schema. In a typical text description there will be explanatory text, > there will be explanation of requirements that are also in the schema, > and there will be explanation of requirements that are not in the > schema. (Occasionally one gets lucky and the last category is empty.) > As an author, I really don't want to have to try to change style from > sentence to sentence in a section depending upon whether or not the > particular behavior I am describing also occurs in the schema. > Also, as I reader I would like to see a complete description in the text. > > Yours, > Joel M. Halpern > > At 06:23 AM 7/2/2004 -0400, Jonathan Rosenberg wrote: > > >> Miguel Garcia wrote: >> >>> Hi Joel: >>> I don't agree with you. We can't avoid the XML schema. I believe you >>> agree with me. >>> Since the XML schema already needs to indicate whether an element or >>> attribute is mandatory or not, there is no point in repeating the >>> same information in the text. What for? >> >> >> I think that it can be useful for purposes of clarification. I would >> advise using non-normative terminology in the text. So, for example: >> >> "The element includes a single mandatory attribute, "bar", and >> always has two children, and ..." >> >> I think it also makes sense to have an explicit statement about the >> normative nature of the schema, and that any explanatory text is not >> normative. I routinely put such statements in "overview of operations" >> sections, which are not written with RFC2119-strentgh terms. >> >> -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 > > -- 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 ------_=_NextPart_001_01C4603D.2A71A926 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Simple] Double specification: text and schema

I agree with Joel; I think we're getting back to the = fundamental debate on whether one should comment code or whether good = code is self documenting (or whether detailed design documents should = have pseudo-code or real code, etc.)  It is important to have good = and accurate as possible textual descriptions along with the XML. And, = I don't see a problem with it being normative, either (in fact that = would be my preference). I don't consider myself an XML guru, but I can = manage my way through with the appropriate normative text.  That's = how it's done for all the other specs; why should the XML based specs = be any different?   

Certainly, there are issues with some of the current = documents in the text that could be further clarified to ensure = consistency with the XML schema, but I think that's along the lines of = the last point you make below about putting a "bit of effort" = in writing the documents.   

Regards,
Mary.

-----Original Message-----
From: Miguel Garcia [mailto:Miguel.An.Garcia@nokia= .com]
Sent: Friday, July 02, 2004 8:16 AM
To: Joel M. Halpern
Cc: Jonathan Rosenberg; SIMPLE mailing list
Subject: Re: [Simple] Double specification: text and = schema


Well, here is the disagreement. I just want to tell = authors: "don't use
normative text when there is normative definition = expressed in the schema".

Believe me, and record my words for a future time: if = we start doing
double specification of normative requirements in = RFCs, we will face
interoperability problems.

If you are not able to put a bit of effort when = writing your documents,
we all will pay in the future.

- Miguel

Joel M. Halpern wrote:

> Part of what I am trying to avoid is telling = authors that they must be
> extra careful never to use MUST words about = things described in the
> schema.  In a typical text description = there will be explanatory text,
> there will be explanation of requirements that = are also in the schema,
> and there will be explanation of requirements = that are not in the
> schema.  (Occasionally one gets lucky and = the last category is empty.)
> As an author, I really don't want to have to = try to change style from
> sentence to sentence in a section depending = upon whether or not the
> particular behavior I am describing also occurs = in the schema.
> Also, as I reader I would like to see a = complete description in the text.
>
> Yours,
> Joel M. Halpern
>
> At 06:23 AM 7/2/2004 -0400, Jonathan Rosenberg = wrote:
>
>
>> Miguel Garcia wrote:
>>
>>> Hi Joel:
>>> I don't agree with you. We can't avoid = the XML schema. I believe you
>>> agree with me.
>>> Since the XML schema already needs to = indicate whether an element or
>>> attribute is mandatory or not, there is = no point in repeating the
>>> same information in the text. What = for?
>>
>>
>> I think that it can be useful for purposes = of clarification. I would
>> advise using non-normative terminology in = the text. So, for example:
>>
>> "The <foo> element includes a = single mandatory attribute, "bar", and
>> always has two children, <sip> and = <ping>..."
>>
>> I think it also makes sense to have an = explicit statement about the
>> normative nature of the schema, and that = any explanatory text is not
>> normative. I routinely put such statements = in "overview of operations"
>> sections, which are not written with = RFC2119-strentgh terms.
>>
>> -Jonathan R.
>>
>> --
>> Jonathan D. Rosenberg, = Ph.D.           &= nbsp;    600 Lanidex Plaza
>> Chief Technology = Officer           = ;         Parsippany, NJ = 07054-2711
>> dynamicsoft
>> = jdrosen@dynamicsoft.com        &= nbsp;            = FAX:   (973) 952-5050
>> http://www.jdrosen.net    &nbs= p;           &nbs= p;     PHONE: (973) 952-5000
>> http://www.dynamicsoft.com
>>
>> = _______________________________________________
>> Simple mailing list
>> Simple@ietf.org
>> https://www1.ietf.org/mailman/listinfo/simple
>
>

--
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

------_=_NextPart_001_01C4603D.2A71A926-- --===============1092286735== 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 --===============1092286735==-- From simple-bounces@ietf.org Fri Jul 2 10:40: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 KAA09432 for ; Fri, 2 Jul 2004 10:40: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 1BgPD8-00012g-KW for simple-archive@ietf.org; Fri, 02 Jul 2004 10:40:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgPCA-0000g9-00 for simple-archive@ietf.org; Fri, 02 Jul 2004 10:39:18 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BgPB6-00002K-00; Fri, 02 Jul 2004 10:38:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgP3z-0004kv-Og; Fri, 02 Jul 2004 10:30:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgOnU-0003kM-Ml for simple@megatron.ietf.org; Fri, 02 Jul 2004 10: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 KAA07750 for ; Fri, 2 Jul 2004 10:13:46 -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 1BgOnT-0007mV-Tz for simple@ietf.org; Fri, 02 Jul 2004 10:13:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgOmN-0007QJ-00 for simple@ietf.org; Fri, 02 Jul 2004 10:12:39 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1BgOlc-00074m-00 for simple@ietf.org; Fri, 02 Jul 2004 10:11:52 -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 i62EBn219465; Fri, 2 Jul 2004 17:11:49 +0300 (EET DST) X-Scanned: Fri, 2 Jul 2004 17:11:37 +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 i62EBbgq016583; Fri, 2 Jul 2004 17:11:37 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00lZ8zx1; Fri, 02 Jul 2004 17:11: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 i62EBVH28127; Fri, 2 Jul 2004 17:11:31 +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, 2 Jul 2004 17:11:29 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Date: Fri, 2 Jul 2004 17:11:29 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7023EEA9E@esebe019.ntc.nokia.com> Thread-Topic: XCAP list-usage: list URI creation Thread-Index: AcRgPnkad6P2cp7BS9iALSMgCLdQkQ== To: X-OriginalArrivalTime: 02 Jul 2004 14:11:30.0083 (UTC) FILETIME=[789A3F30:01C4603E] Content-Transfer-Encoding: quoted-printable Cc: jdrosen@dynamicsoft.com Subject: [Simple] XCAP list-usage: list URI creation X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org 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 know we concluded this issue, but cannot remember that the conclusion = was. How is the List URI created? Was it that the client always suggests and = the server rejects with 409 if the list URI is not acceptable? (I'm looking to mirror the same behaviour in the conferencing work) Thanks, Hisham _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jul 2 10:42: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 KAA09567 for ; Fri, 2 Jul 2004 10:42: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 1BgPF5-0001jn-Hn for simple-archive@ietf.org; Fri, 02 Jul 2004 10:42:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgPE5-0001Od-00 for simple-archive@ietf.org; Fri, 02 Jul 2004 10:41:17 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BgPD7-0000k6-00; Fri, 02 Jul 2004 10:40:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgP42-0004my-Q7; Fri, 02 Jul 2004 10:30:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgOq9-0004ox-Gr for simple@megatron.ietf.org; Fri, 02 Jul 2004 10:16: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 KAA08069 for ; Fri, 2 Jul 2004 10:16: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 1BgOq8-0000zd-OA for simple@ietf.org; Fri, 02 Jul 2004 10:16:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgOp6-0000ef-00 for simple@ietf.org; Fri, 02 Jul 2004 10:15:28 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BgOoL-0000CX-00 for simple@ietf.org; Fri, 02 Jul 2004 10:14:41 -0400 Received: from dynamicsoft.com ([63.113.46.29]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i62EERbo004894; Fri, 2 Jul 2004 10:14:27 -0400 (EDT) Message-ID: <40E56DB0.5070206@dynamicsoft.com> Date: Fri, 02 Jul 2004 10:14: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 References: <2038BCC78B1AD641891A0D1AE133DBB7023EEA9E@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB7023EEA9E@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 Subject: [Simple] Re: XCAP list-usage: list URI creation X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org 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 know we concluded this issue, but cannot remember that the > conclusion was. > > How is the List URI created? Was it that the client always suggests > and the server rejects with 409 if the list URI is not acceptable? Yes. We debated whether to allow the client to omit the list, and then have the server generate a 409. But, there was nothing gained by this, and since the list URI is really supposed to be there, you want it as mandatory in the schema. -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 Jul 2 11:03: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 LAA11289 for ; Fri, 2 Jul 2004 11:03: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 1BgPZH-00019U-Lm for simple-archive@ietf.org; Fri, 02 Jul 2004 11:03:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgPYC-0000hZ-00 for simple-archive@ietf.org; Fri, 02 Jul 2004 11:02:06 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BgPX3-0000DL-00; Fri, 02 Jul 2004 11:00:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgPHt-0002At-Dr; Fri, 02 Jul 2004 10: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 1Bg5sK-0008R4-FS for simple@megatron.ietf.org; Thu, 01 Jul 2004 14:01: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 OAA21501 for ; Thu, 1 Jul 2004 14:01: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 1Bg5sI-0007lI-Rn for simple@ietf.org; Thu, 01 Jul 2004 14:01:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bg5rO-0007O9-00 for simple@ietf.org; Thu, 01 Jul 2004 14:00:36 -0400 Received: from smtp.spamarrest.com ([66.150.163.174] helo=spamarrest.com) by ietf-mx with esmtp (Exim 4.12) id 1Bg5qW-0006dL-00 for simple@ietf.org; Thu, 01 Jul 2004 13:59:40 -0400 Received: from [128.104.192.100] (account vanderhe@smtp.spamarrest.com HELO NC6000BAK) by spamarrest.com (CommuniGate Pro SMTP 4.2b1) with ESMTP id 8391510; Thu, 01 Jul 2004 10:59:09 -0700 From: "Gregg Vanderheiden" To: "'Eric Burger'" , "'Arnoud van Wijk'" Subject: RE: [Simple] RE: [Sipping] RE: text/T140 and audio/t140was:[avt]Comments/questions on draft-ietf-av Date: Thu, 1 Jul 2004 12:59:09 -0500 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: AcRfh8vwBxBuCpcKQma2cY1Nlf0jGgABjuxQ In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Message-ID: Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 02 Jul 2004 10:45:12 -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.2 required=5.0 tests=AWL,MISSING_OUTLOOK_NAME, YOU_WON autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Hmmmm We have no ground to say 'if you have IM you MUST have real-time-text.' I think we can and should say "you SHOULD have real-time-text. it is easy and useful" On the other hand, in the US under our laws, we do say that if you have VOICE TELECOM you MUST support real-time-text. (either provide it or allow connection of devices that do). This latter item (requiring text with voice) is not a topic for this forum though. Those requirements must come from another place HOWEVER - 1) we should ENCOURAGE and ENABLE real-time-text wherever there is audio. 2) And we should ENCOURAGE and ENABLE real-time-text wherever there is Messaging, and real-time-text is possible. (Not possible for example with two way paging because of the technology used). 3) And we should do whatever we can to make sure everything works together. - that means that everything needs to support every format - or everything needs to support at least one format - or someone needs to support Transcoders everywhere (Not likely). What is the best way to do this? Gregg -- ------------------------------ Gregg C Vanderheiden Ph.D. Professor - Ind. Engr. & BioMed Engr. Director - Trace R & D Center University of Wisconsin-Madison -----Original Message----- From: Eric Burger [mailto:eburger@brooktrout.com] Sent: Thursday, July 01, 2004 10:44 AM To: Arnoud van Wijk; 'Gregg Vanderheiden' Cc: simple@ietf.org Subject: RE: [Simple] RE: [Sipping] RE: text/T140 and audio/t140was:[avt]Comments/questions on draft-ietf-av I disagree that the tie-in is voice and real-time-text. I believe the tie-in is between IM and real-time text. If we say, "If you have voice, you MUST have real-time-text", it just won't happen, unless mandated by law. If we say, "If you have voice, you SHOULD have real-time-text", it really won't happen, unless someone is making a really high-end set. If we say, "If you have IM, you SHOULD/MUST have real-time-text", we will see real-time-text deployed in a big way. It is so easy to add it in that environment that it will probably "just happen." Moreover, even mid-priced telephony sets will probably include real-time-text, which was the goal of tying voice to real-time-text in the first place. > -----Original Message----- > From: Arnoud van Wijk [mailto:a.vwijk@viataal.nl] > Sent: Friday, June 25, 2004 5:40 AM > To: 'Paul Kyzivat'; 'Gregg Vanderheiden' > Cc: 'Guido Gybels'; gunnar.hellstrom@omnitor.se; fluffy@cisco.com; > simple@ietf.org; paulej@packetizer.com; toip@snowshore.com; > smundra@telogy.com > Subject: RE: [Simple] RE: [Sipping] RE: text/T140 and > audio/t140was:[avt]Comments/questions on draft-ietf-av > > > Hi Paul, > Is there a possibility that we can talk with Cisco and work > out a strategy > for the IP phones? Viataal and RNID and Trace are quite > willing to help > defining a good strategy that helps manufacturers to satify all users. > If there are enough IP phones in every price range that > supports Interactive > Text, then I do not care whether EVERY phone has it. > > Not all phones support caller ID, but there are plenty phones > who supports > it anyway. > > I would indeed focus in 2 ways. > > 1. If an IP phone supports IM, it MUST also support > Interactive text. There > is no excuse whichsoever, no argument to explain why > interactive text is > then skipped! > 2. For every price range, there MUST be IP phones with > Interactive text > capabilities. Regardless they also support IM or not. > > A voice only cheap IP phone to be used for your teenage > daughter or in the > basement, etc. there is no need for text support there. If > possible, great.. > > As long that user who need Interactive text can buy such phones at any > Wallmart or other shop. And that other users can just as > easily buy an IP > phone with interactive text without having to rob a bank, or > take a second > mortgage. > > Ofcourse, I do want to see Interactive text in EVERY phone. I > also want to > win the lottery jackpot. And marry a supermodel. > > Greetz > > Arnoud > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: donderdag 24 juni 2004 21:24 > To: Gregg Vanderheiden > Cc: 'Guido Gybels'; gunnar.hellstrom@omnitor.se; fluffy@cisco.com; > simple@ietf.org; paulej@packetizer.com; toip@snowshore.com; > smundra@telogy.com; a.vwijk@viataal.nl > Subject: Re: [Simple] RE: [Sipping] RE: text/T140 and > audio/t140was:[avt]Comments/questions on draft-ietf-av > > > > 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 > > > - > 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 Fri Jul 2 11:03: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 LAA11315 for ; Fri, 2 Jul 2004 11:03: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 1BgPZW-0001Qi-UT for simple-archive@ietf.org; Fri, 02 Jul 2004 11:03:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgPYK-0000lm-00 for simple-archive@ietf.org; Fri, 02 Jul 2004 11:02:13 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BgPX8-0000Dz-00; Fri, 02 Jul 2004 11:00:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgPHt-0002B4-TI; Fri, 02 Jul 2004 10: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 1Bg5xg-0004zl-1t for simple@megatron.ietf.org; Thu, 01 Jul 2004 14:07: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 OAA21908 for ; Thu, 1 Jul 2004 14:07: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 1Bg5xf-00023G-41 for simple@ietf.org; Thu, 01 Jul 2004 14:07:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bg5wJ-0001aI-00 for simple@ietf.org; Thu, 01 Jul 2004 14:05:40 -0400 Received: from smtp.spamarrest.com ([66.150.163.174] helo=spamarrest.com) by ietf-mx with esmtp (Exim 4.12) id 1Bg5vB-0000mA-00 for simple@ietf.org; Thu, 01 Jul 2004 14:04:29 -0400 Received: from [128.104.192.100] (account vanderhe@smtp.spamarrest.com HELO NC6000BAK) by spamarrest.com (CommuniGate Pro SMTP 4.2b1) with ESMTP id 8395585; Thu, 01 Jul 2004 11:03:59 -0700 From: "Gregg Vanderheiden" To: "'Guido Gybels'" , "'RNIDMAIL.GWIA.\"A.vWijk@viataal.nl\"'" , , , , Subject: RE: Tiny ant vs big Mammoths, was RE: [Simple] Using MSRP for realtime text conversation Date: Thu, 1 Jul 2004 13:03:57 -0500 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: AcRejngaO5tJpaNkRY2Mor+yDLjZwQArRKUQAA9rxXA= In-Reply-To: <4818CE251FC66942A7EF35B92695246E01B2212F@JUPITER-MSG.ad.rnid.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Message-ID: Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 02 Jul 2004 10:45:12 -0400 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.8 required=5.0 tests=AWL,EXCUSE_16, MAILTO_TO_SPAM_ADDR,MISSING_OUTLOOK_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit I too worry about having multiple text conversation technologies. I don't see it as bad theoretically. Difference facilitates evolution. HOWEVER, if we have different formats, then 1) EITHER everyone has to support ALL of them ALWAYS... OR 2) Everyone has to support ONE technique (as well as anything else they want to ) OR 3) SOMEONE must maintain TRANSLATORS EVERYWHERE and on ALL SYSTEMS. It is not clear that these would exist or who would pay for them. The alternative is that text calls fail. We do it for voice (make sure it works everywhere or is translated) but market forces ensure that. For text how will we ensure this. I think it is #2 above - or else failures. Gregg -- ------------------------------ Gregg C Vanderheiden Ph.D. Professor - Ind. Engr. & BioMed Engr. Director - Trace R & D Center University of Wisconsin-Madison -----Original Message----- From: owner-toip@snowshore.com [mailto:owner-toip@snowshore.com] On Behalf Of Guido Gybels Sent: Thursday, July 01, 2004 2:27 AM To: RNIDMAIL.GWIA."A.vWijk@viataal.nl"; bcampbell@dynamicsoft.com; dean.willis@softarmor.com; gunnar.hellstrom@omnitor.se; hisham.khartabil@nokia.com Cc: adam@dynamicsoft.com; simple@ietf.org; stf267@etsi.org; toip@snowshore.com Subject: RE: Tiny ant vs big Mammoths, was RE: [Simple] Using MSRP for realtime text conversation All, <> Arnoud is, as usual, right. The very last thing we should even contemplate is introducing competing solutions for deaf people's communication needs. Remember what has happened in the PSTN and how as a direct result of that deaf andf hard of hearing people have hugely lost out in society. As far as t140/RTP is concerned: that was not randomly chosen, but after careful analysis of the problem in combination with looking at real-world constraints in terms of bandwidth, cost, practicality, etc. For all clarity: so far there is *NO* scientific data whatsoever that shows there is a more bandwidth effective solution than t140/RTP. So, if people don't want to agree with that, can I respectfully suggest they submit relevant data from repeatable experiments that we can peer review. There is a lot of misunderstanding about t140/RTP it seems. Arnoud and Gunnar are doing a great job in educating the community, so keep it up! Best wishes, Guido Guido Gybels Director of New Technologies RNID, 19-23 Featherstone Street London EC1Y 8SL, UK Tel +44(0)207 294 3713 Fax +44(0)207 296 8069 ************************************************************************ 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 ************************************************************************ - 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 Fri Jul 2 11:04: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 LAA11421 for ; Fri, 2 Jul 2004 11:04: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 1BgPaY-0001qY-RF for simple-archive@ietf.org; Fri, 02 Jul 2004 11:04:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgPZI-0001AM-00 for simple-archive@ietf.org; Fri, 02 Jul 2004 11:03:13 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BgPYE-0000e8-00; Fri, 02 Jul 2004 11:02:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgPHu-0002BJ-El; Fri, 02 Jul 2004 10:45:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bg7fw-0004NZ-95 for simple@megatron.ietf.org; Thu, 01 Jul 2004 15:56: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 PAA29098 for ; Thu, 1 Jul 2004 15:56: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 1Bg7fv-0006Rt-3Q for simple@ietf.org; Thu, 01 Jul 2004 15:56:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bg7ek-00063n-00 for simple@ietf.org; Thu, 01 Jul 2004 15:55:39 -0400 Received: from pmesmtp02.wcom.com ([199.249.20.2] helo=pmesmtp02.mci.com) by ietf-mx with esmtp (Exim 4.12) id 1Bg7dv-0005Ki-00 for simple@ietf.org; Thu, 01 Jul 2004 15:54:47 -0400 Received: from dgismtp02.wcomnet.com ([166.38.58.142]) by firewall.wcom.com (Iplanet MTA 5.2) with ESMTP id <0I06004MQV8X4Z@firewall.wcom.com> for simple@ietf.org; Thu, 01 Jul 2004 19:53:21 +0000 (GMT) Received: from dgismtp02.wcomnet.com by dgismtp02.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with SMTP id <0I0600301V6K2Y@dgismtp02.mcilink.com>; Thu, 01 Jul 2004 19:53:21 +0000 (GMT) Received: from ThinkpadT40 ([166.50.154.222]) by dgismtp02.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <0I060032OV8T47@dgismtp02.mcilink.com>; Thu, 01 Jul 2004 19:53:18 +0000 (GMT) Date: Thu, 01 Jul 2004 14:53:17 -0500 From: Henry Sinnreich Subject: RE: Tiny ant vs big Mammoths, was RE: [Simple] Using MSRP for real time text conversation In-reply-to: <200407011723.i61HNib0007415@smtp.eweka.nl> To: "'Arnoud van Wijk'" , "'Dean Willis'" Message-id: <0I060032PV8T47@dgismtp02.mcilink.com> Organization: MCI MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Thread-index: AcRfhSgGp69wz7mdQc2STF2vk1RzZAACN3aQAARB+kA= Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 02 Jul 2004 10:45:12 -0400 Cc: stf267@etsi.org, adam@dynamicsoft.com, simple@ietf.org, hisham.khartabil@nokia.com, toip@snowshore.com, gunnar.hellstrom@omnitor.se, 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.9 required=5.0 tests=AWL,MAILTO_TO_SPAM_ADDR, MISSING_OUTLOOK_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Arnoud, I have to agree with Dean's arguments and add that in dealing with real vendors and program managers, even what is 100% consensus in the IETF is "in the next generation" (in a next life probably) under consideration for them. So let's do a reality check and come back with these issues after we had a couple of months to check with vendors and program managers, so we don't spin our wheels here in the list. Henry Henry Sinnreich MCI 400 International Parkway Richardson, Texas 75081 USA -----Original Message----- From: owner-toip@snowshore.com [mailto:owner-toip@snowshore.com] On Behalf Of Arnoud van Wijk Sent: Thursday, July 01, 2004 12:24 PM To: 'Dean Willis' Cc: bcampbell@dynamicsoft.com; hisham.khartabil@nokia.com; gunnar.hellstrom@omnitor.se; adam@dynamicsoft.com; stf267@etsi.org; simple@ietf.org; toip@snowshore.com Subject: RE: Tiny ant vs big Mammoths, was RE: [Simple] Using MSRP for real time text conversation Dean, I said this to indicate that the method Interactive text is using for redundancy will only slightly increase the bandwidth. There are generally no more packets per second being sent with redundancy, the redundant generation is sent with the normal next batch of typed characters in the following packet! Think of a bus with 10 characters in it or a bus with 20 characters in it. It is then the same bus. It is not 1 packet per character! Unless you t y p e s o s l o w that there is a second or more between every character or so. :-) And if there is a congestion like you described with so many Interactive text streams. Normal congestion mechnism that are used for other RTP traffic will also apply for Interactive text. Also as stated in the 07 version of the RFC 2793 bis draft, if there is a good mechanism that prevents dropped packets..then that can be used instead of the 2 generations redundancy. So, I do not see the problem. Greetz Arnoud -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com] Sent: donderdag 1 juli 2004 18:04 To: A vWijk Cc: bcampbell@dynamicsoft.com; hisham.khartabil@nokia.com; gunnar.hellstrom@omnitor.se; adam@dynamicsoft.com; stf267@etsi.org; simple@ietf.org; toip@snowshore.com Subject: Re: Tiny ant vs big Mammoths, was RE: [Simple] Using MSRP for real time text conversation A vWijk wrote: > My comment marked with *** > *** 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 generations 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. > No, let's put it in the right perspective. Assume real-time text drives 2kb/s of bandwidth, or approximately 3 packets per second. Assume 20,000,000 users are running real-time-text sessions concurrently. This is approximately peak load for a really big mobile operator, and well below peak load for the Internet as a whole. Assume that real-time text continues to operate without the sort of congestion control that forces it to "back off" in the event of network congestion. We now have 40 billion (40E9) bits per second of non-bandwidth-controlled traffic out there, or approximately 60E6 packets per second. Will any of this ever traverse a link that is also trying to carry nice friendly TCP traffic? Will that link ever get congested? Will the real-time text "starve out" the TCP traffic when it does? The answers here are most likely "yes" . . . How can you assure us that this will never happen? Are operators going to build dedicated networks for real-time text? Are we going to use DS-markings to make real-time text low priority and discardable? Or, otherwise said, what gives real-time-text the "right" to cheat the rules and unfairly consume scarce network resources? Does any application have that right? -- Dean - 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 Fri Jul 2 11:05: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 LAA11547 for ; Fri, 2 Jul 2004 11:05: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 1BgPbO-0002EW-RV for simple-archive@ietf.org; Fri, 02 Jul 2004 11:05:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgPaC-0001XJ-00 for simple-archive@ietf.org; Fri, 02 Jul 2004 11:04:09 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BgPYx-0000rG-00; Fri, 02 Jul 2004 11:02:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgPHu-0002BO-QG; Fri, 02 Jul 2004 10:45:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgI8Z-0004cD-VS for simple@megatron.ietf.org; Fri, 02 Jul 2004 03:07: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 DAA11639 for ; Fri, 2 Jul 2004 03:07: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 1BgI8X-0006Hi-Pp for simple@ietf.org; Fri, 02 Jul 2004 03:07:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgI7W-0005wY-00 for simple@ietf.org; Fri, 02 Jul 2004 03:06:03 -0400 Received: from [217.158.120.227] (helo=rnidmail.rnid.org.uk) by ietf-mx with esmtp (Exim 4.12) id 1BgI6c-0005HK-00 for simple@ietf.org; Fri, 02 Jul 2004 03:05:06 -0400 Received: from JUPITER-MSG.rnid.org.uk (unverified) by rnidmail.rnid.org.uk (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 2 Jul 2004 08:04:04 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message Subject: RE: Tiny ant vs big Mammoths, was RE: [Simple] Using MSRP for realtime text conversation Date: Fri, 2 Jul 2004 08:08:41 +0100 Message-ID: <4818CE251FC66942A7EF35B92695246E01B22142@JUPITER-MSG.ad.rnid.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: RE: Tiny ant vs big Mammoths, was RE: [Simple] Using MSRP for realtime text conversation Thread-Index: AcRflnRGhBNmDq35Tv6r6MMC3ZXuVQAa4h/Q From: "Guido Gybels" To: "RNIDMAIL.GWIA.\"gv@trace.wisc.edu\"" , , , , , Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 02 Jul 2004 10:45:12 -0400 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.2 required=5.0 tests=AWL,EXCUSE_16,HTML_MESSAGE autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Gregg and others, Thanks for, as always, a helpful and well formulated response. To clarify: <> But that is why I used the phrase "solutions for deaf people's communicatio= n needs". For them it's not a matter of competition in the mainstream marke= t, with consumer choice and the economics that go with it. For deaf people, the choice is between the ability to communicate and the I= Nability to do so. While IM is already becoming more and more mainstream, i= t does not meet their requirements, so making sure there is something strea= med in place is of the greatest importance. And of course, once we do put s= omethign in place, we should not make the same mistakes as in the past and = use different protocols, because precisely this is what has been disenfranc= hising deaf people in terms of availability, interoperability, choice and c= ost. <> Agreed. Best wishes, Guido Guido Gybels Director of New Technologies RNID, 19-23 Featherstone Street London EC1Y 8SL, UK Tel +44(0)207 294 3713 Fax +44(0)207 296 8069 ************************************************************************ 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 =20 Registered Office 19-23 Featherstone Street=20 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 Fri Jul 2 11:05: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 LAA11613 for ; Fri, 2 Jul 2004 11:05: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 1BgPc0-0002Js-Hu for simple-archive@ietf.org; Fri, 02 Jul 2004 11:06:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgPas-0001tf-00 for simple-archive@ietf.org; Fri, 02 Jul 2004 11:04:51 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BgPZk-00019K-00; Fri, 02 Jul 2004 11: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 1BgPHv-0002BT-7P; Fri, 02 Jul 2004 10:45:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgIOu-0001mw-7P for simple@megatron.ietf.org; Fri, 02 Jul 2004 03:24: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 DAA12150 for ; Fri, 2 Jul 2004 03:23: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 1BgIOr-0004Go-Ub for simple@ietf.org; Fri, 02 Jul 2004 03:23:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgINx-0003wW-00 for simple@ietf.org; Fri, 02 Jul 2004 03:23:01 -0400 Received: from [217.158.120.227] (helo=rnidmail.rnid.org.uk) by ietf-mx with esmtp (Exim 4.12) id 1BgING-0003Lq-00 for simple@ietf.org; Fri, 02 Jul 2004 03:22:19 -0400 Received: from JUPITER-MSG.rnid.org.uk (unverified) by rnidmail.rnid.org.uk (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 2 Jul 2004 08:21:17 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message Subject: RE: Tiny ant vs big Mammoths, was RE: [Simple] Using MSRP for real time text conversation Date: Fri, 2 Jul 2004 08:25:57 +0100 Message-ID: <4818CE251FC66942A7EF35B92695246E01B61A05@JUPITER-MSG.ad.rnid.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: RE: Tiny ant vs big Mammoths, was RE: [Simple] Using MSRP for real time text conversation Thread-Index: AcRftJfncAsITg7EQOGPW0HW+dejdAAT7Fkw From: "Guido Gybels" To: "RNIDMAIL.GWIA.\"a.vwijk@viataal.nl\"" , , Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 02 Jul 2004 10:45:12 -0400 Cc: stf267@etsi.org, adam@dynamicsoft.com, hisham.khartabil@nokia.com, simple@ietf.org, toip@snowshore.com, gunnar.hellstrom@omnitor.se, 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.2 required=5.0 tests=AWL,EXCUSE_16 autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Arnoud, <> There is hope! I'm a pointy haired boss but I sure can see ahead! ;o) <> I don't know what audience you refer to, but ISTM that at least here in Eur= ope *most* mobile phone users use SMS. And use it a lot. As far as RTT is concerned: every single time we at RNID demonstrate the mo= bile textphone to the general public, people are thrilled by it. They want = one. And I'm talking about mainstream public here. So, yes, you are right when you say: "My message to the vendors is simple: implement interactive text. Text/t140= ." And it's up to us as a technical community to make sure that when the techn= ology is build, it is build in a sound way, i.e. not a bunch of incompatibl= e solutions, but something that is technically and economically viable AND = that meets the needs of deaf and hard of hearing people while at the same t= ime being able to offer something to the mainstream public. In that situati= on, everyone is a winner. You and I obviously understand that concept alrea= dy, so let's make sure everyone else does too ;o) Keep up the good work, Arnoud, you are making a *real* difference to people= 's lives! As ever, Guido Guido Gybels Director of New Technologies RNID, 19-23 Featherstone Street London EC1Y 8SL, UK Tel +44(0)207 294 3713 Fax +44(0)207 296 8069 ************************************************************************ 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 =20 Registered Office 19-23 Featherstone Street=20 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 Fri Jul 2 11:06: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 LAA11679 for ; Fri, 2 Jul 2004 11:06: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 1BgPcb-0002f2-Hu for simple-archive@ietf.org; Fri, 02 Jul 2004 11:06:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgPbV-0002Fl-00 for simple-archive@ietf.org; Fri, 02 Jul 2004 11:05:30 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BgPaO-0001UK-00; Fri, 02 Jul 2004 11:04:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgPHv-0002BY-Oz; Fri, 02 Jul 2004 10:45:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgIQp-0002VP-HC for simple@megatron.ietf.org; Fri, 02 Jul 2004 03:25: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 DAA12168 for ; Fri, 2 Jul 2004 03:25: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 1BgIQn-0004v8-EU for simple@ietf.org; Fri, 02 Jul 2004 03:25:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgIPo-0004an-00 for simple@ietf.org; Fri, 02 Jul 2004 03:24:57 -0400 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1BgIOq-0004GC-00 for simple@ietf.org; Fri, 02 Jul 2004 03:23:56 -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 i627No628200; Fri, 2 Jul 2004 10:23:51 +0300 (EET DST) X-Scanned: Fri, 2 Jul 2004 10:22:57 +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 i627Mv5j009786; Fri, 2 Jul 2004 10:22:57 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00NdDY4u; Fri, 02 Jul 2004 10:22:55 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 i627MgH27549; Fri, 2 Jul 2004 10:22:42 +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, 2 Jul 2004 10:22:35 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Tiny ant vs big Mammoths, was RE: [Simple] Using MSRP for realtime text conversation x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Date: Fri, 2 Jul 2004 10:22:35 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7023EEA8C@esebe019.ntc.nokia.com> Thread-Topic: RE: Tiny ant vs big Mammoths, was RE: [Simple] Using MSRP for realtime text conversation Thread-Index: AcRflnRGhBNmDq35Tv6r6MMC3ZXuVQAa4h/QAADARiA= To: , , , , , X-OriginalArrivalTime: 02 Jul 2004 07:22:35.0336 (UTC) FILETIME=[58C0F480:01C46005] Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 02 Jul 2004 10:45:12 -0400 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.9 required=5.0 tests=AWL,EXCUSE_16,HTML_MESSAGE, MAILTO_TO_SPAM_ADDR,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Guido Gybels [mailto:Guido.Gybels@rnid.org.uk] > Sent: 02.July.2004 10:09 > To: RNIDMAIL.GWIA."gv@trace.wisc.edu"; bcampbell@dynamicsoft.com; > dean.willis@softarmor.com; gunnar.hellstrom@omnitor.se;=20 > Khartabil Hisham > (Nokia-TP-MSW/Helsinki); > IMCEAGWISE-RNIDMAIL+2EGWIA+2E+22A+2EvWijk+40viataal+2Enl+22@rn > id.org.uk > Cc: adam@dynamicsoft.com; simple@ietf.org; stf267@etsi.org; > toip@snowshore.com > Subject: RE: Tiny ant vs big Mammoths, was RE: [Simple] Using MSRP for > realtime text conversation >=20 >=20 > Gregg and others, >=20 > Thanks for, as always, a helpful and well formulated=20 > response. To clarify: >=20 > < technologies. I don't > see it as bad theoretically. Difference facilitates evolution.>> >=20 > But that is why I used the phrase "solutions for deaf=20 > people's communication needs". For them it's not a matter of=20 > competition in the mainstream market, with consumer choice=20 > and the economics that go with it. >=20 > For deaf people, the choice is between the ability to=20 > communicate and the INability to do so. Why are deaf people at a disadvantage if they need to use IM the way it = is today instead of real-time text for textual conversations? I believe you are talking about voice to text translation, and that is = not instant messaging. /Hisham > While IM is already=20 > becoming more and more mainstream, it does not meet their=20 > requirements, so making sure there is something streamed in=20 > place is of the greatest importance. And of course, once we=20 > do put somethign in place, we should not make the same=20 > mistakes as in the past and use different protocols, because=20 > precisely this is what has been disenfranchising deaf people=20 > in terms of availability, interoperability, choice and cost. >=20 > < failures>> >=20 > Agreed. >=20 > Best wishes, >=20 > Guido >=20 > Guido Gybels > Director of New Technologies >=20 > RNID, 19-23 Featherstone Street > London EC1Y 8SL, UK > Tel +44(0)207 294 3713 > Fax +44(0)207 296 8069 >=20 >=20 >=20 > ************************************************************** > ********** > 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. >=20 > If you are not the intended recipient you are advised that any > use, dissemination, forwarding, printing or copying of this > email is strictly prohibited. >=20 > If you have received this email in error please notify the RNID > Helpdesk by telephone on: +44 (0) 207 296 8282. >=20 > The Royal National Institute for Deaf People =20 > Registered Office 19-23 Featherstone Street=20 > London EC1Y 8SL No. 454169 (England) > Registered Charity No. 207720 > ************************************************************** > ********** >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jul 2 11:07: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 LAA11784 for ; Fri, 2 Jul 2004 11:07: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 1BgPdY-00032K-Vd for simple-archive@ietf.org; Fri, 02 Jul 2004 11:07:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgPcM-0002dI-00 for simple-archive@ietf.org; Fri, 02 Jul 2004 11:06:23 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BgPbD-0001s9-00; Fri, 02 Jul 2004 11:05:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgPHw-0002Bd-97; Fri, 02 Jul 2004 10: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 1BgJ2g-0007mZ-DA for simple@megatron.ietf.org; Fri, 02 Jul 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 EAA13874 for ; Fri, 2 Jul 2004 04:05: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 1BgJ2c-0003Ps-0m for simple@ietf.org; Fri, 02 Jul 2004 04:05:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgJ1a-00033u-00 for simple@ietf.org; Fri, 02 Jul 2004 04:03:59 -0400 Received: from [217.158.120.227] (helo=rnidmail.rnid.org.uk) by ietf-mx with esmtp (Exim 4.12) id 1BgJ0Y-0002OO-00 for simple@ietf.org; Fri, 02 Jul 2004 04:02:54 -0400 Received: from JUPITER-MSG.rnid.org.uk (unverified) by rnidmail.rnid.org.uk (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 2 Jul 2004 09:01:52 +0100 Subject: RE: Tiny ant vs big Mammoths, was RE: [Simple] Using MSRP for realtime text conversation Date: Fri, 2 Jul 2004 09:02:15 +0100 Message-ID: <4818CE251FC66942A7EF35B92695246E01B61A07@JUPITER-MSG.ad.rnid.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: RE: Tiny ant vs big Mammoths, was RE: [Simple] Using MSRP for realtime text conversation Thread-Index: AcRgBZNA+voGsDRwRtSdMSzEiWNnSQAA+OAA From: "Guido Gybels" content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 To: "RNIDMAIL.GWIA.\"hisham.khartabil@nokia.com\"" , , , , Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 02 Jul 2004 10:45:12 -0400 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.2 required=5.0 tests=AWL,EXCUSE_16 autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Hisham, <> To be perfectly honest, we have been through this whole discussion many tim= es in the past. I recently recirculated a paper that tries to summarise the= issues. Because it is not an alternative to voice. Hearing people use IM as a *diff= erent* tool, they have the *choice* to select between voice, email, SMS, IM= , etc. Each one of these communication methods has its own characteristics,= its own level of interactivity, etc. So, hearing people select amongst the= se offerings based on what they want to do, the circumstances, etc. Deaf pe= ople will behave the same: sometimes they will use email, they certainly us= e SMS a lot, etc. However, deaf people can't use voice. So, they have no access to one of the most important communication tools in= the Information Society. That non-access disenfranchises them enormously, = in employment, health, education, social life and entertainment alike. Interactive text is the text equivalent of what voice is to hearing people.= So, making it available is bringing deaf people on a more equal basis in s= ociety. Just as much as IM is NOT a REPLACEMENT for voice for hearing people (but r= ather an ADDITIONAL communication method), it can NOT be a REPLACEMENT for = interactive text for deaf people. No hearing people would get it in their r= ight minds to suggest we scrap voice because of the existence of IM. Yet, t= hat is precisely what some people suggest deaf people should accept. That w= ould clearly not be the right way forward. The fact that deaf people do use= other forms of communication, like email or SMS is no more an argument for= getting rid of interactive texting as the use of email and SMS by hearing = people is to get rid of voice telephony. Best regards, Guido Guido Gybels Director of New Technologies RNID, 19-23 Featherstone Street London EC1Y 8SL, UK Tel +44(0)207 294 3713 Fax +44(0)207 296 8069 ************************************************************************ 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 =20 Registered Office 19-23 Featherstone Street=20 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 Fri Jul 2 11:07: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 LAA11822 for ; Fri, 2 Jul 2004 11:07: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 1BgPdg-000339-2c for simple-archive@ietf.org; Fri, 02 Jul 2004 11:07:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgPcW-0002eb-00 for simple-archive@ietf.org; Fri, 02 Jul 2004 11:06:33 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BgPbT-0001ua-00; Fri, 02 Jul 2004 11:05:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgPHw-0002Bi-Pl; Fri, 02 Jul 2004 10: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 1BgJV1-0001tK-Ja for simple@megatron.ietf.org; Fri, 02 Jul 2004 04:34: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 EAA14947 for ; Fri, 2 Jul 2004 04:34: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 1BgJUz-0005ox-Cs for simple@ietf.org; Fri, 02 Jul 2004 04:34:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgJU4-0005Rw-00 for simple@ietf.org; Fri, 02 Jul 2004 04:33:25 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1BgJTA-00054t-00 for simple@ietf.org; Fri, 02 Jul 2004 04:32:29 -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 i628Rm228104; Fri, 2 Jul 2004 11:27:48 +0300 (EET DST) X-Scanned: Fri, 2 Jul 2004 11:27:04 +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 i628R4h9021043; Fri, 2 Jul 2004 11:27:04 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00uQf3hh; Fri, 02 Jul 2004 11:27: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 i628QuH02775; Fri, 2 Jul 2004 11:26:56 +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); Fri, 2 Jul 2004 11:26:55 +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] RE: [Sipping] RE: text/T140 andaudio/t140 was:[avt]Comments/questions on draft-ietf-av x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Date: Fri, 2 Jul 2004 11:26:55 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7023EEA94@esebe019.ntc.nokia.com> Thread-Topic: [Simple] RE: [Sipping] RE: text/T140 andaudio/t140 was:[avt]Comments/questions on draft-ietf-av Thread-Index: AcRZ7oAhxcB0CC6GT5qLh6XIsdQ+iQAT8qmAABaV8PABXTxhMA== To: , , , X-OriginalArrivalTime: 02 Jul 2004 08:26:55.0362 (UTC) FILETIME=[55822E20:01C4600E] Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 02 Jul 2004 10:45:12 -0400 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.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable There is no hostility here. We are negotiating the usefulness of it. = Some people prefer IM, others prefer interactive text, so it might an = additional value service or a waste of implementer's time. No one knows. I would never, for example, use real time text since I, like many people = in the world, am a very slow typist, make many typos and change my mind = a lot about what I should say or how I should say it. One comment inline... > -----Original Message----- > From: simple-bounces@ietf.org=20 > [mailto:simple-bounces@ietf.org]On Behalf > Of ext Arnoud van Wijk > Sent: 25.June.2004 12:51 > To: 'Paul E. Jones'; 'Paul Kyzivat'; 'Guido Gybels' > Cc: fluffy@cisco.com; simple@ietf.org; gv@trace.wisc.edu; > toip@snowshore.com; gunnar.hellstrom@omnitor.se; smundra@telogy.com > Subject: RE: [Simple] RE: [Sipping] RE: text/T140 andaudio/t140 > was:[avt]Comments/questions on draft-ietf-av >=20 >=20 > Good point Paul! >=20 > Also..I want to point it out again... > WE ARE NOT TALKING ABOUT REPLACING INSTANT MESSAGING WITH=20 > INTERACTIVE TEXT! >=20 > Most of you already know that. But just today I met another=20 > person who still > thinks Interactive text is to replace IM. >=20 > I do not understand the hostility from several IM people.=20 > Interactive text > is even going to make IM better! See it as an additional=20 > valuable service > for IM. > Users exchange IM messages, and then a discussion starts,=20 > they switch over > into real-time chat mode. Discuss things, work out plans in=20 > real-time. Then > end the real-time chat mode. > And the next 2 hours they exchange a few IM messages. What makes this character-by-character (or x number of characters for = 300ms) more interactive than IM in the scenario you describe above = (besides the fact that you will see all my spelling mistakes, that I = typed a message then changed my mind and deleted it)? >=20 > And I do hear from many ICQ users who miss the real-time chat=20 > mode. That was > easier to use. And with SIP, server load is not an issue=20 > anymore, which > caused ICQ to scrap this option. >=20 > Cheers >=20 > Arnoud >=20 >=20 > -----Original Message----- > From: owner-toip@snowshore.com=20 > [mailto:owner-toip@snowshore.com] On Behalf > Of Paul E. Jones > Sent: vrijdag 25 juni 2004 1:16 > To: 'Paul Kyzivat'; 'Guido Gybels' > Cc: gunnar.hellstrom@omnitor.se; gv@trace.wisc.edu; fluffy@cisco.com; > simple@ietf.org; toip@snowshore.com; smundra@telogy.com;=20 > a.vwijk@viataal.nl > Subject: RE: [Simple] RE: [Sipping] RE: text/T140 and audio/t140 > was:[avt]Comments/questions on draft-ietf-av >=20 > Paul, >=20 > > I accept your point that IM isn't suitable for a bunch of the > > communication needs of the hearing impaired. (Among=20 > others.) But I also > > want you to accept that RTT isn't a suitable substitute for=20 > IM in the > > applications that millions (actually probably 10s or 100s=20 > of millions) > > of people use it everyday. >=20 > ICQ once had a mode wherein one could send=20 > character-at-a-time and it worked > pretty well (may still be in there). What was nice about it=20 > was that one > could begin his/her reply even before the other person=20 > finished his/her > message. I found the two-way exchange much better than=20 > today's IM systems, > as there was virtually no delay-- it was real-time. >=20 > One of the reasons why the IM systems today have problems in=20 > scaling is that > they have to interface with servers that handle message=20 > exchange between all > those users you spoke about. The farm of servers to run the=20 > existing IM > systems do a lot of work and it's not a trivial task. The=20 > problem with the > model is that farm of central servers that receive and=20 > dispatch messages. > (Perhaps SIMPLE has done something to improve on the current state of > technology, but I'll confess that I don't know.) >=20 > If we can solve the scalability issues required to handle=20 > lots of voice and > video streams flowing between users, then it would not take a=20 > great leap to > do the same thing for text (literally). There may be more=20 > text sessions, > but the only change in resource requirements from blocks of=20 > text and RTT are > the resources required to process messages (as there are more=20 > RTT packets). > For voice, those fifty or so packets per second would not flow through > centralized servers and neither should the text. If the=20 > system operated > allowing media to flow point-to-point, the RTT would scale. =20 > I guess the > question is whether we will be able to allow audio to flow=20 > point-to-point or > whether the FWs, NATs, "session border controllers", and such=20 > devices will > inhibit that. >=20 > Paul >=20 >=20 > - > This list is maintained by Snowshore Networks -=20 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 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jul 2 11:09: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 LAA11927 for ; Fri, 2 Jul 2004 11:09: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 1BgPfA-0003cE-IC for simple-archive@ietf.org; Fri, 02 Jul 2004 11:09:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgPdm-00033w-00 for simple-archive@ietf.org; Fri, 02 Jul 2004 11:07:50 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BgPcm-0002aX-00; Fri, 02 Jul 2004 11:06:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgPHx-0002Bn-Al; Fri, 02 Jul 2004 10:45:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgJwz-0002oh-9r for simple@megatron.ietf.org; Fri, 02 Jul 2004 05:03: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 FAA18845 for ; Fri, 2 Jul 2004 05:03: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 1BgJwx-0007lP-4v for simple@ietf.org; Fri, 02 Jul 2004 05:03:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgJw3-0007ME-00 for simple@ietf.org; Fri, 02 Jul 2004 05:02:19 -0400 Received: from [217.158.120.227] (helo=rnidmail.rnid.org.uk) by ietf-mx with esmtp (Exim 4.12) id 1BgJuh-0006V2-00 for simple@ietf.org; Fri, 02 Jul 2004 05:00:55 -0400 Received: from JUPITER-MSG.rnid.org.uk (unverified) by rnidmail.rnid.org.uk (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 2 Jul 2004 09:59:51 +0100 content-class: urn:content-classes:message Subject: RE: Tiny ant vs big Mammoths, was RE: [Simple] Using MSRP forrealtime text conversation Date: Fri, 2 Jul 2004 10:00:10 +0100 Message-ID: <4818CE251FC66942A7EF35B92695246E01B61A08@JUPITER-MSG.ad.rnid.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: RE: Tiny ant vs big Mammoths, was RE: [Simple] Using MSRP forrealtime text conversation Thread-Index: AcRgDTNr2YULib9ARmqGbNt4UUSW+QAA6wKQ From: "Guido Gybels" X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 To: "RNIDMAIL.GWIA.\"hisham.khartabil@nokia.com\"" Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 02 Jul 2004 10:45:12 -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.2 required=5.0 tests=AWL,EXCUSE_16 autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Hisham, <> I remember the days when different email systems didn't talk to each other.= It didn't have real mainstream appeal. When I got my first GSM mobile phon= e in 1994, SMS didn't work across network boundaries. It didn't have much a= ppeal. Now that email and SMS are, from a user's perspective, fairly seamless: the= y are available almost everywhere, even on the move, it's interoperable bet= ween handsets and it traverses network boundaries just fine, these have bec= ome mainstream provisions. IM has similar problems. So, the gradual converg= ence in that technology is good. I suspect that for quite a while though, t= here will be different, competing systems. However, because this is a mains= tream technology, the pressure on various implementers and service provider= s to offer interoperability between their systems will increase and if IM i= s really to become as widespread as voice telephony or email, it will have = to offer a similar experience in terms of interworking between various netw= orks. For interactive texting, something similar can be argued, with the big diff= erence that if it is not available, it is not just an inconvenience, it is = actually disenfranchising deaf and hard of hearing people who rely on text. <> You can use RTT as an alternative to IM. But not the other way around. That= is not to say that I am not interested in IM. Just that if you have to mak= e a choice, the more inclusive one of the two is RTT. How manufacturers bui= ld there devices, their UI etc is mostly up to them. Different manufacturer= s have different views on how to position devices etc. As someone who has been working on UI issues for about 20 years, I would ar= gue that what users want is actually something which is easy to use, doesn'= t require different ways of working for different functions and meets their= needs. IMHO that means that integrating text messaging into user friendly,= mostly integrated applications is wise. Whether or not the marketing boys = are bothered by that is another question of course! Non technical users don't think segmented. They "use a mobile phone". Wheth= er or not they talk into it or send SMS, such users don't really bother wit= h the logical and technical analysis of how applications/protocols and the = like are technically separated and implemented. From a user's perspective, = they have a mobile phone and they use it for different things. Users want t= hings that are intuitive and easy to use. Whether or not underneath it's us= ing two modules and separate protocols, the user doesn't care. To argue that because IM and RTT are different technologies, they should al= so be visible to the user as clearly different things is a techie/scientifi= c viewpoint, it does not IMHO relate to average users at all. Best regards, Guido Guido Gybels Director of New Technologies RNID, 19-23 Featherstone Street London EC1Y 8SL, UK Tel +44(0)207 294 3713 Fax +44(0)207 296 8069 ************************************************************************ 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 =20 Registered Office 19-23 Featherstone Street=20 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 Fri Jul 2 11:10: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 LAA12299 for ; Fri, 2 Jul 2004 11:10: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 1BgPgN-0004EK-Ow for simple-archive@ietf.org; Fri, 02 Jul 2004 11:10:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgPfH-0003iZ-00 for simple-archive@ietf.org; Fri, 02 Jul 2004 11:09:23 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BgPdz-00031y-00; Fri, 02 Jul 2004 11:08:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgPHx-0002Bs-SF; Fri, 02 Jul 2004 10:45:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgK1i-0004UD-9Q for simple@megatron.ietf.org; Fri, 02 Jul 2004 05:08: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 FAA19004 for ; Fri, 2 Jul 2004 05:08: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 1BgK1g-0001g0-0d for simple@ietf.org; Fri, 02 Jul 2004 05:08:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgK0a-0001Jb-00 for simple@ietf.org; Fri, 02 Jul 2004 05:07:01 -0400 Received: from [217.158.120.227] (helo=rnidmail.rnid.org.uk) by ietf-mx with esmtp (Exim 4.12) id 1BgJzW-0000fU-00 for simple@ietf.org; Fri, 02 Jul 2004 05:05:54 -0400 Received: from JUPITER-MSG.rnid.org.uk (unverified) by rnidmail.rnid.org.uk (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 2 Jul 2004 10:04:53 +0100 content-class: urn:content-classes:message Subject: RE: [Simple] RE: [Sipping] RE: text/T140 andaudio/t140 was:[avt]Comments/questions on draft-ietf-av Date: Fri, 2 Jul 2004 10:05:20 +0100 Message-ID: <4818CE251FC66942A7EF35B92695246E01B22149@JUPITER-MSG.ad.rnid.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: RE: [Simple] RE: [Sipping] RE: text/T140 andaudio/t140 was:[avt]Comments/questions on draft-ietf-av Thread-Index: AcRgDww2V7Ixn1MFTA2FYNSNd+ppYwABFU6Q From: "Guido Gybels" X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 To: "RNIDMAIL.GWIA.\"hisham.khartabil@nokia.com\"" , , , Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 02 Jul 2004 10:45:12 -0400 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.2 required=5.0 tests=AWL,EXCUSE_16 autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Hisham, <> Precisely that argument is seriously flawed IMHO. In reality, the overall m= ajority of users only has access to IM, not RTT. To argue therefore that a = substantial amount of people actually prefer IM over RTT is IMHO flawed log= ic. Guido ************************************************************************ 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 =20 Registered Office 19-23 Featherstone Street=20 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 Fri Jul 2 11:11: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 LAA12361 for ; Fri, 2 Jul 2004 11:11: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 1BgPhA-0004b7-Uc for simple-archive@ietf.org; Fri, 02 Jul 2004 11:11:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgPgB-00046U-00 for simple-archive@ietf.org; Fri, 02 Jul 2004 11:10:20 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BgPev-0003Q3-00; Fri, 02 Jul 2004 11:09:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgPHy-0002Bx-BR; Fri, 02 Jul 2004 10:45:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgKQc-0006Re-KH for simple@megatron.ietf.org; Fri, 02 Jul 2004 05:33: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 FAA20296 for ; Fri, 2 Jul 2004 05:33: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 1BgKQa-0002pp-1k for simple@ietf.org; Fri, 02 Jul 2004 05:33:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgKPM-0002RA-00 for simple@ietf.org; Fri, 02 Jul 2004 05:32:37 -0400 Received: from [217.158.120.227] (helo=rnidmail.rnid.org.uk) by ietf-mx with esmtp (Exim 4.12) id 1BgKOT-0001za-00 for simple@ietf.org; Fri, 02 Jul 2004 05:31:41 -0400 Received: from JUPITER-MSG.rnid.org.uk (unverified) by rnidmail.rnid.org.uk (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 2 Jul 2004 10:30:39 +0100 content-class: urn:content-classes:message Subject: RE: Tiny ant vs big Mammoths, was RE: [Simple] Using MSRPforrealtime text conversation Date: Fri, 2 Jul 2004 10:31:06 +0100 Message-ID: <4818CE251FC66942A7EF35B92695246E01B2214B@JUPITER-MSG.ad.rnid.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: RE: Tiny ant vs big Mammoths, was RE: [Simple] Using MSRPforrealtime text conversation Thread-Index: AcRgFkQZ2pbhuTMlS+alQKgIXi7quwAAHjtA From: "Guido Gybels" X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 To: "RNIDMAIL.GWIA.\"hisham.khartabil@nokia.com\"" Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 02 Jul 2004 10:45:12 -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.2 required=5.0 tests=AWL,EXCUSE_16,HTML_MESSAGE autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Hisham, <> I actually didn't say that. My interest is in making sure t140/RTP get impl= emented as a basic provision in as much devices as possible. I'm sure the m= arket will deal with IM issues. <> I haven't said anything about that. Again, you are confusing the user's per= spective with the technical one. It is up to the technical community to loo= k at what the best approach is to make sure that t140/RTP gets implemented = as widely as possible. Whether or not it presents itself to the user as one= "application" or not is less of an issue to me. <> It's a matter of choice. If both of you have text-to-text available then yo= u could use it. Or the other. Or both. Relay services exist to transcode be= tween otherwise non compatible modes and thereby to overcome communication = barriers. Back to back text could be quite useful for all people, not just deaf peopl= e. It's a matter of choice and equality. Guido ************************************************************************ 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 =20 Registered Office 19-23 Featherstone Street=20 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 Fri Jul 2 11:47: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 LAA14450 for ; Fri, 2 Jul 2004 11:47: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 1BgQGT-0000oi-Ov for simple-archive@ietf.org; Fri, 02 Jul 2004 11:47:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgQEG-00000X-00 for simple-archive@ietf.org; Fri, 02 Jul 2004 11:45:33 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BgQCb-0007Iw-00; Fri, 02 Jul 2004 11:43:49 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BgQ5z-0002sl-6A; Fri, 02 Jul 2004 11:36:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgPqb-0006H0-9s; Fri, 02 Jul 2004 11:21:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgPaL-0001aG-Uo for simple@megatron.ietf.org; Fri, 02 Jul 2004 11:04: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 LAA11409 for ; Fri, 2 Jul 2004 11:04: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 1BgPaL-0001ae-15 for simple@ietf.org; Fri, 02 Jul 2004 11:04:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgPZ7-00016n-00 for simple@ietf.org; Fri, 02 Jul 2004 11:03:02 -0400 Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx with esmtp (Exim 4.12) id 1BgPXv-0000V4-00 for simple@ietf.org; Fri, 02 Jul 2004 11:01: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 i62F1Hou016886; Fri, 2 Jul 2004 10:01:17 -0500 (CDT) Received: by eamrcnt750.exu.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Fri, 2 Jul 2004 10:00:12 -0500 Message-ID: From: "George Foti (QA/EMC)" To: "'Miguel Garcia'" Subject: RE: [Simple] RE: XCAP Directory: Large response ? Date: Fri, 2 Jul 2004 09:53:03 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Cc: Jonathan Rosenberg , 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 Comments in line Miguel. > -----Original Message----- > From: Miguel Garcia [mailto:Miguel.An.Garcia@nokia.com] > Sent: Friday, July 02, 2004 9:03 AM > To: George Foti (QA/EMC) > Cc: Henrik Albertsson (KI/EAB); Jonathan Rosenberg; simple@ietf.org > Subject: Re: [Simple] RE: XCAP Directory: Large response ? > > > George: > > I don't like this solution. It requires the XCAP server to do > a "trial > and error" of the XML document that will be send to the user. > Build an > XML document with "n" entries, if the size of the document exceeds X > bytes, start reducing the number entries, one by one, until > the result > is less than X bytes. That's awful. > It is a managed complexity, and mostly implementation. With some meta data, it can be manageable. > I believe we have two constraints here: one is the display > size of the > device and the other is the memory of the device. I believe a > device may > want to get a page of entries it can render in the display, > then release > the memory, and request a new page. > I addition to what you state, anything that is returned has to be usable and we can do operations n them. > I don't think this can be achieved by selecting the size in > bytes, but > with the number of entries in a list. > That is true in certain cases not all cases. We cannot put a solution oly for those cases. The most common case is where the user dont know what to expect, i.e he or she has no clue on how many entries are in there. I am afraid that there are no simple solutions unless we do away with some requirements. > - Miguel > > > George Foti (QA/EMC) wrote: > > > A potential solution is for a client to be able to ask > either of the following questions: > > 1) Give me a *maximum* of X bytes ranges Z onwards > > 2) Give me a *maximum* of X bytes ranges Y-Z > > > > The XCAP server should return in a successfull response an > XML document that is schema compliant that does not exceed > the *maximum* range. The client can then perform operations > on such a document. > > A request could fail for multiple reasons, no document > meets the maximum length, server does not understand the > schema, etcc.. > > > > The above implies that XCAP servers must understand > different schemas, but that may be unavoidable for some operations. > > The other thing, I dont know if HTTP headers do allow for the above. > > > > Rgds/gf > > > > > > > > > >>-----Original Message----- > >>From: simple-bounces@ietf.org > >>[mailto:simple-bounces@ietf.org]On Behalf > >>Of Henrik Albertsson (KI/EAB) > >>Sent: Friday, July 02, 2004 6:38 AM > >>To: 'Miguel Garcia'; ext Jonathan Rosenberg > >>Cc: simple@ietf.org > >>Subject: [Simple] RE: XCAP Directory: Large response ? > >> > >> > >>I agree with you Miguel that the "give me X byte" solution is > >>not usable for the reasons you mentioned. However most likely > >>the XCAP client will operate on a well known AUDI and have > >>knowledge about what the structure of the XCAP document is so > >>it can roughly estimate what size 30 elements would be. > >> > >>Is it so that when specifying a XCAP document we also need to > >>define what element will be used for indexing when asking for > >>a range of elements? > >> > >>Regards > >>/Henrik > >> > >> > >> > >> > >>>-----Original Message----- > >>>From: Miguel Garcia [mailto:Miguel.An.Garcia@nokia.com] > >>>Sent: den 2 juli 2004 12:14 > >>>To: ext Jonathan Rosenberg > >>>Cc: Henrik Albertsson (KI/EAB); simple@ietf.org > >>>Subject: Re: XCAP Directory: Large response ? > >>> > >>> > >>>Jonathan Rosenberg wrote: > >>> > >>> > >>>>I would propose that we not put this functionality in xcap > >>> > >>>itself, but > >>> > >>>>use the existing HTTP mechanisms. I will note that these > >>> > >>>mechanisms are > >>> > >>>>*byte* oriented, and not XML oriented. Thus, you may cut an > >>> > >>>element off > >>> > >>>>in the middle by asking for the first 50 bytes. However, if > >>> > >>>your main > >>> > >>>>concern is bandwidth or latency, then bytes are much more > >>> > >>>significant of > >>> > >>>>a measure than elements. If I say, "give me 30 elements", > >>> > >>>that could be > >>> > >>>>30 bytes or 30MB, depennding on the amount of data in > >> > >>each element. > >> > >>>>-Jonathan R. > >>>> > >>> > >>>Jonathan, I think the HTTP byte ranges will not work. Let's say I > >>>request a long document, and I request bytes 1 to 10000. The > >>>HTTP server > >>>will cut the XML document exacltly when the number of bytes > >>>has reached > >>>the count, and will send it to the XCAP client. The XCAP > >> > >>client can't > >> > >>>check if the document is well-formed, not even check if it > is valid > >>>according to the XML schema. As a consequence, it won't > >> > >>display it to > >> > >>>the user, or dare to do any operation on it. The only thing > >> > >>the XCAP > >> > >>>client can do is to request the next byte range. > >>> > >>>I am concerned with the limited amount of memory a device > >> > >>might have, > >> > >>>AND the bandwidth. The latter can be solved with byte > >> > >>ranges, but not > >> > >>>the former. > >>> > >>>However, if we provide a mechanism to request ranges of > >> > >>entries in a > >> > >>>list, this will solve the problem: the XCAP server create a > >> > >>valid XML > >> > >>>document that complies with the schema and send it to the > >>>XCAP client. > >>>The client can request additional ranges once it has freed > >>>the memory. > >>>The drawback is that we cannot accurately control the > bandwidth (we > >>>don't know how many bytes will come), but I don't think this > >>>is a big issue. > >>> > >>>- 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 > >> > > -- > 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 Fri Jul 2 14:03: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 OAA23841 for ; Fri, 2 Jul 2004 14:03: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 1BgSNe-0000wR-Eg for simple-archive@ietf.org; Fri, 02 Jul 2004 14:03:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgSLE-000038-00 for simple-archive@ietf.org; Fri, 02 Jul 2004 14:00:52 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BgSJa-0007IG-01; Fri, 02 Jul 2004 13:59:10 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BgS9K-0005Sy-6P; Fri, 02 Jul 2004 13:48:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgRvA-0003H6-Di; Fri, 02 Jul 2004 13:33:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgRqC-0000i5-G4 for simple@megatron.ietf.org; Fri, 02 Jul 2004 13:28: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 NAA21858 for ; Fri, 2 Jul 2004 13:28: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 1BgRqB-00054g-E9 for simple@ietf.org; Fri, 02 Jul 2004 13:28:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgRpD-0004kG-00 for simple@ietf.org; Fri, 02 Jul 2004 13:27:48 -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 1BgRof-0004Os-00 for simple@ietf.org; Fri, 02 Jul 2004 13:27:13 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 02 Jul 2004 10:31:59 +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 i62HQZSc015236; Fri, 2 Jul 2004 10:26:38 -0700 (PDT) Received: from cisco.com ([161.44.79.239]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AJW52774; Fri, 2 Jul 2004 13:26:34 -0400 (EDT) Message-ID: <40E59ACA.8050507@cisco.com> Date: Fri, 02 Jul 2004 13:26:34 -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 andaudio/t140 was:[avt]Comments/questions on draft-ietf-av References: <4818CE251FC66942A7EF35B92695246E01B22149@JUPITER-MSG.ad.rnid.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: fluffy@cisco.com, paulej@packetizer.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.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Guido Gybels wrote: > Hisham, > > <> > > Precisely that argument is seriously flawed IMHO. In reality, the overall majority of users only has access to IM, not RTT. To argue therefore that a substantial amount of people actually prefer IM over RTT is IMHO flawed logic. To argue the contrary is also flawed. This is also mixed with other features of the protocols and clients that support them. If I can send files with IM, have presence with IM, etc. that that also biases the discussion. To get beyond this, somebody will have to implement RTT in a client and protocol that support all those other things. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jul 2 14:04: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 OAA24067 for ; Fri, 2 Jul 2004 14:04: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 1BgSOO-0001Jq-VS for simple-archive@ietf.org; Fri, 02 Jul 2004 14:04:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgSMC-0000HR-00 for simple-archive@ietf.org; Fri, 02 Jul 2004 14:01:53 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BgSJe-0007IG-02; Fri, 02 Jul 2004 13:59:14 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BgS4z-0005L8-EJ; Fri, 02 Jul 2004 13:44:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgRuB-0002vC-MT; Fri, 02 Jul 2004 13:32:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgRnE-0008LV-67 for simple@megatron.ietf.org; Fri, 02 Jul 2004 13:25: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 NAA21662 for ; Fri, 2 Jul 2004 13:25: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 1BgRnD-00043z-4y for simple@ietf.org; Fri, 02 Jul 2004 13:25:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgRmI-0003jE-00 for simple@ietf.org; Fri, 02 Jul 2004 13:24:47 -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 1BgRlV-0003KA-00 for simple@ietf.org; Fri, 02 Jul 2004 13:23:57 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 02 Jul 2004 10:23:33 -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 i62HNOSc012736; Fri, 2 Jul 2004 10:23:25 -0700 (PDT) Received: from cisco.com ([161.44.79.239]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AJW52580; Fri, 2 Jul 2004 13:23:23 -0400 (EDT) Message-ID: <40E59A0B.4020901@cisco.com> Date: Fri, 02 Jul 2004 13:23:23 -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: Tiny ant vs big Mammoths, was RE: [Simple] Using MSRP forrealtime text conversation References: <4818CE251FC66942A7EF35B92695246E01B61A08@JUPITER-MSG.ad.rnid.org> 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 Guido Gybels wrote: > > You can use RTT as an alternative to IM. But not the other way around. I understand your point, but I don't think I fully agree with it. Let me give an analogy: email is to IM as IM is to RTT. I can use email as a substitute for IM, but it is clumsy and annoying. I can use IM as a substitute for email, but it is clumsy and annoying. Similarly I can use RTT as a substitute for IM but it is clumsy and annoying, and visa versa. When you compare X with Y you find each gains something and loses something compared to the other. When you substitute one for another you notice what you lose but probably not what you gain. So you are annoyed or inconvenienced. > That is not to say that I am not interested in IM. Just that if you have > to make a choice, the more inclusive one of the two is RTT. I don't agree. I consider the fact that what I type is not transmitted immediately as one of the features of IM. RTT loses that, and so is not inclusive. In fact, from my perspective it has no features I want over and above IM. And it possibly loses other features, like ability to transmit other media types. *If* we had a *protocol* that supported everything we are putting into MSRP, and *also* reasonably supported the sending of RTT, *then* it would be possible to design clients such that RTT was just a mode setting - controlling the decision of when to send. Then you could set your client to RTT and I could set mine to message-mode and we could communicate. I would see your char at a time typing, and you wouldn't see mine. > How manufacturers build there devices, their UI etc is mostly up to them. > Different manufacturers have different views on how to position devices etc. > > As someone who has been working on UI issues for about 20 years, I would argue that what users want is actually something which is easy to use, doesn't require different ways of working for different functions and meets their needs. IMHO that means that integrating text messaging into user friendly, mostly integrated applications is wise. Whether or not the marketing boys are bothered by that is another question of course! I agree that however the technology works, at the product level you want to hide as much as possible. There may still need to be a mode setting, but perhaps nothing more. > Non technical users don't think segmented. They "use a mobile phone". Whether or not they talk into it or send SMS, such users don't really bother with the logical and technical analysis of how applications/protocols and the like are technically separated and implemented. I think this has a lot to do with addressing. If I can communicate to the same user using the same address, then is is conceptually the same technology. From a user's perspective, they have a mobile phone and they use it for different things. Users want things that are intuitive and easy to use. Whether or not underneath it's using two modules and separate protocols, the user doesn't care. > > To argue that because IM and RTT are different technologies, they should also be visible to the user as clearly different things is a techie/scientific viewpoint, it does not IMHO relate to average users at all. I still *think* there are assumptions being made that aren't yet clearly identified: - deaf people want to use RTT to communicate with one another, or with others that are fluent in RTT. In this role, IM is not in any way a substitute for RTT. - many non-deaf people want to communicate with one another using text even though voice is an option. To date most of them seem to find IM meets this need. - deaf people want to communicate with people who are not fluent in RTT. I get the impression the preference of the deaf person is to use RTT. The best style to use (IM or RTT) is in dispute in this case. - when a communication channel is established, the capabilities of the two endpoints (for IM, RTT, and Voice) may not be known a priori. Ideally any capabilities shared in common should be available. I get the impression that there is a feeling among some RTT advocates that if only people would bother to become fluent with RTT they would prefer it to IM in all cases. I disagree, but this is in the realm of opinions - AFAIK there have been no studies on this. (At least I have not seen any cited.) Unless it can be demonstrated that RTT should totally replace IM, I it seems that there are a couple of issues arising from the above: - how should text communication be transacted between those fluent in RTT and those who aren't. (Assuming both are available.) The answer to this question will in part determine whether all IM clients must be capable of supporting RTT. - When A is calling B, it may be that B has multiple devices where he may be reached, with different capabilities. (E.g. a voice phone and a text IM client on a pc.) How can call setup be arranged so that the device chosen maximizes the ability for A and B to communicate? This should work for all combinations of capabilities for Voice, IM, and RTT at A and B. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jul 2 14:54: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 OAA28409 for ; Fri, 2 Jul 2004 14:54: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 1BgTBB-0003oo-Hd for simple-archive@ietf.org; Fri, 02 Jul 2004 14:54:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgTAH-0003Tx-00 for simple-archive@ietf.org; Fri, 02 Jul 2004 14:53:38 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BgT9M-0002qU-00; Fri, 02 Jul 2004 14: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 1BgSsF-0000Kn-0C; Fri, 02 Jul 2004 14:34:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgSk2-0004mG-0Z for simple@megatron.ietf.org; Fri, 02 Jul 2004 14:26: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 OAA26308 for ; Fri, 2 Jul 2004 14:26: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 1BgSk0-0001Pd-Uf for simple@ietf.org; Fri, 02 Jul 2004 14:26:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgSiF-0000rN-00 for simple@ietf.org; Fri, 02 Jul 2004 14:24:40 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx with esmtp (Exim 4.12) id 1BgSfa-0007W0-00 for simple@ietf.org; Fri, 02 Jul 2004 14:21:54 -0400 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i62ILE57015317; Fri, 2 Jul 2004 11:21:15 -0700 (PDT) Received: from [129.46.227.161] (carbuncle.qualcomm.com [129.46.227.161]) by magus.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i62ILB0D011398; Fri, 2 Jul 2004 11:21:12 -0700 (PDT) Mime-Version: 1.0 X-Sender: hardie@mage.qualcomm.com Message-Id: In-Reply-To: <40E53251.6000102@dynamicsoft.com> References: <342C4681F0D4A04CA50A97D74DA8FB9A0C0AC79B@esealnt875.al.sw.ericsson.se> <40E521E2.9010209@nokia.com> <40E53251.6000102@dynamicsoft.com> Date: Fri, 2 Jul 2004 11:21:11 -0700 To: Jonathan Rosenberg , Miguel Garcia From: Ted Hardie Subject: [Simple] Re: XCAP Directory: Large response ? 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 6:00 AM -0400 7/2/04, Jonathan Rosenberg wrote: > >I would propose that we not put this functionality in xcap itself, >but use the existing HTTP mechanisms. I will note that these >mechanisms are *byte* oriented, and not XML oriented. Thus, you may >cut an element off in the middle by asking for the first 50 bytes. >However, if your main concern is bandwidth or latency, then bytes >are much more significant of a measure than elements. If I say, >"give me 30 elements", that could be 30 bytes or 30MB, depennding on >the amount of data in each element. I'd like to strongly support this view. XCAP is currently a profile of HTTP, and re-using HTTP methods makes a great deal of sense here. Attempting to extend XCAP to include mechanisms that are not part of the core of HTTP will require either extending HTTP (hard) or diverging from HTTP (problematic for code re-use, which has been a key factor before). I'd also like to point out that the problem (unexpectedly large responses) may be less likely than originally supposed. An XCAP client will have to have some knowledge of the schema with which it is interacting in order to get the base advantage of XCAP over HTTP. That is, it will have to know the break points between things like the whole buddy list, the list of "friends", the subset of "friends" who are "good friends", and a possibly overlapping set of "work colleagues". While it would not be formally part of the schema, it would not be hard to store the number of elements last known for each of the break points in the hierarchy; indeed, the previous discussion of positional insertions seemed to presume this was stored. Even without positional insertions, this is useful information that it is relatively easy to store and maintain. As Jonathan points out, it still won't map perfection to bytes, since elements may be of different sizes, but it will help the client understand the likely size of a request. regards, Ted Hardie _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jul 2 15:36: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 PAA02342 for ; Fri, 2 Jul 2004 15: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 1BgTpn-0002OM-LU for simple-archive@ietf.org; Fri, 02 Jul 2004 15:36:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgTom-000227-00 for simple-archive@ietf.org; Fri, 02 Jul 2004 15:35:28 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BgTnm-0001P3-00; Fri, 02 Jul 2004 15:34:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgTcS-0002jd-AW; Fri, 02 Jul 2004 15: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 1BgQO3-0007BQ-3g for simple@megatron.ietf.org; Fri, 02 Jul 2004 11:55: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 LAA15469 for ; Fri, 2 Jul 2004 11:55: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 1BgQO2-0003xZ-7W for simple@ietf.org; Fri, 02 Jul 2004 11:55:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgQNH-0003c2-00 for simple@ietf.org; Fri, 02 Jul 2004 11:54:51 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx with esmtp (Exim 4.12) id 1BgQMP-0003C8-00 for simple@ietf.org; Fri, 02 Jul 2004 11:53:57 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 02 Jul 2004 11:52:23 -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 i62FrLaG013655; Fri, 2 Jul 2004 11:53:21 -0400 (EDT) Received: from mhammer-w2k03.cisco.com (dhcp-hrn-64-100-229-208.cisco.com [64.100.229.208]) by fruitpie.cisco.com (MOS 3.4.6-GR) with ESMTP id BAI79653; Fri, 2 Jul 2004 08:51:48 -0700 (PDT) Message-Id: <4.3.2.7.2.20040702114710.00b2c048@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 02 Jul 2004 11:52:49 -0400 To: "Guido Gybels" , "RNIDMAIL.GWIA.\"hisham.khartabil@nokia.com\"" , , , From: Mike Hammer Subject: RE: [Simple] RE: [Sipping] RE: text/T140 andaudio/t140 was:[avt]Comments/questions on draft-ietf-av In-Reply-To: <4818CE251FC66942A7EF35B92695246E01B22149@JUPITER-MSG.ad.rn id.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailman-Approved-At: Fri, 02 Jul 2004 15:22:43 -0400 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,EXCUSE_16 autolearn=no version=2.60 Not really. If this were an election, and money were votes, then the current state of the market is the count which says that most people, with no discrimination for/against their physical abilities, bought and therefore voted for IM over other RTT options that have been available in the past. Your logic suggests that if only more people had voted for a candidate, then they would have liked that candidate. :) Nice thing though, there is always room for niche markets. And we need not be ruled by the tyranny of the majority. And even the mainstream products try to cram every possible feature in over time. Mike At 10:05 AM 7/2/2004 +0100, Guido Gybels wrote: >Hisham, > ><prefer interactive text>> > >Precisely that argument is seriously flawed IMHO. In reality, the overall >majority of users only has access to IM, not RTT. To argue therefore that >a substantial amount of people actually prefer IM over RTT is IMHO flawed >logic. > >Guido > > >************************************************************************ >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 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jul 2 15:36: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 PAA02396 for ; Fri, 2 Jul 2004 15:36: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 1BgTq1-0002QB-N3 for simple-archive@ietf.org; Fri, 02 Jul 2004 15:36:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgTp9-00025L-00 for simple-archive@ietf.org; Fri, 02 Jul 2004 15:35:52 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BgToT-0001iQ-00; Fri, 02 Jul 2004 15:35:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgTcS-0002ji-Nu; Fri, 02 Jul 2004 15: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 1BgQvs-0007sF-LL for simple@megatron.ietf.org; Fri, 02 Jul 2004 12: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 MAA18249 for ; Fri, 2 Jul 2004 12:30: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 1BgQvr-00012Y-NA for simple@ietf.org; Fri, 02 Jul 2004 12:30:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgQv4-0000ht-00 for simple@ietf.org; Fri, 02 Jul 2004 12:29:47 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx with esmtp (Exim 4.12) id 1BgQu7-0000BG-00 for simple@ietf.org; Fri, 02 Jul 2004 12:28:47 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 02 Jul 2004 12:36:30 -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 i62GSBaG021201; Fri, 2 Jul 2004 12:28:11 -0400 (EDT) Received: from cisco.com ([161.44.79.239]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AJW48424; Fri, 2 Jul 2004 12:28:09 -0400 (EDT) Message-ID: <40E58D19.2060904@cisco.com> Date: Fri, 02 Jul 2004 12:28: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: Tiny ant vs big Mammoths, was RE: [Simple] Using MSRP for realtime text conversation References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 02 Jul 2004 15:22:43 -0400 Cc: stf267@etsi.org, toip@snowshore.com, hisham.khartabil@nokia.com, adam@dynamicsoft.com, simple@ietf.org, dean.willis@softarmor.com, "'Guido Gybels'" , gunnar.hellstrom@omnitor.se, 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 Gregg Vanderheiden wrote: > I too worry about having multiple text conversation technologies. I don't > see it as bad theoretically. Difference facilitates evolution. > > HOWEVER, if we have different formats, then > 1) EITHER everyone has to support ALL of them ALWAYS... > OR > 2) Everyone has to support ONE technique (as well as anything else they want > to ) > OR > 3) SOMEONE must maintain TRANSLATORS EVERYWHERE and on ALL SYSTEMS. > It is not clear that these would exist or who would pay for them. > > The alternative is that text calls fail. We do it for voice (make sure it > works everywhere or is translated) but market forces ensure that. > > For text how will we ensure this. I think it is #2 above - or else > failures. Well, we already have a situation where there are multiple formats for text, even when limited to message based text: AIM format, Yahoo format, Jabber (XMPP) format, SIMPLE page mode format, (coming) SIMPLE session mode format (MSRP), ... I doubt adding text/t140 to the list makes the situation much better *or* worse. In most cases now you either need to run a separate client for each protocol, or else you run a client that supports multiple protocols. Gateways would be good, and they exist to some extent. But the largest providers don't seem to think gateways are in their best interest, and so actively break them. Of course a gateway solution wouldn't be very good for RTT, because its semantics are not message based like the others. Gateways would probably have to buffer test and look for message boundaries or something like that. (Getting RTT one character at a time in an AIM application wouldn't be very readable.) So the chance of getting universal access to every text application looks pretty dismal right now, even if you were satisfied with message based IM. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jul 2 15:38: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 PAA02482 for ; Fri, 2 Jul 2004 15:38: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 1BgTrj-00035Q-Uz for simple-archive@ietf.org; Fri, 02 Jul 2004 15:38:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgTql-0002ja-00 for simple-archive@ietf.org; Fri, 02 Jul 2004 15:37:32 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BgTpm-00026B-00; Fri, 02 Jul 2004 15:36:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgTcT-0002jn-5n; Fri, 02 Jul 2004 15: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 1BgRBB-00088c-Lb for simple@megatron.ietf.org; Fri, 02 Jul 2004 12:46: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 MAA19242 for ; Fri, 2 Jul 2004 12:46: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 1BgRBA-0006Wp-Q5 for simple@ietf.org; Fri, 02 Jul 2004 12:46:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgRAH-0006Dp-00 for simple@ietf.org; Fri, 02 Jul 2004 12:45:30 -0400 Received: from [217.158.120.227] (helo=rnidmail.rnid.org.uk) by ietf-mx with esmtp (Exim 4.12) id 1BgR9R-0005bY-00 for simple@ietf.org; Fri, 02 Jul 2004 12:44:37 -0400 Received: from JUPITER-MSG.rnid.org.uk (unverified) by rnidmail.rnid.org.uk (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 2 Jul 2004 17:43:32 +0100 content-class: urn:content-classes:message Subject: RE: [Simple] RE: [Sipping] RE: text/T140 andaudio/t140was:[avt]Comments/questions on draft-ietf-av Date: Fri, 2 Jul 2004 17:43:59 +0100 Message-ID: <4818CE251FC66942A7EF35B92695246E01B22154@JUPITER-MSG.ad.rnid.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: RE: [Simple] RE: [Sipping] RE: text/T140 andaudio/t140was:[avt]Comments/questions on draft-ietf-av Thread-Index: AcRgUntJgE55qRKfQXiUb4ItPifBvQAAKB/Q From: "Guido Gybels" To: "RNIDMAIL.GWIA.\"mhammer@cisco.com\"" , , , Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 02 Jul 2004 15:22:43 -0400 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.2 required=5.0 tests=AWL,EXCUSE_16 autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable This is non sequitur. To indicate that users *prefer* IM is simply not true= , because most users haven't had any choice. At least in an election (well at least here in Europe...) people can see bo= th candidates and read their programme. The situation with IM is more like = elections under a dictatorial regime for example, where in theory there was= "free" choice, yet in practice there isn't. Or to say it otherwise, free choice is great, it's only that at the moment = we haven't got it. Have a good weekend! Guido -----Original Message----- From: Mike Hammer =20 Sent: 02 July 2004 16:52 To: Guido Gybels; a.vwijk@viataal.nl; IMCEAGWISE-RNIDMAIL+2EGWIA+2E+22hisham+2Ekhartabil+40nokia+2Ecom+22@rnid .org.uk; pkyzivat@cisco.com Cc: fluffy@cisco.com; gunnar.hellstrom@omnitor.se; gv@trace.wisc.edu; simple@ietf.org; smundra@telogy.com; toip@snowshore.com Subject: RE: [Simple] RE: [Sipping] RE: text/T140 andaudio/t140was:[avt]Comments/questions on draft-ietf-av Not really. If this were an election, and money were votes, then the=20 current state of the market is the count which says that most people, with= n o discrimination for/against their physical abilities, bought and=20 therefore voted for IM over other RTT options that have been available in= t he past. Your logic suggests that if only more people had voted for a candidate,=20 then they would have liked that candidate. :) Nice thing though, there is always room for niche markets. And we need not= b e ruled by the tyranny of the majority. And even the mainstream products= t ry to cram every possible feature in over time. Mike At 10:05 AM 7/2/2004 +0100, Guido Gybels wrote: >Hisham, > >< prefer interactive text>> > >Precisely that argument is seriously flawed IMHO. In reality, the overall= > majority of users only has access to IM, not RTT. To argue therefore that= > a substantial amount of people actually prefer IM over RTT is IMHO flawed= > logic. > >Guido > > >************************************************************************ >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 ************************************************************************ 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 =20 Registered Office 19-23 Featherstone Street=20 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 Fri Jul 2 15:41: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 PAA02638 for ; Fri, 2 Jul 2004 15:41: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 1BgTum-00047M-GS for simple-archive@ietf.org; Fri, 02 Jul 2004 15:41:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgTtj-0003ku-00 for simple-archive@ietf.org; Fri, 02 Jul 2004 15:40:36 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BgTsl-00037y-00; Fri, 02 Jul 2004 15:39:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgTce-0002ku-Ci; Fri, 02 Jul 2004 15:22:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgSqv-0007uq-E0 for simple@megatron.ietf.org; Fri, 02 Jul 2004 14:33: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 OAA26957 for ; Fri, 2 Jul 2004 14:33: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 1BgSqt-0004DC-Nm for simple@ietf.org; Fri, 02 Jul 2004 14:33:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgSpl-0003n4-00 for simple@ietf.org; Fri, 02 Jul 2004 14:32:26 -0400 Received: from starburst.cae.wisc.edu ([144.92.13.24] helo=cae.wisc.edu) by ietf-mx with esmtp (Exim 4.12) id 1BgSof-000336-00 for simple@ietf.org; Fri, 02 Jul 2004 14:31:17 -0400 Received: from jalopy.cae.wisc.edu (root@jalopy.cae.wisc.edu [144.92.12.93]) by cae.wisc.edu (8.12.9/8.12.9) with ESMTP id i62ITPK6004733; Fri, 2 Jul 2004 13:29:25 -0500 (CDT) Received: from NC6000BAK (tracepub.trace.wisc.edu [128.104.192.100]) (authenticated bits=0) by jalopy.cae.wisc.edu (8.12.3/8.12.3/Debian-6.6) with ESMTP id i62ITJE7019696 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 2 Jul 2004 13:29:20 -0500 Message-Id: <200407021829.i62ITJE7019696@jalopy.cae.wisc.edu> From: "Gregg Vanderheiden" To: "'Paul Kyzivat'" Subject: RE: Tiny ant vs big Mammoths, was RE: [Simple] Using MSRP for realtime text conversation Date: Fri, 2 Jul 2004 13:29:18 -0500 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 Thread-index: AcRgUaT+DcUXJnqXQvmL9OLtfl5ZkAAAOjyw In-reply-to: <40E58D19.2060904@cisco.com> X-CAE-MailScanner-Information: Please contact security@engr.wisc.edu if this message contains a virus or has been corrupted in delivery. X-CAE-MailScanner: Found to be clean (starburst) Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 02 Jul 2004 15:22:55 -0400 Cc: stf267@etsi.org, toip@snowshore.com, hisham.khartabil@nokia.com, adam@dynamicsoft.com, simple@ietf.org, dean.willis@softarmor.com, "'Guido Gybels'" , gunnar.hellstrom@omnitor.se, 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.8 required=5.0 tests=AWL,MAILTO_TO_SPAM_ADDR, MISSING_OUTLOOK_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Hi Paul, That is exactly the point. Hmmmmm Let me see if I can explain the difference, the importance of this. For those of us who can talk, IM is a convenience and if my IM doesn't work with yours - no big deal. I can use the phone or email. But for deaf people, text conversation is like the phone. What if there were lots of different phone systems and they didn't all work together. So to call you I had to find out what phone system you had and then go sign up for that type of phone. Or like email What if all the email didn't work together. So that you could only email some people from some programs and call some people from some phones. To send an email you would first have to figure out what email system the recipient had and then get one of those. This is why the FCC and other countries regulatory people are starting to get involved. Because the regular market forces for text conversation are not strong enough to guarantee that there is a text conversation method that works everywhere -- and that is equivalent to the phone system (for people who cannot use the phone system). So - lots of message standards are fine but there has to either be 1 standard that you can always rely on OR - gateways that someone maintains that will always work to convert any text conversation into any other. RE why IM isn't enough to replace interactive text or text conversation?? Hmmm Let me try that too Try a phone call where you say everything to yourself at normal speed before you say it aloud to the other person. Not only is the call twice as long, but you will also find that the other person keeps being distracted, or leaves the phone call. It also breaks all the social conversation rules (not messaging rules but that is different). It isn't that messaging isn't great. It is. But it does not remove the need for conversation. For the ability to respond immediately. To have that immediacy. If you talk mostly and Message sometimes you don't understand what it would be like to only be able to message. People who are deaf LOVE messaging and SWEAR BY messaging because it is so great compared to what they had. And it will always be a great tool even if we have text conversation. Give people the choice of messaging and text conversation and I think you will find that most do not JUST use messaging. Many will use IM to and text conversation to talk. Some will do more with one than the other. Some will do only I'm, - for example if they are poor typists. (some don't and won't use either because they are poor spellers) But that needs to be something that people can decide based on their needs - not forced by the technology. And in many cases, people's communication will be severely hampered (by social conventions) if they can only message - especially with hearing folk who are not friends and family. SO a) we need a text standard that interoperates across technologies and that is always supported. (then we can have as many other forms on devices as we want - but something has to work across them). b) it should be text conversation - though a universal IM would be welcomed by all. Gregg -- ------------------------------ Gregg C Vanderheiden Ph.D. Professor - Ind. Engr. & BioMed Engr. Director - Trace R & D Center University of Wisconsin-Madison -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: Friday, July 02, 2004 11:28 AM To: Gregg Vanderheiden Cc: 'Guido Gybels'; bcampbell@dynamicsoft.com; dean.willis@softarmor.com; gunnar.hellstrom@omnitor.se; hisham.khartabil@nokia.com; stf267@etsi.org; toip@snowshore.com; adam@dynamicsoft.com; simple@ietf.org Subject: Re: Tiny ant vs big Mammoths, was RE: [Simple] Using MSRP for realtime text conversation Gregg Vanderheiden wrote: > I too worry about having multiple text conversation technologies. I don't > see it as bad theoretically. Difference facilitates evolution. > > HOWEVER, if we have different formats, then > 1) EITHER everyone has to support ALL of them ALWAYS... > OR > 2) Everyone has to support ONE technique (as well as anything else they want > to ) > OR > 3) SOMEONE must maintain TRANSLATORS EVERYWHERE and on ALL SYSTEMS. > It is not clear that these would exist or who would pay for them. > > The alternative is that text calls fail. We do it for voice (make sure it > works everywhere or is translated) but market forces ensure that. > > For text how will we ensure this. I think it is #2 above - or else > failures. Well, we already have a situation where there are multiple formats for text, even when limited to message based text: AIM format, Yahoo format, Jabber (XMPP) format, SIMPLE page mode format, (coming) SIMPLE session mode format (MSRP), ... I doubt adding text/t140 to the list makes the situation much better *or* worse. In most cases now you either need to run a separate client for each protocol, or else you run a client that supports multiple protocols. Gateways would be good, and they exist to some extent. But the largest providers don't seem to think gateways are in their best interest, and so actively break them. Of course a gateway solution wouldn't be very good for RTT, because its semantics are not message based like the others. Gateways would probably have to buffer test and look for message boundaries or something like that. (Getting RTT one character at a time in an AIM application wouldn't be very readable.) So the chance of getting universal access to every text application looks pretty dismal right now, even if you were satisfied with message based IM. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jul 2 15:45: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 PAA02959 for ; Fri, 2 Jul 2004 15:45: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 1BgTya-0005ST-A6 for simple-archive@ietf.org; Fri, 02 Jul 2004 15:45:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgTxe-000595-00 for simple-archive@ietf.org; Fri, 02 Jul 2004 15:44:38 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BgTx5-0004od-00; Fri, 02 Jul 2004 15:44:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgTtk-00038I-I5; Fri, 02 Jul 2004 15:40:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgTk3-0005SI-HT for simple@megatron.ietf.org; Fri, 02 Jul 2004 15: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 PAA01962 for ; Fri, 2 Jul 2004 15:30: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 1BgTk2-0000M6-C3 for simple@ietf.org; Fri, 02 Jul 2004 15:30:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgTj5-00002K-00 for simple@ietf.org; Fri, 02 Jul 2004 15:29: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 1BgTiF-0007Do-00 for simple@ietf.org; Fri, 02 Jul 2004 15:28:43 -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 i62JSDLp026113 for ; Fri, 2 Jul 2004 14:28:13 -0500 From: Robert Sparks To: simple@ietf.org Content-Type: text/plain Message-Id: <1088796471.2203.70.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Date: Fri, 02 Jul 2004 14:27:52 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Administrivia: posts are being held for moderation X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org 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 - There are an unusually large number of posts getting wedged int he moderation queue, particularly on the "text/T140 ..." thread. Most of these are due to two conditions: - Extremely long messages - Too many recipients If you don't want your posts delayed, trim your replies to what's pertinent, and please send only plain-text. Reply to the list - the CC snowball effect of "Reply-All" is not necessary. Thanks, RjS _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jul 2 16:51: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 QAA05980 for ; Fri, 2 Jul 2004 16: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 1BgV0U-0003Mf-3p for simple-archive@ietf.org; Fri, 02 Jul 2004 16:51:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgUzV-000334-00 for simple-archive@ietf.org; Fri, 02 Jul 2004 16:50:38 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BgUyl-0002RM-00; Fri, 02 Jul 2004 16:49:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgUw9-00053u-I4; Fri, 02 Jul 2004 16:47:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgUVW-0003l3-VD for simple@megatron.ietf.org; Fri, 02 Jul 2004 16:19: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 QAA04337 for ; Fri, 2 Jul 2004 16:19: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 1BgUVV-0000tF-O8 for simple@ietf.org; Fri, 02 Jul 2004 16:19:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgUUa-0000a9-00 for simple@ietf.org; Fri, 02 Jul 2004 16:18:41 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BgUU6-0000G1-00 for simple@ietf.org; Fri, 02 Jul 2004 16:18:10 -0400 Received: from dynamicsoft.com ([63.113.46.29]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i62KHubo005098; Fri, 2 Jul 2004 16:17:56 -0400 (EDT) Message-ID: <40E5C2E1.50502@dynamicsoft.com> Date: Fri, 02 Jul 2004 16:17: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: "George Foti (QA/EMC)" Subject: Re: [Simple] RE: XCAP Directory: Large response ? References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: "'Miguel Garcia'" , 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. George Foti (QA/EMC) wrote: > Comments in line Miguel. > > >> -----Original Message----- From: Miguel Garcia >> [mailto:Miguel.An.Garcia@nokia.com] Sent: Friday, July 02, 2004 >> 9:03 AM To: George Foti (QA/EMC) Cc: Henrik Albertsson (KI/EAB); >> Jonathan Rosenberg; simple@ietf.org Subject: Re: [Simple] RE: XCAP >> Directory: Large response ? >> >> >> George: >> >> I don't like this solution. It requires the XCAP server to do a >> "trial and error" of the XML document that will be send to the >> user. Build an XML document with "n" entries, if the size of the >> document exceeds X bytes, start reducing the number entries, one by >> one, until the result is less than X bytes. That's awful. >> > > It is a managed complexity, and mostly implementation. With some meta > data, it can be manageable. I agree with Miguel; this is really hard. It would require a lot of implementation complexity. >> I believe we have two constraints here: one is the display size of >> the device and the other is the memory of the device. I believe a >> device may want to get a page of entries it can render in the >> display, then release the memory, and request a new page. >> > > I addition to what you state, anything that is returned has to be > usable and we can do operations n them. If you want pagination, I think you need to provide that as something quite separate from the byte length constraints. Pagination is a very application/content specific thing. Indeed, if the goal were to say "give me the first N children of this element", thats something that the multiple-element selection can do. I think you'd want to then add a Ranges header to protect yourself against byte overload in the case where an entry is too large. XPath provides the ability to do that kind of selection. Something like this would work: list/buddy[position() > N and position() < M] That would give you the Nth through Mth buddy elements. XCAP doesnt support that level of complexity in the server. If it did, and you wanted protection against memory overload (say, 1k max), you'd do something like this: GET http://server/blah-blah/list/buddy[position() > N and position() < M] Range: bytes=0-1000 If the response is truncated, then you need to adjust your pagination size on the client. -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 Jul 2 17:16: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 RAA07314 for ; Fri, 2 Jul 2004 17:16: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 1BgVOo-00043h-Tg for simple-archive@ietf.org; Fri, 02 Jul 2004 17:16:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgVNw-0003ht-00 for simple-archive@ietf.org; Fri, 02 Jul 2004 17:15:53 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BgVMx-00031b-00; Fri, 02 Jul 2004 17:14:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgVDQ-0005Es-Kd; Fri, 02 Jul 2004 17:05:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgVB6-0002ZO-55 for simple@megatron.ietf.org; Fri, 02 Jul 2004 17: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 RAA06532 for ; Fri, 2 Jul 2004 17:02: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 1BgVB4-00073B-JG for simple@ietf.org; Fri, 02 Jul 2004 17:02:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgVAA-0006jX-00 for simple@ietf.org; Fri, 02 Jul 2004 17:01:38 -0400 Received: from smtp.eweka.nl ([81.171.101.3]) by ietf-mx with esmtp (Exim 4.12) id 1BgV9H-0006Oh-00 for simple@ietf.org; Fri, 02 Jul 2004 17:00:43 -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 i62L0Tb0015898; Fri, 2 Jul 2004 23:00:36 +0200 (CEST) (envelope-from a.vwijk@viataal.nl) Message-Id: <200407022100.i62L0Tb0015898@smtp.eweka.nl> From: "Arnoud van Wijk" To: "'Guido Gybels'" , , , , Subject: RE: Tiny ant vs big Mammoths, was RE: [Simple] Using MSRP forrealtime text conversation Date: Fri, 2 Jul 2004 23:00:11 +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 Thread-index: AcRgCytEz7dM1ogRSP6D2UEC0KAGqwAbFQlQ In-reply-to: Content-Transfer-Encoding: 7bit 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.9 required=5.0 tests=AWL,EXCUSE_16, MAILTO_TO_SPAM_ADDR,MISSING_OUTLOOK_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Guido, Excellent said! Very true! /Arnoud -----Original Message----- From: Guido Gybels [mailto:Guido.Gybels@rnid.org.uk] Sent: vrijdag 2 juli 2004 10:02 To: bcampbell@dynamicsoft.com; hisham.khartabil@nokia.com; gunnar.hellstrom@omnitor.se; dean.willis@softarmor.com; A.vWijk@viataal.nl Cc: adam@dynamicsoft.com; stf267@etsi.org; simple@ietf.org; toip@snowshore.com Subject: RE: Tiny ant vs big Mammoths, was RE: [Simple] Using MSRP forrealtime text conversation Hisham, <> To be perfectly honest, we have been through this whole discussion many times in the past. I recently recirculated a paper that tries to summarise the issues. Because it is not an alternative to voice. Hearing people use IM as a *different* tool, they have the *choice* to select between voice, email, SMS, IM, etc. Each one of these communication methods has its own characteristics, its own level of interactivity, etc. So, hearing people select amongst these offerings based on what they want to do, the circumstances, etc. Deaf people will behave the same: sometimes they will use email, they certainly use SMS a lot, etc. However, deaf people can't use voice. So, they have no access to one of the most important communication tools in the Information Society. That non-access disenfranchises them enormously, in employment, health, education, social life and entertainment alike. Interactive text is the text equivalent of what voice is to hearing people. So, making it available is bringing deaf people on a more equal basis in society. Just as much as IM is NOT a REPLACEMENT for voice for hearing people (but rather an ADDITIONAL communication method), it can NOT be a REPLACEMENT for interactive text for deaf people. No hearing people would get it in their right minds to suggest we scrap voice because of the existence of IM. Yet, that is precisely what some people suggest deaf people should accept. That would clearly not be the right way forward. The fact that deaf people do use other forms of communication, like email or SMS is no more an argument for getting rid of interactive texting as the use of email and SMS by hearing people is to get rid of voice telephony. Best regards, Guido Guido Gybels Director of New Technologies RNID, 19-23 Featherstone Street London EC1Y 8SL, UK Tel +44(0)207 294 3713 Fax +44(0)207 296 8069 ************************************************************************ 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 Sat Jul 3 16:08: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 QAA17039 for ; Sat, 3 Jul 2004 16:08: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 1BgqoU-0001Ek-0T for simple-archive@ietf.org; Sat, 03 Jul 2004 16:08:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgqnX-0000xG-00 for simple-archive@ietf.org; Sat, 03 Jul 2004 16:07:44 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bgqmz-0000ez-00; Sat, 03 Jul 2004 16: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 1BgqDN-0007sY-3k; Sat, 03 Jul 2004 15:30:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bgpre-0000lO-EV for simple@megatron.ietf.org; Sat, 03 Jul 2004 15:07: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 HAA26266 for ; Sat, 3 Jul 2004 07:30: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 1Bgiip-0002sK-R6 for simple@ietf.org; Sat, 03 Jul 2004 07:30:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bgihr-0002ax-00 for simple@ietf.org; Sat, 03 Jul 2004 07:29:20 -0400 Received: from albatross.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1BgihA-0002JZ-00 for simple@ietf.org; Sat, 03 Jul 2004 07:28:36 -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 i63BSZWR024100 for ; Sat, 3 Jul 2004 13:28:35 +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); Sat, 3 Jul 2004 13:28:35 +0200 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id <3D9FV5MJ>; Sat, 3 Jul 2004 13:28:35 +0200 Message-ID: From: "Christer Holmberg (JO/LMF)" To: "'Ben Campbell'" , Paul Kyzivat Subject: RE: [Simple] MSRP: updates and re-invites Date: Sat, 3 Jul 2004 13:28:34 +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: 03 Jul 2004 11:28:35.0274 (UTC) FILETIME=[E0C682A0:01C460F0] 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.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Hi, I think it is important to look at this from a generic TCP point of = view, and not only from a MSRP perspective. Because, if we in a session = have multiple "streams" (used for different applications and/or = multiple instances of the same application) using TCP, and they all = define separate SIP behaviour we may end up in situations when = re-INVITEs are sent in different directions etc. Because, unlike in = H.323, we do need to include ALL m=3D lines in a new offer, even if we = only modify/(re-)establish/delete a specific stream. So, the question is: what does a SIP node (offerer and answerer) do if = a bearer level TCP connection goes down? WHO does re-establish the TCP = connection? WHEN is the TCP connection re-establish? Do we send a = re-INVITE, or don't we send anything? Regards, Christer Holmberg Ericsson Finland > -----Original Message----- > From: simple-bounces@ietf.org=20 > [mailto:simple-bounces@ietf.org]On Behalf > Of Ben Campbell > Sent: 29. kes=E4kuuta 2004 21:41 > To: Paul Kyzivat > Cc: Simple WG > Subject: Re: [Simple] MSRP: updates and re-invites >=20 >=20 > Paul Kyzivat wrote: >=20 > >=20 > >=20 > > Ben Campbell wrote: > >=20 > >> In the shared connection model, connections are as-needed. By=20 > >> implication, we do not signal connections, we signal=20 > sessions. If we=20 > >> 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,=20 > why would=20 > >> we signal a new connection? > >=20 > >=20 > > Unless I missed a change somewhere, connections *at the=20 > endpoints* are=20 > > not entirely as-needed. In particular, if a connection has=20 > gone away but=20 > > is still needed it cannot just be made again. >=20 > Oops, yes, you are correct. >=20 > >=20 > > But I agree that the need to do that can be defined away,=20 > by saying that=20 > > loss of the connection implies loss of the session, so that a new=20 > > session must be requested. > >=20 > > I think this is what you mean, and if so that is fine. I=20 > just want to be=20 > > sure. >=20 > Yes, that is what I mean. >=20 > >=20 > > Paul > >=20 > >> Paul Kyzivat wrote: > >> > >>> Ben, > >>> > >>> I think what you describe here is what we discussed at=20 > some point,=20 > >>> that should work. But the general wording below leaves me a bit=20 > >>> uncertain of that. Am I right that point below is that if=20 > the path is=20 > >>> unchanged then the old connections are reused, while when=20 > the path is=20 > >>> changed (by either end) then the offerer establishes a=20 > new connection? > >>> > >>> Paul > >>> > >>> Ben Campbell wrote: > >>> > >>>> We have had a lot of discussion on how to handle updated=20 > offers in=20 > >>>> SIP updates and re-invites. We had made some proposals=20 > back when we=20 > >>>> negotiated connection direction that are not really=20 > relevant any more. > >>>> > >>>> The design team spent some time discussing this, and=20 > came up with a=20 > >>>> proposal: > >>>> > >>>> Reconnection no longer an issue with connection sharing. TCP=20 > >>>> connection establishment is done on-demand. Therefore we=20 > do not need=20 > >>>> a way to signal a desire to establish a new TCP session. > >>>> > >>>> The offerer of a new sdp exchange assumes the role of=20 > offerer for=20 > >>>> all purposes, regardless of whether it was the=20 > origininal offerer. > >>>> > >>>> An offerer or answer is effectively unchanged if the=20 > path does not=20 > >>>> change from the previous version. If either side changes=20 > the path,=20 > >>>> then we effectively have a new session. > >>>> > >>>> If offerer does not change anything, answerers can still make=20 > >>>> changes. Answerer must always answer with a currently=20 > valid path.=20 > >>>> These could be the same as before the update, or different. > >>>> > >>>> Local policy may choose to re-invite to fix session=20 > problems without=20 > >>>> user interaction, or give user a choice. (examples: you=20 > get an error=20 > >>>> report to the initial send, a mobile device looses connectivity=20 > >>>> through tunnel, etc.) > >>>> > >>>> I invite everyone who cares to think this through, and=20 > make sure we=20 > >>>> are not breaking something important. > >>>> > >>>> Thanks! > >>>> > >>>> Ben. > >>>> > >>>> _______________________________________________ > >>>> 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 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sat Jul 3 16: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 QAA17096 for ; Sat, 3 Jul 2004 16:09: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 1BgqpO-0001XG-Ag for simple-archive@ietf.org; Sat, 03 Jul 2004 16:09:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgqoV-0001F0-00 for simple-archive@ietf.org; Sat, 03 Jul 2004 16:08:45 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bgqna-0000gE-00; Sat, 03 Jul 2004 16: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 1BgqDT-00080s-4N; Sat, 03 Jul 2004 15:30:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bgps9-0005cZ-El for simple@megatron.ietf.org; Sat, 03 Jul 2004 15:08: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 HAA26350 for ; Sat, 3 Jul 2004 07:33: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 1Bgilz-0003lv-F1 for simple@ietf.org; Sat, 03 Jul 2004 07:33:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bgiko-0003U2-00 for simple@ietf.org; Sat, 03 Jul 2004 07:32:23 -0400 Received: from albatross.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1BgikR-0003By-00 for simple@ietf.org; Sat, 03 Jul 2004 07:31:59 -0400 Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i63BVwWR024381 for ; Sat, 3 Jul 2004 13:31:58 +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); Sat, 3 Jul 2004 13:31:58 +0200 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id <3D9FV5VX>; Sat, 3 Jul 2004 13:31:58 +0200 Message-ID: From: "Christer Holmberg (JO/LMF)" To: "'Paul Kyzivat'" , Eric Burger Subject: RE: [Simple] MSRP: Ending a session Date: Sat, 3 Jul 2004 13:31:56 +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: 03 Jul 2004 11:31:58.0321 (UTC) FILETIME=[59CD0610:01C460F1] Content-Transfer-Encoding: quoted-printable 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 Content-Transfer-Encoding: quoted-printable Hi Paul, If you really want to make sure you receive everything on the TCP = connection (or any other transport mechanism) before freeing the = resources I guess you would have to first send an "inactive" or = "sendonly" re-INVITE, get a response, wait for a while (to make sure = everything "on the line" reaches you) and then send BYE.=20 Yes, this behaviour is very "heavy" and ugly, but that's the way you = have to do it using SIP... And, even if you DO wait for the 200, which Eric said may not even = come, there is still a chance it will reach you before the last bit of = the "media". And, also if you use MESSAGE for IM there is a risk that there is a = request on the line when you send BYE, and free your session level = resources, so I don't think this is a MSRP-only problem. Regards, Christer Holmberg Ericsson Finland > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: 1. hein=E4kuuta 2004 20:37 > To: Eric Burger > Cc: Christer Holmberg (JO/LMF); 'simple@ietf.org'; > 'bcampbell@dynamicsoft.com' > Subject: Re: [Simple] MSRP: Ending a session >=20 >=20 >=20 >=20 > Eric Burger wrote: > > I agree with Christer. If you really want this behavior,=20 > extend SIP. I > > don't want this behavior codified. In the real world, the=20 > media resources > > are long gone by the time the BYE hits. > >=20 > > I really, really don't want to write-in an enormous=20 > denial-of-service > > opening by requiring the resources to stay around for 200=20 > OK's that will > > never come. >=20 > I've lost the beginning of this thread, so I don't have a record of=20 > exactly what was proposed. So I will shoot from the hip. >=20 > I certainly don't want to *require* resources to be held=20 > after BYE. It=20 > would be especially stupid to do that when the UA will have nothing=20 > better to do with incoming media than drop it in the bit bucket. >=20 > OTOH, I think it at least ought to be permissible for a UA to=20 > try to get=20 > the last bit of media that might trickle in after the session=20 > is closed,=20 > and to process it if that has meaning for the device. >=20 > There clearly is a problem with the chapter 15.1.1 of 3261 in=20 > this regard: >=20 > "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." >=20 > Its reasonable to require that media not be sent. But at least in the = > case of connection oriented media, it makes sense to permit any media = > remaining in the connection to be processed. (Its a little=20 > dicier with=20 > non-connection-oriented media because input to the same port=20 > may not be=20 > from the same source.) Details about the interpretation of=20 > this may need=20 > to be media specific. >=20 > In the absence of this, when using MSRP, if I want to ensure=20 > that all my=20 > messages have been processed before ending the session I will have to = > send a last message with a requested positive acknowlegment before=20 > ending the session. (I guess this could be an empty message if I have = > nothing left to send when I want to end the session.) >=20 > There may be a more interesting case to consider than the BYE of a=20 > simple call. Consider a case when A & B are directly connected, but=20 > there is a need to move to a mixer to establish a conference. In this = > case lets assume for simplicity that both A and B receive an=20 > INVITE/Replaces from the new focus, offering a new MSRP session. We=20 > presumably want the switch to be graceful with no messages=20 > lost. How do=20 > A and B manage the use of their old and new MSRP connections, and the = > termination of their old call in order to achieve this? >=20 > I believe both A and B will want to stop sending and suck the old=20 > connection dry, before beginning to use the new connection. This will = > require closing the old stream for output but continuing to read till = > eof. Upon eof, switchover to the new stream can occur. But=20 > somebody has=20 > to send a BYE on the old call too. And neither A nor B will=20 > know what is=20 > really going on. So neither knows the other has been told to stop=20 > sending. To ensure they will stop receiving input, both A and B will=20 > want to send a BYE. With current rules, they will have to=20 > stop receiving=20 > at that time, messing things up. >=20 > Paul >=20 > >>-----Original Message----- > >>From: Christer Holmberg (JO/LMF)=20 > >>[mailto:christer.holmberg@ericsson.com] > >>Sent: Monday, June 07, 2004 2:24 PM > >>To: 'Paul Kyzivat' > >>Cc: 'simple@ietf.org'; 'bcampbell@dynamicsoft.com' > >>Subject: RE: [Simple] MSRP: Ending a session > >> > >> > >> > >>Hi Paul, > >> > >>Comments inline ([CHH]) > >> > >> > >>>Obviously you can't force anybody to do anything. If they=20 > >> > >>want to cut=20 > >> > >>>you off in mid conversation then that is what they will do,=20 > >> > >>just like=20 > >> > >>>hanging up on you in a conversation. But its not polite. > >>> > >>>In some sense the situation is no different with MSRP than=20 > >> > >>it is with=20 > >> > >>>voice and RTP. However I think MSRP exposes issues that are=20 > >>>small enough to ignore with voice. In particular, with=20 > >> > >>voice, if you lose a small=20 > >> > >>>number of packets typically nobody cares, because with voice=20 > >> > >>there is=20 > >> > >>>little information content in a small number of packets. But=20 > >>>with MSRP, a "packet" (message) can have substantial=20 > >> > >>content, so that whether it=20 > >> > >>>gets thru or not can have considerable significance. > >>> > >>>This will be true in all sorts of call flows, such as=20 > >>>transfers, and is true here at the end of a session. So we=20 > >> > >>should be defining=20 > >> > >>>mechanisms that can work gracefully, without loss of=20 > >> > >>messages. Whether=20 > >> > >>>people use them that way is up to them. > >> > >>[CHH] Of course, there may be scenarios where it's good, or=20 > >>even required, to wait for the release response. So, the=20 > >>draft could say that a node MAY do so. But, at the same time=20 > >>we sould respect the SIP core rules, and not defining=20 > >>behaviour which overrides those. Otherwise things will get=20 > >>very messy, and things may get out of hand when new=20 > >>extensions, features and/or media types are defined... > >> > >> > >>>Also, I see many people talk as if BYE was the only way to=20 > >>>end an MSRP session. But it is not. It may be ended simply=20 > >> > >>by sending a=20 > >> > >>>reINVITE (or UPDATE) that drops the MSRP stream (by=20 > setting the port=20 > >>>number to zero).=20 > >>> > >>>This may not be a very useful thing to do when MSRP is the=20 > >>>only medium in use, but it can make a lot of sense when=20 > >> > >>there are other=20 > >> > >>>media. For instance, I might start in an IM session, then=20 > >> > >>decide to add=20 > >> > >>>voice. Once voice has been added, I may just close my IM=20 > >> > >>window, killing the MSRP=20 > >> > >>>stream. > >>> > >>>In a case like that there is more lattitude to keep the=20 > state of the=20 > >>>stream until all the signaling to kill it is complete. For=20 > instance,=20 > >>>when I close my IM window that can implicitly initiate the=20 > >>>reinvite to drop the stream. But even though the window=20 > >> > >>disappears, its state can=20 > >> > >>>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=20 > >>parameters in an updated offer won't replace the old ones=20 > >>before an answer has been received. However, even then, in=20 > >>the special case when someone removes a stream by setting the=20 > >>port to zero, I am pretty sure the media resources (wether=20 > >>it's RTP or MSRP) in many cases are "gone", no matter if the=20 > >>other party accepts the offer or not. But again, of course=20 > >>one may keep state and resources until the answer is=20 > >>received, if there is a reason/possibility to do so. But,=20 > >>this are generic offer/answer rules, and again I don't think=20 > >>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=20 > >>> > >>>session, it > >>> > >>>>first signals its intent using the normal processing for the > >>>>signaling protocol. For example, in SIP, it would send a=20 > >>> > >>>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=20 > >>> > >>>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=20 > >>> > >>>for a node to receive the BYE response before the TCP=20 > >>>resources are released. Many nodes releases the media=20 > >>>resources at the same time as the BYE is sent. And, even if=20 > >>>would keep the connection open for possible outstanding MSRP=20 > >>>transactions they would most likely be "lost" anyway, since a=20 > >>>user will not (in gateway scenarios may not even be able to)=20 > >>>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=20 > >>> > >>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=20 > >>> > >>>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 > >> > >=20 > >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sun Jul 4 04:09: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 EAA29679 for ; Sun, 4 Jul 2004 04:09: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 1Bh23c-0004qJ-Ao for simple-archive@ietf.org; Sun, 04 Jul 2004 04:09:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bh22e-0004ab-00 for simple-archive@ietf.org; Sun, 04 Jul 2004 04:08:05 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bh21m-00046c-00; Sun, 04 Jul 2004 04:07:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bh1ry-0003lb-EM; Sun, 04 Jul 2004 03:57:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bh1ar-0001qw-03 for simple@megatron.ietf.org; Sun, 04 Jul 2004 03:39: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 DAA28825 for ; Sun, 4 Jul 2004 03:39: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 1Bh1aj-0005HP-Op for simple@ietf.org; Sun, 04 Jul 2004 03:39:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bh1Zl-0004zq-00 for simple@ietf.org; Sun, 04 Jul 2004 03:38:14 -0400 Received: from av7-1-sn4.m-sp.skanova.net ([81.228.10.110]) by ietf-mx with esmtp (Exim 4.12) id 1Bh1Yq-0004U8-00 for simple@ietf.org; Sun, 04 Jul 2004 03:37:16 -0400 Received: by av7-1-sn4.m-sp.skanova.net (Postfix, from userid 502) id D9A5237E48; Sun, 4 Jul 2004 09:36:46 +0200 (CEST) Received: from smtp2-1-sn4.m-sp.skanova.net (smtp2-1-sn4.m-sp.skanova.net [81.228.10.183]) by av7-1-sn4.m-sp.skanova.net (Postfix) with ESMTP id CB8CE37E42; Sun, 4 Jul 2004 09:36:46 +0200 (CEST) Received: from vit (h53n2fls31o265.telia.com [217.208.189.53]) by smtp2-1-sn4.m-sp.skanova.net (Postfix) with SMTP id A03A637E46; Sun, 4 Jul 2004 09:36:46 +0200 (CEST) From: "Gunnar Hellstrom" To: , , Subject: RE: [Simple] Using MSRP for (pseudo?) real time text conversation Date: Sun, 4 Jul 2004 09:36:46 +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: <200407011128.i61BSDb0004248@smtp.eweka.nl> Importance: Normal 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.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable I think last week=B4s intensive discussion was very useful. We saw a cult= ure collission between "real timers" and "messagers". For a real timer, the real time text component is a tiny part of a call w= here we are already used to set aside resources for the much more demanding media voi= ce and video. It is also natural to follow the same protocol for the text part, so that co= nnection is smooth, multipart handling is equal for all media, NAT traversal is on eq= ual termas etc. rfc2793 is already there, and the sip sdp is defined. We transmit at a de= fault maximum every 300 ms and behave well. There is no need to question this. It should have its way rapidly into em= ergency services, relay services, and everybody=B4s telephone in order to keep up with the = rapidly evolving VoIP and IP Multimedia areas. AVT is hopefully soon ready with the new co= mponents here, and I foresee most work in sipping, xcon and external fora, taking it int= o profiles for services in their domains. For the message side, sending three messages per seond seems threatening,= and the question is still if there is a case for introducing a real time mode. Or maybe a = "pseudo real time mode". Or if that should be avoided and a mode switch should be built int= o the applications for easy shift to the real time protocols. I want to take this discussion a couple of steps forward before deciding. 1. Are there environments where only IM protocols can be used? -------------------------------------------------------------- I think I saw in the discussion an opinion that there will be terminals w= here IM will be implemented, but not real time conversational voice. Some real time text = users do not bother about parallell voice. Today it is only 15% of the real time text = users, who use voice in parallell in the same call. I expect this figure to grow now, wh= en we have introduced more convenient user interfaces for simultaneous voice and tex= t. Evenso. text-only is also of interest. So, if there is something that blocks the = real time protocols but allow MSRP, I think it is worth while studying at least a p= seudo real time mode of MSRP. If the protocols can be implemented in parallell everywhere, I think we s= hould stick to RTP for real time text. 2. Can a pseudo-real-time mode for text be sufficient for IM users? ------------------------------------------------------------------- When I made my brief "research" last week, and found that the real time u= sers were happy with 300 ms buffering, but found 500 ms buffering too long, I noticed tha= t it was the jerkiness of the presentation that they were annoyed by, rather than the = delay itself. The traditional figures (from F.700, F.703) say that a delay of 2 seconds fro= m character entry to display can be accepted, but 1 second is regarded good. It may be so t= hat a smoothening of the presentation can make a method acceptable that includes one second= buffering. This is local policy, but general recommendations can be made. When in IM pseu= do real time mode, the presentation should be made so that characters received in one = block are presented evenly spread during the inter-block period. The default inter-= block period should be one second. This assumption needs validation. 3. Plain MSRP can be used for pseudo real time mode with a specific MIME = media type. -------------------------------------------------------------------------= ----------- If the validation of issue 2. is positive, the concerns about using MSRP = can be eliminated. We are then down to the same bandwidth use as RTP at 300 ms b= uffering. In the discussions it was clear that the only thing needed with MSRP to e= stablish a real time mode was to have a specific media type that is intended for this pur= pose that is used with the following characteristics: a. Collect entered characters during one second and transmit. b. Receive and display by concatenation in a consecutive area. c. Present characters in a smoothened fashion in time. d. Allow a few remote edits, at least "erase last character" and "new lin= e" in the same way as in ITU-T T.140. e. Unicode and ITU-T T.140 is a good candidate for the coding, because it= is used by nearly all other real time text implementations, and it would ease gatewa= ying. 4. Interoperability issues -------------------------- There are severe interoperability issues with this approach, because it i= ntroduces a second protocol for nearly the same thing in overlapping network environm= ents. So it is depending of the answer on question 1 if this should be considered. If in= troduced, good negotiation functions are needed, and discussions must be completed about= its consequences for emergency services, relay services, and the opportunity to ever harmo= nise real time conversational services in IP. 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 Sun Jul 4 06:04: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 GAA03864 for ; Sun, 4 Jul 2004 06:04: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 1Bh3r0-0001cj-Cq for simple-archive@ietf.org; Sun, 04 Jul 2004 06:04:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bh3q0-0001Oy-00 for simple-archive@ietf.org; Sun, 04 Jul 2004 06:03:09 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bh3pD-0000xh-00; Sun, 04 Jul 2004 06:02:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bh3Yl-0008JQ-VM; Sun, 04 Jul 2004 05:45:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bh3O4-000738-3w for simple@megatron.ietf.org; Sun, 04 Jul 2004 05:34: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 FAA03147 for ; Sun, 4 Jul 2004 05:34: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 1Bh3Nw-0002V9-Qg for simple@ietf.org; Sun, 04 Jul 2004 05:34:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bh3N2-0002GJ-00 for simple@ietf.org; Sun, 04 Jul 2004 05:33:13 -0400 Received: from smtp.eweka.nl ([81.171.101.3]) by ietf-mx with esmtp (Exim 4.12) id 1Bh3M7-00020n-00 for simple@ietf.org; Sun, 04 Jul 2004 05:32:15 -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 i649WXb0023401; Sun, 4 Jul 2004 11:32:44 +0200 (CEST) (envelope-from a.vwijk@viataal.nl) Message-Id: <200407040932.i649WXb0023401@smtp.eweka.nl> From: "Arnoud van Wijk" To: , , Subject: RE: Tiny ant vs big Mammoths, was RE: [Simple] Using MSRP for real time text conversation Date: Sun, 4 Jul 2004 11:31:53 +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: AcRfhSgGp69wz7mdQc2STF2vk1RzZAACN3aQAARB+kAABIe6EAAUstnAAGjglLA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB7023EEA8B@esebe019.ntc.nokia.com> Content-Transfer-Encoding: 7bit Cc: stf267@etsi.org, adam@dynamicsoft.com, simple@ietf.org, toip@snowshore.com, gunnar.hellstrom@omnitor.se, 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.8 required=5.0 tests=AWL,MAILTO_TO_SPAM_ADDR, MISSING_OUTLOOK_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Hisham, Actually... I did some market research. Based on 15 people. 3 deaf, 5 worked in deaf related business (hearing people) And 7 don't care about deaf (2 of them are IM freaks). Result: First telling them about total conversation and Interactive text (text/t140). It did not mean much to them, they looked glassy eyed. Real-time charcter per character..oh Yawn... lovely... pish posh. They could not imagine it. No concept of it. Then I showed them. They could communicate with somebody in Sweden, and with me on a different terminal in a different room. All were deeply impressed. The 3 deaf wanted to take it home right now. Being able to communicate everywhere , everytime..finally free! The 5 who worked in the deaf business, they loved it and want to see it implemted and mainstream. They love it and will use it regularly to communicate with deaf and some even say that it can be quite convenient for hearing people as well. The 7 hearing, non deaf related liked it too! They said, wow... this is much more direct then IM, you can actually call people in situations where voice is a bit not done (think cinema, concert, restaurant, train). They see it as direct real-time IM. They will keep using IM anyway. But see uses for text/t140 too and will use it if it is convenient. The 2 IM freaks agreed, though they prefer IM, but if somebdoy contacts them via interactive text text/t140, they will use it too. "It depends who to contact to use the right text communication method. I like the choice to have an alternative". So. Yes.. I know people will like it. Not everybody will use interactive text. Some will thus only use if somebody else uses it, whether a deaf person or one who likes to use text/t140. All of them hope that interactive text will be mainstream and will use it with varying degrees, from sometimes, to daily. So, this is my message, from an interactive text user AND having showed/demonstrated interactive text to other people. It is not my desire only. Greetz Arnoud -----Original Message----- From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] Sent: vrijdag 2 juli 2004 9:19 To: a.vwijk@viataal.nl; Henry.Sinnreich@mci.com; dean.willis@softarmor.com Cc: bcampbell@dynamicsoft.com; gunnar.hellstrom@omnitor.se; adam@dynamicsoft.com; stf267@etsi.org; simple@ietf.org; toip@snowshore.com Subject: RE: Tiny ant vs big Mammoths, was RE: [Simple] Using MSRP for real time text conversation Arnoud, You speak as if you have done the market research already for all of us :) How do you know that people will appreciate it once they discover it? How do you know that people will use it? How do you know that it adds value to the phone instead of just implementing something that no one will use? How do you know that if I like interactive text, then my mum and dad will and buy a phone like mine just to use interactive text???? How do you know...? Did people complain to you that IM the way it is these days in annoying to use? or are you just stating your opinion? And about mobile phones. If you can type an SMS faster than 2 characters a second, you're a genius. Even if you can, I don't believe operators would want to floor they scarce air interface with IP packets that carry 2 characters at a time. Thanks, Hisham _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jul 5 03:23: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 DAA11674 for ; Mon, 5 Jul 2004 03:23: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 1BhNog-0006In-9z for simple-archive@ietf.org; Mon, 05 Jul 2004 03:23:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BhNnn-00062m-00 for simple-archive@ietf.org; Mon, 05 Jul 2004 03:22:12 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BhNnB-0005lF-00; Mon, 05 Jul 2004 03:21:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BhNTl-0003TR-6o; Mon, 05 Jul 2004 03:01:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BhNHr-0002Nn-P2 for simple@megatron.ietf.org; Mon, 05 Jul 2004 02:49:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10174 for ; Mon, 5 Jul 2004 02:49: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 1BhNHk-0004X1-IA for simple@ietf.org; Mon, 05 Jul 2004 02:49:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BhNGn-0004Gx-00 for simple@ietf.org; Mon, 05 Jul 2004 02:48:06 -0400 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1BhNGB-00041F-00 for simple@ietf.org; Mon, 05 Jul 2004 02:47:27 -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 i656lF610988; Mon, 5 Jul 2004 09:47:15 +0300 (EET DST) X-Scanned: Mon, 5 Jul 2004 09:47:09 +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 i656l9o6007197; Mon, 5 Jul 2004 09:47:09 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00VBKYja; Mon, 05 Jul 2004 09:47:07 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 i656l7H13251; Mon, 5 Jul 2004 09:47:07 +0300 (EET DST) Received: from nokia.com ([172.21.42.108]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 5 Jul 2004 09:47:06 +0300 Message-ID: <40E8F96A.2090503@nokia.com> Date: Mon, 05 Jul 2004 09:47:06 +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: Mary Barnes Subject: Re: [Simple] Double specification: text and schema References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Jul 2004 06:47:06.0626 (UTC) FILETIME=[E32ED620:01C4625B] Content-Transfer-Encoding: 7bit Cc: "Joel M. Halpern" , Jonathan Rosenberg , SIMPLE mailing list X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org 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 Mary: I don't have any problem with having accurate comments on the text. My problem is with having normative statements that, at some point in time, may differ with the XML schema (which is also normative). I am just seeking for a future proof specification that allows interoperability. I have seen many other SDOs that systematically repeat normative statements across the same or different specifications, and you know what? They are always divergencies. As I want to avoid this divergence, my proposal is to avoid normative statements when the normative part is described in the XML schema. I still think that Jonathan's proposal was excellent: comment the XML schema in the text, but avoid normative statements. - Miguel Mary Barnes wrote: > I agree with Joel; I think we're getting back to the fundamental debate > on whether one should comment code or whether good code is self > documenting (or whether detailed design documents should have > pseudo-code or real code, etc.) It is important to have good and > accurate as possible textual descriptions along with the XML. And, I > don't see a problem with it being normative, either (in fact that would > be my preference). I don't consider myself an XML guru, but I can manage > my way through with the appropriate normative text. That's how it's > done for all the other specs; why should the XML based specs be any > different? > > Certainly, there are issues with some of the current documents in the > text that could be further clarified to ensure consistency with the XML > schema, but I think that's along the lines of the last point you make > below about putting a "bit of effort" in writing the documents. > > Regards, > Mary. > > -----Original Message----- > From: Miguel Garcia [mailto:Miguel.An.Garcia@nokia.com] > Sent: Friday, July 02, 2004 8:16 AM > To: Joel M. Halpern > Cc: Jonathan Rosenberg; SIMPLE mailing list > Subject: Re: [Simple] Double specification: text and schema > > > Well, here is the disagreement. I just want to tell authors: "don't use > normative text when there is normative definition expressed in the schema". > > Believe me, and record my words for a future time: if we start doing > double specification of normative requirements in RFCs, we will face > interoperability problems. > > If you are not able to put a bit of effort when writing your documents, > we all will pay in the future. > > - Miguel > > Joel M. Halpern wrote: > > > Part of what I am trying to avoid is telling authors that they must be > > extra careful never to use MUST words about things described in the > > schema. In a typical text description there will be explanatory text, > > there will be explanation of requirements that are also in the schema, > > and there will be explanation of requirements that are not in the > > schema. (Occasionally one gets lucky and the last category is empty.) > > As an author, I really don't want to have to try to change style from > > sentence to sentence in a section depending upon whether or not the > > particular behavior I am describing also occurs in the schema. > > Also, as I reader I would like to see a complete description in the > text. > > > > Yours, > > Joel M. Halpern > > > > At 06:23 AM 7/2/2004 -0400, Jonathan Rosenberg wrote: > > > > > >> Miguel Garcia wrote: > >> > >>> Hi Joel: > >>> I don't agree with you. We can't avoid the XML schema. I believe you > >>> agree with me. > >>> Since the XML schema already needs to indicate whether an element or > >>> attribute is mandatory or not, there is no point in repeating the > >>> same information in the text. What for? > >> > >> > >> I think that it can be useful for purposes of clarification. I would > >> advise using non-normative terminology in the text. So, for example: > >> > >> "The element includes a single mandatory attribute, "bar", and > >> always has two children, and ..." > >> > >> I think it also makes sense to have an explicit statement about the > >> normative nature of the schema, and that any explanatory text is not > >> normative. I routinely put such statements in "overview of operations" > >> sections, which are not written with RFC2119-strentgh terms. > >> > >> -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 > > > > > > -- > 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 > -- 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 Jul 5 03:48: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 DAA12492 for ; Mon, 5 Jul 2004 03:48: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 1BhOD1-0005NI-O9 for simple-archive@ietf.org; Mon, 05 Jul 2004 03:48:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BhOC5-00056p-00 for simple-archive@ietf.org; Mon, 05 Jul 2004 03:47:18 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BhOBZ-0004pi-00; Mon, 05 Jul 2004 03:46:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BhNvN-0005mE-33; Mon, 05 Jul 2004 03:30:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bh3Ye-0008Hm-NU for simple@megatron.ietf.org; Sun, 04 Jul 2004 05:45: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 FAA03399 for ; Sun, 4 Jul 2004 05:45: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 1Bh3YX-00053F-Bf for simple@ietf.org; Sun, 04 Jul 2004 05:45:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bh3XX-0004oS-00 for simple@ietf.org; Sun, 04 Jul 2004 05:44:04 -0400 Received: from smtp.eweka.nl ([81.171.101.3]) by ietf-mx with esmtp (Exim 4.12) id 1Bh3WZ-0004Zm-00 for simple@ietf.org; Sun, 04 Jul 2004 05:43:03 -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 i649hHb0023447; Sun, 4 Jul 2004 11:43:34 +0200 (CEST) (envelope-from a.vwijk@viataal.nl) Message-Id: <200407040943.i649hHb0023447@smtp.eweka.nl> From: "Arnoud van Wijk" To: , , , Subject: RE: [Simple] RE: [Sipping] RE: text/T140 andaudio/t140 was:[avt]Comments/questions on draft-ietf-av Date: Sun, 4 Jul 2004 11:42: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: AcRZ7oAhxcB0CC6GT5qLh6XIsdQ+iQAT8qmAABaV8PABXTxhMABnDTQQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB7023EEA94@esebe019.ntc.nokia.com> Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 05 Jul 2004 03:29:59 -0400 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.3 required=5.0 tests=AWL,MISSING_OUTLOOK_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Never say never. Have you tried interactive text/real-time text? Did you? First try it and THEN you can say if you like it or not. If you want to determine how useful it is. Test it. Use it Try it Compare it with IM. See the differences between IM and RTT/Interactive text. See that both text communication methods have their advantages and disadvantages. And use both for the best situations. And if you still don't want to use RTT/Interactive text..fine..I just hope that when I call you, that you can still receive my call. Just use it only when the other person uses Interactive text/RTT. Even if it is then 3-4 times per year. Can you with IM: * directly call the other? * forward the call? * put on hold? * have the call go to multiple terminals? * not being logged on a buddy list server, where you may get flooded by 20 users at the same time saying hi! And such? * being able to leave a message on an answering machine? * using a service that allows a ring notifivation as soon the other user is ready with his/her other phonecall? (ring back on busy). There are more.. but I am unfamiliar with voice calls. I am just enjoying my freedom of communications beyond the IM limitations. And I enjoy using IM also..even though I am forced to use Trillian, since there is NO one universal standard for IM right now! Interactive text is! Greetz Arnoud -----Original Message----- From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] Sent: vrijdag 2 juli 2004 10:27 To: a.vwijk@viataal.nl; paulej@packetizer.com; pkyzivat@cisco.com; Guido.Gybels@rnid.org.uk Cc: fluffy@cisco.com; simple@ietf.org; gv@trace.wisc.edu; toip@snowshore.com; gunnar.hellstrom@omnitor.se; smundra@telogy.com Subject: RE: [Simple] RE: [Sipping] RE: text/T140 andaudio/t140 was:[avt]Comments/questions on draft-ietf-av There is no hostility here. We are negotiating the usefulness of it. Some people prefer IM, others prefer interactive text, so it might an additional value service or a waste of implementer's time. No one knows. I would never, for example, use real time text since I, like many people in the world, am a very slow typist, make many typos and change my mind a lot about what I should say or how I should say it. One comment inline... > -----Original Message----- > From: simple-bounces@ietf.org > [mailto:simple-bounces@ietf.org]On Behalf > Of ext Arnoud van Wijk > Sent: 25.June.2004 12:51 > To: 'Paul E. Jones'; 'Paul Kyzivat'; 'Guido Gybels' > Cc: fluffy@cisco.com; simple@ietf.org; gv@trace.wisc.edu; > toip@snowshore.com; gunnar.hellstrom@omnitor.se; smundra@telogy.com > Subject: RE: [Simple] RE: [Sipping] RE: text/T140 andaudio/t140 > was:[avt]Comments/questions on draft-ietf-av > > > Good point Paul! > > Also..I want to point it out again... > WE ARE NOT TALKING ABOUT REPLACING INSTANT MESSAGING WITH > INTERACTIVE TEXT! > > Most of you already know that. But just today I met another > person who still > thinks Interactive text is to replace IM. > > I do not understand the hostility from several IM people. > Interactive text > is even going to make IM better! See it as an additional > valuable service > for IM. > Users exchange IM messages, and then a discussion starts, > they switch over > into real-time chat mode. Discuss things, work out plans in > real-time. Then > end the real-time chat mode. > And the next 2 hours they exchange a few IM messages. What makes this character-by-character (or x number of characters for 300ms) more interactive than IM in the scenario you describe above (besides the fact that you will see all my spelling mistakes, that I typed a message then changed my mind and deleted it)? > > 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. > > Cheers > > Arnoud > > > -----Original Message----- > From: owner-toip@snowshore.com > [mailto:owner-toip@snowshore.com] On Behalf > Of Paul E. Jones > Sent: vrijdag 25 juni 2004 1:16 > To: 'Paul Kyzivat'; 'Guido Gybels' > Cc: gunnar.hellstrom@omnitor.se; gv@trace.wisc.edu; fluffy@cisco.com; > simple@ietf.org; toip@snowshore.com; smundra@telogy.com; > a.vwijk@viataal.nl > Subject: RE: [Simple] RE: [Sipping] RE: text/T140 and audio/t140 > was:[avt]Comments/questions on draft-ietf-av > > 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 > > > - > 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 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jul 5 03: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 DAA12513 for ; Mon, 5 Jul 2004 03: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 1BhODm-0005cn-2H for simple-archive@ietf.org; Mon, 05 Jul 2004 03:49:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BhOCt-0005MS-00 for simple-archive@ietf.org; Mon, 05 Jul 2004 03:48:08 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BhOC0-0004pp-00; Mon, 05 Jul 2004 03:47:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BhNvN-0005mJ-Ou; Mon, 05 Jul 2004 03:30:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bh3jN-0000jC-8C for simple@megatron.ietf.org; Sun, 04 Jul 2004 05:56: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 FAA03675 for ; Sun, 4 Jul 2004 05:56: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 1Bh3jG-0007ZV-16 for simple@ietf.org; Sun, 04 Jul 2004 05:56:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bh3iM-0007Lk-00 for simple@ietf.org; Sun, 04 Jul 2004 05:55:15 -0400 Received: from smtp.eweka.nl ([81.171.101.3]) by ietf-mx with esmtp (Exim 4.12) id 1Bh3hq-00077m-00 for simple@ietf.org; Sun, 04 Jul 2004 05:54:42 -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 i649tJb0023495; Sun, 4 Jul 2004 11:55:25 +0200 (CEST) (envelope-from a.vwijk@viataal.nl) Message-Id: <200407040955.i649tJb0023495@smtp.eweka.nl> From: "Arnoud van Wijk" To: "'Guido Gybels'" , "'RNIDMAIL.GWIA.\"a.vwijk@viataal.nl\"'" , , Subject: RE: Tiny ant vs big Mammoths, was RE: [Simple] Using MSRP for real time text conversation Date: Sun, 4 Jul 2004 11:54:39 +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: AcRftJfncAsITg7EQOGPW0HW+dejdAAT7FkwAGn4DSA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 In-Reply-To: <4818CE251FC66942A7EF35B92695246E01B61A05@JUPITER-MSG.ad.rnid.org> Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 05 Jul 2004 03:29:59 -0400 Cc: stf267@etsi.org, adam@dynamicsoft.com, hisham.khartabil@nokia.com, simple@ietf.org, toip@snowshore.com, gunnar.hellstrom@omnitor.se, 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.9 required=5.0 tests=AWL,EXCUSE_16, MAILTO_TO_SPAM_ADDR,MISSING_OUTLOOK_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Guido, Thanks for your comments. When I said most do not use it..I meant Most do not use it on a day to day basis. Thus sometimes they sent an SMS message..or just receive an SMS message. But the strong pojnt is that SMS is available in every GSM phone! And many do not care if it is present..and then some day, they start using it..since it is available and easy to use (depending on the user ofcourse). My boss never uses SMS, but I can tell him per SMS when I am late for a meeting. He never replies. But mostly it works. He gets the message. So.. Interactive text is just as useless as SMS. That is what people tell me in those mails. :-) Greetz Arnoud -----Original Message----- From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf Of Guido Gybels Sent: vrijdag 2 juli 2004 9:26 To: RNIDMAIL.GWIA."a.vwijk@viataal.nl"; dean.willis@softarmor.com; Henry.Sinnreich@mci.com Cc: stf267@etsi.org; adam@dynamicsoft.com; hisham.khartabil@nokia.com; simple@ietf.org; toip@snowshore.com; gunnar.hellstrom@omnitor.se; bcampbell@dynamicsoft.com Subject: RE: Tiny ant vs big Mammoths,was RE: [Simple] Using MSRP for real time text conversation Arnoud, <> There is hope! I'm a pointy haired boss but I sure can see ahead! ;o) <> I don't know what audience you refer to, but ISTM that at least here in Europe *most* mobile phone users use SMS. And use it a lot. As far as RTT is concerned: every single time we at RNID demonstrate the mobile textphone to the general public, people are thrilled by it. They want one. And I'm talking about mainstream public here. So, yes, you are right when you say: "My message to the vendors is simple: implement interactive text. Text/t140." And it's up to us as a technical community to make sure that when the technology is build, it is build in a sound way, i.e. not a bunch of incompatible solutions, but something that is technically and economically viable AND that meets the needs of deaf and hard of hearing people while at the same time being able to offer something to the mainstream public. In that situation, everyone is a winner. You and I obviously understand that concept already, so let's make sure everyone else does too ;o) Keep up the good work, Arnoud, you are making a *real* difference to people's lives! As ever, Guido Guido Gybels Director of New Technologies RNID, 19-23 Featherstone Street London EC1Y 8SL, UK Tel +44(0)207 294 3713 Fax +44(0)207 296 8069 ************************************************************************ 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 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jul 5 04:11: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 EAA13336 for ; Mon, 5 Jul 2004 04:11: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 1BhOZ9-00041E-4k for simple-archive@ietf.org; Mon, 05 Jul 2004 04:11:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BhOYN-0003c5-00 for simple-archive@ietf.org; Mon, 05 Jul 2004 04:10:20 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BhOXr-0003Fw-00; Mon, 05 Jul 2004 04:09:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BhONe-0008AE-Vs; Mon, 05 Jul 2004 03:59:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BhNzL-00062Z-R9 for simple@megatron.ietf.org; Mon, 05 Jul 2004 03:34: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 DAA12020 for ; Mon, 5 Jul 2004 03:34: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 1BhNzE-0001VI-Kz for simple@ietf.org; Mon, 05 Jul 2004 03:34:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BhNyG-0001EU-00 for simple@ietf.org; Mon, 05 Jul 2004 03:33:00 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1BhNxE-0000oa-00 for simple@ietf.org; Mon, 05 Jul 2004 03:31:56 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i657VsJ26464; Mon, 5 Jul 2004 10:31:54 +0300 (EET DST) X-Scanned: Mon, 5 Jul 2004 10:31:44 +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 i657Vig0001517; Mon, 5 Jul 2004 10:31:44 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 006Nr6oK; Mon, 05 Jul 2004 10:31:43 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 i657VgH10136; Mon, 5 Jul 2004 10:31:43 +0300 (EET DST) Received: from nokia.com ([172.21.42.108]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 5 Jul 2004 10:31:30 +0300 Message-ID: <40E903D2.2050703@nokia.com> Date: Mon, 05 Jul 2004 10:31:30 +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] RE: XCAP Directory: Large response ? References: <40E5C2E1.50502@dynamicsoft.com> In-Reply-To: <40E5C2E1.50502@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Jul 2004 07:31:30.0992 (UTC) FILETIME=[1744D300:01C46262] Content-Transfer-Encoding: 7bit Cc: "George Foti \(QA/EMC\)" , 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 See below. Jonathan Rosenberg wrote: > inline. > > George Foti (QA/EMC) wrote: > >> Comments in line Miguel. >> [snip] >>> I believe we have two constraints here: one is the display size of >>> the device and the other is the memory of the device. I believe a >>> device may want to get a page of entries it can render in the >>> display, then release the memory, and request a new page. >>> >> >> I addition to what you state, anything that is returned has to be >> usable and we can do operations n them. > > > If you want pagination, I think you need to provide that as something > quite separate from the byte length constraints. Pagination is a very > application/content specific thing. Indeed, if the goal were to say > "give me the first N children of this element", thats something that the > multiple-element selection can do. I think you'd want to then add a > Ranges header to protect yourself against byte overload in the case > where an entry is too large. > > XPath provides the ability to do that kind of selection. Something like > this would work: > > list/buddy[position() > N and position() < M] > > That would give you the Nth through Mth buddy elements. > > XCAP doesnt support that level of complexity in the server. If it did, > and you wanted protection against memory overload (say, 1k max), you'd > do something like this: > > GET http://server/blah-blah/list/buddy[position() > N and position() < M] > Range: bytes=0-1000 > > If the response is truncated, then you need to adjust your pagination > size on the client. > > -Jonathan R. > I think this is going in the right direction now. So let me ask a couple of questions to verify that the position() is valid for the purpose we want. 1) Is position already part of XCAP? By reading the XCAP base document I guess the answer is yes. 2) I guess if we have a non-flat list, the position element will operate in all the leaves of the XML document. For instance, if we have a resource list document, with several elements, each one containing a few elements, the position() predicate executed in the element will consider the element sequentially ordered. Let me try to explain better with an example. Consider the following resource list XML document. Bill Doe Johanna Doe Joe Smith Nancy Gross Peter Black http://www.example.org/xcap/resource-lists/users/a/foo There are 5 elements, named Bill, Johanna, Joe, Nancy and Peter. Imagine I want entries 2 to 4 (in spite they span across different lists). Will the HTTP URI be something like: GET http://server/blah-blah/resource-lists/users/jack/entry[position()>1 and position()<5] 3) I believe the HTTP byte ranges is a complement of this feature, a kind of emergency life jacket that under normal circumstances will not be use. I doubt an XCAP client can do much with an XML document that is truncated by the byte ranges: it can just discard the contents or store them (if it has enough memory) and request the rest of the document. - 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 Mon Jul 5 04:26: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 EAA14184 for ; Mon, 5 Jul 2004 04:26: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 1BhOnv-0000dv-A4 for simple-archive@ietf.org; Mon, 05 Jul 2004 04:26:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BhOmz-0000Lv-00 for simple-archive@ietf.org; Mon, 05 Jul 2004 04:25:26 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BhOmT-00001o-00; Mon, 05 Jul 2004 04:24:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BhOPR-0008RT-Aq; Mon, 05 Jul 2004 04:01:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BhOA3-000773-O8 for simple@megatron.ietf.org; Mon, 05 Jul 2004 03:45: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 DAA12384 for ; Mon, 5 Jul 2004 03:45: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 1BhO9w-0004WR-KQ for simple@ietf.org; Mon, 05 Jul 2004 03:45:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BhO8v-0004EF-00 for simple@ietf.org; Mon, 05 Jul 2004 03:44:02 -0400 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1BhO81-0003xY-00 for simple@ietf.org; Mon, 05 Jul 2004 03:43:06 -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 i657h0621942; Mon, 5 Jul 2004 10:43:00 +0300 (EET DST) X-Scanned: Mon, 5 Jul 2004 10:42: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 i657gts9002970; Mon, 5 Jul 2004 10:42:55 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00rp1BBg; Mon, 05 Jul 2004 10:42:53 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 i657gqH01809; Mon, 5 Jul 2004 10:42:52 +0300 (EET DST) Received: from nokia.com ([172.21.42.108]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 5 Jul 2004 10:42:39 +0300 Message-ID: <40E9066F.1020706@nokia.com> Date: Mon, 05 Jul 2004 10:42:39 +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: Ted Hardie Subject: Re: [Simple] Re: XCAP Directory: Large response ? References: <342C4681F0D4A04CA50A97D74DA8FB9A0C0AC79B@esealnt875.al.sw.ericsson.se> <40E521E2.9010209@nokia.com> <40E53251.6000102@dynamicsoft.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Jul 2004 07:42:39.0343 (UTC) FILETIME=[A5A317F0:01C46263] Content-Transfer-Encoding: 7bit Cc: Jonathan Rosenberg , 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 I think the discussion is becoming clearer now. For sure an XCAP client will have knowledge of the schema is trying to download/manipulate, so in most circumstances it can just request to download a few elements (e.g., the "good friends" list). The problems is when I get my brand new mobile device, and I want to add a new buddy to my list. First I need to download my complete presence list. If that list is huge (well, imagine my companies employees list), then I may flood my terminal (or even the access network). The Range header in HTTP does not seem to be quite useful, since it will truncate the XML document. Then the XCAP client cannot validate it, it can either request the rest of the document or abort the operation. The position() XPath operator seems to fulfill the requirements. I can request entries 1 to 50 to avoid flooding my terminal. Since the XCAP server will return a valid XML document, it can be displayed to the user, and do some manipulation. Then the XCAP client can request entries 51 to 100, etc. Yes, we don't know how many bytes will be sent to the terminal in each of the pages, but I don't think the exact number of bytes is so important, what is important is the number of entries in a list. - Miguel Ted Hardie wrote: > At 6:00 AM -0400 7/2/04, Jonathan Rosenberg wrote: > >> >> I would propose that we not put this functionality in xcap itself, but >> use the existing HTTP mechanisms. I will note that these mechanisms >> are *byte* oriented, and not XML oriented. Thus, you may cut an >> element off in the middle by asking for the first 50 bytes. However, >> if your main concern is bandwidth or latency, then bytes are much more >> significant of a measure than elements. If I say, "give me 30 >> elements", that could be 30 bytes or 30MB, depennding on the amount of >> data in each element. > > > I'd like to strongly support this view. XCAP is currently a profile of > HTTP, and re-using HTTP methods makes a great deal of sense here. > Attempting to extend XCAP to include mechanisms that are not part > of the core of HTTP will require either extending HTTP (hard) > or diverging from HTTP (problematic for code re-use, which has > been a key factor before). > > I'd also like to point out that the problem (unexpectedly large responses) > may be less likely than originally supposed. An XCAP client will have > to have some knowledge of the schema with which it is interacting > in order to get the base advantage of XCAP over HTTP. That is, it > will have to know the break points between things like the whole > buddy list, the list of "friends", the subset of "friends" who are > "good friends", and a possibly overlapping set of "work colleagues". > While it would not be formally part of the schema, it would not be > hard to store the number of elements last known for each of the > break points in the hierarchy; indeed, the previous discussion of > positional insertions seemed to presume this was stored. Even > without positional insertions, this is useful information that it is > relatively easy to store and maintain. As Jonathan points out, > it still won't map perfection to bytes, since elements may be of > different sizes, but it will help the client understand the likely > size of a request. > > regards, > Ted Hardie -- 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 Jul 5 06:11: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 GAA18190 for ; Mon, 5 Jul 2004 06:11: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 1BhQRQ-0005oo-4v for simple-archive@ietf.org; Mon, 05 Jul 2004 06:11:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BhQQc-0005X9-00 for simple-archive@ietf.org; Mon, 05 Jul 2004 06:10:27 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BhQPi-000500-00; Mon, 05 Jul 2004 06:09:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BhQ9l-00028y-KG; Mon, 05 Jul 2004 05:53:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BhPxR-00014d-7m for simple@megatron.ietf.org; Mon, 05 Jul 2004 05:40: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 FAA16712 for ; Mon, 5 Jul 2004 05:40:09 -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 1BhPxJ-000511-Qe for simple@ietf.org; Mon, 05 Jul 2004 05:40:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BhPwO-0004l7-00 for simple@ietf.org; Mon, 05 Jul 2004 05:39:13 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BhPvb-0004VJ-00 for simple@ietf.org; Mon, 05 Jul 2004 05:38:23 -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 i659cGN29003; Mon, 5 Jul 2004 12:38:16 +0300 (EET DST) X-Scanned: Mon, 5 Jul 2004 12:38:03 +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 i659c3DU012391; Mon, 5 Jul 2004 12:38:03 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 00OLKDUv; Mon, 05 Jul 2004 12:38:02 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 i659c2H26802; Mon, 5 Jul 2004 12:38:02 +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, 5 Jul 2004 12:38:01 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [Simple] Re: XCAP Directory: Large response ? Date: Mon, 5 Jul 2004 12:38:02 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7023EEAA7@esebe019.ntc.nokia.com> Thread-Topic: [Simple] Re: XCAP Directory: Large response ? Thread-Index: AcRibyi2y4f1UqJjTTyelG/PTpjyXAABFx9g To: , X-OriginalArrivalTime: 05 Jul 2004 09:38:01.0748 (UTC) FILETIME=[C3B64540:01C46273] Content-Transfer-Encoding: quoted-printable 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.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable I wonder if you can use the following event filtering draft with HTTP = GET? http://www.ietf.org/internet-drafts/draft-ietf-simple-filter-format-01.tx= t (currently in WGLC) At least the part could be useful. /Hisham > -----Original Message----- > From: simple-bounces@ietf.org=20 > [mailto:simple-bounces@ietf.org]On Behalf > Of ext Miguel Garcia > Sent: 05.July.2004 10:43 > To: Ted Hardie > Cc: Jonathan Rosenberg; simple@ietf.org > Subject: Re: [Simple] Re: XCAP Directory: Large response ? >=20 >=20 > I think the discussion is becoming clearer now. For sure an=20 > XCAP client=20 > will have knowledge of the schema is trying to=20 > download/manipulate, so=20 > in most circumstances it can just request to download a few elements=20 > (e.g., the "good friends" list). >=20 > The problems is when I get my brand new mobile device, and I=20 > want to add=20 > a new buddy to my list. First I need to download my complete presence=20 > list. If that list is huge (well, imagine my companies=20 > employees list),=20 > then I may flood my terminal (or even the access network). >=20 > The Range header in HTTP does not seem to be quite useful,=20 > since it will=20 > truncate the XML document. Then the XCAP client cannot=20 > validate it, it=20 > can either request the rest of the document or abort the operation. >=20 > The position() XPath operator seems to fulfill the=20 > requirements. I can=20 > request entries 1 to 50 to avoid flooding my terminal. Since the XCAP=20 > server will return a valid XML document, it can be displayed to the=20 > user, and do some manipulation. Then the XCAP client can=20 > request entries=20 > 51 to 100, etc. >=20 > Yes, we don't know how many bytes will be sent to the=20 > terminal in each=20 > of the pages, but I don't think the exact number of bytes is so=20 > important, what is important is the number of entries in a list. >=20 > - Miguel >=20 > Ted Hardie wrote: >=20 > > At 6:00 AM -0400 7/2/04, Jonathan Rosenberg wrote: > >=20 > >> > >> I would propose that we not put this functionality in xcap=20 > itself, but=20 > >> use the existing HTTP mechanisms. I will note that these=20 > mechanisms=20 > >> are *byte* oriented, and not XML oriented. Thus, you may cut an=20 > >> element off in the middle by asking for the first 50=20 > bytes. However,=20 > >> if your main concern is bandwidth or latency, then bytes=20 > are much more=20 > >> significant of a measure than elements. If I say, "give me 30=20 > >> elements", that could be 30 bytes or 30MB, depennding on=20 > the amount of=20 > >> data in each element. > >=20 > >=20 > > I'd like to strongly support this view. XCAP is currently=20 > a profile of > > HTTP, and re-using HTTP methods makes a great deal of sense here. > > Attempting to extend XCAP to include mechanisms that are not part > > of the core of HTTP will require either extending HTTP (hard) > > or diverging from HTTP (problematic for code re-use, which has > > been a key factor before). > >=20 > > I'd also like to point out that the problem (unexpectedly=20 > large responses) > > may be less likely than originally supposed. An XCAP=20 > client will have > > to have some knowledge of the schema with which it is interacting > > in order to get the base advantage of XCAP over HTTP. That is, it > > will have to know the break points between things like the whole > > buddy list, the list of "friends", the subset of "friends" who are > > "good friends", and a possibly overlapping set of "work colleagues". > > While it would not be formally part of the schema, it would not be > > hard to store the number of elements last known for each of the > > break points in the hierarchy; indeed, the previous discussion of > > positional insertions seemed to presume this was stored. Even > > without positional insertions, this is useful information that it is > > relatively easy to store and maintain. As Jonathan points out, > > it still won't map perfection to bytes, since elements may be of > > different sizes, but it will help the client understand the likely > > size of a request. > >=20 > > regards, > > Ted Hardie >=20 > --=20 > Miguel A. Garcia tel:+358-50-4804586 > Nokia Research Center Helsinki, Finland >=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 Jul 5 06:25: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 GAA18809 for ; Mon, 5 Jul 2004 06: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 1BhQeu-0001tn-1f for simple-archive@ietf.org; Mon, 05 Jul 2004 06:25:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BhQe1-0001cl-00 for simple-archive@ietf.org; Mon, 05 Jul 2004 06:24:17 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BhQdM-0001JX-00; Mon, 05 Jul 2004 06:23:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BhQJv-0002yt-VD; Mon, 05 Jul 2004 06:03:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BhQ9I-00025t-MY for simple@megatron.ietf.org; Mon, 05 Jul 2004 05:52: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 FAA17298 for ; Mon, 5 Jul 2004 05:52: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 1BhQ9B-0000YF-AQ for simple@ietf.org; Mon, 05 Jul 2004 05:52:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BhQ8I-0000GD-00 for simple@ietf.org; Mon, 05 Jul 2004 05:51:31 -0400 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1BhQ7F-0007kQ-00 for simple@ietf.org; Mon, 05 Jul 2004 05:50: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 i659oI601007; Mon, 5 Jul 2004 12:50:18 +0300 (EET DST) X-Scanned: Mon, 5 Jul 2004 12:50:13 +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 i659oDxR007698; Mon, 5 Jul 2004 12:50:13 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 00qbN2Ac; Mon, 05 Jul 2004 12:50:12 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 i659oCH04542; Mon, 5 Jul 2004 12:50:12 +0300 (EET DST) Received: from nokia.com ([172.21.42.108]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 5 Jul 2004 12:50:07 +0300 Message-ID: <40E9244F.9090303@nokia.com> Date: Mon, 05 Jul 2004 12:50:07 +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: "Khartabil Hisham (Nokia-TP-MSW/Helsinki)" Subject: Re: [Simple] Re: XCAP Directory: Large response ? References: <2038BCC78B1AD641891A0D1AE133DBB7023EEAA7@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB7023EEAA7@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Jul 2004 09:50:07.0596 (UTC) FILETIME=[7459E2C0:01C46275] Content-Transfer-Encoding: 7bit Cc: Ted Hardie , Jonathan Rosenberg , 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 I am writing a set of comments to the filter format, but when I read the document I thought it was only applicable to SIP events. At least the Abstract and the Introduction consider only the case where the filter applies to SIP Notifications. However, in this thread, we were discussing XCAP documents that you retrieve with an HTTP GET. Are you suggesting that Filter Criteria documents can be applied to XCAP? Is this discussed somewhere? - Miguel Khartabil Hisham (Nokia-TP-MSW/Helsinki) wrote: > I wonder if you can use the following event filtering draft with HTTP GET? > > http://www.ietf.org/internet-drafts/draft-ietf-simple-filter-format-01.txt (currently in WGLC) > > At least the part could be useful. > > /Hisham > > >>-----Original Message----- >>From: simple-bounces@ietf.org >>[mailto:simple-bounces@ietf.org]On Behalf >>Of ext Miguel Garcia >>Sent: 05.July.2004 10:43 >>To: Ted Hardie >>Cc: Jonathan Rosenberg; simple@ietf.org >>Subject: Re: [Simple] Re: XCAP Directory: Large response ? >> >> >>I think the discussion is becoming clearer now. For sure an >>XCAP client >>will have knowledge of the schema is trying to >>download/manipulate, so >>in most circumstances it can just request to download a few elements >>(e.g., the "good friends" list). >> >>The problems is when I get my brand new mobile device, and I >>want to add >>a new buddy to my list. First I need to download my complete presence >>list. If that list is huge (well, imagine my companies >>employees list), >>then I may flood my terminal (or even the access network). >> >>The Range header in HTTP does not seem to be quite useful, >>since it will >>truncate the XML document. Then the XCAP client cannot >>validate it, it >>can either request the rest of the document or abort the operation. >> >>The position() XPath operator seems to fulfill the >>requirements. I can >>request entries 1 to 50 to avoid flooding my terminal. Since the XCAP >>server will return a valid XML document, it can be displayed to the >>user, and do some manipulation. Then the XCAP client can >>request entries >>51 to 100, etc. >> >>Yes, we don't know how many bytes will be sent to the >>terminal in each >>of the pages, but I don't think the exact number of bytes is so >>important, what is important is the number of entries in a list. >> >>- Miguel >> >>Ted Hardie wrote: >> >> >>>At 6:00 AM -0400 7/2/04, Jonathan Rosenberg wrote: >>> >>> >>>>I would propose that we not put this functionality in xcap >> >>itself, but >> >>>>use the existing HTTP mechanisms. I will note that these >> >>mechanisms >> >>>>are *byte* oriented, and not XML oriented. Thus, you may cut an >>>>element off in the middle by asking for the first 50 >> >>bytes. However, >> >>>>if your main concern is bandwidth or latency, then bytes >> >>are much more >> >>>>significant of a measure than elements. If I say, "give me 30 >>>>elements", that could be 30 bytes or 30MB, depennding on >> >>the amount of >> >>>>data in each element. >>> >>> >>>I'd like to strongly support this view. XCAP is currently >> >>a profile of >> >>>HTTP, and re-using HTTP methods makes a great deal of sense here. >>>Attempting to extend XCAP to include mechanisms that are not part >>>of the core of HTTP will require either extending HTTP (hard) >>>or diverging from HTTP (problematic for code re-use, which has >>>been a key factor before). >>> >>>I'd also like to point out that the problem (unexpectedly >> >>large responses) >> >>>may be less likely than originally supposed. An XCAP >> >>client will have >> >>>to have some knowledge of the schema with which it is interacting >>>in order to get the base advantage of XCAP over HTTP. That is, it >>>will have to know the break points between things like the whole >>>buddy list, the list of "friends", the subset of "friends" who are >>>"good friends", and a possibly overlapping set of "work colleagues". >>>While it would not be formally part of the schema, it would not be >>>hard to store the number of elements last known for each of the >>>break points in the hierarchy; indeed, the previous discussion of >>>positional insertions seemed to presume this was stored. Even >>>without positional insertions, this is useful information that it is >>>relatively easy to store and maintain. As Jonathan points out, >>>it still won't map perfection to bytes, since elements may be of >>>different sizes, but it will help the client understand the likely >>>size of a request. >>> >>> regards, >>> Ted Hardie >> >>-- >>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 > > -- 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 Jul 5 06:29: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 GAA18995 for ; Mon, 5 Jul 2004 06: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 1BhQir-00033w-5y for simple-archive@ietf.org; Mon, 05 Jul 2004 06:29:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BhQhq-0002kl-00 for simple-archive@ietf.org; Mon, 05 Jul 2004 06:28:15 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BhQgh-0002Ck-00; Mon, 05 Jul 2004 06:27:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BhQMk-0003GM-5C; Mon, 05 Jul 2004 06:06:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BhQCx-0002Pk-5U for simple@megatron.ietf.org; Mon, 05 Jul 2004 05:56: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 FAA17446 for ; Mon, 5 Jul 2004 05:56: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 1BhQCp-0001eb-S3 for simple@ietf.org; Mon, 05 Jul 2004 05:56:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BhQBr-0001NW-00 for simple@ietf.org; Mon, 05 Jul 2004 05:55:12 -0400 Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx with esmtp (Exim 4.12) id 1BhQB0-0000rD-00 for simple@ietf.org; Mon, 05 Jul 2004 05:54:18 -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 i659rl5w013352 for ; Mon, 5 Jul 2004 04:53:48 -0500 (CDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Mon, 5 Jul 2004 10:53:47 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB00C29013E@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: simple@ietf.org Subject: RE: [Simple] RE: [Sipping] RE: text/T140 andaudio/t140 was:[avt]C omments/questions on draft-ietf-av Date: Mon, 5 Jul 2004 10:53:45 +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 Given the length of time this discussion has been going on, and the number of messages exchanged, is it not about time we reached some conclusions. These lists are to advance the deliverables in the working groups concerned, so how do any conclusions affect those deliverables. SIMPLE has a charter to produce instant messaging protocols. I do not see in all the discussion of the advantages of instant messaging versus real-time text removing that charter item. Therefore I suggest we STOP that discussion, or the proponents move it elsewhere. SIMPLE does not have a charter item to produce real-time text protocols. There is already an existing capability in IETF for real-time text protocols. It is not really up to SIMPLE to discuss whether that works well or not, as it was not developed under SIMPLEs charter. How terminals mix and match applications is not something that IETF traditionally deals with. Therefore I would suggest that any requirements that state RTT and IM must be implemented in the same terminal are out of scope of IETF. They should certainly be in some device specification rather than in the MSRP specification which SIMPLE is specifically delivering. I guess the questions as affecting MSRP really fall down to these: - Are there capabilities in MSRP that would lead to a valid RTT protocol that works better than the existing IETF solution, in addition to it fulfilling the requirements to provide an IM protocol. From the exchange of messages I have seem so far, it seems to me that the conclusion should be NO. - In order to deal with a body of users that have IM, and prefer to use IM, and a body of users that have RTT, and prefer to use RTT, is there a need to be able to interwork the two protocols at some intermediate point, and not just within the terminal by supporting both protocols under a common user interface? I see that as an element of the discussion just raised by Paul. Does such interworking, if required, have any impact on the contents of MSRP? regards Keith Keith Drage Lucent Technologies drage@lucent.com tel: +44 1793 776249 > -----Original Message----- > From: Arnoud van Wijk [mailto:a.vwijk@viataal.nl] > Sent: 04 July 2004 10:43 > To: hisham.khartabil@nokia.com; paulej@packetizer.com; > pkyzivat@cisco.com; Guido.Gybels@rnid.org.uk > Cc: fluffy@cisco.com; simple@ietf.org; gv@trace.wisc.edu; > toip@snowshore.com; gunnar.hellstrom@omnitor.se; smundra@telogy.com > Subject: RE: [Simple] RE: [Sipping] RE: text/T140 andaudio/t140 > was:[avt]Comments/questions on draft-ietf-av > > > Never say never. > Have you tried interactive text/real-time text? > Did you? > > First try it and THEN you can say if you like it or not. > > If you want to determine how useful it is. Test it. > Use it > Try it > Compare it with IM. > See the differences between IM and RTT/Interactive text. > See that both text communication methods have their advantages and > disadvantages. > And use both for the best situations. > > And if you still don't want to use RTT/Interactive > text..fine..I just hope > that when I call you, that you can still receive my call. > Just use it only > when the other person uses Interactive text/RTT. > Even if it is then 3-4 times per year. > > Can you with IM: > * directly call the other? > * forward the call? > * put on hold? > * have the call go to multiple terminals? > * not being logged on a buddy list server, where you may get > flooded by 20 > users at the same time saying hi! And such? > * being able to leave a message on an answering machine? > * using a service that allows a ring notifivation as soon the > other user is > ready with his/her other phonecall? (ring back on busy). > > There are more.. but I am unfamiliar with voice calls. I am > just enjoying my > freedom of communications beyond the IM limitations. > > And I enjoy using IM also..even though I am forced to use > Trillian, since > there is NO one universal standard for IM right now! > > Interactive text is! > > Greetz > > Arnoud > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jul 5 08:13: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 IAA22836 for ; Mon, 5 Jul 2004 08:13: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 1BhSLd-0000E8-Dp for simple-archive@ietf.org; Mon, 05 Jul 2004 08:13:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BhSKi-0007kV-00 for simple-archive@ietf.org; Mon, 05 Jul 2004 08:12:29 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BhSKM-0007TO-00; Mon, 05 Jul 2004 08:12:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BhS7J-0005JY-UK; Mon, 05 Jul 2004 07:58:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BhRzN-0004ae-Km for simple@megatron.ietf.org; Mon, 05 Jul 2004 07:50: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 HAA22115 for ; Mon, 5 Jul 2004 07:50: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 1BhRzI-0001mv-2S for simple@ietf.org; Mon, 05 Jul 2004 07:50:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BhRyM-0001Wo-00 for simple@ietf.org; Mon, 05 Jul 2004 07:49:23 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BhRxu-0001GO-00 for simple@ietf.org; Mon, 05 Jul 2004 07:48: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 i65BmjN19036; Mon, 5 Jul 2004 14:48:45 +0300 (EET DST) X-Scanned: Mon, 5 Jul 2004 14:48:25 +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 i65BmPhZ032397; Mon, 5 Jul 2004 14:48:25 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00Bcm2vh; Mon, 05 Jul 2004 14:48:24 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 i65BmEH02267; Mon, 5 Jul 2004 14:48:14 +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, 5 Jul 2004 14:48:13 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 5 Jul 2004 14:48:13 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [Simple] Re: XCAP Directory: Large response ? Date: Mon, 5 Jul 2004 14:48:14 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7023EEAAA@esebe019.ntc.nokia.com> Thread-Topic: [Simple] Re: XCAP Directory: Large response ? Thread-Index: AcRifyxkOxE0eccfQEevtr4zs8LnkgABqipQ To: X-OriginalArrivalTime: 05 Jul 2004 11:48:13.0571 (UTC) FILETIME=[F3EBDD30:01C46285] Content-Transfer-Encoding: quoted-printable Cc: hardie@qualcomm.com, 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.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 Miguel Garcia > Sent: 05.July.2004 12:50 > To: Khartabil Hisham (Nokia-TP-MSW/Helsinki) > Cc: Ted Hardie; Jonathan Rosenberg; simple@ietf.org > Subject: Re: [Simple] Re: XCAP Directory: Large response ? >=20 >=20 > I am writing a set of comments to the filter format, but when=20 > I read the=20 > document I thought it was only applicable to SIP events. At least the=20 > Abstract and the Introduction consider only the case where the filter=20 > applies to SIP Notifications. >=20 > However, in this thread, we were discussing XCAP documents that you=20 > retrieve with an HTTP GET. >=20 > Are you suggesting that Filter Criteria documents can be applied to=20 > XCAP? Is this discussed somewhere? It's not discussed in the draft, but I was suggesting it can be applied = (the XML format) /Hisham >=20 > - Miguel >=20 > Khartabil Hisham (Nokia-TP-MSW/Helsinki) wrote: > > I wonder if you can use the following event filtering draft=20 > with HTTP GET? > >=20 > >=20 > http://www.ietf.org/internet-drafts/draft-ietf-simple-filter-f > ormat-01.txt (currently in WGLC) > >=20 > > At least the part could be useful. > >=20 > > /Hisham > >=20 > >=20 > >>-----Original Message----- > >>From: simple-bounces@ietf.org=20 > >>[mailto:simple-bounces@ietf.org]On Behalf > >>Of ext Miguel Garcia > >>Sent: 05.July.2004 10:43 > >>To: Ted Hardie > >>Cc: Jonathan Rosenberg; simple@ietf.org > >>Subject: Re: [Simple] Re: XCAP Directory: Large response ? > >> > >> > >>I think the discussion is becoming clearer now. For sure an=20 > >>XCAP client=20 > >>will have knowledge of the schema is trying to=20 > >>download/manipulate, so=20 > >>in most circumstances it can just request to download a few=20 > elements=20 > >>(e.g., the "good friends" list). > >> > >>The problems is when I get my brand new mobile device, and I=20 > >>want to add=20 > >>a new buddy to my list. First I need to download my=20 > complete presence=20 > >>list. If that list is huge (well, imagine my companies=20 > >>employees list),=20 > >>then I may flood my terminal (or even the access network). > >> > >>The Range header in HTTP does not seem to be quite useful,=20 > >>since it will=20 > >>truncate the XML document. Then the XCAP client cannot=20 > >>validate it, it=20 > >>can either request the rest of the document or abort the operation. > >> > >>The position() XPath operator seems to fulfill the=20 > >>requirements. I can=20 > >>request entries 1 to 50 to avoid flooding my terminal.=20 > Since the XCAP=20 > >>server will return a valid XML document, it can be displayed to the=20 > >>user, and do some manipulation. Then the XCAP client can=20 > >>request entries=20 > >>51 to 100, etc. > >> > >>Yes, we don't know how many bytes will be sent to the=20 > >>terminal in each=20 > >>of the pages, but I don't think the exact number of bytes is so=20 > >>important, what is important is the number of entries in a list. > >> > >>- Miguel > >> > >>Ted Hardie wrote: > >> > >> > >>>At 6:00 AM -0400 7/2/04, Jonathan Rosenberg wrote: > >>> > >>> > >>>>I would propose that we not put this functionality in xcap=20 > >> > >>itself, but=20 > >> > >>>>use the existing HTTP mechanisms. I will note that these=20 > >> > >>mechanisms=20 > >> > >>>>are *byte* oriented, and not XML oriented. Thus, you may cut an=20 > >>>>element off in the middle by asking for the first 50=20 > >> > >>bytes. However,=20 > >> > >>>>if your main concern is bandwidth or latency, then bytes=20 > >> > >>are much more=20 > >> > >>>>significant of a measure than elements. If I say, "give me 30=20 > >>>>elements", that could be 30 bytes or 30MB, depennding on=20 > >> > >>the amount of=20 > >> > >>>>data in each element. > >>> > >>> > >>>I'd like to strongly support this view. XCAP is currently=20 > >> > >>a profile of > >> > >>>HTTP, and re-using HTTP methods makes a great deal of sense here. > >>>Attempting to extend XCAP to include mechanisms that are not part > >>>of the core of HTTP will require either extending HTTP (hard) > >>>or diverging from HTTP (problematic for code re-use, which has > >>>been a key factor before). > >>> > >>>I'd also like to point out that the problem (unexpectedly=20 > >> > >>large responses) > >> > >>>may be less likely than originally supposed. An XCAP=20 > >> > >>client will have > >> > >>>to have some knowledge of the schema with which it is interacting > >>>in order to get the base advantage of XCAP over HTTP. That is, it > >>>will have to know the break points between things like the whole > >>>buddy list, the list of "friends", the subset of "friends" who are > >>>"good friends", and a possibly overlapping set of "work=20 > colleagues". > >>>While it would not be formally part of the schema, it would not be > >>>hard to store the number of elements last known for each of the > >>>break points in the hierarchy; indeed, the previous discussion of > >>>positional insertions seemed to presume this was stored. Even > >>>without positional insertions, this is useful information=20 > that it is > >>>relatively easy to store and maintain. As Jonathan points out, > >>>it still won't map perfection to bytes, since elements may be of > >>>different sizes, but it will help the client understand the likely > >>>size of a request. > >>> > >>> regards, > >>> Ted Hardie > >> > >>--=20 > >>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 > >=20 > >=20 >=20 > --=20 > Miguel A. Garcia tel:+358-50-4804586 > Nokia Research Center Helsinki, Finland >=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 Jul 5 08:41: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 IAA24039 for ; Mon, 5 Jul 2004 08:41: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 1BhSme-000028-Lh for simple-archive@ietf.org; Mon, 05 Jul 2004 08:41:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BhSlj-0007ZC-00 for simple-archive@ietf.org; Mon, 05 Jul 2004 08:40:24 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BhSl1-00073a-00; Mon, 05 Jul 2004 08:39:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BhST8-0007Nf-Kk; Mon, 05 Jul 2004 08:21:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BhSGs-000627-0W for simple@megatron.ietf.org; Mon, 05 Jul 2004 08:08: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 IAA22652 for ; Mon, 5 Jul 2004 08:08:23 -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 1BhSGm-0006eN-AB for simple@ietf.org; Mon, 05 Jul 2004 08:08:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BhSFh-0006Nh-00 for simple@ietf.org; Mon, 05 Jul 2004 08:07:17 -0400 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1BhSEx-00067o-00 for simple@ietf.org; Mon, 05 Jul 2004 08:06:31 -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 i65C6R612803; Mon, 5 Jul 2004 15:06:27 +0300 (EET DST) X-Scanned: Mon, 5 Jul 2004 15:06:21 +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 i65C6LBW010150; Mon, 5 Jul 2004 15:06:21 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00AzcJQc; Mon, 05 Jul 2004 15:06:11 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 i65C5vH18703; Mon, 5 Jul 2004 15:05:57 +0300 (EET DST) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 5 Jul 2004 15:05:34 +0300 Received: from trebe003.NOE.Nokia.com ([172.22.232.175]) by esebe023.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 5 Jul 2004 15:05: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] WGLC: Event Filtering Date: Mon, 5 Jul 2004 15:05:32 +0300 Message-ID: Thread-Topic: [Simple] WGLC: Event Filtering Thread-Index: AcRetS+6gkZh4cbWRPmITzYUThfuYwD0faTg To: , , X-OriginalArrivalTime: 05 Jul 2004 12:05:32.0594 (UTC) FILETIME=[5F3A3120:01C46288] 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, Please find below some comments to the filter-format-01 draft: In the beginning of the subsection 3.3.1 ("include") it is said that an = XML attribute can be selected as content to be delivered. However, it is = not clear how the selection of the attribute is done in practise (e.g., = if the "type" attribute's value 'XML element' is used), and what it = means to indicate an XML attribute in the . The meaning of the sentence 3.3.1: "The element MUST identify = one element only, unless the conditional expression results in more than = one element with the same name being identified." is a bit unclear.=20 3.3.1: "... all other mandatory XML elements and/or attributes must be = incorporated in the resulting XML document...": are e.g. optional XML = attributes of mandatory XML elements incorporated or not? 3.3.1 (example): "The following example selects the element = defined in PIDF XML document [11]. This results in the selection of all = the ancestors of . I.e. and ." -> I'd rephrase = the texts something like this: "The following example selects the = element defined in PIDF [11]. This also results in the = selection of all mandatory elements related to the , i.e. = and ." 3.3.1.1: "The syntax is defined in a way ..." -> I'd add a sentence for = clarifying the context of the syntax, e.g. something like "The = 'xml-element' value is used when the element identifies XML = elements. The syntax is defined in a way..." 3.3.1.1.: It'd be good to have at least one example of the selection of = an XML attribute. 3.3.2: it'd be good to add e.g. a note about vs. mandatory XML = element. 3.3.2: the last sentence is basically unnecessary since earlier in the = draft it is said that the element must contain at least one = . 5.1.(examples) The text talks about first and 2nd filter definition even = if there is only one. Additionally,=20 the filter definition should contain = "xmlns:simple-filter=3D"urn:ietf:params:xml:ns:simple-filter" + similar = definitions for pidf and rpid prefixes. Also the element = could have the "simple-filter" prefix as also other XML elements seems = to have it. This comment applies to all the filter definition examples. 5.3: The xml document could be corrected as follows: needed namespace = prefixes to be defined; "//" to be added to the first ; is = there something wrong in "//wi:watcher/@wi:status@status"; the trigger = part contains two elements, but isn't it so the trigger never = matches if the AND operation is applied to the ...." -> = because there can be only one element per wouldn't it be = more appropriate to list e.g. the and/or element = instead? Other minor issues: - names of RPID elements should be updated in the filtering XML document = examples - usage of ' vs. " could be aligned through the whole draft - 5.2.: "... when a certain PIDF [11] tuple changes its status = from 'closed' to 'open'" -> maybe "tuple changes its" part could be = rephrased=20 - 5.2: the xmlns definition ends with double "" -> should be only one BR, Eva > -----Original Message----- > From: simple-bounces@ietf.org=20 > [mailto:simple-bounces@ietf.org]On Behalf > Of ext Robert Sparks > Sent: 30 June, 2004 18:07 > To: simple@ietf.org > Cc: Khartabil Hisham (Nokia-TP-MSW/Helsinki) > Subject: [Simple] WGLC: Event Filtering >=20 >=20 > This is a SIMPLE working group last call for the following drafts: >=20 > http://www.ietf.org/internet-drafts/draft-ietf-simple-filter-f > ormat-01.txt > http://www.ietf.org/internet-drafts/draft-ietf-simple-event-fi lter-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 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jul 5 09:14: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 JAA25219 for ; Mon, 5 Jul 2004 09:14: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 1BhTIe-0001VU-9u for simple-archive@ietf.org; Mon, 05 Jul 2004 09:14:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BhTHr-0001El-00 for simple-archive@ietf.org; Mon, 05 Jul 2004 09:13:37 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BhTH6-0000tg-00; Mon, 05 Jul 2004 09:12:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BhT1d-0002uS-VK; Mon, 05 Jul 2004 08:56:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BhSsb-0001qc-Gk for simple@megatron.ietf.org; Mon, 05 Jul 2004 08:47: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 IAA24258 for ; Mon, 5 Jul 2004 08:47: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 1BhSsV-0001lM-SF for simple@ietf.org; Mon, 05 Jul 2004 08:47:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BhSrf-0001V2-00 for simple@ietf.org; Mon, 05 Jul 2004 08:46:33 -0400 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1BhSrG-0001Di-00 for simple@ietf.org; Mon, 05 Jul 2004 08:46:07 -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 i65Ck3608069; Mon, 5 Jul 2004 15:46:03 +0300 (EET DST) X-Scanned: Mon, 5 Jul 2004 15:45:42 +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 i65CjgiE013900; Mon, 5 Jul 2004 15:45:42 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00mo58Io; Mon, 05 Jul 2004 15:45:41 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 i65CjYH19659; Mon, 5 Jul 2004 15:45:35 +0300 (EET DST) Received: from nokia.com ([172.21.42.108]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 5 Jul 2004 15:45:35 +0300 Message-ID: <40E94D6B.9090206@nokia.com> Date: Mon, 05 Jul 2004 15:45:31 +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: Robert Sparks Subject: Re: [Simple] WGLC: Event Filtering References: <1088608002.2201.50.camel@localhost.localdomain> In-Reply-To: <1088608002.2201.50.camel@localhost.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Jul 2004 12:45:35.0106 (UTC) FILETIME=[F73C6E20:01C4628D] Content-Transfer-Encoding: 7bit Cc: Costa Requena Jose , Hisham Khartabil , simple@ietf.org, =?ISO-8859-1?Q?L=F6nnfors_Mikko_Aleksi?= , "Leppanen Eva-Maria \(Nokia-NET/Tampere\)" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org 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 am sorry for the long e-mail... Here are some comments to the filter-format-01.txt draft. - Section 3, first paragraph reads: The filter criteria is an XML document [8] that MUST be well-formed and MUST be valid. The filter criteria XML documents MUST have the XML declaration and it SHOULD contain an encoding declaration in the XML declaration, for example; "". First problem, why the document 'MUST be valid'? In other XML documents created by SIMPLE the statement reads 'SHOULD be valid'. So why the strength is higher in Filter Criteria documents? Second problem. I don't understand the value of the above sentence: 'XML document MUST have the XML declaration' (of course, they are XML documents) and 'SHOULD contain an encoding declaration'... but you don't say what the encoding should be, so there is not point in indicating the encoding declaration if you don't restrict it to some values. My proposal is to align this statement with the rest of the XML documents that SIMPLE is producing, and replace the above sentence with: A filter criteria is an XML [3] document that MUST be well-formed and SHOULD be valid. Filter criteria documents MUST be based on XML 1.0 and MUST be encoded using UTF-8. - Section 3 states: The namespace identifier for elements defined by this specification is a URN [5], using the namespace identifier 'ietf' defined by [6] and extended by [4]. This urn is: urn:ietf:params:xml:ns:simple-filter+xml. The namespace should be "urn:ietf:params:xml:ns:simple-filter" rather than "urn:ietf:params:xml:ns:simple-filter+xml". - Missing link with the MIME type simple-filter+xml. I didn't fine any linkage to the simple-filter+xml MIME type. I am missing some normative text that indicates the following ideas: a) This specification defines a new MIME type "simpler-filter+xml". b) Implementations MUST support this MIME type. c) Filter criteria documents MUST be sent setting the Content-Type to "simple-filter+xml". - Namespaces prefixes. There are many elements that accept a namespace prefix to identify the correct element. The question is, where is the binding between the namespace and the prefix defined? None of the examples show this binding, but all of them refer to "pidf", "rpid", "wi" namespaces. For instance, this is an excerpt from an example: //pidf:tuple/pidf:status/pidf:basic[rpid:class="IM" or rpid:class="SMS" or rpid:class="MMS"] Where is it define that "rpid" refers to either urn:ietf:params:xml:ns:pidf:rpid-tuple or urn:ietf:params:xml:ns:pidf:status:rpid-status? And to which one? I see two possible solutions. One is that you use the regular prefix-namespace binding used in XML. The only problem is that this binding refers to elements that you use in your XML document. However, you want to prefix ***values*** that refer, in turn, to an XML element. It is not quite the same thing. For instance, if you want to use rpid and pidf, you could use the following element. The other solution is that you explicitly define some XML element as part of your schema. This will be used to define the binding you use later. Something like: - Section 3.3. The statement says: The element MAY contain one or more elements and one or more elements. However, the element MUST contain at least one element. I would like to understand why at least one element must be present. In other words, why can I just have element that simply states what I don't want to receive, i.e., a collection of elements and zero elements. In case something changes in this section, then section 3.3.2 should change as well: The element MUST NOT be used if there are no element(s) in the same content filter. - Section 3.3.1.1. The first paragraph is ok, but the remaining of the section has nothing to do with the 'type' attribute. I believe the rest should be moved to Section 4, as it discusses the syntax. - Section 3.4 states: The element MAY contain the element, the element or the , but MUST contain at least one of the three elements. Any combination of the 3 elements is possible. Multiple appearances of those element within a element denotes the "AND" operation. This means that updates to a resource that satisfy ALL of the , and elements' criteria within the element constitute the content to be delivered. Question: is there a case where the and can appear simultaneously? It would mean: send me element if it is and , which I believe is not possible ever. - Section 3.4.1 states: The element is used to identify the XML element or attribute, from the package specific XML document, that must change, compared to the previous XML document, in order to activate the trigger and cause the content to be delivered. If I understand correctly, what changes is not the element itself, but the value. Can you confirm it? If the element changes, then it could be, e.g., because a new optional attribute is added or removed. But I believe that you want to say that what it has to change is the value, right? Can you clarify in the text what is the intention? - Section 3.4.1.3 states: A trigger is active when the XML element or attribute identified with the element has changed by the value indicated by this attribute from a different value. So does this element apply to numeric values only? If so, then I guess this is either an addition or subtraction with respect the current value (not multiply or division). Therefore, I would propose: The 'changed-by' attribute applies only to numerical values and indicates a delta with respect the current value that an attribute or element (identified in the element) needs to change before it is selected. Example: if the 'changed-by' attribute is set to 2, and the current value of the element/attribute is 6, the element/attribute is selected when it reaches (or exceeds) the value 8 or when it decreases to 4 or lower value. - Section 3.4.2 states: The XML element or attribute is indicated using the syntax defined in Section 4 for the "reference". I think you should make the above text normative: The XML element or attribute MUST be expressed using the syntax defined in Section 4 for the "reference" ABNF. - Section 6, extensibility of the XML schema. I noticed weird things related to the extensibility of the XML schema. While you provide extensibility for new attributes of most elements, there is no attribute extensibility to the element. Additionally, I didn't find any possibility to add new elements. I think this should be possible, when it is rational. - Section 6, the "TypeType" definition. Currently, the "TypeType" is defined as: I believe the "token" value should not be present. Second: in the text it is said (a few times) that a filter applies to either an element, an attribute or a namespace. But now the "type" definition only considers values "xml-element" and "namespace". So how I identify an attribute? I believe that "xml-element" is sufficient to accommodate attributes, because you will have an XPath expression that clearly distinguishes elements from attributes. So I am not advocating to add a new "attribute" value to the "type" definition, instead I think you need to rename the "xml-element" by something more generic, perhaps "xpath" to indicate that the value of the element is an XPath expression (or a namespace it is so). Then probably you need to add some discussion, in the text, to indicate when to use one or the other. - I would like to get your opinion on a new feature. I believe it might be interesting to have rules defined and stored in the server, so that I can easily activate a filter set or deactivate it. So a filter that is deactivated is not in used, although is easily available for future reference or enable it at any time. I think I would like to see some 'state' attribute in each or elements, so that I can "enable" or "disable" easily a filter, without sending the whole to the server. - Notation. Some months ago we got an agreement on the notation that we should be using for XML specifications. I believe the agreement is that, whenever we refer to an element, we include it within brackets (e.g., ); an attribute is enclosed in single quotes (e.g., 'attribute'); a value is enclosed in quotation marks (e.g., "this is a value"). For instance: the element contains an optional 'type' attribute that can get the value "open" or "closed". This facilitates the reading of the specification. So can you please revise the document and make the notation consistent according to the above rules? - Examples. All the examples should start with a proper XML header, like: After that, you don't need to prepend each element in the examples with a "simple-filter" prefix (that is not even bound anywhere). But this requires that you change a bit the XML schema to add the default behavior for elements and attributes. So the schema should start with : With this change to the schema, then the examples validate without that prefix, and they are easier to read. - Section 5.1, example. Shouldn't the value of the element be prepended with "//pidf:presence" to identify the root element of the pidf document?. For example: //pidf:presence/pidf:tuple/pidf:status/ pidf:basic[rpid:class="IM" or rpid:class="SMS" or rpid:class="MMS"] - Section 5.2, example. Missing one slash "/" before the "/pidf:presence". - Section 5.3, example. Missing double slashes "//" before the "wi:watcher" value in the element. Also in this example, is it it correct to have a slash "/" prior to the at sign "@" in : //wi:watcher/@wi:status@status At least by following the ABNF I thought it wasn't right. - Section 5.5, typo in title: s/Include/include - Section 3.1, typo in sentence: '... document containing the filter criteria is separated from the events that makes use of it or from the protocol that usually carries it.' s/makes/make - Section 8: I would remove the two paragraphs in this subsection A new content type "application/simple-filter+xml" is defined to represent an XML MIME for the filter criteria. This specification follows the guidelines of RFC3023 [7] And I would start section 8.1 with: This specification registers a new MIME type according to the procedures of RFC 2048 [xx] and guidelines in RFC 3023 [yy]. - Section 8.1: Typo in title: application/simple-filter+xml mime TYPE should read: application/simple-filter+xml MIME type - Section 8.1: Typo. Security considerations: See section 10 of RFC 3023 [7] and section Section 8 of this document. should read Security considerations: See section 10 of RFC 3023 [7] and section Section 7 of this document. - Section 8.2: The "URN document" is now RFC 3688. Best regards, Miguel Robert Sparks wrote: > 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 > -- 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 Jul 5 10:10: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 KAA28559 for ; Mon, 5 Jul 2004 10:10: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 1BhUAo-00029O-6J for simple-archive@ietf.org; Mon, 05 Jul 2004 10:10:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BhU9x-0001tN-00 for simple-archive@ietf.org; Mon, 05 Jul 2004 10:09:30 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BhU9T-0001be-00; Mon, 05 Jul 2004 10:08:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BhTqf-0007JE-8L; Mon, 05 Jul 2004 09:49:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BhTi2-0006JC-6C for simple@megatron.ietf.org; Mon, 05 Jul 2004 09:40: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 JAA26745 for ; Mon, 5 Jul 2004 09:40:31 -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 1BhThw-0001O2-Fq for simple@ietf.org; Mon, 05 Jul 2004 09:40:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BhTh8-00016n-00 for simple@ietf.org; Mon, 05 Jul 2004 09:39:42 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BhTgT-0000oN-00 for simple@ietf.org; Mon, 05 Jul 2004 09:39:01 -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 i65DcwN13949; Mon, 5 Jul 2004 16:38:58 +0300 (EET DST) X-Scanned: Mon, 5 Jul 2004 16:38: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 i65DcsVJ004196; Mon, 5 Jul 2004 16:38:54 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00q911qN; Mon, 05 Jul 2004 16:38:52 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 i65DcpH05692; Mon, 5 Jul 2004 16:38:51 +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); Mon, 5 Jul 2004 16:38:46 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [Simple] XCAP Issue 6 Interim Summary: selecting elements by textvalue Date: Mon, 5 Jul 2004 16:38:47 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7023EEAAF@esebe019.ntc.nokia.com> Thread-Topic: [Simple] XCAP Issue 6 Interim Summary: selecting elements by textvalue Thread-Index: AcROvDfTDJ5k7cJZT3WQjx8MEh/uWgT1/32w To: , X-OriginalArrivalTime: 05 Jul 2004 13:38:46.0818 (UTC) FILETIME=[65A50820:01C46295] 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 If I have an authorisation rule as follows: example.com bob@example.com alice@example.com allow friend Now I want to remove the first that excepts Bob. How do I do = that without selecting the element by text value? I'm going to have to = re-write the whole element and its sub elements. Is that = acceptable? 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 09:42 > To: Simple WG > Subject: [Simple] XCAP Issue 6 Interim Summary: selecting elements by > textvalue >=20 >=20 > The issue here was whether or not to include a feature in xcap that=20 > allowed you to select an element by the value of its content. For=20 > example, if the doc is this: >=20 > > val > ue > >=20 > then you could do foo/bar[.=3D"val"] and this would select the=20 > first bar=20 > element. >=20 > The problem, raised by Joel on the list and discussed at the=20 > meeting, is=20 > that this makes sense only if the text content is actually a useful=20 > index. In some application usages, the text content may be text for=20 > human consumption, like a paragraph of text (think about the=20 > element=20 > in xml2rfc). Indexing this is expensive and a waste of time. >=20 > I proposed three possible solutions: >=20 > 1. add more complexity to the spec - allow applicaiton usages to=20 > declare, in their definitions, when text content represents=20 > an index. An=20 > implementation would therefore be able to be dynamically=20 > programmed to=20 > know which element content to index. >=20 > 2. Allow selection of elements based on content; assume that=20 > URIs would=20 > not use content as a selector unless it really was a useful index >=20 > 3. do not allow selection based on content >=20 >=20 >=20 > The question was raised as to whether there was a specific=20 > application=20 > usage driving this feature. There isn't. There was general=20 > agreement to=20 > only add stuff if a concrete need in an existing application=20 > usage was=20 > driving it. Since it was not the case here, there was=20 > consensus to drop=20 > this feature. >=20 > Any objections? >=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 Jul 5 11:54: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 LAA04257 for ; Mon, 5 Jul 2004 11:54: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 1BhVnW-00028J-AU for simple-archive@ietf.org; Mon, 05 Jul 2004 11:54:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BhVmY-0001ow-00 for simple-archive@ietf.org; Mon, 05 Jul 2004 11:53:27 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BhVm7-0001XM-00; Mon, 05 Jul 2004 11:52:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BhVZa-0006pO-6v; Mon, 05 Jul 2004 11:40:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BhVNe-0005tY-FC for simple@megatron.ietf.org; Mon, 05 Jul 2004 11:27: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 LAA03293 for ; Mon, 5 Jul 2004 11:27: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 1BhVNY-0001s9-KE for simple@ietf.org; Mon, 05 Jul 2004 11:27:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BhVMY-0001ZG-00 for simple@ietf.org; Mon, 05 Jul 2004 11:26:35 -0400 Received: from albatross.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1BhVM6-0001Gm-00 for simple@ietf.org; Mon, 05 Jul 2004 11:26:06 -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 i65FQ5WR007775 for ; Mon, 5 Jul 2004 17:26:05 +0200 (MEST) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 5 Jul 2004 17:26:05 +0200 Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id <321KWHHH>; Mon, 5 Jul 2004 17:26:05 +0200 Message-ID: From: "Anders Lindgren C (HF/EAB)" To: "'hisham.khartabil@nokia.com'" , simple@ietf.org Date: Mon, 5 Jul 2004 17:26: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: 05 Jul 2004 15:26:05.0710 (UTC) FILETIME=[6385FAE0:01C462A4] Cc: Miguel.An.Garcia@nokia.com Subject: [Simple] RE: simple-filter Max Size or Max number of element as filter cri terias? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org 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 Hi In the tread #RE: [Simple] Re: XCAP Directory: Large response ?" you asked Miguel to have a look at the filter draft to solve the XCAP problem. I qoute: "I wonder if you can use the following event filtering draft with HTTP GET? http://www.ietf.org/internet-drafts/draft-ietf-simple-filter-format-01.txt (currently in WGLC) At least the part could be useful." My view is that it is the same thing Miguel and I are addressing, but on different protocols ( SIP, XCAP). A client can get a list of users that is to more that it can handle. How can it be that the filter draft can solve the XCAP problem but not the Subscribe problem? /Anders -----Original Message----- From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] Sent: den 2 juli 2004 16:01 To: Anders Lindgren C (HF/EAB); simple@ietf.org Subject: RE: simple-filter Max Size or Max number of element as filter criterias? > -----Original Message----- > From: ext Anders Lindgren C (HF/EAB) > [mailto:anders.c.lindgren@ericsson.com] > Sent: 02.July.2004 16:42 > To: Khartabil Hisham (Nokia-TP-MSW/Helsinki); simple@ietf.org > Subject: RE: simple-filter Max Size or Max number of element as filter > criterias? > > > Ok > Can I select the number of elements of a certain type I want > to receive? Ie give my at the most 100 buddies in a resource > list when subscribing to a list? No you cannot, but what you can do is list in the filter the buddies you are interested in receiving information about. I think this is more useful that using the filter to tell the server to send you the first x buddies. /Hisham > Or is it that something > complete new is needed or is it covered by some other spec? > As I see it this is a general problem for all types of > Subscribe for event packages if you can not control the size > of what is send in the Notify. > Regards Anders > > -----Original Message----- > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > Sent: den 2 juli 2004 14:40 > To: Anders Lindgren C (HF/EAB); simple@ietf.org > Subject: RE: simple-filter Max Size or Max number of element as filter > criterias? > > > You can reduce the size of the document delivered in the > NOTIFY by using the filters (but selecting the elements that > you really want to be delivered to you), but you cannot > filter based on size. You cannot say "send me a NOTIFY with a > body no larger than 1000 bytes". > > If you want something like that, then this is outside the > scope of the filtering drafts in question. > > Regards, > Hisham > > > -----Original Message----- > > From: ext Anders Lindgren C (HF/EAB) > > [mailto:anders.c.lindgren@ericsson.com] > > Sent: 02.July.2004 15:23 > > To: Khartabil Hisham (Nokia-TP-MSW/Helsinki); simple@ietf.org > > Subject: RE: simple-filter Max Size or Max number of > element as filter > > criterias? > > > > > > Hi > > The question is what "unwanted" information" mean? Can it be > > that a XML document that is to large to handle can be > > regarded as "unwanted" information and therefore can be > > regarded as being inside the scope of the simple-filter draft. > > Regards > > Anders > > > > -----Original Message----- > > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > > Sent: den 2 juli 2004 10:07 > > To: Anders Lindgren C (HF/EAB); simple@ietf.org > > Subject: RE: simple-filter Max Size or Max number of > element as filter > > criterias? > > > > > > I believe that you are asking for is outside the scope of the > > simple-filter drafts. It can be done with filters, but not > those ones. > > > > The current filter drafts talk about filtering unwanted or > > uninteresting information sent in a NOTIFY. They also talk > > about triggering of notifications when certain changes to the > > state of an event occur. > > > > Regards, > > Hisham > > > > > -----Original Message----- > > > From: ext Anders Lindgren C (HF/EAB) > > > [mailto:anders.c.lindgren@ericsson.com] > > > Sent: 02.July.2004 10:53 > > > To: simple@ietf.org; Khartabil Hisham (Nokia-TP-MSW/Helsinki) > > > Subject: simple-filter Max Size or Max number of element as filter > > > criterias? > > > > > > > > > Hi, > > > The XML documents sent from the network to the client can be > > > very large or it can contains a very long sequence of > > > elements ( e.g a resource list with 1000 buddies) > > > It will also exist different types of clients. Some clients > > > can specify a very large resource list and it will exist > > > clients that can not handle that large list. > > > > > > I have not found how a client can inform the network about > > > how large documents is can handle or how many elements of a > > > certain type it can handle. > > > My question is now if this information can be regarded as > > > filter criterias and includes in this filter specification? > > > > > > Best regards > > > > > > Anders Lindgren Ericsson AB Sweden > > > > > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jul 5 13:16: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 NAA07480 for ; Mon, 5 Jul 2004 13:16: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 1BhX4t-0003dq-Ur for simple-archive@ietf.org; Mon, 05 Jul 2004 13:16:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BhX3v-0003L1-00 for simple-archive@ietf.org; Mon, 05 Jul 2004 13:15:29 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BhX2v-0002m4-00; Mon, 05 Jul 2004 13:14:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BhWle-0006yy-Ow; Mon, 05 Jul 2004 12:56:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BhWbz-00069c-Uk for simple@megatron.ietf.org; Mon, 05 Jul 2004 12:46: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 MAA06338 for ; Mon, 5 Jul 2004 12:46: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 1BhWbu-0002M3-0J for simple@ietf.org; Mon, 05 Jul 2004 12:46:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BhWaw-00024F-00 for simple@ietf.org; Mon, 05 Jul 2004 12:45:32 -0400 Received: from zrtps06s.nortelnetworks.com ([47.140.48.50]) by ietf-mx with esmtp (Exim 4.12) id 1BhWaP-0001mQ-00 for simple@ietf.org; Mon, 05 Jul 2004 12:44:57 -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 i65GiGr22698; Mon, 5 Jul 2004 12:44:16 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 5 Jul 2004 12:44:16 -0400 Message-ID: From: "Mary Barnes" To: "'Miguel Garcia'" Subject: RE: [Simple] Double specification: text and schema Date: Mon, 5 Jul 2004 12:44:10 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Cc: "Joel M. Halpern" , Jonathan Rosenberg , SIMPLE mailing list X-BeenThere: simple@ietf.org X-Mailman-Version: 2.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="===============0730827377==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org 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,HTML_20_30,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. --===============0730827377== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C462AF.4B7B5F08" 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_01C462AF.4B7B5F08 Content-Type: text/plain Hi Miguel, The problem is that if there are inconsistencies in the text (whether it's normative or not) and the XML, you've got a problem. I agree that a statement specifying that if there are inconsistencies, the XML schema overrides the text, thus allowing an implementation to go forward without having to await resolution of the inconsistency. But, I stand by the view that I think having the text be normative actually will improve the quality of documentation overall as it forces the author(s) to double check and ensure that text matches the XML, particularly when the text is in the same document as the XML. I would agree that there's some room for flexibility when the text is in another document. But, that still requires a precise statement as to whether the text/XML in the other document would override the referenced document text/XML. However, you're still not really solving the basic problem that it's important to write accurate documentation to ensure that things are clearly understood. My primary concern is that the end result will be poorer documentation as the message is that all that matters is the XML. Mary -----Original Message----- From: Miguel Garcia [mailto:Miguel.An.Garcia@nokia.com] Sent: Monday, July 05, 2004 1:47 AM To: Barnes, Mary [NGC:B601:EXCH] Cc: Joel M. Halpern; Jonathan Rosenberg; SIMPLE mailing list Subject: Re: [Simple] Double specification: text and schema Hi Mary: I don't have any problem with having accurate comments on the text. My problem is with having normative statements that, at some point in time, may differ with the XML schema (which is also normative). I am just seeking for a future proof specification that allows interoperability. I have seen many other SDOs that systematically repeat normative statements across the same or different specifications, and you know what? They are always divergencies. As I want to avoid this divergence, my proposal is to avoid normative statements when the normative part is described in the XML schema. I still think that Jonathan's proposal was excellent: comment the XML schema in the text, but avoid normative statements. - Miguel Mary Barnes wrote: > I agree with Joel; I think we're getting back to the fundamental debate > on whether one should comment code or whether good code is self > documenting (or whether detailed design documents should have > pseudo-code or real code, etc.) It is important to have good and > accurate as possible textual descriptions along with the XML. And, I > don't see a problem with it being normative, either (in fact that would > be my preference). I don't consider myself an XML guru, but I can manage > my way through with the appropriate normative text. That's how it's > done for all the other specs; why should the XML based specs be any > different? > > Certainly, there are issues with some of the current documents in the > text that could be further clarified to ensure consistency with the XML > schema, but I think that's along the lines of the last point you make > below about putting a "bit of effort" in writing the documents. > > Regards, > Mary. > > -----Original Message----- > From: Miguel Garcia [mailto:Miguel.An.Garcia@nokia.com] > Sent: Friday, July 02, 2004 8:16 AM > To: Joel M. Halpern > Cc: Jonathan Rosenberg; SIMPLE mailing list > Subject: Re: [Simple] Double specification: text and schema > > > Well, here is the disagreement. I just want to tell authors: "don't use > normative text when there is normative definition expressed in the schema". > > Believe me, and record my words for a future time: if we start doing > double specification of normative requirements in RFCs, we will face > interoperability problems. > > If you are not able to put a bit of effort when writing your documents, > we all will pay in the future. > > - Miguel > > Joel M. Halpern wrote: > > > Part of what I am trying to avoid is telling authors that they must be > > extra careful never to use MUST words about things described in the > > schema. In a typical text description there will be explanatory text, > > there will be explanation of requirements that are also in the schema, > > and there will be explanation of requirements that are not in the > > schema. (Occasionally one gets lucky and the last category is empty.) > > As an author, I really don't want to have to try to change style from > > sentence to sentence in a section depending upon whether or not the > > particular behavior I am describing also occurs in the schema. > > Also, as I reader I would like to see a complete description in the > text. > > > > Yours, > > Joel M. Halpern > > > > At 06:23 AM 7/2/2004 -0400, Jonathan Rosenberg wrote: > > > > > >> Miguel Garcia wrote: > >> > >>> Hi Joel: > >>> I don't agree with you. We can't avoid the XML schema. I believe you > >>> agree with me. > >>> Since the XML schema already needs to indicate whether an element or > >>> attribute is mandatory or not, there is no point in repeating the > >>> same information in the text. What for? > >> > >> > >> I think that it can be useful for purposes of clarification. I would > >> advise using non-normative terminology in the text. So, for example: > >> > >> "The element includes a single mandatory attribute, "bar", and > >> always has two children, and ..." > >> > >> I think it also makes sense to have an explicit statement about the > >> normative nature of the schema, and that any explanatory text is not > >> normative. I routinely put such statements in "overview of operations" > >> sections, which are not written with RFC2119-strentgh terms. > >> > >> -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 > > > > > > -- > 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 > -- Miguel A. Garcia tel:+358-50-4804586 Nokia Research Center Helsinki, Finland ------_=_NextPart_001_01C462AF.4B7B5F08 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Simple] Double specification: text and schema

Hi Miguel,

The problem is that if there are inconsistencies in = the text (whether it's normative or not) and the XML, you've got a = problem.  I agree that a statement specifying that if there are = inconsistencies, the XML schema overrides the text, thus allowing an = implementation to go forward without having to await resolution of the = inconsistency. 

But, I stand by the view that I think having the text = be normative actually will improve the quality of documentation overall = as it forces the author(s) to double check and ensure that text matches = the XML, particularly when the text is in the same document as the = XML.  I would agree that there's some room for flexibility when = the text is in another document.  But, that still requires a = precise statement as to whether the text/XML in the other document = would override the referenced document text/XML. 

However, you're still not really solving the basic = problem that it's important to write accurate documentation to ensure = that things are clearly understood. My primary concern is that the end = result will be poorer documentation as the message is that all that = matters is the XML. 

Mary


-----Original Message-----
From: Miguel Garcia [mailto:Miguel.An.Garcia@nokia= .com]
Sent: Monday, July 05, 2004 1:47 AM
To: Barnes, Mary [NGC:B601:EXCH]
Cc: Joel M. Halpern; Jonathan Rosenberg; SIMPLE = mailing list
Subject: Re: [Simple] Double specification: text and = schema


Hi Mary:

I don't have any problem with having accurate = comments on the text. My
problem is with having normative statements that, at = some point in time,
may differ with the XML schema (which is also = normative). I am just
seeking for a future proof specification that allows = interoperability.

I have seen many other SDOs that systematically = repeat normative
statements across the same or different = specifications, and you know
what? They are always divergencies. As I want to = avoid this divergence,
my proposal is to avoid normative statements when = the normative part is
described in the XML schema.

I still think that Jonathan's proposal was excellent: = comment the XML
schema in the text, but avoid normative = statements.

- Miguel

Mary Barnes wrote:
> I agree with Joel; I think we're getting back = to the fundamental debate
> on whether one should comment code or whether = good code is self
> documenting (or whether detailed design = documents should have
> pseudo-code or real code, etc.)  It is = important to have good and
> accurate as possible textual descriptions along = with the XML. And, I
> don't see a problem with it being normative, = either (in fact that would
> be my preference). I don't consider myself an = XML guru, but I can manage
> my way through with the appropriate normative = text.  That's how it's
> done for all the other specs; why should the = XML based specs be any
> different?  
>
> Certainly, there are issues with some of the = current documents in the
> text that could be further clarified to ensure = consistency with the XML
> schema, but I think that's along the lines of = the last point you make
> below about putting a "bit of effort" = in writing the documents.  
>
> Regards,
> Mary.
>
> -----Original Message-----
> From: Miguel Garcia [mailto:Miguel.An.Garcia@nokia= .com]
> Sent: Friday, July 02, 2004 8:16 AM
> To: Joel M. Halpern
> Cc: Jonathan Rosenberg; SIMPLE mailing = list
> Subject: Re: [Simple] Double specification: = text and schema
>
>
> Well, here is the disagreement. I just want to = tell authors: "don't use
> normative text when there is normative = definition expressed in the schema".
>
> Believe me, and record my words for a future = time: if we start doing
> double specification of normative requirements = in RFCs, we will face
> interoperability problems.
>
> If you are not able to put a bit of effort when = writing your documents,
> we all will pay in the future.
>
> - Miguel
>
> Joel M. Halpern wrote:
>
>  > Part of what I am trying to avoid is = telling authors that they must be
>  > extra careful never to use MUST = words about things described in the
>  > schema.  In a typical text = description there will be explanatory text,
>  > there will be explanation of = requirements that are also in the schema,
>  > and there will be explanation of = requirements that are not in the
>  > schema.  (Occasionally one gets = lucky and the last category is empty.)
>  > As an author, I really don't want to = have to try to change style from
>  > sentence to sentence in a section = depending upon whether or not the
>  > particular behavior I am describing = also occurs in the schema.
>  > Also, as I reader I would like to = see a complete description in the
> text.
>  >
>  > Yours,
>  > Joel M. Halpern
>  >
>  > At 06:23 AM 7/2/2004 -0400, Jonathan = Rosenberg wrote:
>  >
>  >
>  >> Miguel Garcia wrote:
>  >>
>  >>> Hi Joel:
>  >>> I don't agree with you. We = can't avoid the XML schema. I believe you
>  >>> agree with me.
>  >>> Since the XML schema already = needs to indicate whether an element or
>  >>> attribute is mandatory or = not, there is no point in repeating the
>  >>> same information in the = text. What for?
>  >>
>  >>
>  >> I think that it can be useful = for purposes of clarification. I would
>  >> advise using non-normative = terminology in the text. So, for example:
>  >>
>  >> "The <foo> element = includes a single mandatory attribute, "bar", and
>  >> always has two children, = <sip> and <ping>..."
>  >>
>  >> I think it also makes sense to = have an explicit statement about the
>  >> normative nature of the schema, = and that any explanatory text is not
>  >> normative. I routinely put such = statements in "overview of operations"
>  >> sections, which are not written = with RFC2119-strentgh terms.
>  >>
>  >> -Jonathan R.
>  >>
>  >> --
>  >> Jonathan D. Rosenberg, = Ph.D.           &= nbsp;    600 Lanidex Plaza
>  >> Chief Technology = Officer           = ;         Parsippany, NJ = 07054-2711
>  >> dynamicsoft
>  >> = jdrosen@dynamicsoft.com        &= nbsp;            = FAX:   (973) 952-5050
>  >> http://www.jdrosen.net    &nbs= p;           &nbs= p;     PHONE: (973) 952-5000
>  >> http://www.dynamicsoft.com
>  >>
>  >> = _______________________________________________
>  >> Simple mailing list
>  >> Simple@ietf.org
>  >> https://www1.ietf.org/mailman/listinfo/simple
>  >
>  >
>
> --
> 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
>

--
Miguel A. = Garcia           = tel:+358-50-4804586
Nokia Research Center      = Helsinki, Finland

------_=_NextPart_001_01C462AF.4B7B5F08-- --===============0730827377== 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 --===============0730827377==-- From simple-bounces@ietf.org Mon Jul 5 14: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 OAA10251 for ; Mon, 5 Jul 2004 14: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 1BhYHU-0003UA-IH for simple-archive@ietf.org; Mon, 05 Jul 2004 14:33:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BhYGY-0003Cj-00 for simple-archive@ietf.org; Mon, 05 Jul 2004 14:32:35 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BhYFr-0002cm-00; Mon, 05 Jul 2004 14:31:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BhY00-0004bN-CH; Mon, 05 Jul 2004 14:15:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BhXrR-0003sX-VI for simple@megatron.ietf.org; Mon, 05 Jul 2004 14:06: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 OAA09219 for ; Mon, 5 Jul 2004 14:06: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 1BhXrL-0003BQ-Vc for simple@ietf.org; Mon, 05 Jul 2004 14:06:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BhXqR-0002uG-00 for simple@ietf.org; Mon, 05 Jul 2004 14:05:36 -0400 Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx with esmtp (Exim 4.12) id 1BhXq1-0002ca-00 for simple@ietf.org; Mon, 05 Jul 2004 14:05:09 -0400 Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id i65I4XJh015751 for ; Mon, 5 Jul 2004 13:04:34 -0500 (CDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Mon, 5 Jul 2004 19:04:33 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB00C290142@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'Ben Campbell'" Subject: RE: [Simple] Re: MSRP: Max message size indication Date: Mon, 5 Jul 2004 19:04:32 +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 Having reread the entire thread, the only winner I have seen in this = vote is Christer Holmberg for the sheer number of messages sent. If = that is the criteria that is being used for decision, then you should = have made this clear at the beginning. What I do see from the list is = that the balance of the votes was pretty even, even on the send = capability. I do not call that rough working consensus. What I am seeing here is feature creep. People are justifying their = arguments on the basis that it does not take much time to add a = particular feature, therefore lets add it. What this means is that this = continues to happen and we never get the deliverable out of the door. We saw it happen in SIP, we are seeing it happen in sdp-new, and we are = seeing it happen now in XCAP as well. MSRP is needed pretty damn soon. Can we please stop the feature creep and deliver what is already in the = document, and deal with other stuff as extensions. regards Keith Drage > -----Original Message----- > From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] > Sent: 28 June 2004 20:57 > To: Christer Holmberg (JO/LMF) > Cc: Adam Roach; simple@ietf.org; 'hisham.khartabil@nokia.com'; 'Paul > Kyzivat'; alex.audu@alcatel.com; cboulton@ubiquity.com > Subject: Re: [Simple] Re: MSRP: Max message size indication >=20 >=20 > 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. >=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=20 > 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=20 > 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=20 > 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 > >> >=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 Jul 5 14:51: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 OAA11109 for ; Mon, 5 Jul 2004 14:51: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 1BhYYt-0001KY-9V for simple-archive@ietf.org; Mon, 05 Jul 2004 14:51:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BhYXu-00010D-00 for simple-archive@ietf.org; Mon, 05 Jul 2004 14:50:32 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BhYWq-0000PQ-00; Mon, 05 Jul 2004 14:49:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BhYGQ-0005iI-Gq; Mon, 05 Jul 2004 14:32:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BhY8C-00052u-CX for simple@megatron.ietf.org; Mon, 05 Jul 2004 14:23: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 OAA09805 for ; Mon, 5 Jul 2004 14:23: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 1BhY7w-0000Tp-90 for simple@ietf.org; Mon, 05 Jul 2004 14:23:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BhY6y-0000B0-00 for simple@ietf.org; Mon, 05 Jul 2004 14:22:42 -0400 Received: from ns.execdsl.net ([208.184.15.238] helo=EXECDSL.COM) by ietf-mx with esmtp (Exim 4.12) id 1BhY6W-0007gG-00 for simple@ietf.org; Mon, 05 Jul 2004 14:22:12 -0400 Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 7162490 for simple@ietf.org; Mon, 05 Jul 2004 14:22:12 -0400 Message-Id: <5.1.0.14.0.20040705141554.022c7ee0@localhost> X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 05 Jul 2004 14:21:54 -0400 To: SIMPLE mailing list From: "Joel M. Halpern" Subject: RE: [Simple] Double specification: text and schema In-Reply-To: Mime-Version: 1.0 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.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="===============1400770491==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org 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_30_40,HTML_MESSAGE autolearn=no version=2.60 --===============1400770491== Content-Type: text/html; charset="us-ascii" [I agree with Mary, and believe this is just an example of a general case.]

To use a concrete example, I recently had reason to look at the iscomposing draft.  The XML for that is very short.  The schema therefore is actually fairly readable.  Even so, I found the absence of clear English text describing the required elements of the document disconcerting.  (All the necessary pieces are there, but it is harder to understand than it ought to be.)  If the schema were any more complex, it would be very hard.  If the ForCES Model document (which relies heavily on XML Schema) were to omit normative language for all elements covered by the XML Schema, it would read very badly, and be very hard to understand.

We have been using duplicate specifications for ages.  When we use ABNF for syntax, we do not leave out normative language about what the syntax is.  (We do not insist that the English be complete.  But we do have normative English.) We do say that the ABNF is definitive.  And we consider it a bug if they differ.
When IEEE did the original 802.1d spec, they included well commented code for all the behaviors.  They also included good, clear, English descriptions of the required behaviors.
XML is not any different from any of the other formal specification tools we use, and should not be treated differently.

Yours,
Joel

At 12:44 PM 7/5/2004 -0400, Mary Barnes wrote:

Hi Miguel,

The problem is that if there are inconsistencies in the text (whether it's normative or not) and the XML, you've got a problem.  I agree that a statement specifying that if there are inconsistencies, the XML schema overrides the text, thus allowing an implementation to go forward without having to await resolution of the inconsistency. 

But, I stand by the view that I think having the text be normative actually will improve the quality of documentation overall as it forces the author(s) to double check and ensure that text matches the XML, particularly when the text is in the same document as the XML.  I would agree that there's some room for flexibility when the text is in another document.  But, that still requires a precise statement as to whether the text/XML in the other document would override the referenced document text/XML. 

However, you're still not really solving the basic problem that it's important to write accurate documentation to ensure that things are clearly understood. My primary concern is that the end result will be poorer documentation as the message is that all that matters is the XML. 

Mary

-----Original Message-----
From: Miguel Garcia [mailto:Miguel.An.Garcia@nokia.com]
Sent: Monday, July 05, 2004 1:47 AM
To: Barnes, Mary [NGC:B601:EXCH]
Cc: Joel M. Halpern; Jonathan Rosenberg; SIMPLE mailing list
Subject: Re: [Simple] Double specification: text and schema

Hi Mary:

I don't have any problem with having accurate comments on the text. My
problem is with having normative statements that, at some point in time,
may differ with the XML schema (which is also normative). I am just
seeking for a future proof specification that allows interoperability.

I have seen many other SDOs that systematically repeat normative
statements across the same or different specifications, and you know
what? They are always divergencies. As I want to avoid this divergence,
my proposal is to avoid normative statements when the normative part is
described in the XML schema.

I still think that Jonathan's proposal was excellent: comment the XML
schema in the text, but avoid normative statements.

- Miguel

Mary Barnes wrote:
> I agree with Joel; I think we're getting back to the fundamental debate
> on whether one should comment code or whether good code is self
> documenting (or whether detailed design documents should have
> pseudo-code or real code, etc.)  It is important to have good and
> accurate as possible textual descriptions along with the XML. And, I
> don't see a problem with it being normative, either (in fact that would
> be my preference). I don't consider myself an XML guru, but I can manage
> my way through with the appropriate normative text.  That's how it's
> done for all the other specs; why should the XML based specs be any
> different?  
>
> Certainly, there are issues with some of the current documents in the
> text that could be further clarified to ensure consistency with the XML
> schema, but I think that's along the lines of the last point you make
> below about putting a "bit of effort" in writing the documents.  
>
> Regards,
> Mary.
>
> -----Original Message-----
> From: Miguel Garcia [mailto:Miguel.An.Garcia@nokia.com]
> Sent: Friday, July 02, 2004 8:16 AM
> To: Joel M. Halpern
> Cc: Jonathan Rosenberg; SIMPLE mailing list
> Subject: Re: [Simple] Double specification: text and schema
>
>
> Well, here is the disagreement. I just want to tell authors: "don't use
> normative text when there is normative definition expressed in the schema".
>
> Believe me, and record my words for a future time: if we start doing
> double specification of normative requirements in RFCs, we will face
> interoperability problems.
>
> If you are not able to put a bit of effort when writing your documents,
> we all will pay in the future.
>
> - Miguel
>
> Joel M. Halpern wrote:
>
>  > Part of what I am trying to avoid is telling authors that they must be
>  > extra careful never to use MUST words about things described in the
>  > schema.  In a typical text description there will be explanatory text,
>  > there will be explanation of requirements that are also in the schema,
>  > and there will be explanation of requirements that are not in the
>  > schema.  (Occasionally one gets lucky and the last category is empty.)
>  > As an author, I really don't want to have to try to change style from
>  > sentence to sentence in a section depending upon whether or not the
>  > particular behavior I am describing also occurs in the schema.
>  > Also, as I reader I would like to see a complete description in the
> text.
>  >
>  > Yours,
>  > Joel M. Halpern
>  >
>  > At 06:23 AM 7/2/2004 -0400, Jonathan Rosenberg wrote:
>  >
>  >
>  >> Miguel Garcia wrote:
>  >>
>  >>> Hi Joel:
>  >>> I don't agree with you. We can't avoid the XML schema. I believe you
>  >>> agree with me.
>  >>> Since the XML schema already needs to indicate whether an element or
>  >>> attribute is mandatory or not, there is no point in repeating the
>  >>> same information in the text. What for?
>  >>
>  >>
>  >> I think that it can be useful for purposes of clarification. I would
>  >> advise using non-normative terminology in the text. So, for example:
>  >>
>  >> "The <foo> element includes a single mandatory attribute, "bar", and
>  >> always has two children, <sip> and <ping>..."
>  >>
>  >> I think it also makes sense to have an explicit statement about the
>  >> normative nature of the schema, and that any explanatory text is not
>  >> normative. I routinely put such statements in "overview of operations"
>  >> sections, which are not written with RFC2119-strentgh terms.
>  >>
>  >> -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
>  >
>  >
>
> --
> 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
>

--
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
--===============1400770491== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============1400770491==-- From simple-bounces@ietf.org Mon Jul 5 15:06: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 PAA11945 for ; Mon, 5 Jul 2004 15:06: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 1BhYng-0005yt-Jc for simple-archive@ietf.org; Mon, 05 Jul 2004 15:06:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BhYmU-0005dG-00 for simple-archive@ietf.org; Mon, 05 Jul 2004 15:05:34 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BhYlU-000534-00; Mon, 05 Jul 2004 15:04:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BhYXG-000798-DE; Mon, 05 Jul 2004 14:49:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BhYNN-0006BR-H7 for simple@megatron.ietf.org; Mon, 05 Jul 2004 14:39:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10516 for ; Mon, 5 Jul 2004 14:39: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 1BhYNH-0005E7-F9 for simple@ietf.org; Mon, 05 Jul 2004 14:39:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BhYMJ-0004wX-00 for simple@ietf.org; Mon, 05 Jul 2004 14:38:31 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx with esmtp (Exim 4.12) id 1BhYLM-0004NN-00 for simple@ietf.org; Mon, 05 Jul 2004 14:37:32 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i65Iar57002766; Mon, 5 Jul 2004 11:36:54 -0700 (PDT) Received: from [67.164.0.147] (vpn-10-50-0-29.qualcomm.com [10.50.0.29]) by neophyte.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i65Iap4L020411; Mon, 5 Jul 2004 11:36:52 -0700 (PDT) Mime-Version: 1.0 X-Sender: hardie@mage.qualcomm.com Message-Id: In-Reply-To: <40E9066F.1020706@nokia.com> References: <342C4681F0D4A04CA50A97D74DA8FB9A0C0AC79B@esealnt875.al.sw.ericsson.se> <40E521E2.9010209@nokia.com> <40E53251.6000102@dynamicsoft.com> <40E9066F.1020706@nokia.com> Date: Mon, 5 Jul 2004 11:36:55 -0700 To: Miguel Garcia From: Ted Hardie Subject: Re: [Simple] Re: XCAP Directory: Large response ? Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: Jonathan Rosenberg , 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:42 AM +0300 7/5/04, Miguel Garcia wrote: > >The Range header in HTTP does not seem to be quite useful, since it >will truncate the XML document. Then the XCAP client cannot validate >it, it can either request the rest of the document or abort the >operation. Under normal circumstances, I would expect the range header to be used to collect the whole of the document, which the terminal would then process. If it cannot store the whole document or process it, it seems to me it must understand the schema in order to proceed (using XPATH or the hierarchy inherent in XCAP). regards, Ted Hardie _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jul 5 18: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 SAA21644 for ; Mon, 5 Jul 2004 18: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 1Bhc8j-00015v-5V for simple-archive@ietf.org; Mon, 05 Jul 2004 18:40:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bhc7j-0000ls-00 for simple-archive@ietf.org; Mon, 05 Jul 2004 18:39:44 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bhc6m-0000AQ-00; Mon, 05 Jul 2004 18:38:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BhbsL-0005w4-OT; Mon, 05 Jul 2004 18:23:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BhbmY-0004iw-RW for simple@megatron.ietf.org; Mon, 05 Jul 2004 18:17: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 SAA20505 for ; Mon, 5 Jul 2004 18:17: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 1BhbmS-0001ht-8s for simple@ietf.org; Mon, 05 Jul 2004 18:17:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bhblf-0001Q6-00 for simple@ietf.org; Mon, 05 Jul 2004 18:16:56 -0400 Received: from av3-1-sn4.m-sp.skanova.net ([81.228.10.114]) by ietf-mx with esmtp (Exim 4.12) id 1Bhbl1-0000om-00 for simple@ietf.org; Mon, 05 Jul 2004 18:16:15 -0400 Received: by av3-1-sn4.m-sp.skanova.net (Postfix, from userid 502) id 07F9037E7A; Tue, 6 Jul 2004 00:15:25 +0200 (CEST) Received: from smtp2-1-sn4.m-sp.skanova.net (smtp2-1-sn4.m-sp.skanova.net [81.228.10.183]) by av3-1-sn4.m-sp.skanova.net (Postfix) with ESMTP id ED7AE37E42; Tue, 6 Jul 2004 00:15:24 +0200 (CEST) Received: from vit (h53n2fls31o265.telia.com [217.208.189.53]) by smtp2-1-sn4.m-sp.skanova.net (Postfix) with SMTP id B15EC37E4B; Tue, 6 Jul 2004 00:15:24 +0200 (CEST) From: "Gunnar Hellstrom" To: "Gunnar Hellstrom" , , , Subject: RE: [Simple] Using MSRP for (pseudo?) real time text conversation Date: Tue, 6 Jul 2004 00:15:12 +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: Importance: Normal 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 The conclusion from the different threads on real time text versus IM was= that we need to look into the opportunities to negotiate the best suitable protocol for t= he situation. For that purpose we need to look into the callee capabilities/ caller pre= fewrences negotiation and the Offer / Answer model for the text case. 1. At registration time, a UA may register its capabilities as a callee. = Text is one such capability, according to this definition: -------------------------------------------------------------------------= ----------------- --- 6 sip.text This feature tag indicates that [RFC-ietf-sip-callee-caps-03.txt] the device supports text as a streaming media type. -------------------------------------------------------------------------= ----------------- --- 2. At INVITE time or call modification time, an sdp line with m=3Dtext ..... can be used to indicate real time text capability and a wi= sh to connect text if both ate capable of text/t140 according to rfc2793. ( or rfc2793bis) If the other party accept, text shall be included in the OK. Can the MSRP experts add how MSRP is negotiated, so we can figure out whe= re there is a need for extensions on the current mechanisms. 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: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org]On Behalf >Of Gunnar Hellstrom >Sent: Sunday, July 04, 2004 9:37 AM >To: simple@ietf.org; stf267@etsi.org; toip@snowshore.com >Subject: RE: [Simple] Using MSRP for (pseudo?) real time text >conversation > > >I think last week=B4s intensive discussion was very useful. We saw a cul= ture collission >between "real timers" and "messagers". > >For a real timer, the real time text component is a tiny part of a call = where we are >already used to set aside resources for the much more demanding media vo= ice and video. It >is also natural to follow the same protocol for the text part, so that c= onnection is >smooth, multipart handling is equal for all media, NAT traversal is on e= qual termas etc. >rfc2793 is already there, and the sip sdp is defined. We transmit at a d= efault maximum >every 300 ms and behave well. >There is no need to question this. It should have its way rapidly into e= mergency >services, >relay services, and everybody=B4s telephone in order to keep up with the= rapidly evolving >VoIP and IP Multimedia areas. AVT is hopefully soon ready with the new c= omponents here, >and I foresee most work in sipping, xcon and external fora, taking it in= to profiles for >services in their domains. > >For the message side, sending three messages per seond seems threatening= , and >the question >is still if there is a case for introducing a real time mode. Or maybe a= "pseudo >real time >mode". Or if that should be avoided and a mode switch should be built in= to the >applications for easy shift to the real time protocols. > >I want to take this discussion a couple of steps forward before deciding= . > >1. Are there environments where only IM protocols can be used? >-------------------------------------------------------------- >I think I saw in the discussion an opinion that there will be terminals = where IM will be >implemented, but not real time conversational voice. Some real time text= users do not >bother about parallell voice. Today it is only 15% of the real time text= users, who use >voice in parallell in the same call. I expect this figure to grow now, w= hen we have >introduced more convenient user interfaces for simultaneous voice and te= xt. Evenso. >text-only is also of interest. So, if there is something that blocks the= real time >protocols but allow MSRP, I think it is worth while studying at least a = pseudo real time >mode of MSRP. >If the protocols can be implemented in parallell everywhere, I think we = should stick to >RTP for real time text. > >2. Can a pseudo-real-time mode for text be sufficient for IM users? >------------------------------------------------------------------- >When I made my brief "research" last week, and found that the real time = users were happy >with 300 ms buffering, but found 500 ms buffering too long, I noticed th= at it was the >jerkiness of the presentation that they were annoyed by, rather than the= delay >itself. The >traditional figures (from F.700, F.703) say that a delay of 2 seconds fr= om >character entry >to display can be accepted, but 1 second is regarded good. It may be so = that a >smoothening >of the presentation can make a method acceptable that includes one secon= d buffering. This >is local policy, but general recommendations can be made. When in IM pse= udo real time >mode, the presentation should be made so that characters received in one= block are >presented evenly spread during the inter-block period. The default inter= -block period >should be one second. >This assumption needs validation. > >3. Plain MSRP can be used for pseudo real time mode with a specific MIME= media type. >------------------------------------------------------------------------= ------------ >If the validation of issue 2. is positive, the concerns about using MSRP= can be >eliminated. We are then down to the same bandwidth use as RTP at 300 ms = buffering. >In the discussions it was clear that the only thing needed with MSRP to = establish a real >time mode was to have a specific media type that is intended for this pu= rpose >that is used >with the following characteristics: >a. Collect entered characters during one second and transmit. >b. Receive and display by concatenation in a consecutive area. >c. Present characters in a smoothened fashion in time. >d. Allow a few remote edits, at least "erase last character" and "new li= ne" in the same >way as in ITU-T T.140. >e. Unicode and ITU-T T.140 is a good candidate for the coding, because i= t is used by >nearly all other real time text implementations, and it would ease gatew= aying. > >4. Interoperability issues >-------------------------- >There are severe interoperability issues with this approach, because it = introduces a >second protocol for nearly the same thing in overlapping network environ= ments. So it is >depending of the answer on question 1 if this should be considered. If i= ntroduced, good >negotiation functions are needed, and discussions must be completed abou= t its >consequences >for emergency services, relay services, and the opportunity to ever harm= onise real time >conversational services in IP. > >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 Jul 5 21: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 VAA27917 for ; Mon, 5 Jul 2004 21: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 1Bheog-0006Rx-GF for simple-archive@ietf.org; Mon, 05 Jul 2004 21:32:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bhene-00066p-00 for simple-archive@ietf.org; Mon, 05 Jul 2004 21:31:11 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bhen9-0005ln-00; Mon, 05 Jul 2004 21:30:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BheaG-0000Yk-KB; Mon, 05 Jul 2004 21:17:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BheQD-0008Kb-Lg for simple@megatron.ietf.org; Mon, 05 Jul 2004 21:06: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 VAA26939 for ; Mon, 5 Jul 2004 21:06: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 1BheQ7-0006W7-3y for simple@ietf.org; Mon, 05 Jul 2004 21:06:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BheP8-0006Du-00 for simple@ietf.org; Mon, 05 Jul 2004 21:05:51 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BheOE-0005eI-00 for simple@ietf.org; Mon, 05 Jul 2004 21:04:54 -0400 Received: from dynamicsoft.com ([63.113.46.28]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i6614gbo006121; Mon, 5 Jul 2004 21:04:43 -0400 (EDT) Message-ID: <40E9FA98.1060306@dynamicsoft.com> Date: Mon, 05 Jul 2004 21:04: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: hisham.khartabil@nokia.com Subject: Re: [Simple] XCAP Issue 6 Interim Summary: selecting elements by textvalue References: <2038BCC78B1AD641891A0D1AE133DBB7023EEAAF@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB7023EEAAF@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 There are a number of choices. Assuming the current schema: 1. replace the whole of identity 2. if the client has the document cached, it can use positional addressing to delete the specific element The current schema (as in http://www.tschofenig.com/snapshot/draft-ietf-geopriv-common-policy-01_20June2004.txt) allows for multiple elements within identity. If we want the ability to add and remove those individually, without replacing the whoel thing, and we want the ability to do this without caching the document, the best approach is to update the schema so that instead of this: sip:user@domain it would be this: > > > example.com > bob@example.com > alice@example.com > > > > allow > > > > > > > > friend > > > > > > Now I want to remove the first that excepts Bob. How do I do that without selecting the element by text value? I'm going to have to re-write the whole element and its sub elements. Is that acceptable? > > Thanks, > Hisham > > >>-----Original Message----- >>From: simple-bounces@ietf.org >>[mailto:simple-bounces@ietf.org]On Behalf >>Of ext Jonathan Rosenberg >>Sent: 10.June.2004 09:42 >>To: Simple WG >>Subject: [Simple] XCAP Issue 6 Interim Summary: selecting elements by >>textvalue >> >> >>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 >> > > -- 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 Jul 5 21:50: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 VAA28613 for ; Mon, 5 Jul 2004 21:50: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 1Bhf6p-0004a4-8a for simple-archive@ietf.org; Mon, 05 Jul 2004 21:50:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bhf5y-0004HL-00 for simple-archive@ietf.org; Mon, 05 Jul 2004 21:50:07 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bhf5X-0003wf-00; Mon, 05 Jul 2004 21: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 1Bhf08-0002PJ-4j; Mon, 05 Jul 2004 21:44:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bhemk-0001Ek-7n for simple@megatron.ietf.org; Mon, 05 Jul 2004 21:30: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 VAA27822 for ; Mon, 5 Jul 2004 21:30: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 1Bhemd-0005lZ-Kj for simple@ietf.org; Mon, 05 Jul 2004 21:30:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bhele-0005SF-00 for simple@ietf.org; Mon, 05 Jul 2004 21:29:07 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1Bheky-00057w-00 for simple@ietf.org; Mon, 05 Jul 2004 21:28:24 -0400 Received: from dynamicsoft.com ([63.113.46.28]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i661SBbo006131; Mon, 5 Jul 2004 21:28:11 -0400 (EDT) Message-ID: <40EA0018.3080408@dynamicsoft.com> Date: Mon, 05 Jul 2004 21:27:52 -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] RE: XCAP Directory: Large response ? References: <40E5C2E1.50502@dynamicsoft.com> <40E903D2.2050703@nokia.com> In-Reply-To: <40E903D2.2050703@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: "George Foti \(QA/EMC\)" , 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. Miguel Garcia wrote: >> XCAP doesnt support that level of complexity in the server. If it did, >> and you wanted protection against memory overload (say, 1k max), you'd >> do something like this: >> >> GET http://server/blah-blah/list/buddy[position() > N and position() < M] >> Range: bytes=0-1000 >> >> If the response is truncated, then you need to adjust your pagination >> size on the client. >> >> -Jonathan R. >> > > I think this is going in the right direction now. So let me ask a couple > of questions to verify that the position() is valid for the purpose we > want. > > 1) Is position already part of XCAP? By reading the XCAP base document I > guess the answer is yes. No, it is not. I would not suggest putting this in the base spec, which is already overdue and suffering feature creep. I have suggested, in another thread, that we perhaps can have an "xcap advanced operations" spec that extended xcap with new features, including multiple insertions. This would possibly be a candidate feature for such an extension, if the group decided to pursue that. > > 2) I guess if we have a non-flat list, the position element will operate > in all the leaves of the XML document. For instance, if we have a > resource list document, with several elements, each one > containing a few elements, the position() predicate executed in > the element will consider the element sequentially ordered. No. It would apply only at the specific place in the hierarchy where it is placed. > > Let me try to explain better with an example. Consider the following > resource list XML document. > > > > Bill Doe > > > Johanna Doe > > subscribeable="true"> > > Joe Smith > > > Nancy Gross > > > Peter Black > > http://www.example.org/xcap/resource-lists/users/a/foo > > > > > There are 5 elements, named Bill, Johanna, Joe, Nancy and Peter. > Imagine I want entries 2 to 4 (in spite they span across different > lists). Will the HTTP URI be something like: > > GET http://server/blah-blah/resource-lists/users/jack/entry[position()>1 > and position()<5] No, this will not work. I would suggest that, if you are worried about this, the client would page in each level of the hierarchy at a time. > > 3) I believe the HTTP byte ranges is a complement of this feature, a > kind of emergency life jacket that under normal circumstances will not > be use. I doubt an XCAP client can do much with an XML document that is > truncated by the byte ranges: it can just discard the contents or store > them (if it has enough memory) and request the rest of the document. Right. The problem Ranges solves is if a fixed memory is available in the device for the content, you can make sure that there is room to store the results. If the results are a truncated document, you would need to retry with a much smaller page size. -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 Jul 6 02:52: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 CAA25090 for ; Tue, 6 Jul 2004 02:52: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 1BhjoG-00049u-34 for simple-archive@ietf.org; Tue, 06 Jul 2004 02:52:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BhjnI-0003rc-00 for simple-archive@ietf.org; Tue, 06 Jul 2004 02:51:09 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bhjmp-0003TW-00; Tue, 06 Jul 2004 02:50:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BhjV8-00026j-TX; Tue, 06 Jul 2004 02:32:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BhjKG-00006U-4T for simple@megatron.ietf.org; Tue, 06 Jul 2004 02:21: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 CAA23667 for ; Tue, 6 Jul 2004 02: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 1BhjK9-0002NM-DQ for simple@ietf.org; Tue, 06 Jul 2004 02:21:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BhjJA-00024O-00 for simple@ietf.org; Tue, 06 Jul 2004 02:20:01 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BhjI6-0001Z1-00 for simple@ietf.org; Tue, 06 Jul 2004 02:18: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 i666IpN18032; Tue, 6 Jul 2004 09:18:51 +0300 (EET DST) X-Scanned: Tue, 6 Jul 2004 09:18:46 +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 i666IkmI001889; Tue, 6 Jul 2004 09:18:46 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00SEjYRA; Tue, 06 Jul 2004 09:18:44 EEST Received: from nokia.com (esnira-pool401599.nokia.com [10.162.15.99]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i666IYH20590; Tue, 6 Jul 2004 09:18:34 +0300 (EET DST) Message-ID: <40EA4435.2040205@nokia.com> Date: Tue, 06 Jul 2004 09:18:29 +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> <40E30A07.6090407@nokia.com> <40E54102.9090803@dynamicsoft.com> In-Reply-To: <40E54102.9090803@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: > inline. > > Jari Urpalainen wrote: > >>> >>>> >>>> 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. > > > Yes, you need error checking. This request must generate a 409. My > point was, it is very easy to check for this condition *before* you go > and do the insert. You just look at the attribute selector in the > r-uri (@a="bar") and make sure it matches the attributes of the > element in the body of the request. > >> >> This will happen also with attribute updates like >> put .../foo[@a="bar"]/@a with content "foobar" > > > Right, good point. This check needs to happen too. > >> >>>> 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. > > > My point was, with the multiple-inserts technique, it is only allowing > insertions; you can't also do a delete somewhere in there, and have > the whole operation locked. That would require proper database-style > locking mechanisms. > Of course you need proper locking if you want to use different methods sequentially. However, within the same doc you can delete several nodes properly. > Let me make a proposal. Lets keep multiple inserts out of the base > spec. I will writeup the multiple inserts as an extension to xcap. > Xcap base will have a basic capability discovery mechanism, allowing > you to check what xcap extensions are supported by the server. The > client can then figure out whether or not it can do the multiple > inserts or not. The group can then debate the multiple-inserts feature > separately as an extension. All clients would need to be able to > operate against servers that didnt do multiple inserts. > > Is that OK? > > -Jonathan R. > That's fine. BR, Jari _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Jul 6 02:56: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 CAA25239 for ; Tue, 6 Jul 2004 02:56: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 1Bhjs3-0005Tw-HM for simple-archive@ietf.org; Tue, 06 Jul 2004 02:56:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bhjr4-00057A-00 for simple-archive@ietf.org; Tue, 06 Jul 2004 02:55:03 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Bhjpz-0004ZK-00; Tue, 06 Jul 2004 02:53:55 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Bhjq0-00065G-Qq; Tue, 06 Jul 2004 02:53:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BhjYH-0002Nh-OH; Tue, 06 Jul 2004 02:35:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BhjO7-0001RT-N2 for simple@megatron.ietf.org; Tue, 06 Jul 2004 02:25: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 CAA24027 for ; Tue, 6 Jul 2004 02:25: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 1BhjO0-0003ZP-LU for simple@ietf.org; Tue, 06 Jul 2004 02:25:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BhjN1-0003Gs-00 for simple@ietf.org; Tue, 06 Jul 2004 02:24:00 -0400 Received: from av1-2-sn4.m-sp.skanova.net ([81.228.10.115]) by ietf-mx with esmtp (Exim 4.12) id 1BhjM3-0002gr-00 for simple@ietf.org; Tue, 06 Jul 2004 02:22:59 -0400 Received: by av1-2-sn4.m-sp.skanova.net (Postfix, from userid 502) id 0851B37E50; Tue, 6 Jul 2004 08:22:30 +0200 (CEST) Received: from smtp2-1-sn4.m-sp.skanova.net (smtp2-1-sn4.m-sp.skanova.net [81.228.10.183]) by av1-2-sn4.m-sp.skanova.net (Postfix) with ESMTP id EC0CD37E42; Tue, 6 Jul 2004 08:22:29 +0200 (CEST) Received: from vit (h53n2fls31o265.telia.com [217.208.189.53]) by smtp2-1-sn4.m-sp.skanova.net (Postfix) with SMTP id B5EFE37E43; Tue, 6 Jul 2004 08:22:29 +0200 (CEST) From: "Gunnar Hellstrom" To: "Arnoud van Wijk" Subject: RE: Tiny ant vs big Mammoths, was RE: [Simple] Using MSRP for real time text conversation Date: Tue, 6 Jul 2004 08:22:31 +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: <200407040932.i649WXb0023401@smtp.eweka.nl> Importance: Normal Content-Transfer-Encoding: 7bit Cc: stf267@etsi.org, 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.7 required=5.0 tests=AWL,MAILTO_TO_SPAM_ADDR autolearn=no version=2.60 Content-Transfer-Encoding: 7bit I opened a new thread under the name RE: [Simple] Using MSRP for (pseudo?) real time text conversation For discussing conclusions and negotiation. Hope you all will join there. I agree with Arnoud in the impression that any user you show real time text conversation to, say that it is very good and needed in future services. So, please look for the new subject line and start thinking about what inter-relations that are needed do declare and negotiate what text service you can and want to use. And answer these messages, so that we get back to one thread. 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: owner-toip@snowshore.com [mailto:owner-toip@snowshore.com]On >Behalf Of Arnoud van Wijk >Sent: Sunday, July 04, 2004 11:32 AM >To: hisham.khartabil@nokia.com; Henry.Sinnreich@mci.com; >dean.willis@softarmor.com >Cc: bcampbell@dynamicsoft.com; gunnar.hellstrom@omnitor.se; >adam@dynamicsoft.com; stf267@etsi.org; simple@ietf.org; >toip@snowshore.com >Subject: RE: Tiny ant vs big Mammoths, was RE: [Simple] Using MSRP for >real time text conversation > > >Hisham, >Actually... >I did some market research. Based on 15 people. >3 deaf, 5 worked in deaf related business (hearing people) >And 7 don't care about deaf (2 of them are IM freaks). > >Result: > >First telling them about total conversation and Interactive text >(text/t140). >It did not mean much to them, they looked glassy eyed. Real-time charcter >per character..oh Yawn... lovely... pish posh. They could not imagine it. No >concept of it. > >Then I showed them. >They could communicate with somebody in Sweden, and with me on a different >terminal in a different room. >All were deeply impressed. > >The 3 deaf wanted to take it home right now. Being able to communicate >everywhere , everytime..finally free! >The 5 who worked in the deaf business, they loved it and want to see it >implemted and mainstream. They love it and will use it regularly to >communicate with deaf and some even say that it can be quite convenient for >hearing people as well. > >The 7 hearing, non deaf related liked it too! >They said, wow... this is much more direct then IM, you can actually call >people in situations where voice is a bit not done (think cinema, concert, >restaurant, train). They see it as direct real-time IM. >They will keep using IM anyway. But see uses for text/t140 too and will use >it if it is convenient. >The 2 IM freaks agreed, though they prefer IM, but if somebdoy contacts them >via interactive text text/t140, they will use it too. >"It depends who to contact to use the right text communication method. I >like the choice to have an alternative". > >So. Yes.. I know people will like it. Not everybody will use interactive >text. Some will thus only use if somebody else uses it, whether a deaf >person or one who likes to use text/t140. > >All of them hope that interactive text will be mainstream and will use it >with varying degrees, from sometimes, to daily. > >So, this is my message, from an interactive text user AND having >showed/demonstrated interactive text to other people. It is not my desire >only. > >Greetz > >Arnoud > >-----Original Message----- >From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] >Sent: vrijdag 2 juli 2004 9:19 >To: a.vwijk@viataal.nl; Henry.Sinnreich@mci.com; dean.willis@softarmor.com >Cc: bcampbell@dynamicsoft.com; gunnar.hellstrom@omnitor.se; >adam@dynamicsoft.com; stf267@etsi.org; simple@ietf.org; toip@snowshore.com >Subject: RE: Tiny ant vs big Mammoths, was RE: [Simple] Using MSRP for real >time text conversation > >Arnoud, > >You speak as if you have done the market research already for all of us :) >How do you know that people will appreciate it once they discover it? How do >you know that people will use it? How do you know that it adds value to the >phone instead of just implementing something that no one will use? How do >you know that if I like interactive text, then my mum and dad will and buy a >phone like mine just to use interactive text???? How do you know...? > >Did people complain to you that IM the way it is these days in annoying to >use? or are you just stating your opinion? > >And about mobile phones. If you can type an SMS faster than 2 characters a >second, you're a genius. Even if you can, I don't believe operators would >want to floor they scarce air interface with IP packets that carry 2 >characters at a time. > >Thanks, >Hisham > > >- >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 Tue Jul 6 03:51: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 DAA27078 for ; Tue, 6 Jul 2004 03:51: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 1BhkjN-0006lF-PA for simple-archive@ietf.org; Tue, 06 Jul 2004 03:51:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BhkiU-0006TD-00 for simple-archive@ietf.org; Tue, 06 Jul 2004 03:50:15 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bhkhb-0005sH-00; Tue, 06 Jul 2004 03:49:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BhkMZ-0007AV-Gh; Tue, 06 Jul 2004 03:27:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BhkDa-0006K4-Ih for simple@megatron.ietf.org; Tue, 06 Jul 2004 03:18: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 DAA26081 for ; Tue, 6 Jul 2004 03:18: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 1BhkDT-0004VV-FP for simple@ietf.org; Tue, 06 Jul 2004 03:18:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BhkCN-0004Dv-00 for simple@ietf.org; Tue, 06 Jul 2004 03:17:04 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BhkBd-0003wb-00 for simple@ietf.org; Tue, 06 Jul 2004 03:16:18 -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 i667GEN01991; Tue, 6 Jul 2004 10:16:15 +0300 (EET DST) X-Scanned: Tue, 6 Jul 2004 10:16:12 +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 i667GCgP014468; Tue, 6 Jul 2004 10:16:12 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00ZVHyty; Tue, 06 Jul 2004 10:16:10 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 i667FoH09814; Tue, 6 Jul 2004 10:15:50 +0300 (EET DST) Received: from nokia.com ([172.21.42.108]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 6 Jul 2004 10:15:41 +0300 Message-ID: <40EA519D.7050708@nokia.com> Date: Tue, 06 Jul 2004 10:15:41 +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] RE: XCAP Directory: Large response ? References: <40E5C2E1.50502@dynamicsoft.com> <40E903D2.2050703@nokia.com> <40EA0018.3080408@dynamicsoft.com> In-Reply-To: <40EA0018.3080408@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Jul 2004 07:15:41.0706 (UTC) FILETIME=[0BDD06A0:01C46329] Content-Transfer-Encoding: 7bit Cc: "George Foti \(QA/EMC\)" , 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 Summary of the thread: - I think we have consensus on adding a feature that allows an XCAP client to request a range of XML elements in a particular schema. - It seems that the HTP Range header does not serve for the purpose, since it operates on bytes and will most likely truncate XML documents. - It seems that the XPath position() operator will almost serve, but it is not part of the XCAP base specification. - And we don't want to delay the XCAP base spec by adding more features at this stage. - So this feature can be added as an advanced XCAP feature at a later stage. So far so good. At least I agree with the above. There is one bit where I don't quite agree: it seems that the position() opeator in XPath operates on the element level, meaning that if we have a non-flat list, the XCAP client will need to request ranges in each of the lists (see point 2 below). I think this is bad, and since we are going to design this extended feature, we should make it simple to use. First, if I have a device that can accommodate x entries, my XCAP client would need to request x entries for the first list, get the response (say y entries came), then do a new query requesting x-y entries in the next list, etc. Alternatively, my XCAP client can request x entries en each list, and perhaps I will get n * x entries (n is the number of lists). Second, this way of working assumes that I know in advance the number of lists that are nested. This assumption is false when I have never downloaded the XML document (such as when I start using a new device). In short: I want to have the means in XCAP to indicate: "please send me this XML document with range of x to z entries, and send them to me in a valid XML document". I don't need to know the structure of the document in advance (how many deep nested lists and their names), although I know the XML schema of the document. Is this something we can agree upon? - Miguel Jonathan Rosenberg wrote: > inline. > > Miguel Garcia wrote: > >>> XCAP doesnt support that level of complexity in the server. If it >>> did, and you wanted protection against memory overload (say, 1k max), >>> you'd do something like this: >>> >>> GET http://server/blah-blah/list/buddy[position() > N and position() >>> < M] >>> Range: bytes=0-1000 >>> >>> If the response is truncated, then you need to adjust your pagination >>> size on the client. >>> >>> -Jonathan R. >>> >> >> I think this is going in the right direction now. So let me ask a >> couple of questions to verify that the position() is valid for the >> purpose we want. >> >> 1) Is position already part of XCAP? By reading the XCAP base document >> I guess the answer is yes. > > > No, it is not. I would not suggest putting this in the base spec, which > is already overdue and suffering feature creep. I have suggested, in > another thread, that we perhaps can have an "xcap advanced operations" > spec that extended xcap with new features, including multiple > insertions. This would possibly be a candidate feature for such an > extension, if the group decided to pursue that. > > >> >> 2) I guess if we have a non-flat list, the position element will >> operate in all the leaves of the XML document. For instance, if we >> have a resource list document, with several elements, each one >> containing a few elements, the position() predicate executed >> in the element will consider the element sequentially >> ordered. > > > No. It would apply only at the specific place in the hierarchy where it > is placed. > >> >> Let me try to explain better with an example. Consider the following >> resource list XML document. >> >> > subscribeable="true"> >> >> Bill Doe >> >> >> Johanna Doe >> >> > subscribeable="true"> >> >> Joe Smith >> >> >> Nancy Gross >> >> >> Peter Black >> >> http://www.example.org/xcap/resource-lists/users/a/foo >> >> >> >> >> There are 5 elements, named Bill, Johanna, Joe, Nancy and >> Peter. Imagine I want entries 2 to 4 (in spite they span across >> different lists). Will the HTTP URI be something like: >> >> GET >> http://server/blah-blah/resource-lists/users/jack/entry[position()>1 >> and position()<5] > > > No, this will not work. I would suggest that, if you are worried about > this, the client would page in each level of the hierarchy at a time. > > >> >> 3) I believe the HTTP byte ranges is a complement of this feature, a >> kind of emergency life jacket that under normal circumstances will not >> be use. I doubt an XCAP client can do much with an XML document that >> is truncated by the byte ranges: it can just discard the contents or >> store them (if it has enough memory) and request the rest of the >> document. > > > Right. The problem Ranges solves is if a fixed memory is available in > the device for the content, you can make sure that there is room to > store the results. If the results are a truncated document, you would > need to retry with a much smaller page size. > > -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 Tue Jul 6 06:53: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 GAA05216 for ; Tue, 6 Jul 2004 06:53: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 1BhnZj-00038X-AX for simple-archive@ietf.org; Tue, 06 Jul 2004 06:53:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BhnZ0-0002oa-00 for simple-archive@ietf.org; Tue, 06 Jul 2004 06:52:40 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BhnY1-0002EV-00; Tue, 06 Jul 2004 06:51:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BhnF7-0007AG-Tf; Tue, 06 Jul 2004 06:32:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bhn1z-0005K3-7z for simple@megatron.ietf.org; Tue, 06 Jul 2004 06:18: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 GAA03299 for ; Tue, 6 Jul 2004 06:18: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 1Bhn1r-00076k-Py for simple@ietf.org; Tue, 06 Jul 2004 06:18:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bhn11-0006je-00 for simple@ietf.org; Tue, 06 Jul 2004 06:17:33 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BhmzW-0005ym-00 for simple@ietf.org; Tue, 06 Jul 2004 06:15: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 i66AFoN07490; Tue, 6 Jul 2004 13:15:51 +0300 (EET DST) X-Scanned: Tue, 6 Jul 2004 13:13:51 +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 i66ADpTP015806; Tue, 6 Jul 2004 13:13:51 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00vhaAWl; Tue, 06 Jul 2004 13:13:50 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 i66ADjH16614; Tue, 6 Jul 2004 13:13:46 +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, 6 Jul 2004 13:13:25 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [Simple] RE: simple-filter Max Size or Max number of element asfilter cri terias? Date: Tue, 6 Jul 2004 13:13:27 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7023EEAB5@esebe019.ntc.nokia.com> Thread-Topic: [Simple] RE: simple-filter Max Size or Max number of element asfilter cri terias? Thread-Index: AcRirUk1Kw2hhkrBT+a9akQDvHTTtgAguo1A To: , X-OriginalArrivalTime: 06 Jul 2004 10:13:25.0373 (UTC) FILETIME=[DFE77AD0:01C46341] Content-Transfer-Encoding: quoted-printable Cc: Miguel.An.Garcia@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 Perhaps I wasn't clear I was suggesting that the filter, when applied to a HTTP GET, lists the = resources in the buddy list that the client wants to get, much like what = I suggested for the SUBSCRIBE. For example, we have a list containing Bob, Sarah, John and Alice: If I want to SUBSCRIBE and receive information about Bob and Alice, this = is what the filter in the SUBSCRIBE would look like (the xpath = expression is according the event list package): //rlmi:list/rlmi:resource[@uri=3D""bob@example.com"] //rlmi:list/rlmi:resource[@uri=3D""alice@example.com"] Now, if I do a HTTP GET and want to get those resources, then the GET = would have a filter: = //resource-lists/list[@name=3D"friends"]/entry[@uri=3D""bob@example.com"]= = //resource-lists/list[@name=3D"friends"]/entry[@uri=3D""alice@example.com= "] Thanks, Hisham > -----Original Message----- > From: simple-bounces@ietf.org=20 > [mailto:simple-bounces@ietf.org]On Behalf > Of ext Anders Lindgren C (HF/EAB) > Sent: 05.July.2004 18:26 > To: Khartabil Hisham (Nokia-TP-MSW/Helsinki); simple@ietf.org > Cc: Garcia Miguel.An (Nokia-NRC/Helsinki) > Subject: [Simple] RE: simple-filter Max Size or Max number of element > asfilter cri terias? >=20 >=20 > Hi > In the tread #RE: [Simple] Re: XCAP Directory: Large=20 > response ?" you asked Miguel to have a look at the filter=20 > draft to solve the XCAP problem. I qoute: > "I wonder if you can use the following event filtering draft=20 > with HTTP GET? >=20 > http://www.ietf.org/internet-drafts/draft-ietf-simple-filter-f > ormat-01.txt (currently in WGLC) >=20 > At least the part could be useful." >=20 > My view is that it is the same thing Miguel and I are=20 > addressing, but on different protocols ( SIP, XCAP). A client=20 > can get a list of users that is to more that it can handle.=20 > How can it be that the filter draft can solve the XCAP=20 > problem but not the Subscribe problem? > /Anders >=20 >=20 >=20 > -----Original Message----- > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > Sent: den 2 juli 2004 16:01 > To: Anders Lindgren C (HF/EAB); simple@ietf.org > Subject: RE: simple-filter Max Size or Max number of element as filter > criterias? >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: ext Anders Lindgren C (HF/EAB) > > [mailto:anders.c.lindgren@ericsson.com] > > Sent: 02.July.2004 16:42 > > To: Khartabil Hisham (Nokia-TP-MSW/Helsinki); simple@ietf.org > > Subject: RE: simple-filter Max Size or Max number of=20 > element as filter > > criterias? > >=20 > >=20 > > Ok > > Can I select the number of elements of a certain type I want=20 > > to receive? Ie give my at the most 100 buddies in a resource=20 > > list when subscribing to a list? >=20 > No you cannot, but what you can do is list in the filter the=20 > buddies you are interested in receiving information about. I=20 > think this is more useful that using the filter to tell the=20 > server to send you the first x buddies. >=20 > /Hisham >=20 > > Or is it that something=20 > > complete new is needed or is it covered by some other spec? =20 > > As I see it this is a general problem for all types of=20 > > Subscribe for event packages if you can not control the size=20 > > of what is send in the Notify. > > Regards Anders > >=20 > > -----Original Message----- > > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > > Sent: den 2 juli 2004 14:40 > > To: Anders Lindgren C (HF/EAB); simple@ietf.org > > Subject: RE: simple-filter Max Size or Max number of=20 > element as filter > > criterias? > >=20 > >=20 > > You can reduce the size of the document delivered in the=20 > > NOTIFY by using the filters (but selecting the elements that=20 > > you really want to be delivered to you), but you cannot=20 > > filter based on size. You cannot say "send me a NOTIFY with a=20 > > body no larger than 1000 bytes". > >=20 > > If you want something like that, then this is outside the=20 > > scope of the filtering drafts in question. > >=20 > > Regards, > > Hisham > >=20 > > > -----Original Message----- > > > From: ext Anders Lindgren C (HF/EAB) > > > [mailto:anders.c.lindgren@ericsson.com] > > > Sent: 02.July.2004 15:23 > > > To: Khartabil Hisham (Nokia-TP-MSW/Helsinki); simple@ietf.org > > > Subject: RE: simple-filter Max Size or Max number of=20 > > element as filter > > > criterias? > > >=20 > > >=20 > > > Hi > > > The question is what "unwanted" information" mean? Can it be=20 > > > that a XML document that is to large to handle can be=20 > > > regarded as "unwanted" information and therefore can be=20 > > > regarded as being inside the scope of the simple-filter draft. > > > Regards > > > Anders > > >=20 > > > -----Original Message----- > > > From: hisham.khartabil@nokia.com=20 [mailto:hisham.khartabil@nokia.com] > > Sent: den 2 juli 2004 10:07 > > To: Anders Lindgren C (HF/EAB); simple@ietf.org > > Subject: RE: simple-filter Max Size or Max number of=20 > element as filter > > criterias? > >=20 > >=20 > > I believe that you are asking for is outside the scope of the=20 > > simple-filter drafts. It can be done with filters, but not=20 > those ones. > >=20 > > The current filter drafts talk about filtering unwanted or=20 > > uninteresting information sent in a NOTIFY. They also talk=20 > > about triggering of notifications when certain changes to the=20 > > state of an event occur. > >=20 > > Regards, > > Hisham > >=20 > > > -----Original Message----- > > > From: ext Anders Lindgren C (HF/EAB) > > > [mailto:anders.c.lindgren@ericsson.com] > > > Sent: 02.July.2004 10:53 > > > To: simple@ietf.org; Khartabil Hisham (Nokia-TP-MSW/Helsinki) > > > Subject: simple-filter Max Size or Max number of element as filter > > > criterias? > > >=20 > > >=20 > > > Hi, > > > The XML documents sent from the network to the client can be=20 > > > very large or it can contains a very long sequence of=20 > > > elements ( e.g a resource list with 1000 buddies) > > > It will also exist different types of clients. Some clients=20 > > > can specify a very large resource list and it will exist=20 > > > clients that can not handle that large list. > > >=20 > > > I have not found how a client can inform the network about=20 > > > how large documents is can handle or how many elements of a=20 > > > certain type it can handle. > > > My question is now if this information can be regarded as=20 > > > filter criterias and includes in this filter specification? > > >=20 > > > Best regards > > >=20 > > > Anders Lindgren Ericsson AB Sweden > > >=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 Tue Jul 6 06:56: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 GAA05305 for ; Tue, 6 Jul 2004 06:56: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 1BhncU-00044A-97 for simple-archive@ietf.org; Tue, 06 Jul 2004 06:56:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BhnbV-0003l0-00 for simple-archive@ietf.org; Tue, 06 Jul 2004 06:55:14 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bhnab-00039e-00; Tue, 06 Jul 2004 06:54:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BhnF8-0007AR-LZ; Tue, 06 Jul 2004 06:32:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bhn21-0005K8-1M for simple@megatron.ietf.org; Tue, 06 Jul 2004 06:18: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 GAA03306 for ; Tue, 6 Jul 2004 06:18: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 1Bhn1t-00076v-LN for simple@ietf.org; Tue, 06 Jul 2004 06:18:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bhn13-0006k7-00 for simple@ietf.org; Tue, 06 Jul 2004 06:17:37 -0400 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1Bhmza-0005xv-00 for simple@ietf.org; Tue, 06 Jul 2004 06:16:03 -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 i66AFn618501; Tue, 6 Jul 2004 13:15:50 +0300 (EET DST) X-Scanned: Tue, 6 Jul 2004 13:14:08 +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 i66AE8Os016644; Tue, 6 Jul 2004 13:14:08 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00xGvIWk; Tue, 06 Jul 2004 13:14:06 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 i66AE6H14395; Tue, 6 Jul 2004 13:14:06 +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, 6 Jul 2004 13:13:35 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [Simple] RE: XCAP Directory: Large response ? Date: Tue, 6 Jul 2004 13:13:38 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7023EEAB6@esebe019.ntc.nokia.com> Thread-Topic: [Simple] RE: XCAP Directory: Large response ? Thread-Index: AcRjMzTC9REURHRgRKuIfigmtKtlXAADNsgw To: , X-OriginalArrivalTime: 06 Jul 2004 10:13:35.0935 (UTC) FILETIME=[E6331CF0:01C46341] Content-Transfer-Encoding: quoted-printable Cc: george.foti@ericsson.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 really wonder what the benefit is from such feature. If there are 1000 = resources in a resource list and I can only fit 100 due to memory = limitations in my device. What would it mean for me to get the first = 100, the 2nd 100 or the resources between 500 and 599? I would rather prefer a feature where I can select the resources I want = to get, if they are indeed on the list. That's why I was suggestion an = event-filter like approach we I select the resources explicitly. I gave an example on this in a separate thread, but I copy it again = here: GET ... = //resource-lists/list[@name=3D"friends"]/entry[@uri=3D""bob@example.com"]= = //resource-lists/list[@name=3D"friends"]/entry[@uri=3D""alice@example.com= "] So a filter is used to GET the resources a client is interested in, if = they are present on the list. /Hisham > -----Original Message----- > From: simple-bounces@ietf.org=20 > [mailto:simple-bounces@ietf.org]On Behalf > Of ext Miguel Garcia > Sent: 06.July.2004 10:16 > To: Jonathan Rosenberg > Cc: George Foti (QA/EMC); simple@ietf.org > Subject: Re: [Simple] RE: XCAP Directory: Large response ? >=20 >=20 > Summary of the thread: >=20 > - I think we have consensus on adding a feature that allows an XCAP=20 > client to request a range of XML elements in a particular schema. >=20 > - It seems that the HTP Range header does not serve for the purpose,=20 > since it operates on bytes and will most likely truncate XML=20 > documents. >=20 > - It seems that the XPath position() operator will almost=20 > serve, but it=20 > is not part of the XCAP base specification. >=20 > - And we don't want to delay the XCAP base spec by adding=20 > more features=20 > at this stage. >=20 > - So this feature can be added as an advanced XCAP feature at=20 > a later stage. >=20 > So far so good. At least I agree with the above. There is one=20 > bit where=20 > I don't quite agree: it seems that the position() opeator in XPath=20 > operates on the element level, meaning that if we have a=20 > non-flat list,=20 > the XCAP client will need to request ranges in each of the lists (see=20 > point 2 below). >=20 > I think this is bad, and since we are going to design this extended=20 > feature, we should make it simple to use. >=20 > First, if I have a device that can accommodate x entries, my=20 > XCAP client=20 > would need to request x entries for the first list, get the response=20 > (say y entries came), then do a new query requesting x-y=20 > entries in the=20 > next list, etc. Alternatively, my XCAP client can request x=20 > entries en=20 > each list, and perhaps I will get n * x entries (n is the=20 > number of lists). >=20 > Second, this way of working assumes that I know in advance=20 > the number of=20 > lists that are nested. This assumption is false when I have never=20 > downloaded the XML document (such as when I start using a new device). >=20 > In short: I want to have the means in XCAP to indicate:=20 > "please send me=20 > this XML document with range of x to z entries, and send them=20 > to me in a=20 > valid XML document". I don't need to know the structure of=20 > the document=20 > in advance (how many deep nested lists and their names),=20 > although I know=20 > the XML schema of the document. >=20 > Is this something we can agree upon? >=20 > - Miguel >=20 > Jonathan Rosenberg wrote: >=20 > > inline. > >=20 > > Miguel Garcia wrote: > >=20 > >>> XCAP doesnt support that level of complexity in the server. If it=20 > >>> did, and you wanted protection against memory overload=20 > (say, 1k max),=20 > >>> you'd do something like this: > >>> > >>> GET http://server/blah-blah/list/buddy[position() > N and=20 > position()=20 > >>> < M] > >>> Range: bytes=3D0-1000 > >>> > >>> If the response is truncated, then you need to adjust=20 > your pagination=20 > >>> size on the client. > >>> > >>> -Jonathan R. > >>> > >> > >> I think this is going in the right direction now. So let me ask a=20 > >> couple of questions to verify that the position() is valid for the=20 > >> purpose we want. > >> > >> 1) Is position already part of XCAP? By reading the XCAP=20 > base document=20 > >> I guess the answer is yes. > >=20 > >=20 > > No, it is not. I would not suggest putting this in the base=20 > spec, which=20 > > is already overdue and suffering feature creep. I have=20 > suggested, in=20 > > another thread, that we perhaps can have an "xcap advanced=20 > operations"=20 > > spec that extended xcap with new features, including multiple=20 > > insertions. This would possibly be a candidate feature for such an=20 > > extension, if the group decided to pursue that. > >=20 > >=20 > >> > >> 2) I guess if we have a non-flat list, the position element will=20 > >> operate in all the leaves of the XML document. For=20 > instance, if we=20 > >> have a resource list document, with several =20 > elements, each one=20 > >> containing a few elements, the position()=20 > predicate executed=20 > >> in the element will consider the element=20 > sequentially=20 > >> ordered. > >=20 > >=20 > > No. It would apply only at the specific place in the=20 > hierarchy where it=20 > > is placed. > >=20 > >> > >> Let me try to explain better with an example. Consider the=20 > following=20 > >> resource list XML document. > >> > >> >> subscribeable=3D"true"> > >> > >> Bill Doe > >> > >> > >> Johanna Doe > >> > >> >> subscribeable=3D"true"> > >> > >> Joe Smith > >> > >> > >> Nancy Gross > >> > >> > >> Peter Black > >> > >> =20 > http://www.example.org/xcap/resource-lists/users/a/foo > >> > >> > >> > >> > >> There are 5 elements, named Bill, Johanna, Joe, Nancy and=20 > >> Peter. Imagine I want entries 2 to 4 (in spite they span across=20 > >> different lists). Will the HTTP URI be something like: > >> > >> GET=20 > >>=20 http://server/blah-blah/resource-lists/users/jack/entry[position()>1=20 >> and position()<5] >=20 >=20 > No, this will not work. I would suggest that, if you are worried about = > this, the client would page in each level of the hierarchy at a time. >=20 >=20 >> >> 3) I believe the HTTP byte ranges is a complement of this feature, a=20 >> kind of emergency life jacket that under normal circumstances will = not=20 >> be use. I doubt an XCAP client can do much with an XML document that=20 >> is truncated by the byte ranges: it can just discard the contents or=20 >> store them (if it has enough memory) and request the rest of the=20 >> document. >=20 >=20 > Right. The problem Ranges solves is if a fixed memory is available in=20 > the device for the content, you can make sure that there is room to=20 > store the results. If the results are a truncated document, you would=20 > need to retry with a much smaller page size. >=20 > -Jonathan R. >=20 >=20 --=20 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 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Jul 6 07:29: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 HAA06455 for ; Tue, 6 Jul 2004 07:29: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 1Bho8C-0006ih-Jn for simple-archive@ietf.org; Tue, 06 Jul 2004 07:29:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bho78-0006Kg-00 for simple-archive@ietf.org; Tue, 06 Jul 2004 07:27:55 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bho6I-00060D-00; Tue, 06 Jul 2004 07:27:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BhniA-00027Y-4Y; Tue, 06 Jul 2004 07:02:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BhnWq-0000zv-KW for simple@megatron.ietf.org; Tue, 06 Jul 2004 06: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 GAA05005 for ; Tue, 6 Jul 2004 06:50:16 -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 1BhnWi-000250-Vf for simple@ietf.org; Tue, 06 Jul 2004 06:50:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BhnVf-0001kq-00 for simple@ietf.org; Tue, 06 Jul 2004 06:49:11 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1BhnUf-0001Jv-00 for simple@ietf.org; Tue, 06 Jul 2004 06:48:09 -0400 Received: from hydra.cs.columbia.edu (IDENT:0sv3ZqXzMmgKlv2lkDjekEtAvUhPtaqu@hydra.cs.columbia.edu [128.59.16.129]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i66Am8fq016904 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Tue, 6 Jul 2004 06:48:08 -0400 (EDT) Received: from webmail.cs.columbia.edu (IDENT:p+/rioIIjhgwQmW/Ruq41LT99OCvzwhX@localhost [127.0.0.1]) by hydra.cs.columbia.edu (8.12.10/8.12.10) with SMTP id i66Am8Xt030835 for ; Tue, 6 Jul 2004 06:48:08 -0400 Received: from 212.119.9.178 (SquirrelMail authenticated user hgs) by webmail.cs.columbia.edu with HTTP; Tue, 6 Jul 2004 06:48:08 -0400 (EDT) Message-ID: <57796.212.119.9.178.1089110888.squirrel@webmail.cs.columbia.edu> Date: Tue, 6 Jul 2004 06:48:08 -0400 (EDT) To: simple@ietf.org 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.7.5.105974 X-PerlMx-Spam: Gauge=X, Probability=10%, Report='PRIORITY_NO_NAME 0.716, __SANE_MSGID 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, __MIME_TEXT_ONLY 0, __HAS_MSGID 0, USER_AGENT 0.000' Content-Transfer-Encoding: 8bit Subject: [Simple] What are tuples? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.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 Trying to pick up and maybe summarize aspects of the discussion. There may be some items of general consensus: - [HUMAN] There didn't to be much enthusiasm for a separate tuple type for the human itself. Rather, there might be some use for shared information that reflects the presentity as a whole (see below). In general, if different tuples represent complementary rather than conflicting information about a presentity, there doesn't seem much need for a human abstraction. One use for a "human" is the ability to indicate whether the person is reachable by visiting. Rather than designating some pseudo-URI (goto: :-)), it might be sufficient to have a URI-less tuple. Having a label seems to just introduce another error condition (in-person type with a URI). Proposal: treat non-URI tuple as personal interaction. - [SERVICE] There seems to some consensus that all tuples are essentially services. There are different granularities of service announcement, e.g., by unifying several URIs behind one externally visible URI, with a proxy doing the detail routing, but there doesn't seem to be a fundamental difference between a URI representing one and one hiding several. Proposal: drop tuple classification. - [DEVICE] Some tuples will share characteristics. For example, all devices carried on the belt of a single user will share the same location to within a few inches, while others might share device characteristics such as screen size. While the concept of 'device' is fairly clear for many classical devices such as cell phones, laptops, desk phones and the like, there are also an increasing number of pseudo-devices tied together by some kind of personal area network (PAN) such as BlueTooth. A single physical device might offer many different services, but it is unclear to me as to why the watcher benefits from knowing this. There has been some discussion on providing some labeling or grouping that ties together tuples as being part of some notion of a device. There are several possible motivations for such labeling or grouping. At the lowest level, it simply avoids repeating common information such as location, presumably to make notifications shorter. This might also allow the watcher to infer characteristics across tuples, although I'm less clear what safe assumptions on such inference might be. Question: I'd like to hear more about motivations and use cases. Proposal: Can we punt? - [INHERITANCE] There was discussion on some way of inheriting information from the presentity (by putting common information at the presentity level) or from other tuples (by reference to a tupe identifier). Proposal: allow inheritance of location, CIPID (already there) and maybe activity at presentity level. Open issue: do they need to be wrapped? Henning _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Jul 6 07:31: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 HAA06840 for ; Tue, 6 Jul 2004 07:31: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 1BhoAh-00000m-My for simple-archive@ietf.org; Tue, 06 Jul 2004 07:31:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bho9h-0007SD-00 for simple-archive@ietf.org; Tue, 06 Jul 2004 07:30:34 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bho8c-0006iG-00; Tue, 06 Jul 2004 07:29:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bhntn-0002w6-BA; Tue, 06 Jul 2004 07:14:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BhnZt-0001Ma-BS for simple@megatron.ietf.org; Tue, 06 Jul 2004 06:53: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 GAA05237 for ; Tue, 6 Jul 2004 06:53: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 1BhnZm-00038r-1O for simple@ietf.org; Tue, 06 Jul 2004 06:53:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BhnZ4-0002ov-00 for simple@ietf.org; Tue, 06 Jul 2004 06:52:43 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1BhnY2-0002T6-00 for simple@ietf.org; Tue, 06 Jul 2004 06:51:38 -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 i66ApZJ04396; Tue, 6 Jul 2004 13:51:35 +0300 (EET DST) X-Scanned: Tue, 6 Jul 2004 13:51:25 +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 i66ApPos021040; Tue, 6 Jul 2004 13:51:25 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 001JfrD1; Tue, 06 Jul 2004 13:51:23 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 i66ApEH21974; Tue, 6 Jul 2004 13:51:14 +0300 (EET DST) Received: from nokia.com ([172.21.42.108]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 6 Jul 2004 13:51:14 +0300 Message-ID: <40EA8421.4040404@nokia.com> Date: Tue, 06 Jul 2004 13:51:13 +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: "Khartabil Hisham (Nokia-TP-MSW/Helsinki)" Subject: Re: [Simple] RE: XCAP Directory: Large response ? References: <2038BCC78B1AD641891A0D1AE133DBB7023EEAB6@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB7023EEAB6@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Jul 2004 10:51:14.0303 (UTC) FILETIME=[284AB8F0:01C46347] Content-Transfer-Encoding: 7bit Cc: "George Foti \(QA/EMC\)" , Jonathan Rosenberg , 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 Well, the benefit is clear to me. Let's assume you can accommodate 100 resources in a device. You get resources 1-100, do some xcap operation (add, delete, modify), then you can release your memory and get resources 101-200, and so on. Think for a second that this is something similar to browsing your e-mails through a web interface. All the applications I am aware of allow you to do some pagination. They return a valid HTML code with a range of messages of your inbox. The key feature is to avoid flood your browser and get the user bored scrolling down over 1000 messages. - Miguel Khartabil Hisham (Nokia-TP-MSW/Helsinki) wrote: > I really wonder what the benefit is from such feature. If there are 1000 resources in a resource list and I can only fit 100 due to memory limitations in my device. What would it mean for me to get the first 100, the 2nd 100 or the resources between 500 and 599? > > I would rather prefer a feature where I can select the resources I want to get, if they are indeed on the list. That's why I was suggestion an event-filter like approach we I select the resources explicitly. > > I gave an example on this in a separate thread, but I copy it again here: > > GET ... > > > > > > > //resource-lists/list[@name="friends"]/entry[@uri=""bob@example.com"] > > > //resource-lists/list[@name="friends"]/entry[@uri=""alice@example.com"] > > > > > > > So a filter is used to GET the resources a client is interested in, if they are present on the list. > > /Hisham > > >>-----Original Message----- >>From: simple-bounces@ietf.org >>[mailto:simple-bounces@ietf.org]On Behalf >>Of ext Miguel Garcia >>Sent: 06.July.2004 10:16 >>To: Jonathan Rosenberg >>Cc: George Foti (QA/EMC); simple@ietf.org >>Subject: Re: [Simple] RE: XCAP Directory: Large response ? >> >> >>Summary of the thread: >> >>- I think we have consensus on adding a feature that allows an XCAP >>client to request a range of XML elements in a particular schema. >> >>- It seems that the HTP Range header does not serve for the purpose, >>since it operates on bytes and will most likely truncate XML >>documents. >> >>- It seems that the XPath position() operator will almost >>serve, but it >>is not part of the XCAP base specification. >> >>- And we don't want to delay the XCAP base spec by adding >>more features >>at this stage. >> >>- So this feature can be added as an advanced XCAP feature at >>a later stage. >> >>So far so good. At least I agree with the above. There is one >>bit where >>I don't quite agree: it seems that the position() opeator in XPath >>operates on the element level, meaning that if we have a >>non-flat list, >>the XCAP client will need to request ranges in each of the lists (see >>point 2 below). >> >>I think this is bad, and since we are going to design this extended >>feature, we should make it simple to use. >> >>First, if I have a device that can accommodate x entries, my >>XCAP client >>would need to request x entries for the first list, get the response >>(say y entries came), then do a new query requesting x-y >>entries in the >>next list, etc. Alternatively, my XCAP client can request x >>entries en >>each list, and perhaps I will get n * x entries (n is the >>number of lists). >> >>Second, this way of working assumes that I know in advance >>the number of >>lists that are nested. This assumption is false when I have never >>downloaded the XML document (such as when I start using a new device). >> >>In short: I want to have the means in XCAP to indicate: >>"please send me >>this XML document with range of x to z entries, and send them >>to me in a >>valid XML document". I don't need to know the structure of >>the document >>in advance (how many deep nested lists and their names), >>although I know >>the XML schema of the document. >> >>Is this something we can agree upon? >> >>- Miguel >> >>Jonathan Rosenberg wrote: >> >> >>>inline. >>> >>>Miguel Garcia wrote: >>> >>> >>>>>XCAP doesnt support that level of complexity in the server. If it >>>>>did, and you wanted protection against memory overload >> >>(say, 1k max), >> >>>>>you'd do something like this: >>>>> >>>>>GET http://server/blah-blah/list/buddy[position() > N and >> >>position() >> >>>>>< M] >>>>>Range: bytes=0-1000 >>>>> >>>>>If the response is truncated, then you need to adjust >> >>your pagination >> >>>>>size on the client. >>>>> >>>>>-Jonathan R. >>>>> >>>> >>>>I think this is going in the right direction now. So let me ask a >>>>couple of questions to verify that the position() is valid for the >>>>purpose we want. >>>> >>>>1) Is position already part of XCAP? By reading the XCAP >> >>base document >> >>>>I guess the answer is yes. >>> >>> >>>No, it is not. I would not suggest putting this in the base >> >>spec, which >> >>>is already overdue and suffering feature creep. I have >> >>suggested, in >> >>>another thread, that we perhaps can have an "xcap advanced >> >>operations" >> >>>spec that extended xcap with new features, including multiple >>>insertions. This would possibly be a candidate feature for such an >>>extension, if the group decided to pursue that. >>> >>> >>> >>>>2) I guess if we have a non-flat list, the position element will >>>>operate in all the leaves of the XML document. For >> >>instance, if we >> >>>>have a resource list document, with several >> >>elements, each one >> >>>>containing a few elements, the position() >> >>predicate executed >> >>>>in the element will consider the element >> >>sequentially >> >>>>ordered. >>> >>> >>>No. It would apply only at the specific place in the >> >>hierarchy where it >> >>>is placed. >>> >>> >>>>Let me try to explain better with an example. Consider the >> >>following >> >>>>resource list XML document. >>>> >>>> >>>subscribeable="true"> >>>> >>>> Bill Doe >>>> >>>> >>>> Johanna Doe >>>> >>>> >>> subscribeable="true"> >>>> >>>> Joe Smith >>>> >>>> >>>> Nancy Gross >>>> >>>> >>>> Peter Black >>>> >>>> >> >>http://www.example.org/xcap/resource-lists/users/a/foo >> >>>> >>>> >>>> >>>> >>>>There are 5 elements, named Bill, Johanna, Joe, Nancy and >>>>Peter. Imagine I want entries 2 to 4 (in spite they span across >>>>different lists). Will the HTTP URI be something like: >>>> >>>>GET >>>> > > http://server/blah-blah/resource-lists/users/jack/entry[position()>1 > >>>and position()<5] >> >> >>No, this will not work. I would suggest that, if you are worried about >>this, the client would page in each level of the hierarchy at a time. >> >> >> >>>3) I believe the HTTP byte ranges is a complement of this feature, a >>>kind of emergency life jacket that under normal circumstances will not >>>be use. I doubt an XCAP client can do much with an XML document that >>>is truncated by the byte ranges: it can just discard the contents or >>>store them (if it has enough memory) and request the rest of the >>>document. >> >> >>Right. The problem Ranges solves is if a fixed memory is available in >>the device for the content, you can make sure that there is room to >>store the results. If the results are a truncated document, you would >>need to retry with a much smaller page size. >> >>-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 Tue Jul 6 08:11: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 IAA08819 for ; Tue, 6 Jul 2004 08:11: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 1Bhon8-0005b0-0r for simple-archive@ietf.org; Tue, 06 Jul 2004 08:11:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bhom8-0005He-00 for simple-archive@ietf.org; Tue, 06 Jul 2004 08:10:17 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bhol8-0004fk-00; Tue, 06 Jul 2004 08:09:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BhoQ5-0006OA-1F; Tue, 06 Jul 2004 07:47:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BhoA1-0004dW-CY for simple@megatron.ietf.org; Tue, 06 Jul 2004 07:30: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 HAA06770 for ; Tue, 6 Jul 2004 07:30: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 1Bho9v-0007U6-QX for simple@ietf.org; Tue, 06 Jul 2004 07:30:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bho8w-00075U-00 for simple@ietf.org; Tue, 06 Jul 2004 07:29:47 -0400 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1Bho7o-0006fg-00 for simple@ietf.org; Tue, 06 Jul 2004 07:28:36 -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 i66BSY621346; Tue, 6 Jul 2004 14:28:34 +0300 (EET DST) X-Scanned: Tue, 6 Jul 2004 14:28:33 +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 i66BSXLw032262; Tue, 6 Jul 2004 14:28:33 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00SDEtZj; Tue, 06 Jul 2004 14:28:31 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 i66BSVH24258; Tue, 6 Jul 2004 14:28:31 +0300 (EET DST) Received: from nokia.com ([172.21.42.108]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 6 Jul 2004 14:28:29 +0300 Message-ID: <40EA8CDD.70108@nokia.com> Date: Tue, 06 Jul 2004 14:28: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: "Khartabil Hisham (Nokia-TP-MSW/Helsinki)" Subject: Re: [Simple] RE: simple-filter Max Size or Max number of element asfilter cri terias? References: <2038BCC78B1AD641891A0D1AE133DBB7023EEAB5@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB7023EEAB5@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Jul 2004 11:28:29.0704 (UTC) FILETIME=[5CB1D880:01C4634C] Content-Transfer-Encoding: 7bit Cc: "Anders Lindgren C \(HF/EAB\)" , 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 Hisham: I find this explanation very interesting, but unfortunately this is not the functionality I was thining of. I thought that I would like to limit the number of entries returned in a document. I don't even know, at the time of requesting, if there is an entry by name Bob, Sarah, John or Alice in my list. I don't even know how many entries and lists I have in the XML document I am trying to retrieve. I just know that my device has some limitations, perhas due to a small display, perhaps due to memory constraints, that makes me want to limit the number of entries returned in the XML document. I don't think the filter fulfills this requirement. - Miguel Khartabil Hisham (Nokia-TP-MSW/Helsinki) wrote: > Perhaps I wasn't clear > > I was suggesting that the filter, when applied to a HTTP GET, lists the resources in the buddy list that the client wants to get, much like what I suggested for the SUBSCRIBE. > > For example, we have a list containing Bob, Sarah, John and Alice: > > > > > > > > > > > > > If I want to SUBSCRIBE and receive information about Bob and Alice, this is what the filter in the SUBSCRIBE would look like (the xpath expression is according the event list package): > > > > > > > //rlmi:list/rlmi:resource[@uri=""bob@example.com"] > > > //rlmi:list/rlmi:resource[@uri=""alice@example.com"] > > > > > > > Now, if I do a HTTP GET and want to get those resources, then the GET would have a filter: > > > > > > > //resource-lists/list[@name="friends"]/entry[@uri=""bob@example.com"] > > > //resource-lists/list[@name="friends"]/entry[@uri=""alice@example.com"] > > > > > > Thanks, > Hisham > > >>-----Original Message----- >>From: simple-bounces@ietf.org >>[mailto:simple-bounces@ietf.org]On Behalf >>Of ext Anders Lindgren C (HF/EAB) >>Sent: 05.July.2004 18:26 >>To: Khartabil Hisham (Nokia-TP-MSW/Helsinki); simple@ietf.org >>Cc: Garcia Miguel.An (Nokia-NRC/Helsinki) >>Subject: [Simple] RE: simple-filter Max Size or Max number of element >>asfilter cri terias? >> >> >>Hi >>In the tread #RE: [Simple] Re: XCAP Directory: Large >>response ?" you asked Miguel to have a look at the filter >>draft to solve the XCAP problem. I qoute: >>"I wonder if you can use the following event filtering draft >>with HTTP GET? >> >>http://www.ietf.org/internet-drafts/draft-ietf-simple-filter-f >>ormat-01.txt (currently in WGLC) >> >>At least the part could be useful." >> >>My view is that it is the same thing Miguel and I are >>addressing, but on different protocols ( SIP, XCAP). A client >>can get a list of users that is to more that it can handle. >>How can it be that the filter draft can solve the XCAP >>problem but not the Subscribe problem? >>/Anders >> >> >> >>-----Original Message----- >>From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] >>Sent: den 2 juli 2004 16:01 >>To: Anders Lindgren C (HF/EAB); simple@ietf.org >>Subject: RE: simple-filter Max Size or Max number of element as filter >>criterias? >> >> >> >> >> >>>-----Original Message----- >>>From: ext Anders Lindgren C (HF/EAB) >>>[mailto:anders.c.lindgren@ericsson.com] >>>Sent: 02.July.2004 16:42 >>>To: Khartabil Hisham (Nokia-TP-MSW/Helsinki); simple@ietf.org >>>Subject: RE: simple-filter Max Size or Max number of >> >>element as filter >> >>>criterias? >>> >>> >>>Ok >>>Can I select the number of elements of a certain type I want >>>to receive? Ie give my at the most 100 buddies in a resource >>>list when subscribing to a list? >> >>No you cannot, but what you can do is list in the filter the >>buddies you are interested in receiving information about. I >>think this is more useful that using the filter to tell the >>server to send you the first x buddies. >> >>/Hisham >> >> >>>Or is it that something >>>complete new is needed or is it covered by some other spec? >>>As I see it this is a general problem for all types of >>>Subscribe for event packages if you can not control the size >>>of what is send in the Notify. >>>Regards Anders >>> >>>-----Original Message----- >>>From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] >>>Sent: den 2 juli 2004 14:40 >>>To: Anders Lindgren C (HF/EAB); simple@ietf.org >>>Subject: RE: simple-filter Max Size or Max number of >> >>element as filter >> >>>criterias? >>> >>> >>>You can reduce the size of the document delivered in the >>>NOTIFY by using the filters (but selecting the elements that >>>you really want to be delivered to you), but you cannot >>>filter based on size. You cannot say "send me a NOTIFY with a >>>body no larger than 1000 bytes". >>> >>>If you want something like that, then this is outside the >>>scope of the filtering drafts in question. >>> >>>Regards, >>>Hisham >>> >>> >>>>-----Original Message----- >>>>From: ext Anders Lindgren C (HF/EAB) >>>>[mailto:anders.c.lindgren@ericsson.com] >>>>Sent: 02.July.2004 15:23 >>>>To: Khartabil Hisham (Nokia-TP-MSW/Helsinki); simple@ietf.org >>>>Subject: RE: simple-filter Max Size or Max number of >>> >>>element as filter >>> >>>>criterias? >>>> >>>> >>>>Hi >>>>The question is what "unwanted" information" mean? Can it be >>>>that a XML document that is to large to handle can be >>>>regarded as "unwanted" information and therefore can be >>>>regarded as being inside the scope of the simple-filter draft. >>>>Regards >>>>Anders >>>> >>>>-----Original Message----- >>>>From: hisham.khartabil@nokia.com > > [mailto:hisham.khartabil@nokia.com] > >>>Sent: den 2 juli 2004 10:07 >>>To: Anders Lindgren C (HF/EAB); simple@ietf.org >>>Subject: RE: simple-filter Max Size or Max number of >> >>element as filter >> >>>criterias? >>> >>> >>>I believe that you are asking for is outside the scope of the >>>simple-filter drafts. It can be done with filters, but not >> >>those ones. >> >>>The current filter drafts talk about filtering unwanted or >>>uninteresting information sent in a NOTIFY. They also talk >>>about triggering of notifications when certain changes to the >>>state of an event occur. >>> >>>Regards, >>>Hisham >>> >>> >>>>-----Original Message----- >>>>From: ext Anders Lindgren C (HF/EAB) >>>>[mailto:anders.c.lindgren@ericsson.com] >>>>Sent: 02.July.2004 10:53 >>>>To: simple@ietf.org; Khartabil Hisham (Nokia-TP-MSW/Helsinki) >>>>Subject: simple-filter Max Size or Max number of element as filter >>>>criterias? >>>> >>>> >>>>Hi, >>>>The XML documents sent from the network to the client can be >>>>very large or it can contains a very long sequence of >>>>elements ( e.g a resource list with 1000 buddies) >>>>It will also exist different types of clients. Some clients >>>>can specify a very large resource list and it will exist >>>>clients that can not handle that large list. >>>> >>>>I have not found how a client can inform the network about >>>>how large documents is can handle or how many elements of a >>>>certain type it can handle. >>>>My question is now if this information can be regarded as >>>>filter criterias and includes in this filter specification? >>>> >>>>Best regards >>>> >>>>Anders Lindgren Ericsson AB Sweden >>>> >>> > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple -- 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 Jul 6 08:18: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 IAA09049 for ; Tue, 6 Jul 2004 08:18: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 1Bhotw-00005L-1S for simple-archive@ietf.org; Tue, 06 Jul 2004 08:18:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bhot0-0007Z2-00 for simple-archive@ietf.org; Tue, 06 Jul 2004 08:17:23 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bhos3-0006up-00; Tue, 06 Jul 2004 08:16:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BhoUQ-0006sV-MV; Tue, 06 Jul 2004 07:51:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BhoJX-0005ay-7d for simple@megatron.ietf.org; Tue, 06 Jul 2004 07:40: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 HAA07328 for ; Tue, 6 Jul 2004 07:40: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 1BhoJR-00038z-P6 for simple@ietf.org; Tue, 06 Jul 2004 07:40:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BhoIO-0002md-00 for simple@ietf.org; Tue, 06 Jul 2004 07:39:33 -0400 Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx with esmtp (Exim 4.12) id 1BhoHV-000283-00 for simple@ietf.org; Tue, 06 Jul 2004 07:38:37 -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 i66Bc8ou000468; Tue, 6 Jul 2004 06:38:08 -0500 (CDT) Received: by eamrcnt750.exu.ericsson.se with Internet Mail Service (5.5.2657.72) id <3J94TR6X>; Tue, 6 Jul 2004 06:36:58 -0500 Message-ID: From: "George Foti (QA/EMC)" To: "'Miguel Garcia'" , Jonathan Rosenberg Subject: RE: [Simple] What is an entrty was (RE: XCAP Directory: Large res ponse ?) Date: Tue, 6 Jul 2004 06:28:53 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) 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.1 required=5.0 tests=AWL autolearn=no version=2.60 Miguel you wrote, > I think this is bad, and since we are going to design this extended > feature, we should make it simple to use. > > First, if I have a device that can accommodate x entries, my > XCAP client > would need to request x entries for the first list, get the response > (say y entries came), then do a new query requesting x-y > entries in the > next list, etc. Alternatively, my XCAP client can request x > entries en > each list, and perhaps I will get n * x entries (n is the > number of lists). > > Second, this way of working assumes that I know in advance > the number of > lists that are nested. This assumption is false when I have never > downloaded the XML document (such as when I start using a new device). > > In short: I want to have the means in XCAP to indicate: > "please send me > this XML document with range of x to z entries, and send them > to me in a > valid XML document". I don't need to know the structure of > the document > in advance (how many deep nested lists and their names), > although I know > the XML schema of the document. > > Is this something we can agree upon? > Miguel, I agree with you on that one. But this is not the only assumption that needs to be stated. Other assumptions. The user does not in advance how may entries exist in the list in the first place. Is there a way for that information to be available. Otherwise, how would a user to know if he has all the list or not, or how many entires he should retrieve, etc... > >> >> subscribeable="true"> > >> > >> Bill Doe > >> > >> > >> Johanna Doe > >> > >> >> subscribeable="true"> > >> > >> Joe Smith > >> > >> > >> Nancy Gross > >> > >> > >> Peter Black > >> > >> > http://www.example.org/xcap/resource-lists/users/a/foo > >> > >> > >> > >> > >> There are 5 elements, named Bill, Johanna, Joe, Nancy and > >> Peter. Imagine I want entries 2 to 4 (in spite they span across > >> different lists). Will the HTTP URI be something like: > >> Now that makes me ask a second question. What is an entry from a server point of view ? Looking back at the example above. If a user request 3 entries. Does he get only 2 cause the thirs want is a list or ????? Rgds/gf _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Jul 6 08:22: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 IAA09229 for ; Tue, 6 Jul 2004 08:22: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 1Bhoxp-0001QV-5F for simple-archive@ietf.org; Tue, 06 Jul 2004 08:22:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bhowu-00012O-00 for simple-archive@ietf.org; Tue, 06 Jul 2004 08:21:25 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BhowE-0000We-00; Tue, 06 Jul 2004 08:20:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BhoUY-0006u0-JN; Tue, 06 Jul 2004 07:52:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BhoKD-0005h3-Qq for simple@megatron.ietf.org; Tue, 06 Jul 2004 07:41: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 HAA07358 for ; Tue, 6 Jul 2004 07:41: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 1BhoK8-0003S9-7w for simple@ietf.org; Tue, 06 Jul 2004 07:41:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BhoJ7-000361-00 for simple@ietf.org; Tue, 06 Jul 2004 07:40:18 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1BhoI6-0002fW-00 for simple@ietf.org; Tue, 06 Jul 2004 07:39:14 -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 i66Bd9J04497; Tue, 6 Jul 2004 14:39:09 +0300 (EET DST) X-Scanned: Tue, 6 Jul 2004 14:39:06 +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 i66Bd6bL031364; Tue, 6 Jul 2004 14:39:06 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00qoCu3b; Tue, 06 Jul 2004 14:39:02 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 i66Bd0H03903; Tue, 6 Jul 2004 14:39:00 +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, 6 Jul 2004 14:38: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 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [Simple] RE: XCAP Directory: Large response ? Date: Tue, 6 Jul 2004 14:38:54 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7023EEAB7@esebe019.ntc.nokia.com> Thread-Topic: [Simple] RE: XCAP Directory: Large response ? Thread-Index: AcRjRyi5OfocbM1qQ8SN4SNndbyIawABhjdw To: X-OriginalArrivalTime: 06 Jul 2004 11:38:54.0925 (UTC) FILETIME=[D15AFFD0:01C4634D] Content-Transfer-Encoding: quoted-printable Cc: george.foti@ericsson.com, 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.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable I think extending XCAP to enable this feature is limiting and only works = for XCAP. A better solution would be to create a general HTTP solution. I acknowledge that the filter stuff as it is defined now does not allow = you to do what you want, but we can extend it in a similar way Jonathan = proposed to extend XCAP. I.e. Allow the filter to carry the position() = function. The example I gave therefore becomes: GET ... //resource-lists/list[@name=3D"friends"]/entry[position() > N = and position() < M] Regards, Hisham > -----Original Message----- > From: Miguel Garcia [mailto:Miguel.An.Garcia@nokia.com] > Sent: 06.July.2004 13:51 > To: Khartabil Hisham (Nokia-TP-MSW/Helsinki) > Cc: Jonathan Rosenberg; George Foti (QA/EMC); simple@ietf.org > Subject: Re: [Simple] RE: XCAP Directory: Large response ? >=20 >=20 > Well, the benefit is clear to me. Let's assume you can=20 > accommodate 100=20 > resources in a device. You get resources 1-100, do some xcap=20 > operation=20 > (add, delete, modify), then you can release your memory and get=20 > resources 101-200, and so on. >=20 > Think for a second that this is something similar to browsing your=20 > e-mails through a web interface. All the applications I am aware of=20 > allow you to do some pagination. They return a valid HTML code with a=20 > range of messages of your inbox. The key feature is to avoid=20 > flood your=20 > browser and get the user bored scrolling down over 1000 messages. >=20 > - Miguel >=20 > Khartabil Hisham (Nokia-TP-MSW/Helsinki) wrote: >=20 > > I really wonder what the benefit is from such feature. If=20 > there are 1000 resources in a resource list and I can only=20 > fit 100 due to memory limitations in my device. What would it=20 > mean for me to get the first 100, the 2nd 100 or the=20 > resources between 500 and 599? > >=20 > > I would rather prefer a feature where I can select the=20 > resources I want to get, if they are indeed on the list.=20 > That's why I was suggestion an event-filter like approach we=20 > I select the resources explicitly. > >=20 > > I gave an example on this in a separate thread, but I copy=20 > it again here: > >=20 > > GET ... > >=20 > > > > > > > > > > > > =20 > = //resource-lists/list[@name=3D"friends"]/entry[@uri=3D""bob@example.com"]= > > > > > > =20 > //resource-lists/list[@name=3D"friends"]/entry[@uri=3D""alice@exam > ple.com"] > > > > > > > > > >=20 > >=20 > > So a filter is used to GET the resources a client is=20 > interested in, if they are present on the list. > >=20 > > /Hisham > >=20 > >=20 > >>-----Original Message----- > >>From: simple-bounces@ietf.org=20 > >>[mailto:simple-bounces@ietf.org]On Behalf > >>Of ext Miguel Garcia > >>Sent: 06.July.2004 10:16 > >>To: Jonathan Rosenberg > >>Cc: George Foti (QA/EMC); simple@ietf.org > >>Subject: Re: [Simple] RE: XCAP Directory: Large response ? > >> > >> > >>Summary of the thread: > >> > >>- I think we have consensus on adding a feature that allows an XCAP=20 > >>client to request a range of XML elements in a particular schema. > >> > >>- It seems that the HTP Range header does not serve for the=20 > purpose,=20 > >>since it operates on bytes and will most likely truncate XML=20 > >>documents. > >> > >>- It seems that the XPath position() operator will almost=20 > >>serve, but it=20 > >>is not part of the XCAP base specification. > >> > >>- And we don't want to delay the XCAP base spec by adding=20 > >>more features=20 > >>at this stage. > >> > >>- So this feature can be added as an advanced XCAP feature at=20 > >>a later stage. > >> > >>So far so good. At least I agree with the above. There is one=20 > >>bit where=20 > >>I don't quite agree: it seems that the position() opeator in XPath=20 > >>operates on the element level, meaning that if we have a=20 > >>non-flat list,=20 > >>the XCAP client will need to request ranges in each of the=20 > lists (see=20 > >>point 2 below). > >> > >>I think this is bad, and since we are going to design this extended=20 > >>feature, we should make it simple to use. > >> > >>First, if I have a device that can accommodate x entries, my=20 > >>XCAP client=20 > >>would need to request x entries for the first list, get the=20 > response=20 > >>(say y entries came), then do a new query requesting x-y=20 > >>entries in the=20 > >>next list, etc. Alternatively, my XCAP client can request x=20 > >>entries en=20 > >>each list, and perhaps I will get n * x entries (n is the=20 > >>number of lists). > >> > >>Second, this way of working assumes that I know in advance=20 > >>the number of=20 > >>lists that are nested. This assumption is false when I have never=20 > >>downloaded the XML document (such as when I start using a=20 > new device). > >> > >>In short: I want to have the means in XCAP to indicate:=20 > >>"please send me=20 > >>this XML document with range of x to z entries, and send them=20 > >>to me in a=20 > >>valid XML document". I don't need to know the structure of=20 > >>the document=20 > >>in advance (how many deep nested lists and their names),=20 > >>although I know=20 > >>the XML schema of the document. > >> > >>Is this something we can agree upon? > >> > >>- Miguel > >> > >>Jonathan Rosenberg wrote: > >> > >> > >>>inline. > >>> > >>>Miguel Garcia wrote: > >>> > >>> > >>>>>XCAP doesnt support that level of complexity in the=20 > server. If it=20 > >>>>>did, and you wanted protection against memory overload=20 > >> > >>(say, 1k max),=20 > >> > >>>>>you'd do something like this: > >>>>> > >>>>>GET http://server/blah-blah/list/buddy[position() > N and=20 > >> > >>position()=20 > >> > >>>>>< M] > >>>>>Range: bytes=3D0-1000 > >>>>> > >>>>>If the response is truncated, then you need to adjust=20 > >> > >>your pagination=20 > >> > >>>>>size on the client. > >>>>> > >>>>>-Jonathan R. > >>>>> > >>>> > >>>>I think this is going in the right direction now. So let me ask a=20 > >>>>couple of questions to verify that the position() is=20 > valid for the=20 > >>>>purpose we want. > >>>> > >>>>1) Is position already part of XCAP? By reading the XCAP=20 > >> > >>base document=20 > >> > >>>>I guess the answer is yes. > >>> > >>> > >>>No, it is not. I would not suggest putting this in the base=20 > >> > >>spec, which=20 > >> > >>>is already overdue and suffering feature creep. I have=20 > >> > >>suggested, in=20 > >> > >>>another thread, that we perhaps can have an "xcap advanced=20 > >> > >>operations"=20 > >> > >>>spec that extended xcap with new features, including multiple=20 > >>>insertions. This would possibly be a candidate feature for such an=20 > >>>extension, if the group decided to pursue that. > >>> > >>> > >>> > >>>>2) I guess if we have a non-flat list, the position element will=20 > >>>>operate in all the leaves of the XML document. For=20 > >> > >>instance, if we=20 > >> > >>>>have a resource list document, with several =20 > >> > >>elements, each one=20 > >> > >>>>containing a few elements, the position()=20 > >> > >>predicate executed=20 > >> > >>>>in the element will consider the element=20 > >> > >>sequentially=20 > >> > >>>>ordered. > >>> > >>> > >>>No. It would apply only at the specific place in the=20 > >> > >>hierarchy where it=20 > >> > >>>is placed. > >>> > >>> > >>>>Let me try to explain better with an example. Consider the=20 > >> > >>following=20 > >> > >>>>resource list XML document. > >>>> > >>>> >>>>subscribeable=3D"true"> > >>>> > >>>> Bill Doe > >>>> > >>>> > >>>> Johanna Doe > >>>> > >>>> >>>> subscribeable=3D"true"> > >>>> > >>>> Joe Smith > >>>> > >>>> > >>>> Nancy Gross > >>>> > >>>> > >>>> Peter Black > >>>> > >>>> =20 > >> > >>http://www.example.org/xcap/resource-lists/users/a/foo > >> > >>>> > >>>> > >>>> > >>>> > >>>>There are 5 elements, named Bill, Johanna, Joe, Nancy and=20 > >>>>Peter. Imagine I want entries 2 to 4 (in spite they span across=20 > >>>>different lists). Will the HTTP URI be something like: > >>>> > >>>>GET=20 > >>>> > >=20 > >=20 > http://server/blah-blah/resource-lists/users/jack/entry[position()>1=20 > >=20 > >>>and position()<5] > >> > >> > >>No, this will not work. I would suggest that, if you are=20 > worried about=20 > >>this, the client would page in each level of the hierarchy=20 > at a time. > >> > >> > >> > >>>3) I believe the HTTP byte ranges is a complement of this=20 > feature, a=20 > >>>kind of emergency life jacket that under normal=20 > circumstances will not=20 > >>>be use. I doubt an XCAP client can do much with an XML=20 > document that=20 > >>>is truncated by the byte ranges: it can just discard the=20 > contents or=20 > >>>store them (if it has enough memory) and request the rest of the=20 > >>>document. > >> > >> > >>Right. The problem Ranges solves is if a fixed memory is=20 > available in=20 > >>the device for the content, you can make sure that there is room to=20 > >>store the results. If the results are a truncated document,=20 > you would=20 > >>need to retry with a much smaller page size. > >> > >>-Jonathan R. > >> > >> > >=20 > >=20 >=20 > --=20 > Miguel A. Garcia tel:+358-50-4804586 > Nokia Research Center Helsinki, Finland >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Jul 6 08:23: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 IAA09380 for ; Tue, 6 Jul 2004 08:23: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 1Bhoyu-0001p6-NI for simple-archive@ietf.org; Tue, 06 Jul 2004 08:23:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bhoy0-0001Ry-00 for simple-archive@ietf.org; Tue, 06 Jul 2004 08:22:33 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bhox5-0000jG-00; Tue, 06 Jul 2004 08:21:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BhobN-0007Pq-CC; Tue, 06 Jul 2004 07:59:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BhoO2-00066E-Ov for simple@megatron.ietf.org; Tue, 06 Jul 2004 07:45: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 HAA07544 for ; Tue, 6 Jul 2004 07:45: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 1BhoNx-0004jA-8N for simple@ietf.org; Tue, 06 Jul 2004 07:45:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BhoMy-0004PN-00 for simple@ietf.org; Tue, 06 Jul 2004 07:44:18 -0400 Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx with esmtp (Exim 4.12) id 1BhoM5-0003ny-00 for simple@ietf.org; Tue, 06 Jul 2004 07:43:21 -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 i66Bgqou001432; Tue, 6 Jul 2004 06:42:52 -0500 (CDT) Received: by eamrcnt750.exu.ericsson.se with Internet Mail Service (5.5.2657.72) id <3J94TS1W>; Tue, 6 Jul 2004 06:41:42 -0500 Message-ID: From: "George Foti (QA/EMC)" To: "'hisham.khartabil@nokia.com'" , Miguel.An.Garcia@nokia.com Subject: RE: [Simple] RE: XCAP Directory: Large response ? Date: Tue, 6 Jul 2004 06:33:36 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" 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.1 required=5.0 tests=AWL autolearn=no version=2.60 Hisham, you are assuming that the user remembers the list names, etc.. How realistic is that ?? Rgds/gf > -----Original Message----- > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > Sent: Tuesday, July 06, 2004 7:39 AM > To: Miguel.An.Garcia@nokia.com > Cc: jdrosen@dynamicsoft.com; George Foti (QA/EMC); simple@ietf.org > Subject: RE: [Simple] RE: XCAP Directory: Large response ? > > > I think extending XCAP to enable this feature is limiting and > only works for XCAP. A better solution would be to create a > general HTTP solution. > > I acknowledge that the filter stuff as it is defined now does > not allow you to do what you want, but we can extend it in a > similar way Jonathan proposed to extend XCAP. I.e. Allow the > filter to carry the position() function. The example I gave > therefore becomes: > > GET ... > > > > > > > > //resource-lists/list[@name="friends"]/entry[position() > N > and position() < M] > > > > > > Regards, > Hisham > > > -----Original Message----- > > From: Miguel Garcia [mailto:Miguel.An.Garcia@nokia.com] > > Sent: 06.July.2004 13:51 > > To: Khartabil Hisham (Nokia-TP-MSW/Helsinki) > > Cc: Jonathan Rosenberg; George Foti (QA/EMC); simple@ietf.org > > Subject: Re: [Simple] RE: XCAP Directory: Large response ? > > > > > > Well, the benefit is clear to me. Let's assume you can > > accommodate 100 > > resources in a device. You get resources 1-100, do some xcap > > operation > > (add, delete, modify), then you can release your memory and get > > resources 101-200, and so on. > > > > Think for a second that this is something similar to browsing your > > e-mails through a web interface. All the applications I am aware of > > allow you to do some pagination. They return a valid HTML > code with a > > range of messages of your inbox. The key feature is to avoid > > flood your > > browser and get the user bored scrolling down over 1000 messages. > > > > - Miguel > > > > Khartabil Hisham (Nokia-TP-MSW/Helsinki) wrote: > > > > > I really wonder what the benefit is from such feature. If > > there are 1000 resources in a resource list and I can only > > fit 100 due to memory limitations in my device. What would it > > mean for me to get the first 100, the 2nd 100 or the > > resources between 500 and 599? > > > > > > I would rather prefer a feature where I can select the > > resources I want to get, if they are indeed on the list. > > That's why I was suggestion an event-filter like approach we > > I select the resources explicitly. > > > > > > I gave an example on this in a separate thread, but I copy > > it again here: > > > > > > GET ... > > > > > > > > > > > > > > > > > > > > > > > > //resource-lists/list[@name="friends"]/entry[@uri=""bob@example.com"] > > > > > > > > > > > //resource-lists/list[@name="friends"]/entry[@uri=""alice@exam > > ple.com"] > > > > > > > > > > > > > > > > > > > > > So a filter is used to GET the resources a client is > > interested in, if they are present on the list. > > > > > > /Hisham > > > > > > > > >>-----Original Message----- > > >>From: simple-bounces@ietf.org > > >>[mailto:simple-bounces@ietf.org]On Behalf > > >>Of ext Miguel Garcia > > >>Sent: 06.July.2004 10:16 > > >>To: Jonathan Rosenberg > > >>Cc: George Foti (QA/EMC); simple@ietf.org > > >>Subject: Re: [Simple] RE: XCAP Directory: Large response ? > > >> > > >> > > >>Summary of the thread: > > >> > > >>- I think we have consensus on adding a feature that > allows an XCAP > > >>client to request a range of XML elements in a particular schema. > > >> > > >>- It seems that the HTP Range header does not serve for the > > purpose, > > >>since it operates on bytes and will most likely truncate XML > > >>documents. > > >> > > >>- It seems that the XPath position() operator will almost > > >>serve, but it > > >>is not part of the XCAP base specification. > > >> > > >>- And we don't want to delay the XCAP base spec by adding > > >>more features > > >>at this stage. > > >> > > >>- So this feature can be added as an advanced XCAP feature at > > >>a later stage. > > >> > > >>So far so good. At least I agree with the above. There is one > > >>bit where > > >>I don't quite agree: it seems that the position() opeator > in XPath > > >>operates on the element level, meaning that if we have a > > >>non-flat list, > > >>the XCAP client will need to request ranges in each of the > > lists (see > > >>point 2 below). > > >> > > >>I think this is bad, and since we are going to design > this extended > > >>feature, we should make it simple to use. > > >> > > >>First, if I have a device that can accommodate x entries, my > > >>XCAP client > > >>would need to request x entries for the first list, get the > > response > > >>(say y entries came), then do a new query requesting x-y > > >>entries in the > > >>next list, etc. Alternatively, my XCAP client can request x > > >>entries en > > >>each list, and perhaps I will get n * x entries (n is the > > >>number of lists). > > >> > > >>Second, this way of working assumes that I know in advance > > >>the number of > > >>lists that are nested. This assumption is false when I have never > > >>downloaded the XML document (such as when I start using a > > new device). > > >> > > >>In short: I want to have the means in XCAP to indicate: > > >>"please send me > > >>this XML document with range of x to z entries, and send them > > >>to me in a > > >>valid XML document". I don't need to know the structure of > > >>the document > > >>in advance (how many deep nested lists and their names), > > >>although I know > > >>the XML schema of the document. > > >> > > >>Is this something we can agree upon? > > >> > > >>- Miguel > > >> > > >>Jonathan Rosenberg wrote: > > >> > > >> > > >>>inline. > > >>> > > >>>Miguel Garcia wrote: > > >>> > > >>> > > >>>>>XCAP doesnt support that level of complexity in the > > server. If it > > >>>>>did, and you wanted protection against memory overload > > >> > > >>(say, 1k max), > > >> > > >>>>>you'd do something like this: > > >>>>> > > >>>>>GET http://server/blah-blah/list/buddy[position() > N and > > >> > > >>position() > > >> > > >>>>>< M] > > >>>>>Range: bytes=0-1000 > > >>>>> > > >>>>>If the response is truncated, then you need to adjust > > >> > > >>your pagination > > >> > > >>>>>size on the client. > > >>>>> > > >>>>>-Jonathan R. > > >>>>> > > >>>> > > >>>>I think this is going in the right direction now. So > let me ask a > > >>>>couple of questions to verify that the position() is > > valid for the > > >>>>purpose we want. > > >>>> > > >>>>1) Is position already part of XCAP? By reading the XCAP > > >> > > >>base document > > >> > > >>>>I guess the answer is yes. > > >>> > > >>> > > >>>No, it is not. I would not suggest putting this in the base > > >> > > >>spec, which > > >> > > >>>is already overdue and suffering feature creep. I have > > >> > > >>suggested, in > > >> > > >>>another thread, that we perhaps can have an "xcap advanced > > >> > > >>operations" > > >> > > >>>spec that extended xcap with new features, including multiple > > >>>insertions. This would possibly be a candidate feature > for such an > > >>>extension, if the group decided to pursue that. > > >>> > > >>> > > >>> > > >>>>2) I guess if we have a non-flat list, the position > element will > > >>>>operate in all the leaves of the XML document. For > > >> > > >>instance, if we > > >> > > >>>>have a resource list document, with several > > >> > > >>elements, each one > > >> > > >>>>containing a few elements, the position() > > >> > > >>predicate executed > > >> > > >>>>in the element will consider the element > > >> > > >>sequentially > > >> > > >>>>ordered. > > >>> > > >>> > > >>>No. It would apply only at the specific place in the > > >> > > >>hierarchy where it > > >> > > >>>is placed. > > >>> > > >>> > > >>>>Let me try to explain better with an example. Consider the > > >> > > >>following > > >> > > >>>>resource list XML document. > > >>>> > > >>>> > >>>>subscribeable="true"> > > >>>> > > >>>> Bill Doe > > >>>> > > >>>> > > >>>> Johanna Doe > > >>>> > > >>>> uri="sip:close-friends@example.com" > > >>>> subscribeable="true"> > > >>>> > > >>>> Joe Smith > > >>>> > > >>>> > > >>>> Nancy Gross > > >>>> > > >>>> > > >>>> Peter Black > > >>>> > > >>>> > > >> > > >>http://www.example.org/xcap/resource-lists/users/a/foo > > >> > > >>>> > > >>>> > > >>>> > > >>>> > > >>>>There are 5 elements, named Bill, Johanna, Joe, > Nancy and > > >>>>Peter. Imagine I want entries 2 to 4 (in spite they span across > > >>>>different lists). Will the HTTP URI be something like: > > >>>> > > >>>>GET > > >>>> > > > > > > > > > http://server/blah-blah/resource-lists/users/jack/entry[position()>1 > > > > > >>>and position()<5] > > >> > > >> > > >>No, this will not work. I would suggest that, if you are > > worried about > > >>this, the client would page in each level of the hierarchy > > at a time. > > >> > > >> > > >> > > >>>3) I believe the HTTP byte ranges is a complement of this > > feature, a > > >>>kind of emergency life jacket that under normal > > circumstances will not > > >>>be use. I doubt an XCAP client can do much with an XML > > document that > > >>>is truncated by the byte ranges: it can just discard the > > contents or > > >>>store them (if it has enough memory) and request the rest of the > > >>>document. > > >> > > >> > > >>Right. The problem Ranges solves is if a fixed memory is > > available in > > >>the device for the content, you can make sure that there > is room to > > >>store the results. If the results are a truncated document, > > you would > > >>need to retry with a much smaller page size. > > >> > > >>-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 Tue Jul 6 08:38: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 IAA10590 for ; Tue, 6 Jul 2004 08:38: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 1BhpDW-0006Zc-F1 for simple-archive@ietf.org; Tue, 06 Jul 2004 08:38:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BhpCQ-0006EG-00 for simple-archive@ietf.org; Tue, 06 Jul 2004 08:37:26 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BhpBY-0005Zs-00; Tue, 06 Jul 2004 08:36:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BhojG-0008HR-QI; Tue, 06 Jul 2004 08:07:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BhoTz-0006nz-F7 for simple@megatron.ietf.org; Tue, 06 Jul 2004 07: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 HAA07828 for ; Tue, 6 Jul 2004 07:51:25 -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 1BhoTt-0006jh-VX for simple@ietf.org; Tue, 06 Jul 2004 07:51:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BhoSx-0006Pj-00 for simple@ietf.org; Tue, 06 Jul 2004 07:50:28 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1BhoSZ-000662-00 for simple@ietf.org; Tue, 06 Jul 2004 07:50:03 -0400 Received: from hydra.cs.columbia.edu (IDENT:fGMDWUakoYA0l14i8GcWq8lO1e4p7g11@hydra.cs.columbia.edu [128.59.16.129]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i66Bo0fq028079 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Tue, 6 Jul 2004 07:50:01 -0400 (EDT) Received: from webmail.cs.columbia.edu (IDENT:5P4xxFd9LzcJHUBiMpYy5RYav+Ig0Ez1@localhost [127.0.0.1]) by hydra.cs.columbia.edu (8.12.10/8.12.10) with SMTP id i66Bo0Xt031041 for ; Tue, 6 Jul 2004 07:50:00 -0400 Received: from 212.119.9.178 (SquirrelMail authenticated user hgs) by webmail.cs.columbia.edu with HTTP; Tue, 6 Jul 2004 07:50:00 -0400 (EDT) Message-ID: <57984.212.119.9.178.1089114600.squirrel@webmail.cs.columbia.edu> Date: Tue, 6 Jul 2004 07:50:00 -0400 (EDT) To: simple@ietf.org 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.7.5.105974 X-PerlMx-Spam: Gauge=X, Probability=10%, Report='PRIORITY_NO_NAME 0.716, __SANE_MSGID 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, __MIME_TEXT_ONLY 0, __HAS_MSGID 0, USER_AGENT 0.000' Content-Transfer-Encoding: 8bit Subject: [Simple] CIPID WGLC summary X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.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 My thanks to all the WG members that took time to read the CIPID draft. As reflected in the soon-to-be-appearing draft-ietf-simple-cipid-03, the following changes of a non-editorial nature were made: - Specify for all elements which types receivers should support. - Add a security consideration paragraph about covert channels. I believe all open issues have been closed. Henning _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Jul 6 08:41: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 IAA10833 for ; Tue, 6 Jul 2004 08:41: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 1BhpGV-0007dc-PV for simple-archive@ietf.org; Tue, 06 Jul 2004 08:41:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BhpFc-0007Hq-00 for simple-archive@ietf.org; Tue, 06 Jul 2004 08:40:45 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BhpEq-0006ug-00; Tue, 06 Jul 2004 08:39:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bhosa-0000tr-4U; Tue, 06 Jul 2004 08:16:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BhoYv-0007Do-Jn for simple@megatron.ietf.org; Tue, 06 Jul 2004 07:56: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 HAA08272 for ; Tue, 6 Jul 2004 07: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 1BhoYp-0000kz-WB for simple@ietf.org; Tue, 06 Jul 2004 07:56:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BhoY2-0000Qe-00 for simple@ietf.org; Tue, 06 Jul 2004 07:55:43 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BhoX6-00006e-00 for simple@ietf.org; Tue, 06 Jul 2004 07:54:44 -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 i66BsPN22598; Tue, 6 Jul 2004 14:54:25 +0300 (EET DST) X-Scanned: Tue, 6 Jul 2004 14:54:17 +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 i66BsHdn005466; Tue, 6 Jul 2004 14:54:17 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00CpJ2qg; Tue, 06 Jul 2004 14:54:16 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 i66BsBH21127; Tue, 6 Jul 2004 14:54:11 +0300 (EET DST) Received: from nokia.com ([172.21.42.108]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 6 Jul 2004 14:54:08 +0300 Message-ID: <40EA92DF.6010105@nokia.com> Date: Tue, 06 Jul 2004 14:54:07 +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: "Khartabil Hisham (Nokia-TP-MSW/Helsinki)" Subject: Re: [Simple] RE: XCAP Directory: Large response ? References: <2038BCC78B1AD641891A0D1AE133DBB7023EEAB7@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB7023EEAB7@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Jul 2004 11:54:08.0463 (UTC) FILETIME=[F1DDD5F0:01C4634F] Content-Transfer-Encoding: 7bit Cc: "George Foti \(QA/EMC\)" , Jonathan Rosenberg , 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 Hisham: I agree that the filter function could be extended, but I doubt it could be generally be useful for HTTP, since it requires the document to be written in XML. At the end of the day, it is the same to carry a filter that indicates how many entries should be return, than carrying the request itself in the URI as a position predicate. Honestly, I think it is simpler to use the position predicate in the URI than all the burden of a filter criteria document. Don't missinterpret me. Filters are important for long lived SIP subscriptions, but I don't see the point in every HTTP (XCAP) request carring a filter criteria document to be applied to the response. - Miguel Khartabil Hisham (Nokia-TP-MSW/Helsinki) wrote: > I think extending XCAP to enable this feature is limiting and only works for XCAP. A better solution would be to create a general HTTP solution. > > I acknowledge that the filter stuff as it is defined now does not allow you to do what you want, but we can extend it in a similar way Jonathan proposed to extend XCAP. I.e. Allow the filter to carry the position() function. The example I gave therefore becomes: > > GET ... > > > > > > > //resource-lists/list[@name="friends"]/entry[position() > N and position() < M] > > > > > > Regards, > Hisham > > >>-----Original Message----- >>From: Miguel Garcia [mailto:Miguel.An.Garcia@nokia.com] >>Sent: 06.July.2004 13:51 >>To: Khartabil Hisham (Nokia-TP-MSW/Helsinki) >>Cc: Jonathan Rosenberg; George Foti (QA/EMC); simple@ietf.org >>Subject: Re: [Simple] RE: XCAP Directory: Large response ? >> >> >>Well, the benefit is clear to me. Let's assume you can >>accommodate 100 >>resources in a device. You get resources 1-100, do some xcap >>operation >>(add, delete, modify), then you can release your memory and get >>resources 101-200, and so on. >> >>Think for a second that this is something similar to browsing your >>e-mails through a web interface. All the applications I am aware of >>allow you to do some pagination. They return a valid HTML code with a >>range of messages of your inbox. The key feature is to avoid >>flood your >>browser and get the user bored scrolling down over 1000 messages. >> >>- Miguel >> >>Khartabil Hisham (Nokia-TP-MSW/Helsinki) wrote: >> >> >>>I really wonder what the benefit is from such feature. If >> >>there are 1000 resources in a resource list and I can only >>fit 100 due to memory limitations in my device. What would it >>mean for me to get the first 100, the 2nd 100 or the >>resources between 500 and 599? >> >>>I would rather prefer a feature where I can select the >> >>resources I want to get, if they are indeed on the list. >>That's why I was suggestion an event-filter like approach we >>I select the resources explicitly. >> >>>I gave an example on this in a separate thread, but I copy >> >>it again here: >> >>> GET ... >>> >>> >>> >>> >>> >>> >>> >> >>//resource-lists/list[@name="friends"]/entry[@uri=""bob@example.com"] >> >>> >>> >>> >> >>//resource-lists/list[@name="friends"]/entry[@uri=""alice@exam >>ple.com"] >> >>> >>> >>> >>> >>> >>> >>>So a filter is used to GET the resources a client is >> >>interested in, if they are present on the list. >> >>>/Hisham >>> >>> >>> >>>>-----Original Message----- >>>>From: simple-bounces@ietf.org >>>>[mailto:simple-bounces@ietf.org]On Behalf >>>>Of ext Miguel Garcia >>>>Sent: 06.July.2004 10:16 >>>>To: Jonathan Rosenberg >>>>Cc: George Foti (QA/EMC); simple@ietf.org >>>>Subject: Re: [Simple] RE: XCAP Directory: Large response ? >>>> >>>> >>>>Summary of the thread: >>>> >>>>- I think we have consensus on adding a feature that allows an XCAP >>>>client to request a range of XML elements in a particular schema. >>>> >>>>- It seems that the HTP Range header does not serve for the >> >>purpose, >> >>>>since it operates on bytes and will most likely truncate XML >>>>documents. >>>> >>>>- It seems that the XPath position() operator will almost >>>>serve, but it >>>>is not part of the XCAP base specification. >>>> >>>>- And we don't want to delay the XCAP base spec by adding >>>>more features >>>>at this stage. >>>> >>>>- So this feature can be added as an advanced XCAP feature at >>>>a later stage. >>>> >>>>So far so good. At least I agree with the above. There is one >>>>bit where >>>>I don't quite agree: it seems that the position() opeator in XPath >>>>operates on the element level, meaning that if we have a >>>>non-flat list, >>>>the XCAP client will need to request ranges in each of the >> >>lists (see >> >>>>point 2 below). >>>> >>>>I think this is bad, and since we are going to design this extended >>>>feature, we should make it simple to use. >>>> >>>>First, if I have a device that can accommodate x entries, my >>>>XCAP client >>>>would need to request x entries for the first list, get the >> >>response >> >>>>(say y entries came), then do a new query requesting x-y >>>>entries in the >>>>next list, etc. Alternatively, my XCAP client can request x >>>>entries en >>>>each list, and perhaps I will get n * x entries (n is the >>>>number of lists). >>>> >>>>Second, this way of working assumes that I know in advance >>>>the number of >>>>lists that are nested. This assumption is false when I have never >>>>downloaded the XML document (such as when I start using a >> >>new device). >> >>>>In short: I want to have the means in XCAP to indicate: >>>>"please send me >>>>this XML document with range of x to z entries, and send them >>>>to me in a >>>>valid XML document". I don't need to know the structure of >>>>the document >>>>in advance (how many deep nested lists and their names), >>>>although I know >>>>the XML schema of the document. >>>> >>>>Is this something we can agree upon? >>>> >>>>- Miguel >>>> >>>>Jonathan Rosenberg wrote: >>>> >>>> >>>> >>>>>inline. >>>>> >>>>>Miguel Garcia wrote: >>>>> >>>>> >>>>> >>>>>>>XCAP doesnt support that level of complexity in the >> >>server. If it >> >>>>>>>did, and you wanted protection against memory overload >>>> >>>>(say, 1k max), >>>> >>>> >>>>>>>you'd do something like this: >>>>>>> >>>>>>>GET http://server/blah-blah/list/buddy[position() > N and >>>> >>>>position() >>>> >>>> >>>>>>>< M] >>>>>>>Range: bytes=0-1000 >>>>>>> >>>>>>>If the response is truncated, then you need to adjust >>>> >>>>your pagination >>>> >>>> >>>>>>>size on the client. >>>>>>> >>>>>>>-Jonathan R. >>>>>>> >>>>>> >>>>>>I think this is going in the right direction now. So let me ask a >>>>>>couple of questions to verify that the position() is >> >>valid for the >> >>>>>>purpose we want. >>>>>> >>>>>>1) Is position already part of XCAP? By reading the XCAP >>>> >>>>base document >>>> >>>> >>>>>>I guess the answer is yes. >>>>> >>>>> >>>>>No, it is not. I would not suggest putting this in the base >>>> >>>>spec, which >>>> >>>> >>>>>is already overdue and suffering feature creep. I have >>>> >>>>suggested, in >>>> >>>> >>>>>another thread, that we perhaps can have an "xcap advanced >>>> >>>>operations" >>>> >>>> >>>>>spec that extended xcap with new features, including multiple >>>>>insertions. This would possibly be a candidate feature for such an >>>>>extension, if the group decided to pursue that. >>>>> >>>>> >>>>> >>>>> >>>>>>2) I guess if we have a non-flat list, the position element will >>>>>>operate in all the leaves of the XML document. For >>>> >>>>instance, if we >>>> >>>> >>>>>>have a resource list document, with several >>>> >>>>elements, each one >>>> >>>> >>>>>>containing a few elements, the position() >>>> >>>>predicate executed >>>> >>>> >>>>>>in the element will consider the element >>>> >>>>sequentially >>>> >>>> >>>>>>ordered. >>>>> >>>>> >>>>>No. It would apply only at the specific place in the >>>> >>>>hierarchy where it >>>> >>>> >>>>>is placed. >>>>> >>>>> >>>>> >>>>>>Let me try to explain better with an example. Consider the >>>> >>>>following >>>> >>>> >>>>>>resource list XML document. >>>>>> >>>>>> >>>>>subscribeable="true"> >>>>>> >>>>>> Bill Doe >>>>>> >>>>>> >>>>>> Johanna Doe >>>>>> >>>>>> >>>>> subscribeable="true"> >>>>>> >>>>>> Joe Smith >>>>>> >>>>>> >>>>>> Nancy Gross >>>>>> >>>>>> >>>>>> Peter Black >>>>>> >>>>>> >>>> >>>>http://www.example.org/xcap/resource-lists/users/a/foo >>>> >>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>There are 5 elements, named Bill, Johanna, Joe, Nancy and >>>>>>Peter. Imagine I want entries 2 to 4 (in spite they span across >>>>>>different lists). Will the HTTP URI be something like: >>>>>> >>>>>>GET >>>>>> >>> >>> >>http://server/blah-blah/resource-lists/users/jack/entry[position()>1 >> >>>>>and position()<5] >>>> >>>> >>>>No, this will not work. I would suggest that, if you are >> >>worried about >> >>>>this, the client would page in each level of the hierarchy >> >>at a time. >> >>>> >>>> >>>>>3) I believe the HTTP byte ranges is a complement of this >> >>feature, a >> >>>>>kind of emergency life jacket that under normal >> >>circumstances will not >> >>>>>be use. I doubt an XCAP client can do much with an XML >> >>document that >> >>>>>is truncated by the byte ranges: it can just discard the >> >>contents or >> >>>>>store them (if it has enough memory) and request the rest of the >>>>>document. >>>> >>>> >>>>Right. The problem Ranges solves is if a fixed memory is >> >>available in >> >>>>the device for the content, you can make sure that there is room to >>>>store the results. If the results are a truncated document, >> >>you would >> >>>>need to retry with a much smaller page size. >>>> >>>>-Jonathan R. >>>> >>>> >>> >>> >>-- >>Miguel A. Garcia tel:+358-50-4804586 >>Nokia Research Center Helsinki, Finland >> > > -- 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 Jul 6 08:59: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 IAA11763 for ; Tue, 6 Jul 2004 08:59: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 1BhpXM-0005lW-W5 for simple-archive@ietf.org; Tue, 06 Jul 2004 08:59:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BhpWC-0005Nl-00 for simple-archive@ietf.org; Tue, 06 Jul 2004 08:57:52 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BhpVV-00050C-00; Tue, 06 Jul 2004 08:57:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BhpBK-00039H-3Z; Tue, 06 Jul 2004 08:36:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BholX-0008OH-Qy for simple@megatron.ietf.org; Tue, 06 Jul 2004 08:09: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 IAA08789 for ; Tue, 6 Jul 2004 08:09:33 -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 1BholS-0004z2-88 for simple@ietf.org; Tue, 06 Jul 2004 08:09:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BhokS-0004fE-00 for simple@ietf.org; Tue, 06 Jul 2004 08:08:33 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1Bhojh-0004Kt-00 for simple@ietf.org; Tue, 06 Jul 2004 08:07:45 -0400 Received: from hydra.cs.columbia.edu (IDENT:hm/ji50G5wO9FjKgoCmvGjqEHbJZKP7/@hydra.cs.columbia.edu [128.59.16.129]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i66C7dfq001274 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Tue, 6 Jul 2004 08:07:39 -0400 (EDT) Received: from webmail.cs.columbia.edu (IDENT:RbYrLyDJtNx0tHcXsULhTZHnc29hp6qL@localhost [127.0.0.1]) by hydra.cs.columbia.edu (8.12.10/8.12.10) with SMTP id i66C7ZXt031076; Tue, 6 Jul 2004 08:07:39 -0400 Received: from 212.119.9.178 (SquirrelMail authenticated user hgs) by webmail.cs.columbia.edu with HTTP; Tue, 6 Jul 2004 08:07:39 -0400 (EDT) Message-ID: <58012.212.119.9.178.1089115659.squirrel@webmail.cs.columbia.edu> In-Reply-To: References: <40A7FA76.6070407@cs.columbia.edu> Date: Tue, 6 Jul 2004 08:07:39 -0400 (EDT) Subject: Re: [Simple] WGLC on future status To: yannis.pavlidis@openwave.com 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.7.5.105974 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, __CHILD_PORN_NOT_1 0, __C230066_P5 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 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.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 > Hi, > > Some comments on the > http://www.cs.columbia.edu/sip/draft/timed-status/draft-ietf-simple-future-0 > 2.txt. > > 1. The element MUST be qualified with the 'from' > attribute and MAY be qualified with an 'until' attribute to describe > the time when the status assumed this value and the time until which > this element is expected to be valid. > > a. What happens when I provide a 'from' attribute but not an 'until' > attribute? Is the status, note or other presence included in the > element that I published valid for ever (until I publish > something else to overwrite it?) or is it valid until my publication > expires? > > It is not clear which are the semantics when the 'until' attribute is not > provided. Since tuples could be published without using PUBLISH, I don't think we can rely on any SIP-level expiration information. Rather, I think the information is valid until explicitly overridden (or, as noted, until the underlying publication mechanism removes it). This is no different from regular (non-timed) presence. I will clarify. > > b. What happens to the presence information included in the > element when the value of the "until" attribute exceeds the publication > expiration? If published using PUBLISH, the information would be removed, like all other such items ("soft state"). Do you think it would be helpful to call this out explicitly? > > c. Based on the above sentence I assume that the use of the 'from' > attribute > is required. This is not depicted in the XML Schema definition: > "". > > If my above statement is correct I suggest the addition of the > use="required" attribute in the XML Schema definition. Good idea; I'll add. > > Thanks, > > Yannis Pavlidis > Openwave Systems > yannis.pavlidis@openwave.com > +1-303 385 6695 > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Jul 6 09:01: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 JAA11961 for ; Tue, 6 Jul 2004 09:01: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 1BhpZb-0006s8-4U for simple-archive@ietf.org; Tue, 06 Jul 2004 09:01:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BhpYa-0006T9-00 for simple-archive@ietf.org; Tue, 06 Jul 2004 09:00:20 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BhpXT-0005ip-00; Tue, 06 Jul 2004 08:59:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BhpBc-0003Dq-1D; Tue, 06 Jul 2004 08:36:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BhoqA-0000VC-G0 for simple@megatron.ietf.org; Tue, 06 Jul 2004 08:14: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 IAA08919 for ; Tue, 6 Jul 2004 08:14:20 -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 1Bhoq4-0006Zn-UU for simple@ietf.org; Tue, 06 Jul 2004 08:14:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BhopC-0006GM-00 for simple@ietf.org; Tue, 06 Jul 2004 08:13:26 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1BhooS-0005x6-00 for simple@ietf.org; Tue, 06 Jul 2004 08:12:40 -0400 Received: from hydra.cs.columbia.edu (IDENT:2pSUn/L3TGK4NbuXP67+ws4fUFfE1C18@hydra.cs.columbia.edu [128.59.16.129]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i66CCafq002301 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Tue, 6 Jul 2004 08:12:36 -0400 (EDT) Received: from webmail.cs.columbia.edu (IDENT:Z3xw1l/2o3wyR7e1UqbkvFA+vPkTR3Ik@localhost [127.0.0.1]) by hydra.cs.columbia.edu (8.12.10/8.12.10) with SMTP id i66CCaXt031088 for ; Tue, 6 Jul 2004 08:12:36 -0400 Received: from 212.119.9.178 (SquirrelMail authenticated user hgs) by webmail.cs.columbia.edu with HTTP; Tue, 6 Jul 2004 08:12:36 -0400 (EDT) Message-ID: <58015.212.119.9.178.1089115956.squirrel@webmail.cs.columbia.edu> Date: Tue, 6 Jul 2004 08:12:36 -0400 (EDT) To: simple@ietf.org 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.7.5.105974 X-PerlMx-Spam: Gauge=X, Probability=10%, Report='PRIORITY_NO_NAME 0.716, __SANE_MSGID 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, __MIME_TEXT_ONLY 0, __HAS_MSGID 0, USER_AGENT 0.000' Content-Transfer-Encoding: 8bit Subject: [Simple] WGLC summary on timed-status 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: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.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=NO_REAL_NAME,PRIORITY_NO_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 8bit Thanks to the individuals that have provided feedback on the timed-status draft. All changes made could be considered editorial, but the more significant ones were: - clarification of where the timed-status element could appear - conversion of such elements into regular status if their time intervals overlap the - clarification on expiration behavior (see previous email) I will submit a revised (02) version that also incorporates the third item as soon as I'm back in ssh range. With those changes, I believe all LC comments to have been addressed and all open issues closed. Henning _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Jul 6 09:12: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 JAA12515 for ; Tue, 6 Jul 2004 09:12: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 1BhpkN-0002o0-5P for simple-archive@ietf.org; Tue, 06 Jul 2004 09:12:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BhpjQ-0002Tx-00 for simple-archive@ietf.org; Tue, 06 Jul 2004 09:11:33 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bhpiv-00028o-00; Tue, 06 Jul 2004 09:11:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BhpEg-0003fg-Th; Tue, 06 Jul 2004 08:39:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bhovv-0001Bs-Al for simple@megatron.ietf.org; Tue, 06 Jul 2004 08:20: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 IAA09133 for ; Tue, 6 Jul 2004 08:20: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 1Bhovp-0000hq-Mu for simple@ietf.org; Tue, 06 Jul 2004 08:20:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bhour-0000OV-00 for simple@ietf.org; Tue, 06 Jul 2004 08:19:17 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1Bhotp-0007gq-00 for simple@ietf.org; Tue, 06 Jul 2004 08:18:13 -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 i66CI9200545; Tue, 6 Jul 2004 15:18:09 +0300 (EET DST) X-Scanned: Tue, 6 Jul 2004 15:17:43 +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 i66CHhnt021932; Tue, 6 Jul 2004 15:17:43 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 00MlZRXu; Tue, 06 Jul 2004 15:17:39 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 i66CHcH06057; Tue, 6 Jul 2004 15:17:38 +0300 (EET DST) Received: from nokia.com ([172.21.42.108]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 6 Jul 2004 15:17:36 +0300 Message-ID: <40EA9860.6050409@nokia.com> Date: Tue, 06 Jul 2004 15:17:36 +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: "George Foti (QA/EMC)" Subject: Re: [Simple] What is an entrty was (RE: XCAP Directory: Large res ponse ?) References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Jul 2004 12:17:36.0848 (UTC) FILETIME=[39545500:01C46353] Content-Transfer-Encoding: 7bit Cc: Jonathan Rosenberg , 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 George Foti (QA/EMC) wrote: [snip] > > Miguel, I agree with you on that one. > But this is not the only assumption that needs to be stated. > Other assumptions. > The user does not in advance how may entries exist in the list in the first place. Is there a way for that information to be available. Otherwise, how would a user to know if he has all the list or not, or how many entires he should retrieve, etc... > I agree. [snip] > > > Now that makes me ask a second question. > What is an entry from a server point of view ? > Looking back at the example above. > If a user request 3 entries. > Does he get only 2 cause the thirs want is a list or ????? > I was always thinking of limiting the number of elements, but you are right, there could be a list containing a huge number of elements... Hmmm.... At least this problem is only present in the presence lists, but not in the XCAP directory (since it is a flat document). The possible solutions range: 1) I don't care about the problem, limit only the number of elements 2) Limit both, and , but independently of each other. 3) Make a joint limit (or range) for both and 2 has problems, like if I limit each of and to 50 elements, I may get up to 100 entries, but it is simple for both the client and the server. 3 is the desired solution, but I am not sure on the complexities of the design of such alternative. I guess we need to give it a thought. - Miguel > Rgds/gf -- 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 Jul 6 13: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 NAA05914 for ; Tue, 6 Jul 2004 13: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 1Bhtxg-00001r-QW for simple-archive@ietf.org; Tue, 06 Jul 2004 13:42:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bhtwi-0007S0-00 for simple-archive@ietf.org; Tue, 06 Jul 2004 13:41:33 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bhtvi-0006me-00; Tue, 06 Jul 2004 13:40:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bht9H-00018W-Ns; Tue, 06 Jul 2004 12:50:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BhrUp-0005Nw-15 for simple@megatron.ietf.org; Tue, 06 Jul 2004 11: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 LAA21856 for ; Tue, 6 Jul 2004 11: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 1BhrUj-0002PP-8O for simple@ietf.org; Tue, 06 Jul 2004 11:04:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BhrTi-00022q-00 for simple@ietf.org; Tue, 06 Jul 2004 11:03:27 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BhrSe-0001OA-00 for simple@ietf.org; Tue, 06 Jul 2004 11:02: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 i66F1lLp009414; Tue, 6 Jul 2004 10:01:48 -0500 Message-ID: <40EABEDC.1010005@dynamicsoft.com> Date: Tue, 06 Jul 2004 10:01:48 -0500 From: Ben Campbell User-Agent: Mozilla Thunderbird 0.7 (Macintosh/20040616) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Drage, Keith (Keith)" , Hisham Khartabil , Robert Sparks Subject: Re: [Simple] Re: MSRP: Max message size indication References: <475FF955A05DD411980D00508B6D5FB00C290142@en0033exch001u.uk.lucent.com> In-Reply-To: <475FF955A05DD411980D00508B6D5FB00C290142@en0033exch001u.uk.lucent.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 dyn-tx-arch-crash.dfw.dynamicsoft.com id i66F1lLp009414 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 Hi Keith, I am sensitive to your concern, and my initial position was to push back=20 on _any_ new MSRP features at this time. You are correct, the votes were=20 about even from the people who responded. I pretty much gave in to the feature because it is fairly trivial to=20 specify, doesn't appear to break anything, and it began to look like=20 less work to add it than to argue about it. Its presence in Jonathan's=20 Advanced Messaging Requirements document gave some weight to the=20 argument to put it in. We can discuss whether that document is=20 authoritative, but that gives us even more time spent arguing. So, perhaps the chairs would like to assert a final opinion on the=20 consensus about this item? Drage, Keith (Keith) wrote: > Having reread the entire thread, the only winner I have seen in this vo= te is Christer Holmberg for the sheer number of messages sent. If that is= the criteria that is being used for decision, then you should have made = this clear at the beginning. What I do see from the list is that the bala= nce of the votes was pretty even, even on the send capability. I do not c= all that rough working consensus. >=20 > What I am seeing here is feature creep. People are justifying their arg= uments on the basis that it does not take much time to add a particular f= eature, therefore lets add it. What this means is that this continues to = happen and we never get the deliverable out of the door. >=20 > We saw it happen in SIP, we are seeing it happen in sdp-new, and we are= seeing it happen now in XCAP as well. >=20 > MSRP is needed pretty damn soon. >=20 > Can we please stop the feature creep and deliver what is already in the= document, and deal with other stuff as extensions. >=20 > regards >=20 > Keith Drage >=20 >=20 >=20 >>-----Original Message----- >>From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] >>Sent: 28 June 2004 20:57 >>To: Christer Holmberg (JO/LMF) >>Cc: Adam Roach; simple@ietf.org; 'hisham.khartabil@nokia.com'; 'Paul >>Kyzivat'; alex.audu@alcatel.com; cboulton@ubiquity.com >>Subject: Re: [Simple] Re: MSRP: Max message size indication >> >> >>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, >>> >>>So, do we have some kind of conclusion on this? >>> >>>Some people have asked for use-cases, and scenarios where=20 >> >>this can be useful, and I think a number of those have now=20 >>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 >>>> >>>> >>>> >>>> >>>>Alex Audu wrote: >>>> >>>> >>>>>I think there is great value in end-point being able to=20 >> >>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=20 >> >>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 >> _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Jul 6 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 NAA06964 for ; Tue, 6 Jul 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 1Bhu8L-00049f-NY for simple-archive@ietf.org; Tue, 06 Jul 2004 13:53:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bhu6o-0003SQ-00 for simple-archive@ietf.org; Tue, 06 Jul 2004 13:52:00 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bhu5O-0002g3-00; Tue, 06 Jul 2004 13:50:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BhtEe-00020B-2a; Tue, 06 Jul 2004 12:56:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BhrlQ-00006W-Im for simple@megatron.ietf.org; Tue, 06 Jul 2004 11:21: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 LAA22663 for ; Tue, 6 Jul 2004 11: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 1BhrlA-00008m-Mj for simple@ietf.org; Tue, 06 Jul 2004 11:21:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BhrkE-0007ca-00 for simple@ietf.org; Tue, 06 Jul 2004 11:20:31 -0400 Received: from ns.execdsl.net ([208.184.15.238] helo=EXECDSL.COM) by ietf-mx with esmtp (Exim 4.12) id 1BhrjU-0007Je-00 for simple@ietf.org; Tue, 06 Jul 2004 11:19:44 -0400 Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 7166044; Tue, 06 Jul 2004 11:19:32 -0400 Message-Id: <5.1.0.14.0.20040706111036.023f5320@localhost> X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 06 Jul 2004 11:19:21 -0400 To: Miguel Garcia From: "Joel M. Halpern" Subject: Re: [Simple] RE: XCAP Directory: Large response ? In-Reply-To: <40EA519D.7050708@nokia.com> References: <40EA0018.3080408@dynamicsoft.com> <40E5C2E1.50502@dynamicsoft.com> <40E903D2.2050703@nokia.com> <40EA0018.3080408@dynamicsoft.com> Mime-Version: 1.0 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 I rather disagree with your summary. 1) I am not at all convinced this is necessary, 1') The way you are defining the problem, I am not at all convinced it is achievable. 2) I do not think we have anything like a rough consensus on whether this is ended, but rather an interesting discussion on possible requirements and possible ways to meet it. The chairs may have observed a consensus, I suppose. As far as I can tell, requesting x elements of a certain type, from a certain point in the XML document, tells you almost nothing about how much information you are getting. If the elements are leaf elements, they may contain large or small amounts of content. If they are not leaf elements, then how many contained elements there are depends upon the schema, whether the nested elements are optional and / or may occur multiple times, etc. And if you try to say "I want X elements, just start counting from the starting point." then there is no way that the result can confidently be a valid XML document or meaningful portion of a document according to a schema. It will take some interesting work to even make it well-formed XML under that constraint. Now, if we add the filter definition Hisham has suggested, we at least have a behaviors that is well defined and can produce meaningful results. It even matches a useful and understandable problem. However, it is a big change in the semantics of HTTP GET as far as I can tell. It starts falling into the trap of using HTTP as a generic transport. Will it work through relays? It seems to me that byte ranges are already there and already give control at a level that corresponds to real limits on real clients. It may be hard to construct what you need from it, but it matches the "I only have Y buffer space available" constraint. If we really need to solve this problem over and above that, I guess I would prefer to explore whether the suggestion of Filters on GET is valid and workable. Yours, Joel M. Halpern At 10:15 AM 7/6/2004 +0300, Miguel Garcia wrote: >Summary of the thread: > >- I think we have consensus on adding a feature that allows an XCAP client >to request a range of XML elements in a particular schema. > >- It seems that the HTP Range header does not serve for the purpose, since >it operates on bytes and will most likely truncate XML documents. > >- It seems that the XPath position() operator will almost serve, but it is >not part of the XCAP base specification. > >- And we don't want to delay the XCAP base spec by adding more features at >this stage. > >- So this feature can be added as an advanced XCAP feature at a later stage. > >So far so good. At least I agree with the above. There is one bit where I >don't quite agree: it seems that the position() opeator in XPath operates >on the element level, meaning that if we have a non-flat list, the XCAP >client will need to request ranges in each of the lists (see point 2 below). > >I think this is bad, and since we are going to design this extended >feature, we should make it simple to use. > >First, if I have a device that can accommodate x entries, my XCAP client >would need to request x entries for the first list, get the response (say >y entries came), then do a new query requesting x-y entries in the next >list, etc. Alternatively, my XCAP client can request x entries en each >list, and perhaps I will get n * x entries (n is the number of lists). > >Second, this way of working assumes that I know in advance the number of >lists that are nested. This assumption is false when I have never >downloaded the XML document (such as when I start using a new device). > >In short: I want to have the means in XCAP to indicate: "please send me >this XML document with range of x to z entries, and send them to me in a >valid XML document". I don't need to know the structure of the document in >advance (how many deep nested lists and their names), although I know the >XML schema of the document. > >Is this something we can agree upon? > >- Miguel > >Jonathan Rosenberg wrote: > >>inline. >>Miguel Garcia wrote: >> >>>>XCAP doesnt support that level of complexity in the server. If it did, >>>>and you wanted protection against memory overload (say, 1k max), you'd >>>>do something like this: >>>> >>>>GET http://server/blah-blah/list/buddy[position() > N and position() < M] >>>>Range: bytes=0-1000 >>>> >>>>If the response is truncated, then you need to adjust your pagination >>>>size on the client. >>>> >>>>-Jonathan R. >>> >>>I think this is going in the right direction now. So let me ask a couple >>>of questions to verify that the position() is valid for the purpose we want. >>> >>>1) Is position already part of XCAP? By reading the XCAP base document I >>>guess the answer is yes. >> >>No, it is not. I would not suggest putting this in the base spec, which >>is already overdue and suffering feature creep. I have suggested, in >>another thread, that we perhaps can have an "xcap advanced operations" >>spec that extended xcap with new features, including multiple insertions. >>This would possibly be a candidate feature for such an extension, if the >>group decided to pursue that. >> >>> >>>2) I guess if we have a non-flat list, the position element will >>>operate in all the leaves of the XML document. For instance, if we have >>>a resource list document, with several elements, each one >>>containing a few elements, the position() predicate executed in >>>the element will consider the element sequentially ordered. >> >>No. It would apply only at the specific place in the hierarchy where it >>is placed. >> >>> >>>Let me try to explain better with an example. Consider the following >>>resource list XML document. >>> >>> >>> >>> Bill Doe >>> >>> >>> Johanna Doe >>> >>> >> subscribeable="true"> >>> >>> Joe Smith >>> >>> >>> Nancy Gross >>> >>> >>> Peter Black >>> >>> http://www.example.org/xcap/resource-lists/users/a/foo >>> >>> >>> >>> >>>There are 5 elements, named Bill, Johanna, Joe, Nancy and Peter. >>>Imagine I want entries 2 to 4 (in spite they span across different >>>lists). Will the HTTP URI be something like: >>> >>>GET http://server/blah-blah/resource-lists/users/jack/entry[position()>1 >>>and position()<5] >> >>No, this will not work. I would suggest that, if you are worried about >>this, the client would page in each level of the hierarchy at a time. >> >>> >>>3) I believe the HTTP byte ranges is a complement of this feature, a >>>kind of emergency life jacket that under normal circumstances will not >>>be use. I doubt an XCAP client can do much with an XML document that is >>>truncated by the byte ranges: it can just discard the contents or store >>>them (if it has enough memory) and request the rest of the document. >> >>Right. The problem Ranges solves is if a fixed memory is available in the >>device for the content, you can make sure that there is room to store the >>results. If the results are a truncated document, you would need to retry >>with a much smaller page size. >>-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 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Jul 6 19:27: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 TAA03455 for ; Tue, 6 Jul 2004 19:27: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 1BhzLB-0005cH-0a for simple-archive@ietf.org; Tue, 06 Jul 2004 19:27:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BhzKB-0005Fu-00 for simple-archive@ietf.org; Tue, 06 Jul 2004 19:26:08 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BhzJM-0004ri-00; Tue, 06 Jul 2004 19:25:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BhwIx-0001WW-2X; Tue, 06 Jul 2004 16:12:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BhvlD-0002Wn-Oe; Tue, 06 Jul 2004 15:37:47 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16576; Tue, 6 Jul 2004 15:37:45 -0400 (EDT) Message-Id: <200407061937.PAA16576@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 06 Jul 2004 15:37:45 -0400 Cc: simple@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-cipid-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 : CIPID: Contact Information in Presence Information Data Format Author(s) : H. Schulzrinne Filename : draft-ietf-simple-cipid-02.txt Pages : 9 Date : 2004-7-6 The Presence Information Data Format (PIDF) defines a basic XML format for presenting presence information for a presentity. The Contact Information for Presence Information Data Format (CIPID) is an extension that adds elements to PIDF that provide additional contact information about a presentity and its contacts, including references to address book entries and icons. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-cipid-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-cipid-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-cipid-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-7-6152039.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-cipid-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-cipid-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-7-6152039.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 Tue Jul 6 21:34: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 VAA10553 for ; Tue, 6 Jul 2004 21:34: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 1Bi1K2-000214-EW for simple-archive@ietf.org; Tue, 06 Jul 2004 21:34:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bi1JB-0001gd-00 for simple-archive@ietf.org; Tue, 06 Jul 2004 21:33:15 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bi1IT-0001JD-00; Tue, 06 Jul 2004 21:32:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bi0I3-0001bq-Vf; Tue, 06 Jul 2004 20:27:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BhxBr-0002vK-UM for simple@megatron.ietf.org; Tue, 06 Jul 2004 17: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 RAA23123 for ; Tue, 6 Jul 2004 17: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 1BhxBk-0003CS-PN for simple@ietf.org; Tue, 06 Jul 2004 17:09:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BhxAD-0002T6-00 for simple@ietf.org; Tue, 06 Jul 2004 17:07:43 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Bhx8y-00021E-01 for simple@ietf.org; Tue, 06 Jul 2004 17:06:24 -0400 Received: from mail3.microsoft.com ([131.107.3.123]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BhwxC-0004nk-GH for simple@ietf.org; Tue, 06 Jul 2004 16:54:14 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.175); Tue, 6 Jul 2004 13:53:43 -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); Tue, 6 Jul 2004 13:52:14 -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, 6 Jul 2004 13:53:39 -0700 Message-ID: Thread-Topic: [Simple] MSRP Boundary header Thread-Index: AcRf97oY0fD8vAVCROqdzLscGfGDagDnmuEw From: "Orit Levin" To: "Cullen Jennings" , "Ben Campbell" , "Vijay Kishen Hampapur Parthasarathy" X-OriginalArrivalTime: 06 Jul 2004 20:52:14.0336 (UTC) FILETIME=[1DBF1800:01C4639B] Content-Transfer-Encoding: quoted-printable Cc: Paul H 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.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Cullen, I am worried about the recipient performance :-) in addition to relay performance. Sorry about not being clear in the previous response. The arguments boil down to 1. Yes, the conceptual design problem exists 2. Yes, there are ways to reduce the problem by designing the MSRP SW either around dedicated HW devices or around built-in OS techniques once become generally available. (Although, in general purpose OS data copy is performed by the network/protocol driver. This driver cannot be modified to also perform MSRP parsing - this is performed by the application handling MSRP. By the time the data reaches the application, it is no longer in the cache.) 3. Yes, there is still the question: Why to take this HW-oriented design path in the first place? - How come an additional length in the header makes the MSRP solution more complicated than the requirement to always scan all the data for the delimiters? - Does the implicit assumption that all the data needs to be encoded/escaped (no binary data in MSRP) work for everybody? I do agree with one curious point though :-) For short messages, the overhead of scanning the data is a relatively small percentage of the total processing of the message in total. For big messages (for the sake of those that the whole delimiters mechanism is being proposed for!!!) the overhead can be actually very big!!! My intermediate conclusion is that I would like to read the new versions of both the core MSRP and the relays draft in order to understand the exact proposed mechanism and what its implementation would mean to all MSRP entities . Thanks, Orit. > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com]=20 > Sent: Thursday, July 01, 2004 10:44 PM > To: Orit Levin; Ben Campbell; Vijay Kishen Hampapur Parthasarathy > Cc: Paul H Kyzivat; seancolson@yahoo.com; simple@ietf.org > Subject: Re: [Simple] MSRP Boundary header >=20 >=20 > This is a very strange argument, I think you exactly support=20 > my point but then you seem to draw the opposite conclusion. I=20 > will respond to you points inline but this whole argument=20 > does not make sense to me. I can scan for boundary at the=20 > speed of the memory bandwidth on any any machine anyone is=20 > likely to run a relay on. This is many giga bits per second=20 > worth of data. I can not imagine that this will represent a=20 > significant percentage of time for any relay and removing it=20 > will not make a relevant difference. >=20 > More inline >=20 > On 7/1/04 6:13 PM, "Orit Levin" wrote: >=20 > > The argument below about copying in parallel with checking=20 > is true for=20 > > single-purpose devices whose only or main job is to processes MSRP=20 > > messages. In general-purpose OS, copying occurs in lower=20 > layers (e.g. > > network drivers) and by the time the data reaches the=20 > application, it=20 > > is already out of the cache. > >=20 > > After some investigation, below are the facts: > >=20 > > The described behavior has been noted by OS vendors and=20 > some of them=20 > > already use special version of copy instruction that does=20 > not pollute=20 > > the cache when copying network data (e.g. using movnti on X86). >=20 > Yep - any my point was you could transfer it from block A in=20 > memory to block B in exactly the same time that you can=20 > transfer it and check it. If I used the non cache polluting=20 > instructions to transfer the data into a register, check it,=20 > then transfer out, I can still do this at the full bandwidth=20 > of the memory bus.=20 >=20 > >=20 > > Furthermore, there are protocols under development (CISCO=20 > along with=20 > > Microsoft are by the way among the founders of RDMA consortium - > > www.rdmaconsortium.org) that facilitate DMA directly from the wire=20 > > into the application data buffers (so-named Remote DMA). This=20 > > obviously completely bypasses the cache and makes the bottleneck=20 > > argument obsolete. > > >=20 > Yes very familiar with this. Let's see what would happen, a=20 > fragment of UDP packet arrives on the Ethernet card and you=20 > are going to know where to DMA the right portion of this=20 > fragment into a buffer in user space that represents the=20 > correct portion of a TCP data stream. I don't think so. If=20 > this protocol ran over UDP, you might be able to use this to=20 > improve performance beyond the current vector IO stuff that=20 > NT supports. However, it does not run over UDP and the DMA=20 > trick is not going to help for this. >=20 > Even if it did, your performance would be total limited by=20 > the bandwidth of the NIC cards - lets say you somehow had=20 > really a lot of of really fast NIC cards, you are going to=20 > hit the limit of the PCI bus to DMA it to memory. > This time to scan it is going to be a drop in the bucket=20 > because the CPU memory bandwidth is so much better than the=20 > memory to NIC bandwidth which is probably much greater than=20 > the actual bandwidth the NIC cards can put onto the network. =20 > =20 > > Finally, if one is implementing a gateway between MSRP and other=20 > > protocols, it may need to copy the whole data only to insert=20 > > additional escape sequences on the output path. >=20 > Uh, perhaps, if you implement TCP and MSRP in VLSI on the NIC=20 > card but otherwise I think the machine is going to copy it to memory. >=20 > >=20 > > To summarize this, I would say that it will be strange if=20 > SIMPLE comes=20 > > up with a brand new protocol which is "optimized" for > > - Dedicated HW devices >=20 > I'm lost how it is "optimized" for this >=20 > > - Encourages lazy implementation where the data is not=20 > being chunked=20 > > into reasonably sized blocks so that the relays in the middle have=20 > > hard time to decide whether they will be able to process a single=20 > > chunk or not >=20 > Again - don't see how you get to this conclusion. >=20 > > - and still being called the protocol for Instant Messaging >=20 > Let's say the type of IM you are interested in results in an=20 > average MSRP message that is 256 bytes long. If we take a=20 > 3Ghz P4 with 800 MHz frontside and good DDR memory, how many=20 > million of these messages do you think I can boundary scan per second? >=20 > How many million messages per second do you think you can=20 > relay on a single host?=20 >=20 > Do you think this result in dropped performance? I don't=20 > think it will drop performance at all because you can't relay=20 > from one stream to another stream with zero copies but even=20 > if you did implement it as another pass over the data just to=20 > do this, I doubt it can make any real difference. >=20 > >=20 > > Orit. > >=20 > >> -----Original Message----- > >> From: simple-bounces@ietf.org > >> [mailto:simple-bounces@ietf.org] On Behalf Of Cullen Jennings > >> Sent: Thursday, July 01, 2004 11:05 AM > >> To: Chris Boulton; Ben Campbell; Vijay Kishen Hampapur=20 > Parthasarathy > >> Cc: Ted Hardie; Paul H Kyzivat; seancolson@yahoo.com;=20 > simple@ietf.org > >> Subject: Re: [Simple] MSRP Boundary header > >>=20 > >>=20 > >> This whole discussion is premised on the idea that framing=20 > by finding=20 > >> a length header is somehow much more efficient, faster,=20 > etc than the=20 > >> boundary framing. I like to poke at that a little. This=20 > efficiency is=20 > >> probably only relevant on relays or things dealing with lots of=20 > >> messages and these run on machines where the CPU has a cache. > >>=20 > >> The experiments I have been playing with show that given=20 > the boundary=20 > >> recommendations that we are making that allow you to check for a=20 > >> "----" > >> 4 bytes at a time allow you look for boundary at the same=20 > rate that=20 > >> the memory can be copied. Basically the bandwidth from=20 > main memory to=20 > >> cache is the bottleneck and the extra check if the 4 byte value is=20 > >> "----" takes no extra time - the CPU is mostly idle=20 > waiting for the=20 > >> cache to fill. If you send a message which consisted of a special=20 > >> constructed message that looked very similar to the boundary, this=20 > >> might slow down but this is an artificial corner case I can't get=20 > >> worked up about. > >>=20 > >> I know of no reason for MSRP to prefer the length to the boundary=20 > >> scheme. If someone has one, let's get that on the table=20 > and establish=20 > >> if there is a real need to do both. The downside about both is=20 > >> interoperability issues when people only implement one. > >>=20 > >> I point out that I can find boundaries at the same rate I can copy=20 > >> memory and this is way way way beyond the total network bandwidth=20 > >> that can flow in or out of my machine. I'm missing what=20 > the argument=20 > >> for doing both is. > >>=20 > >> Cullen > >>=20 > >>=20 > >>=20 > >> On 7/1/04 12:27 AM, "Chris Boulton" wrote: > >>=20 > >>> I agree with Ben - why do something twice. This only increases=20 > >>> complexity and potential to provide conflicting + syntactically=20 > >>> incorrect semantics. > >>>=20 > >>> Chris. > >>>=20 > >>>=20 > >>> -----Original Message----- > >>> From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] > >>> Sent: 30 June 2004 19:35 > >>> To: Vijay Kishen Hampapur Parthasarathy > >>> Cc: Ted Hardie; Paul Kyzivat; seancolson@yahoo.com;=20 > simple@ietf.org > >>> Subject: Re: [Simple] MSRP Boundary header > >>>=20 > >>> Because having two ways to do the same thing adds > >> complexity to both > >>> the > >>>=20 > >>> implementation and the specification. > >>>=20 > >>> Vijay Kishen Hampapur Parthasarathy wrote: > >>>=20 > >>>> Can you comment on the initial question on why not allow > >> both methods > >>>> for message framing. > >>>>=20 > >>>> Vijay > >>>>=20 > >>>> -----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=20 > >>>> Parthasarathy; simple@ietf.org > >>>> Subject: Re: [Simple] MSRP Boundary header > >>>>=20 > >>>>=20 > >>>>=20 > >>>> Paul Kyzivat wrote: > >>>>=20 > >>>>=20 > >>>>>=20 > >>>>> Ted Hardie wrote: > >>>>>=20 > >>>>>=20 > >>>>>> At 7:48 PM -0700 6/29/04, Sean Olson wrote: > >>>>>>=20 > >>>>>>=20 > >>>>>>> Why not allow both methods? > >>>>>>> It seems clear that there are probably two common use cases: > >>>>>>>=20 > >>>>>>> 1) Simple, brief messages as in today's IM conversations > >>>>>>> 2) Larger, more complex, richer messages as forseen in 3G and=20 > >>>>>>> other environments > >>>>>>=20 > >>>>>>=20 > >>>>>>=20 > >>>>>> 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.=20 > But if you=20 > >>>>> are having a conversation composed of simple brief > >> messages then I > >>>>> believe > >>>>=20 > >>>>=20 > >>>>> the expectation is that you would be using MSRP. > >>>>>=20 > >>>>=20 > >>>>=20 > >>>> Or at one composed of a series of short, interactive > >> messages. (Which > >>> is > >>>> probably what Paul meant to say. > >>>>=20 > >>>>=20 > >>>>> At least that is my expectation. One subject that has yet to be=20 > >>>>> 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. > >>>>>=20 > >>>>=20 > >>>>=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. > >>>>=20 > >>>> 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. > >>>>=20 > >>>>=20 > >>>>> Paul > >>>=20 > >>> _______________________________________________ > >>> Simple mailing list > >>> Simple@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/simple > >>>=20 > >>>=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 > >=20 >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jul 7 03: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 DAA28690 for ; Wed, 7 Jul 2004 03: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 1Bi76a-0003LK-Eu for simple-archive@ietf.org; Wed, 07 Jul 2004 03:44:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bi72o-0002VV-00 for simple-archive@ietf.org; Wed, 07 Jul 2004 03:40:44 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Bi71G-0001t4-00; Wed, 07 Jul 2004 03:39:06 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Bi6qo-0007xJ-4Z; Wed, 07 Jul 2004 03:28:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bi6Vf-0008Tf-GI; Wed, 07 Jul 2004 03:06:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bi6AA-0004ZC-5r for simple@megatron.ietf.org; Wed, 07 Jul 2004 02: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 CAA25799 for ; Wed, 7 Jul 2004 02:44: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 1Bi6A2-0007bk-Rv for simple@ietf.org; Wed, 07 Jul 2004 02:44:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bi696-0007IA-00 for simple@ietf.org; Wed, 07 Jul 2004 02:43:12 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1Bi67U-0006gF-00 for simple@ietf.org; Wed, 07 Jul 2004 02:41: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 i676fPJ18094; Wed, 7 Jul 2004 09:41:25 +0300 (EET DST) X-Scanned: Wed, 7 Jul 2004 09:41: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 i676f0MS016071; Wed, 7 Jul 2004 09:41:00 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00IqlTWK; Wed, 07 Jul 2004 09:40:59 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 i676erH02006; Wed, 7 Jul 2004 09:40:53 +0300 (EET DST) Received: from nokia.com ([172.21.42.108]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 7 Jul 2004 09:40:53 +0300 Message-ID: <40EB9AF4.2080209@nokia.com> Date: Wed, 07 Jul 2004 09:40:52 +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: "Joel M. Halpern" Subject: Re: [Simple] RE: XCAP Directory: Large response ? References: <40EA0018.3080408@dynamicsoft.com> <40E5C2E1.50502@dynamicsoft.com> <40E903D2.2050703@nokia.com> <40EA0018.3080408@dynamicsoft.com> <5.1.0.14.0.20040706111036.023f5320@localhost> In-Reply-To: <5.1.0.14.0.20040706111036.023f5320@localhost> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Jul 2004 06:40:53.0090 (UTC) FILETIME=[595D4420:01C463ED] 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 Inline. Joel M. Halpern wrote: > I rather disagree with your summary. > 1) I am not at all convinced this is necessary, Well, this is not what some other folks thought. I can recall 4 or 5 folks arguing that this functionality is needed. > 1') The way you are defining the problem, I am not at all convinced it > is achievable. Again this is a matter of subject interpretation. Everything is achievable if you are smart enough to solve the problem. > > 2) I do not think we have anything like a rough consensus on whether > this is ended, but rather an interesting discussion on possible > requirements and possible ways to meet it. The chairs may have observed > a consensus, I suppose. It's not me who should judge whether we have consensus or not. I thought we had it, but that's my own interpretation. One has to bear in mind that consensus is not unanimity. Some folks tend to forget this slight difference. > As far as I can tell, requesting x elements of a certain type, from a > certain point in the XML document, tells you almost nothing about how > much information you are getting. If the elements are leaf elements, > they may contain large or small amounts of content. If they are not > leaf elements, then how many contained elements there are depends upon > the schema, whether the nested elements are optional and / or may occur > multiple times, etc. I know it, we discussed it. > And if you try to say "I want X elements, just start counting from the > starting point." then there is no way that the result can confidently be > a valid XML document or meaningful portion of a document according to a > schema. It will take some interesting work to even make it well-formed > XML under that constraint. Disagree. I can safely say "please send me X elements in a valid XML document". The XML document is valid no matter whether it contains 1 or a milillion elements in it. The XCAP server is responsible to create a valid XML document according to the schema, including the "appropriate" number of elements. We are doing the same with presence documents, whereby the presence server creates an XML document with the appropriate number of tuples and extensions, according to the authorizationn rules, policy, filters, etc. So if we can do it with a presence server, we can do it with an XCAP server. > > Now, if we add the filter definition Hisham has suggested, we at least > have a behaviors that is well defined and can produce meaningful > results. It even matches a useful and understandable problem. However, > it is a big change in the semantics of HTTP GET as far as I can tell. > It starts falling into the trap of using HTTP as a generic transport. > Will it work through relays? It will work with proxies, although I agree that is extending somehow the semantics of the GET method in HTTP. Having said that, I don't see Hisham's proposal fulfills the requirements. It assumes that you know in advance the XML document, and then you apply a filter. It requires you to know the values you are trying to filter. We don't want to filter based on values, but based on the number of elements present in the XML document. Therefore, I don't think adding a filter to the GET request will solve the problem. > > It seems to me that byte ranges are already there and already give > control at a level that corresponds to real limits on real clients. It > may be hard to construct what you need from it, but it matches the "I > only have Y buffer space available" constraint. > If we really need to solve this problem over and above that, I guess I > would prefer to explore whether the suggestion of Filters on GET is > valid and workable. We already had consensus (not unanimity) that byte ranges is a complement to the filter. It does not solve any problem by itself, as the XCAP server will truncate the XML document when the byte count is reached. Your XCAP client can't do anything with the truncated XML document. So byte ranges is just a limit to avoid flooding an XCAP client, but will not solve any other problem. > > Yours, > Joel M. Halpern Regards, Miguel Garcia > > At 10:15 AM 7/6/2004 +0300, Miguel Garcia wrote: > >> Summary of the thread: >> >> - I think we have consensus on adding a feature that allows an XCAP >> client to request a range of XML elements in a particular schema. >> >> - It seems that the HTP Range header does not serve for the purpose, >> since it operates on bytes and will most likely truncate XML documents. >> >> - It seems that the XPath position() operator will almost serve, but >> it is not part of the XCAP base specification. >> >> - And we don't want to delay the XCAP base spec by adding more >> features at this stage. >> >> - So this feature can be added as an advanced XCAP feature at a later >> stage. >> >> So far so good. At least I agree with the above. There is one bit >> where I don't quite agree: it seems that the position() opeator in >> XPath operates on the element level, meaning that if we have a >> non-flat list, the XCAP client will need to request ranges in each of >> the lists (see point 2 below). >> >> I think this is bad, and since we are going to design this extended >> feature, we should make it simple to use. >> >> First, if I have a device that can accommodate x entries, my XCAP >> client would need to request x entries for the first list, get the >> response (say y entries came), then do a new query requesting x-y >> entries in the next list, etc. Alternatively, my XCAP client can >> request x entries en each list, and perhaps I will get n * x entries >> (n is the number of lists). >> >> Second, this way of working assumes that I know in advance the number >> of lists that are nested. This assumption is false when I have never >> downloaded the XML document (such as when I start using a new device). >> >> In short: I want to have the means in XCAP to indicate: "please send >> me this XML document with range of x to z entries, and send them to me >> in a valid XML document". I don't need to know the structure of the >> document in advance (how many deep nested lists and their names), >> although I know the XML schema of the document. >> >> Is this something we can agree upon? >> >> - Miguel >> >> Jonathan Rosenberg wrote: >> >>> inline. >>> Miguel Garcia wrote: >>> >>>>> XCAP doesnt support that level of complexity in the server. If it >>>>> did, and you wanted protection against memory overload (say, 1k >>>>> max), you'd do something like this: >>>>> >>>>> GET http://server/blah-blah/list/buddy[position() > N and >>>>> position() < M] >>>>> Range: bytes=0-1000 >>>>> >>>>> If the response is truncated, then you need to adjust your >>>>> pagination size on the client. >>>>> >>>>> -Jonathan R. >>>> >>>> >>>> I think this is going in the right direction now. So let me ask a >>>> couple of questions to verify that the position() is valid for the >>>> purpose we want. >>>> >>>> 1) Is position already part of XCAP? By reading the XCAP base >>>> document I guess the answer is yes. >>> >>> >>> No, it is not. I would not suggest putting this in the base spec, >>> which is already overdue and suffering feature creep. I have >>> suggested, in another thread, that we perhaps can have an "xcap >>> advanced operations" spec that extended xcap with new features, >>> including multiple insertions. This would possibly be a candidate >>> feature for such an extension, if the group decided to pursue that. >>> >>>> >>>> 2) I guess if we have a non-flat list, the position element will >>>> operate in all the leaves of the XML document. For instance, if we >>>> have a resource list document, with several elements, each >>>> one containing a few elements, the position() predicate >>>> executed in the element will consider the element >>>> sequentially ordered. >>> >>> >>> No. It would apply only at the specific place in the hierarchy where >>> it is placed. >>> >>>> >>>> Let me try to explain better with an example. Consider the following >>>> resource list XML document. >>>> >>>> >>> subscribeable="true"> >>>> >>>> Bill Doe >>>> >>>> >>>> Johanna Doe >>>> >>>> >>> subscribeable="true"> >>>> >>>> Joe Smith >>>> >>>> >>>> Nancy Gross >>>> >>>> >>>> Peter Black >>>> >>>> http://www.example.org/xcap/resource-lists/users/a/foo >>>> >>>> >>>> >>>> >>>> There are 5 elements, named Bill, Johanna, Joe, Nancy and >>>> Peter. Imagine I want entries 2 to 4 (in spite they span across >>>> different lists). Will the HTTP URI be something like: >>>> >>>> GET >>>> http://server/blah-blah/resource-lists/users/jack/entry[position()>1 >>>> and position()<5] >>> >>> >>> No, this will not work. I would suggest that, if you are worried >>> about this, the client would page in each level of the hierarchy at a >>> time. >>> >>>> >>>> 3) I believe the HTTP byte ranges is a complement of this feature, a >>>> kind of emergency life jacket that under normal circumstances will >>>> not be use. I doubt an XCAP client can do much with an XML document >>>> that is truncated by the byte ranges: it can just discard the >>>> contents or store them (if it has enough memory) and request the >>>> rest of the document. >>> >>> >>> Right. The problem Ranges solves is if a fixed memory is available in >>> the device for the content, you can make sure that there is room to >>> store the results. If the results are a truncated document, you would >>> need to retry with a much smaller page size. >>> -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 > > -- 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 Jul 7 04: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 EAA02733 for ; Wed, 7 Jul 2004 04: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 1Bi7is-0001nm-Oa for simple-archive@ietf.org; Wed, 07 Jul 2004 04:24:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bi7ht-0001TY-00 for simple-archive@ietf.org; Wed, 07 Jul 2004 04:23:10 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bi7h2-0000qd-00; Wed, 07 Jul 2004 04:22:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bi7Hq-0000ox-JM; Wed, 07 Jul 2004 03:56:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bi6qb-0003sm-QX for simple@megatron.ietf.org; Wed, 07 Jul 2004 03:28:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28012 for ; Wed, 7 Jul 2004 03:27: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 1Bi6qU-0005rG-M7 for simple@ietf.org; Wed, 07 Jul 2004 03:27:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bi6mo-00057O-00 for simple@ietf.org; Wed, 07 Jul 2004 03:24:11 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1Bi6jy-0003ve-00 for simple@ietf.org; Wed, 07 Jul 2004 03:21:14 -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 i677KvN15170; Wed, 7 Jul 2004 10:20:57 +0300 (EET DST) X-Scanned: Wed, 7 Jul 2004 10:20:47 +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 i677Kl54009813; Wed, 7 Jul 2004 10:20:47 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00W5RFVL; Wed, 07 Jul 2004 10:20:46 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 i677KjH07719; Wed, 7 Jul 2004 10:20:45 +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, 7 Jul 2004 10:20:43 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [Simple] Re: MSRP: Max message size indication Date: Wed, 7 Jul 2004 10:20:42 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7023EEACD@esebe019.ntc.nokia.com> Thread-Topic: [Simple] Re: MSRP: Max message size indication Thread-Index: AcRjalYYBztaNDxKRhK6Z8nqvTVKMAAh2QiA To: , , X-OriginalArrivalTime: 07 Jul 2004 07:20:43.0180 (UTC) FILETIME=[E9F80EC0:01C463F2] 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 haven't seen any technical arguments against it besides the arguments = I made about how that number is calculated. People felt that the number = calculation is local policy. People who want this feature feel very strongly about it and obviously = have a need for it. I take Ben's word that it is trivial to specify, so = unless someone brings forward technical arguments against having it in, = then it will be in, but under one condition: any valid technical = arguments brought forward that might cause delay will result in removing = that feature. So Ben, please go ahead an specify it in the next version. We can still = take a hum at the meeting in San Diego to confirm. Thanks, Hisham > -----Original Message----- > From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] > Sent: 06.July.2004 18:02 > To: Drage, Keith (Keith); Khartabil Hisham (Nokia-TP-MSW/Helsinki); > Robert Sparks > Cc: simple@ietf.org > Subject: Re: [Simple] Re: MSRP: Max message size indication >=20 >=20 > Hi Keith, >=20 > I am sensitive to your concern, and my initial position was=20 > to push back=20 > on _any_ new MSRP features at this time. You are correct, the=20 > votes were=20 > about even from the people who responded. >=20 > I pretty much gave in to the feature because it is fairly trivial to=20 > specify, doesn't appear to break anything, and it began to look like=20 > less work to add it than to argue about it. Its presence in=20 > Jonathan's=20 > Advanced Messaging Requirements document gave some weight to the=20 > argument to put it in. We can discuss whether that document is=20 > authoritative, but that gives us even more time spent arguing. >=20 > So, perhaps the chairs would like to assert a final opinion on the=20 > consensus about this item? >=20 > Drage, Keith (Keith) wrote: > > Having reread the entire thread, the only winner I have=20 > seen in this vote is Christer Holmberg for the sheer number=20 > of messages sent. If that is the criteria that is being used=20 > for decision, then you should have made this clear at the=20 > beginning. What I do see from the list is that the balance of=20 > the votes was pretty even, even on the send capability. I do=20 > not call that rough working consensus. > >=20 > > What I am seeing here is feature creep. People are=20 > justifying their arguments on the basis that it does not take=20 > much time to add a particular feature, therefore lets add it.=20 > What this means is that this continues to happen and we never=20 > get the deliverable out of the door. > >=20 > > We saw it happen in SIP, we are seeing it happen in=20 > sdp-new, and we are seeing it happen now in XCAP as well. > >=20 > > MSRP is needed pretty damn soon. > >=20 > > Can we please stop the feature creep and deliver what is=20 > already in the document, and deal with other stuff as extensions. > >=20 > > regards > >=20 > > Keith Drage > >=20 > >=20 > >=20 > >>-----Original Message----- > >>From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] > >>Sent: 28 June 2004 20:57 > >>To: Christer Holmberg (JO/LMF) > >>Cc: Adam Roach; simple@ietf.org; 'hisham.khartabil@nokia.com'; 'Paul > >>Kyzivat'; alex.audu@alcatel.com; cboulton@ubiquity.com > >>Subject: Re: [Simple] Re: MSRP: Max message size indication > >> > >> > >>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, > >>> > >>>So, do we have some kind of conclusion on this? > >>> > >>>Some people have asked for use-cases, and scenarios where=20 > >> > >>this can be useful, and I think a number of those have now=20 > >>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 > >>>> > >>>> > >>>> > >>>> > >>>>Alex Audu wrote: > >>>> > >>>> > >>>>>I think there is great value in end-point being able to=20 > >> > >>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=20 > >> > >>communicated with a=20 > >> > >>>>>decreased risk of truncation > >>>>>at first try. That makes for a more efficient=20 > 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 > >> >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jul 7 05:55: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 FAA07589 for ; Wed, 7 Jul 2004 05:55: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 1Bi99N-0003Cc-Tc for simple-archive@ietf.org; Wed, 07 Jul 2004 05:55:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bi98S-0002od-00 for simple-archive@ietf.org; Wed, 07 Jul 2004 05:54:41 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bi97e-0002OA-00; Wed, 07 Jul 2004 05:53:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bi8FD-0006Ks-AL; Wed, 07 Jul 2004 04:57:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bi7h3-0006r0-Qf for simple@megatron.ietf.org; Wed, 07 Jul 2004 04:22: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 EAA02704 for ; Wed, 7 Jul 2004 04:22:10 -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 1Bi7gw-00019o-CL for simple@ietf.org; Wed, 07 Jul 2004 04:22:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bi7g0-0000pC-00 for simple@ietf.org; Wed, 07 Jul 2004 04:21:12 -0400 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1Bi7f9-0000T0-00 for simple@ietf.org; Wed, 07 Jul 2004 04:20:19 -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 i678KB608242; Wed, 7 Jul 2004 11:20:12 +0300 (EET DST) X-Scanned: Wed, 7 Jul 2004 11:20:06 +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 i678K6No012907; Wed, 7 Jul 2004 11:20:06 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00Hrf1vy; Wed, 07 Jul 2004 11:20:05 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 i678K4H28745; Wed, 7 Jul 2004 11:20:04 +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, 7 Jul 2004 11:20:04 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 7 Jul 2004 11:20:03 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [Simple] RE: XCAP Directory: Large response ? Date: Wed, 7 Jul 2004 11:20:03 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7023EEAD1@esebe019.ntc.nokia.com> Thread-Topic: [Simple] RE: XCAP Directory: Large response ? Thread-Index: AcRj+O7e4Cq5rcJcQG+ODRj/hmw0rQAASc8Q To: , X-OriginalArrivalTime: 07 Jul 2004 08:20:03.0274 (UTC) FILETIME=[33F34AA0:01C463FB] 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 Miguel Garcia > Sent: 07.July.2004 09:41 > To: Joel M. Halpern > Cc: simple@ietf.org > Subject: Re: [Simple] RE: XCAP Directory: Large response ? >=20 >=20 > >=20 > > Now, if we add the filter definition Hisham has suggested,=20 > we at least=20 > > have a behaviors that is well defined and can produce meaningful=20 > > results. It even matches a useful and understandable=20 > problem. However,=20 > > it is a big change in the semantics of HTTP GET as far as I=20 > can tell. =20 > > It starts falling into the trap of using HTTP as a generic=20 > transport. =20 > > Will it work through relays? >=20 > It will work with proxies, although I agree that is extending somehow=20 > the semantics of the GET method in HTTP. Having said that, I=20 > don't see=20 > Hisham's proposal fulfills the requirements. It assumes that=20 > you know in=20 > advance the XML document, and then you apply a filter. It=20 > requires you=20 > to know the values you are trying to filter. We don't want to filter=20 > based on values, but based on the number of elements=20 > present in=20 > the XML document. Therefore, I don't think adding a filter to the GET=20 > request will solve the problem. I did propose this in an earlier email, it is very similar to the URI in = the GET approach suggested Jonathan. Here is the text again: we can extend it in a similar way Jonathan proposed to extend XCAP. I.e. = Allow the filter to carry the position() function. The example I gave = therefore becomes: GET ... //resource-lists/list[@name=3D"friends"]/entry[position() > N = and position() < M] It might be overloading the semantics of HTTP GET and it might be too = much overhead, but it's a proposal in any case. Regards, Hisham=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jul 7 07:34: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 HAA12343 for ; Wed, 7 Jul 2004 07:34: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 1BiAgu-0007Hx-5j for simple-archive@ietf.org; Wed, 07 Jul 2004 07:34:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BiAg4-0006wV-00 for simple-archive@ietf.org; Wed, 07 Jul 2004 07:33:29 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BiAey-0006HU-00; Wed, 07 Jul 2004 07: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 1Bi9vK-0002WG-56; Wed, 07 Jul 2004 06:45:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bi9Qa-0003Te-0f for simple@megatron.ietf.org; Wed, 07 Jul 2004 06:13: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 GAA08199 for ; Wed, 7 Jul 2004 06:13: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 1Bi9QS-0001b9-MH for simple@ietf.org; Wed, 07 Jul 2004 06:13:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bi9OX-0000yt-00 for simple@ietf.org; Wed, 07 Jul 2004 06:11:18 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1Bi9O1-0000e2-00 for simple@ietf.org; Wed, 07 Jul 2004 06:10:45 -0400 Received: from dynamicsoft.com ([63.113.46.28]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i67AAXbo006863; Wed, 7 Jul 2004 06:10:33 -0400 (EDT) Message-ID: <40EBCC06.1030307@dynamicsoft.com> Date: Wed, 07 Jul 2004 06:10: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: Miguel Garcia Subject: Re: [Simple] RE: simple-filter Max Size or Max number of element asfilter cri terias? References: <2038BCC78B1AD641891A0D1AE133DBB7023EEAB5@esebe019.ntc.nokia.com> <40EA8CDD.70108@nokia.com> In-Reply-To: <40EA8CDD.70108@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: "Anders Lindgren C \(HF/EAB\)" , 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 Directly using the filters in xcap would be a major change in how xcap does things. We'd probably have to start with a totally new protocol (i.e., it couldnt be HTTP based anymore). As such, I am opposed to such a change. I will note that the filter work and xcap both use similar concepts in addressing elements - xpath expressions for selection. Indeed, I would argue that, given the scope of xcap, all of the information in the filter is not needed except for this expression, and that expression appears in the URI of the XCAP request. -Jonathan R. Miguel Garcia wrote: > Hisham: > > I find this explanation very interesting, but unfortunately this is not > the functionality I was thining of. > > I thought that I would like to limit the number of entries returned in a > document. I don't even know, at the time of requesting, if there is an > entry by name Bob, Sarah, John or Alice in my list. I don't even know > how many entries and lists I have in the XML document I am trying to > retrieve. I just know that my device has some limitations, perhas due to > a small display, perhaps due to memory constraints, that makes me want > to limit the number of entries returned in the XML document. > > I don't think the filter fulfills this requirement. > > - Miguel > > Khartabil Hisham (Nokia-TP-MSW/Helsinki) wrote: > >> Perhaps I wasn't clear >> >> I was suggesting that the filter, when applied to a HTTP GET, lists >> the resources in the buddy list that the client wants to get, much >> like what I suggested for the SUBSCRIBE. >> >> For example, we have a list containing Bob, Sarah, John and Alice: >> >> >> >> > subscribeable="true"> >> >> >> >> >> >> >> >> >> If I want to SUBSCRIBE and receive information about Bob and Alice, >> this is what the filter in the SUBSCRIBE would look like (the xpath >> expression is according the event list package): >> >> >> >> >> >> >> //rlmi:list/rlmi:resource[@uri=""bob@example.com"] >> >> >> //rlmi:list/rlmi:resource[@uri=""alice@example.com"] >> >> >> >> >> >> >> Now, if I do a HTTP GET and want to get those resources, then the GET >> would have a filter: >> >> >> >> >> >> >> >> //resource-lists/list[@name="friends"]/entry[@uri=""bob@example.com"] >> >> >> >> //resource-lists/list[@name="friends"]/entry[@uri=""alice@example.com"] >> >> >> >> >> >> Thanks, >> Hisham >> >> >>> -----Original Message----- >>> From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org]On Behalf >>> Of ext Anders Lindgren C (HF/EAB) >>> Sent: 05.July.2004 18:26 >>> To: Khartabil Hisham (Nokia-TP-MSW/Helsinki); simple@ietf.org >>> Cc: Garcia Miguel.An (Nokia-NRC/Helsinki) >>> Subject: [Simple] RE: simple-filter Max Size or Max number of element >>> asfilter cri terias? >>> >>> >>> Hi >>> In the tread #RE: [Simple] Re: XCAP Directory: Large response ?" >>> you asked Miguel to have a look at the filter draft to solve the XCAP >>> problem. I qoute: >>> "I wonder if you can use the following event filtering draft with >>> HTTP GET? >>> >>> http://www.ietf.org/internet-drafts/draft-ietf-simple-filter-f >>> ormat-01.txt (currently in WGLC) >>> >>> At least the part could be useful." >>> >>> My view is that it is the same thing Miguel and I are addressing, but >>> on different protocols ( SIP, XCAP). A client can get a list of users >>> that is to more that it can handle. How can it be that the filter >>> draft can solve the XCAP problem but not the Subscribe problem? >>> /Anders >>> >>> >>> >>> -----Original Message----- >>> From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] >>> Sent: den 2 juli 2004 16:01 >>> To: Anders Lindgren C (HF/EAB); simple@ietf.org >>> Subject: RE: simple-filter Max Size or Max number of element as filter >>> criterias? >>> >>> >>> >>> >>> >>>> -----Original Message----- >>>> From: ext Anders Lindgren C (HF/EAB) >>>> [mailto:anders.c.lindgren@ericsson.com] >>>> Sent: 02.July.2004 16:42 >>>> To: Khartabil Hisham (Nokia-TP-MSW/Helsinki); simple@ietf.org >>>> Subject: RE: simple-filter Max Size or Max number of >>> >>> >>> element as filter >>> >>>> criterias? >>>> >>>> >>>> Ok >>>> Can I select the number of elements of a certain type I want to >>>> receive? Ie give my at the most 100 buddies in a resource list when >>>> subscribing to a list? >>> >>> >>> No you cannot, but what you can do is list in the filter the buddies >>> you are interested in receiving information about. I think this is >>> more useful that using the filter to tell the server to send you the >>> first x buddies. >>> >>> /Hisham >>> >>> >>>> Or is it that something complete new is needed or is it covered by >>>> some other spec? As I see it this is a general problem for all >>>> types of Subscribe for event packages if you can not control the >>>> size of what is send in the Notify. >>>> Regards Anders >>>> >>>> -----Original Message----- >>>> From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] >>>> Sent: den 2 juli 2004 14:40 >>>> To: Anders Lindgren C (HF/EAB); simple@ietf.org >>>> Subject: RE: simple-filter Max Size or Max number of >>> >>> >>> element as filter >>> >>>> criterias? >>>> >>>> >>>> You can reduce the size of the document delivered in the NOTIFY by >>>> using the filters (but selecting the elements that you really want >>>> to be delivered to you), but you cannot filter based on size. You >>>> cannot say "send me a NOTIFY with a body no larger than 1000 bytes". >>>> >>>> If you want something like that, then this is outside the scope of >>>> the filtering drafts in question. >>>> >>>> Regards, >>>> Hisham >>>> >>>> >>>>> -----Original Message----- >>>>> From: ext Anders Lindgren C (HF/EAB) >>>>> [mailto:anders.c.lindgren@ericsson.com] >>>>> Sent: 02.July.2004 15:23 >>>>> To: Khartabil Hisham (Nokia-TP-MSW/Helsinki); simple@ietf.org >>>>> Subject: RE: simple-filter Max Size or Max number of >>>> >>>> >>>> element as filter >>>> >>>>> criterias? >>>>> >>>>> >>>>> Hi >>>>> The question is what "unwanted" information" mean? Can it be that a >>>>> XML document that is to large to handle can be regarded as >>>>> "unwanted" information and therefore can be regarded as being >>>>> inside the scope of the simple-filter draft. >>>>> Regards >>>>> Anders >>>>> >>>>> -----Original Message----- >>>>> From: hisham.khartabil@nokia.com >> >> >> [mailto:hisham.khartabil@nokia.com] >> >>>> Sent: den 2 juli 2004 10:07 >>>> To: Anders Lindgren C (HF/EAB); simple@ietf.org >>>> Subject: RE: simple-filter Max Size or Max number of >>> >>> >>> element as filter >>> >>>> criterias? >>>> >>>> >>>> I believe that you are asking for is outside the scope of the >>>> simple-filter drafts. It can be done with filters, but not >>> >>> >>> those ones. >>> >>>> The current filter drafts talk about filtering unwanted or >>>> uninteresting information sent in a NOTIFY. They also talk about >>>> triggering of notifications when certain changes to the state of an >>>> event occur. >>>> >>>> Regards, >>>> Hisham >>>> >>>> >>>>> -----Original Message----- >>>>> From: ext Anders Lindgren C (HF/EAB) >>>>> [mailto:anders.c.lindgren@ericsson.com] >>>>> Sent: 02.July.2004 10:53 >>>>> To: simple@ietf.org; Khartabil Hisham (Nokia-TP-MSW/Helsinki) >>>>> Subject: simple-filter Max Size or Max number of element as filter >>>>> criterias? >>>>> >>>>> >>>>> Hi, >>>>> The XML documents sent from the network to the client can be very >>>>> large or it can contains a very long sequence of elements ( e.g a >>>>> resource list with 1000 buddies) >>>>> It will also exist different types of clients. Some clients can >>>>> specify a very large resource list and it will exist clients that >>>>> can not handle that large list. >>>>> >>>>> I have not found how a client can inform the network about how >>>>> large documents is can handle or how many elements of a certain >>>>> type it can handle. >>>>> My question is now if this information can be regarded as filter >>>>> criterias and includes in this filter specification? >>>>> >>>>> Best regards >>>>> >>>>> Anders Lindgren Ericsson AB Sweden >>>>> >>>> >> >> _______________________________________________ >> 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 Wed Jul 7 07: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 HAA12575 for ; Wed, 7 Jul 2004 07: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 1BiAmx-0001Xi-7K for simple-archive@ietf.org; Wed, 07 Jul 2004 07:40:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BiAm3-0001CH-00 for simple-archive@ietf.org; Wed, 07 Jul 2004 07:39:40 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BiAlH-0000ph-00; Wed, 07 Jul 2004 07:38:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BiA8P-0005Ag-3w; Wed, 07 Jul 2004 06:58:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bi9hy-0007JX-Pv for simple@megatron.ietf.org; Wed, 07 Jul 2004 06:31: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 GAA09285 for ; Wed, 7 Jul 2004 06:31: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 1Bi9hr-0000R5-F1 for simple@ietf.org; Wed, 07 Jul 2004 06:31:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bi9gt-00004L-00 for simple@ietf.org; Wed, 07 Jul 2004 06:30:16 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1Bi9fu-0007Bv-00 for simple@ietf.org; Wed, 07 Jul 2004 06:29:14 -0400 Received: from dynamicsoft.com ([63.113.46.28]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i67AT1bo006879; Wed, 7 Jul 2004 06:29:01 -0400 (EDT) Message-ID: <40EBD05A.9060003@dynamicsoft.com> Date: Wed, 07 Jul 2004 06:28: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: Miguel Garcia Subject: Re: [Simple] RE: XCAP Directory: Large response ? References: <40EA0018.3080408@dynamicsoft.com> <40E5C2E1.50502@dynamicsoft.com> <40E903D2.2050703@nokia.com> <40EA0018.3080408@dynamicsoft.com> <5.1.0.14.0.20040706111036.023f5320@localhost> <40EB9AF4.2080209@nokia.com> In-Reply-To: <40EB9AF4.2080209@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: "Joel M. Halpern" , 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. Miguel Garcia wrote: > Inline. > > Joel M. Halpern wrote: > >> I rather disagree with your summary. >> 1) I am not at all convinced this is necessary, > > > Well, this is not what some other folks thought. I can recall 4 or 5 > folks arguing that this functionality is needed. I think "pagination" is a reasonable requirement. It is definitely a new one, in that it has not appeared in our requirements document: http://www.jdrosen.net/papers/draft-ietf-simple-data-req-03.txt My definition of pagination is that this is a feature specific to resource lists. The feature allows the client to request any number of items (which include entries, lists, or entry references) at each level. Thus, if a user has a two-level hierarchical list, the user could get the first level, and see it on their phone. They can then select one of the lists on the first level, and the phone will get pages of that list. This approach is achievable as well. >> And if you try to say "I want X elements, just start counting from the >> starting point." then there is no way that the result can confidently >> be a valid XML document or meaningful portion of a document according >> to a schema. It will take some interesting work to even make it >> well-formed XML under that constraint. > > > Disagree. I can safely say "please send me X elements in a valid XML > document". The XML document is valid no matter whether it contains 1 or > a milillion elements in it. The XCAP server is responsible to create a > valid XML document according to the schema, including the "appropriate" > number of elements. No. This is not possible. Joel is correct - you cannot have an algorithm for getting X elements of an arbitrary XML document which results in a document that is schema valid. Let me give you an example. Lets say I have the following schema: This schema *requires* that the element have three children, el1, el2 and el3. If you ask for a version of this document with no more than two elements, it cannot be done in a way that results in a schema compliant document. > > We are doing the same with presence documents, whereby the presence > server creates an XML document with the appropriate number of tuples and > extensions, according to the authorizationn rules, policy, filters, etc. > So if we can do it with a presence server, we can do it with an XCAP > server. This "pagination" concept you are interested in is only meaningful for specific XML document formats, where there is a natural place in the schema were an arbitrary number of elements can be present. This is NOT a general XML, XCAP or HTTP feature. > >> >> Now, if we add the filter definition Hisham has suggested, we at least >> have a behaviors that is well defined and can produce meaningful >> results. It even matches a useful and understandable problem. >> However, it is a big change in the semantics of HTTP GET as far as I >> can tell. It starts falling into the trap of using HTTP as a generic >> transport. Will it work through relays? > > > It will work with proxies, although I agree that is extending somehow > the semantics of the GET method in HTTP. Having said that, I don't see > Hisham's proposal fulfills the requirements. It assumes that you know in > advance the XML document, and then you apply a filter. It requires you > to know the values you are trying to filter. We don't want to filter > based on values, but based on the number of elements present in > the XML document. Therefore, I don't think adding a filter to the GET > request will solve the problem. As I posted in a separate note, I see no point in including filters in the HTTP requests. Hisham - what does this add beyond what the URI can already too? I know what it takes away - it takes away our ability to use PUT, which will mean that we are back to a custom protocol. That is definitely months of additional delay. I see no value in doing this. -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 Jul 7 08:07: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 IAA13744 for ; Wed, 7 Jul 2004 08:07: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 1BiBCu-00039A-E5 for simple-archive@ietf.org; Wed, 07 Jul 2004 08:07:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BiBC0-0002nK-00 for simple-archive@ietf.org; Wed, 07 Jul 2004 08:06:30 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BiBBA-00027d-00; Wed, 07 Jul 2004 08:05:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BiAjB-0004Yk-EO; Wed, 07 Jul 2004 07:36:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BiA95-0005KP-PG for simple@megatron.ietf.org; Wed, 07 Jul 2004 06:59: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 GAA10891 for ; Wed, 7 Jul 2004 06:59:15 -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 1BiA8y-0002rj-CR for simple@ietf.org; Wed, 07 Jul 2004 06:59:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BiA7x-0002Wl-00 for simple@ietf.org; Wed, 07 Jul 2004 06:58:15 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1BiA6x-00024h-00 for simple@ietf.org; Wed, 07 Jul 2004 06:57:11 -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 i67Atr214045; Wed, 7 Jul 2004 13:55:53 +0300 (EET DST) X-Scanned: Wed, 7 Jul 2004 13:55:49 +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 i67AtnbJ011265; Wed, 7 Jul 2004 13:55:49 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00mCbMS7; Wed, 07 Jul 2004 13:55:33 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 i67AtVH12977; Wed, 7 Jul 2004 13:55:31 +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, 7 Jul 2004 13:55:27 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [Simple] RE: simple-filter Max Size or Max number of element asfilter cri terias? Date: Wed, 7 Jul 2004 13:55:25 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7023EEAD7@esebe019.ntc.nokia.com> Thread-Topic: [Simple] RE: simple-filter Max Size or Max number of element asfilter cri terias? Thread-Index: AcRkDgRkJC8geVZOTZ2f33IMk5OtnQAAsw7g To: , X-OriginalArrivalTime: 07 Jul 2004 10:55:27.0667 (UTC) FILETIME=[E9B8C030:01C46410] Content-Transfer-Encoding: quoted-printable Cc: anders.c.lindgren@ericsson.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 was suggesting it as an HTTP extension, not an XCAP extension. /Hisham > -----Original Message----- > From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: 07.July.2004 13:10 > To: Garcia Miguel.An (Nokia-NRC/Helsinki) > Cc: Khartabil Hisham (Nokia-TP-MSW/Helsinki); Anders Lindgren C > (HF/EAB); simple@ietf.org > Subject: Re: [Simple] RE: simple-filter Max Size or Max number of > element asfilter cri terias? >=20 >=20 > Directly using the filters in xcap would be a major change in=20 > how xcap=20 > does things. We'd probably have to start with a totally new protocol=20 > (i.e., it couldnt be HTTP based anymore). As such, I am=20 > opposed to such=20 > a change. >=20 > I will note that the filter work and xcap both use similar=20 > concepts in=20 > addressing elements - xpath expressions for selection.=20 > Indeed, I would=20 > argue that, given the scope of xcap, all of the information in the=20 > filter is not needed except for this expression, and that expression=20 > appears in the URI of the XCAP request. >=20 > -Jonathan R. >=20 > Miguel Garcia wrote: >=20 > > Hisham: > >=20 > > I find this explanation very interesting, but unfortunately=20 > this is not=20 > > the functionality I was thining of. > >=20 > > I thought that I would like to limit the number of entries=20 > returned in a=20 > > document. I don't even know, at the time of requesting, if=20 > there is an=20 > > entry by name Bob, Sarah, John or Alice in my list. I don't=20 > even know=20 > > how many entries and lists I have in the XML document I am=20 > trying to=20 > > retrieve. I just know that my device has some limitations,=20 > perhas due to=20 > > a small display, perhaps due to memory constraints, that=20 > makes me want=20 > > to limit the number of entries returned in the XML document. > >=20 > > I don't think the filter fulfills this requirement. > >=20 > > - Miguel > >=20 > > Khartabil Hisham (Nokia-TP-MSW/Helsinki) wrote: > >=20 > >> Perhaps I wasn't clear > >> > >> I was suggesting that the filter, when applied to a HTTP=20 > GET, lists=20 > >> the resources in the buddy list that the client wants to get, much=20 > >> like what I suggested for the SUBSCRIBE. > >> > >> For example, we have a list containing Bob, Sarah, John and Alice: > >> > >> > >> xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance"> > >> >> subscribeable=3D"true"> > >> > >> > >> > >> > >> > >> > >> > >> > >> If I want to SUBSCRIBE and receive information about Bob=20 > and Alice,=20 > >> this is what the filter in the SUBSCRIBE would look like=20 > (the xpath=20 > >> expression is according the event list package): > >> > >> > >> > >> > >> > >> > >> //rlmi:list/rlmi:resource[@uri=3D""bob@example.com"] > >> > >> > >> //rlmi:list/rlmi:resource[@uri=3D""alice@example.com"] > >> > >> > >> > >> > >> > >> > >> Now, if I do a HTTP GET and want to get those resources,=20 > then the GET=20 > >> would have a filter: > >> > >> > >> > >> > >> > >> > >> =20 > >>=20 > = //resource-lists/list[@name=3D"friends"]/entry[@uri=3D""bob@example.com"]= > >> > >> > >> =20 > >>=20 > //resource-lists/list[@name=3D"friends"]/entry[@uri=3D""alice@exam > ple.com"] > >> > >> > >> > >> > >> > >> Thanks, > >> Hisham > >> > >> > >>> -----Original Message----- > >>> From: simple-bounces@ietf.org=20 > [mailto:simple-bounces@ietf.org]On Behalf > >>> Of ext Anders Lindgren C (HF/EAB) > >>> Sent: 05.July.2004 18:26 > >>> To: Khartabil Hisham (Nokia-TP-MSW/Helsinki); simple@ietf.org > >>> Cc: Garcia Miguel.An (Nokia-NRC/Helsinki) > >>> Subject: [Simple] RE: simple-filter Max Size or Max=20 > number of element > >>> asfilter cri terias? > >>> > >>> > >>> Hi > >>> In the tread #RE: [Simple] Re: XCAP Directory: Large=20 > response ?" =20 > >>> you asked Miguel to have a look at the filter draft to=20 > solve the XCAP=20 > >>> problem. I qoute: > >>> "I wonder if you can use the following event filtering draft with=20 > >>> HTTP GET? > >>> > >>> http://www.ietf.org/internet-drafts/draft-ietf-simple-filter-f > >>> ormat-01.txt (currently in WGLC) > >>> > >>> At least the part could be useful." > >>> > >>> My view is that it is the same thing Miguel and I are=20 > addressing, but=20 > >>> on different protocols ( SIP, XCAP). A client can get a=20 > list of users=20 > >>> that is to more that it can handle. How can it be that the filter=20 > >>> draft can solve the XCAP problem but not the Subscribe problem? > >>> /Anders > >>> > >>> > >>> > >>> -----Original Message----- > >>> From: hisham.khartabil@nokia.com=20 > [mailto:hisham.khartabil@nokia.com] > >>> Sent: den 2 juli 2004 16:01 > >>> To: Anders Lindgren C (HF/EAB); simple@ietf.org > >>> Subject: RE: simple-filter Max Size or Max number of=20 > element as filter > >>> criterias? > >>> > >>> > >>> > >>> > >>> > >>>> -----Original Message----- > >>>> From: ext Anders Lindgren C (HF/EAB) > >>>> [mailto:anders.c.lindgren@ericsson.com] > >>>> Sent: 02.July.2004 16:42 > >>>> To: Khartabil Hisham (Nokia-TP-MSW/Helsinki); simple@ietf.org > >>>> Subject: RE: simple-filter Max Size or Max number of=20 > >>> > >>> > >>> element as filter > >>> > >>>> criterias? > >>>> > >>>> > >>>> Ok > >>>> Can I select the number of elements of a certain type I want to=20 > >>>> receive? Ie give my at the most 100 buddies in a=20 > resource list when=20 > >>>> subscribing to a list? > >>> > >>> > >>> No you cannot, but what you can do is list in the filter=20 > the buddies=20 > >>> you are interested in receiving information about. I=20 > think this is=20 > >>> more useful that using the filter to tell the server to=20 > send you the=20 > >>> first x buddies. > >>> > >>> /Hisham > >>> > >>> > >>>> Or is it that something complete new is needed or is it=20 > covered by=20 > >>>> some other spec? As I see it this is a general problem for all=20 > >>>> types of Subscribe for event packages if you can not=20 > control the=20 > >>>> size of what is send in the Notify. > >>>> Regards Anders > >>>> > >>>> -----Original Message----- > >>>> From: hisham.khartabil@nokia.com=20 > [mailto:hisham.khartabil@nokia.com] > >>>> Sent: den 2 juli 2004 14:40 > >>>> To: Anders Lindgren C (HF/EAB); simple@ietf.org > >>>> Subject: RE: simple-filter Max Size or Max number of=20 > >>> > >>> > >>> element as filter > >>> > >>>> criterias? > >>>> > >>>> > >>>> You can reduce the size of the document delivered in the=20 > NOTIFY by=20 > >>>> using the filters (but selecting the elements that you=20 > really want=20 > >>>> to be delivered to you), but you cannot filter based on=20 > size. You=20 > >>>> cannot say "send me a NOTIFY with a body no larger than=20 > 1000 bytes". > >>>> > >>>> If you want something like that, then this is outside=20 > the scope of=20 > >>>> the filtering drafts in question. > >>>> > >>>> Regards, > >>>> Hisham > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: ext Anders Lindgren C (HF/EAB) > >>>>> [mailto:anders.c.lindgren@ericsson.com] > >>>>> Sent: 02.July.2004 15:23 > >>>>> To: Khartabil Hisham (Nokia-TP-MSW/Helsinki); simple@ietf.org > >>>>> Subject: RE: simple-filter Max Size or Max number of=20 > >>>> > >>>> > >>>> element as filter > >>>> > >>>>> criterias? > >>>>> > >>>>> > >>>>> Hi > >>>>> The question is what "unwanted" information" mean? Can=20 > it be that a=20 > >>>>> XML document that is to large to handle can be regarded as=20 > >>>>> "unwanted" information and therefore can be regarded as being=20 > >>>>> inside the scope of the simple-filter draft. > >>>>> Regards > >>>>> Anders > >>>>> > >>>>> -----Original Message----- > >>>>> From: hisham.khartabil@nokia.com=20 > >> > >> > >> [mailto:hisham.khartabil@nokia.com] > >> > >>>> Sent: den 2 juli 2004 10:07 > >>>> To: Anders Lindgren C (HF/EAB); simple@ietf.org > >>>> Subject: RE: simple-filter Max Size or Max number of=20 > >>> > >>> > >>> element as filter > >>> > >>>> criterias? > >>>> > >>>> > >>>> I believe that you are asking for is outside the scope of the=20 > >>>> simple-filter drafts. It can be done with filters, but not=20 > >>> > >>> > >>> those ones. > >>> > >>>> The current filter drafts talk about filtering unwanted or=20 > >>>> uninteresting information sent in a NOTIFY. They also talk about=20 > >>>> triggering of notifications when certain changes to the=20 > state of an=20 > >>>> event occur. > >>>> > >>>> Regards, > >>>> Hisham > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: ext Anders Lindgren C (HF/EAB) > >>>>> [mailto:anders.c.lindgren@ericsson.com] > >>>>> Sent: 02.July.2004 10:53 > >>>>> To: simple@ietf.org; Khartabil Hisham (Nokia-TP-MSW/Helsinki) > >>>>> Subject: simple-filter Max Size or Max number of=20 > element as filter > >>>>> criterias? > >>>>> > >>>>> > >>>>> Hi, > >>>>> The XML documents sent from the network to the client=20 > can be very=20 > >>>>> large or it can contains a very long sequence of=20 > elements ( e.g a=20 > >>>>> resource list with 1000 buddies) > >>>>> It will also exist different types of clients. Some clients can=20 > >>>>> specify a very large resource list and it will exist=20 > clients that=20 > >>>>> can not handle that large list. > >>>>> > >>>>> I have not found how a client can inform the network about how=20 > >>>>> large documents is can handle or how many elements of a certain=20 > >>>>> type it can handle. > >>>>> My question is now if this information can be regarded=20 > as filter=20 > >>>>> criterias and includes in this filter specification? > >>>>> > >>>>> Best regards > >>>>> > >>>>> Anders Lindgren Ericsson AB Sweden > >>>>> > >>>> > >> > >> _______________________________________________ > >> Simple mailing list > >> Simple@ietf.org > >> https://www1.ietf.org/mailman/listinfo/simple > >=20 > >=20 >=20 > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jul 7 08: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 IAA13857 for ; Wed, 7 Jul 2004 08: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 1BiBEw-0003tH-5H for simple-archive@ietf.org; Wed, 07 Jul 2004 08:09:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BiBDx-0003Vv-00 for simple-archive@ietf.org; Wed, 07 Jul 2004 08:08:30 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BiBCu-0002pW-00; Wed, 07 Jul 2004 08:07:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BiAlF-00050p-Uu; Wed, 07 Jul 2004 07:38:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BiACv-00061T-U7 for simple@megatron.ietf.org; Wed, 07 Jul 2004 07:03: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 HAA11092 for ; Wed, 7 Jul 2004 07:03: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 1BiACq-0004JJ-2C for simple@ietf.org; Wed, 07 Jul 2004 07:03:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BiABu-0003xB-00 for simple@ietf.org; Wed, 07 Jul 2004 07:02:19 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1BiAAw-0003Yx-00 for simple@ietf.org; Wed, 07 Jul 2004 07:01:18 -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 i67Axe218230; Wed, 7 Jul 2004 13:59:40 +0300 (EET DST) X-Scanned: Wed, 7 Jul 2004 13:59:39 +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 i67AxdCa003033; Wed, 7 Jul 2004 13:59:39 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00Jpokhc; Wed, 07 Jul 2004 13:59:36 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 i67AxaH13248; Wed, 7 Jul 2004 13:59:36 +0300 (EET DST) Received: from nokia.com ([172.21.42.108]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 7 Jul 2004 13:59:36 +0300 Message-ID: <40EBD798.9010400@nokia.com> Date: Wed, 07 Jul 2004 13:59:36 +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] RE: XCAP Directory: Large response ? References: <40EA0018.3080408@dynamicsoft.com> <40E5C2E1.50502@dynamicsoft.com> <40E903D2.2050703@nokia.com> <40EA0018.3080408@dynamicsoft.com> <5.1.0.14.0.20040706111036.023f5320@localhost> <40EB9AF4.2080209@nokia.com> <40EBD05A.9060003@dynamicsoft.com> In-Reply-To: <40EBD05A.9060003@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Jul 2004 10:59:36.0756 (UTC) FILETIME=[7E30B740:01C46411] Content-Transfer-Encoding: 7bit Cc: "Joel M. Halpern" , 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 Inline as well. My comments are prepended by M.G. Jonathan Rosenberg wrote: > inline. > > Miguel Garcia wrote: > >> Inline. >> >> Joel M. Halpern wrote: >> >>> I rather disagree with your summary. >>> 1) I am not at all convinced this is necessary, >> >> >> >> Well, this is not what some other folks thought. I can recall 4 or 5 >> folks arguing that this functionality is needed. > > > I think "pagination" is a reasonable requirement. It is definitely a new > one, in that it has not appeared in our requirements document: > http://www.jdrosen.net/papers/draft-ietf-simple-data-req-03.txt > > My definition of pagination is that this is a feature specific to > resource lists. The feature allows the client to request any number of > items (which include entries, lists, or entry references) at each level. > Thus, if a user has a two-level hierarchical list, the user could get > the first level, and see it on their phone. They can then select one of > the lists on the first level, and the phone will get pages of that list. > > This approach is achievable as well. M.G: I agree that the "pagination" requirement is applicable to resource lists, but it is also applicable to XCAP directory lists. Actually, the whole discussion (see the title of this e-mail) started with the XCAP directory lists. In general, the requirement is applicable whenever an XML element can be infinitely repeated in an XML document. > >>> And if you try to say "I want X elements, just start counting from >>> the starting point." then there is no way that the result can >>> confidently be a valid XML document or meaningful portion of a >>> document according to a schema. It will take some interesting work >>> to even make it well-formed XML under that constraint. >> >> >> >> Disagree. I can safely say "please send me X elements in a valid XML >> document". The XML document is valid no matter whether it contains 1 >> or a milillion elements in it. The XCAP server is responsible to >> create a valid XML document according to the schema, including the >> "appropriate" number of elements. > > > No. This is not possible. Joel is correct - you cannot have an algorithm > for getting X elements of an arbitrary XML document which results in a > document that is schema valid. Let me give you an example. Lets say I > have the following schema: > > > elementFormDefault="qualified" attributeFormDefault="unqualified"> > > > > > > > > > > > > > This schema *requires* that the element have three children, el1, > el2 and el3. If you ask for a version of this document with no more > than two elements, it cannot be done in a way that results in a schema > compliant document. M.G: Yes, you are right. IF the schema mandates the presence of a number of elements, those must be present, and cannot be restricted by a range. I am not trying to change that behaviour. I think the precondition for requesting a range of elements is that the elemnt is defined with the fololowing attributes minOccurs="0" maxOccurs="unbounded" This is what happens with the , , elements in the resource list, and the element in the XCAP directory list. In this way, the schema is always respected independently of the range of requested elements. > >> >> We are doing the same with presence documents, whereby the presence >> server creates an XML document with the appropriate number of tuples >> and extensions, according to the authorizationn rules, policy, >> filters, etc. So if we can do it with a presence server, we can do it >> with an XCAP server. > > > This "pagination" concept you are interested in is only meaningful for > specific XML document formats, where there is a natural place in the > schema were an arbitrary number of elements can be present. This is NOT > a general XML, XCAP or HTTP feature. M.G: I agree. >> >>> >>> Now, if we add the filter definition Hisham has suggested, we at >>> least have a behaviors that is well defined and can produce >>> meaningful results. It even matches a useful and understandable >>> problem. However, it is a big change in the semantics of HTTP GET as >>> far as I can tell. It starts falling into the trap of using HTTP as >>> a generic transport. Will it work through relays? >> >> >> >> It will work with proxies, although I agree that is extending somehow >> the semantics of the GET method in HTTP. Having said that, I don't see >> Hisham's proposal fulfills the requirements. It assumes that you know >> in advance the XML document, and then you apply a filter. It requires >> you to know the values you are trying to filter. We don't want to >> filter based on values, but based on the number of elements >> present in the XML document. Therefore, I don't think adding a filter >> to the GET request will solve the problem. > > > As I posted in a separate note, I see no point in including filters in > the HTTP requests. Hisham - what does this add beyond what the URI can > already too? I know what it takes away - it takes away our ability to > use PUT, which will mean that we are back to a custom protocol. That is > definitely months of additional delay. I see no value in doing this. M.G: I agree. > -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 Wed Jul 7 08:13: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 IAA14097 for ; Wed, 7 Jul 2004 08:13: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 1BiBIs-0005K3-Lf for simple-archive@ietf.org; Wed, 07 Jul 2004 08:13:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BiBHu-0004xO-00 for simple-archive@ietf.org; Wed, 07 Jul 2004 08:12:35 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BiBH7-0004Su-00; Wed, 07 Jul 2004 08:11:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BiAlk-00056v-B0; Wed, 07 Jul 2004 07:39:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BiAEu-0006Ig-Tu for simple@megatron.ietf.org; Wed, 07 Jul 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 HAA11159 for ; Wed, 7 Jul 2004 07:05: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 1BiAEn-00050M-H0 for simple@ietf.org; Wed, 07 Jul 2004 07:05:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BiADo-0004fF-00 for simple@ietf.org; Wed, 07 Jul 2004 07:04:17 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BiACt-000406-00 for simple@ietf.org; Wed, 07 Jul 2004 07:03:19 -0400 Received: from dynamicsoft.com ([63.113.46.28]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i67B37bo006902; Wed, 7 Jul 2004 07:03:07 -0400 (EDT) Message-ID: <40EBD858.2030301@dynamicsoft.com> Date: Wed, 07 Jul 2004 07:02: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: hisham.khartabil@nokia.com Subject: Re: [Simple] RE: simple-filter Max Size or Max number of element asfilter cri terias? References: <2038BCC78B1AD641891A0D1AE133DBB7023EEAD7@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB7023EEAD7@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: Miguel.An.Garcia@nokia.com, anders.c.lindgren@ericsson.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: > I was suggesting it as an HTTP extension, not an XCAP extension. I don't understand how this is an HTTP extension. Its XML specific. I also dont understand what is gained, in terms of xcap, from doing it this way instead of just including the actual xpath expression into the XCAP URI. What features does the filter document provide, that we need in xcap, beyond the xpath filering expression? -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 Jul 7 08:28: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 IAA14844 for ; Wed, 7 Jul 2004 08:28: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 1BiBXB-0002dP-9z for simple-archive@ietf.org; Wed, 07 Jul 2004 08:28:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BiBWB-0002JK-00 for simple-archive@ietf.org; Wed, 07 Jul 2004 08:27:20 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BiBVC-0001h9-00; Wed, 07 Jul 2004 08:26:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BiB4J-0001UI-AT; Wed, 07 Jul 2004 07:58:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BiAgH-0003oP-J5 for simple@megatron.ietf.org; Wed, 07 Jul 2004 07:33: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 HAA12317 for ; Wed, 7 Jul 2004 07:33:34 -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 1BiAgC-0006xL-1R for simple@ietf.org; Wed, 07 Jul 2004 07:33:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BiAf4-0006bX-00 for simple@ietf.org; Wed, 07 Jul 2004 07:32:27 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BiAeC-0006G6-00 for simple@ietf.org; Wed, 07 Jul 2004 07:31: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 i67BVVN28840 for ; Wed, 7 Jul 2004 14:31:31 +0300 (EET DST) X-Scanned: Wed, 7 Jul 2004 14:31:21 +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 i67BVLb8005681 for ; Wed, 7 Jul 2004 14:31:21 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00cnm66J; Wed, 07 Jul 2004 14:31:20 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 i67BVKH01461 for ; Wed, 7 Jul 2004 14:31:20 +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, 7 Jul 2004 14:31:11 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 7 Jul 2004 14:31:11 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [Simple] WGLC: Event Filtering Date: Wed, 7 Jul 2004 14:31:10 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7023EEAD8@esebe019.ntc.nokia.com> Thread-Topic: [Simple] WGLC: Event Filtering Thread-Index: AcRetS+6gkZh4cbWRPmITzYUThfuYwD0faTgAGB0OFA= To: , X-OriginalArrivalTime: 07 Jul 2004 11:31:11.0333 (UTC) FILETIME=[E7723950:01C46415] 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 Eva, and thanks for the comments. Responses inline... > -----Original Message----- > From: simple-bounces@ietf.org=20 > [mailto:simple-bounces@ietf.org]On Behalf > Of ext eva-maria.leppanen@nokia.com > Sent: 05.July.2004 15:06 > To: rsparks@dynamicsoft.com; simple@ietf.org; Khartabil Hisham > (Nokia-TP-MSW/Helsinki) > Subject: RE: [Simple] WGLC: Event Filtering >=20 >=20 > Hi, >=20 > Please find below some comments to the filter-format-01 draft: >=20 > In the beginning of the subsection 3.3.1 ("include") it is=20 > said that an XML attribute can be selected as content to be=20 > delivered. However, it is not clear how the selection of the=20 > attribute is done in practise (e.g., if the "type"=20 > attribute's value 'XML element' is used), and what it means=20 > to indicate an XML attribute in the . I was thinking of changing the type value from "xml-element" to "xpath" = to cover both attribute and element cases. Is that satisfactory? >=20 > The meaning of the sentence 3.3.1: "The element=20 > MUST identify one element only, unless the conditional=20 > expression results in more than one element with the same=20 > name being identified." is a bit unclear.=20 Will clarify. >=20 > 3.3.1: "... all other mandatory XML elements and/or=20 > attributes must be incorporated in the resulting XML=20 > document...": are e.g. optional XML attributes of mandatory=20 > XML elements incorporated or not?' No. I think the text is clear, I you read the paragraph until the end. " in addition to including the elements identified with the element, all other mandatory XML elements and/or attributes must be incorporated in the resulting XML document in order to make it valid. This, in practice, means that a subscriber defining a filter only needs to optional elements and/or attributes, but may mandatory elements and/or attributes as well." >=20 > 3.3.1 (example): "The following example selects the =20 > element defined in PIDF XML document [11]. This results in=20 > the selection of all the ancestors of . I.e. =20 > and ." -> I'd rephrase the texts something like this:=20 > "The following example selects the element defined=20 > in PIDF [11]. This also results in the selection of all=20 > mandatory elements related to the , i.e. and ." Done. >=20 > 3.3.1.1: "The syntax is defined in a way ..." -> I'd add a=20 > sentence for clarifying the context of the syntax, e.g.=20 > something like "The 'xml-element' value is used when the=20 > element identifies XML elements. The syntax is=20 > defined in a way..." I clarified and moved the text and this example to section 3.3.1. >=20 > 3.3.1.1.: It'd be good to have at least one example of the=20 > selection of an XML attribute. Added. >=20 > 3.3.2: it'd be good to add e.g. a note about vs.=20 > mandatory XML element. I put a reference to the section. >=20 > 3.3.2: the last sentence is basically unnecessary since=20 > earlier in the draft it is said that the element must=20 > contain at least one . Removed. >=20 > 5.1.(examples) The text talks about first and 2nd filter=20 > definition even if there is only one. Additionally,=20 > the filter definition should contain=20 > "xmlns:simple-filter=3D"urn:ietf:params:xml:ns:simple-filter" +=20 > similar definitions for pidf and rpid prefixes. I don't think this is how it works. The namespaces do not apply to = element values. To solve this problem, we need to define a new element = that carries prefixes. > Also the=20 > element could have the "simple-filter" prefix as=20 > also other XML elements seems to have it. This comment=20 > applies to all the filter definition examples. I don't believe this is right. >=20 > 5.3: The xml document could be corrected as follows: needed=20 > namespace prefixes to be defined; "//" to be added to the=20 > first ; is there something wrong in=20 > "//wi:watcher/@wi:status@status"; Fixed. > the trigger part contains=20 > two elements, but isn't it so the trigger never=20 > matches if the AND operation is applied to the elements. >=20 > 6. (XML Schema) Shouldn't the value "token" be removed from=20 > "TypeType" definition? Yes. >=20 > 7. (security) "... more than 20 occurences of the =20 > ...." -> because there can be only one element per=20 > wouldn't it be more appropriate to list e.g. the=20 > and/or element instead? Yes. >=20 > Other minor issues: > - names of RPID elements should be updated in the filtering=20 > XML document examples Can you be more specific? I only found 1 where "type" was used as an = RPID element name. > - usage of ' vs. " could be aligned through the whole draft How? > - 5.2.: "... when a certain PIDF [11] tuple changes its=20 > status from 'closed' to 'open'" -> maybe "tuple=20 > changes its" part could be rephrased=20 OK. > - 5.2: the xmlns definition ends with double "" -> should be only one Done. Thanks, Hisham >=20 > BR, Eva >=20 > > -----Original Message----- > > From: simple-bounces@ietf.org=20 > > [mailto:simple-bounces@ietf.org]On Behalf > > Of ext Robert Sparks > > Sent: 30 June, 2004 18:07 > > To: simple@ietf.org > > Cc: Khartabil Hisham (Nokia-TP-MSW/Helsinki) > > Subject: [Simple] WGLC: Event Filtering > >=20 > >=20 > > This is a SIMPLE working group last call for the following drafts: > >=20 > > http://www.ietf.org/internet-drafts/draft-ietf-simple-filter-f > > ormat-01.txt > > http://www.ietf.org/internet-drafts/draft-ietf-simple-event-fi > lter-funct-01.txt >=20 > Please provide comments to the list or chairs by July 16. >=20 > Thanks, > RjS >=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 From simple-bounces@ietf.org Wed Jul 7 08:54: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 IAA16570 for ; Wed, 7 Jul 2004 08:54: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 1BiBwR-0003hT-N9 for simple-archive@ietf.org; Wed, 07 Jul 2004 08:54:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BiBvW-0003Ll-00 for simple-archive@ietf.org; Wed, 07 Jul 2004 08:53:31 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BiBuh-0002eY-00; Wed, 07 Jul 2004 08:52:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BiBO2-00060X-Cx; Wed, 07 Jul 2004 08:18:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BiAuY-0007Xs-Ho for simple@megatron.ietf.org; Wed, 07 Jul 2004 07: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 HAA12851 for ; Wed, 7 Jul 2004 07:48: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 1BiAuS-0004Cq-VS for simple@ietf.org; Wed, 07 Jul 2004 07:48:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BiAtX-0003sv-00 for simple@ietf.org; Wed, 07 Jul 2004 07:47:24 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BiAt0-0003ZK-00 for simple@ietf.org; Wed, 07 Jul 2004 07:46:50 -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 i67BkHN18640; Wed, 7 Jul 2004 14:46:17 +0300 (EET DST) X-Scanned: Wed, 7 Jul 2004 14:46:07 +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 i67Bk7fa020324; Wed, 7 Jul 2004 14:46:07 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00vig6RR; Wed, 07 Jul 2004 14:46:05 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 i67Bk4H27468; Wed, 7 Jul 2004 14:46: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, 7 Jul 2004 14:46:01 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [Simple] RE: simple-filter Max Size or Max number of element asfilter cri terias? Date: Wed, 7 Jul 2004 14:46:00 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7023EEADB@esebe019.ntc.nokia.com> Thread-Topic: [Simple] RE: simple-filter Max Size or Max number of element asfilter cri terias? Thread-Index: AcRkEhTsrFZA/j3mT86M5ibuzGxxCAABTKyQ To: X-OriginalArrivalTime: 07 Jul 2004 11:46:01.0340 (UTC) FILETIME=[F9EE83C0:01C46417] Content-Transfer-Encoding: quoted-printable Cc: Miguel.An.Garcia@nokia.com, anders.c.lindgren@ericsson.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: 07.July.2004 14:03 > To: Khartabil Hisham (Nokia-TP-MSW/Helsinki) > Cc: Garcia Miguel.An (Nokia-NRC/Helsinki); > anders.c.lindgren@ericsson.com; simple@ietf.org > Subject: Re: [Simple] RE: simple-filter Max Size or Max number of > element asfilter cri terias? >=20 >=20 >=20 >=20 > hisham.khartabil@nokia.com wrote: >=20 > > I was suggesting it as an HTTP extension, not an XCAP extension. >=20 > I don't understand how this is an HTTP extension. Its XML specific. So what if it is XML specific. A similar argument can be said about = event notification filtering: Do you really believe that all event = notification packages will be defined in XML? >=20 > I also dont understand what is gained, in terms of xcap, from=20 > doing it=20 > this way instead of just including the actual xpath=20 > expression into the=20 > XCAP URI. What features does the filter document provide,=20 > that we need=20 > in xcap, beyond the xpath filering expression? Probably nothing is gained. I was just pointing to another way of = satisfying the requirement, but with a more general solution not = specific to XCAP. Anyway, it people believe it is too heavy, then I withdraw my = suggestion. /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 Jul 7 09:21: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 JAA17806 for ; Wed, 7 Jul 2004 09:21: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 1BiCMU-0005Fz-D0 for simple-archive@ietf.org; Wed, 07 Jul 2004 09:21:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BiCLZ-0004uw-00 for simple-archive@ietf.org; Wed, 07 Jul 2004 09:20:25 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BiCKh-0004GH-00; Wed, 07 Jul 2004 09:19:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BiBsd-0004lN-PD; Wed, 07 Jul 2004 08:50:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BiBKy-0005QA-Rl for simple@megatron.ietf.org; Wed, 07 Jul 2004 08:15: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 IAA14263 for ; Wed, 7 Jul 2004 08:15: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 1BiBKj-00060O-D3 for simple@ietf.org; Wed, 07 Jul 2004 08:15:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BiBJn-0005fz-00 for simple@ietf.org; Wed, 07 Jul 2004 08:14:32 -0400 Received: from ns.execdsl.net ([208.184.15.238] helo=EXECDSL.COM) by ietf-mx with esmtp (Exim 4.12) id 1BiBJ4-0005KJ-00 for simple@ietf.org; Wed, 07 Jul 2004 08:13:46 -0400 Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 7170542; Wed, 07 Jul 2004 08:13:36 -0400 Message-Id: <5.1.0.14.0.20040707080624.023eb198@localhost> X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 07 Jul 2004 08:13:20 -0400 To: Miguel Garcia From: "Joel M. Halpern" Subject: Re: [Simple] RE: XCAP Directory: Large response ? In-Reply-To: <40EB9AF4.2080209@nokia.com> References: <5.1.0.14.0.20040706111036.023f5320@localhost> <40EA0018.3080408@dynamicsoft.com> <40E5C2E1.50502@dynamicsoft.com> <40E903D2.2050703@nokia.com> <40EA0018.3080408@dynamicsoft.com> <5.1.0.14.0.20040706111036.023f5320@localhost> Mime-Version: 1.0 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 This mechanism for synthesizing a subset document happens to work with the schemas we are using. Here are two examples of problems. Given a schema that said that foo elements can have any number of bar element children, followed by a baz element, it could get very difficult to synthesize a proper document. Suppose that the real document had inside the foo 8 bars, followed by the required baz. And you ask for 5 elements starting with foo. Do you really expect the server to give you a document with a foo containing 3 bar and a baz? Suppose that the schema has more nesting than one would like, and foo1 elements are required to contain foo2 elements, which are required to contain foo3 elements. And you ask for 2 elements starting at foo1. There is no valid document of two elements (by your counting) that the server can return. And these are not the most complex cases that can. I do not want to make XCAP into a full database mechanism, but I also do not want to overly constrain the schemas it can apply to. I think that trying to constrain the length of an XML document by the number of elements in it is simply incompatible with returning something that is schema valid, even according to a sensible fragment schema. Yours, Joel M. Halpern At 09:40 AM 7/7/2004 +0300, Miguel Garcia wrote: >>And if you try to say "I want X elements, just start counting from the >>starting point." then there is no way that the result can confidently be >>a valid XML document or meaningful portion of a document according to a >>schema. It will take some interesting work to even make it well-formed >>XML under that constraint. > >Disagree. I can safely say "please send me X elements in a valid XML >document". The XML document is valid no matter whether it contains 1 or a >milillion elements in it. The XCAP server is responsible to create a valid >XML document according to the schema, including the "appropriate" number >of elements. > >We are doing the same with presence documents, whereby the presence server >creates an XML document with the appropriate number of tuples and >extensions, according to the authorizationn rules, policy, filters, etc. >So if we can do it with a presence server, we can do it with an XCAP server. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jul 7 10:00: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 KAA20267 for ; Wed, 7 Jul 2004 10:00: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 1BiCyQ-0003jk-8m for simple-archive@ietf.org; Wed, 07 Jul 2004 10:00:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BiCxU-0003OV-00 for simple-archive@ietf.org; Wed, 07 Jul 2004 09:59:37 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BiCwf-0002jL-00; Wed, 07 Jul 2004 09:58:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BiCWd-000684-1q; Wed, 07 Jul 2004 09:31:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BiC4F-0007XR-0G for simple@megatron.ietf.org; Wed, 07 Jul 2004 09:02: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 JAA16988 for ; Wed, 7 Jul 2004 09:02: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 1BiC49-0006YW-CO for simple@ietf.org; Wed, 07 Jul 2004 09:02:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BiC3B-0006DM-00 for simple@ietf.org; Wed, 07 Jul 2004 09:01:26 -0400 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1BiC2H-0005tD-00 for simple@ietf.org; Wed, 07 Jul 2004 09:00:30 -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 i67Cug612649; Wed, 7 Jul 2004 15:56:42 +0300 (EET DST) X-Scanned: Wed, 7 Jul 2004 15:56:36 +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 i67CuacB001998; Wed, 7 Jul 2004 15:56:36 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00EREA9a; Wed, 07 Jul 2004 15:56:34 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 i67CuTH22869; Wed, 7 Jul 2004 15:56:29 +0300 (EET DST) Received: from nokia.com ([172.21.42.108]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 7 Jul 2004 15:55:21 +0300 Message-ID: <40EBF2B9.3030009@nokia.com> Date: Wed, 07 Jul 2004 15:55:21 +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: "Joel M. Halpern" Subject: Re: [Simple] RE: XCAP Directory: Large response ? References: <5.1.0.14.0.20040706111036.023f5320@localhost> <40EA0018.3080408@dynamicsoft.com> <40E5C2E1.50502@dynamicsoft.com> <40E903D2.2050703@nokia.com> <40EA0018.3080408@dynamicsoft.com> <5.1.0.14.0.20040706111036.023f5320@localhost> <5.1.0.14.0.20040707080624.023eb198@localhost> In-Reply-To: <5.1.0.14.0.20040707080624.023eb198@localhost> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Jul 2004 12:55:21.0630 (UTC) FILETIME=[A9A863E0:01C46421] 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 Inline. Joel M. Halpern wrote: > This mechanism for synthesizing a subset document happens to work with > the schemas we are using. Here are two examples of problems. > > Given a schema that said that foo elements can have any number of bar > element children, followed by a baz element, it could get very difficult > to synthesize a proper document. > Suppose that the real document had inside the foo 8 bars, followed by > the required baz. And you ask for 5 elements starting with foo. > Do you really expect the server to give you a document with a foo > containing 3 bar and a baz? In the example you are describing, the XCAP client will request 5 bar elements, that is, will place a limit in the number of bar elements, but not on the baz element, since it is mandatory by the schema (remember, the XCAP client knows the schema). So the XCAP server will build an XML document that contains 5 bar elements and 1 baz element, and any other mandated element. We are doing the same with attributes. If an attribute is mandatory by the schema, I don't need to request it, I just request the element. > Suppose that the schema has more nesting than one would like, and foo1 > elements are required to contain foo2 elements, which are required to > contain foo3 elements. And you ask for 2 elements starting at foo1. > There is no valid document of two elements (by your counting) that the > server can return. I indicated in a previous e-mail that the precondition to be able to request ranges of elements is that the element is declared with attributes minOccurs="0" maxOccurs="unbounded" in the schema. Certainly, this does not match your example, because foo2 elements will be declared with minOccurse="1" (you said it is required to contain foo2 elements, which I interpret as 'at least 1 must be present'). What is clear is that we need to define the rules under which an XCAP client can request pagination. > And these are not the most complex cases that can. > I do not want to make XCAP into a full database mechanism, but I also do > not want to overly constrain the schemas it can apply to. It is not a matter of turning XCAP into this or that, it is a matter into making XCAP a useful protocol. Without this feature I doubt XCAP can be widely deployed in mobile devices. > I think that trying to constrain the length of an XML document by the > number of elements in it is simply incompatible with returning something > that is schema valid, even according to a sensible fragment schema. I disagree. I believe it is possible. Or do you think that when you read e-mail through a web interface you are getting unvaild HTML documents? Of course not. So the same logic can be applied to XML documents. I also believe we need to set the rules for the XCAP client to determine when it can request pagination. - Miguel > Yours, > Joel M. Halpern > > At 09:40 AM 7/7/2004 +0300, Miguel Garcia wrote: > >>> And if you try to say "I want X elements, just start counting from >>> the starting point." then there is no way that the result can >>> confidently be a valid XML document or meaningful portion of a >>> document according to a schema. It will take some interesting work >>> to even make it well-formed XML under that constraint. >> >> >> Disagree. I can safely say "please send me X elements in a valid XML >> document". The XML document is valid no matter whether it contains 1 >> or a milillion elements in it. The XCAP server is responsible to >> create a valid XML document according to the schema, including the >> "appropriate" number of elements. >> >> We are doing the same with presence documents, whereby the presence >> server creates an XML document with the appropriate number of tuples >> and extensions, according to the authorizationn rules, policy, >> filters, etc. So if we can do it with a presence server, we can do it >> with an XCAP server. > > -- 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 Jul 7 10:18: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 KAA22062 for ; Wed, 7 Jul 2004 10:18: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 1BiDG0-0002C4-GS for simple-archive@ietf.org; Wed, 07 Jul 2004 10:18:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BiDEs-0001l2-00 for simple-archive@ietf.org; Wed, 07 Jul 2004 10:17:35 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BiDE2-0001QU-00; Wed, 07 Jul 2004 10:16:42 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BiDDj-0002OZ-E2; Wed, 07 Jul 2004 10:16:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BiCro-00035S-Cp; Wed, 07 Jul 2004 09:53:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bi2X4-0001Ya-3q for simple@megatron.ietf.org; Tue, 06 Jul 2004 22:51: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 WAA15354 for ; Tue, 6 Jul 2004 22: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 1Bi2Ws-0005NX-6V for simple@ietf.org; Tue, 06 Jul 2004 22:51:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bi2Vx-00050G-00 for simple@ietf.org; Tue, 06 Jul 2004 22:50:30 -0400 Received: from voodoo.izone.net.au ([202.160.129.225]) by ietf-mx with esmtp (Exim 4.12) id 1Bi2Ul-0004YY-00 for simple@ietf.org; Tue, 06 Jul 2004 22:49:15 -0400 Received: from Home (dialup-191.28.221.203.acc11-dryb-mel.comindico.com.au [203.221.28.191]) by voodoo.izone.net.au (Postfix) with SMTP id 92DDB5D9D0; Wed, 7 Jul 2004 12:44:03 +1000 (EST) Message-ID: <060f01c463cc$3d1549a0$b631c2cb@Home> From: "Barry Dingle" To: "Gunnar Hellstrom" , "Arnoud van Wijk" References: Subject: Re: Tiny ant vs big Mammoths, was RE: [Simple] Using MSRP for real time text conversation Date: Wed, 7 Jul 2004 12:43:39 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-AFFINITYINTERNET-MailScanner-Information: Please contact support on 1300 85 75 65 for more information X-AFFINITYINTERNET-MailScanner: Found to be clean X-MailScanner-From: barry.dingle@bigfoot.com.au Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 07 Jul 2004 09:53:42 -0400 Cc: stf267@etsi.org, 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=1.1 required=5.0 tests=MAILTO_TO_SPAM_ADDR autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Some thoughts on this subject. I approach this from a Service level. Real time or near real time text service is essential for some legislative environments eg. Australia where 'equivalent' service to telephony is defined for people who cannot effectively use telephony. Use of mainstream protocols is important for the disabled community in order that they can communicate with all people not just amongst people with the same special terminals. MSRP provides a very useful mainstream, text communication service. It provides a different 'user feel' to a character-by-character service. Its performance could improve over time. text/t140 (RFC2793) is an important near real time text service that is consistent with traditional multimedia services and with the SIP controlled real time multiservice environment. Choice is important for users so that we do not get locked into one service if a better service becomes available. Therefore negotiation is essential. Both MSRP and rfc2793 work with SIP/SDP so negotiation should not be too difficult. Cheers, Barry DINGLE Telecommunications Consultant Project Manager - ACIF Any-to-Any Text Connectivity Options WG Fellow of the University of Melbourne barry.dingle@bigfoot.com.au Mob: +61 (0)41 911 7578 Fixed: +61 (0)3 9725 3937 ----- Original Message ----- From: "Gunnar Hellstrom" To: "Arnoud van Wijk" Cc: ; ; Sent: Tuesday, July 06, 2004 4:22 PM Subject: RE: Tiny ant vs big Mammoths, was RE: [Simple] Using MSRP for real time text conversation > I opened a new thread under the name > > RE: [Simple] Using MSRP for (pseudo?) real time text conversation > > For discussing conclusions and negotiation. > Hope you all will join there. > > I agree with Arnoud in the impression that any user you show real time text conversation > to, say that it is very good and needed in future services. > > So, please look for the new subject line and start thinking about what inter-relations > that are needed do declare and negotiate what text service you can and want to use. And > answer these messages, so that we get back to one thread. > > 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: owner-toip@snowshore.com [mailto:owner-toip@snowshore.com]On > >Behalf Of Arnoud van Wijk > >Sent: Sunday, July 04, 2004 11:32 AM > >To: hisham.khartabil@nokia.com; Henry.Sinnreich@mci.com; > >dean.willis@softarmor.com > >Cc: bcampbell@dynamicsoft.com; gunnar.hellstrom@omnitor.se; > >adam@dynamicsoft.com; stf267@etsi.org; simple@ietf.org; > >toip@snowshore.com > >Subject: RE: Tiny ant vs big Mammoths, was RE: [Simple] Using MSRP for > >real time text conversation > > > > > >Hisham, > >Actually... > >I did some market research. Based on 15 people. > >3 deaf, 5 worked in deaf related business (hearing people) > >And 7 don't care about deaf (2 of them are IM freaks). > > > >Result: > > > >First telling them about total conversation and Interactive text > >(text/t140). > >It did not mean much to them, they looked glassy eyed. Real-time charcter > >per character..oh Yawn... lovely... pish posh. They could not imagine it. No > >concept of it. > > > >Then I showed them. > >They could communicate with somebody in Sweden, and with me on a different terminal in a different room. > >All were deeply impressed. > > > >The 3 deaf wanted to take it home right now. Being able to communicate everywhere , everytime..finally free! > >The 5 who worked in the deaf business, they loved it and want to see it implemted and mainstream. They love it and will use it regularly to > >communicate with deaf and some even say that it can be quite convenient for hearing people as well. > > > >The 7 hearing, non deaf related liked it too! > >They said, wow... this is much more direct then IM, you can actually call people in situations where voice is a bit not done (think cinema, concert, > >restaurant, train). They see it as direct real-time IM. > >They will keep using IM anyway. But see uses for text/t140 too and will use it if it is convenient. > >The 2 IM freaks agreed, though they prefer IM, but if somebdoy contacts them via interactive text text/t140, they will use it too. > >"It depends who to contact to use the right text communication method. I like the choice to have an alternative". > > > >So. Yes.. I know people will like it. Not everybody will use interactive text. Some will thus only use if somebody else uses it, whether a deaf > >person or one who likes to use text/t140. > > > >All of them hope that interactive text will be mainstream and will use it with varying degrees, from sometimes, to daily. > > > >So, this is my message, from an interactive text user AND having showed/demonstrated interactive text to other people. It is not my desire > >only. > > > >Greetz > > > >Arnoud > > > >-----Original Message----- > >From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > >Sent: vrijdag 2 juli 2004 9:19 > >To: a.vwijk@viataal.nl; Henry.Sinnreich@mci.com; dean.willis@softarmor.com > >Cc: bcampbell@dynamicsoft.com; gunnar.hellstrom@omnitor.se; > >adam@dynamicsoft.com; stf267@etsi.org; simple@ietf.org; toip@snowshore.com > >Subject: RE: Tiny ant vs big Mammoths, was RE: [Simple] Using MSRP for real > >time text conversation > > > >Arnoud, > > > >You speak as if you have done the market research already for all of us :) > >How do you know that people will appreciate it once they discover it? How do > >you know that people will use it? How do you know that it adds value to the > >phone instead of just implementing something that no one will use? How do > >you know that if I like interactive text, then my mum and dad will and buy a > >phone like mine just to use interactive text???? How do you know...? > > > >Did people complain to you that IM the way it is these days in annoying to > >use? or are you just stating your opinion? > > > >And about mobile phones. If you can type an SMS faster than 2 characters a > >second, you're a genius. Even if you can, I don't believe operators would > >want to floor they scarce air interface with IP packets that carry 2 > >characters at a time. > > > >Thanks, > >Hisham > > > > > >- > >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 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 Wed Jul 7 10:27: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 KAA22730 for ; Wed, 7 Jul 2004 10:27: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 1BiDOV-0005N3-Vz for simple-archive@ietf.org; Wed, 07 Jul 2004 10:27:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BiDNa-00051p-00 for simple-archive@ietf.org; Wed, 07 Jul 2004 10:26:34 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BiDN0-0004gc-00; Wed, 07 Jul 2004 10:25:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BiCxZ-0004UO-BX; Wed, 07 Jul 2004 09:59:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BiCaO-0006vd-N8 for simple@megatron.ietf.org; Wed, 07 Jul 2004 09:35: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 JAA18884 for ; Wed, 7 Jul 2004 09:35: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 1BiCaJ-0002fM-4D for simple@ietf.org; Wed, 07 Jul 2004 09:35:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BiCZV-0002KU-00 for simple@ietf.org; Wed, 07 Jul 2004 09:34:49 -0400 Received: from viap106.atea.be ([194.78.143.106] helo=hrtades9.atea.be) by ietf-mx with esmtp (Exim 4.12) id 1BiCYb-0001ux-00 for simple@ietf.org; Wed, 07 Jul 2004 09:33:53 -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 3LDZFYHS; Wed, 7 Jul 2004 15:33:20 +0200 Received: by siemens.atea.be with Internet Mail Service (5.5.2653.19) id <33CG7A8F>; Wed, 7 Jul 2004 15:33:20 +0200 Message-ID: <6B546A602AD2D211BFF00008C7A428890B1E28D2@hrtades2.atea.be> From: Biot Olivier To: Simple WG Date: Wed, 7 Jul 2004 15:33:19 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [Simple] XCAP and multiple edits by multiple users X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org 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 Hi list, Although the SIMPLE WG strongly favours not inventing a new protocol for implementing XCAP, I think some issues being regularly discussed suggest it is time to think about adding an extension to the envisaged HTTP framework. Consider the following issues: 1. Can multiple users safely edit the same application usage? 2. Can multiple edits be safely applied "atomically" by one user? I think a simple solution for dealing with both issues is implementing a time-based resource locking mechanism, similar to the what the SIP Expires header provides. (Unfortunately HTTP states that the Expires header must contain a HTTP-date so it is not suitable for this proposal. For this reason, this header is named "expires" in this text.) The idea I have in mind is that one XCAP client is allowed to LOCK or RESERVE a resource for a specific time (seconds) as specified in the request's "expires" header. The XCAP server can either accept or reject this request, and may modify the amount of time the resource has a "write lock" on it, by means of the "expires" response header. The locked resource is unlocked after the specified time or after the client issued an UNLOCK or RELEASE request on the resource. Note that this request does not need to be implemented as an HTTP method, but could be communicated by means of a "expires" header with value zero. As long as the resource is locked, the validity of the lock must be communicated and may be renegotiated between client and server, by means of this "expires" header. If another XCAP client wishes to edit the currently locked resource, the XCAP server could issue a 503 response with a Retry-After response header informing the XCAP client when it may reissue the same request. If multiple edits have to be implemented as an atomic operation where each operation must succeed, a final "commit" or "roll-back" must be possible. A commit would happen at the same time a new Entity Tag is being computed for the new resource, at the time the lock will either be released or will expire. A "roll-back" should apply from the moment the first error appreared. After a commit or a roll-back, the new ETag is computed and the lock is released; this is communicated by sending the Etag and an "expires" response header with 0 (zero) as value. This approach renders the use of the ETag useless between subsequent XCAP operations on the same locked entity. I am however not really opposed to sending intermediate ETag values to the manipulating client. In order to distinguish between singular XCAP operations and operations on a locked resource, the XCAP server should respond with a 202 status instead of a 200, which means that the client may continue with the next request. I understand that this proposal adds at least one HTTP method (LOCK or RESERVE) and one HTTP header (similar to the SIP Expires header), and that (because of this) XCAP would not be 100% standard HTTP anymore. Additionally, a "lock war" denial-of-service security breach can be seen in this approach. However I'd like to know whether this apporach makes sense, maybe as a future extension to "vanilla" XCAP. If I overlooked something, please let me know. Regards, Olivier _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jul 7 10:40: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 KAA23276 for ; Wed, 7 Jul 2004 10:40: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 1BiDbE-0001ro-AX for simple-archive@ietf.org; Wed, 07 Jul 2004 10:40:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BiDaM-0001J1-00 for simple-archive@ietf.org; Wed, 07 Jul 2004 10:39:48 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BiDYd-0000rt-00; Wed, 07 Jul 2004 10:37:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BiD9r-0003F6-R8; Wed, 07 Jul 2004 10:12:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BiCgw-0000I7-Ln for simple@megatron.ietf.org; Wed, 07 Jul 2004 09:42: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 JAA19081 for ; Wed, 7 Jul 2004 09:42: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 1BiCgq-0004yW-Mi for simple@ietf.org; Wed, 07 Jul 2004 09:42:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BiCg3-0004dd-00 for simple@ietf.org; Wed, 07 Jul 2004 09:41:37 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BiCew-0004HT-00 for simple@ietf.org; Wed, 07 Jul 2004 09:40:26 -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 i67DeLN25613 for ; Wed, 7 Jul 2004 16:40:21 +0300 (EET DST) X-Scanned: Wed, 7 Jul 2004 16:40:16 +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 i67DeGST006529 for ; Wed, 7 Jul 2004 16:40:16 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00NA9TAI; Wed, 07 Jul 2004 16:40:14 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 i67DeEH20564 for ; Wed, 7 Jul 2004 16:40:14 +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); Wed, 7 Jul 2004 16:40:13 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 7 Jul 2004 16:40:14 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [Simple] WGLC: Event Filtering Date: Wed, 7 Jul 2004 16:40:13 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7023EEADD@esebe019.ntc.nokia.com> Thread-Topic: [Simple] WGLC: Event Filtering Thread-Index: AcRilqq3R+QB2ixxRQaw4/BzPEUlbgBgZV0A To: X-OriginalArrivalTime: 07 Jul 2004 13:40:14.0602 (UTC) FILETIME=[EECB4EA0:01C46427] 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 Miguel, Thanks for the comments. Responses inline... > -----Original Message----- > From: simple-bounces@ietf.org=20 > [mailto:simple-bounces@ietf.org]On Behalf > Of ext Miguel Garcia > Sent: 05.July.2004 15:46 > To: Robert Sparks > Cc: Costa-Requena Jose (Nokia-TP/Helsinki); Khartabil Hisham > (Nokia-TP-MSW/Helsinki); simple@ietf.org; Lonnfors Mikko > (Nokia-NRC/Helsinki); Leppanen Eva-Maria (Nokia-NET/Tampere) > Subject: Re: [Simple] WGLC: Event Filtering >=20 >=20 > Hi: >=20 > I am sorry for the long e-mail... Here are some comments to the=20 > filter-format-01.txt draft. >=20 >=20 >=20 > - Section 3, first paragraph reads: >=20 > The filter criteria is an XML document [8] that MUST be=20 > well-formed > and MUST be valid. The filter criteria XML documents=20 > MUST have the > XML declaration and it SHOULD contain an encoding=20 > declaration in the > XML declaration, for example; " encoding=3D'UTF-8'?>". >=20 > First problem, why the document 'MUST be valid'? In other XML=20 > documents > created by SIMPLE the statement reads 'SHOULD be valid'. So why the > strength is higher in Filter Criteria documents? Ok, changed to SHOULD. >=20 > Second problem. I don't understand the value of the above=20 > sentence: 'XML > document MUST have the XML declaration' (of course, they are XML > documents) and 'SHOULD contain an encoding declaration'...=20 > but you don't > say what the encoding should be, so there is not point in=20 > indicating the > encoding declaration if you don't restrict it to some values. My > proposal is to align this statement with the rest of the XML documents > that SIMPLE is producing, and replace the above sentence with: >=20 > A filter criteria is an XML [3] document that MUST be > well-formed and SHOULD be valid. Filter criteria documents MUST > be based on XML 1.0 and MUST be encoded using UTF-8. Done. >=20 > - Section 3 states: >=20 > The namespace identifier for elements defined by this=20 > specification > is a URN [5], using the namespace identifier 'ietf' defined by [6] > and extended by [4]. This urn is: > urn:ietf:params:xml:ns:simple-filter+xml. >=20 > The namespace should be "urn:ietf:params:xml:ns:simple-filter" rather=20 > than "urn:ietf:params:xml:ns:simple-filter+xml". Fixed. >=20 > - Missing link with the MIME type simple-filter+xml. I didn't=20 > fine any=20 > linkage to the simple-filter+xml MIME type. >=20 > I am missing some normative text that indicates the following ideas: > a) This specification defines a new MIME type "simpler-filter+xml". Added. > b) Implementations MUST support this MIME type. Functionality draft issue. > c) Filter criteria documents MUST be sent setting the Content-Type to=20 > "simple-filter+xml". Functionality draft issue. >=20 > - Namespaces prefixes. There are many elements that accept a namespace > prefix to identify the correct element. The question is, where is the > binding between the namespace and the prefix defined? None of the > examples show this binding, but all of them refer to "pidf", "rpid", > "wi" namespaces. For instance, this is an excerpt from an example: >=20 > > //pidf:tuple/pidf:status/pidf:basic[rpid:class=3D"IM" > or rpid:class=3D"SMS" or rpid:class=3D"MMS"] > >=20 > Where is it define that "rpid" refers to either > urn:ietf:params:xml:ns:pidf:rpid-tuple or > urn:ietf:params:xml:ns:pidf:status:rpid-status? And to which one? >=20 > I see two possible solutions. One is that you use the regular > prefix-namespace binding used in XML. The only problem is that this > binding refers to elements that you use in your XML document. However, > you want to prefix ***values*** that refer, in turn, to an=20 > XML element. > It is not quite the same thing. For instance, if you want to use rpid > and pidf, you could use the following element. >=20 > xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance" > xsi:schemaLocation=3D"urn:ietf:params:xml:ns:simple-filter" > xmlns:rpid=3D"urn:ietf:params:xml:ns:pidf:rpid-tuple" > xmlns:pidf=3D"urn:ietf:params:xml:ns:pidf" > elementFormDefault=3D"qualified" > attributeFormDefault=3D"unqualified"> I don't believe this is the right solution. As you said, those apply to = qualifying elements not values of elements. >=20 > The other solution is that you explicitly define some XML > element as part of your schema. This will be used to define=20 > the binding > you use later. Something like: >=20 > xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance" > xsi:schemaLocation=3D"urn:ietf:params:xml:ns:simple-filter" > elementFormDefault=3D"qualified" > attributeFormDefault=3D"unqualified"> >=20 > > This works. I used=20 Is this acceptable? >=20 >=20 > - Section 3.3. The statement says: >=20 > The element MAY contain one or more =20 > elements and one > or more elements. However, the element=20 > MUST contain > at least one element. >=20 > I would like to understand why at least one element must be > present. In other words, why can I just have element=20 > that simply > states what I don't want to receive, i.e., a collection of > elements and zero elements. I guess alone works. >=20 > In case something changes in this section, then section 3.3.2 should > change as well: >=20 > The element MUST NOT be used if there are no > element(s) in the same content filter. Removed. >=20 > - Section 3.3.1.1. The first paragraph is ok, but the remaining of the > section has nothing to do with the 'type' attribute. I=20 > believe the rest > should be moved to Section 4, as it discusses the syntax. I moved to section 3.3.1 where is defined. >=20 > - Section 3.4 states: >=20 > The element MAY contain the element,=20 > the > element or the , but MUST contain at least one=20 > of the three > elements. Any combination of the 3 elements is possible.=20 > Multiple > appearances of those element within a element=20 > denotes the > "AND" operation. This means that updates to a resource=20 > that satisfy > ALL of the , and elements'=20 > criteria within > the element constitute the content to be delivered. >=20 > Question: is there a case where the and can appear > simultaneously? It would mean: send me element if it is > and , which I believe is not possible ever. The trigger would say send me a NOTIFY when element was added and = element was removed. >=20 > - Section 3.4.1 states: >=20 > The element is used to identify the XML element or > attribute, from the package specific XML document, that=20 > must change, > compared to the previous XML document, in order to activate the > trigger and cause the content to be delivered. >=20 > If I understand correctly, what changes is not the element itself, but > the value. Can you confirm it? >=20 > If the element changes, then it could be, e.g., because a new optional > attribute is added or removed. But I believe that you want to say that > what it has to change is the value, right? >=20 > Can you clarify in the text what is the intention? Yes, the texts talks about the value. I'll clarify. >=20 > - Section 3.4.1.3 states: >=20 > A trigger is active when the XML element or attribute=20 > identified with > the element has changed by the value indicated by this > attribute from a different value. >=20 > So does this element apply to numeric values only? If so, then I guess > this is either an addition or subtraction with respect the current > value (not multiply or division). Therefore, I would propose: >=20 > The 'changed-by' attribute applies only to numerical values and > indicates a delta with respect the current value that an attribute > or element (identified in the element) needs to change > before it is selected. >=20 > Example: if the 'changed-by' attribute is set to 2, and=20 > the current > value of the element/attribute is 6, the element/attribute is > selected when it reaches (or exceeds) the value 8 or when it > decreases to 4 or lower value. Done. >=20 > - Section 3.4.2 states: >=20 > The XML element or > attribute is indicated using the syntax defined in=20 > Section 4 for the > "reference". >=20 > I think you should make the above text normative: >=20 > The XML element or attribute MUST be expressed using the syntax > defined in Section 4 for the "reference" ABNF. Done. >=20 > - Section 6, extensibility of the XML schema. >=20 > I noticed weird things related to the extensibility of the=20 > XML schema.=20 > While you provide extensibility for new attributes of most elements,=20 > there is no attribute extensibility to the element.=20 > Additionally,=20 > I didn't find any possibility to add new elements. I think=20 > this should=20 > be possible, when it is rational. I'll fix by allowing extensibility for elements in FilterType and = WhatType. >=20 > - Section 6, the "TypeType" definition. >=20 > Currently, the "TypeType" is defined as: >=20 > > > > > > > >=20 > I believe the "token" value should not be present. Yes, left from an older version by mistake. > Second: in=20 > the text=20 > it is said (a few times) that a filter applies to either an=20 > element, an=20 > attribute or a namespace. But now the "type" definition only=20 > considers=20 > values "xml-element" and "namespace". So how I identify an attribute? >=20 > I believe that "xml-element" is sufficient to accommodate attributes,=20 > because you will have an XPath expression that clearly distinguishes=20 > elements from attributes. So I am not advocating to add a new=20 > "attribute" value to the "type" definition, instead I think=20 > you need to=20 > rename the "xml-element" by something more generic, perhaps=20 > "xpath" to=20 > indicate that the value of the element is an XPath expression (or a=20 > namespace it is so). >=20 > Then probably you need to add some discussion, in the text,=20 > to indicate=20 > when to use one or the other. Changed to "xpath". >=20 > - I would like to get your opinion on a new feature. I=20 > believe it might > be interesting to have rules defined and stored in the=20 > server, so that I > can easily activate a filter set or deactivate it. So a filter that is > deactivated is not in used, although is easily available for future > reference or enable it at any time. >=20 > I think I would like to see some 'state' attribute in each or > elements, so that I can "enable" or "disable" easily a > filter, without sending the whole to the server. Sounds interensting, if there are no objections, I will add. >=20 > - Notation. Some months ago we got an agreement on the=20 > notation that we > should be using for XML specifications. I believe the=20 > agreement is that, > whenever we refer to an element, we include it within brackets (e.g., > ); an attribute is enclosed in single quotes (e.g., > 'attribute'); a value is enclosed in quotation marks (e.g., "this is a > value"). >=20 > For instance: the element contains an optional 'type' attribute > that can get the value "open" or "closed". >=20 > This facilitates the reading of the specification. So can you please > revise the document and make the notation consistent according to the > above rules? Done. >=20 > - Examples. All the examples should start with a proper XML=20 > header, like: >=20 > > xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance" > xsi:schemaLocation=3D"urn:ietf:params:xml:ns:simple-filter"> >=20 > After that, you don't need to prepend each element in the=20 > examples with > a "simple-filter" prefix (that is not even bound anywhere). But this > requires that you change a bit the XML schema to add the default > behavior for elements and attributes. So the schema should=20 > start with : >=20 > > xmlns=3D"urn:ietf:params:xml:ns:simple-filter" > xmlns:xs=3D"http://www.w3.org/2001/XMLSchema" > elementFormDefault=3D"qualified" > attributeFormDefault=3D"unqualified"> >=20 > With this change to the schema, then the examples validate=20 > without that > prefix, and they are easier to read. Done. >=20 > - Section 5.1, example. Shouldn't the value of the =20 > element be > prepended with "//pidf:presence" to identify the root element of the=20 > pidf document?. For example: >=20 > > //pidf:presence/pidf:tuple/pidf:status/ > pidf:basic[rpid:class=3D"IM" or rpid:class=3D"SMS" or > rpid:class=3D"MMS"] > No. // means any element under the root element >=20 > - Section 5.2, example. Missing one slash "/" before the=20 > "/pidf:presence". Not needed // mean any element. >=20 > - Section 5.3, example. Missing double slashes "//" before the=20 > "wi:watcher" value in the element. Fixed. >=20 > Also in this example, is it it correct to have a slash "/"=20 > prior to the=20 > at sign "@" in : >=20 > //wi:watcher/@wi:status@status >=20 > At least by following the ABNF I thought it wasn't right. This is correct syntax and is allowed by the ABNF. >=20 > - Section 5.5, typo in title: >=20 > s/Include/include Fixed. >=20 > - Section 3.1, typo in sentence: >=20 > '... document containing the filter criteria is separated from > the events that makes use of it or from the protocol that > usually carries it.' >=20 > s/makes/make >=20 > - Section 8: I would remove the two paragraphs in this subsection >=20 > A new content type "application/simple-filter+xml" is defined to > represent an XML MIME for the filter criteria. >=20 > This specification follows the guidelines of RFC3023 [7] I wouldn't ;) >=20 >=20 > And I would start section 8.1 with: >=20 > This specification registers a new MIME type according to the > procedures of RFC 2048 [xx] and guidelines in RFC 3023 [yy]. >=20 >=20 > - Section 8.1: Typo in title: >=20 > application/simple-filter+xml mime TYPE >=20 > should read: >=20 > application/simple-filter+xml MIME type >=20 > - Section 8.1: Typo. >=20 > Security considerations: See section 10 of RFC 3023 [7]=20 > and section > Section 8 of this document. >=20 > should read >=20 > Security considerations: See section 10 of RFC 3023 [7]=20 > and section > Section 7 of this document. >=20 > - Section 8.2: The "URN document" is now RFC 3688. All fixed. Thanks, Hisham >=20 >=20 >=20 >=20 > Best regards, >=20 > Miguel >=20 > Robert Sparks wrote: >=20 > > This is a SIMPLE working group last call for the following drafts: > >=20 > >=20 http://www.ietf.org/internet-drafts/draft-ietf-simple-filter-format-01.tx= t > = http://www.ietf.org/internet-drafts/draft-ietf-simple-event-filter-funct-= 01.txt >=20 > Please provide comments to the list or chairs by July 16. >=20 > Thanks, > RjS >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 --=20 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 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jul 7 11:37: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 LAA26304 for ; Wed, 7 Jul 2004 11:37: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 1BiEU1-00059K-3d for simple-archive@ietf.org; Wed, 07 Jul 2004 11:37:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BiESX-0004o6-00 for simple-archive@ietf.org; Wed, 07 Jul 2004 11:35:46 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BiERl-0004Np-00; Wed, 07 Jul 2004 11:34:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BiDiJ-0007IA-Iy; Wed, 07 Jul 2004 10: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 1BiDEu-0006M8-8f for simple@megatron.ietf.org; Wed, 07 Jul 2004 10:17: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 KAA21934 for ; Wed, 7 Jul 2004 10: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 1BiDEo-0001ka-IF for simple@ietf.org; Wed, 07 Jul 2004 10:17:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BiDDv-0001QF-00 for simple@ietf.org; Wed, 07 Jul 2004 10:16:36 -0400 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1BiDDN-00015j-00 for simple@ietf.org; Wed, 07 Jul 2004 10:16:01 -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 i67EG0624178 for ; Wed, 7 Jul 2004 17:16:00 +0300 (EET DST) X-Scanned: Wed, 7 Jul 2004 17:15:51 +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 i67EFpYe012000 for ; Wed, 7 Jul 2004 17:15:51 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00C9TkZk; Wed, 07 Jul 2004 17:15:49 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 i67EFmH06290 for ; Wed, 7 Jul 2004 17:15:48 +0300 (EET DST) Received: from nokia.com ([172.21.42.108]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 7 Jul 2004 17:15:39 +0300 Message-ID: <40EC0589.7050703@nokia.com> Date: Wed, 07 Jul 2004 17:15:37 +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: "Khartabil Hisham (Nokia-TP-MSW/Helsinki)" Subject: Re: [Simple] WGLC: Event Filtering References: <2038BCC78B1AD641891A0D1AE133DBB7023EEADD@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB7023EEADD@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Jul 2004 14:15:39.0043 (UTC) FILETIME=[E10F4730:01C4642C] 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 Inline. I have deleted all the items for which we don't need further discussion. - Miguel Khartabil Hisham (Nokia-TP-MSW/Helsinki) wrote: >>- Missing link with the MIME type simple-filter+xml. I didn't >>fine any >>linkage to the simple-filter+xml MIME type. >> >>I am missing some normative text that indicates the following ideas: >>a) This specification defines a new MIME type "simpler-filter+xml". > > > Added. > > >>b) Implementations MUST support this MIME type. > > > Functionality draft issue. > M.G: I think I expressed myself wrong, because obviously it does not make sense that you define a MIME type and in the same document you say that implementations MUST suppport it, so I agree with you. But I think the text I am looking for is something that indicates that when an implementation encodes a Filter Criteria document, it MUST set the Content-Type header (or whatever protocol) to simple-filter+xml. Then the functionality draft can say that implementations MUST support filter criteria documents. > >>c) Filter criteria documents MUST be sent setting the Content-Type to >>"simple-filter+xml". > > > Functionality draft issue. > No, this is what I said in point b) above, I think this should be stated in the filter criteria format. > >>- Namespaces prefixes. There are many elements that accept a namespace >>prefix to identify the correct element. The question is, where is the >>binding between the namespace and the prefix defined? None of the >>examples show this binding, but all of them refer to "pidf", "rpid", >>"wi" namespaces. For instance, this is an excerpt from an example: >> >> >> //pidf:tuple/pidf:status/pidf:basic[rpid:class="IM" >> or rpid:class="SMS" or rpid:class="MMS"] >> >> >>Where is it define that "rpid" refers to either >>urn:ietf:params:xml:ns:pidf:rpid-tuple or >>urn:ietf:params:xml:ns:pidf:status:rpid-status? And to which one? >> >>I see two possible solutions. One is that you use the regular >>prefix-namespace binding used in XML. The only problem is that this >>binding refers to elements that you use in your XML document. However, >>you want to prefix ***values*** that refer, in turn, to an >>XML element. >>It is not quite the same thing. For instance, if you want to use rpid >>and pidf, you could use the following element. >> >>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" >> xsi:schemaLocation="urn:ietf:params:xml:ns:simple-filter" >> xmlns:rpid="urn:ietf:params:xml:ns:pidf:rpid-tuple" >> xmlns:pidf="urn:ietf:params:xml:ns:pidf" >> elementFormDefault="qualified" >> attributeFormDefault="unqualified"> > > > I don't believe this is the right solution. As you said, those apply to qualifying elements not values of elements. > > >>The other solution is that you explicitly define some XML >>element as part of your schema. This will be used to define >>the binding >>you use later. Something like: >> >>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" >> xsi:schemaLocation="urn:ietf:params:xml:ns:simple-filter" >> elementFormDefault="qualified" >> attributeFormDefault="unqualified"> >> >> >> > > > This works. I used > > > > > > > Is this acceptable? > > Yes, at least to me. >> >>- Section 3.3.1.1. The first paragraph is ok, but the remaining of the >>section has nothing to do with the 'type' attribute. I >>believe the rest >>should be moved to Section 4, as it discusses the syntax. > > > I moved to section 3.3.1 where is defined. > I don't think it makes much sense. Basically, most of the section 3.3.1 speaks about syntax of Xpath expressions, which happens to be the subject of section 4. I see a duplication. So you should choose how to document it, but make sure you don't repeat "syntax" sections. > >>- Section 5.1, example. Shouldn't the value of the >>element be >>prepended with "//pidf:presence" to identify the root element of the >>pidf document?. For example: >> >> >> //pidf:presence/pidf:tuple/pidf:status/ >> pidf:basic[rpid:class="IM" or rpid:class="SMS" or >> rpid:class="MMS"] >> > > > No. // means any element under the root element Ok, I understand that the current example is OK, but a bit akward I would say: //pidf:tuple/pidf:status/pidf:basic[rpid:class ...] So this means: give me all the elements that are children of that are children of that are children of *anything* else. Although valid, I would just say //pidf:basic[rpid:class ...] meaning: give me all the elements that are children of anything. Anyway, it is just an example. >> >>- Section 8: I would remove the two paragraphs in this subsection >> >> A new content type "application/simple-filter+xml" is defined to >> represent an XML MIME for the filter criteria. >> >> This specification follows the guidelines of RFC3023 [7] > > > I wouldn't ;) > > >> >>And I would start section 8.1 with: >> >> This specification registers a new MIME type according to the >> procedures of RFC 2048 [xx] and guidelines in RFC 3023 [yy]. >> >> This was a complete one, not only removing two paragraphs, but rephrasing with the above text. I am not sure if you missinterpret me. > Thanks, > Hisham > > >> >> >> >>Best regards, >> >> Miguel >> >>Robert Sparks wrote: >> >> >>>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 >> > > -- 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 Jul 7 12:38: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 MAA29370 for ; Wed, 7 Jul 2004 12:38: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 1BiFRJ-0001iO-IF for simple-archive@ietf.org; Wed, 07 Jul 2004 12:38:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BiFQH-0001PQ-00 for simple-archive@ietf.org; Wed, 07 Jul 2004 12:37:29 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BiFPD-0000oz-00; Wed, 07 Jul 2004 12:36:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BiEKj-0008LB-Ey; Wed, 07 Jul 2004 11:27:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BiDdY-0005p1-T5 for simple@megatron.ietf.org; Wed, 07 Jul 2004 10:43: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 KAA23484 for ; Wed, 7 Jul 2004 10:42: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 1BiDdJ-0002bG-6H for simple@ietf.org; Wed, 07 Jul 2004 10:42:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BiDcO-0002Fp-00 for simple@ietf.org; Wed, 07 Jul 2004 10:41:53 -0400 Received: from ns.execdsl.net ([208.184.15.238] helo=EXECDSL.COM) by ietf-mx with esmtp (Exim 4.12) id 1BiDbi-0001tr-00 for simple@ietf.org; Wed, 07 Jul 2004 10:41:10 -0400 Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 7180367 for simple@ietf.org; Wed, 07 Jul 2004 10:41:07 -0400 Message-Id: <5.1.0.14.0.20040707103647.023de8c8@localhost> X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 07 Jul 2004 10:40:54 -0400 To: simple@ietf.org From: "Joel M. Halpern" Subject: Re: [Simple] Large response ? In-Reply-To: <40EBF2B9.3030009@nokia.com> References: <5.1.0.14.0.20040707080624.023eb198@localhost> <5.1.0.14.0.20040706111036.023f5320@localhost> <40EA0018.3080408@dynamicsoft.com> <40E5C2E1.50502@dynamicsoft.com> <40E903D2.2050703@nokia.com> <40EA0018.3080408@dynamicsoft.com> <5.1.0.14.0.20040706111036.023f5320@localhost> <5.1.0.14.0.20040707080624.023eb198@localhost> 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 There appears to be some (reasonable) desire to get part of an XML Configuration, where "part" means not a just selection of identified elements but some other subseting. This appears to be driven by some combination of client memory and user presentation resources. Rather than trying to argue that some solution meets the needs, I would like to see a clear and reasonably complete list of requirements. I can believe that there is some requirement that is not met by byte-range for example, but I do not know what it is. Yours, Joel M. Halpern _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jul 7 13:29: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 NAA02494 for ; Wed, 7 Jul 2004 13: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 1BiGEh-000363-PX for simple-archive@ietf.org; Wed, 07 Jul 2004 13:29:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BiGDI-0002Tz-00 for simple-archive@ietf.org; Wed, 07 Jul 2004 13:28:09 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BiGBy-000258-01; Wed, 07 Jul 2004 13:26:46 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BiG2X-0006Zg-6H; Wed, 07 Jul 2004 13:17:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BiFRH-0003xM-9y; Wed, 07 Jul 2004 12:38:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BiEQX-0001Uy-6V for simple@megatron.ietf.org; Wed, 07 Jul 2004 11:33: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 LAA26112 for ; Wed, 7 Jul 2004 11:33: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 1BiEQR-00047m-9a for simple@ietf.org; Wed, 07 Jul 2004 11:33:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BiEPb-0003oZ-00 for simple@ietf.org; Wed, 07 Jul 2004 11:32:44 -0400 Received: from smtp.eweka.nl ([81.171.101.3]) by ietf-mx with esmtp (Exim 4.12) id 1BiEP1-0003Uw-00 for simple@ietf.org; Wed, 07 Jul 2004 11:32:07 -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 i67FW3b0052866; Wed, 7 Jul 2004 17:32:22 +0200 (CEST) (envelope-from a.vwijk@viataal.nl) Message-Id: <200407071532.i67FW3b0052866@smtp.eweka.nl> From: "Arnoud van Wijk" To: "'Paul Kyzivat'" , "'Gregg Vanderheiden'" , Subject: RE: Tiny ant vs big Mammoths, was RE: [Simple] Using MSRP for realtimetext conversation Date: Wed, 7 Jul 2004 17:30:46 +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 Thread-Index: AcRkI5uTK7uhceQ9SWC5kPAVURtaegAEiTrQ In-Reply-To: <40EBF5CC.8000901@cisco.com> Content-Transfer-Encoding: 7bit Cc: adam@dynamicsoft.com, "'Guido Gybels'" , dean.willis@softarmor.com, gunnar.hellstrom@omnitor.se, 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.3 required=5.0 tests=AWL,MISSING_OUTLOOK_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Hello Paul, Quite interesting and a very good point. Perhaps we can ask the SIMPLE WG to make this a WG charter. <> Yes, that is the first goal. IM clients SHOULD support text/t140 over RTP. <> I completely agree here! So, we talk about support for text/t140 on 2 levels. 1. interface, thus you can use the same client somehow to type a text/t140 conversation. 2. More importantly, at the negotiation phase, the IM client should be ready to accept text/t140. When choosing between MESSAGE or MSRP..it can choose text/t140. <> This is what we need to describe in the ToIP draft I think. Working with SIMPLE on that part. Gateways..PSTNs, legacy Textphones... quite complex jungle here. But we will try. If we can get a positive signal from SIMPLE for text/t140 support at negotiation of a session between SIMPLE clients. Then we have many more possibilities! And we can focus on that instead of changing MSRP to support text/t140 in a non RTP way. Greetz Arnoud _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jul 7 14:05:40 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04967 for ; Wed, 7 Jul 2004 14:05: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 1BiGnc-0007j6-Vv for simple-archive@ietf.org; Wed, 07 Jul 2004 14:05:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BiGmg-0007QN-00 for simple-archive@ietf.org; Wed, 07 Jul 2004 14:04:43 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BiGm6-00075e-00; Wed, 07 Jul 2004 14:04:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BiGCb-0007Ye-N7; Wed, 07 Jul 2004 13:27:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BiFUU-00054D-Ak for simple@megatron.ietf.org; Wed, 07 Jul 2004 12:41: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 MAA29539 for ; Wed, 7 Jul 2004 12:41: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 1BiFUO-0002k9-Eg for simple@ietf.org; Wed, 07 Jul 2004 12:41:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BiFTY-0002Ps-00 for simple@ietf.org; Wed, 07 Jul 2004 12:40:53 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BiFSi-00021P-00 for simple@ietf.org; Wed, 07 Jul 2004 12:40:00 -0400 Received: from dynamicsoft.com ([63.113.46.28]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i67Gdlbo007087; Wed, 7 Jul 2004 12:39:48 -0400 (EDT) Message-ID: <40EC2741.5070904@dynamicsoft.com> Date: Wed, 07 Jul 2004 12:39: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: Biot Olivier Subject: Re: [Simple] XCAP and multiple edits by multiple users References: <6B546A602AD2D211BFF00008C7A428890B1E28D2@hrtades2.atea.be> In-Reply-To: <6B546A602AD2D211BFF00008C7A428890B1E28D2@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 This functionality more or less already exists in Webdav, see http://www.ietf.org/rfc/rfc2518.txt. It provides a LOCK method that does exactly what you want. The lock extensions there do not support rollback, though I suspect there would be interest in adding it. I think the subject of webdav usage with xcap is a good one, but one that should be part of follow-on activity. I think that many usages will not require this kind of functionality, and its important that the base specification be kept simple. -Jonathan R. Biot Olivier wrote: > Hi list, > > Although the SIMPLE WG strongly favours not inventing a new protocol for > implementing XCAP, I think some issues being regularly discussed suggest it > is time to think about adding an extension to the envisaged HTTP framework. > Consider the following issues: > > 1. Can multiple users safely edit the same application usage? > > 2. Can multiple edits be safely applied "atomically" by one user? > > I think a simple solution for dealing with both issues is implementing a > time-based resource locking mechanism, similar to the what the SIP Expires > header provides. (Unfortunately HTTP states that the Expires header must > contain a HTTP-date so it is not suitable for this proposal. For this > reason, this header is named "expires" in this text.) > > The idea I have in mind is that one XCAP client is allowed to LOCK or > RESERVE a resource for a specific time (seconds) as specified in the > request's "expires" header. The XCAP server can either accept or reject this > request, and may modify the amount of time the resource has a "write lock" > on it, by means of the "expires" response header. The locked resource is > unlocked after the specified time or after the client issued an UNLOCK or > RELEASE request on the resource. Note that this request does not need to be > implemented as an HTTP method, but could be communicated by means of a > "expires" header with value zero. > > As long as the resource is locked, the validity of the lock must be > communicated and may be renegotiated between client and server, by means of > this "expires" header. > > If another XCAP client wishes to edit the currently locked resource, the > XCAP server could issue a 503 response with a Retry-After response header > informing the XCAP client when it may reissue the same request. > > If multiple edits have to be implemented as an atomic operation where each > operation must succeed, a final "commit" or "roll-back" must be possible. A > commit would happen at the same time a new Entity Tag is being computed for > the new resource, at the time the lock will either be released or will > expire. A "roll-back" should apply from the moment the first error > appreared. After a commit or a roll-back, the new ETag is computed and the > lock is released; this is communicated by sending the Etag and an "expires" > response header with 0 (zero) as value. > > This approach renders the use of the ETag useless between subsequent XCAP > operations on the same locked entity. I am however not really opposed to > sending intermediate ETag values to the manipulating client. > > In order to distinguish between singular XCAP operations and operations on a > locked resource, the XCAP server should respond with a 202 status instead of > a 200, which means that the client may continue with the next request. > > I understand that this proposal adds at least one HTTP method (LOCK or > RESERVE) and one HTTP header (similar to the SIP Expires header), and that > (because of this) XCAP would not be 100% standard HTTP anymore. > Additionally, a "lock war" denial-of-service security breach can be seen in > this approach. However I'd like to know whether this apporach makes sense, > maybe as a future extension to "vanilla" XCAP. If I overlooked something, > please let me know. > > Regards, > > Olivier > > _______________________________________________ > 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 Wed Jul 7 15:07: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 PAA08979 for ; Wed, 7 Jul 2004 15:07: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 1BiHle-0005KS-Q7 for simple-archive@ietf.org; Wed, 07 Jul 2004 15:07:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BiHkj-0004xr-00 for simple-archive@ietf.org; Wed, 07 Jul 2004 15:06:46 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BiHjX-0004C1-00; Wed, 07 Jul 2004 15:05:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BiHEl-0008HT-3k; Wed, 07 Jul 2004 14:33:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BiGXD-00057E-JB for simple@megatron.ietf.org; Wed, 07 Jul 2004 13:48: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 NAA03770 for ; Wed, 7 Jul 2004 13:48: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 1BiGXC-0001wn-Lt for simple@ietf.org; Wed, 07 Jul 2004 13:48:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BiGWB-0001Zy-00 for simple@ietf.org; Wed, 07 Jul 2004 13:47:40 -0400 Received: from mx4.broadwing.com ([216.140.57.248] helo=ausspam02.ixc-comm.com) by ietf-mx with esmtp (Exim 4.12) id 1BiGVD-0000vm-00; Wed, 07 Jul 2004 13:46:39 -0400 Received: from mail pickup service by ausspam02.ixc-comm.com with Microsoft SMTPSVC; Wed, 7 Jul 2004 12:41:26 -0500 Received: from megatron.ietf.org ([132.151.6.71]) by ausspam02.ixc-comm.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 6 Jul 2004 19:05:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BhwJ0-0001Wt-9F; Tue, 06 Jul 2004 16:12:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BhvlD-0002Wn-Oe; Tue, 06 Jul 2004 15:37:47 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16576; Tue, 6 Jul 2004 15:37:45 -0400 (EDT) Message-Id: <200407061937.PAA16576@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 06 Jul 2004 15:37:45 -0400 X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-OriginalArrivalTime: 07 Jul 2004 00:05:40.0546 (UTC) FILETIME=[23963220:01C463B6] Cc: simple@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-cipid-02.txt X-BeenThere: simple@ietf.org Reply-To: internet-drafts@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.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 : CIPID: Contact Information in Presence Information Data Format Author(s) : H. Schulzrinne Filename : draft-ietf-simple-cipid-02.txt Pages : 9 Date : 2004-7-6 The Presence Information Data Format (PIDF) defines a basic XML format for presenting presence information for a presentity. The Contact Information for Presence Information Data Format (CIPID) is an extension that adds elements to PIDF that provide additional contact information about a presentity and its contacts, including references to address book entries and icons. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-cipid-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-cipid-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-cipid-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-7-6152039.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-cipid-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-cipid-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-7-6152039.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 Content-Transfer-Encoding: 7bit _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --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 Wed Jul 7 19:26: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 TAA27495 for ; Wed, 7 Jul 2004 19:26: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 1BiLoc-0005ts-0y for simple-archive@ietf.org; Wed, 07 Jul 2004 19:27:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BiLna-0005YY-00 for simple-archive@ietf.org; Wed, 07 Jul 2004 19:25:59 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BiLm5-0004wT-00; Wed, 07 Jul 2004 19:24:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BiKa3-00079H-Vm; Wed, 07 Jul 2004 18:07:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BiJQH-0006uB-GB for simple@megatron.ietf.org; Wed, 07 Jul 2004 16:53: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 QAA16736 for ; Wed, 7 Jul 2004 16:53: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 1BiJQF-0001gK-T5 for simple@ietf.org; Wed, 07 Jul 2004 16:53:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BiJPF-0001Ml-00 for simple@ietf.org; Wed, 07 Jul 2004 16:52:42 -0400 Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx with esmtp (Exim 4.12) id 1BiJOG-0000lk-00 for simple@ietf.org; Wed, 07 Jul 2004 16:51:40 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.175); Wed, 7 Jul 2004 13:51:03 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 7 Jul 2004 13:51:54 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 7 Jul 2004 13:51:11 -0700 Message-ID: Thread-Topic: Friendly Display Name in Presence Schema? Thread-Index: AcRkZCJx4GewS0fDRWSuOBwWQSvUPQ== From: "Orit Levin" To: X-OriginalArrivalTime: 07 Jul 2004 20:51:54.0945 (UTC) FILETIME=[3C9A0310:01C46464] Subject: [Simple] Friendly Display Name in Presence Schema? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.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="===============2106966562==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org 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,HTML_30_40,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. --===============2106966562== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C46464.35C46E34" This is a multi-part message in MIME format. ------_=_NextPart_001_01C46464.35C46E34 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Guys, Do we have a friendly display name defined per user in one of our presence XML schemas (in addition to the entity URI) ? =20 Thanks, Orit. ------_=_NextPart_001_01C46464.35C46E34 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Guys,
Do we = have a=20 friendly display name defined per user in one of our presence XML = schemas (in=20 addition to the entity URI) ?
 
Thanks,
Orit.
------_=_NextPart_001_01C46464.35C46E34-- --===============2106966562== 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 --===============2106966562==-- From simple-bounces@ietf.org Thu Jul 8 00:19: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 AAA11171 for ; Thu, 8 Jul 2004 00:19: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 1BiQNX-0006xH-38 for simple-archive@ietf.org; Thu, 08 Jul 2004 00:19:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BiQMP-0006d9-00 for simple-archive@ietf.org; Thu, 08 Jul 2004 00:18:14 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BiQLz-0006J3-00; Thu, 08 Jul 2004 00:17:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BiOWW-0000hC-3l; Wed, 07 Jul 2004 22:20:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BiNVA-0001eS-A3 for simple@megatron.ietf.org; Wed, 07 Jul 2004 21:15: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 VAA02244 for ; Wed, 7 Jul 2004 21:14: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 1BiNV3-0000zH-Mi for simple@ietf.org; Wed, 07 Jul 2004 21:14:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BiNUE-0000h4-00 for simple@ietf.org; Wed, 07 Jul 2004 21:14:07 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BiNTm-0000OZ-00 for simple@ietf.org; Wed, 07 Jul 2004 21:13:38 -0400 Received: from dynamicsoft.com ([63.113.46.28]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i681DObo007256; Wed, 7 Jul 2004 21:13:26 -0400 (EDT) Message-ID: <40EC9FA2.4080303@dynamicsoft.com> Date: Wed, 07 Jul 2004 21:13:06 -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: Orit Levin Subject: Re: [Simple] Friendly Display Name in Presence Schema? 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=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit I dont think so, no. I would think that, in most cases, the display name would be set by the watcher, and present in their resource list. The resource list XML does have a display name. -Jonathan R. Orit Levin wrote: > Guys, > Do we have a friendly display name defined per user in one of our > presence XML schemas (in addition to the entity URI) ? > > Thanks, > Orit. > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 Jul 8 01:03: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 BAA13085 for ; Thu, 8 Jul 2004 01: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 1BiR4A-0005td-SY for simple-archive@ietf.org; Thu, 08 Jul 2004 01:03:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BiR1q-0005Ni-00 for simple-archive@ietf.org; Thu, 08 Jul 2004 01:01:03 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BiR0p-0004mJ-00; Thu, 08 Jul 2004 00:59:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BiPr6-0001pw-E7; Wed, 07 Jul 2004 23:45:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BiOKT-0005d2-02 for simple@megatron.ietf.org; Wed, 07 Jul 2004 22:08: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 WAA05464 for ; Wed, 7 Jul 2004 22:07: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 1BiOKM-0003KU-BW for simple@ietf.org; Wed, 07 Jul 2004 22:07:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BiOJT-00032L-00 for simple@ietf.org; Wed, 07 Jul 2004 22:07:03 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BiOIu-0002gs-00 for simple@ietf.org; Wed, 07 Jul 2004 22:06:28 -0400 Received: from dynamicsoft.com ([63.113.46.28]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i6826Hbo007302; Wed, 7 Jul 2004 22:06:17 -0400 (EDT) Message-ID: <40ECAC06.9020206@dynamicsoft.com> Date: Wed, 07 Jul 2004 22:05:58 -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] RE: XCAP Directory: Large response ? References: <40EA0018.3080408@dynamicsoft.com> <40E5C2E1.50502@dynamicsoft.com> <40E903D2.2050703@nokia.com> <40EA0018.3080408@dynamicsoft.com> <5.1.0.14.0.20040706111036.023f5320@localhost> <40EB9AF4.2080209@nokia.com> <40EBD05A.9060003@dynamicsoft.com> <40EBD798.9010400@nokia.com> In-Reply-To: <40EBD798.9010400@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: "Joel M. Halpern" , 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 Miguel Garcia wrote: >> >> This schema *requires* that the element have three children, >> el1, el2 and el3. If you ask for a version of this document with no >> more than two elements, it cannot be done in a way that results in a >> schema compliant document. > > > M.G: Yes, you are right. IF the schema mandates the presence of a number > of elements, those must be present, and cannot be restricted by a range. > I am not trying to change that behaviour. > > I think the precondition for requesting a range of elements is that the > elemnt is defined with the fololowing attributes > > minOccurs="0" maxOccurs="unbounded" > > This is what happens with the , , elements in > the resource list, and the element in the XCAP directory list. > In this way, the schema is always respected independently of the range > of requested elements. OK, so lets push on this a bit. Lets say I have a bunch of places where this schema constraint is true. If you ask for "20 things", which 20 get returned? Is the 20 distributed around the document? Is it based on some kind of DFS walk? How do you know whether you will return something meaningful to the user, even if its schema compliant? In a hierarchical list, I really think you want to separately paginate each layer in the hierarchy, by explicit user request. That seems implementable to me, and it also seems to match the user experience I would expect. Anyway, as Joel mentioned, it would be good to better understand the requirements here. -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 Jul 8 04:16: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 EAA05864 for ; Thu, 8 Jul 2004 04:16: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 1BiU4q-0001N2-DM for simple-archive@ietf.org; Thu, 08 Jul 2004 04:16:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BiU40-00012j-00 for simple-archive@ietf.org; Thu, 08 Jul 2004 04:15:28 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BiU3W-0000gm-00; Thu, 08 Jul 2004 04:14:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BiTSn-0002et-1M; Thu, 08 Jul 2004 03:37:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BiSRH-0002zS-9j for simple@megatron.ietf.org; Thu, 08 Jul 2004 02:31: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 CAA01257 for ; Thu, 8 Jul 2004 02:31: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 1BiSRA-0004mY-7h for simple@ietf.org; Thu, 08 Jul 2004 02:31:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BiSQH-0004Rc-00 for simple@ietf.org; Thu, 08 Jul 2004 02:30:22 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BiSPM-0003yb-00 for simple@ietf.org; Thu, 08 Jul 2004 02:29:24 -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 i686Se417039; Thu, 8 Jul 2004 09:28:44 +0300 (EET DST) X-Scanned: Thu, 8 Jul 2004 09:28:24 +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 i686SO2u026725; Thu, 8 Jul 2004 09:28:24 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00btXKhx; Thu, 08 Jul 2004 09:28:12 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 i686Ren20781; Thu, 8 Jul 2004 09:27:40 +0300 (EET DST) Received: from nokia.com ([172.21.42.108]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 8 Jul 2004 09:27:31 +0300 Message-ID: <40ECE953.6060606@nokia.com> Date: Thu, 08 Jul 2004 09:27:31 +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] RE: XCAP Directory: Large response ? References: <40EA0018.3080408@dynamicsoft.com> <40E5C2E1.50502@dynamicsoft.com> <40E903D2.2050703@nokia.com> <40EA0018.3080408@dynamicsoft.com> <5.1.0.14.0.20040706111036.023f5320@localhost> <40EB9AF4.2080209@nokia.com> <40EBD05A.9060003@dynamicsoft.com> <40EBD798.9010400@nokia.com> <40ECAC06.9020206@dynamicsoft.com> In-Reply-To: <40ECAC06.9020206@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Jul 2004 06:27:31.0402 (UTC) FILETIME=[A5EF22A0:01C464B4] Content-Transfer-Encoding: 7bit Cc: "Joel M. Halpern" , 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 Inline. Jonathan Rosenberg wrote: > > > Miguel Garcia wrote: > > >>> >>> This schema *requires* that the element have three children, >>> el1, el2 and el3. If you ask for a version of this document with no >>> more than two elements, it cannot be done in a way that results in a >>> schema compliant document. >> >> >> >> M.G: Yes, you are right. IF the schema mandates the presence of a >> number of elements, those must be present, and cannot be restricted by >> a range. I am not trying to change that behaviour. >> >> I think the precondition for requesting a range of elements is that >> the elemnt is defined with the fololowing attributes >> >> minOccurs="0" maxOccurs="unbounded" >> >> This is what happens with the , , elements in >> the resource list, and the element in the XCAP directory list. >> In this way, the schema is always respected independently of the range >> of requested elements. > > > OK, so lets push on this a bit. > > Lets say I have a bunch of places where this schema constraint is true. > If you ask for "20 things", which 20 get returned? Is the 20 distributed > around the document? Is it based on some kind of DFS walk? How do you > know whether you will return something meaningful to the user, even if > its schema compliant? In a hierarchical list, I really think you want to > separately paginate each layer in the hierarchy, by explicit user > request. That seems implementable to me, and it also seems to match the > user experience I would expect. I don't have a special requirement here, so I am fine with your proposal to do pagination on a per hierarchical level. > Anyway, as Joel mentioned, it would be good to better understand the > requirements here. Right. So let's try to formulate the requirement. We are looking for a mechanism that allows an XCAP client to request fractions of an XML document, so that the returned document is valid but need not include all the repeatable entries. This allows the XCAP client to operate on the XML document (render and manipulate it), release the memory, request the next fraction of the same XML document, and start the process again. > -Jonathan R. > 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 Thu Jul 8 04:20: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 EAA05976 for ; Thu, 8 Jul 2004 04:20: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 1BiU8a-0002hY-KD for simple-archive@ietf.org; Thu, 08 Jul 2004 04:20:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BiU7d-0002ML-00 for simple-archive@ietf.org; Thu, 08 Jul 2004 04:19:14 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BiU6d-0001j9-00; Thu, 08 Jul 2004 04:18:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BiTbe-0004ii-Ps; Thu, 08 Jul 2004 03: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 1BiSbx-00066C-LM for simple@megatron.ietf.org; Thu, 08 Jul 2004 02:42: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 CAA01907 for ; Thu, 8 Jul 2004 02:42: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 1BiSbq-0000p3-If for simple@ietf.org; Thu, 08 Jul 2004 02:42:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BiSau-0000SW-00 for simple@ietf.org; Thu, 08 Jul 2004 02:41:21 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BiSZy-000065-00 for simple@ietf.org; Thu, 08 Jul 2004 02:40:22 -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 i686eF408603; Thu, 8 Jul 2004 09:40:15 +0300 (EET DST) X-Scanned: Thu, 8 Jul 2004 09:40:12 +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 i686eClw025552; Thu, 8 Jul 2004 09:40:12 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00KnPR5Z; Thu, 08 Jul 2004 09:37:54 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 i686bsu06755; Thu, 8 Jul 2004 09:37:54 +0300 (EET DST) Received: from nokia.com ([172.21.42.108]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 8 Jul 2004 09:37:20 +0300 Message-ID: <40ECEBA0.9070804@nokia.com> Date: Thu, 08 Jul 2004 09:37:20 +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: "Joel M. Halpern" Subject: Re: [Simple] Large response ? References: <5.1.0.14.0.20040707080624.023eb198@localhost> <5.1.0.14.0.20040706111036.023f5320@localhost> <40EA0018.3080408@dynamicsoft.com> <40E5C2E1.50502@dynamicsoft.com> <40E903D2.2050703@nokia.com> <40EA0018.3080408@dynamicsoft.com> <5.1.0.14.0.20040706111036.023f5320@localhost> <5.1.0.14.0.20040707080624.023eb198@localhost> <5.1.0.14.0.20040707103647.023de8c8@localhost> In-Reply-To: <5.1.0.14.0.20040707103647.023de8c8@localhost> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Jul 2004 06:37:20.0930 (UTC) FILETIME=[0551F820:01C464B6] 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 Joel: Let me try to give you a concrete example where you can see that the byte range does not server for the purpose: Imagine I want to request this very simple XML document This is an element Now, when I request this document, I request a byte range (say, 0 to x bytes). The server apply the count on the byte range, and cut the document. It returns me the following document: This is a So my XCAP client will not consider the document even well-formed, not even valid. So what can my XCAP client do with this document? I have two options: a) request the remaining of the document. But since I applied a byte range, presumably because my XCAP client does not have more available memory to request a longer document (otherwise, why did I request a byte range in the first place), I cannot store this partial document and request the remaining parts (I don't have memory to store the remaining parts). So this does not solve the problem. b) dispose the document in the garbage bin (a.k.a. release the memory), and request the complete document. But again we are in the same situation as in a), the terminal requested a byte range in the first place, so what for if it has to request the remaining document? Is there any other solution you can envision? I don't, and therefore my conclusion is that byte ranges does not serve for the purpose. Regards, Miguel Joel M. Halpern wrote: > There appears to be some (reasonable) desire to get part of an XML > Configuration, where "part" means not a just selection of identified > elements but some other subseting. > This appears to be driven by some combination of client memory and user > presentation resources. > > Rather than trying to argue that some solution meets the needs, I would > like to see a clear and reasonably complete list of requirements. I can > believe that there is some requirement that is not met by byte-range for > example, but I do not know what it is. > > Yours, > Joel M. Halpern > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > -- 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 Jul 8 05:51: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 FAA09996 for ; Thu, 8 Jul 2004 05:51: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 1BiVYj-0002R5-4L for simple-archive@ietf.org; Thu, 08 Jul 2004 05:51:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BiVXo-00026v-00 for simple-archive@ietf.org; Thu, 08 Jul 2004 05:50:21 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BiVWs-0001UM-00; Thu, 08 Jul 2004 05: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 1BiVHo-0005Tx-PH; Thu, 08 Jul 2004 05:33:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BiUkR-0003WT-O8 for simple@megatron.ietf.org; Thu, 08 Jul 2004 04:59: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 EAA07824 for ; Thu, 8 Jul 2004 04:59:12 -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 1BiUkK-0000Zs-FN for simple@ietf.org; Thu, 08 Jul 2004 04:59:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BiUjS-0000Ct-00 for simple@ietf.org; Thu, 08 Jul 2004 04:58:20 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BiUhP-0007JP-00 for simple@ietf.org; Thu, 08 Jul 2004 04:56:12 -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 i688uC421181 for ; Thu, 8 Jul 2004 11:56:12 +0300 (EET DST) X-Scanned: Thu, 8 Jul 2004 11:56: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 i688u0fb031323 for ; Thu, 8 Jul 2004 11:56:00 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 009QMz3X; Thu, 08 Jul 2004 11:55:15 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 i688tEn10793 for ; Thu, 8 Jul 2004 11:55:14 +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); Thu, 8 Jul 2004 11:55:04 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Simple] WGLC: Event Filtering Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Date: Thu, 8 Jul 2004 11:55:03 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7023EEAE4@esebe019.ntc.nokia.com> Thread-Topic: [Simple] WGLC: Event Filtering Thread-Index: AcRkLOEJMdHbcJAQTSO3fCOdGvbylgAmzrkw To: X-OriginalArrivalTime: 08 Jul 2004 08:55:04.0356 (UTC) FILETIME=[42B4B640:01C464C9] 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: Miguel Garcia [mailto:Miguel.An.Garcia@nokia.com] > Sent: 07.July.2004 17:16 > To: Khartabil Hisham (Nokia-TP-MSW/Helsinki) > Cc: simple@ietf.org > Subject: Re: [Simple] WGLC: Event Filtering >=20 >=20 > Khartabil Hisham (Nokia-TP-MSW/Helsinki) wrote: >=20 > >=20 > >>b) Implementations MUST support this MIME type. > >=20 > >=20 > > Functionality draft issue. > >=20 >=20 > M.G: I think I expressed myself wrong, because obviously it does not=20 > make sense that you define a MIME type and in the same=20 > document you say=20 > that implementations MUST suppport it, so I agree with you.=20 > But I think=20 > the text I am looking for is something that indicates that when an=20 > implementation encodes a Filter Criteria document, it MUST set the=20 > Content-Type header (or whatever protocol) to simple-filter+xml. Then=20 > the functionality draft can say that implementations MUST=20 > support filter=20 > criteria documents. We don't want to dictate how a filter arrives at a server or what = protocol is used to upload such filters. Content-type header gives the = false impression that this XML document is only used with SUBSCRIBE = requests. A filter can be uploaded using some other means than SIP = SUBSCRIBE. >=20 >=20 > >=20 > >>c) Filter criteria documents MUST be sent setting the=20 > Content-Type to=20 > >>"simple-filter+xml". > >=20 > >=20 > > Functionality draft issue. > >=20 >=20 > No, this is what I said in point b) above, I think this=20 > should be stated=20 > in the filter criteria format. >=20 >=20 > >=20 > >>- Namespaces prefixes. There are many elements that accept=20 > a namespace > >>prefix to identify the correct element. The question is,=20 > where is the > >>binding between the namespace and the prefix defined? None of the > >>examples show this binding, but all of them refer to "pidf", "rpid", > >>"wi" namespaces. For instance, this is an excerpt from an example: > >> > >> > >> //pidf:tuple/pidf:status/pidf:basic[rpid:class=3D"IM" > >> or rpid:class=3D"SMS" or rpid:class=3D"MMS"] > >> > >> > >>Where is it define that "rpid" refers to either > >>urn:ietf:params:xml:ns:pidf:rpid-tuple or > >>urn:ietf:params:xml:ns:pidf:status:rpid-status? And to which one? > >> > >>I see two possible solutions. One is that you use the regular > >>prefix-namespace binding used in XML. The only problem is that this > >>binding refers to elements that you use in your XML=20 > document. However, > >>you want to prefix ***values*** that refer, in turn, to an=20 > >>XML element. > >>It is not quite the same thing. For instance, if you want=20 > to use rpid > >>and pidf, you could use the following element. > >> > >> >> xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance" > >> xsi:schemaLocation=3D"urn:ietf:params:xml:ns:simple-filter" > >> xmlns:rpid=3D"urn:ietf:params:xml:ns:pidf:rpid-tuple" > >> xmlns:pidf=3D"urn:ietf:params:xml:ns:pidf" > >> elementFormDefault=3D"qualified" > >> attributeFormDefault=3D"unqualified"> > >=20 > >=20 > > I don't believe this is the right solution. As you said,=20 > those apply to qualifying elements not values of elements. > >=20 > >=20 > >>The other solution is that you explicitly define some XML > >>element as part of your schema. This will be used to define=20 > >>the binding > >>you use later. Something like: > >> > >> >> xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance" > >> xsi:schemaLocation=3D"urn:ietf:params:xml:ns:simple-filter" > >> elementFormDefault=3D"qualified" > >> attributeFormDefault=3D"unqualified"> > >> > >> > >> > >=20 > >=20 > > This works. I used=20 > >=20 > > > > urn=3D"urn:ietf:params:xml:ns:pidf:rpid-tuple"/> > > > > > >=20 > > Is this acceptable? > >=20 > >=20 >=20 > Yes, at least to me. Ok, I'll add. >=20 >=20 > >> >=20 > >>- Section 3.3.1.1. The first paragraph is ok, but the=20 > remaining of the > >>section has nothing to do with the 'type' attribute. I=20 > >>believe the rest > >>should be moved to Section 4, as it discusses the syntax. > >=20 > >=20 > > I moved to section 3.3.1 where is defined. > >=20 >=20 > I don't think it makes much sense. Basically, most of the=20 > section 3.3.1=20 > speaks about syntax of Xpath expressions, which happens to be the=20 > subject of section 4. I see a duplication. So you should=20 > choose how to=20 > document it, but make sure you don't repeat "syntax" sections. Sorry, typo. I did move to section 4. Hisham _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jul 8 07:36: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 HAA14944 for ; Thu, 8 Jul 2004 07: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 1BiXCV-0005Bq-N5 for simple-archive@ietf.org; Thu, 08 Jul 2004 07:36:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BiXBa-0004sQ-00 for simple-archive@ietf.org; Thu, 08 Jul 2004 07:35:31 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BiXAs-0004R1-00; Thu, 08 Jul 2004 07:34:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BiWeM-0000Iw-I7; Thu, 08 Jul 2004 07:01:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BiVsD-0001XW-5Q for simple@megatron.ietf.org; Thu, 08 Jul 2004 06:11: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 GAA10716 for ; Thu, 8 Jul 2004 06:11: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 1BiVs5-0001EL-RS for simple@ietf.org; Thu, 08 Jul 2004 06:11:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BiVr6-0000ua-00 for simple@ietf.org; Thu, 08 Jul 2004 06:10:16 -0400 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1BiVqH-0000U9-00 for simple@ietf.org; Thu, 08 Jul 2004 06:09:25 -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 i68A9PA26160 for ; Thu, 8 Jul 2004 13:09:25 +0300 (EET DST) X-Scanned: Thu, 8 Jul 2004 13:09: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 i68A9OR7006211 for ; Thu, 8 Jul 2004 13:09:24 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 005TYyI1; Thu, 08 Jul 2004 13:09: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 i68A9Nu26029 for ; Thu, 8 Jul 2004 13:09:23 +0300 (EET DST) Received: from nokia.com ([172.21.42.108]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 8 Jul 2004 13:09:09 +0300 Message-ID: <40ED1D45.2080109@nokia.com> Date: Thu, 08 Jul 2004 13:09:09 +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: "Khartabil Hisham (Nokia-TP-MSW/Helsinki)" Subject: Re: [Simple] WGLC: Event Filtering References: <2038BCC78B1AD641891A0D1AE133DBB7023EEAE4@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB7023EEAE4@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Jul 2004 10:09:09.0905 (UTC) FILETIME=[9C75A810:01C464D3] 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 Khartabil Hisham (Nokia-TP-MSW/Helsinki) wrote: > >>-----Original Message----- >>From: Miguel Garcia [mailto:Miguel.An.Garcia@nokia.com] >>Sent: 07.July.2004 17:16 >>To: Khartabil Hisham (Nokia-TP-MSW/Helsinki) >>Cc: simple@ietf.org >>Subject: Re: [Simple] WGLC: Event Filtering >> >> >>Khartabil Hisham (Nokia-TP-MSW/Helsinki) wrote: >> >> >>>>b) Implementations MUST support this MIME type. >>> >>> >>>Functionality draft issue. >>> >> >>M.G: I think I expressed myself wrong, because obviously it does not >>make sense that you define a MIME type and in the same >>document you say >>that implementations MUST suppport it, so I agree with you. >>But I think >>the text I am looking for is something that indicates that when an >>implementation encodes a Filter Criteria document, it MUST set the >>Content-Type header (or whatever protocol) to simple-filter+xml. Then >>the functionality draft can say that implementations MUST >>support filter >>criteria documents. > > > We don't want to dictate how a filter arrives at a server or what protocol is used to upload such filters. Content-type header gives the false impression that this XML document is only used with SUBSCRIBE requests. A filter can be uploaded using some other means than SIP SUBSCRIBE. > Hisham, as you know, a Content-Type header is not SIP-specific. It is available for SIP, HTTP, e-mail, etc. This header just describes the type of body, irrespective the protocol used to transfer the contents. So even if you use HTTP or MSRP (crazy, I know it, just a hypothetical example) to transfer a filter criteria document, still you will need to populate the Content-Type header with a simple-filter+xml. As a consequence, I believe the filter format document should state that whatever is the protocol you use to transfer the contents, the MIME type is set to simple-filter+xml, so is the Content-Type header. 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 Thu Jul 8 07:44: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 HAA15399 for ; Thu, 8 Jul 2004 07: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 1BiXKF-0007jd-9o for simple-archive@ietf.org; Thu, 08 Jul 2004 07:44:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BiXJJ-0007Qm-00 for simple-archive@ietf.org; Thu, 08 Jul 2004 07:43:30 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BiXIR-0006p5-00; Thu, 08 Jul 2004 07:42:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BiWlK-0002Eh-1Q; Thu, 08 Jul 2004 07:08:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BiW5m-0006KW-Fr for simple@megatron.ietf.org; Thu, 08 Jul 2004 06:25: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 GAA11402 for ; Thu, 8 Jul 2004 06:25: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 1BiW5f-00063z-4c for simple@ietf.org; Thu, 08 Jul 2004 06:25:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BiW4k-0005k6-00 for simple@ietf.org; Thu, 08 Jul 2004 06:24:23 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1BiW3u-0005Oo-00 for simple@ietf.org; Thu, 08 Jul 2004 06:23:31 -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 i68ANUB05900 for ; Thu, 8 Jul 2004 13:23:30 +0300 (EET DST) X-Scanned: Thu, 8 Jul 2004 13:23:27 +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 i68ANRUR017990 for ; Thu, 8 Jul 2004 13:23:27 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00mkLlwC; Thu, 08 Jul 2004 13:23:27 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 i68ANPn26635 for ; Thu, 8 Jul 2004 13:23: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); Thu, 8 Jul 2004 13:23:23 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] WGLC: Event Filtering x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Date: Thu, 8 Jul 2004 13:23:24 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7023EEAE8@esebe019.ntc.nokia.com> Thread-Topic: [Simple] WGLC: Event Filtering Thread-Index: AcRk051E809zikajTTaol42QqWy3jQAAWfMQ To: X-OriginalArrivalTime: 08 Jul 2004 10:23:23.0309 (UTC) FILETIME=[9920C5D0:01C464D5] 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: Miguel Garcia [mailto:Miguel.An.Garcia@nokia.com] > Sent: 08.July.2004 13:09 > To: Khartabil Hisham (Nokia-TP-MSW/Helsinki) > Cc: simple@ietf.org > Subject: Re: [Simple] WGLC: Event Filtering >=20 >=20 > Khartabil Hisham (Nokia-TP-MSW/Helsinki) wrote: > >=20 > >>-----Original Message----- > >>From: Miguel Garcia [mailto:Miguel.An.Garcia@nokia.com] > >>Sent: 07.July.2004 17:16 > >>To: Khartabil Hisham (Nokia-TP-MSW/Helsinki) > >>Cc: simple@ietf.org > >>Subject: Re: [Simple] WGLC: Event Filtering > >> > >> > >>Khartabil Hisham (Nokia-TP-MSW/Helsinki) wrote: > >> > >> > >>>>b) Implementations MUST support this MIME type. > >>> > >>> > >>>Functionality draft issue. > >>> > >> > >>M.G: I think I expressed myself wrong, because obviously it=20 > does not=20 > >>make sense that you define a MIME type and in the same=20 > >>document you say=20 > >>that implementations MUST suppport it, so I agree with you.=20 > >>But I think=20 > >>the text I am looking for is something that indicates that when an=20 > >>implementation encodes a Filter Criteria document, it MUST set the=20 > >>Content-Type header (or whatever protocol) to=20 > simple-filter+xml. Then=20 > >>the functionality draft can say that implementations MUST=20 > >>support filter=20 > >>criteria documents. > >=20 > >=20 > > We don't want to dictate how a filter arrives at a server=20 > or what protocol is used to upload such filters. Content-type=20 > header gives the false impression that this XML document is=20 > only used with SUBSCRIBE requests. A filter can be uploaded=20 > using some other means than SIP SUBSCRIBE. > >=20 >=20 > Hisham, as you know, a Content-Type header is not SIP-specific. It is=20 > available for SIP, HTTP, e-mail, etc. This header just describes the=20 > type of body, irrespective the protocol used to transfer the=20 > contents.=20 > So even if you use HTTP or MSRP (crazy, I know it, just a=20 > hypothetical=20 > example) to transfer a filter criteria document, still you=20 > will need to=20 > populate the Content-Type header with a simple-filter+xml. >=20 > As a consequence, I believe the filter format document should=20 > state that=20 > whatever is the protocol you use to transfer the contents,=20 > the MIME type=20 > is set to simple-filter+xml, so is the Content-Type header. I could be manually configuring those filters and not use any transport = protocol. But Ok, I will add the following: Any transport protocol that is used to carry the filters MUST identify = the payload as MIME type "simple-filter+xml", if the transport protocol = carries such information (for example: a Content-Type header). Regards, Hisham >=20 > Regards, >=20 > Miguel > --=20 > Miguel A. Garcia tel:+358-50-4804586 > Nokia Research Center Helsinki, Finland >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jul 8 10:28: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 KAA26069 for ; Thu, 8 Jul 2004 10:28: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 1BiZsg-0004sQ-Hg for simple-archive@ietf.org; Thu, 08 Jul 2004 10:28:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BiZqL-0004C9-00 for simple-archive@ietf.org; Thu, 08 Jul 2004 10:25:47 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BiZnc-0002v3-00; Thu, 08 Jul 2004 10:22:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BiZ73-0005U8-Vm; Thu, 08 Jul 2004 09:38:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BiYLM-0007hz-1z for simple@megatron.ietf.org; Thu, 08 Jul 2004 08:49:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17894 for ; Thu, 8 Jul 2004 08:49: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 1BiYL6-0004SY-Eh for simple@ietf.org; Thu, 08 Jul 2004 08:49:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BiYKD-0004BC-00 for simple@ietf.org; Thu, 08 Jul 2004 08:48:30 -0400 Received: from ns.execdsl.net ([208.184.15.238] helo=EXECDSL.COM) by ietf-mx with esmtp (Exim 4.12) id 1BiYJv-0003tK-00 for simple@ietf.org; Thu, 08 Jul 2004 08:48:11 -0400 Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 7185384; Thu, 08 Jul 2004 08:47:58 -0400 Message-Id: <5.1.0.14.0.20040708083645.023da180@localhost> X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 08 Jul 2004 08:47:39 -0400 To: Miguel Garcia From: "Joel M. Halpern" Subject: Re: [Simple] Large response ? In-Reply-To: <40ECEBA0.9070804@nokia.com> References: <5.1.0.14.0.20040707103647.023de8c8@localhost> <5.1.0.14.0.20040707080624.023eb198@localhost> <5.1.0.14.0.20040706111036.023f5320@localhost> <40EA0018.3080408@dynamicsoft.com> <40E5C2E1.50502@dynamicsoft.com> <40E903D2.2050703@nokia.com> <40EA0018.3080408@dynamicsoft.com> <5.1.0.14.0.20040706111036.023f5320@localhost> <5.1.0.14.0.20040707080624.023eb198@localhost> <5.1.0.14.0.20040707103647.023de8c8@localhost> Mime-Version: 1.0 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 I am sorry. I can not understand the case where the client can not repair the partial answer, but somehow can get a meaningful answer when it is provided as complete XML elements. (I presume the example you gave was over-simpilifed, but in the example, there is no anser that will fit.) a) If the server sends as much as fits in the "buffer", the client can always parse forward, trim backwards, add closing elements as needed, and end up with more content than would have been shipped if the server had shipped only the elements that it somehow knew would fit. b) given that the length of the content of the elements is not known, I do not understand in what terms an element count limit will help a client cope with a resource limitation. c) The requirement as you state it seems to edge in to the solution. I understand that the client software wants to request part of a document. I understand that to present this to the user the client software will need a well-formed XML document. I do not understand why it follows that the partial document that is delivered must be well-formed, since the client can work it over any way it chooses. From the last sentence, you seem to be driving towards a specific implementation. d) When we starting putting on constraint about which portions of a document can be requested using this mechanism, and what "schema compliance" is supposed to mean about the answer we are crafting a very specialized solution, rather than tackling a general problem. And that will make it difficult to build compliant XCAP servers that can cope easily with multiple schemas and schema changes. Yours, Joel M. Halpern In a separate message Miguel Garcia wrote: Right. So let's try to formulate the requirement. We are looking for a mechanism that allows an XCAP client to request fractions of an XML document, so that the returned document is valid but need not include all the repeatable entries. This allows the XCAP client to operate on the XML document (render and manipulate it), release the memory, request the next fraction of the same XML document, and start the process again. At 09:37 AM 7/8/2004 +0300, Miguel Garcia wrote: >Joel: > >Let me try to give you a concrete example where you can see that the byte >range does not server for the purpose: > >Imagine I want to request this very simple XML document > > > This is an element > > >Now, when I request this document, I request a byte range (say, 0 to x >bytes). The server apply the count on the byte range, and cut the >document. It returns me the following document: > > > This is a > >So my XCAP client will not consider the document even well-formed, not >even valid. So what can my XCAP client do with this document? I have two >options: > >a) request the remaining of the document. But since I applied a byte >range, presumably because my XCAP client does not have more available >memory to request a longer document (otherwise, why did I request a byte >range in the first place), I cannot store this partial document and >request the remaining parts (I don't have memory to store the remaining >parts). So this does not solve the problem. > >b) dispose the document in the garbage bin (a.k.a. release the memory), >and request the complete document. But again we are in the same situation >as in a), the terminal requested a byte range in the first place, so what >for if it has to request the remaining document? > >Is there any other solution you can envision? I don't, and therefore my >conclusion is that byte ranges does not serve for the purpose. > >Regards, > > Miguel > >Joel M. Halpern wrote: > >>There appears to be some (reasonable) desire to get part of an XML >>Configuration, where "part" means not a just selection of identified >>elements but some other subseting. >>This appears to be driven by some combination of client memory and user >>presentation resources. >>Rather than trying to argue that some solution meets the needs, I would >>like to see a clear and reasonably complete list of requirements. I can >>believe that there is some requirement that is not met by byte-range for >>example, but I do not know what it is. >>Yours, >>Joel M. Halpern >> >>_______________________________________________ >>Simple mailing list >>Simple@ietf.org >>https://www1.ietf.org/mailman/listinfo/simple > >-- >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 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jul 8 11:52: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 LAA04433 for ; Thu, 8 Jul 2004 11:52: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 1BibCT-0004NE-LV for simple-archive@ietf.org; Thu, 08 Jul 2004 11:52:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BibBR-0003y9-00 for simple-archive@ietf.org; Thu, 08 Jul 2004 11:51:38 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BibAN-00038U-00; Thu, 08 Jul 2004 11:50:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BiaiW-0006jr-RI; Thu, 08 Jul 2004 11:21:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BiaFV-0007xx-KS for simple@megatron.ietf.org; Thu, 08 Jul 2004 10: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 KAA27808 for ; Thu, 8 Jul 2004 10:51: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 1BiaFP-0005Cf-Ol for simple@ietf.org; Thu, 08 Jul 2004 10:51:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BiaEQ-0004sq-00 for simple@ietf.org; Thu, 08 Jul 2004 10:50:39 -0400 Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx with esmtp (Exim 4.12) id 1BiaE1-0004Yk-00 for simple@ietf.org; Thu, 08 Jul 2004 10:50: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 i68Enpou001081; Thu, 8 Jul 2004 09:49:51 -0500 (CDT) Received: by eamrcnt750.exu.ericsson.se with Internet Mail Service (5.5.2657.72) id <3J94ZR02>; Thu, 8 Jul 2004 09:48:37 -0500 Message-ID: From: "George Foti (QA/EMC)" To: "'Joel M. Halpern'" , Miguel Garcia Subject: RE: [Simple] Large response ? Date: Thu, 8 Jul 2004 09:40:00 -0500 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.1 required=5.0 tests=AWL autolearn=no version=2.60 Isnt it a trade-off of where you put the complexity to repair the document, in the client or in the server. We need really the requirments to be spelled out to better judge how to proceed. Rgds/gf > -----Original Message----- > From: simple-bounces@ietf.org > [mailto:simple-bounces@ietf.org]On Behalf > Of Joel M. Halpern > Sent: Thursday, July 08, 2004 8:48 AM > To: Miguel Garcia > Cc: simple@ietf.org > Subject: Re: [Simple] Large response ? > > > I am sorry. I can not understand the case where the client > can not repair > the partial answer, but somehow can get a meaningful answer > when it is > provided as complete XML elements. (I presume the example > you gave was > over-simpilifed, but in the example, there is no anser that will fit.) > > a) If the server sends as much as fits in the "buffer", the > client can > always parse forward, trim backwards, add closing elements as > needed, and > end up with more content than would have been shipped if the > server had > shipped only the elements that it somehow knew would fit. > b) given that the length of the content of the elements is > not known, I do > not understand in what terms an element count limit will help > a client cope > with a resource limitation. > c) The requirement as you state it seems to edge in to the > solution. I > understand that the client software wants to request part of > a document. I > understand that to present this to the user the client > software will need a > well-formed XML document. I do not understand why it follows > that the > partial document that is delivered must be well-formed, since > the client > can work it over any way it chooses. From the last sentence, > you seem to > be driving towards a specific implementation. > d) When we starting putting on constraint about which portions of a > document can be requested using this mechanism, and what "schema > compliance" is supposed to mean about the answer we are > crafting a very > specialized solution, rather than tackling a general problem. > And that > will make it difficult to build compliant XCAP servers that > can cope easily > with multiple schemas and schema changes. > > Yours, > Joel M. Halpern > > > In a separate message Miguel Garcia wrote: > Right. So let's try to formulate the requirement. We are > looking for a > mechanism that allows an XCAP client to request fractions of an XML > document, so that the returned document is valid but need not > include all > the repeatable entries. This allows the XCAP client to > operate on the XML > document (render and manipulate it), release the memory, > request the next > fraction of the same XML document, and start the process again. > > > At 09:37 AM 7/8/2004 +0300, Miguel Garcia wrote: > >Joel: > > > >Let me try to give you a concrete example where you can see > that the byte > >range does not server for the purpose: > > > >Imagine I want to request this very simple XML document > > > > > > This is an element > > > > > >Now, when I request this document, I request a byte range > (say, 0 to x > >bytes). The server apply the count on the byte range, and cut the > >document. It returns me the following document: > > > > > > This is a > > > >So my XCAP client will not consider the document even > well-formed, not > >even valid. So what can my XCAP client do with this > document? I have two > >options: > > > >a) request the remaining of the document. But since I applied a byte > >range, presumably because my XCAP client does not have more > available > >memory to request a longer document (otherwise, why did I > request a byte > >range in the first place), I cannot store this partial document and > >request the remaining parts (I don't have memory to store > the remaining > >parts). So this does not solve the problem. > > > >b) dispose the document in the garbage bin (a.k.a. release > the memory), > >and request the complete document. But again we are in the > same situation > >as in a), the terminal requested a byte range in the first > place, so what > >for if it has to request the remaining document? > > > >Is there any other solution you can envision? I don't, and > therefore my > >conclusion is that byte ranges does not serve for the purpose. > > > >Regards, > > > > Miguel > > > >Joel M. Halpern wrote: > > > >>There appears to be some (reasonable) desire to get part of an XML > >>Configuration, where "part" means not a just selection of > identified > >>elements but some other subseting. > >>This appears to be driven by some combination of client > memory and user > >>presentation resources. > >>Rather than trying to argue that some solution meets the > needs, I would > >>like to see a clear and reasonably complete list of > requirements. I can > >>believe that there is some requirement that is not met by > byte-range for > >>example, but I do not know what it is. > >>Yours, > >>Joel M. Halpern > >> > >>_______________________________________________ > >>Simple mailing list > >>Simple@ietf.org > >>https://www1.ietf.org/mailman/listinfo/simple > > > >-- > >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 > > > _______________________________________________ > Simple mailing 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 Jul 8 15:20: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 PAA21213 for ; Thu, 8 Jul 2004 15:20: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 1BieRw-000007-2H for simple-archive@ietf.org; Thu, 08 Jul 2004 15:20:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BieR1-0007Px-00 for simple-archive@ietf.org; Thu, 08 Jul 2004 15:19:56 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BieQT-00072Q-00; Thu, 08 Jul 2004 15: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 1Biax4-0003DI-5l; Thu, 08 Jul 2004 11:36:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BiadR-00052j-W2; Thu, 08 Jul 2004 11:16:30 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00314; Thu, 8 Jul 2004 11:16:27 -0400 (EDT) Message-Id: <200407081516.LAA00314@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Thu, 08 Jul 2004 11:16:27 -0400 Cc: simple@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-cipid-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 : CIPID: Contact Information in Presence Information Data Format Author(s) : H. Schulzrinne Filename : draft-ietf-simple-cipid-02.txt Pages : 9 Date : 2004-7-6 The Presence Information Data Format (PIDF) defines a basic XML format for presenting presence information for a presentity. The Contact Information for Presence Information Data Format (CIPID) is an extension that adds elements to PIDF that provide additional contact information about a presentity and its contacts, including references to address book entries and icons. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-cipid-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-cipid-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-cipid-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-7-6152039.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-cipid-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-cipid-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-7-6152039.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 Jul 8 16:19: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 QAA25380 for ; Thu, 8 Jul 2004 16: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 1BifMM-00063F-Q5 for simple-archive@ietf.org; Thu, 08 Jul 2004 16:19:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BifIN-0005BR-00 for simple-archive@ietf.org; Thu, 08 Jul 2004 16:15:05 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BifH1-0004Ws-02; Thu, 08 Jul 2004 16:13:39 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BifBj-0004FW-AW; Thu, 08 Jul 2004 16:08:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BibGF-00081x-Vw; Thu, 08 Jul 2004 11:56:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Biav1-0001rG-CN for simple@megatron.ietf.org; Thu, 08 Jul 2004 11:34: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 LAA02804 for ; Thu, 8 Jul 2004 11:34: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 1Biauv-0004kS-CE for simple@ietf.org; Thu, 08 Jul 2004 11:34:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Biaty-0004Po-00 for simple@ietf.org; Thu, 08 Jul 2004 11:33:35 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx with esmtp (Exim 4.12) id 1Biasr-0003Pu-01 for simple@ietf.org; Thu, 08 Jul 2004 11:32:25 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 08 Jul 2004 11:30: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 i68FVlN9005539; Thu, 8 Jul 2004 11:31:47 -0400 (EDT) Received: from mhammer-w2k03.cisco.com (dhcp-hrn-64-100-229-208.cisco.com [64.100.229.208]) by fruitpie.cisco.com (MOS 3.4.6-GR) with ESMTP id BAL36183; Thu, 8 Jul 2004 08:31:48 -0700 (PDT) Message-Id: <4.3.2.7.2.20040708112121.00b17868@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 08 Jul 2004 11:32:54 -0400 To: "Barry Dingle" , , , From: Mike Hammer Subject: Re: Tiny ant vs big Mammoths, was RE: [Simple] Using MSRP for real time text conversation In-Reply-To: <070601c46485$787618d0$b631c2cb@Home> References: <4.3.2.7.2.20040707110031.00b17d00@cia.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Barry Dingle X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org 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,MAILTO_TO_SPAM_ADDR autolearn=no version=2.60 Barry, I would object to the ENTERED aspect, as that starts into specifying the nature of the service beyond the transmission performance requirements. As a user, I always want to reserve the right to edit and erase or correct my text before indicating intent to transmit information. If you want to make it more generic and service independent, you would need to say something like: Transmission delay must be less than N ms from when the sender intends for the text data to be sent. "Intent" can be automated or manually indicated. Note that the main difference between the RTT and IM modes of texting is that the RTT user has his intent to send automated to do so after every character, with possibly a buffer batching characters into one message when within 300 ms of each other. In the case of IM, the intent to send is an explicit indication by hitting the ENTER, SEND, or similar key. A performance metric should not preclude that feature. Q: Does the 300ms batching count against the transmission delay in your ENTERED proposal? My suggestion would put that outside the transmission delay. It would be possible on IM systems to put a timer on the sending aspect that in the limit would approach the behavior of RTT. However, the approach of some systems to interleave lines of text of various parties engaged in an IM session into the same window would need to change. Mike At 10:49 AM 7/8/2004 +1000, Barry Dingle wrote: >Mike, > >Comments below. > >Barry DINGLE > >----- Original Message ----- >From: "Mike Hammer" >To: "Barry Dingle" >Sent: Thursday, July 08, 2004 1:04 AM >Subject: Re: Tiny ant vs big Mammoths, was RE: [Simple] Using MSRP for >real time text conversation > > > > Does Australia define what is considered "real-time", form a > performance measurement perspective? > > >Good question. We are keen to base our services (text and other) on >international specifications and that is progressively >happening. Our end-to-end service performance requirements are following a >similar approach. That means (at present) that ITU-T >F.700 is used as a starting point. > >(Note that the F.700 T1 2 second delay figure (for useable service) is >often quoted but there is growing interest in specifying >the T2 1 second delay figure (for good service) - along with the lower >character corruption rate as well.) > > > In other words, if the data arrives within, say one second, of when it > was transmitted, be that data one character or one >sentence, is that fast > > enough to be real time? > > >You use a very specific way to define delay in your statement 'when it was >transmitted'. From a user perspective, text >conversation delay is from when each character is entered to when it is >displayed at the remote end. It includes any buffering >delay. > >If I reword your statement to "if the data arrives within, say one second, >of when it was ENTERED, be that data one character or >one sentence, is that fast enough to be real time?" then my answer would >be POSSIBLY YES. The proviso is that the 'user feel' is >different - more bursty. Maybe we need to specify the variability of delay >as well as the delay to cover this situation. (To >start discussion, based on recent discussions, how about a 500 ms delay >variation max?) > > > The reason I ask is that some folks on these mail lists have claimed > that IM is not real time, but I think they are basing >that conclusion on their > > experience with SMS, for which there is an observable delay, rather > than a point-point IM model which is as fast as 2793 once >the send key is pressed. > > >We should base our discussions on 'agreed user requirements', not names >like 'real time' with different meanings to different >people. But the requirements should not be 'manufactured' to suit a >particular service. I said 'real time or near real time' >because I believe that some' near real time' services can be adequate for >text. (Note - speech and video may have different >requirements!!) > > > > Mike > > > > > > At 12:43 PM 7/7/2004 +1000, you wrote: > > >Some thoughts on this subject. I approach this from a Service level. > > > > > >Real time or near real time text service is essential for some > legislative environments eg. Australia where 'equivalent' >service > > >to telephony is defined for people who cannot effectively use telephony. > > > > > >Use of mainstream protocols is important for the disabled community in > order that they can communicate with all people not >just > > >amongst people with the same special terminals. > > > > > >MSRP provides a very useful mainstream, text communication service. It > provides a different 'user feel' to a > > >character-by-character service. Its performance could improve over time. > > > > > >text/t140 (RFC2793) is an important near real time text service that > is consistent with traditional multimedia services and >with > > >the SIP controlled real time multiservice environment. > > > > > >Choice is important for users so that we do not get locked into one > service if a better service becomes available. Therefore > > >negotiation is essential. > > > > > >Both MSRP and rfc2793 work with SIP/SDP so negotiation should not be > too difficult. > > > > > >Cheers, > > > > > >Barry DINGLE > > >Telecommunications Consultant > > >Project Manager - ACIF Any-to-Any Text Connectivity Options WG > > >Fellow of the University of Melbourne > > > barry.dingle@bigfoot.com.au > > >Mob: +61 (0)41 911 7578 > > >Fixed: +61 (0)3 9725 3937 > > >----- Original Message ----- > > >From: "Gunnar Hellstrom" > > >To: "Arnoud van Wijk" > > >Cc: ; ; > > >Sent: Tuesday, July 06, 2004 4:22 PM > > >Subject: RE: Tiny ant vs big Mammoths, was RE: [Simple] Using MSRP for > > >real time text conversation > > > > > > > > > > I opened a new thread under the name > > > > > > > > RE: [Simple] Using MSRP for (pseudo?) real time text conversation > > > > > > > > For discussing conclusions and negotiation. > > > > Hope you all will join there. > > > > > > > > I agree with Arnoud in the impression that any user you show real time > > > text conversation > > > > to, say that it is very good and needed in future services. > > > > > > > > So, please look for the new subject line and start thinking about what > > > inter-relations > > > > that are needed do declare and negotiate what text service you can and > > > want to use. And > > > > answer these messages, so that we get back to one thread. > > > > > > > > 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: owner-toip@snowshore.com [mailto:owner-toip@snowshore.com]On > > > > >Behalf Of Arnoud van Wijk > > > > >Sent: Sunday, July 04, 2004 11:32 AM > > > > >To: hisham.khartabil@nokia.com; Henry.Sinnreich@mci.com; > > > > >dean.willis@softarmor.com > > > > >Cc: bcampbell@dynamicsoft.com; gunnar.hellstrom@omnitor.se; > > > > >adam@dynamicsoft.com; stf267@etsi.org; simple@ietf.org; > > > > >toip@snowshore.com > > > > >Subject: RE: Tiny ant vs big Mammoths, was RE: [Simple] Using MSRP for > > > > >real time text conversation > > > > > > > > > > > > > > >Hisham, > > > > >Actually... > > > > >I did some market research. Based on 15 people. > > > > >3 deaf, 5 worked in deaf related business (hearing people) > > > > >And 7 don't care about deaf (2 of them are IM freaks). > > > > > > > > > >Result: > > > > > > > > > >First telling them about total conversation and Interactive text > > > > >(text/t140). > > > > >It did not mean much to them, they looked glassy eyed. Real-time > charcter > > > > >per character..oh Yawn... lovely... pish posh. They could not imagine > > > it. No > > > > >concept of it. > > > > > > > > > >Then I showed them. > > > > >They could communicate with somebody in Sweden, and with me on a > > > different terminal in a different room. > > > > >All were deeply impressed. > > > > > > > > > >The 3 deaf wanted to take it home right now. Being able to communicate > > > everywhere , everytime..finally free! > > > > >The 5 who worked in the deaf business, they loved it and want to see > > > it implemted and mainstream. They love it and will use > > >it regularly to > > > > >communicate with deaf and some even say that it can be quite > > > convenient for hearing people as well. > > > > > > > > > >The 7 hearing, non deaf related liked it too! > > > > >They said, wow... this is much more direct then IM, you can actually > > > call people in situations where voice is a bit not done > > >(think cinema, concert, > > > > >restaurant, train). They see it as direct real-time IM. > > > > >They will keep using IM anyway. But see uses for text/t140 too and > > > will use it if it is convenient. > > > > >The 2 IM freaks agreed, though they prefer IM, but if somebdoy > > > contacts them via interactive text text/t140, they will use it > > >too. > > > > >"It depends who to contact to use the right text communication method. > > > I like the choice to have an alternative". > > > > > > > > > >So. Yes.. I know people will like it. Not everybody will use > > > interactive text. Some will thus only use if somebody else uses > > >it, whether a deaf > > > > >person or one who likes to use text/t140. > > > > > > > > > >All of them hope that interactive text will be mainstream and will use > > > it with varying degrees, from sometimes, to daily. > > > > > > > > > >So, this is my message, from an interactive text user AND having > > > showed/demonstrated interactive text to other people. It is > > >not my desire > > > > >only. > > > > > > > > > >Greetz > > > > > > > > > >Arnoud > > > > > > > > > >-----Original Message----- > > > > >From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > > > > >Sent: vrijdag 2 juli 2004 9:19 > > > > >To: a.vwijk@viataal.nl; Henry.Sinnreich@mci.com; > dean.willis@softarmor.com > > > > >Cc: bcampbell@dynamicsoft.com; gunnar.hellstrom@omnitor.se; > > > > >adam@dynamicsoft.com; stf267@etsi.org; simple@ietf.org; > toip@snowshore.com > > > > >Subject: RE: Tiny ant vs big Mammoths, was RE: [Simple] Using MSRP for > > > real > > > > >time text conversation > > > > > > > > > >Arnoud, > > > > > > > > > >You speak as if you have done the market research already for all > of us :) > > > > >How do you know that people will appreciate it once they discover it? > > > How do > > > > >you know that people will use it? How do you know that it adds value > > > to the > > > > >phone instead of just implementing something that no one will use? > How do > > > > >you know that if I like interactive text, then my mum and dad will and > > > buy a > > > > >phone like mine just to use interactive text???? How do you know...? > > > > > > > > > >Did people complain to you that IM the way it is these days in > annoying to > > > > >use? or are you just stating your opinion? > > > > > > > > > >And about mobile phones. If you can type an SMS faster than 2 > characters a > > > > >second, you're a genius. Even if you can, I don't believe > operators would > > > > >want to floor they scarce air interface with IP packets that carry 2 > > > > >characters at a time. > > > > > > > > > >Thanks, > > > > >Hisham > > > > > > > > > > > > > > >- > > > > >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 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 > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jul 8 17:30: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 RAA01980 for ; Thu, 8 Jul 2004 17:30: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 1BigTQ-0006xQ-3U for simple-archive@ietf.org; Thu, 08 Jul 2004 17:30:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BigQg-00067R-00 for simple-archive@ietf.org; Thu, 08 Jul 2004 17:27:44 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BigNH-0005F2-00; Thu, 08 Jul 2004 17:24:11 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BigNI-0006iT-5c; Thu, 08 Jul 2004 17:24:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BifJR-0004dS-VY; Thu, 08 Jul 2004 16:16:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BiNCo-0006ix-OI for simple@megatron.ietf.org; Wed, 07 Jul 2004 20:56:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01370 for ; Wed, 7 Jul 2004 20:55: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 1BiNCd-0002nI-3M for simple@ietf.org; Wed, 07 Jul 2004 20:55:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BiNBk-0002V9-00 for simple@ietf.org; Wed, 07 Jul 2004 20:55:01 -0400 Received: from voodoo.izone.net.au ([202.160.129.225]) by ietf-mx with esmtp (Exim 4.12) id 1BiNB3-0002CK-00 for simple@ietf.org; Wed, 07 Jul 2004 20:54:17 -0400 Received: from Home (dialup-140.81.220.203.acc05-dryb-mel.comindico.com.au [203.220.81.140]) by voodoo.izone.net.au (Postfix) with SMTP id 34A358A8; Thu, 8 Jul 2004 10:50:00 +1000 (EST) Message-ID: <070601c46485$787618d0$b631c2cb@Home> From: "Barry Dingle" To: "Mike Hammer" , , , References: <4.3.2.7.2.20040707110031.00b17d00@cia.cisco.com> Subject: Re: Tiny ant vs big Mammoths, was RE: [Simple] Using MSRP for real time text conversation Date: Thu, 8 Jul 2004 10:49:45 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-AFFINITYINTERNET-MailScanner-Information: Please contact support on 1300 85 75 65 for more information X-AFFINITYINTERNET-MailScanner: Found to be clean X-MailScanner-From: barry.dingle@bigfoot.com.au Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 08 Jul 2004 16:16:08 -0400 Cc: Barry Dingle X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.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,MAILTO_TO_SPAM_ADDR autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Mike, Comments below. Barry DINGLE ----- Original Message ----- From: "Mike Hammer" To: "Barry Dingle" Sent: Thursday, July 08, 2004 1:04 AM Subject: Re: Tiny ant vs big Mammoths, was RE: [Simple] Using MSRP for real time text conversation > Does Australia define what is considered "real-time", form a performance measurement perspective? > Good question. We are keen to base our services (text and other) on international specifications and that is progressively happening. Our end-to-end service performance requirements are following a similar approach. That means (at present) that ITU-T F.700 is used as a starting point. (Note that the F.700 T1 2 second delay figure (for useable service) is often quoted but there is growing interest in specifying the T2 1 second delay figure (for good service) - along with the lower character corruption rate as well.) > In other words, if the data arrives within, say one second, of when it was transmitted, be that data one character or one sentence, is that fast > enough to be real time? > You use a very specific way to define delay in your statement 'when it was transmitted'. From a user perspective, text conversation delay is from when each character is entered to when it is displayed at the remote end. It includes any buffering delay. If I reword your statement to "if the data arrives within, say one second, of when it was ENTERED, be that data one character or one sentence, is that fast enough to be real time?" then my answer would be POSSIBLY YES. The proviso is that the 'user feel' is different - more bursty. Maybe we need to specify the variability of delay as well as the delay to cover this situation. (To start discussion, based on recent discussions, how about a 500 ms delay variation max?) > The reason I ask is that some folks on these mail lists have claimed that IM is not real time, but I think they are basing that conclusion on their > experience with SMS, for which there is an observable delay, rather than a point-point IM model which is as fast as 2793 once the send key is pressed. > We should base our discussions on 'agreed user requirements', not names like 'real time' with different meanings to different people. But the requirements should not be 'manufactured' to suit a particular service. I said 'real time or near real time' because I believe that some' near real time' services can be adequate for text. (Note - speech and video may have different requirements!!) > Mike > > > At 12:43 PM 7/7/2004 +1000, you wrote: > >Some thoughts on this subject. I approach this from a Service level. > > > >Real time or near real time text service is essential for some legislative environments eg. Australia where 'equivalent' service > >to telephony is defined for people who cannot effectively use telephony. > > > >Use of mainstream protocols is important for the disabled community in order that they can communicate with all people not just > >amongst people with the same special terminals. > > > >MSRP provides a very useful mainstream, text communication service. It provides a different 'user feel' to a > >character-by-character service. Its performance could improve over time. > > > >text/t140 (RFC2793) is an important near real time text service that is consistent with traditional multimedia services and with > >the SIP controlled real time multiservice environment. > > > >Choice is important for users so that we do not get locked into one service if a better service becomes available. Therefore > >negotiation is essential. > > > >Both MSRP and rfc2793 work with SIP/SDP so negotiation should not be too difficult. > > > >Cheers, > > > >Barry DINGLE > >Telecommunications Consultant > >Project Manager - ACIF Any-to-Any Text Connectivity Options WG > >Fellow of the University of Melbourne > > barry.dingle@bigfoot.com.au > >Mob: +61 (0)41 911 7578 > >Fixed: +61 (0)3 9725 3937 > >----- Original Message ----- > >From: "Gunnar Hellstrom" > >To: "Arnoud van Wijk" > >Cc: ; ; > >Sent: Tuesday, July 06, 2004 4:22 PM > >Subject: RE: Tiny ant vs big Mammoths, was RE: [Simple] Using MSRP for > >real time text conversation > > > > > > > I opened a new thread under the name > > > > > > RE: [Simple] Using MSRP for (pseudo?) real time text conversation > > > > > > For discussing conclusions and negotiation. > > > Hope you all will join there. > > > > > > I agree with Arnoud in the impression that any user you show real time > > text conversation > > > to, say that it is very good and needed in future services. > > > > > > So, please look for the new subject line and start thinking about what > > inter-relations > > > that are needed do declare and negotiate what text service you can and > > want to use. And > > > answer these messages, so that we get back to one thread. > > > > > > 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: owner-toip@snowshore.com [mailto:owner-toip@snowshore.com]On > > > >Behalf Of Arnoud van Wijk > > > >Sent: Sunday, July 04, 2004 11:32 AM > > > >To: hisham.khartabil@nokia.com; Henry.Sinnreich@mci.com; > > > >dean.willis@softarmor.com > > > >Cc: bcampbell@dynamicsoft.com; gunnar.hellstrom@omnitor.se; > > > >adam@dynamicsoft.com; stf267@etsi.org; simple@ietf.org; > > > >toip@snowshore.com > > > >Subject: RE: Tiny ant vs big Mammoths, was RE: [Simple] Using MSRP for > > > >real time text conversation > > > > > > > > > > > >Hisham, > > > >Actually... > > > >I did some market research. Based on 15 people. > > > >3 deaf, 5 worked in deaf related business (hearing people) > > > >And 7 don't care about deaf (2 of them are IM freaks). > > > > > > > >Result: > > > > > > > >First telling them about total conversation and Interactive text > > > >(text/t140). > > > >It did not mean much to them, they looked glassy eyed. Real-time charcter > > > >per character..oh Yawn... lovely... pish posh. They could not imagine > > it. No > > > >concept of it. > > > > > > > >Then I showed them. > > > >They could communicate with somebody in Sweden, and with me on a > > different terminal in a different room. > > > >All were deeply impressed. > > > > > > > >The 3 deaf wanted to take it home right now. Being able to communicate > > everywhere , everytime..finally free! > > > >The 5 who worked in the deaf business, they loved it and want to see > > it implemted and mainstream. They love it and will use > >it regularly to > > > >communicate with deaf and some even say that it can be quite > > convenient for hearing people as well. > > > > > > > >The 7 hearing, non deaf related liked it too! > > > >They said, wow... this is much more direct then IM, you can actually > > call people in situations where voice is a bit not done > >(think cinema, concert, > > > >restaurant, train). They see it as direct real-time IM. > > > >They will keep using IM anyway. But see uses for text/t140 too and > > will use it if it is convenient. > > > >The 2 IM freaks agreed, though they prefer IM, but if somebdoy > > contacts them via interactive text text/t140, they will use it > >too. > > > >"It depends who to contact to use the right text communication method. > > I like the choice to have an alternative". > > > > > > > >So. Yes.. I know people will like it. Not everybody will use > > interactive text. Some will thus only use if somebody else uses > >it, whether a deaf > > > >person or one who likes to use text/t140. > > > > > > > >All of them hope that interactive text will be mainstream and will use > > it with varying degrees, from sometimes, to daily. > > > > > > > >So, this is my message, from an interactive text user AND having > > showed/demonstrated interactive text to other people. It is > >not my desire > > > >only. > > > > > > > >Greetz > > > > > > > >Arnoud > > > > > > > >-----Original Message----- > > > >From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > > > >Sent: vrijdag 2 juli 2004 9:19 > > > >To: a.vwijk@viataal.nl; Henry.Sinnreich@mci.com; dean.willis@softarmor.com > > > >Cc: bcampbell@dynamicsoft.com; gunnar.hellstrom@omnitor.se; > > > >adam@dynamicsoft.com; stf267@etsi.org; simple@ietf.org; toip@snowshore.com > > > >Subject: RE: Tiny ant vs big Mammoths, was RE: [Simple] Using MSRP for > > real > > > >time text conversation > > > > > > > >Arnoud, > > > > > > > >You speak as if you have done the market research already for all of us :) > > > >How do you know that people will appreciate it once they discover it? > > How do > > > >you know that people will use it? How do you know that it adds value > > to the > > > >phone instead of just implementing something that no one will use? How do > > > >you know that if I like interactive text, then my mum and dad will and > > buy a > > > >phone like mine just to use interactive text???? How do you know...? > > > > > > > >Did people complain to you that IM the way it is these days in annoying to > > > >use? or are you just stating your opinion? > > > > > > > >And about mobile phones. If you can type an SMS faster than 2 characters a > > > >second, you're a genius. Even if you can, I don't believe operators would > > > >want to floor they scarce air interface with IP packets that carry 2 > > > >characters at a time. > > > > > > > >Thanks, > > > >Hisham > > > > > > > > > > > >- > > > >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 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 > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jul 8 19:35: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 TAA14006 for ; Thu, 8 Jul 2004 19:35: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 1BiiQk-0006xW-MZ for simple-archive@ietf.org; Thu, 08 Jul 2004 19:35:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BiiPk-0006Y7-00 for simple-archive@ietf.org; Thu, 08 Jul 2004 19:34:52 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BiiOe-0005pa-00; Thu, 08 Jul 2004 19:33:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BigJd-000279-5h; Thu, 08 Jul 2004 17:20:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BifOc-00051x-KA for simple@megatron.ietf.org; Thu, 08 Jul 2004 16:21: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 QAA25728 for ; Thu, 8 Jul 2004 16: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 1BifOY-0006da-SL for simple@ietf.org; Thu, 08 Jul 2004 16:21:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BifNT-0006BM-00 for simple@ietf.org; Thu, 08 Jul 2004 16:20:19 -0400 Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx with esmtp (Exim 4.12) id 1BifL6-0005Vy-00 for simple@ietf.org; Thu, 08 Jul 2004 16:17:52 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.175); Thu, 8 Jul 2004 13:17:19 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 8 Jul 2004 13:19:26 -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] Friendly Display Name in Presence Schema? Date: Thu, 8 Jul 2004 13:17:23 -0700 Message-ID: Thread-Topic: [Simple] Friendly Display Name in Presence Schema? Thread-Index: AcRkpuxERY0k2CsfQE+cldo5NwLMLgAfXr9w From: "Orit Levin" To: "Jonathan Rosenberg" , "Henning Schulzrinne" X-OriginalArrivalTime: 08 Jul 2004 20:19:26.0683 (UTC) FILETIME=[DDC292B0:01C46528] 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 The protocol difference or flexibility is in who generates the display name. In some systems, the watcher sets the display name, indeed. In others, it is being set by presentities' aggregation point per user. Still in others, it is the presentity instance itself. Of cause, it is always the policy of the watcher which one(s) to display to the user. There are obvious application usages for each of the approaches.=20 Would somebody object for adding "presentity-display-name" as one of the optional elements to the CIPID XML schema? Along the same lines as "card", "icon", etc. (both for the whole presence document and for an individual tuple) ? Thanks, Orit. > -----Original Message----- > From: simple-bounces@ietf.org=20 > [mailto:simple-bounces@ietf.org] On Behalf Of Jonathan Rosenberg > Sent: Wednesday, July 07, 2004 6:13 PM > To: Orit Levin > Cc: simple@ietf.org > Subject: Re: [Simple] Friendly Display Name in Presence Schema? >=20 > I dont think so, no. >=20 > I would think that, in most cases, the display name would be=20 > set by the watcher, and present in their resource list. The=20 > resource list XML does have a display name. >=20 > -Jonathan R. >=20 > Orit Levin wrote: >=20 > > Guys, > > Do we have a friendly display name defined per user in one of our=20 > > presence XML schemas (in addition to the entity URI) ? > > =20 > > Thanks, > > Orit. > >=20 > >=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 >=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 Jul 9 04:19: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 EAA10664 for ; Fri, 9 Jul 2004 04:19: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 1BiqbG-0003k2-3e for simple-archive@ietf.org; Fri, 09 Jul 2004 04:19:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BiqaB-0003QH-00 for simple-archive@ietf.org; Fri, 09 Jul 2004 04:18:13 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BiqZF-0002pc-00; Fri, 09 Jul 2004 04:17:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BiqJo-0000eJ-7n; Fri, 09 Jul 2004 04:01:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bipm1-00049g-V4 for simple@megatron.ietf.org; Fri, 09 Jul 2004 03:26: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 DAA08331 for ; Fri, 9 Jul 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 1Biplp-0002nX-Mv for simple@ietf.org; Fri, 09 Jul 2004 03:26:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bipkp-0002Us-00 for simple@ietf.org; Fri, 09 Jul 2004 03:25:08 -0400 Received: from voodoo.izone.net.au ([202.160.129.225]) by ietf-mx with esmtp (Exim 4.12) id 1Bipjq-0001t7-00 for simple@ietf.org; Fri, 09 Jul 2004 03:24:06 -0400 Received: from Home (dialup-224.51.194.203.acc02-dryb-mel.comindico.com.au [203.194.51.224]) by voodoo.izone.net.au (Postfix) with SMTP id C51105CE58; Fri, 9 Jul 2004 17:21:06 +1000 (EST) Message-ID: <089601c46585$46093200$b631c2cb@Home> From: "Barry Dingle" To: , , , "Mike Hammer" References: <4.3.2.7.2.20040707110031.00b17d00@cia.cisco.com> <4.3.2.7.2.20040708112121.00b17868@cia.cisco.com> Subject: Re: Tiny ant vs big Mammoths, was RE: [Simple] Using MSRP for Date: Fri, 9 Jul 2004 17:20:50 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-AFFINITYINTERNET-MailScanner-Information: Please contact support on 1300 85 75 65 for more information X-AFFINITYINTERNET-MailScanner: Found to be clean X-MailScanner-From: barry.dingle@bigfoot.com.au Content-Transfer-Encoding: 7bit Cc: Barry Dingle X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.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.3 required=5.0 tests=AWL,MAILTO_TO_SPAM_ADDR autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Mike, As I said at the start of my first message, I am referring to requirements at a "Service level". Maybe I should have said a "User Service level" to be very clear. I am a firm believer in designing services/systems/protocols that are based on User Service requirements as a starting point. We can then use this information to define the performance of individual components of the service (in this case). One does not say this is the transmission characteristics of protocol and then change the User Requirements to suit. One can of course do what you suggest and define some different user requirements based on what IM can achieve - but you are defining a Different Service. OK, it is not radically different but different none the less. The key difference in the User Requirements could be the ability to edit before sending. The term 'Instant Messaging' is very descriptive of the service. It is fast messaging. It is not real time or near real time. Many of us use the term "Text Conversation" to reflect the immediacy and real time, interactive nature of the service that we have been talking about. The ITU-T F.700 requirements are often quoted especially in relation to real time text services. It specifies both a 'useable' service and a 'good' service. Most people have called up the 'useable' figures. The discussions recently are saying that maybe we should be using the 'good' service figures in F.700 - that is, allowable delays from character entry to display of less than 1 second instead of 2 seconds. I am fully in favour of IM as it provides a very useful service. I said that negotiation is very desirable so that users can choose their preference but can fallback to an alternative. This is very much in the philosophy of the IETF. As I also said, negotiation allows for a protocol to be enhanced and maybe become more acceptable for a particular service - if the different versions of the protocol can be identified and included in the negotiation procedure. Now to your specific questions - 1) It is very hard to include 'user intent' in a protocol specification. 'Character entry' and 'character display' are easily identifiable actions and allow performance measurability. 2) Any buffering delay MUST be included in any user delay performance measurement. If the buffering is of short duration, then it could enable that protocol to meet the 'near real time' criterion. 3) If we can negotiate at session startup that IM can send with short delays, then it becomes an option for the real time text service. 4) Delay is only one of the factors that must be considered. Other issues could include the interworking with existing text services. /Barry ================== > Barry, > > I would object to the ENTERED aspect, as that starts into specifying the nature of the service beyond the transmission performance requirements. As > a user, I always want to reserve the right to edit and erase or correct my text before indicating intent to transmit information. If you want to make > it more generic and service independent, you would need to say something like: > > Transmission delay must be less than N ms from when the sender intends for the text data to be sent. "Intent" can be automated or manually indicated. > > Note that the main difference between the RTT and IM modes of texting is that the RTT user has his intent to send automated to do so after every > character, with possibly a buffer batching characters into one message when within 300 ms of each other. In the case of IM, the intent to send is an > explicit indication by hitting the ENTER, SEND, or similar key. A performance metric should not preclude that feature. > > Q: Does the 300ms batching count against the transmission delay in your ENTERED proposal? My suggestion would put that outside the transmission delay. > > It would be possible on IM systems to put a timer on the sending aspect that in the limit would approach the behavior of RTT. However, the > approach of some systems to interleave lines of text of various parties engaged in an IM session into the same window would need to change. > > Mike > > > At 10:49 AM 7/8/2004 +1000, Barry Dingle wrote: > >Mike, > > > >Comments below. > > > >Barry DINGLE > > > >----- Original Message ----- > >From: "Mike Hammer" > >To: "Barry Dingle" > >Sent: Thursday, July 08, 2004 1:04 AM > >Subject: Re: Tiny ant vs big Mammoths, was RE: [Simple] Using MSRP for > >real time text conversation > > > > > > > Does Australia define what is considered "real-time", form a performance measurement perspective? > > > > >Good question. We are keen to base our services (text and other) on international specifications and that is progressively > >happening. Our end-to-end service performance requirements are following a similar approach. That means (at present) that ITU-T > >F.700 is used as a starting point. > > > >(Note that the F.700 T1 2 second delay figure (for useable service) is often quoted but there is growing interest in specifying > >the T2 1 second delay figure (for good service) - along with the lower character corruption rate as well.) > > > > > In other words, if the data arrives within, say one second, of when it was transmitted, be that data one character or one > >sentence, is that fast enough to be real time? > > > > >You use a very specific way to define delay in your statement 'when it was transmitted'. From a user perspective, text > >conversation delay is from when each character is entered to when it is displayed at the remote end. It includes any buffering > >delay. > > > >If I reword your statement to "if the data arrives within, say one second, of when it was ENTERED, be that data one character or > >one sentence, is that fast enough to be real time?" then my answer would be POSSIBLY YES. The proviso is that the 'user feel' is > >different - more bursty. Maybe we need to specify the variability of delay as well as the delay to cover this situation. (To > >start discussion, based on recent discussions, how about a 500 ms delay variation max?) > > > > > The reason I ask is that some folks on these mail lists have claimed that IM is not real time, but I think they are basing > >that conclusion on their experience with SMS, for which there is an observable delay, rather > > than a point-point IM model which is as fast as 2793 once the send key is pressed. > > > > >We should base our discussions on 'agreed user requirements', not names like 'real time' with different meanings to different > >people. But the requirements should not be 'manufactured' to suit a particular service. I said 'real time or near real time' > >because I believe that some' near real time' services can be adequate for text. (Note - speech and video may have different > >requirements!!) > > > > > > > Mike > > > > > > > > > At 12:43 PM 7/7/2004 +1000, you wrote: > > > >Some thoughts on this subject. I approach this from a Service level. > > > > > > > >Real time or near real time text service is essential for some > > legislative environments eg. Australia where 'equivalent' service > > > >to telephony is defined for people who cannot effectively use telephony. > > > > > > > >Use of mainstream protocols is important for the disabled community in > > order that they can communicate with all people not just > > > >amongst people with the same special terminals. > > > > > > > >MSRP provides a very useful mainstream, text communication service. It > > provides a different 'user feel' to a > > > >character-by-character service. Its performance could improve over time. > > > > > > > >text/t140 (RFC2793) is an important near real time text service that > > is consistent with traditional multimedia services and with > > > >the SIP controlled real time multiservice environment. > > > > > > > >Choice is important for users so that we do not get locked into one > > service if a better service becomes available. Therefore > > > >negotiation is essential. > > > > > > > >Both MSRP and rfc2793 work with SIP/SDP so negotiation should not be > > too difficult. > > > > > > > >Cheers, > > > > > > > >Barry DINGLE > > > >Telecommunications Consultant > > > >Project Manager - ACIF Any-to-Any Text Connectivity Options WG > > > >Fellow of the University of Melbourne > > > > barry.dingle@bigfoot.com.au > > > >Mob: +61 (0)41 911 7578 > > > >Fixed: +61 (0)3 9725 3937 > > > >----- Original Message ----- > > > >From: "Gunnar Hellstrom" > > > >To: "Arnoud van Wijk" > > > >Cc: ; ; > > > >Sent: Tuesday, July 06, 2004 4:22 PM > > > >Subject: RE: Tiny ant vs big Mammoths, was RE: [Simple] Using MSRP for > > > >real time text conversation > > > > > > > > > > > > > I opened a new thread under the name > > > > > > > > > > RE: [Simple] Using MSRP for (pseudo?) real time text conversation > > > > > > > > > > For discussing conclusions and negotiation. > > > > > Hope you all will join there. > > > > > > > > > > I agree with Arnoud in the impression that any user you show real time > > > > text conversation > > > > > to, say that it is very good and needed in future services. > > > > > > > > > > So, please look for the new subject line and start thinking about what > > > > inter-relations > > > > > that are needed do declare and negotiate what text service you can and > > > > want to use. And > > > > > answer these messages, so that we get back to one thread. > > > > > > > > > > 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: owner-toip@snowshore.com [mailto:owner-toip@snowshore.com]On > > > > > >Behalf Of Arnoud van Wijk > > > > > >Sent: Sunday, July 04, 2004 11:32 AM > > > > > >To: hisham.khartabil@nokia.com; Henry.Sinnreich@mci.com; > > > > > >dean.willis@softarmor.com > > > > > >Cc: bcampbell@dynamicsoft.com; gunnar.hellstrom@omnitor.se; > > > > > >adam@dynamicsoft.com; stf267@etsi.org; simple@ietf.org; > > > > > >toip@snowshore.com > > > > > >Subject: RE: Tiny ant vs big Mammoths, was RE: [Simple] Using MSRP for > > > > > >real time text conversation > > > > > > > > > > > > > > > > > >Hisham, > > > > > >Actually... > > > > > >I did some market research. Based on 15 people. > > > > > >3 deaf, 5 worked in deaf related business (hearing people) > > > > > >And 7 don't care about deaf (2 of them are IM freaks). > > > > > > > > > > > >Result: > > > > > > > > > > > >First telling them about total conversation and Interactive text > > > > > >(text/t140). > > > > > >It did not mean much to them, they looked glassy eyed. Real-time > > charcter > > > > > >per character..oh Yawn... lovely... pish posh. They could not imagine > > > > it. No > > > > > >concept of it. > > > > > > > > > > > >Then I showed them. > > > > > >They could communicate with somebody in Sweden, and with me on a > > > > different terminal in a different room. > > > > > >All were deeply impressed. > > > > > > > > > > > >The 3 deaf wanted to take it home right now. Being able to communicate > > > > everywhere , everytime..finally free! > > > > > >The 5 who worked in the deaf business, they loved it and want to see > > > > it implemted and mainstream. They love it and will use > > > >it regularly to > > > > > >communicate with deaf and some even say that it can be quite > > > > convenient for hearing people as well. > > > > > > > > > > > >The 7 hearing, non deaf related liked it too! > > > > > >They said, wow... this is much more direct then IM, you can actually > > > > call people in situations where voice is a bit not done > > > >(think cinema, concert, > > > > > >restaurant, train). They see it as direct real-time IM. > > > > > >They will keep using IM anyway. But see uses for text/t140 too and > > > > will use it if it is convenient. > > > > > >The 2 IM freaks agreed, though they prefer IM, but if somebdoy > > > > contacts them via interactive text text/t140, they will use it > > > >too. > > > > > >"It depends who to contact to use the right text communication method. > > > > I like the choice to have an alternative". > > > > > > > > > > > >So. Yes.. I know people will like it. Not everybody will use > > > > interactive text. Some will thus only use if somebody else uses > > > >it, whether a deaf > > > > > >person or one who likes to use text/t140. > > > > > > > > > > > >All of them hope that interactive text will be mainstream and will use > > > > it with varying degrees, from sometimes, to daily. > > > > > > > > > > > >So, this is my message, from an interactive text user AND having > > > > showed/demonstrated interactive text to other people. It is > > > >not my desire > > > > > >only. > > > > > > > > > > > >Greetz > > > > > > > > > > > >Arnoud > > > > > > > > > > > >-----Original Message----- > > > > > >From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > > > > > >Sent: vrijdag 2 juli 2004 9:19 > > > > > >To: a.vwijk@viataal.nl; Henry.Sinnreich@mci.com; > > dean.willis@softarmor.com > > > > > >Cc: bcampbell@dynamicsoft.com; gunnar.hellstrom@omnitor.se; > > > > > >adam@dynamicsoft.com; stf267@etsi.org; simple@ietf.org; > > toip@snowshore.com > > > > > >Subject: RE: Tiny ant vs big Mammoths, was RE: [Simple] Using MSRP for > > > > real > > > > > >time text conversation > > > > > > > > > > > >Arnoud, > > > > > > > > > > > >You speak as if you have done the market research already for all > > of us :) > > > > > >How do you know that people will appreciate it once they discover it? > > > > How do > > > > > >you know that people will use it? How do you know that it adds value > > > > to the > > > > > >phone instead of just implementing something that no one will use? > > How do > > > > > >you know that if I like interactive text, then my mum and dad will and > > > > buy a > > > > > >phone like mine just to use interactive text???? How do you know...? > > > > > > > > > > > >Did people complain to you that IM the way it is these days in > > annoying to > > > > > >use? or are you just stating your opinion? > > > > > > > > > > > >And about mobile phones. If you can type an SMS faster than 2 > > characters a > > > > > >second, you're a genius. Even if you can, I don't believe > > operators would > > > > > >want to floor they scarce air interface with IP packets that carry 2 > > > > > >characters at a time. > > > > > > > > > > > >Thanks, > > > > > >Hisham > > > > > > > > > > > > > > > > > >- > > > > > >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 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 > > > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jul 9 05:31: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 FAA13481 for ; Fri, 9 Jul 2004 05:31: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 1Biriu-0002Md-Fi for simple-archive@ietf.org; Fri, 09 Jul 2004 05:31:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Birhy-00024w-00 for simple-archive@ietf.org; Fri, 09 Jul 2004 05:30:18 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Birh8-0001VF-00; Fri, 09 Jul 2004 05:29:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BirME-00046w-TC; Fri, 09 Jul 2004 05:07:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BiqxW-0000FY-Np for simple@megatron.ietf.org; Fri, 09 Jul 2004 04:42: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 EAA11601 for ; Fri, 9 Jul 2004 04:42: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 1BiqxP-00033a-Ek for simple@ietf.org; Fri, 09 Jul 2004 04:42:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BiqwU-0002kN-00 for simple@ietf.org; Fri, 09 Jul 2004 04:41:15 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1Biqve-0002Ae-00 for simple@ietf.org; Fri, 09 Jul 2004 04:40:22 -0400 Received: from dynamicsoft.com ([63.113.46.54]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i698e1bo008126; Fri, 9 Jul 2004 04:40:01 -0400 (EDT) Message-ID: <40EE59CE.9090101@dynamicsoft.com> Date: Fri, 09 Jul 2004 04:39: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: Orit Levin Subject: Re: [Simple] Friendly Display Name in Presence Schema? 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, 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 I think this would be fine. -Jonathan R. Orit Levin wrote: > The protocol difference or flexibility is in who generates the display > name. In some systems, the watcher sets the display name, indeed. In > others, it is being set by presentities' aggregation point per user. > Still in others, it is the presentity instance itself. Of cause, it is > always the policy of the watcher which one(s) to display to the user. > > There are obvious application usages for each of the approaches. > > Would somebody object for adding "presentity-display-name" as one of the > optional elements to the CIPID XML schema? Along the same lines as > "card", "icon", etc. (both for the whole presence document and for an > individual tuple) ? > > Thanks, > Orit. > > >>-----Original Message----- >>From: simple-bounces@ietf.org >>[mailto:simple-bounces@ietf.org] On Behalf Of Jonathan Rosenberg >>Sent: Wednesday, July 07, 2004 6:13 PM >>To: Orit Levin >>Cc: simple@ietf.org >>Subject: Re: [Simple] Friendly Display Name in Presence Schema? >> >>I dont think so, no. >> >>I would think that, in most cases, the display name would be >>set by the watcher, and present in their resource list. The >>resource list XML does have a display name. >> >>-Jonathan R. >> >>Orit Levin wrote: >> >> >>>Guys, >>>Do we have a friendly display name defined per user in one of our >>>presence XML schemas (in addition to the entity URI) ? >>> >>>Thanks, >>>Orit. >>> >>> >>> >> >>---------------------------------------------------------------------- >> >>>-- >>> >>>_______________________________________________ >>>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 >> > > -- 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 Jul 9 06:06: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 GAA14832 for ; Fri, 9 Jul 2004 06:06: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 1BisGv-00058E-LC for simple-archive@ietf.org; Fri, 09 Jul 2004 06:06:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BisG0-0004pt-00 for simple-archive@ietf.org; Fri, 09 Jul 2004 06:05:29 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BisFb-0004XB-00; Fri, 09 Jul 2004 06:05:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BirpX-0000ab-9k; Fri, 09 Jul 2004 05: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 1BirZU-0006EI-Be for simple@megatron.ietf.org; Fri, 09 Jul 2004 05:21: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 FAA13210 for ; Fri, 9 Jul 2004 05: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 1BirZN-0007Bl-1q for simple@ietf.org; Fri, 09 Jul 2004 05:21:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BirYV-0006sJ-00 for simple@ietf.org; Fri, 09 Jul 2004 05:20:32 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BirXZ-0006De-00 for simple@ietf.org; Fri, 09 Jul 2004 05:19:33 -0400 Received: from dynamicsoft.com ([63.113.46.54]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i699JKbo008212; Fri, 9 Jul 2004 05:19:22 -0400 (EDT) Message-ID: <40EE6304.8030206@dynamicsoft.com> Date: Fri, 09 Jul 2004 05:19: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: "Joel M. Halpern" Subject: Re: [Simple] Large response ? References: <5.1.0.14.0.20040707103647.023de8c8@localhost> <5.1.0.14.0.20040707080624.023eb198@localhost> <5.1.0.14.0.20040706111036.023f5320@localhost> <40EA0018.3080408@dynamicsoft.com> <40E5C2E1.50502@dynamicsoft.com> <40E903D2.2050703@nokia.com> <40EA0018.3080408@dynamicsoft.com> <5.1.0.14.0.20040706111036.023f5320@localhost> <5.1.0.14.0.20040707080624.023eb198@localhost> <5.1.0.14.0.20040707103647.023de8c8@localhost> <5.1.0.14.0.20040708083645.023da180@localhost> In-Reply-To: <5.1.0.14.0.20040708083645.023da180@localhost> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: Miguel Garcia , 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. Joel M. Halpern wrote: > I am sorry. I can not understand the case where the client can not > repair the partial answer, but somehow can get a meaningful answer when > it is provided as complete XML elements. (I presume the example you > gave was over-simpilifed, but in the example, there is no anser that > will fit.) > > a) If the server sends as much as fits in the "buffer", the client can > always parse forward, trim backwards, add closing elements as needed, > and end up with more content than would have been shipped if the server > had shipped only the elements that it somehow knew would fit. This still might not yield a schema compliant document though. > b) given that the length of the content of the elements is not known, I > do not understand in what terms an element count limit will help a > client cope with a resource limitation. I think that there are really *two* resources that are limited. One resource is the memory buffer, which has an absolute maximum. The HTTP Range headers are ideal for making sure that you never pull more than fits in here. Presumably, this limit is never reached except only in very unusual error cases, and then if it happens you'd display an error to the user. I get this in my cell phone sometimes when viewing websites that are too large. Another resource is the air interface. Since the screen real estate is small, the phone is only capable of rendering a few lines of a buddy list to a user at a time (say, 10). So, rather than fetching the whole thing, the phone just gets the bits that it is rendering. That is called "pagination". The size of each page would be determined by UI constraints, and is measured in terms of units of "buddies" or "lists" (in the hierarchical case). In pretty much all cases, I would guess that the size of the data in a single "page" of rendered data is way, way, way less than the memory capacity of the phone. These two resource constraints are only loosely coupled; its loosely coupled in the sense that, if you werent using pagination, and you tried to get the whole document, you might hit the memory limit. Pagination, as a result, has the benefit of reducing the amount of memory needed at any time, and thus makes it far less likely that you would ever hit the memory constraint. If, for some reason, you hit this memory constraint even while paginating, you would probably report this as an error to the user, through away the content you received, possibly reduce the pagination count, and try again. I dont think you want to mix the usage of the Range headers with the pagination, in that, you would never use the Range headers as a way to get parts of the document a bit at a time. -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 Jul 9 06:32: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 GAA16048 for ; Fri, 9 Jul 2004 06:32: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 1Bisg0-0005FT-7e for simple-archive@ietf.org; Fri, 09 Jul 2004 06:32:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bisf6-0004wD-00 for simple-archive@ietf.org; Fri, 09 Jul 2004 06:31:25 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BiseW-0004ab-00; Fri, 09 Jul 2004 06:30:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BisDx-0004ce-Nt; Fri, 09 Jul 2004 06:03:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Birpn-0000dP-TY for simple@megatron.ietf.org; Fri, 09 Jul 2004 05:38: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 FAA13703 for ; Fri, 9 Jul 2004 05:38: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 1Birpg-0004Rd-IK for simple@ietf.org; Fri, 09 Jul 2004 05:38:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Biroh-00049F-00 for simple@ietf.org; Fri, 09 Jul 2004 05:37:16 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1Birnk-0003q1-00 for simple@ietf.org; Fri, 09 Jul 2004 05:36:17 -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 i699aEb23874; Fri, 9 Jul 2004 12:36:14 +0300 (EET DST) X-Scanned: Fri, 9 Jul 2004 12:36:07 +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 i699a7nl011900; Fri, 9 Jul 2004 12:36:07 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00dv4PQb; Fri, 09 Jul 2004 12:36:05 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 i699a4n12536; Fri, 9 Jul 2004 12:36:04 +0300 (EET DST) Received: from nokia.com ([172.21.42.108]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 9 Jul 2004 12:35:46 +0300 Message-ID: <40EE66F2.6020008@nokia.com> Date: Fri, 09 Jul 2004 12:35:46 +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: "Joel M. Halpern" Subject: Re: [Simple] Large response ? References: <5.1.0.14.0.20040707103647.023de8c8@localhost> <5.1.0.14.0.20040707080624.023eb198@localhost> <5.1.0.14.0.20040706111036.023f5320@localhost> <40EA0018.3080408@dynamicsoft.com> <40E5C2E1.50502@dynamicsoft.com> <40E903D2.2050703@nokia.com> <40EA0018.3080408@dynamicsoft.com> <5.1.0.14.0.20040706111036.023f5320@localhost> <5.1.0.14.0.20040707080624.023eb198@localhost> <5.1.0.14.0.20040707103647.023de8c8@localhost> <5.1.0.14.0.20040708083645.023da180@localhost> In-Reply-To: <5.1.0.14.0.20040708083645.023da180@localhost> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Jul 2004 09:35:46.0787 (UTC) FILETIME=[1CEBDB30:01C46598] 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 Joel: I will try to explain once more... Inline. Joel M. Halpern wrote: > I am sorry. I can not understand the case where the client can not > repair the partial answer, but somehow can get a meaningful answer when > it is provided as complete XML elements. (I presume the example you > gave was over-simpilifed, but in the example, there is no anser that > will fit.) > > a) If the server sends as much as fits in the "buffer", the client can > always parse forward, trim backwards, add closing elements as needed, > and end up with more content than would have been shipped if the server > had shipped only the elements that it somehow knew would fit. No, I disagree. The client has to check that the document is well-formed and valid according to the schema. If the server truncates the document, because it reaches the byte count, then the document is not well formed and is not valid according to the schema. > b) given that the length of the content of the elements is not known, I > do not understand in what terms an element count limit will help a > client cope with a resource limitation. As I said, the resource limitation is not exclusively related to memory, but also to display capabilities, etc. So the client can estimate the amount of needed memory per element (something big if you want) and the amount of entries it can safely display with a limited buffering. I believe there is not safe equation indicating the number of bytes and entries the client can accept, but some limit in which the client is safe to operate. > c) The requirement as you state it seems to edge in to the solution. I > understand that the client software wants to request part of a > document. I understand that to present this to the user the client > software will need a well-formed XML document. I do not understand why > it follows that the partial document that is delivered must be > well-formed, since the client can work it over any way it chooses. From > the last sentence, you seem to be driving towards a specific > implementation. At least I am not trying to drive towards a specific implementation. But I think you are wrgon with the well-formed XML document. We are using XML because implementations can check whether the document is well-formed or not, and whether the document is valid according to the schema. Still with paginated documents I believe this requirement is in place. So the document MUST be well-formed and MUST be valid; the client has to check it. > d) When we starting putting on constraint about which portions of a > document can be requested using this mechanism, and what "schema > compliance" is supposed to mean about the answer we are crafting a very > specialized solution, rather than tackling a general problem. And that > will make it difficult to build compliant XCAP servers that can cope > easily with multiple schemas and schema changes. > I don't quite understand. The whole thing about XCAP is to be able to manipulate portions of documents, still being compliant with the schema. I don't think that "requesting a portion of a document still being compliant with the schema" diverges that much from what XCAP is orinally meant to do. I don't think the mechanism is so specific, it should have been in place in the first place... but since it isn't, let's work together to make it fit smoothly. > Yours, > Joel M. Halpern Regards, Miguel > > > In a separate message Miguel Garcia wrote: > Right. So let's try to formulate the requirement. We are looking for a > mechanism that allows an XCAP client to request fractions of an XML > document, so that the returned document is valid but need not include > all the repeatable entries. This allows the XCAP client to operate on > the XML document (render and manipulate it), release the memory, request > the next fraction of the same XML document, and start the process again. > > > At 09:37 AM 7/8/2004 +0300, Miguel Garcia wrote: > >> Joel: >> >> Let me try to give you a concrete example where you can see that the >> byte range does not server for the purpose: >> >> Imagine I want to request this very simple XML document >> >> >> This is an element >> >> >> Now, when I request this document, I request a byte range (say, 0 to x >> bytes). The server apply the count on the byte range, and cut the >> document. It returns me the following document: >> >> >> This is a >> >> So my XCAP client will not consider the document even well-formed, not >> even valid. So what can my XCAP client do with this document? I have >> two options: >> >> a) request the remaining of the document. But since I applied a byte >> range, presumably because my XCAP client does not have more available >> memory to request a longer document (otherwise, why did I request a >> byte range in the first place), I cannot store this partial document >> and request the remaining parts (I don't have memory to store the >> remaining parts). So this does not solve the problem. >> >> b) dispose the document in the garbage bin (a.k.a. release the >> memory), and request the complete document. But again we are in the >> same situation as in a), the terminal requested a byte range in the >> first place, so what for if it has to request the remaining document? >> >> Is there any other solution you can envision? I don't, and therefore >> my conclusion is that byte ranges does not serve for the purpose. >> >> Regards, >> >> Miguel >> >> Joel M. Halpern wrote: >> >>> There appears to be some (reasonable) desire to get part of an XML >>> Configuration, where "part" means not a just selection of identified >>> elements but some other subseting. >>> This appears to be driven by some combination of client memory and >>> user presentation resources. >>> Rather than trying to argue that some solution meets the needs, I >>> would like to see a clear and reasonably complete list of >>> requirements. I can believe that there is some requirement that is >>> not met by byte-range for example, but I do not know what it is. >>> Yours, >>> Joel M. Halpern >>> >>> _______________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> https://www1.ietf.org/mailman/listinfo/simple >> >> >> -- >> 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 > > -- 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 Fri Jul 9 06:32: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 GAA16069 for ; Fri, 9 Jul 2004 06:32: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 1Bisg1-0005Fe-Hs for simple-archive@ietf.org; Fri, 09 Jul 2004 06:32:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BisfA-0004wg-00 for simple-archive@ietf.org; Fri, 09 Jul 2004 06:31:28 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BiseZ-0004at-00; Fri, 09 Jul 2004 06: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 1BisFE-0004rA-3C; Fri, 09 Jul 2004 06:04:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Birsj-00012v-Pz for simple@megatron.ietf.org; Fri, 09 Jul 2004 05:41: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 FAA13826 for ; Fri, 9 Jul 2004 05: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 1Birsc-0005Mo-DY for simple@ietf.org; Fri, 09 Jul 2004 05:41:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Birrf-00053m-00 for simple@ietf.org; Fri, 09 Jul 2004 05:40:20 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1Birql-0004lL-00 for simple@ietf.org; Fri, 09 Jul 2004 05:39:23 -0400 Received: from razor.cs.columbia.edu (IDENT:Z0jUROwPbGj+OWOhsFFggEw071fxmXdF@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i699dJfq009515 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Fri, 9 Jul 2004 05:39:19 -0400 (EDT) Received: from [127.0.0.1] (IDENT:MmugpS8zB1WStLRl2fQo0ruyLTF2CmjN@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i699dIjd007470; Fri, 9 Jul 2004 05:39:18 -0400 Message-ID: <40EE67C6.50309@cs.columbia.edu> Date: Fri, 09 Jul 2004 05:39:18 -0400 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 0.7.1 (Windows/20040626) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Simple] Friendly Display Name in Presence Schema? References: <40EE59CE.9090101@dynamicsoft.com> In-Reply-To: <40EE59CE.9090101@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.7.8.106480 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: Orit Levin , 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 The vcard already contains name information, but I'll add as an additional element for simplicity since I suspect that the two may differ on occasion. Jonathan Rosenberg wrote: > I think this would be fine. > > -Jonathan R. > > Orit Levin wrote: > >> The protocol difference or flexibility is in who generates the display >> name. In some systems, the watcher sets the display name, indeed. In >> others, it is being set by presentities' aggregation point per user. >> Still in others, it is the presentity instance itself. Of cause, it is >> always the policy of the watcher which one(s) to display to the user. >> >> There are obvious application usages for each of the approaches. >> Would somebody object for adding "presentity-display-name" as one of the >> optional elements to the CIPID XML schema? Along the same lines as >> "card", "icon", etc. (both for the whole presence document and for an >> individual tuple) ? _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jul 9 10:54: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 KAA03818 for ; Fri, 9 Jul 2004 10: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 1Biwln-0000BT-00 for simple-archive@ietf.org; Fri, 09 Jul 2004 10:54:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Biwks-0007fD-00 for simple-archive@ietf.org; Fri, 09 Jul 2004 10:53:39 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BiwkI-0007LD-00; Fri, 09 Jul 2004 10:53:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BiwAm-00053l-Tu; Fri, 09 Jul 2004 10:16:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bivti-00054b-P9 for simple@megatron.ietf.org; Fri, 09 Jul 2004 09:58: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 JAA27730 for ; Fri, 9 Jul 2004 09:58: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 1BivtT-0005xJ-4f for simple@ietf.org; Fri, 09 Jul 2004 09:58:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BivsS-0005ef-00 for simple@ietf.org; Fri, 09 Jul 2004 09:57:25 -0400 Received: from ns.execdsl.net ([208.184.15.238] helo=EXECDSL.COM) by ietf-mx with esmtp (Exim 4.12) id 1BivrN-00054f-00 for simple@ietf.org; Fri, 09 Jul 2004 09:56:17 -0400 Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 7190915; Fri, 09 Jul 2004 09:56:04 -0400 Message-Id: <5.1.0.14.0.20040709094644.02311cd0@localhost> X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 09 Jul 2004 09:55:48 -0400 To: Miguel Garcia From: "Joel M. Halpern" Subject: Re: [Simple] Large response ? In-Reply-To: <40EE66F2.6020008@nokia.com> References: <5.1.0.14.0.20040708083645.023da180@localhost> <5.1.0.14.0.20040707103647.023de8c8@localhost> <5.1.0.14.0.20040707080624.023eb198@localhost> <5.1.0.14.0.20040706111036.023f5320@localhost> <40EA0018.3080408@dynamicsoft.com> <40E5C2E1.50502@dynamicsoft.com> <40E903D2.2050703@nokia.com> <40EA0018.3080408@dynamicsoft.com> <5.1.0.14.0.20040706111036.023f5320@localhost> <5.1.0.14.0.20040707080624.023eb198@localhost> <5.1.0.14.0.20040707103647.023de8c8@localhost> <5.1.0.14.0.20040708083645.023da180@localhost> Mime-Version: 1.0 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 Let me try and restate this, with caveats along the way: 1) One goal is to be able to asked for a specific number of XML elements, starting at a specific point in the document, and get a well-formed document fragment. 1a) As we have discussed, this can only be done at certain points in a schema. At many points in a schema, this request is either impossible to meet, or produces nonsense results, for example when there are more mandatory elements than the requested count, or when there are mandatory elements later in the set than the requested number of optional elements, or... 2) A related goal is to be able to retrieve information that will fit on the screen. The idea is not to waste air bandwidth (a scarce resource) shipping things that can not be displayed. 2a) For any schema element with string or token content, or URI content or URI attributes, or ... even if the element is a leaf, the actual amount of display resources needed to display a single element is not a constant. As such, requesting 10 elements does not correlate with what fits on the screen. Hence, I am left to conclude that what is being requested is a very special case mechanism that can be effectively used only in limited circumstances. Supporting it on the server will require significant intelligence. Using it on the client will require knowledge about the length of content that typically does not exist. If I have understood the requirements you are aiming at, I am left to conclude that this is not something that belongs in XCAP. It may be possible to restrict the scope in the definition. For example, if the scope were only a single repeating XML element which must be a leaf, then at least the valid construction problem goes away. It still would not have any relationship to display size. And it would require extending the pattern syntax very heavily. Yours, Joel M. Halpern At 12:35 PM 7/9/2004 +0300, Miguel Garcia wrote: >Hi Joel: > >I will try to explain once more... Inline. > >Joel M. Halpern wrote: >>I am sorry. I can not understand the case where the client can not >>repair the partial answer, but somehow can get a meaningful answer when >>it is provided as complete XML elements. (I presume the example you gave >>was over-simpilifed, but in the example, there is no anser that will fit.) >>a) If the server sends as much as fits in the "buffer", the client can >>always parse forward, trim backwards, add closing elements as needed, and >>end up with more content than would have been shipped if the server had >>shipped only the elements that it somehow knew would fit. > >No, I disagree. The client has to check that the document is well-formed >and valid according to the schema. If the server truncates the document, >because it reaches the byte count, then the document is not well formed >and is not valid according to the schema. > > >>b) given that the length of the content of the elements is not known, I >>do not understand in what terms an element count limit will help a client >>cope with a resource limitation. > >As I said, the resource limitation is not exclusively related to memory, >but also to display capabilities, etc. So the client can estimate the >amount of needed memory per element (something big if you want) and the >amount of entries it can safely display with a limited buffering. I >believe there is not safe equation indicating the number of bytes and >entries the client can accept, but some limit in which the client is safe >to operate. > >>c) The requirement as you state it seems to edge in to the solution. I >>understand that the client software wants to request part of a >>document. I understand that to present this to the user the client >>software will need a well-formed XML document. I do not understand why >>it follows that the partial document that is delivered must be >>well-formed, since the client can work it over any way it chooses. From >>the last sentence, you seem to be driving towards a specific implementation. > >At least I am not trying to drive towards a specific implementation. >But I think you are wrgon with the well-formed XML document. We are using >XML because implementations can check whether the document is well-formed >or not, and whether the document is valid according to the schema. Still >with paginated documents I believe this requirement is in place. So the >document MUST be well-formed and MUST be valid; the client has to check it. > >>d) When we starting putting on constraint about which portions of a >>document can be requested using this mechanism, and what "schema >>compliance" is supposed to mean about the answer we are crafting a very >>specialized solution, rather than tackling a general problem. And that >>will make it difficult to build compliant XCAP servers that can cope >>easily with multiple schemas and schema changes. > > > >I don't quite understand. The whole thing about XCAP is to be able to >manipulate portions of documents, still being compliant with the schema. I >don't think that "requesting a portion of a document still being compliant >with the schema" diverges that much from what XCAP is orinally meant to >do. I don't think the mechanism is so specific, it should have been in >place in the first place... but since it isn't, let's work together to >make it fit smoothly. > >>Yours, >>Joel M. Halpern > >Regards, > > Miguel > >> >>In a separate message Miguel Garcia wrote: >>Right. So let's try to formulate the requirement. We are looking for a >>mechanism that allows an XCAP client to request fractions of an XML >>document, so that the returned document is valid but need not include all >>the repeatable entries. This allows the XCAP client to operate on the XML >>document (render and manipulate it), release the memory, request the next >>fraction of the same XML document, and start the process again. >> >>At 09:37 AM 7/8/2004 +0300, Miguel Garcia wrote: >> >>>Joel: >>> >>>Let me try to give you a concrete example where you can see that the >>>byte range does not server for the purpose: >>> >>>Imagine I want to request this very simple XML document >>> >>> >>> This is an element >>> >>> >>>Now, when I request this document, I request a byte range (say, 0 to x >>>bytes). The server apply the count on the byte range, and cut the >>>document. It returns me the following document: >>> >>> >>> This is a >>> >>>So my XCAP client will not consider the document even well-formed, not >>>even valid. So what can my XCAP client do with this document? I have two >>>options: >>> >>>a) request the remaining of the document. But since I applied a byte >>>range, presumably because my XCAP client does not have more available >>>memory to request a longer document (otherwise, why did I request a byte >>>range in the first place), I cannot store this partial document and >>>request the remaining parts (I don't have memory to store the remaining >>>parts). So this does not solve the problem. >>> >>>b) dispose the document in the garbage bin (a.k.a. release the memory), >>>and request the complete document. But again we are in the same >>>situation as in a), the terminal requested a byte range in the first >>>place, so what for if it has to request the remaining document? >>> >>>Is there any other solution you can envision? I don't, and therefore my >>>conclusion is that byte ranges does not serve for the purpose. >>> >>>Regards, >>> >>> Miguel >>> >>>Joel M. Halpern wrote: >>> >>>>There appears to be some (reasonable) desire to get part of an XML >>>>Configuration, where "part" means not a just selection of identified >>>>elements but some other subseting. >>>>This appears to be driven by some combination of client memory and user >>>>presentation resources. >>>>Rather than trying to argue that some solution meets the needs, I would >>>>like to see a clear and reasonably complete list of requirements. I >>>>can believe that there is some requirement that is not met by >>>>byte-range for example, but I do not know what it is. >>>>Yours, >>>>Joel M. Halpern >>>> >>>>_______________________________________________ >>>>Simple mailing list >>>>Simple@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/simple >>> >>> >>>-- >>>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 > >-- >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 Fri Jul 9 11:44: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 LAA06288 for ; Fri, 9 Jul 2004 11:44: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 1BixY7-0000do-Ep for simple-archive@ietf.org; Fri, 09 Jul 2004 11:44:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BixX7-0000Hi-00 for simple-archive@ietf.org; Fri, 09 Jul 2004 11:43:30 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BixW3-0007TK-00; Fri, 09 Jul 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 1Bix5w-0004Tn-2k; Fri, 09 Jul 2004 11:15:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Biwit-0000F8-9X for simple@megatron.ietf.org; Fri, 09 Jul 2004 10:51: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 KAA03690 for ; Fri, 9 Jul 2004 10:51: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 1Biwin-00071K-Dr for simple@ietf.org; Fri, 09 Jul 2004 10:51:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Biwhq-0006hM-00 for simple@ietf.org; Fri, 09 Jul 2004 10:50:32 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx with esmtp (Exim 4.12) id 1Biwh0-00065V-00 for simple@ietf.org; Fri, 09 Jul 2004 10:49:38 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 09 Jul 2004 10:49:19 -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 i69En3N9017890; Fri, 9 Jul 2004 10:49:03 -0400 (EDT) Received: from mhammer-w2k03.cisco.com (dhcp-hrn-64-100-229-208.cisco.com [64.100.229.208]) by fruitpie.cisco.com (MOS 3.4.6-GR) with ESMTP id BAM07137; Fri, 9 Jul 2004 07:49:03 -0700 (PDT) Message-Id: <4.3.2.7.2.20040709104443.00b19668@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 09 Jul 2004 10:50:07 -0400 To: "Barry Dingle" , , , From: Mike Hammer Subject: Re: Tiny ant vs big Mammoths, was RE: [Simple] Using MSRP for In-Reply-To: <089601c46585$46093200$b631c2cb@Home> References: <4.3.2.7.2.20040707110031.00b17d00@cia.cisco.com> <4.3.2.7.2.20040708112121.00b17868@cia.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Barry Dingle X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org 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 Barry, Agree that these are different user services, given that one allows editing before transmission, while the other edits post-transmission. I think you are also agreeing that if the "Instant" in IM meets fast delay requirements (e.g. the 1-2 seconds) then it could also be classified as "real-time". But to keep a distinction, it would be real-time messaging versus real time text. Mike At 05:20 PM 7/9/2004 +1000, Barry Dingle wrote: >Mike, > >As I said at the start of my first message, I am referring to requirements >at a "Service level". Maybe I should have said a >"User Service level" to be very clear. > >I am a firm believer in designing services/systems/protocols that are >based on User Service requirements as a starting point. We >can then use this information to define the performance of individual >components of the service (in this case). One does not say >this is the transmission characteristics of protocol and then change the >User Requirements to suit. > >One can of course do what you suggest and define some different user >requirements based on what IM can achieve - but you are >defining a Different Service. OK, it is not radically different but >different none the less. The key difference in the User >Requirements could be the ability to edit before sending. > >The term 'Instant Messaging' is very descriptive of the service. It is >fast messaging. It is not real time or near real time. > >Many of us use the term "Text Conversation" to reflect the immediacy and >real time, interactive nature of the service that we >have been talking about. > >The ITU-T F.700 requirements are often quoted especially in relation to >real time text services. It specifies both a 'useable' >service and a 'good' service. Most people have called up the 'useable' >figures. The discussions recently are saying that maybe >we should be using the 'good' service figures in F.700 - that is, >allowable delays from character entry to display of less than >1 second instead of 2 seconds. > >I am fully in favour of IM as it provides a very useful service. I said >that negotiation is very desirable so that users can >choose their preference but can fallback to an alternative. This is very >much in the philosophy of the IETF. > >As I also said, negotiation allows for a protocol to be enhanced and maybe >become more acceptable for a particular service - if >the different versions of the protocol can be identified and included in >the negotiation procedure. > > Now to your specific questions - > >1) It is very hard to include 'user intent' in a protocol specification. >'Character entry' and 'character display' are easily >identifiable actions and allow performance measurability. > >2) Any buffering delay MUST be included in any user delay performance >measurement. If the buffering is of short duration, then >it could enable that protocol to meet the 'near real time' criterion. > >3) If we can negotiate at session startup that IM can send with short >delays, then it becomes an option for the real time text >service. > >4) Delay is only one of the factors that must be considered. Other issues >could include the interworking with existing text >services. > >/Barry >================== > > Barry, > > > > I would object to the ENTERED aspect, as that starts into specifying > the nature of the service beyond the transmission >performance requirements. As > > a user, I always want to reserve the right to edit and erase or correct > my text before indicating intent to transmit >information. If you want to make > > it more generic and service independent, you would need to say > something like: > > > > Transmission delay must be less than N ms from when the sender intends > for the text data to be sent. "Intent" can be >automated or manually indicated. > > > > Note that the main difference between the RTT and IM modes of texting > is that the RTT user has his intent to send automated to >do so after every > > character, with possibly a buffer batching characters into one message > when within 300 ms of each other. In the case of IM, >the intent to send is an > > explicit indication by hitting the ENTER, SEND, or similar key. A > performance metric should not preclude that feature. > > > > Q: Does the 300ms batching count against the transmission delay in > your ENTERED proposal? My suggestion would put that >outside the transmission delay. > > > > It would be possible on IM systems to put a timer on the sending aspect > that in the limit would approach the behavior of RTT. >However, the > > approach of some systems to interleave lines of text of various parties > engaged in an IM session into the same window would >need to change. > > > > Mike > > > > > > At 10:49 AM 7/8/2004 +1000, Barry Dingle wrote: > > >Mike, > > > > > >Comments below. > > > > > >Barry DINGLE > > > > > >----- Original Message ----- > > >From: "Mike Hammer" > > >To: "Barry Dingle" > > >Sent: Thursday, July 08, 2004 1:04 AM > > >Subject: Re: Tiny ant vs big Mammoths, was RE: [Simple] Using MSRP for > > >real time text conversation > > > > > > > > > > Does Australia define what is considered "real-time", form a > performance measurement perspective? > > > > > > >Good question. We are keen to base our services (text and other) on > international specifications and that is progressively > > >happening. Our end-to-end service performance requirements are > following a similar approach. That means (at present) that >ITU-T > > >F.700 is used as a starting point. > > > > > >(Note that the F.700 T1 2 second delay figure (for useable service) is > often quoted but there is growing interest in >specifying > > >the T2 1 second delay figure (for good service) - along with the lower > character corruption rate as well.) > > > > > > > In other words, if the data arrives within, say one second, of when > it was transmitted, be that data one character or one > > >sentence, is that fast enough to be real time? > > > > > > >You use a very specific way to define delay in your statement 'when it > was transmitted'. From a user perspective, text > > >conversation delay is from when each character is entered to when it > is displayed at the remote end. It includes any >buffering > > >delay. > > > > > >If I reword your statement to "if the data arrives within, say one > second, of when it was ENTERED, be that data one character >or > > >one sentence, is that fast enough to be real time?" then my answer > would be POSSIBLY YES. The proviso is that the 'user feel' >is > > >different - more bursty. Maybe we need to specify the variability of > delay as well as the delay to cover this situation. (To > > >start discussion, based on recent discussions, how about a 500 ms > delay variation max?) > > > > > > > The reason I ask is that some folks on these mail lists have > claimed that IM is not real time, but I think they are basing > > >that conclusion on their experience with SMS, for which there is an > observable delay, rather > > > than a point-point IM model which is as fast as 2793 once the send > key is pressed. > > > > > > >We should base our discussions on 'agreed user requirements', not > names like 'real time' with different meanings to different > > >people. But the requirements should not be 'manufactured' to suit a > particular service. I said 'real time or near real time' > > >because I believe that some' near real time' services can be adequate > for text. (Note - speech and video may have different > > >requirements!!) > > > > > > > > > > Mike > > > > > > > > > > > > At 12:43 PM 7/7/2004 +1000, you wrote: > > > > >Some thoughts on this subject. I approach this from a Service level. > > > > > > > > > >Real time or near real time text service is essential for some > > > legislative environments eg. Australia where 'equivalent' service > > > > >to telephony is defined for people who cannot effectively use > telephony. > > > > > > > > > >Use of mainstream protocols is important for the disabled community in > > > order that they can communicate with all people not just > > > > >amongst people with the same special terminals. > > > > > > > > > >MSRP provides a very useful mainstream, text communication service. It > > > provides a different 'user feel' to a > > > > >character-by-character service. Its performance could improve over > time. > > > > > > > > > >text/t140 (RFC2793) is an important near real time text service that > > > is consistent with traditional multimedia services and with > > > > >the SIP controlled real time multiservice environment. > > > > > > > > > >Choice is important for users so that we do not get locked into one > > > service if a better service becomes available. Therefore > > > > >negotiation is essential. > > > > > > > > > >Both MSRP and rfc2793 work with SIP/SDP so negotiation should not be > > > too difficult. > > > > > > > > > >Cheers, > > > > > > > > > >Barry DINGLE > > > > >Telecommunications Consultant > > > > >Project Manager - ACIF Any-to-Any Text Connectivity Options WG > > > > >Fellow of the University of Melbourne > > > > > barry.dingle@bigfoot.com.au > > > > >Mob: +61 (0)41 911 7578 > > > > >Fixed: +61 (0)3 9725 3937 > > > > >----- Original Message ----- > > > > >From: "Gunnar Hellstrom" > > > > >To: "Arnoud van Wijk" > > > > >Cc: ; ; > > > > >Sent: Tuesday, July 06, 2004 4:22 PM > > > > >Subject: RE: Tiny ant vs big Mammoths, was RE: [Simple] Using MSRP for > > > > >real time text conversation > > > > > > > > > > > > > > > > I opened a new thread under the name > > > > > > > > > > > > RE: [Simple] Using MSRP for (pseudo?) real time text conversation > > > > > > > > > > > > For discussing conclusions and negotiation. > > > > > > Hope you all will join there. > > > > > > > > > > > > I agree with Arnoud in the impression that any user you show > real time > > > > > text conversation > > > > > > to, say that it is very good and needed in future services. > > > > > > > > > > > > So, please look for the new subject line and start thinking > about what > > > > > inter-relations > > > > > > that are needed do declare and negotiate what text service you > can and > > > > > want to use. And > > > > > > answer these messages, so that we get back to one thread. > > > > > > > > > > > > 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: owner-toip@snowshore.com [mailto:owner-toip@snowshore.com]On > > > > > > >Behalf Of Arnoud van Wijk > > > > > > >Sent: Sunday, July 04, 2004 11:32 AM > > > > > > >To: hisham.khartabil@nokia.com; Henry.Sinnreich@mci.com; > > > > > > >dean.willis@softarmor.com > > > > > > >Cc: bcampbell@dynamicsoft.com; gunnar.hellstrom@omnitor.se; > > > > > > >adam@dynamicsoft.com; stf267@etsi.org; simple@ietf.org; > > > > > > >toip@snowshore.com > > > > > > >Subject: RE: Tiny ant vs big Mammoths, was RE: [Simple] Using > MSRP for > > > > > > >real time text conversation > > > > > > > > > > > > > > > > > > > > >Hisham, > > > > > > >Actually... > > > > > > >I did some market research. Based on 15 people. > > > > > > >3 deaf, 5 worked in deaf related business (hearing people) > > > > > > >And 7 don't care about deaf (2 of them are IM freaks). > > > > > > > > > > > > > >Result: > > > > > > > > > > > > > >First telling them about total conversation and Interactive text > > > > > > >(text/t140). > > > > > > >It did not mean much to them, they looked glassy eyed. Real-time > > > charcter > > > > > > >per character..oh Yawn... lovely... pish posh. They could not > imagine > > > > > it. No > > > > > > >concept of it. > > > > > > > > > > > > > >Then I showed them. > > > > > > >They could communicate with somebody in Sweden, and with me on a > > > > > different terminal in a different room. > > > > > > >All were deeply impressed. > > > > > > > > > > > > > >The 3 deaf wanted to take it home right now. Being able to > communicate > > > > > everywhere , everytime..finally free! > > > > > > >The 5 who worked in the deaf business, they loved it and want > to see > > > > > it implemted and mainstream. They love it and will use > > > > >it regularly to > > > > > > >communicate with deaf and some even say that it can be quite > > > > > convenient for hearing people as well. > > > > > > > > > > > > > >The 7 hearing, non deaf related liked it too! > > > > > > >They said, wow... this is much more direct then IM, you can > actually > > > > > call people in situations where voice is a bit not done > > > > >(think cinema, concert, > > > > > > >restaurant, train). They see it as direct real-time IM. > > > > > > >They will keep using IM anyway. But see uses for text/t140 too and > > > > > will use it if it is convenient. > > > > > > >The 2 IM freaks agreed, though they prefer IM, but if somebdoy > > > > > contacts them via interactive text text/t140, they will use it > > > > >too. > > > > > > >"It depends who to contact to use the right text communication > method. > > > > > I like the choice to have an alternative". > > > > > > > > > > > > > >So. Yes.. I know people will like it. Not everybody will use > > > > > interactive text. Some will thus only use if somebody else uses > > > > >it, whether a deaf > > > > > > >person or one who likes to use text/t140. > > > > > > > > > > > > > >All of them hope that interactive text will be mainstream and > will use > > > > > it with varying degrees, from sometimes, to daily. > > > > > > > > > > > > > >So, this is my message, from an interactive text user AND having > > > > > showed/demonstrated interactive text to other people. It is > > > > >not my desire > > > > > > >only. > > > > > > > > > > > > > >Greetz > > > > > > > > > > > > > >Arnoud > > > > > > > > > > > > > >-----Original Message----- > > > > > > >From: hisham.khartabil@nokia.com > [mailto:hisham.khartabil@nokia.com] > > > > > > >Sent: vrijdag 2 juli 2004 9:19 > > > > > > >To: a.vwijk@viataal.nl; Henry.Sinnreich@mci.com; > > > dean.willis@softarmor.com > > > > > > >Cc: bcampbell@dynamicsoft.com; gunnar.hellstrom@omnitor.se; > > > > > > >adam@dynamicsoft.com; stf267@etsi.org; simple@ietf.org; > > > toip@snowshore.com > > > > > > >Subject: RE: Tiny ant vs big Mammoths, was RE: [Simple] Using > MSRP for > > > > > real > > > > > > >time text conversation > > > > > > > > > > > > > >Arnoud, > > > > > > > > > > > > > >You speak as if you have done the market research already for all > > > of us :) > > > > > > >How do you know that people will appreciate it once they > discover it? > > > > > How do > > > > > > >you know that people will use it? How do you know that it adds > value > > > > > to the > > > > > > >phone instead of just implementing something that no one will use? > > > How do > > > > > > >you know that if I like interactive text, then my mum and dad > will and > > > > > buy a > > > > > > >phone like mine just to use interactive text???? How do you > know...? > > > > > > > > > > > > > >Did people complain to you that IM the way it is these days in > > > annoying to > > > > > > >use? or are you just stating your opinion? > > > > > > > > > > > > > >And about mobile phones. If you can type an SMS faster than 2 > > > characters a > > > > > > >second, you're a genius. Even if you can, I don't believe > > > operators would > > > > > > >want to floor they scarce air interface with IP packets that > carry 2 > > > > > > >characters at a time. > > > > > > > > > > > > > >Thanks, > > > > > > >Hisham > > > > > > > > > > > > > > > > > > > > >- > > > > > > >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 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 > > > > > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sat Jul 10 03:06: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 DAA26448 for ; Sat, 10 Jul 2004 03:06: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 1BjBw9-0004RW-BV for simple-archive@ietf.org; Sat, 10 Jul 2004 03:06:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BjBvD-00047N-00 for simple-archive@ietf.org; Sat, 10 Jul 2004 03:05:20 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BjBum-0003n5-00; Sat, 10 Jul 2004 03:04:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BjBrz-0007gA-Bu; Sat, 10 Jul 2004 03:01:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BjBrA-0007Xf-KM for simple@megatron.ietf.org; Sat, 10 Jul 2004 03:01: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 DAA26272 for ; Sat, 10 Jul 2004 03:01: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 1BjBr8-0002o5-Cp for simple@ietf.org; Sat, 10 Jul 2004 03:01:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BjBqA-0002UH-00 for simple@ietf.org; Sat, 10 Jul 2004 03:00:08 -0400 Received: from mail3.pi.se ([195.7.64.137] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1BjBp6-0001yF-00 for simple@ietf.org; Sat, 10 Jul 2004 02:59:00 -0400 Received: from vit ([80.251.207.22]) (authenticated (0 bits)) by mail3.pi.se (8.12.10/8.11.2) with ESMTP id i6A6uQSt028243; Sat, 10 Jul 2004 08:56:55 +0200 (CEST) From: "Gunnar Hellstrom" To: "Mike Hammer" , "Barry Dingle" , , , Subject: RE: Tiny ant vs big Mammoths, was RE: [Simple] Using MSRP for Date: Sat, 10 Jul 2004 08:58:17 +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: <4.3.2.7.2.20040709104443.00b19668@cia.cisco.com> 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=1.1 required=5.0 tests=MAILTO_TO_SPAM_ADDR autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Mike, I get the impression that you missed the intensive mail exchange that took place in the lists the last two weeks or so. You can find it in the archive of the simple group. I appreciate that Barry refers to the service descriptions in F.700 and F.703. I think they reflect well the service we know that there is a need for, but is not yet wide spread. The "real time" we are talking about gives the same feeling for text as voice telephony gives for voice users. No waiting. The receiver builds understanding of the thought while it is expressed by the transmitting person. If you say a word in mistake, you say "whoops - I meant...", if you type something in error you can erase it in front of the reader?s eyes, or type "whoops - I meant ...". This direct mode is needed to get really deep in a text based discussion. It is also needed if you want to offer online text translation of a speech or conference. If a sentence of text is stored until pressing ENTER or SEND, the typing person may get stressed by the feeling to need to complete the thought soon, and the reader may get stressed by sitting waiting and start fancying that the typing person types away in long explanations that are not needed, or on the wrong track. Of course there are also situations, when the message oriented transmission is perfectly suitable. In previous discussions and documents we have used the terms "conversational text" "text conversation" and "interactive text" and even "real time interactive text conversation" for the real time, character-by-character (or close to) mode. We have noted that it is sometimes hard to get the distinction across and wondered if we need yet another term, or just sharpen the definitions. IM applications often have a button, where a real time voice and video conversation can be started. Then real time protocols are invoked, with RTP for media transport. It would be natural to also enter real time conversational mode in text with that button. Most natural the text transmission would also be RTP. But with the value of a real timish text mode, there may be a reason to also make the near real-time MSRP mode, with transmission every 900 ms and smoothened presentation. In good network conditions that will still meet the requirement for "good" real time text as specified in F.700. 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 Mike Hammer >Sent: Friday, July 09, 2004 4:50 PM >To: Barry Dingle; stf267@etsi.org; simple@ietf.org; toip@snowshore.com >Cc: Barry Dingle >Subject: Re: Tiny ant vs big Mammoths, was RE: [Simple] Using MSRP for > > >Barry, > >Agree that these are different user services, given that one allows editing >before transmission, while the other edits post-transmission. > >I think you are also agreeing that if the "Instant" in IM meets fast delay >requirements (e.g. the 1-2 seconds) then it could also be classified as >"real-time". But to keep a distinction, it would be real-time messaging >versus real time text. > >Mike > >At 05:20 PM 7/9/2004 +1000, Barry Dingle wrote: > >>Mike, >> >>As I said at the start of my first message, I am referring to requirements >>at a "Service level". Maybe I should have said a >>"User Service level" to be very clear. >> >>I am a firm believer in designing services/systems/protocols that are >>based on User Service requirements as a starting point. We >>can then use this information to define the performance of individual >>components of the service (in this case). One does not say >>this is the transmission characteristics of protocol and then change the >>User Requirements to suit. >> >>One can of course do what you suggest and define some different user >>requirements based on what IM can achieve - but you are >>defining a Different Service. OK, it is not radically different but >>different none the less. The key difference in the User >>Requirements could be the ability to edit before sending. >> >>The term 'Instant Messaging' is very descriptive of the service. It is >>fast messaging. It is not real time or near real time. >> >>Many of us use the term "Text Conversation" to reflect the immediacy and >>real time, interactive nature of the service that we >>have been talking about. >> >>The ITU-T F.700 requirements are often quoted especially in relation to >>real time text services. It specifies both a 'useable' >>service and a 'good' service. Most people have called up the 'useable' >>figures. The discussions recently are saying that maybe >>we should be using the 'good' service figures in F.700 - that is, >>allowable delays from character entry to display of less than >>1 second instead of 2 seconds. >> >>I am fully in favour of IM as it provides a very useful service. I said >>that negotiation is very desirable so that users can >>choose their preference but can fallback to an alternative. This is very >>much in the philosophy of the IETF. >> >>As I also said, negotiation allows for a protocol to be enhanced and maybe >>become more acceptable for a particular service - if >>the different versions of the protocol can be identified and included in >>the negotiation procedure. >> >> Now to your specific questions - >> >>1) It is very hard to include 'user intent' in a protocol specification. >>'Character entry' and 'character display' are easily >>identifiable actions and allow performance measurability. >> >>2) Any buffering delay MUST be included in any user delay performance >>measurement. If the buffering is of short duration, then >>it could enable that protocol to meet the 'near real time' criterion. >> >>3) If we can negotiate at session startup that IM can send with short >>delays, then it becomes an option for the real time text >>service. >> >>4) Delay is only one of the factors that must be considered. Other issues >>could include the interworking with existing text >>services. >> >>/Barry >>================== >> > Barry, >> > >> > I would object to the ENTERED aspect, as that starts into specifying >> the nature of the service beyond the transmission >>performance requirements. As >> > a user, I always want to reserve the right to edit and erase or correct >> my text before indicating intent to transmit >>information. If you want to make >> > it more generic and service independent, you would need to say >> something like: >> > >> > Transmission delay must be less than N ms from when the sender intends >> for the text data to be sent. "Intent" can be >>automated or manually indicated. >> > >> > Note that the main difference between the RTT and IM modes of texting >> is that the RTT user has his intent to send automated to >>do so after every >> > character, with possibly a buffer batching characters into one message >> when within 300 ms of each other. In the case of IM, >>the intent to send is an >> > explicit indication by hitting the ENTER, SEND, or similar key. A >> performance metric should not preclude that feature. >> > >> > Q: Does the 300ms batching count against the transmission delay in >> your ENTERED proposal? My suggestion would put that >>outside the transmission delay. >> > >> > It would be possible on IM systems to put a timer on the sending aspect >> that in the limit would approach the behavior of RTT. >>However, the >> > approach of some systems to interleave lines of text of various parties >> engaged in an IM session into the same window would >>need to change. >> > >> > Mike >> > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sat Jul 10 07:40: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 HAA08116 for ; Sat, 10 Jul 2004 07:40: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 1BjGDP-0006bj-MB for simple-archive@ietf.org; Sat, 10 Jul 2004 07:40:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BjGCU-0006Ij-00 for simple-archive@ietf.org; Sat, 10 Jul 2004 07:39:27 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BjGC0-0005yq-00; Sat, 10 Jul 2004 07:38:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BjG4p-0005oZ-7j; Sat, 10 Jul 2004 07: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 1BjG1p-0005Re-SC for simple@megatron.ietf.org; Sat, 10 Jul 2004 07:28: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 HAA07787 for ; Sat, 10 Jul 2004 07:28: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 1BjG1p-0002s9-F2 for simple@ietf.org; Sat, 10 Jul 2004 07:28:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BjG0y-0002YJ-00 for simple@ietf.org; Sat, 10 Jul 2004 07:27:33 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BjG02-0001sQ-00 for simple@ietf.org; Sat, 10 Jul 2004 07:26:34 -0400 Received: from dynamicsoft.com ([63.113.46.54]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i6ABQIbo009102 for ; Sat, 10 Jul 2004 07:26:18 -0400 (EDT) Message-ID: <40EFD246.6070800@dynamicsoft.com> Date: Sat, 10 Jul 2004 07:25:58 -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 Auth: to which resource does a permission apply X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org 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 posted an open issue on the list some weeks back around the resource lists. It had suggested that we split the resource-list document into two parts. One part is a pure list, independent of any particular usage (ie.. subscribing to it for a buddy list), and a separate part, which defines the URIs that I can actually subscribe to for accessing a buddy list. You can take a look at that note here: http://www1.ietf.org/mail-archive/web/simple/current/msg03259.html There were generally supportive comments on this proposal, so I went ahead and made the update to the document. I'll first say that it is a vast improvement; not just because it adds some efficiency, but because the notion of a resource list truly is fundamentally separate from a SIP service (such as a subscribeable buddy list) which uses that resource list. Separating them clarified the document and makes for an overall much more generic and useful solution. While making this change, I began to consider how we would support permissions for subscribing to a resource list. In other words, if I have a group buddy list, like marketing@example.com, and I want anyone in marketing to be able to subscribe to it, how would I set up the permissions for that? The answer is really obvious - we already have a solution. The presence authorization rules spec can be used to define permissions to subscribing to any presence resource; and that would include a list. As such, out of the box, that document can be used to define permissions for a list. That introduces a problem, which is how one goes about defining which permissions to apply when the server gets a subscription to a particular buddy list. Right now, the document says that the server fetches all of the permission documents associated with that user. That won't work if those permission documents can be applied to subscriptions to a multiplicity of resources. That will be the case if we want to use those permissions for buddy list resources. It will also be a problem if a single user has a multiplicity of aliases for which it wants the same permissions to apply. There are two possible ways to fix this: 1. You pretty much do the same kind of thing that the referenced email describes for resource lists. You need a separate index, which says, for each resource on a server, what are thet set of permission documents that get applied when you receive a subscription for that resource. This index is writeable by a user, and it can only contain resources that are "owned" by that user. 2. You can add a new condition to the rule document, which specifies the target resource as part of the condition of applicability. The drawback of just doing (2) is that, when a server gets a subscription for a list resource, it has to do use the xcap directory, get tons and tons of documents, and then determine which ones apply. Most won't. If (1) is done, the buddy list server can figure out, with a single XCAP query, the entire set of premission documents it has to fetch in order to process the request. I think thats really important as a property. Indeed, it is this property which drove me to suggest the approach in the email above for resource list definitions themselves. The drawback of doing (1) alone is that rule documents start to lose their meaning as standalone permissions, and I'd like them to be meaningful outside of xcap. So, my proposal is to do (1) and (2). I think its important to note that this problem, and the problem documented in the above referenced email, are closely related to the recent XCAP directory proposal by Miguel. In particular, Miguels document allows for reading of a directory, which is effectively an index of documents. However, the directory solution does NOT work for this problem; the reason is that the user has to explicitly WRITE the index - that is, it has to explicitly say which permission documents are to be applied to a subscription for a particular resource, and it has to explicitly say which resource list is associated with a buddy list URI. Thus, I believe if we proceed with doing (1) and (2), the directory approach becomes a nice-to-have, but won't be essential at all for making resource-lists or presence authorization rules work. The reason is that the index documents exist in a fixed location. As such, when a client starts up, and it has no idea about anything, it can fetch the index lists, and those index lists contain references to the resource lists/rule documents for that user. Thus, they ALSO serve as a directory function. It is possible that a user has defined permissions or resource lists that are not bound to an index. In that case, a cold-start client would not know about them. In such a case the XCAP directory would be useful. However, if a client simply doesnt do that; that is, if a client only ever defines resource lists that it uses, and rule documents that it uses, you won't ever need the directory. 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 Mon Jul 12 13:08: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 NAA24491 for ; Mon, 12 Jul 2004 13:08: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 1Bk4I5-00012g-Jj for simple-archive@ietf.org; Mon, 12 Jul 2004 13:08:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bk4H9-0000p5-00 for simple-archive@ietf.org; Mon, 12 Jul 2004 13:07:36 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bk4GH-0000OL-00; Mon, 12 Jul 2004 13:06:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bk41W-0003sT-9B; Mon, 12 Jul 2004 12:51:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bk3kG-000189-HI for simple@megatron.ietf.org; Mon, 12 Jul 2004 12:33: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 MAA21871 for ; Mon, 12 Jul 2004 12:33: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 1Bk3kF-0000HO-IA for simple@ietf.org; Mon, 12 Jul 2004 12:33:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bk3jH-00001g-00 for simple@ietf.org; Mon, 12 Jul 2004 12:32:36 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1Bk3iK-0007N6-00 for simple@ietf.org; Mon, 12 Jul 2004 12:31:36 -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 i6CGIpN9022957; Mon, 12 Jul 2004 12:18:51 -0400 (EDT) Received: from mhammer-w2k03.cisco.com (dhcp-hrn-64-100-229-208.cisco.com [64.100.229.208]) by fruitpie.cisco.com (MOS 3.4.6-GR) with ESMTP id BAN18627; Mon, 12 Jul 2004 09:18:46 -0700 (PDT) Message-Id: <4.3.2.7.2.20040712120504.00b0dbd0@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 12 Jul 2004 12:19:55 -0400 To: "Gunnar Hellstrom" , "Barry Dingle" , , , From: Mike Hammer Subject: RE: Tiny ant vs big Mammoths, was RE: [Simple] Using MSRP for In-Reply-To: References: <4.3.2.7.2.20040709104443.00b19668@cia.cisco.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.6 required=5.0 tests=AWL,MAILTO_TO_SPAM_ADDR autolearn=no version=2.60 Gunnar, No, I have seen the whole conversation in all its talk-past one another glory. Even so, I have a full appreciation for the mode of communication service that goes by the name of RTT and fully support having that capability become mainstream. I fully understand the distinction between instant text, character by character, and instant messaging. For, my own personal use, I have a preference for one over the other. The use of one or the other should be a matter of negotiation, not wide availability, or lack thereof, of each mode. I only asked a simple question, both to Barry and to you in sidebars to the email threads: "When can a text communications service be considered real-time?" Barry responded, albeit putting it on the mail list. In several of your messages you imply that instant messaging is not instant, i.e. real-time. I suspect this impression of yours is based on personal anecdotal experience (I'm guessing SMS), and not generally applicable to all such services provided today. I was simply trying to clarify a term being used on these lists, that has both technical and legal implications. Please don't hold a desire for clarity against me. I am not pushing any agenda. Mike At 08:58 AM 7/10/2004 +0200, Gunnar Hellstrom wrote: >Mike, > >I get the impression that you missed the intensive mail exchange that took >place in the >lists the last two weeks or so. >You can find it in the archive of the simple group. > >I appreciate that Barry refers to the service descriptions in F.700 and >F.703. I think >they reflect well the service we know that there is a need for, but is not >yet wide >spread. > >The "real time" we are talking about gives the same feeling for text as >voice telephony >gives for voice users. No waiting. The receiver builds understanding of >the thought while >it is expressed by the transmitting person. If you say a word in mistake, >you say >"whoops - I meant...", if you type something in error you can erase it in >front of the >reader?s eyes, or type "whoops - I meant ...". >This direct mode is needed to get really deep in a text based discussion. >It is also >needed if you want to offer online text translation of a speech or conference. > >If a sentence of text is stored until pressing ENTER or SEND, the typing >person may get >stressed by the feeling to need to complete the thought soon, and the >reader may get >stressed by sitting waiting and start fancying that the typing person >types away in long >explanations that are not needed, or on the wrong track. > >Of course there are also situations, when the message oriented >transmission is perfectly >suitable. > >In previous discussions and documents we have used the terms >"conversational text" "text >conversation" and "interactive text" and even "real time interactive text >conversation" >for the real time, character-by-character (or close to) mode. We have >noted that it is >sometimes hard to get the distinction across and wondered if we need yet >another term, or >just sharpen the definitions. > >IM applications often have a button, where a real time voice and video >conversation can be >started. Then real time protocols are invoked, with RTP for media >transport. It would be >natural to also enter real time conversational mode in text with that >button. Most natural >the text transmission would also be RTP. > >But with the value of a real timish text mode, there may be a reason to >also make the near >real-time MSRP mode, with transmission every 900 ms and smoothened >presentation. In good >network conditions that will still meet the requirement for "good" real >time text as >specified in F.700. > > >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 Mike Hammer > >Sent: Friday, July 09, 2004 4:50 PM > >To: Barry Dingle; stf267@etsi.org; simple@ietf.org; toip@snowshore.com > >Cc: Barry Dingle > >Subject: Re: Tiny ant vs big Mammoths, was RE: [Simple] Using MSRP for > > > > > >Barry, > > > >Agree that these are different user services, given that one allows editing > >before transmission, while the other edits post-transmission. > > > >I think you are also agreeing that if the "Instant" in IM meets fast delay > >requirements (e.g. the 1-2 seconds) then it could also be classified as > >"real-time". But to keep a distinction, it would be real-time messaging > >versus real time text. > > > >Mike > > > >At 05:20 PM 7/9/2004 +1000, Barry Dingle wrote: > > > >>Mike, > >> > >>As I said at the start of my first message, I am referring to requirements > >>at a "Service level". Maybe I should have said a > >>"User Service level" to be very clear. > >> > >>I am a firm believer in designing services/systems/protocols that are > >>based on User Service requirements as a starting point. We > >>can then use this information to define the performance of individual > >>components of the service (in this case). One does not say > >>this is the transmission characteristics of protocol and then change the > >>User Requirements to suit. > >> > >>One can of course do what you suggest and define some different user > >>requirements based on what IM can achieve - but you are > >>defining a Different Service. OK, it is not radically different but > >>different none the less. The key difference in the User > >>Requirements could be the ability to edit before sending. > >> > >>The term 'Instant Messaging' is very descriptive of the service. It is > >>fast messaging. It is not real time or near real time. > >> > >>Many of us use the term "Text Conversation" to reflect the immediacy and > >>real time, interactive nature of the service that we > >>have been talking about. > >> > >>The ITU-T F.700 requirements are often quoted especially in relation to > >>real time text services. It specifies both a 'useable' > >>service and a 'good' service. Most people have called up the 'useable' > >>figures. The discussions recently are saying that maybe > >>we should be using the 'good' service figures in F.700 - that is, > >>allowable delays from character entry to display of less than > >>1 second instead of 2 seconds. > >> > >>I am fully in favour of IM as it provides a very useful service. I said > >>that negotiation is very desirable so that users can > >>choose their preference but can fallback to an alternative. This is very > >>much in the philosophy of the IETF. > >> > >>As I also said, negotiation allows for a protocol to be enhanced and maybe > >>become more acceptable for a particular service - if > >>the different versions of the protocol can be identified and included in > >>the negotiation procedure. > >> > >> Now to your specific questions - > >> > >>1) It is very hard to include 'user intent' in a protocol specification. > >>'Character entry' and 'character display' are easily > >>identifiable actions and allow performance measurability. > >> > >>2) Any buffering delay MUST be included in any user delay performance > >>measurement. If the buffering is of short duration, then > >>it could enable that protocol to meet the 'near real time' criterion. > >> > >>3) If we can negotiate at session startup that IM can send with short > >>delays, then it becomes an option for the real time text > >>service. > >> > >>4) Delay is only one of the factors that must be considered. Other issues > >>could include the interworking with existing text > >>services. > >> > >>/Barry > >>================== > >> > Barry, > >> > > >> > I would object to the ENTERED aspect, as that starts into specifying > >> the nature of the service beyond the transmission > >>performance requirements. As > >> > a user, I always want to reserve the right to edit and erase or correct > >> my text before indicating intent to transmit > >>information. If you want to make > >> > it more generic and service independent, you would need to say > >> something like: > >> > > >> > Transmission delay must be less than N ms from when the sender intends > >> for the text data to be sent. "Intent" can be > >>automated or manually indicated. > >> > > >> > Note that the main difference between the RTT and IM modes of texting > >> is that the RTT user has his intent to send automated to > >>do so after every > >> > character, with possibly a buffer batching characters into one message > >> when within 300 ms of each other. In the case of IM, > >>the intent to send is an > >> > explicit indication by hitting the ENTER, SEND, or similar key. A > >> performance metric should not preclude that feature. > >> > > >> > Q: Does the 300ms batching count against the transmission delay in > >> your ENTERED proposal? My suggestion would put that > >>outside the transmission delay. > >> > > >> > It would be possible on IM systems to put a timer on the sending aspect > >> that in the limit would approach the behavior of RTT. > >>However, the > >> > approach of some systems to interleave lines of text of various parties > >> engaged in an IM session into the same window would > >>need to change. > >> > > >> > Mike > >> > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jul 12 20: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 UAA05770 for ; Mon, 12 Jul 2004 20: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 1BkBHn-0004VY-V2 for simple-archive@ietf.org; Mon, 12 Jul 2004 20:36:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkBCX-0003Rd-00 for simple-archive@ietf.org; Mon, 12 Jul 2004 20:31:18 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BkBAH-0002uv-02; Mon, 12 Jul 2004 20:28:57 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BkAyR-0003I7-KR; Mon, 12 Jul 2004 20:16:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BkA9a-00079s-Ng; Mon, 12 Jul 2004 19:24:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bk6py-0002Wx-Q2 for simple@megatron.ietf.org; Mon, 12 Jul 2004 15:51: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 PAA06262 for ; Mon, 12 Jul 2004 15:51: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 1Bk6px-0002NB-KE for simple@ietf.org; Mon, 12 Jul 2004 15:51:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bk6p0-0002A9-00 for simple@ietf.org; Mon, 12 Jul 2004 15:50:43 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1Bk6oE-0001kC-00 for simple@ietf.org; Mon, 12 Jul 2004 15:49:54 -0400 Received: from dynamicsoft.com ([63.113.46.18]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i6CJnhbo010072 for ; Mon, 12 Jul 2004 15:49:43 -0400 (EDT) Message-ID: <40F2EB3D.6080104@dynamicsoft.com> Date: Mon, 12 Jul 2004 15:49:17 -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] New I-D: presence data model and its relationship to our presence work X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org 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 just submitted an I-D on a presence data model for SIMPLE, which will appear shortly in the archives. Until then, you can pick it up from: http://www.jdrosen.net/papers/draft-rosenberg-simple-presence-data-model-00.txt This I-D is a further elaboration on the model I discussed at the interim, and it further analyzes the meaning of operations like composition, publication, and filtering as they relate to the data model. Composition in particular gets a lot of discussion, since its fundamentally about manipulating presence data, and then is intimately related with the presence data model. The document distills a lot of concepts that have been discussed over the years of this group, which have afaik remain undocumented (for example, Henning's pivot operations, and the presence server processing flow that we discussed on the list some months back). After writing this, I had a lot more clarity in my mind about how all of our presence work fit together, and an particular, I feel that it answers the question of "what is a tuple" in a sufficiently clear way that we can have some interoperability of presence document interpretation across implementations. The document proposes a concrete plan of attack for how this data model affects our ongoing work. Mostly its minor changes to the presence related documents. I'd like to try and see if we can agree on the following points: 1. the data model makes sense, 2. the data model gives people the flexibility they need to represent the systems they are interested in, 3. the data model makes it sufficiently clear about what a tuple is to create interoperable presence systems, 4. the plan of attack makes sense given the previous 3 Comments in any of these four categories are most welcome. I'll be starting some other threads, and in particular, responding to Henning's recent note, and referring to some of the concepts described in here as part of the discussion. As such, the main point of this note is really to encourage people to please take a look at this document. At this point, I feel that we are really stuck on resolving this "what is a tuple" question in order to produce a coherent set of specs. In as much as I hope this document unstucks us, I think its a key part of moving forward. Please take a look and comment. 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 Mon Jul 12 21:32: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 VAA10284 for ; Mon, 12 Jul 2004 21:32: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 1BkC9J-0003vf-7P for simple-archive@ietf.org; Mon, 12 Jul 2004 21:32:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkC8J-0003YU-00 for simple-archive@ietf.org; Mon, 12 Jul 2004 21:31:00 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BkC6z-0002zR-00; Mon, 12 Jul 2004 21:29:37 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BkC6z-0004n3-Nw; Mon, 12 Jul 2004 21:29:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BkAuJ-00040K-46; Mon, 12 Jul 2004 20:12:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bk8h6-00055v-1L for simple@megatron.ietf.org; Mon, 12 Jul 2004 17:50: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 RAA19307 for ; Mon, 12 Jul 2004 17:50: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 1Bk8h4-0003Zj-Nr for simple@ietf.org; Mon, 12 Jul 2004 17:50:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bk8fl-0003B3-00 for simple@ietf.org; Mon, 12 Jul 2004 17:49:18 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1Bk8ea-0002Xx-00 for simple@ietf.org; Mon, 12 Jul 2004 17:48:04 -0400 Received: from dynamicsoft.com ([63.113.46.18]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i6CLljbo010182; Mon, 12 Jul 2004 17:47:45 -0400 (EDT) Message-ID: <40F306E6.3020903@dynamicsoft.com> Date: Mon, 12 Jul 2004 17:47: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: hgs@cs.columbia.edu Subject: Re: [Simple] What are tuples? References: <57796.212.119.9.178.1089110888.squirrel@webmail.cs.columbia.edu> In-Reply-To: <57796.212.119.9.178.1089110888.squirrel@webmail.cs.columbia.edu> 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. hgs@cs.columbia.edu wrote: > Trying to pick up and maybe summarize aspects of the discussion. There may > be some items of general consensus: > > - [HUMAN] There didn't to be much enthusiasm for a separate tuple type for > the human itself. Rather, there might be some use for shared information > that reflects the presentity as a whole (see below). I think we need to be careful to think of the "human" as being two very different things. One is the "presentity", which is a model for the state of the user, separate from any devices or services that they may use, which have presnce implications. Most of RPID covers this kind of data - "in-a-meeting", geographic location, etc. Then there is "human" as a mode of communications - i.e., person-to-person talking. I think the latter is really a communications service, where the "devices" are vocal cords/ears, and the "network" is the air. I think we need to model both of these, though I don't think person-to-person communications should be treated as special or different from other forms of communications services. >In general, if > different tuples represent complementary rather than conflicting > information about a presentity, there doesn't seem much need for a >human > abstraction. I think we absolutely need to have a concrete understanding of what a presence attribute is characterizing. > > One use for a "human" is the ability to indicate whether the person is > reachable by visiting. Rather than designating some pseudo-URI (goto: > :-)), it might be sufficient to have a URI-less tuple. Having a label > seems to just introduce another error condition (in-person type with a > URI). I don't think you want to have a special label that says, "this is a person to person communications". After all, for other services (telephony, PTT, IM, SMS, etc.) we seem to have settled on the idea that either the URI scheme describes the service, or where the scheme is ambigous, characteristic information tells you what it is. I actually think that, if we had a URI scheme for this, it would be ideal. In the absence of one, omitting the contact URI is probably reasonable. However, I think its a mistake to *equate* lack of a contact URI with "person to person communications". I think this is overloading things. The only think lack of a URI means is that the presentity elected not to tell me the URI for this service. I don't think that application of a privacy policy, which might strip the URI, should fundamentally change the meaning of the service. > > Proposal: treat non-URI tuple as personal interaction. Disagree. In the context of the presence data model draft I mentioned in a separate note, that: 1. in-person communications is modeled as a service. Postal communications is similar, and also a service. 2. Like other communications service, the service is identified by the scheme along with service characteristics 3. We don't at this time, define either a scheme or service characteristics for person-to-person communications or postal services 4. down the road, we can work on a URI scheme for representing this kind of interactions > > - [SERVICE] There seems to some consensus that all tuples are essentially > services. There are different granularities of service announcement, e.g., > by unifying several URIs behind one externally visible URI, with a proxy > doing the detail routing, but there doesn't seem to be a fundamental > difference between a URI representing one and one hiding several. I think that the most important piece of information about a user is their set of services, and thus services are the first class citizens we need to model. I agree that a service advertised in a document could map to a lot of actual services, and that there is no difference, from a modeling perspective, between a URI that represents a UA instance and a URI that represents a proxy that can fork there. However, I do think we have a notion of devices and of presentity that are separate from services. > > Proposal: drop tuple classification. I think that the first step is to agree about the underlying data model. That is, forget about tuples and entities and XML - what is the underlying information we want to convey, and how does that information relate. Once we know that, determining whether we represent things with or or is an exercise in syntactic encodings, and nearly anything will do. I think that we have definitely been talking about three fundamentally different pieces of data - services (representing the means of communications), devices (representing the underlying shared resource in which services are hosted) and presentity (the actual user, whose characteristics and status are independent of the services or devices they are using. i.e., it is the *user* thats in a meeting, its the *user* thats on a phone). > > - [DEVICE] Some tuples will share characteristics. For example, all > devices carried on the belt of a single user will share the same location > to within a few inches, while others might share device characteristics > such as screen size. While the concept of 'device' is fairly clear for > many classical devices such as cell phones, laptops, desk phones and the > like, there are also an increasing number of pseudo-devices tied together > by some kind of personal area network (PAN) such as BlueTooth. I think thats OK. As long as the model allows for modeling of virtual devices, you can cover these cases. I don't think we need to impose on a presentity how it chooses to map physical reality into the model. We just need to be clear about what information the presence data is conveying. > > A single physical device might offer many different services, but it is > unclear to me as to why the watcher benefits from knowing this. The think the watcher benefits because it provides what I think is useful information for the watcher to make a choice. For example, "oh, i know bob is travelling and has his cell phone with him, look at that, he has sms on his phone, i will send him an sms". I also think that people tend to think about communications in terms of devices. People say, "call me on my cell", such that the device is the center point for choice and preference. Also keep in mind that watchers are not the only consumers of presence documents. I think that the device information is incredibly useful for presence servers in the process of composition. > > There has been some discussion on providing some labeling or grouping that > ties together tuples as being part of some notion of a device. > > There are several possible motivations for such labeling or grouping. At > the lowest level, it simply avoids repeating common information such as > location, presumably to make notifications shorter. No, its not just a compression operation. Its to allow me to correlate information I learned about a device from one publisher, with a service that runs on that device as indicated by another publisher. > This might also allow > the watcher to infer characteristics across tuples, although I'm less > clear what safe assumptions on such inference might be. Right. > > Question: I'd like to hear more about motivations and use cases. > > Proposal: Can we punt? The whole notion of device has been a constant factor in our "what is a tuple" discussions all along. Indeed, rpid talks about devices and says a lot about what kind of information is associated with a device vs. a service. Thus, I think we should trying and bring clarity to the definition rather than remove all notion of device from rpid. > > - [INHERITANCE] There was discussion on some way of inheriting information > from the presentity (by putting common information at the presentity > level) or from other tuples (by reference to a tupe identifier). I think that inheritance is a bad idea. THe meanining of an attribute is tied to whether the attribute is about a device, service or presentity. "Idle", for example, means something entirely different in each case: 1. if a device is idle, like my PC, it means I have not accessed the device or any services on it for some time. This is the classic meaning of idle in todays IM systems 2. if a a service is idle, like my IM client, it means I havent used the service (i.e., havent sent/receive an IM) for some time 3. if a person is idle, it means that they are bored and not doing anything Inheritance makes sense only when there is a is-a relationship between the thing that is inhertiting and the thing that is the source of the inheritance. Since services and devices and presentities are not the same thing, I dont think we should be inheriting amongst them. I think that, the fewer places an attribute can appear (being associated with a service, device or tuple), the less confusion there is about what that attribute means. When it does appear in multiple places, it should be because it is truly meaningful for a devices, presentities and services. For example, location is meaningful for a device and for a presentity. -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 Jul 13 04:01: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 EAA18957 for ; Tue, 13 Jul 2004 04:01: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 1BkIE4-0000ZG-P8 for simple-archive@ietf.org; Tue, 13 Jul 2004 04:01:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkID3-0000EM-00 for simple-archive@ietf.org; Tue, 13 Jul 2004 04:00:18 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BkICQ-0007j8-00; Tue, 13 Jul 2004 03:59:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BkI2q-0004nL-L3; Tue, 13 Jul 2004 03:49:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BkHxb-0003XE-Ar for simple@megatron.ietf.org; Tue, 13 Jul 2004 03:44: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 DAA18290 for ; Tue, 13 Jul 2004 03:44: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 1BkHxY-0003ef-C2 for simple@ietf.org; Tue, 13 Jul 2004 03:44:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkHwk-0003Nw-00 for simple@ietf.org; Tue, 13 Jul 2004 03:43:27 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1BkHvs-00036H-00 for simple@ietf.org; Tue, 13 Jul 2004 03:42:32 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i6D7gVb02583; Tue, 13 Jul 2004 10:42:31 +0300 (EET DST) X-Scanned: Tue, 13 Jul 2004 10:42: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 i6D7gRns014084; Tue, 13 Jul 2004 10:42:27 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00P11rXA; Tue, 13 Jul 2004 10:42:26 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 i6D7gPn13499; Tue, 13 Jul 2004 10:42:25 +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, 13 Jul 2004 10:42:23 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Date: Tue, 13 Jul 2004 10:42:23 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7023EEB10@esebe019.ntc.nokia.com> Thread-Topic: WGLC: Event Filtering Thread-Index: AcRetDhzVqeGMAuZRKix1HWHOwolFgJ+HpiA To: , X-OriginalArrivalTime: 13 Jul 2004 07:42:23.0598 (UTC) FILETIME=[EF8E98E0:01C468AC] Content-Transfer-Encoding: quoted-printable Subject: [Simple] RE: 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.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable There are very few days left for the WGLC of these drafts. Please send = your comments a.s.a.p. I've had good comments for the filter-format = draft but would appreciate some more comments for filter-funct. Thanks, Hisham > -----Original Message----- > From: ext Robert Sparks [mailto:rsparks@dynamicsoft.com] > Sent: 30.June.2004 18:07 > To: simple@ietf.org > Cc: Khartabil Hisham (Nokia-TP-MSW/Helsinki) > Subject: WGLC: Event Filtering >=20 >=20 > This is a SIMPLE working group last call for the following drafts: >=20 > http://www.ietf.org/internet-drafts/draft-ietf-simple-filter-f > ormat-01.txt > http://www.ietf.org/internet-drafts/draft-ietf-simple-event-fi > lter-funct-01.txt >=20 > Please provide comments to the list or chairs by July 16. >=20 > Thanks, > RjS >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Jul 13 11:46: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 LAA19153 for ; Tue, 13 Jul 2004 11:46: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 1BkPTq-0002b5-DG for simple-archive@ietf.org; Tue, 13 Jul 2004 11:46:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkPSl-0002Ep-00 for simple-archive@ietf.org; Tue, 13 Jul 2004 11:45:00 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BkPRi-0001eF-00; Tue, 13 Jul 2004 11:43:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BkPL4-0005F4-UB; Tue, 13 Jul 2004 11:37:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BkPGG-0003xp-DZ for simple@megatron.ietf.org; Tue, 13 Jul 2004 11:32:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18268 for ; Tue, 13 Jul 2004 11:32: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 1BkPGF-0005hw-Bx for simple@ietf.org; Tue, 13 Jul 2004 11:32:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkPEx-0005Nz-00 for simple@ietf.org; Tue, 13 Jul 2004 11:30:44 -0400 Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx with esmtp (Exim 4.12) id 1BkPER-00054K-00 for simple@ietf.org; Tue, 13 Jul 2004 11:30:12 -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 i6DFTiou010309; Tue, 13 Jul 2004 10:29:44 -0500 (CDT) Received: by eamrcnt750.exu.ericsson.se with Internet Mail Service (5.5.2657.72) id <3J9VCTPS>; Tue, 13 Jul 2004 10:28:22 -0500 Message-ID: From: "George Foti (QA/EMC)" To: "'hisham.khartabil@nokia.com'" , rsparks@dynamicsoft.com, simple@ietf.org Date: Tue, 13 Jul 2004 10:29:27 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Subject: [Simple] Comments Event Filter Function -01 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org 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 Hisham, I have the following comments on the subject draft: 1) Section 3.3.3 : Changing Filters Within a Dialog First, small typo - 3 lines from the bottom: "changing" instead of "chaning". Next, why do we want to consider an error condition the case when a new filter is defined with new contents but reference an existing resource (that already had a previuosly defined filter wih a different filter id). Why not simply remove the old filter for that resource and replace that with the newly defined filter for that resource. Otherwise the only way to define a new filter for such a resource would be to explictly remove the old filter first then define a new one. This way you have uniform treatment for all cases. If you are OK with that one, then there are several places in the draft where that needs to be reflected. 2) Section 4.1 First, can you please add the following clarification to the text in the second paragraph If no URI is indicated by the filter, the filter applies to all the notifications that the RLS issues for the R-URI. If the URI indicated by the filter is a list URI, the filter applies to all the notifications that the RLS issues for the list in the filter URI. Next, in the third paragraph, you have the example on myboddies@mydomain.com & bob@mydomain.com, it seems to me that the domain must be different for the RLS to extract the filter and propagate it, so Bob should have a different domain for the statement to apply. Finally, in the paragraph before the last one, where the filter applies to a domain, you state that the RLS MUST NOT apply any filter to any notifications it sends, but instead MUST forward the filter with all fanned oiut subscriptions to the notifiers. You should qualify that statement, that it only applies if the domain is a different domain then the one that to which the RLS belongs. 3) Section 4.2 Minor typo , fourth line from the bottom: "of" instead of "oif". 4) Section 5.2 Minor typo first line: "additional" instead of "addition" 5) Section 5.3.1 Fist paragraph, you state that the NOTIFY being sent after a 2xx response to the original SUBSCRIBE MUST be populated according to the filter. Using a strength of *MUST* contradicts what you state in section 5.3 that the NOTIFY following a 202 could be used to terminate the subscription. Align the 2 sections. Rgds/gf _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jul 14 01:08: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 BAA20977 for ; Wed, 14 Jul 2004 01: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 1Bkc0P-0004xn-0q for simple-archive@ietf.org; Wed, 14 Jul 2004 01:08:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkbfH-0001NH-00 for simple-archive@ietf.org; Wed, 14 Jul 2004 00:46:48 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BkbC4-0003aL-03; Wed, 14 Jul 2004 00:16:33 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Bkb7H-0002ok-M2; Wed, 14 Jul 2004 00:11:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bkanx-0002Uc-3j; Tue, 13 Jul 2004 23:51:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bka4n-0002Hb-VQ for simple@megatron.ietf.org; Tue, 13 Jul 2004 23:04: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 XAA04301 for ; Tue, 13 Jul 2004 23: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 1Bka4k-0007iT-MK for simple@ietf.org; Tue, 13 Jul 2004 23:04:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkZfa-0002zb-00 for simple@ietf.org; Tue, 13 Jul 2004 22:38:58 -0400 Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by ietf-mx with esmtp (Exim 4.12) id 1BkZF9-0005ly-00 for simple@ietf.org; Tue, 13 Jul 2004 22:11:35 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i6E2Ap408100; Tue, 13 Jul 2004 22:10:51 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 13 Jul 2004 22:10:51 -0400 Message-ID: From: "Mary Barnes" To: "'hisham.khartabil@nokia.com'" , rsparks@dynamicsoft.com Subject: RE: [Simple] RE: WGLC: Event Filtering Date: Tue, 13 Jul 2004 22:10:47 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) 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="===============0380030275==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org 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_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. --===============0380030275== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C46947.C6CCF121" 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_01C46947.C6CCF121 Content-Type: text/plain I do have a few comments, mostly editorial/nits, but there is one general concern about the computational burden on the server that's generating these event filtered notifications, as I think that's not been very thoroughly addressed (except in the security section) and I think it needs to be highlighted upfront in these documents. Mary ---------------------------------------------------------------------- I'll start with my comments on filter-funct. - Update the document to the new template per the updated guidelines reflecting new IPR policies per RFCs: http://www.ietf.org/ietf/1id-guidelines.txt - Abstract. Is not particularly informative. I don't think the 1st paragraph is necessary at all as it only talks about things not related to this document. I would remove that and update the 2nd paragraph by changing from: " 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." To something like: " This document describes the operations a subscriber performs in order to define filtering rules associated with event notification information. The handling of responses to subscriptions carrying filtering rules and the handling of notifications with filtering rules applied to them is described. The document also describes how the notifier behaves when receiving such filtering rules and how a notification is constructed." - Section 7. Certainly, limiting the number of occurrences to 20 would help limit the DoS attacks, however, it seems that the computational intensity of these filters in general should really be highlighted much earlier in the document. I would think this would be useful in the introduction in the 2nd paragraph where the applicability of filtering relative to specific devices is discussed. It may well be a good idea to limit this spec, to systems that must support such devices, due to the computational intensity. Per my next comment, this is an engineering tradeoff, so it's not just a security issue, it's a system capacity and performance issue (for the entity handling the filters) - Section 7. Related to the previous comment, I also think that 20 is rather arbitrary and it would seem that 20 could certainly be a good default recommendation, but that systems need some engineereing to determine the optimum value. Do you all have concrete implementation experience that might help shed some light on why 20 is a good number? Perhaps, this has been discussed and I just missed it. But, this would be useful information for folks to have. I would think it's possible that implementations could have problems at lower levels or could have it set higher with no problem. Thus, more guidance in adjusting that number would be helpful. Now, comments on Filter-format, most of which are very similar to the previous comments for filter-funct. I had a few other comments marked on my hardcopy, but I think those have already been brought up: - Update the document to the new template per the updated guidelines reflecting new IPR policies per RFCs: http://www.ietf.org/ietf/1id-guidelines.txt - Abstract. Is not particularly informative. I don't think the 1st paragraph is necessary at all as it only talks about things not related to this document. I don't find the 2nd paragraph helps much either. I would suggest replacing the 1st paragraph for the abstract with the 1st 2 paragraphs from section 2, with the recommended rewording suggested below, leaving the current 2nd paragraph as a 3rd paragraph or final sentences of the abstract. - Section 2. I would suggest clarifying the first paragraph by augmenting the first paragraph by the following change from: " The filtering mechanism is expected to be particularly valuable to users of mobile wireless access devices." To: " The filtering mechanism is expected to be particularly valuable and primarily applicable to users of mobile wireless access devices." - Section 2. Related to the next comment on section 7, I think the following should be added at the end of that 2nd paragraph: " However, implementors need to be aware of the computational burden on the source of the event notification. This is discussed further in section 7." - Section 7. Certainly, limiting the number of occurrences to 20 would help limit the DoS attacks, however, it seems that the computational intensity of these filters in general should really be highlighted much earlier in the document. I would think this would be useful in the introduction in the 2nd paragraph where the applicability of filtering relative to specific devices is discussed. It may well be a good idea to limit this spec, to systems that must support such devices, due to the computational intensity. Per my next comment, this is an engineering tradeoff, so it's not just a security issue, it's a system capacity and performance issue (for the entity handling the filters) - Section 7. Related to the previous comment, I also think that 20 is rather arbitrary and it would seem that 20 could certainly be a good default recommendation, but that systems need some engineereing to determine the optimum value. Do you all have concrete implementation experience that might help shed some light on why 20 is a good number? Perhaps, this has been discussed and I just missed it. But, this would be useful information for folks to have. I would think it's possible that implementations could have problems at lower levels or could have it set higher with no problem. Thus, more guidance in adjusting that number would be helpful. -----Original Message----- From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] Sent: Tuesday, July 13, 2004 2:42 AM To: rsparks@dynamicsoft.com; simple@ietf.org Subject: [Simple] RE: WGLC: Event Filtering There are very few days left for the WGLC of these drafts. Please send your comments a.s.a.p. I've had good comments for the filter-format draft but would appreciate some more comments for filter-funct. Thanks, Hisham > -----Original Message----- > From: ext Robert Sparks [mailto:rsparks@dynamicsoft.com] > Sent: 30.June.2004 18:07 > To: simple@ietf.org > Cc: Khartabil Hisham (Nokia-TP-MSW/Helsinki) > Subject: WGLC: Event Filtering > > > This is a SIMPLE working group last call for the following drafts: > > http://www.ietf.org/internet-drafts/draft-ietf-simple-filter-f > ormat-01.txt > http://www.ietf.org/internet-drafts/draft-ietf-simple-event-fi > lter-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 ------_=_NextPart_001_01C46947.C6CCF121 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Simple] RE: WGLC: Event Filtering

I do have a few comments, mostly editorial/nits, but = there is one general concern about the computational burden on the = server that's generating these event filtered notifications, as I think = that's not been very thoroughly addressed (except in the security = section) and I think it needs to be highlighted upfront in these = documents.

Mary 
---------------------------------------------------------------= -------

I'll start with my comments on filter-funct.  =

- Update the document to the new template per the = updated guidelines reflecting new IPR policies per RFCs: http://www.ietf.org/ietf/1id-guidelines.txt=

- Abstract. Is not particularly informative.  I = don't think the 1st paragraph is necessary at all as it only talks = about things not related to this document.  I would remove that = and update the 2nd paragraph by changing from:

"  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."

To something like:
"  This document describes the operations = a subscriber performs in order
   to define filtering rules associated = with event notification information.
   The handling of responses to = subscriptions
   carrying filtering rules and the = handling of notifications with
   filtering rules applied to them is = described.  The document also describes
   how the notifier behaves when receiving = such
   filtering rules and how a notification = is constructed."

- Section 7. Certainly, limiting the number of = occurrences to 20 would help limit the DoS attacks, however, it seems = that the computational intensity of these filters in general should = really be highlighted much earlier in the document. I would think this = would be useful in the introduction in the 2nd paragraph where the = applicability of filtering relative to specific devices is = discussed.  It may well be a good idea to limit this spec, to = systems that must support such devices, due to the computational = intensity. Per my next comment, this is an engineering tradeoff, so = it's not just a security issue, it's a system capacity and performance = issue (for the entity handling the filters)

- Section 7. <Duplicate comment for = filter-funct> Related to the previous comment, I also think that 20 = is rather arbitrary and it would seem that 20 could certainly be a good = default recommendation, but that systems need some engineereing to = determine the optimum value.  Do you all have concrete = implementation experience that might help shed some light on why 20 is = a good number?  Perhaps, this has been discussed and I just missed = it.  But, this would be useful information for folks to = have.  I would think it's possible that implementations could have = problems at lower levels or could have it set higher with no = problem.  Thus, more guidance in adjusting that number would be = helpful.


Now, comments on Filter-format, most of which are = very similar to the previous comments for filter-funct. I had a few = other comments marked on my hardcopy, but I think those have already = been brought up:

- Update the document to the new template per the = updated guidelines reflecting new IPR policies per RFCs: http://www.ietf.org/ietf/1id-guidelines.txt=

- Abstract. Is not particularly informative.  I = don't think the 1st paragraph is necessary at all as it only talks = about things not related to this document.  I don't find the 2nd = paragraph helps much either.  I would suggest replacing the 1st = paragraph for the abstract with the 1st 2 paragraphs from section 2, = with the recommended rewording suggested below, leaving the current 2nd = paragraph as a 3rd paragraph or final sentences of the abstract. =

- Section 2. I would suggest clarifying the first = paragraph by augmenting the first paragraph by the following change = from:

"  The filtering mechanism is expected to = be particularly valuable to
   users of mobile wireless access = devices." 

To:
"  The filtering mechanism is expected to = be particularly valuable and       = primarily applicable to users of mobile wireless access = devices." 

- Section 2. Related to the next comment on section = 7, I think the following should be added at the end of that 2nd = paragraph:

" However, implementors need to be aware of the = computational burden on the source of the event notification.  = This is discussed further in section 7."

 
- Section 7. <Duplicate comment for = filter-funct>Certainly, limiting the number of occurrences to 20 = would help limit the DoS attacks, however, it seems that the = computational intensity of these filters in general should really be = highlighted much earlier in the document. I would think this would be = useful in the introduction in the 2nd paragraph where the applicability = of filtering relative to specific devices is discussed.  It may = well be a good idea to limit this spec, to systems that must support = such devices, due to the computational intensity. Per my next comment, = this is an engineering tradeoff, so it's not just a security issue, = it's a system capacity and performance issue (for the entity handling = the filters)

- Section 7. <Duplicate comment for = filter-funct> Related to the previous comment, I also think that 20 = is rather arbitrary and it would seem that 20 could certainly be a good = default recommendation, but that systems need some engineereing to = determine the optimum value.  Do you all have concrete = implementation experience that might help shed some light on why 20 is = a good number?  Perhaps, this has been discussed and I just missed = it.  But, this would be useful information for folks to = have.  I would think it's possible that implementations could have = problems at lower levels or could have it set higher with no = problem.  Thus, more guidance in adjusting that number would be = helpful.


-----Original Message-----
From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia= .com]
Sent: Tuesday, July 13, 2004 2:42 AM
To: rsparks@dynamicsoft.com; simple@ietf.org
Subject: [Simple] RE: WGLC: Event Filtering


There are very few days left for the WGLC of these = drafts. Please send your comments a.s.a.p. I've had good comments for = the filter-format draft but would appreciate some more comments for = filter-funct.

Thanks,
Hisham

> -----Original Message-----
> From: ext Robert Sparks [mailto:rsparks@dynamicsoft.com]
> Sent: 30.June.2004 18:07
> To: simple@ietf.org
> Cc: Khartabil Hisham = (Nokia-TP-MSW/Helsinki)
> Subject: WGLC: Event Filtering
>
>
> This is a SIMPLE working group last call for = the following drafts:
>
> http://www.ietf.org/internet-drafts/draft-ietf-simple-= filter-f
> ormat-01.txt
> http://www.ietf.org/internet-drafts/draft-ietf-simple-= event-fi
> lter-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

------_=_NextPart_001_01C46947.C6CCF121-- --===============0380030275== 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 --===============0380030275==-- From simple-bounces@ietf.org Wed Jul 14 04:49: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 EAA02531 for ; Wed, 14 Jul 2004 04:49: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 1BkfRu-0006ls-Ki for simple-archive@ietf.org; Wed, 14 Jul 2004 04:49:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkfQk-0006Ph-00 for simple-archive@ietf.org; Wed, 14 Jul 2004 04:47:59 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BkfPh-0005mA-00; Wed, 14 Jul 2004 04:46:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BkfI4-0000AQ-RO; Wed, 14 Jul 2004 04:39:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BkfBH-0005uY-2R for simple@megatron.ietf.org; Wed, 14 Jul 2004 04:31: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 EAA01641 for ; Wed, 14 Jul 2004 04:31: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 1BkfBE-00010A-UH for simple@ietf.org; Wed, 14 Jul 2004 04:31:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkfAG-0000fW-00 for simple@ietf.org; Wed, 14 Jul 2004 04:30:57 -0400 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1Bkf9D-00009E-00 for simple@ietf.org; Wed, 14 Jul 2004 04: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 i6E8Tpo02902; Wed, 14 Jul 2004 11:29:51 +0300 (EET DST) X-Scanned: Wed, 14 Jul 2004 11:29:50 +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 i6E8Tohd014301; Wed, 14 Jul 2004 11:29:50 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 004uR3lD; Wed, 14 Jul 2004 11:29:49 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 i6E8Tnu16492; Wed, 14 Jul 2004 11:29:49 +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, 14 Jul 2004 11:29:39 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Date: Wed, 14 Jul 2004 11:29:39 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7023EEB23@esebe019.ntc.nokia.com> Thread-Topic: Comments Event Filter Function -01 Thread-Index: AcRo7kyNw08u7gm+RZiRyBeSjiCSCwAiywTQ To: , X-OriginalArrivalTime: 14 Jul 2004 08:29:39.0910 (UTC) FILETIME=[B48B3660:01C4697C] Content-Transfer-Encoding: quoted-printable Subject: [Simple] RE: Comments Event Filter Function -01 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org 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 George, I appreciate you taking time to review this draft. Responses inline... > -----Original Message----- > From: ext George Foti (QA/EMC) [mailto:george.foti@ericsson.com] > Sent: 13.July.2004 18:29 > To: Khartabil Hisham (Nokia-TP-MSW/Helsinki); rsparks@dynamicsoft.com; > simple@ietf.org > Subject: Comments Event Filter Function -01 >=20 >=20 > Hi Hisham, >=20 > I have the following comments on the subject draft: >=20 > 1) Section 3.3.3 : Changing Filters Within a Dialog >=20 > First, small typo - 3 lines from the bottom: "changing"=20 > instead of "chaning". Done. > Next, why do we want to consider an error condition the case=20 > when a new filter is defined with new contents but reference=20 > an existing resource (that already had a previuosly defined=20 > filter wih a different filter id). > Why not simply remove the old filter for that resource and=20 > replace that with the newly defined filter for that resource. > Otherwise the only way to define a new filter for such a=20 > resource would be to explictly remove the old filter first=20 > then define a new one. > This way you have uniform treatment for all cases. Removing a filter is done in one way. Replacing a filter is done in = another way. Two filters to the same user is an error. Having those 2 = filters appear in the same request or in separate requests does not make = a difference. We shouldn't overload the functionality. If something is = clearly an error (trying to replace a filter in a different way than is = specified), then the client must be told about it. >=20 > If you are OK with that one, then there are several places=20 > in the draft where that needs to be reflected. >=20 > 2) Section 4.1 >=20 > First, can you please add the following clarification to the=20 > text in the second paragraph >=20 > If no URI is indicated by the filter, the filter applies to all the > notifications that the RLS issues for the R-URI.=20 > If the URI indicated by the filter is a list URI, the filter=20 > applies to all the notifications > that the RLS issues for the list in the filter URI. Clarified. >=20 > Next, in the third paragraph, you have the example on=20 > myboddies@mydomain.com & bob@mydomain.com, it seems to me=20 > that the domain must be different for the RLS to extract the=20 > filter and propagate it, so Bob should have a different=20 > domain for the statement to apply.=20 The example is correct. A filter is not propagated if Bob was not part = of the list, but is part of domain.com. >=20 > Finally, in the paragraph before the last one, where the=20 > filter applies to a domain, you state that the RLS MUST NOT=20 > apply any filter to any notifications it sends, but instead=20 > MUST forward the filter with all fanned oiut subscriptions to=20 > the notifiers.=20 > You should qualify that statement, that it only applies if=20 > the domain is a different domain then the one that to which=20 > the RLS belongs. It needs to since filters need to reach the presence server, for = example, and that server could be different than the RLS. >=20 > 3) Section 4.2 > Minor typo , fourth line from the bottom: "of" instead of "oif". >=20 > 4) Section 5.2 >=20 > Minor typo first line: "additional" instead of "addition" >=20 > 5) Section 5.3.1 > Fist paragraph, you state that the NOTIFY being sent after a 2xx > response to the original SUBSCRIBE MUST be populated > according to the filter. =20 >=20 > Using a strength of *MUST* contradicts what you state in=20 > section 5.3 that the NOTIFY following a 202 could be used to=20 > terminate the subscription. >=20 > Align the 2 sections. All done. Thanks, Hisham >=20 > Rgds/gf >=20 >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jul 14 05:17: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 FAA03911 for ; Wed, 14 Jul 2004 05:17: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 1Bkft3-0000d2-Dg for simple-archive@ietf.org; Wed, 14 Jul 2004 05:17:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bkfrx-0000HT-00 for simple-archive@ietf.org; Wed, 14 Jul 2004 05:16:06 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bkfr2-0007Qp-00; Wed, 14 Jul 2004 05:15:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bkfm3-0005XC-5f; Wed, 14 Jul 2004 05:09:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BkffL-000206-OE for simple@megatron.ietf.org; Wed, 14 Jul 2004 05:03:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03221 for ; Wed, 14 Jul 2004 05:03:01 -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 1BkffJ-0003ha-FO for simple@ietf.org; Wed, 14 Jul 2004 05:03:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkfeH-0003MU-00 for simple@ietf.org; Wed, 14 Jul 2004 05:01:59 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BkfdF-0002l9-00 for simple@ietf.org; Wed, 14 Jul 2004 05:00: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 i6E90ls08099; Wed, 14 Jul 2004 12:00:47 +0300 (EET DST) X-Scanned: Wed, 14 Jul 2004 12:00:41 +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 i6E90fQn000612; Wed, 14 Jul 2004 12:00:41 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00FPKZ52; Wed, 14 Jul 2004 12:00:40 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 i6E90eu29671; Wed, 14 Jul 2004 12:00:40 +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, 14 Jul 2004 12:00: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 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [Simple] RE: WGLC: Event Filtering Date: Wed, 14 Jul 2004 12:00:39 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7023EEB25@esebe019.ntc.nokia.com> Thread-Topic: [Simple] RE: WGLC: Event Filtering Thread-Index: AcRpR+/tC2UqnX3kSmC+QfUWmO2NVgANQO9A To: X-OriginalArrivalTime: 14 Jul 2004 09:00:40.0854 (UTC) FILETIME=[09C0BB60:01C46981] 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 Mary, Thanks for your time and comments. Responses inline... > -----Original Message----- > From: Khartabil Hisham (Nokia-TP-MSW/Helsinki)=20 > Sent: 14.July.2004 11:31 > To: Khartabil Hisham (Nokia-TP-MSW/Helsinki) > Subject: FW: [Simple] RE: WGLC: Event Filtering >=20 >=20 >=20 > -----Original Message----- > From: ext Mary Barnes [mailto:mary.barnes@nortelnetworks.com] > Sent: 14.July.2004 05:11 > To: Khartabil Hisham (Nokia-TP-MSW/Helsinki); rsparks@dynamicsoft.com > Cc: simple@ietf.org > Subject: RE: [Simple] RE: WGLC: Event Filtering >=20 >=20 > I do have a few comments, mostly editorial/nits, but there is=20 > one general concern about the computational burden on the=20 > server that's generating these event filtered notifications,=20 > as I think that's not been very thoroughly addressed (except=20 > in the security section) and I think it needs to be=20 > highlighted upfront in these documents.=20 > Mary =20 > -------------------------------------------------------------- > --------=20 > I'll start with my comments on filter-funct. =20 > - Update the document to the new template per the updated=20 > guidelines reflecting new IPR policies per RFCs:=20 > http://www.ietf.org/ietf/1id-guidelines.txt Done. > - Abstract. Is not particularly informative. I don't think=20 > the 1st paragraph is necessary at all as it only talks about=20 > things not related to this document. I would remove that and=20 > update the 2nd paragraph by changing from: > " This document describes the operations a subscriber=20 > performs in order=20 > to define filtering rules, how to handle responses to=20 > subscriptions=20 > carrying filtering rules, and how to handle notifications with=20 > filtering rules applied to them. The document also=20 > describes how the=20 > notifier behaves when receiving such filtering rules and how a=20 > notification is constructed."=20 > To something like:=20 > " This document describes the operations a subscriber=20 > performs in order=20 > to define filtering rules associated with event=20 > notification information.=20 > The handling of responses to subscriptions=20 > carrying filtering rules and the handling of notifications with=20 > filtering rules applied to them is described. The=20 > document also describes=20 > how the notifier behaves when receiving such=20 > filtering rules and how a notification is constructed."=20 Done. > - Section 7. Certainly, limiting the number of occurrences to=20 > 20 would help limit the DoS attacks, however, it seems that=20 > the computational intensity of these filters in general=20 > should really be highlighted much earlier in the document. I=20 > would think this would be useful in the introduction in the=20 > 2nd paragraph where the applicability of filtering relative=20 > to specific devices is discussed. It may well be a good idea=20 > to limit this spec, to systems that must support such=20 > devices, due to the computational intensity. Per my next=20 > comment, this is an engineering tradeoff, so it's not just a=20 > security issue, it's a system capacity and performance issue=20 > (for the entity handling the filters)=20 I agree with you, but I struggled to write some meaningful text. Can you = provide me with text? I would really appreciate it. > - Section 7. Related to=20 > the previous comment, I also think that 20 is rather=20 > arbitrary and it would seem that 20 could certainly be a good=20 > default recommendation, but that systems need some=20 > engineereing to determine the optimum value. Do you all have=20 > concrete implementation experience that might help shed some=20 > light on why 20 is a good number? Perhaps, this has been=20 > discussed and I just missed it. But, this would be useful=20 > information for folks to have. I would think it's possible=20 > that implementations could have problems at lower levels or=20 > could have it set higher with no problem. Thus, more=20 > guidance in adjusting that number would be helpful.=20 The number was not according to any implementation experience, but was = rather according to guesstimates I made using the presence document as a = guide. It is very difficult for a client to estimate the processing = power of the server that is generating those notifications and therefore = we must recommend a number for the client to follow. Having said that, = you are right that some servers might be able to handle more than the = recommended number enabling the client to set more filters. >=20 >=20 > Now, comments on Filter-format, most of which are very=20 > similar to the previous comments for filter-funct. I had a=20 > few other comments marked on my hardcopy, but I think those=20 > have already been brought up: > - Update the document to the new template per the updated=20 > guidelines reflecting new IPR policies per RFCs:=20 > http://www.ietf.org/ietf/1id-guidelines.txt Done. > - Abstract. Is not particularly informative. I don't think=20 > the 1st paragraph is necessary at all as it only talks about=20 > things not related to this document. I don't find the 2nd=20 > paragraph helps much either. I would suggest replacing the=20 > 1st paragraph for the abstract with the 1st 2 paragraphs from=20 > section 2, with the recommended rewording suggested below,=20 > leaving the current 2nd paragraph as a 3rd paragraph or final=20 > sentences of the abstract.=20 The abstract now reads: "Filtering is a mechanism for defining the preferred content to be = delivered and for specifying the rules for when the content should be = delivered. 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. The filtering mechanism is expected to be particularly valuable and = primarily applicable to users of mobile wireless access devices." > - Section 2. I would suggest clarifying the first paragraph=20 > by augmenting the first paragraph by the following change from: > " The filtering mechanism is expected to be particularly valuable to=20 > users of mobile wireless access devices." =20 > To:=20 > " The filtering mechanism is expected to be particularly=20 > valuable and primarily applicable to users of mobile=20 > wireless access devices." =20 Done. > - Section 2. Related to the next comment on section 7, I=20 > think the following should be added at the end of that 2nd paragraph:=20 > " However, implementors need to be aware of the computational=20 > burden on the source of the event notification. This is=20 > discussed further in section 7." Done. > =20 > - Section 7. Certainly,=20 > limiting the number of occurrences to 20 would help limit the=20 > DoS attacks, however, it seems that the computational=20 > intensity of these filters in general should really be=20 > highlighted much earlier in the document. I would think this=20 > would be useful in the introduction in the 2nd paragraph=20 > where the applicability of filtering relative to specific=20 > devices is discussed. It may well be a good idea to limit=20 > this spec, to systems that must support such devices, due to=20 > the computational intensity. Per my next comment, this is an=20 > engineering tradeoff, so it's not just a security issue, it's=20 > a system capacity and performance issue (for the entity=20 > handling the filters)=20 > - Section 7. Related to=20 > the previous comment, I also think that 20 is rather=20 > arbitrary and it would seem that 20 could certainly be a good=20 > default recommendation, but that systems need some=20 > engineereing to determine the optimum value. Do you all have=20 > concrete implementation experience that might help shed some=20 > light on why 20 is a good number? Perhaps, this has been=20 > discussed and I just missed it. But, this would be useful=20 > information for folks to have. I would think it's possible=20 > that implementations could have problems at lower levels or=20 > could have it set higher with no problem. Thus, more=20 > guidance in adjusting that number would be helpful.=20 As above. Thanks, Hisham >=20 >=20 > -----Original Message-----=20 > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com]=20 > Sent: Tuesday, July 13, 2004 2:42 AM=20 > To: rsparks@dynamicsoft.com; simple@ietf.org=20 > Subject: [Simple] RE: WGLC: Event Filtering=20 >=20 >=20 > There are very few days left for the WGLC of these drafts.=20 > Please send your comments a.s.a.p. I've had good comments for=20 > the filter-format draft but would appreciate some more=20 > comments for filter-funct. > Thanks,=20 > Hisham=20 > > -----Original Message-----=20 > > From: ext Robert Sparks [mailto:rsparks@dynamicsoft.com]=20 > > Sent: 30.June.2004 18:07=20 > > To: simple@ietf.org=20 > > Cc: Khartabil Hisham (Nokia-TP-MSW/Helsinki)=20 > > Subject: WGLC: Event Filtering=20 > >=20 > >=20 > > This is a SIMPLE working group last call for the following drafts:=20 > >=20 > > http://www.ietf.org/internet-drafts/draft-ietf-simple-filter-f=20 > > ormat-01.txt=20 > > http://www.ietf.org/internet-drafts/draft-ietf-simple-event-fi=20 > > lter-funct-01.txt=20 > >=20 > > Please provide comments to the list or chairs by July 16.=20 > >=20 > > Thanks,=20 > > RjS=20 > >=20 > >=20 > _______________________________________________=20 > Simple mailing list=20 > Simple@ietf.org=20 > 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 Jul 14 09:51: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 JAA17062 for ; Wed, 14 Jul 2004 09:51: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 1BkkAQ-0005v1-75 for simple-archive@ietf.org; Wed, 14 Jul 2004 09:51:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bkk9f-0005bH-00 for simple-archive@ietf.org; Wed, 14 Jul 2004 09:50:42 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bkk8a-0004xj-00; Wed, 14 Jul 2004 09:49:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bkk2Q-0000oa-EQ; Wed, 14 Jul 2004 09:43:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bkjsw-0006jb-UG for simple@megatron.ietf.org; Wed, 14 Jul 2004 09:33: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 JAA16339 for ; Wed, 14 Jul 2004 09:33: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 1Bkjsw-00001q-4J for simple@ietf.org; Wed, 14 Jul 2004 09:33:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bkjrv-0007VO-00 for simple@ietf.org; Wed, 14 Jul 2004 09:32:22 -0400 Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by ietf-mx with esmtp (Exim 4.12) id 1BkjrS-0007BW-00 for simple@ietf.org; Wed, 14 Jul 2004 09:31:51 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i6EDVC402398; Wed, 14 Jul 2004 09:31:12 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 14 Jul 2004 09:31:12 -0400 Message-ID: From: "Mary Barnes" To: "'hisham.khartabil@nokia.com'" Subject: RE: [Simple] RE: WGLC: Event Filtering Date: Wed, 14 Jul 2004 09:30:57 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) 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="===============1206401671==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org 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,HTML_20_30,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. --===============1206401671== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C469A6.CB7C2EDA" 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_01C469A6.CB7C2EDA Content-Type: text/plain Hisham, I've some suggestions for the wording below [MB]: -----Original Message----- From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] Sent: Wednesday, July 14, 2004 4:01 AM To: Barnes, Mary [NGC:B601:EXCH] Cc: simple@ietf.org Subject: RE: [Simple] RE: WGLC: Event Filtering Hi Mary, Thanks for your time and comments. Responses inline... > -----Original Message----- > From: Khartabil Hisham (Nokia-TP-MSW/Helsinki) > Sent: 14.July.2004 11:31 > To: Khartabil Hisham (Nokia-TP-MSW/Helsinki) > Subject: FW: [Simple] RE: WGLC: Event Filtering > > > > -----Original Message----- > From: ext Mary Barnes [mailto:mary.barnes@nortelnetworks.com] > Sent: 14.July.2004 05:11 > To: Khartabil Hisham (Nokia-TP-MSW/Helsinki); rsparks@dynamicsoft.com > Cc: simple@ietf.org > Subject: RE: [Simple] RE: WGLC: Event Filtering > > > I do have a few comments, mostly editorial/nits, but there is > one general concern about the computational burden on the > server that's generating these event filtered notifications, > as I think that's not been very thoroughly addressed (except > in the security section) and I think it needs to be > highlighted upfront in these documents. > Mary > -------------------------------------------------------------- > -------- > I'll start with my comments on filter-funct. > - Update the document to the new template per the updated > guidelines reflecting new IPR policies per RFCs: > http://www.ietf.org/ietf/1id-guidelines.txt Done. > - Abstract. Is not particularly informative. I don't think > the 1st paragraph is necessary at all as it only talks about > things not related to this document. I would remove that and > update the 2nd paragraph by changing from: > " 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." > To something like: > " This document describes the operations a subscriber > performs in order > to define filtering rules associated with event > notification information. > The handling of responses to subscriptions > carrying filtering rules and the handling of notifications with > filtering rules applied to them is described. The > document also describes > how the notifier behaves when receiving such > filtering rules and how a notification is constructed." Done. > - Section 7. Certainly, limiting the number of occurrences to > 20 would help limit the DoS attacks, however, it seems that > the computational intensity of these filters in general > should really be highlighted much earlier in the document. I > would think this would be useful in the introduction in the > 2nd paragraph where the applicability of filtering relative > to specific devices is discussed. It may well be a good idea > to limit this spec, to systems that must support such > devices, due to the computational intensity. Per my next > comment, this is an engineering tradeoff, so it's not just a > security issue, it's a system capacity and performance issue > (for the entity handling the filters) I agree with you, but I struggled to write some meaningful text. Can you provide me with text? I would really appreciate it. > - Section 7. Related to > the previous comment, I also think that 20 is rather > arbitrary and it would seem that 20 could certainly be a good > default recommendation, but that systems need some > engineereing to determine the optimum value. Do you all have > concrete implementation experience that might help shed some > light on why 20 is a good number? Perhaps, this has been > discussed and I just missed it. But, this would be useful > information for folks to have. I would think it's possible > that implementations could have problems at lower levels or > could have it set higher with no problem. Thus, more > guidance in adjusting that number would be helpful. The number was not according to any implementation experience, but was rather according to guesstimates I made using the presence document as a guide. It is very difficult for a client to estimate the processing power of the server that is generating those notifications and therefore we must recommend a number for the client to follow. Having said that, you are right that some servers might be able to handle more than the recommended number enabling the client to set more filters. [MB] So, perhaps, the simplest thing is to make it a bit more explicit that this number is a bit arbitrary and YMMV. I would suggest changing the wording in the last sentence of this section from: " To counter this, the server SHOULD only allow filters with no more than about 20 occurrences of the , , and elements." To: " To counter this, the server MUST establish a limit on the number of occurrences of the , , and elements allowed in the filters. A default limit of 20 is RECOMMENDED, however, servers MAY raise or lower the limit depending upon their specific engineered capacity. " [MB] I think the MUST is important in that first sentence as that's what satisfies the security requirement to limit the DOS attack. > > > Now, comments on Filter-format, most of which are very > similar to the previous comments for filter-funct. I had a > few other comments marked on my hardcopy, but I think those > have already been brought up: > - Update the document to the new template per the updated > guidelines reflecting new IPR policies per RFCs: > http://www.ietf.org/ietf/1id-guidelines.txt Done. > - Abstract. Is not particularly informative. I don't think > the 1st paragraph is necessary at all as it only talks about > things not related to this document. I don't find the 2nd > paragraph helps much either. I would suggest replacing the > 1st paragraph for the abstract with the 1st 2 paragraphs from > section 2, with the recommended rewording suggested below, > leaving the current 2nd paragraph as a 3rd paragraph or final > sentences of the abstract. The abstract now reads: "Filtering is a mechanism for defining the preferred content to be delivered and for specifying the rules for when the content should be delivered. 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. The filtering mechanism is expected to be particularly valuable and primarily applicable to users of mobile wireless access devices." > - Section 2. I would suggest clarifying the first paragraph > by augmenting the first paragraph by the following change from: > " The filtering mechanism is expected to be particularly valuable to > users of mobile wireless access devices." > To: > " The filtering mechanism is expected to be particularly > valuable and primarily applicable to users of mobile > wireless access devices." Done. > - Section 2. Related to the next comment on section 7, I > think the following should be added at the end of that 2nd paragraph: > " However, implementors need to be aware of the computational > burden on the source of the event notification. This is > discussed further in section 7." Done. > > - Section 7. Certainly, > limiting the number of occurrences to 20 would help limit the > DoS attacks, however, it seems that the computational > intensity of these filters in general should really be > highlighted much earlier in the document. I would think this > would be useful in the introduction in the 2nd paragraph > where the applicability of filtering relative to specific > devices is discussed. It may well be a good idea to limit > this spec, to systems that must support such devices, due to > the computational intensity. Per my next comment, this is an > engineering tradeoff, so it's not just a security issue, it's > a system capacity and performance issue (for the entity > handling the filters) > - Section 7. Related to > the previous comment, I also think that 20 is rather > arbitrary and it would seem that 20 could certainly be a good > default recommendation, but that systems need some > engineereing to determine the optimum value. Do you all have > concrete implementation experience that might help shed some > light on why 20 is a good number? Perhaps, this has been > discussed and I just missed it. But, this would be useful > information for folks to have. I would think it's possible > that implementations could have problems at lower levels or > could have it set higher with no problem. Thus, more > guidance in adjusting that number would be helpful. As above. Thanks, Hisham > > > -----Original Message----- > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > Sent: Tuesday, July 13, 2004 2:42 AM > To: rsparks@dynamicsoft.com; simple@ietf.org > Subject: [Simple] RE: WGLC: Event Filtering > > > There are very few days left for the WGLC of these drafts. > Please send your comments a.s.a.p. I've had good comments for > the filter-format draft but would appreciate some more > comments for filter-funct. > Thanks, > Hisham > > -----Original Message----- > > From: ext Robert Sparks [mailto:rsparks@dynamicsoft.com] > > Sent: 30.June.2004 18:07 > > To: simple@ietf.org > > Cc: Khartabil Hisham (Nokia-TP-MSW/Helsinki) > > Subject: WGLC: Event Filtering > > > > > > This is a SIMPLE working group last call for the following drafts: > > > > http://www.ietf.org/internet-drafts/draft-ietf-simple-filter-f > > ormat-01.txt > > http://www.ietf.org/internet-drafts/draft-ietf-simple-event-fi > > lter-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 > ------_=_NextPart_001_01C469A6.CB7C2EDA Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Simple] RE: WGLC: Event Filtering

Hisham,

I've some suggestions for the wording below = [MB]:

-----Original Message-----
From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia= .com]
Sent: Wednesday, July 14, 2004 4:01 AM
To: Barnes, Mary [NGC:B601:EXCH]
Cc: simple@ietf.org
Subject: RE: [Simple] RE: WGLC: Event = Filtering


Hi Mary,

Thanks for your time and comments. Responses = inline...

> -----Original Message-----
> From: Khartabil Hisham = (Nokia-TP-MSW/Helsinki)
> Sent: 14.July.2004 11:31
> To: Khartabil Hisham = (Nokia-TP-MSW/Helsinki)
> Subject: FW: [Simple] RE: WGLC: Event = Filtering
>
>
>
> -----Original Message-----
> From: ext Mary Barnes [mailto:mary.barnes@nortel= networks.com]
> Sent: 14.July.2004 05:11
> To: Khartabil Hisham (Nokia-TP-MSW/Helsinki); = rsparks@dynamicsoft.com
> Cc: simple@ietf.org
> Subject: RE: [Simple] RE: WGLC: Event = Filtering
>
>
> I do have a few comments, mostly = editorial/nits, but there is
> one general concern about the computational = burden on the
> server that's generating these event filtered = notifications,
> as I think that's not been very thoroughly = addressed (except
> in the security section) and I think it needs = to be
> highlighted upfront in these documents.
> Mary 
> = --------------------------------------------------------------
> --------
> I'll start with my comments on = filter-funct. 
> - Update the document to the new template per = the updated
> guidelines reflecting new IPR policies per = RFCs:
> http://www.ietf.org/ietf/1id-guidelines.txt=

Done.

> - Abstract. Is not particularly = informative.  I don't think
> the 1st paragraph is necessary at all as it = only talks about
> things not related to this document.  I = would remove that and
> update the 2nd paragraph by changing = from:
> "  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."
> To something like:
> "  This document describes the = operations a subscriber
> performs in order
>    to define filtering rules = associated with event
> notification information.
>    The handling of responses to = subscriptions
>    carrying filtering rules and = the handling of notifications with
>    filtering rules applied to = them is described.  The
> document also describes
>    how the notifier behaves when = receiving such
>    filtering rules and how a = notification is constructed."

Done.


> - Section 7. Certainly, limiting the number of = occurrences to
> 20 would help limit the DoS attacks, however, = it seems that
> the computational intensity of these filters in = general
> should really be highlighted much earlier in = the document. I
> would think this would be useful in the = introduction in the
> 2nd paragraph where the applicability of = filtering relative
> to specific devices is discussed.  It may = well be a good idea
> to limit this spec, to systems that must = support such
> devices, due to the computational intensity. = Per my next
> comment, this is an engineering tradeoff, so = it's not just a
> security issue, it's a system capacity and = performance issue
> (for the entity handling the filters)

I agree with you, but I struggled to write some = meaningful text. Can you provide me with text? I would really = appreciate it.

> - Section 7. <Duplicate comment for = filter-funct> Related to
> the previous comment, I also think that 20 is = rather
> arbitrary and it would seem that 20 could = certainly be a good
> default recommendation, but that systems need = some
> engineereing to determine the optimum = value.  Do you all have
> concrete implementation experience that might = help shed some
> light on why 20 is a good number?  = Perhaps, this has been
> discussed and I just missed it.  But, this = would be useful
> information for folks to have.  I would = think it's possible
> that implementations could have problems at = lower levels or
> could have it set higher with no problem.  = Thus, more
> guidance in adjusting that number would be = helpful.

The number was not according to any implementation = experience, but was rather according to guesstimates I made using the = presence document as a guide.  It is very difficult for a client = to estimate the processing power of the server that is generating those = notifications and therefore we must recommend a number for the client = to follow. Having said that, you are right that some servers might be = able to handle more than the recommended number enabling the client to = set more filters.

[MB] So, perhaps, the simplest thing is to make it a = bit more explicit that this number is a bit arbitrary and YMMV.  I = would suggest changing the wording in the last sentence of this section = from:

"  To counter this, the server SHOULD = only
   allow filters with no more than about = 20 occurrences of the <what>,
   <changed>, <added> and = <removed> elements."
To:
"  To counter this, the server MUST = establish a limit on the number of 
   occurrences of the <what>,
   <changed>, <added> and = <removed> elements allowed in the filters. 
   A default limit of 20 is RECOMMENDED, = however, servers MAY raise or lower
   the limit depending upon their specific = engineered capacity. "

[MB] I think the MUST is important in that first = sentence as that's what satisfies the security requirement to limit the = DOS attack. 


>
>
> Now, comments on Filter-format, most of which = are very
> similar to the previous comments for = filter-funct. I had a
> few other comments marked on my hardcopy, but I = think those
> have already been brought up:
> - Update the document to the new template per = the updated
> guidelines reflecting new IPR policies per = RFCs:
> http://www.ietf.org/ietf/1id-guidelines.txt=

Done.

> - Abstract. Is not particularly = informative.  I don't think
> the 1st paragraph is necessary at all as it = only talks about
> things not related to this document.  I = don't find the 2nd
> paragraph helps much either.  I would = suggest replacing the
> 1st paragraph for the abstract with the 1st 2 = paragraphs from
> section 2, with the recommended rewording = suggested below,
> leaving the current 2nd paragraph as a 3rd = paragraph or final
> sentences of the abstract.

The abstract now reads:

"Filtering is a mechanism for defining the = preferred content to be delivered and for specifying the rules for when = the content should be delivered. 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.

The filtering mechanism is expected to be = particularly valuable and primarily applicable to users of mobile = wireless access devices."

> - Section 2. I would suggest clarifying the = first paragraph
> by augmenting the first paragraph by the = following change from:
> "  The filtering mechanism is = expected to be particularly valuable to
>    users of mobile wireless = access devices." 
> To:
> "  The filtering mechanism is = expected to be particularly
> valuable = and       primarily applicable to users = of mobile
> wireless access devices." 

Done.

> - Section 2. Related to the next comment on = section 7, I
> think the following should be added at the end = of that 2nd paragraph:
> " However, implementors need to be aware = of the computational
> burden on the source of the event = notification.  This is
> discussed further in section 7."

Done.

>  
> - Section 7. <Duplicate comment for = filter-funct>Certainly,
> limiting the number of occurrences to 20 would = help limit the
> DoS attacks, however, it seems that the = computational
> intensity of these filters in general should = really be
> highlighted much earlier in the document. I = would think this
> would be useful in the introduction in the 2nd = paragraph
> where the applicability of filtering relative = to specific
> devices is discussed.  It may well be a = good idea to limit
> this spec, to systems that must support such = devices, due to
> the computational intensity. Per my next = comment, this is an
> engineering tradeoff, so it's not just a = security issue, it's
> a system capacity and performance issue (for = the entity
> handling the filters)
> - Section 7. <Duplicate comment for = filter-funct> Related to
> the previous comment, I also think that 20 is = rather
> arbitrary and it would seem that 20 could = certainly be a good
> default recommendation, but that systems need = some
> engineereing to determine the optimum = value.  Do you all have
> concrete implementation experience that might = help shed some
> light on why 20 is a good number?  = Perhaps, this has been
> discussed and I just missed it.  But, this = would be useful
> information for folks to have.  I would = think it's possible
> that implementations could have problems at = lower levels or
> could have it set higher with no problem.  = Thus, more
> guidance in adjusting that number would be = helpful.

As above.

Thanks,
Hisham

>
>
> -----Original Message-----
> From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia= .com]
> Sent: Tuesday, July 13, 2004 2:42 AM
> To: rsparks@dynamicsoft.com; simple@ietf.org =
> Subject: [Simple] RE: WGLC: Event Filtering =
>
>
> There are very few days left for the WGLC of = these drafts.
> Please send your comments a.s.a.p. I've had = good comments for
> the filter-format draft but would appreciate = some more
> comments for filter-funct.
> Thanks,
> Hisham
> > -----Original Message-----
> > From: ext Robert Sparks [mailto:rsparks@dynamicsoft.com]
> > Sent: 30.June.2004 18:07
> > To: simple@ietf.org
> > Cc: Khartabil Hisham = (Nokia-TP-MSW/Helsinki)
> > Subject: WGLC: Event Filtering
> >
> >
> > This is a SIMPLE working group last call = for the following drafts:
> >
> > http://www.ietf.org/internet-drafts/draft-ietf-simple-= filter-f
> > ormat-01.txt
> > http://www.ietf.org/internet-drafts/draft-ietf-simple-= event-fi
> > lter-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 =
>

------_=_NextPart_001_01C469A6.CB7C2EDA-- --===============1206401671== 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 --===============1206401671==-- From simple-bounces@ietf.org Wed Jul 14 10:14: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 KAA18758 for ; Wed, 14 Jul 2004 10:14: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 1BkkWV-0005at-5H for simple-archive@ietf.org; Wed, 14 Jul 2004 10:14:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkkVU-0005Ev-00 for simple-archive@ietf.org; Wed, 14 Jul 2004 10:13:14 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BkkUS-0004cF-00; Wed, 14 Jul 2004 10:12:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BkkHi-00055w-If; Wed, 14 Jul 2004 09:58:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BkkAQ-0002l2-6b for simple@megatron.ietf.org; Wed, 14 Jul 2004 09:51: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 JAA17059 for ; Wed, 14 Jul 2004 09:51: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 1BkkAP-0005uw-Hp for simple@ietf.org; Wed, 14 Jul 2004 09:51:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bkk9d-0005b8-00 for simple@ietf.org; Wed, 14 Jul 2004 09:50:39 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1Bkk8R-0005HN-00 for simple@ietf.org; Wed, 14 Jul 2004 09:49:23 -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 i6EDnC819137; Wed, 14 Jul 2004 16:49:12 +0300 (EET DST) X-Scanned: Wed, 14 Jul 2004 16:49:08 +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 i6EDn8TX019105; Wed, 14 Jul 2004 16:49:08 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00piCczX; Wed, 14 Jul 2004 16:49:06 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 i6EDn5n25737; Wed, 14 Jul 2004 16:49: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); Wed, 14 Jul 2004 16:49:05 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [Simple] RE: WGLC: Event Filtering Date: Wed, 14 Jul 2004 16:49:04 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7023EEB2D@esebe019.ntc.nokia.com> Thread-Topic: [Simple] RE: WGLC: Event Filtering Thread-Index: AcRppvID4/S3CQ5UTVO5QGS8ebDqMAAAXDMw To: X-OriginalArrivalTime: 14 Jul 2004 13:49:05.0585 (UTC) FILETIME=[542D2210:01C469A9] 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="===============1176986339==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org 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_FONTCOLOR_BLUE,HTML_FONTCOLOR_RED,HTML_MESSAGE,NO_REAL_NAME autolearn=no version=2.60 This is a multi-part message in MIME format. --===============1176986339== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C469A9.53B992CD" This is a multi-part message in MIME format. ------_=_NextPart_001_01C469A9.53B992CD Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 -----Original Message----- From: ext Mary Barnes [mailto:mary.barnes@nortelnetworks.com] Sent: 14.July.2004 16:31 To: Khartabil Hisham (Nokia-TP-MSW/Helsinki) Cc: simple@ietf.org Subject: RE: [Simple] RE: WGLC: Event Filtering Hisham,=20 I've some suggestions for the wording below [MB]:=20 -----Original Message-----=20 From: hisham.khartabil@nokia.com [ mailto:hisham.khartabil@nokia.com]=20 Sent: Wednesday, July 14, 2004 4:01 AM=20 To: Barnes, Mary [NGC:B601:EXCH]=20 Cc: simple@ietf.org=20 Subject: RE: [Simple] RE: WGLC: Event Filtering=20 Hi Mary,=20 Thanks for your time and comments. Responses inline...=20 > -----Original Message-----=20 > From: Khartabil Hisham (Nokia-TP-MSW/Helsinki)=20 > Sent: 14.July.2004 11:31=20 > To: Khartabil Hisham (Nokia-TP-MSW/Helsinki)=20 > Subject: FW: [Simple] RE: WGLC: Event Filtering=20 >=20 >=20 >=20 > -----Original Message-----=20 > From: ext Mary Barnes [ mailto:mary.barnes@nortelnetworks.com]=20 > Sent: 14.July.2004 05:11=20 > To: Khartabil Hisham (Nokia-TP-MSW/Helsinki); rsparks@dynamicsoft.com=20 > Cc: simple@ietf.org=20 > Subject: RE: [Simple] RE: WGLC: Event Filtering=20 >=20 >=20 > I do have a few comments, mostly editorial/nits, but there is=20 > one general concern about the computational burden on the=20 > server that's generating these event filtered notifications,=20 > as I think that's not been very thoroughly addressed (except=20 > in the security section) and I think it needs to be=20 > highlighted upfront in these documents.=20 > Mary =20 > --------------------------------------------------------------=20 > --------=20 > I'll start with my comments on filter-funct. =20 > - Update the document to the new template per the updated=20 > guidelines reflecting new IPR policies per RFCs:=20 > http://www.ietf.org/ietf/1id-guidelines.txt=20 Done.=20 > - Abstract. Is not particularly informative. I don't think=20 > the 1st paragraph is necessary at all as it only talks about=20 > things not related to this document. I would remove that and=20 > update the 2nd paragraph by changing from:=20 > " This document describes the operations a subscriber=20 > performs in order=20 > to define filtering rules, how to handle responses to=20 > subscriptions=20 > carrying filtering rules, and how to handle notifications with=20 > filtering rules applied to them. The document also=20 > describes how the=20 > notifier behaves when receiving such filtering rules and how a=20 > notification is constructed."=20 > To something like:=20 > " This document describes the operations a subscriber=20 > performs in order=20 > to define filtering rules associated with event=20 > notification information.=20 > The handling of responses to subscriptions=20 > carrying filtering rules and the handling of notifications with=20 > filtering rules applied to them is described. The=20 > document also describes=20 > how the notifier behaves when receiving such=20 > filtering rules and how a notification is constructed."=20 Done.=20 > - Section 7. Certainly, limiting the number of occurrences to=20 > 20 would help limit the DoS attacks, however, it seems that=20 > the computational intensity of these filters in general=20 > should really be highlighted much earlier in the document. I=20 > would think this would be useful in the introduction in the=20 > 2nd paragraph where the applicability of filtering relative=20 > to specific devices is discussed. It may well be a good idea=20 > to limit this spec, to systems that must support such=20 > devices, due to the computational intensity. Per my next=20 > comment, this is an engineering tradeoff, so it's not just a=20 > security issue, it's a system capacity and performance issue=20 > (for the entity handling the filters)=20 I agree with you, but I struggled to write some meaningful text. Can you = provide me with text? I would really appreciate it. > - Section 7. Related to=20 > the previous comment, I also think that 20 is rather=20 > arbitrary and it would seem that 20 could certainly be a good=20 > default recommendation, but that systems need some=20 > engineereing to determine the optimum value. Do you all have=20 > concrete implementation experience that might help shed some=20 > light on why 20 is a good number? Perhaps, this has been=20 > discussed and I just missed it. But, this would be useful=20 > information for folks to have. I would think it's possible=20 > that implementations could have problems at lower levels or=20 > could have it set higher with no problem. Thus, more=20 > guidance in adjusting that number would be helpful.=20 The number was not according to any implementation experience, but was = rather according to guesstimates I made using the presence document as a = guide. It is very difficult for a client to estimate the processing = power of the server that is generating those notifications and therefore = we must recommend a number for the client to follow. Having said that, = you are right that some servers might be able to handle more than the = recommended number enabling the client to set more filters. [MB] So, perhaps, the simplest thing is to make it a bit more explicit = that this number is a bit arbitrary and YMMV. I would suggest changing = the wording in the last sentence of this section from: " To counter this, the server SHOULD only=20 allow filters with no more than about 20 occurrences of the ,=20 , and elements."=20 To:=20 " To counter this, the server MUST establish a limit on the number of =20 occurrences of the ,=20 , and elements allowed in the filters. =20 A default limit of 20 is RECOMMENDED, however, servers MAY raise or = lower=20 the limit depending upon their specific engineered capacity. "=20 [MB] I think the MUST is important in that first sentence as that's what = satisfies the security requirement to limit the DOS attack. =20 Ok done. I also added text to the introduction as you suggested for the = format draft: "However, implementers need to be aware of the computational burden on = the source of the event notification. This is discussed further in ." Thanks again, Hisham ------_=_NextPart_001_01C469A9.53B992CD Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Simple] RE: WGLC: Event Filtering
 
-----Original Message-----
From: ext Mary Barnes=20 [mailto:mary.barnes@nortelnetworks.com]
Sent: 14.July.2004=20 16:31
To: Khartabil Hisham = (Nokia-TP-MSW/Helsinki)
Cc:=20 simple@ietf.org
Subject: RE: [Simple] RE: WGLC: Event=20 Filtering

Hisham,

I've some suggestions for the wording below = [MB]:

-----Original Message-----
From:=20 hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.= com]=20
Sent: Wednesday, July 14, 2004 4:01 = AM=20
To: Barnes, Mary [NGC:B601:EXCH]
Cc:=20 simple@ietf.org
Subject: RE: [Simple] RE: = WGLC: Event=20 Filtering


Hi Mary,

Thanks for your time and comments. Responses = inline...=20

> -----Original Message-----
>=20 From: Khartabil Hisham (Nokia-TP-MSW/Helsinki)
>=20 Sent: 14.July.2004 11:31
> To: Khartabil = Hisham=20 (Nokia-TP-MSW/Helsinki)
> Subject: FW: = [Simple] RE:=20 WGLC: Event Filtering
>
>
>
>=20 -----Original Message-----
> From: ext = Mary Barnes=20 [mailto:mary.barnes@norteln= etworks.com]=20
> Sent: 14.July.2004 05:11
>=20 To: Khartabil Hisham (Nokia-TP-MSW/Helsinki); = rsparks@dynamicsoft.com=20
> Cc: simple@ietf.org
>=20 Subject: RE: [Simple] RE: WGLC: Event Filtering
>=20
>
> I do = have a few=20 comments, mostly editorial/nits, but there is
> one=20 general concern about the computational burden on the
> server that's generating these event filtered = notifications,=20
> as I think that's not been very = thoroughly=20 addressed (except
> in the security = section) and I=20 think it needs to be
> highlighted = upfront in these=20 documents.
> Mary 
>=20 --------------------------------------------------------------=20
> --------
> I'll = start with my=20 comments on filter-funct. 
> - = Update the=20 document to the new template per the updated
>=20 guidelines reflecting new IPR policies per RFCs:
>=20 http://www.ietf.org/ietf/1id-guidelines.txt =

Done.

> - Abstract. Is not particularly = informative.  I=20 don't think
> the 1st paragraph is = necessary at all=20 as it only talks about
> things not = related to this=20 document.  I would remove that and
> = update=20 the 2nd paragraph by changing from:
> = "  This=20 document describes the operations a subscriber
>=20 performs in order
>    to = define=20 filtering rules, how to handle responses to
>=20 subscriptions
>    = carrying=20 filtering rules, and how to handle notifications with
>    filtering rules applied to them.  = The=20 document also
> describes how the =
>    notifier behaves when receiving such = filtering=20 rules and how a
>    = notification is=20 constructed."
> To something like: =
> "  This document describes the operations a = subscriber=20
> performs in order
>    to define filtering rules associated = with event=20
> notification information. =
>    The handling of responses to = subscriptions=20
>    carrying filtering = rules and=20 the handling of notifications with
>    filtering rules applied to them is=20 described.  The
> document also = describes=20
>    how the notifier = behaves when=20 receiving such
>    = filtering rules=20 and how a notification is constructed."

Done.


> - Section 7. Certainly, limiting the number of=20 occurrences to
> 20 would help limit the = DoS=20 attacks, however, it seems that
> the = computational=20 intensity of these filters in general
> = should=20 really be highlighted much earlier in the document. I
> would think this would be useful in the introduction in = the=20
> 2nd paragraph where the applicability = of=20 filtering relative
> to specific devices = is=20 discussed.  It may well be a good idea
> to=20 limit this spec, to systems that must support such
> devices, due to the computational intensity. Per my next =
> comment, this is an engineering = tradeoff, so it's=20 not just a
> security issue, it's a = system capacity=20 and performance issue
> (for the entity = handling=20 the filters)

I agree with you, but I struggled to write some = meaningful=20 text. Can you provide me with text? I would really appreciate = it.

> - Section 7. <Duplicate comment for = filter-funct>=20 Related to
> the previous comment, I also = think=20 that 20 is rather
> arbitrary and it = would seem=20 that 20 could certainly be a good
> = default=20 recommendation, but that systems need some
>=20 engineereing to determine the optimum value.  Do you all have=20
> concrete implementation experience that = might=20 help shed some
> light on why 20 is a = good=20 number?  Perhaps, this has been
> = discussed=20 and I just missed it.  But, this would be useful
> information for folks to have.  I would think it's = possible=20
> that implementations could have = problems at lower=20 levels or
> could have it set higher with = no=20 problem.  Thus, more
> guidance in = adjusting=20 that number would be helpful.

The number was not according to any implementation = experience,=20 but was rather according to guesstimates I made using the presence = document as=20 a guide.  It is very difficult for a client to estimate the = processing=20 power of the server that is generating those notifications and = therefore we=20 must recommend a number for the client to follow. Having said that, = you are=20 right that some servers might be able to handle more than the = recommended=20 number enabling the client to set more filters.

[MB] So, perhaps, the simplest thing is to make it a = bit more=20 explicit that this number is a bit arbitrary and YMMV.  I would = suggest=20 changing the wording in the last sentence of this section = from:

"  To counter this, the server SHOULD = only=20
   allow filters with no more than about = 20=20 occurrences of the <what>,
  =20 <changed>, <added> and <removed> elements." =
To:
"  To counter this, the = server MUST=20 establish a limit on the number of 
  =20 occurrences of the <what>,
  =20 <changed>, <added> and <removed> elements allowed in = the=20 filters. 
   A default limit = of 20 is=20 RECOMMENDED, however, servers MAY raise or lower
   the limit depending upon their specific = engineered=20 capacity. "

[MB] I think the MUST is important in that first = sentence as=20 that's what satisfies the security requirement to limit the DOS=20 attack.   

Ok done. I also added text to the introduction as you = suggested=20 for the format draft:

"However, implementers need to be aware = of the=20 computational burden on the source of the event notification. This is=20 discussed further in <xref target=3D"security"/>."

Thanks again,

Hisham

------_=_NextPart_001_01C469A9.53B992CD-- --===============1176986339== 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 --===============1176986339==-- From simple-bounces@ietf.org Wed Jul 14 12: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 MAA26987 for ; Wed, 14 Jul 2004 12: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 1BkmhF-00054H-CP for simple-archive@ietf.org; Wed, 14 Jul 2004 12:33:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkmgH-0004jv-00 for simple-archive@ietf.org; Wed, 14 Jul 2004 12:32:30 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BkmfU-00049O-00; Wed, 14 Jul 2004 12:31:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BkmYd-0005nT-Ic; Wed, 14 Jul 2004 12:24:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BkmE5-0001ij-E3 for simple@megatron.ietf.org; Wed, 14 Jul 2004 12:03: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 MAA25530 for ; Wed, 14 Jul 2004 12:03: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 1BkmE4-00038z-Fj for simple@ietf.org; Wed, 14 Jul 2004 12:03:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkmDC-0002qd-00 for simple@ietf.org; Wed, 14 Jul 2004 12:02:27 -0400 Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx with esmtp (Exim 4.12) id 1BkmCa-0002Vl-00 for simple@ietf.org; Wed, 14 Jul 2004 12:01:48 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id i6EG19QM002256; Wed, 14 Jul 2004 11:01:10 -0500 (CDT) Received: from lucent.com (il0015vkg1.ih.lucent.com [135.185.173.147]) by ihmail.ih.lucent.com (8.11.7+Sun/EMS-1.5 sol2) id i6EG19d13423; Wed, 14 Jul 2004 11:01:09 -0500 (CDT) Message-ID: <40F558A8.3010905@lucent.com> Date: Wed, 14 Jul 2004 11:00:40 -0500 From: "Vijay K. Gurbani" Organization: Wireless Research and Development/Internet Software and Services User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7b) Gecko/20040421 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Simple] New I-D: presence data model and its relationship to our presence work References: <40F2EB3D.6080104@dynamicsoft.com> In-Reply-To: <40F2EB3D.6080104@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: IETF 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 Jonathan Rosenberg wrote: > Folks, > > I've just submitted an I-D on a presence data model for SIMPLE > > http://www.jdrosen.net/papers/draft-rosenberg-simple-presence-data-model-00.txt [...] > I'd like to try and see if we can agree on the following points: > > 1. the data model makes sense, > 2. the data model gives people the flexibility they need to represent > the systems they are interested in, > 3. the data model makes it sufficiently clear about what a tuple > is to create interoperable presence systems, > 4. the plan of attack makes sense given the previous 3 > > Comments in any of these four categories are most welcome. Jonathan: The data model outlined in the I-D is sound, and my vote would be that work should proceed as you outline. I had proposed a somewhat similar model back in Jan 2003 on the SIMPLE WG list. In that email thread (which is very long), I had argued for a user-centric presence model as opposed to the device-centric one that was being used. For reference, please see http://www1.ietf.org/mail-archive/web/simple/current/msg00061.html http://www1.ietf.org/mail-archive/web/simple/current/msg00080.html To me, a presentity has always corresponded to a human (or a group of humans, as in a call center); it is the presence state of the human we are trying to model, not the devices commanded by it. Unfortunately, in current usage, a presentity can be anything -- a VM server, a bot, a person, and so on. In think your model is closer to a presentity being a user. I also like your model with the three levels (presentity, service, devices). It is richer than the two level model (presentity, device) I had in mind (see http://www1.ietf.org/mail-archive/web/simple/current/msg00092.html). Your model also provides for the composition of more fine grained presence information. Some other points in the I-D: (1) You note (in Section 5) that "The terminlogy here is confusing: we talk about the presentity as a data element and the presentity as the entire thing being modeled..." What if we used the term "actor" for the entire thing being modeled? As in, "The entity attribute in the element is always present, and identifies the actor described in the document." Other terms: target, principal, addressee (2) In Section 2 (Definitions), the primary difference between "Privacy Filtering" and "Watcher Filtering" appears to be who is requesting the filter to be applied. The watcher is in the latter, and the presentity is in the former. While you explicitly mention the watcher when discussing "Watcher Filtering", maybe you should also mention the presentity when discussing "Privacy Filtering." (3) Page 9, s/offering a choice to the presentity/offering a choice to the watcher/ Thanks for compiling this. It distills in a clear fashion a lot of ideas we have discussed on the WG mailing list. - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Wireless Networks Group/Internet Software and Services Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jul 14 20:54: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 UAA19118 for ; Wed, 14 Jul 2004 20:54: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 1BkuVe-0006m1-Tf for simple-archive@ietf.org; Wed, 14 Jul 2004 20:54:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bktom-0007EY-00 for simple-archive@ietf.org; Wed, 14 Jul 2004 20:09:46 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BktGC-0000X9-02; Wed, 14 Jul 2004 19:34:00 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BktD4-0006px-Io; Wed, 14 Jul 2004 19: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 1BkqZB-0002zg-7o; Wed, 14 Jul 2004 16:41:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bkpe0-00085a-Ct; Wed, 14 Jul 2004 15:42: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 PAA11239; Wed, 14 Jul 2004 15:42:18 -0400 (EDT) Message-Id: <200407141942.PAA11239@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, 14 Jul 2004 15:42:18 -0400 Cc: simple@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-cipid-03.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 : CIPID: Contact Information in Presence Information Data Format Author(s) : H. Schulzrinne Filename : draft-ietf-simple-cipid-03.txt Pages : 10 Date : 2004-7-14 The Presence Information Data Format (PIDF) defines a basic XML format for presenting presence information for a presentity. The Contact Information for Presence Information Data Format (CIPID) is an extension that adds elements to PIDF that provide additional contact information about a presentity and its contacts, including references to address book entries and icons. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-cipid-03.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-cipid-03.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-cipid-03.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-7-14154305.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-cipid-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-cipid-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-7-14154305.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 Wed Jul 14 20:56: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 UAA19850 for ; Wed, 14 Jul 2004 20:56: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 1BkuYK-0007GN-Ha for simple-archive@ietf.org; Wed, 14 Jul 2004 20:56:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bktsc-00002D-00 for simple-archive@ietf.org; Wed, 14 Jul 2004 20:13:43 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BktGy-0000h8-00; Wed, 14 Jul 2004 19:34:48 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BktGx-0007AQ-8A; Wed, 14 Jul 2004 19:34:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BkqZE-00030E-J6; Wed, 14 Jul 2004 16:41:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BkpeW-0008Rt-Ax; Wed, 14 Jul 2004 15:42:52 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11292; Wed, 14 Jul 2004 15:42:50 -0400 (EDT) Message-Id: <200407141942.PAA11292@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, 14 Jul 2004 15:42:50 -0400 Cc: simple@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-future-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 : Timed Presence Extensions to the Presence Information Data Format(PIDF) to Indicate Presence Information for Past and Future Time Intervals Author(s) : H. Schulzrinne Filename : draft-ietf-simple-future-02.txt Pages : 14 Date : 2004-7-14 The timed presence extension adds elements to the Presence Information Data Format (PIDF) that allow a presentity to declare their status for a time interval fully in the future or the past. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-future-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-future-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-future-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-7-14154312.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-future-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-future-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-7-14154312.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 Jul 15 03:39: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 DAA00636 for ; Thu, 15 Jul 2004 03: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 1Bl0qI-0007fi-Ga for simple-archive@ietf.org; Thu, 15 Jul 2004 03:39:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bl0pJ-0007MD-00 for simple-archive@ietf.org; Thu, 15 Jul 2004 03:38:46 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bl0oG-0006k1-00; Thu, 15 Jul 2004 03:37:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bl0mC-00032E-Cw; Thu, 15 Jul 2004 03:35:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bl0ej-0000v0-63 for simple@megatron.ietf.org; Thu, 15 Jul 2004 03:27: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 DAA00343 for ; Thu, 15 Jul 2004 03:27:47 -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 1Bl0eg-0003xN-WC for simple@ietf.org; Thu, 15 Jul 2004 03:27:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bl0dk-0003e8-00 for simple@ietf.org; Thu, 15 Jul 2004 03:26:49 -0400 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1Bl0cq-0003Jx-00 for simple@ietf.org; Thu, 15 Jul 2004 03:25:52 -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 i6F7Poo23530; Thu, 15 Jul 2004 10:25:50 +0300 (EET DST) X-Scanned: Thu, 15 Jul 2004 10:25:23 +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 i6F7PNmq030743; Thu, 15 Jul 2004 10:25:23 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00mfLr5W; Thu, 15 Jul 2004 10:25:22 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 i6F7PLu04146; Thu, 15 Jul 2004 10:25:21 +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); Thu, 15 Jul 2004 10:25: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 I-D: presence data model and its relationship to our presence work Date: Thu, 15 Jul 2004 10:25:21 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF030C9D96@esebe004.ntc.nokia.com> Thread-Topic: [Simple] New I-D: presence data model and its relationship to our presence work Thread-Index: AcRobuS8/filhbLTTYuvhrO3P8ODHQBXzEgA To: , X-OriginalArrivalTime: 15 Jul 2004 07:25:21.0365 (UTC) FILETIME=[E315B850:01C46A3C] 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, >=20 > I'd like to try and see if we can agree on the following points: >=20 > 1. the data model makes sense, I agree with the model that is presented in the I-D. I also think that using tuples to represent services, device, and presentity is the best choice for us at this point. As you point in the draft modeling these as explicit XML element would be better choice but I think this should have happened already in PIDF and changing that is probably now too late. > 2. the data model gives people the flexibility they need to represent > the systems they are interested in, Yes > 3. the data model makes it sufficiently clear about what a=20 > tuple is to=20 > create interoperable presence systems, > 4. the plan of attack makes sense given the previous 3 About prescaps: I think the proposed changes to prescaps make sense. Placing elements directly below is better than having them as attributes. It might make sense to split the current scheme so that service elements would name own namespace and device elements their own. However, I think that class could actually be service element and not device element. I think it should possible to have both business and personal services in same device. About partial notify: If current model where all information is wrapped inside tuples is accepted then this works very well with partial notify drafts and there should be no need to change the current mechanism. One thing about Device ID: In section 3.3 it is stated that selection of device id left to the local policy of the device. Then in section 7.1 it is said that non-presence events can be correlated to particular device using device ID (for example information provided by cell phone network).=20 The identifier used to identify particular device is probably decided by the network or more specifically this information is somehow network specific (for example GSM uses IMEI codes). In order for this correlation to work I think device must know how particular network is going to identify the device and device must use that identifier when publishing presence information. This may be what draft currently says but I think this could be spelled out more clearly.=20 - Mikko =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 > _______________________________________________ > 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 Jul 15 04:00: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 EAA01623 for ; Thu, 15 Jul 2004 04: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 1Bl19v-0006Po-Vp for simple-archive@ietf.org; Thu, 15 Jul 2004 04:00:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bl18r-00065E-00 for simple-archive@ietf.org; Thu, 15 Jul 2004 03:58:57 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bl18B-0005gk-00; Thu, 15 Jul 2004 03:58:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bl10f-0007Jb-Oh; Thu, 15 Jul 2004 03:50:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bl0vK-0005s5-L1 for simple@megatron.ietf.org; Thu, 15 Jul 2004 03:44: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 DAA01008 for ; Thu, 15 Jul 2004 03:44: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 1Bl0vI-0001ap-0Q for simple@ietf.org; Thu, 15 Jul 2004 03:44:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bl0uU-0001GU-00 for simple@ietf.org; Thu, 15 Jul 2004 03:44:07 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1Bl0te-0000vy-00 for simple@ietf.org; Thu, 15 Jul 2004 03:43:14 -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 i6F7h9b22053; Thu, 15 Jul 2004 10:43:09 +0300 (EET DST) X-Scanned: Thu, 15 Jul 2004 10:43: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 i6F7h7Sd014181; Thu, 15 Jul 2004 10:43:07 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00hi3JI4; Thu, 15 Jul 2004 10:43:06 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 i6F7guu12345; Thu, 15 Jul 2004 10:42:56 +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); Thu, 15 Jul 2004 10:42:55 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [Simple] New I-D: presence data model and its relationship toour presence work Date: Thu, 15 Jul 2004 10:42:54 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7023EEB2F@esebe019.ntc.nokia.com> Thread-Topic: [Simple] New I-D: presence data model and its relationship toour presence work Thread-Index: AcRpwDMlcVyaYBt7RfWZAi0jN1wHTgAfwivQ To: , X-OriginalArrivalTime: 15 Jul 2004 07:42:55.0263 (UTC) FILETIME=[5741CAF0:01C46A3F] 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 Vijay K. Gurbani > Sent: 14.July.2004 19:01 > To: Jonathan Rosenberg > Cc: IETF SIMPLE WG > Subject: Re: [Simple] New I-D: presence data model and its=20 > relationship > toour presence work >=20 >=20 > Jonathan Rosenberg wrote: > > Folks, > >=20 > > I've just submitted an I-D on a presence data model for SIMPLE > >=20 > >=20 > http://www.jdrosen.net/papers/draft-rosenberg-simple-presence- > data-model-00.txt=20 > [...] > > I'd like to try and see if we can agree on the following points: > >=20 > > 1. the data model makes sense, > > 2. the data model gives people the flexibility they need to=20 > represent=20 > > the systems they are interested in, > > 3. the data model makes it sufficiently clear about what a tuple=20 > > is to create interoperable presence systems, > > 4. the plan of attack makes sense given the previous 3 > >=20 > > Comments in any of these four categories are most welcome. >=20 > Jonathan: >=20 > The data model outlined in the I-D is sound, and my vote > would be that work should proceed as you outline. >=20 > I had proposed a somewhat similar model back in Jan 2003 on the > SIMPLE WG list. In that email thread (which is very > long), I had argued for a user-centric presence model as > opposed to the device-centric one that was being used. For > reference, please see >=20 > http://www1.ietf.org/mail-archive/web/simple/current/msg00061.html > http://www1.ietf.org/mail-archive/web/simple/current/msg00080.html >=20 > To me, a presentity has always corresponded to a human (or a > group of humans, as in a call center); it is the presence > state of the human we are trying to model, not the devices > commanded by it. Unfortunately, in current usage, a > presentity can be anything -- a VM server, a bot, a person, > and so on. In think your model is closer to a presentity > being a user. >=20 > I also like your model with the three levels (presentity, > service, devices). It is richer than the two level model > (presentity, device) I had in mind (see > http://www1.ietf.org/mail-archive/web/simple/current/msg00092.html). > Your model also provides for the composition of more fine > grained presence information. >=20 > Some other points in the I-D: >=20 > (1) You note (in Section 5) that "The terminlogy here is > confusing: we talk about the presentity as a data element > and the presentity as the entire thing being modeled..." > What if we used the term "actor" for the entire thing being > modeled? As in, "The entity attribute in the > element is always present, and identifies the > actor described in the document." > Other terms: target, principal, addressee Principal gets my vote. It is defined in RFC2778/2779. /Hisham=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jul 15 09:30: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 JAA18831 for ; Thu, 15 Jul 2004 09:30: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 1Bl6JR-0004s8-Rt for simple-archive@ietf.org; Thu, 15 Jul 2004 09:30:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bl6IW-0004Yq-00 for simple-archive@ietf.org; Thu, 15 Jul 2004 09:29:17 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bl6Hm-0004AL-00; Thu, 15 Jul 2004 09: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 1Bl68E-0007xy-2Y; Thu, 15 Jul 2004 09:18:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bl660-0007IS-9S for simple@megatron.ietf.org; Thu, 15 Jul 2004 09:16: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 JAA17887 for ; Thu, 15 Jul 2004 09:16: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 1Bl65z-0000DT-L2 for simple@ietf.org; Thu, 15 Jul 2004 09:16:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bl64z-0007e2-00 for simple@ietf.org; Thu, 15 Jul 2004 09:15:18 -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 1Bl641-000709-00 for simple@ietf.org; Thu, 15 Jul 2004 09:14:17 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 15 Jul 2004 06:14:47 -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 i6FDDZ7u005892; Thu, 15 Jul 2004 06:13:36 -0700 (PDT) Received: from cisco.com ([64.101.175.55]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKD43918; Thu, 15 Jul 2004 09:13:34 -0400 (EDT) Message-ID: <40F409A5.2010004@cisco.com> Date: Tue, 13 Jul 2004 12:11: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: hisham.khartabil@nokia.com Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: simple@ietf.org Subject: [Simple] Re: WGLC: 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.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Hisham, The following are comments on the draft in response to your request for a review. Please take these with a grain of salt - I haven't been following the work (just for lack of time), and I don't know much about XPath either, on which this is based. Feel free to push back if these comments are misguided. Paul General comment: I don't know whether to join this argument or not, but I see that this document uses extensive normative language that is redundant with what the xml schema defines. I am somewhat inclined to agree that the xml should be authoritative and so text descriptions should use non-normative language for things covered by the schema. But I would be happy if this document follows whatever approach is generally considered the WG (or ietf) sanctioned approach. Section 3.2: Says may have uri or domain element. Says domain defines the domain of the resources the filter applies to. I think I know what that means, but it would be nice to be more explicit - namely that it selects resources whose uri is a sip uri with a matching domain part. Says: The URI attribute MAY also carry a domain. In this case, the filter applies to resources in that domain. I *think* this means to say "the may carry a domain", refering to the 'domain' attribute. But I am far from sure of this based on the text. *If* that is the case then it partially resolves my prior comment. But not fully, because it still doesn't define what "resources in that domain" means. I presume this is all about full or partial text matching against URIs. Given that different kinds of URIs have differing matching rules, this whole subject deserves more explanation. The description of the element *does* include normative text that isn't in the schema - namely that there must be at least one of and . While I don't know enough xml to say how, I suspect there is a way to describe this case in the schema. If so, it would be preferable to do so. (In English, I think you could define a type consisting of a sequence of 0 or 1 and 0 or 1 . Then you could define to contain 1 or more of that type.) Section 3.3: says: The element MAY contain one or more elements and one or more elements. However, the element MUST contain at least one element. When more than one element has been defined, the result is the union of all the elements. When more than one element has been defined, the result is the union of all the elements. This isn't entirely clear, especially when there are both and elements. It isn't really possible to define the meaning here because it isn't yet clear what "union" applies to. In reality I think you are operating on trees, not sets, so set operations don't really apply. Are suitable semantics for this available in XPath? I think the semantics are *reasonably* obvious intuitively, but the challenge is to define them normatively. Says: When identifying XML elements, the value may consist of two parts (similar to XPath [9]): the XML element selector and the condition (comparison and logical expressions). The syntax is defined in section Section 4 (see the definition of "selection".) The exact relationship to XPath is confusing. Is there a normative relationship? The reference indicates yes, but exactly what is drawn normatively from it, rather than being copied and subsetted? It appears, here and in later sections, that the syntax is being redefined, but the semantics is being referenced. This could be a lot clearer. Section 3.3.2 Not clear how interacts with the rule that must include other mandatory elements: - what if references something that is unconditionally mandatory? - what if references a mandatory sub-element of an optional element that is referenced by ? Says: The element MUST NOT be used if there are no element(s) in the same content filter. But an element is mandatory. So this is moot. Section 3.4.1: Says: The element is used to identify the XML element or attribute, from the package specific XML document, that must change, compared to the previous XML document, ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ How is 'previous XML document' defined? Is it replaced each time an update to the document is received? Or for a particular subscriber, is it the version last selected for delivery to the subscriber? Apparently the element needn't contain any of changed-from, changed-to, or changed-by. I suppose that means it just tests for changes of any sort. Is that what is intended? In that case, what constitutes a change? Must the value be updated with a *different* value, or simply be updated, possibly with an identical value? For without attributes, or with changed-from or changed-to, how is the comparison done? Is it literal string comparison, or type specific comparison? (If type specific, what if the type is unknown to the server? (Consider a case where an element containing a URI is changed from "sip:foo@bar" to "sip:foo@BAR".) Is there a constraint on the type of element that changed-by is applied to? Must it be decimal? Must the change be in a particular direction? Section 5.4: I find this example inconsistent with my understanding of the uri attribute. I thought it acted as a restriction on what the filter applies to. In this case I would expect that the subscription itself would have been addressed to sip:buddylist@domain.com, and the uri parameter used only to restrict a filter to a particular buddy in the list. Section 5.6: I have the same problem here as in 5.4, but it is even clearer, because the uri attribute is sued both ways. AFAIK there never is a presence document for sip:buddies@domain.com - only ones for each of the buddies. So the uri attribute shouldn't match anything. Section 6 (schema): The attribute 'domain' of is of type 'anyURI'. While I am an xml neophite this seems wrong. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jul 15 09:43: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 JAA19630 for ; Thu, 15 Jul 2004 09:43: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 1Bl6W3-0001Nm-Jb for simple-archive@ietf.org; Thu, 15 Jul 2004 09:43:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bl6V8-000149-00 for simple-archive@ietf.org; Thu, 15 Jul 2004 09:42:18 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bl6Uc-0000jB-00; Thu, 15 Jul 2004 09: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 1Bl6Ly-0002mR-Gg; Thu, 15 Jul 2004 09:32:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bl6GU-0001gE-CN for simple@megatron.ietf.org; Thu, 15 Jul 2004 09:27: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 JAA18677 for ; Thu, 15 Jul 2004 09:27: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 1Bl6GT-0003uQ-JT for simple@ietf.org; Thu, 15 Jul 2004 09:27:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bl6Fg-0003bv-00 for simple@ietf.org; Thu, 15 Jul 2004 09:26:21 -0400 Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx with esmtp (Exim 4.12) id 1Bl6Et-0003Ef-00 for simple@ietf.org; Thu, 15 Jul 2004 09:25:31 -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 i6FDPBou005891; Thu, 15 Jul 2004 08:25:11 -0500 (CDT) Received: by eamrcnt750.exu.ericsson.se with Internet Mail Service (5.5.2657.72) id <3J9VGG5L>; Thu, 15 Jul 2004 08:23:46 -0500 Message-ID: From: "George Foti (QA/EMC)" To: "'hisham.khartabil@nokia.com'" , simple@ietf.org Date: Thu, 15 Jul 2004 08:24:18 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Subject: [Simple] RE: Comments Event Filter Function -01 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org 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 Comments inline Hisham /gf > Removing a filter is done in one way. Replacing a filter is > done in another way. Two filters to the same user is an > error. Having those 2 filters appear in the same request or > in separate requests does not make a difference. We shouldn't > overload the functionality. If something is clearly an error > (trying to replace a filter in a different way than is > specified), then the client must be told about it. > I dont get it. To modify an existing filter for a resource. I have 2 possible alternatives here : 1) Use the same filterid with a new content. 2) Use a new filterid that implicitly removes the old filter for that user and replace it with the new filter. That respects the rule of having one filter per resource. You seem to say that 2 is an error, and we should do that in 2 steps, first an explict remove, then add the new filter. Can U elaborate on the rationale for that. Does it causes confusion for other cases > > > > Next, in the third paragraph, you have the example on > > myboddies@mydomain.com & bob@mydomain.com, it seems to me > > that the domain must be different for the RLS to extract the > > filter and propagate it, so Bob should have a different > > domain for the statement to apply. > > The example is correct. A filter is not propagated if Bob was > not part of the list, but is part of domain.com. Your statement is true but thats not what the text in the draft is saying. If Bob was on the list and part of the domain, I dont see where to would you propagate the filter. I had one comment I forgot to mention. In section 5.2.1 you talk about mismatch between the R-RI in SUBSCRIBE and URI in the filter. It would help to expand what mismatch means. I know you cover it in several places in the document. Optionally refer to the section where one can find the pertinent text. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jul 15 10: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 KAA24714 for ; Thu, 15 Jul 2004 10: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 1Bl7TH-0005CP-AP for simple-archive@ietf.org; Thu, 15 Jul 2004 10:44:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bl7S6-0004mo-00 for simple-archive@ietf.org; Thu, 15 Jul 2004 10:43:15 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bl7Qu-00049J-00; Thu, 15 Jul 2004 10:42:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bl7Ke-0000ry-EG; Thu, 15 Jul 2004 10:35:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bl79u-0004ys-4J for simple@megatron.ietf.org; Thu, 15 Jul 2004 10:24: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 KAA23270 for ; Thu, 15 Jul 2004 10:24: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 1Bl79t-0006YG-8q for simple@ietf.org; Thu, 15 Jul 2004 10:24:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bl78t-0006Dt-00 for simple@ietf.org; Thu, 15 Jul 2004 10:23:24 -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 1Bl781-0005eQ-00 for simple@ietf.org; Thu, 15 Jul 2004 10:22:29 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 15 Jul 2004 07:22:50 +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 i6FEKmZl023836; Thu, 15 Jul 2004 07:20:51 -0700 (PDT) Received: from cisco.com ([64.101.175.55]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKD49117; Thu, 15 Jul 2004 10:20:47 -0400 (EDT) Message-ID: <40F692BE.6010605@cisco.com> Date: Thu, 15 Jul 2004 10:20:46 -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 Kyzivat References: <40F409A5.2010004@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: simple@ietf.org Subject: [Simple] Re: WGLC: 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.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Revision to my comments: I just read draft-ietf-simple-event-filter-funct-01, and based on that I take back the comments below. The semantics are well defined in the latter document. Paul Paul Kyzivat wrote: > > Section 5.4: > > I find this example inconsistent with my understanding of the uri > attribute. I thought it acted as a restriction on what the filter > applies to. In this case I would expect that the subscription itself > would have been addressed to sip:buddylist@domain.com, and the uri > parameter used only to restrict a filter to a particular buddy in the list. > > Section 5.6: > > I have the same problem here as in 5.4, but it is even clearer, because > the uri attribute is sued both ways. AFAIK there never is a presence > document for sip:buddies@domain.com - only ones for each of the buddies. > So the uri attribute shouldn't match anything. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jul 16 04:16: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 EAA14017 for ; Fri, 16 Jul 2004 04:16: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 1BlNsy-0007TG-0V for simple-archive@ietf.org; Fri, 16 Jul 2004 04:16:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BlNru-00078I-00 for simple-archive@ietf.org; Fri, 16 Jul 2004 04:14:59 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BlNrH-0006lq-00; Fri, 16 Jul 2004 04:14:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BlNk3-00064o-JR; Fri, 16 Jul 2004 04:06:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BlNfS-0005PM-Vi for simple@megatron.ietf.org; Fri, 16 Jul 2004 04:02:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13317 for ; Fri, 16 Jul 2004 04:02:04 -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 1BlNfQ-0002eO-0I for simple@ietf.org; Fri, 16 Jul 2004 04:02:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BlNeU-0002JD-00 for simple@ietf.org; Fri, 16 Jul 2004 04:01:07 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1BlNds-0001xk-00 for simple@ietf.org; Fri, 16 Jul 2004 04:00:29 -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 i6G80Sb10430; Fri, 16 Jul 2004 11:00:28 +0300 (EET DST) X-Scanned: Fri, 16 Jul 2004 11:00:25 +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 i6G80PlW029486; Fri, 16 Jul 2004 11:00:25 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00ToY3Tq; Fri, 16 Jul 2004 11:00: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 i6G80Nn27927; Fri, 16 Jul 2004 11:00:23 +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, 16 Jul 2004 11:00:18 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Fri, 16 Jul 2004 11:00:18 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7023EEB36@esebe019.ntc.nokia.com> Thread-Topic: Comments Event Filter Function -01 Thread-Index: AcRqb1DX92j8TwsARqi1RWamjwLtjwAl35Ag To: , X-OriginalArrivalTime: 16 Jul 2004 08:00:18.0926 (UTC) FILETIME=[EFBDE0E0:01C46B0A] Content-Transfer-Encoding: quoted-printable Subject: [Simple] RE: Comments Event Filter Function -01 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org 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 George Foti (QA/EMC) [mailto:george.foti@ericsson.com] > Sent: 15.July.2004 16:24 > To: Khartabil Hisham (Nokia-TP-MSW/Helsinki); simple@ietf.org > Subject: RE: Comments Event Filter Function -01 >=20 >=20 > Comments inline Hisham > /gf > > Removing a filter is done in one way. Replacing a filter is=20 > > done in another way. Two filters to the same user is an=20 > > error. Having those 2 filters appear in the same request or=20 > > in separate requests does not make a difference. We shouldn't=20 > > overload the functionality. If something is clearly an error=20 > > (trying to replace a filter in a different way than is=20 > > specified), then the client must be told about it. > >=20 > I dont get it. > To modify an existing filter for a resource. I have 2=20 > possible alternatives here : > 1) Use the same filterid with a new content. > 2) Use a new filterid that implicitly removes the old filter=20 > for that user and replace it with the new filter. That=20 > respects the rule of having one filter per resource. >=20 > You seem to say that 2 is an error, and we should do that in=20 > 2 steps, first an explict remove, then add the new filter. What you are asking for is a filter replacement. For this, it is defined = that the same filter-id is used with new filter contents. It's just 1 = step. Adding new filters is done using new filter-ids. If this new filter has = a URI that conflicts with another filter URI, then it is an error. So: 1. Removing is done using the remove attribute 2. Replacing/modifying is done by re-using the filter-id 3. Adding is done by creating new filter with new filter id > Can U elaborate on the rationale for that. > Does it causes confusion for other cases > =20 > > >=20 > > > Next, in the third paragraph, you have the example on=20 > > > myboddies@mydomain.com & bob@mydomain.com, it seems to me=20 > > > that the domain must be different for the RLS to extract the=20 > > > filter and propagate it, so Bob should have a different=20 > > > domain for the statement to apply.=20 > >=20 > > The example is correct. A filter is not propagated if Bob was=20 > > not part of the list, but is part of domain.com. > =20 > Your statement is true but thats not what the text in the=20 > draft is saying. There is text for that: "There may be situations where the filters were not propagated because they address a URI that in under the adminstrative domain of the RLS, but are not part of the resource list that the subscription was addressed to. In this case, it is the RLS responsibility to make sure than those filters are applied to notifications issued." I'll make this text more normative. > If Bob was on the list and part of the domain, I dont see=20 > where to would you propagate the filter. You would propagate it to Bob's presence server. The RLS is not the PS = (although they can be co-located). >=20 >=20 >=20 > I had one comment I forgot to mention. > In section 5.2.1 you talk about mismatch between the R-RI in=20 > SUBSCRIBE and URI in the filter. > It would help to expand what mismatch means. > I know you cover it in several places in the document. > Optionally refer to the section where one can find the pertinent text. >=20 >=20 Added some text about this in all sections that imply URI matching is = needed. Thanks, Hisham _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jul 16 06:00: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 GAA19130 for ; Fri, 16 Jul 2004 06:00: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 1BlPVv-0002tK-95 for simple-archive@ietf.org; Fri, 16 Jul 2004 06:00:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BlPUe-0002X8-00 for simple-archive@ietf.org; Fri, 16 Jul 2004 05:59:05 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BlPTv-00029q-00; Fri, 16 Jul 2004 05:58:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BlPQL-0002Bp-8K; Fri, 16 Jul 2004 05:54:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BlPIx-0001a5-FL for simple@megatron.ietf.org; Fri, 16 Jul 2004 05:46: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 FAA18640 for ; Fri, 16 Jul 2004 05:46: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 1BlPIu-0006UZ-Rt for simple@ietf.org; Fri, 16 Jul 2004 05:46:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BlPI0-0006BF-00 for simple@ietf.org; Fri, 16 Jul 2004 05:46:02 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BlPHF-0005rS-00 for simple@ietf.org; Fri, 16 Jul 2004 05:45:13 -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 i6G9j8s02256; Fri, 16 Jul 2004 12:45:08 +0300 (EET DST) X-Scanned: Fri, 16 Jul 2004 12:44: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 i6G9inlN002754; Fri, 16 Jul 2004 12:44:50 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 008TGUN6; Fri, 16 Jul 2004 12:44:42 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 i6G9iYn21961; Fri, 16 Jul 2004 12:44:34 +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); Fri, 16 Jul 2004 12:44:03 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 16 Jul 2004 12:44:03 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Fri, 16 Jul 2004 12:44:02 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7023EEB37@esebe019.ntc.nokia.com> Thread-Topic: WGLC: draft-ietf-simple-filter-format-01.txt Thread-Index: AcRqbbqHWY3SAmXwTCy/vZM4KgqGwgAnXCTA To: X-OriginalArrivalTime: 16 Jul 2004 09:44:03.0454 (UTC) FILETIME=[6DD979E0:01C46B19] Content-Transfer-Encoding: quoted-printable Cc: simple@ietf.org Subject: [Simple] RE: WGLC: 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.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Paul, Thanks for taking the time to review the drafts. Responses inline.. > -----Original Message----- > From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: 13.July.2004 19:11 > To: Khartabil Hisham (Nokia-TP-MSW/Helsinki) > Cc: simple@ietf.org > Subject: Re: WGLC: draft-ietf-simple-filter-format-01.txt >=20 >=20 > Hisham, >=20 > The following are comments on the draft in response to your=20 > request for=20 > a review. Please take these with a grain of salt - I haven't been=20 > following the work (just for lack of time), and I don't know=20 > much about=20 > XPath either, on which this is based. Feel free to push back if these=20 > comments are misguided. >=20 > Paul >=20 > General comment: >=20 > I don't know whether to join this argument or not, but I see=20 > that this=20 > document uses extensive normative language that is redundant=20 > with what=20 > the xml schema defines. I am somewhat inclined to agree that the xml=20 > should be authoritative and so text descriptions should use=20 > non-normative language for things covered by the schema. But=20 > I would be=20 > happy if this document follows whatever approach is generally=20 > considered=20 > the WG (or ietf) sanctioned approach. In the working version that I have now, I have removed all the normative = text (the MUSTs and SHOULDs). I believe there was consensust to have = informative text. >=20 > Section 3.2: >=20 > Says may have uri or domain element. Says domain defines the=20 > domain of=20 > the resources the filter applies to. I think I know what that=20 > means, but=20 > it would be nice to be more explicit - namely that it selects=20 > resources=20 > whose uri is a sip uri with a matching domain part. >=20 > Says: > The URI attribute MAY also carry a domain. In this case,=20 > the filter > applies to resources in that domain. >=20 > I *think* this means to say "the may carry a=20 > domain", refering=20 > to the 'domain' attribute. But I am far from sure of this=20 > based on the=20 > text. Good catch. This text is old. In an earlier version, there was no = 'domain' attribute. I'll clarify. Changed to "The 'domain' attribute = carries a domain. In this case, the filter applies to resources who's = URI has a domain part matching that domain." > *If* that is the case then it partially resolves my=20 > prior comment.=20 > But not fully, because it still doesn't define what=20 > "resources in that=20 > domain" means. I presume this is all about full or partial=20 > text matching=20 > against URIs. Given that different kinds of URIs have=20 > differing matching=20 > rules, this whole subject deserves more explanation. Added some text about this issue. >=20 > The description of the element *does* include normative text=20 > that isn't in the schema - namely that there must be at least one of=20 > and . While I don't know enough xml to say how, I=20 > suspect there is a way to describe this case in the schema. If so, it=20 > would be preferable to do so. (In English, I think you could define a=20 > type consisting of a sequence of 0 or 1 and 0 or 1 .=20 > Then you could define to contain 1 or more of that type.) The problem here is that a maximum of only one element is = allowed, while element occurence is unbounded. I don't think = this restriction can be done with the schema. >=20 > Section 3.3: >=20 > says: > The element MAY contain one or more =20 > elements and one > or more elements. However, the element=20 > MUST contain > at least one element. When more than one=20 > element > has been defined, the result is the union of all the > elements. When more than one element has been=20 > defined, the > result is the union of all the elements. >=20 > This isn't entirely clear, especially when there are both=20 > and=20 > elements. It isn't really possible to define the=20 > meaning here=20 > because it isn't yet clear what "union" applies to. In=20 > reality I think=20 > you are operating on trees, not sets, so set operations don't really=20 > apply. Are suitable semantics for this available in XPath? I=20 > think the=20 > semantics are *reasonably* obvious intuitively, but the=20 > challenge is to=20 > define them normatively. I removed the use of the word "union". The text now reads: The <what> element MAY contain one or more <include> = elements and one or more <exclude> elements. When more than one = <include> element has been defined, the results are additive. I.e. = each <include> element contents adds an element or attribute to = the resulting XML document. When more than one <exclude> element = has been defined, each value it each <exclude> element depletes = the contents of the resulting XML document. >=20 > Says: > When identifying XML elements, the value may consist of two parts > (similar to XPath [9]): the XML element selector and the condition > (comparison and logical expressions). The syntax is defined in > section Section 4 (see the definition of "selection".) >=20 > The exact relationship to XPath is confusing. Is there a normative=20 > relationship? The reference indicates yes, but exactly what is drawn=20 > normatively from it, rather than being copied and subsetted?=20 > It appears,=20 > here and in later sections, that the syntax is being=20 > redefined, but the=20 > semantics is being referenced. This could be a lot clearer. Section 4 has more about this issue. I moved any text talking about = xpath to that section, with more clarifications. >=20 > Section 3.3.2 >=20 > Not clear how interacts with the rule that must=20 > include other mandatory elements: >=20 > - what if references something that is=20 > unconditionally mandatory? >=20 > - what if references a mandatory sub-element of an optional=20 > element that is referenced by ? I had noticed the lack of text on these these issues already and added = some text. >=20 > Says: > The element MUST NOT be used if there are no > element(s) in the same content filter. >=20 > But an element is mandatory. So this is moot. I recently received a comment that it might be useful for to = appear alone without . >=20 > Section 3.4.1: >=20 > Says: > The element is used to identify the XML element or > attribute, from the package specific XML document, that=20 > must change, > compared to the previous XML document, > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >=20 > How is 'previous XML document' defined? Is it replaced each time an=20 > update to the document is received? Or for a particular=20 > subscriber, is=20 > it the version last selected for delivery to the subscriber? it is the version last selected for delivery to the subscruber before = the filter was applied. I say "before the filter was applied" because = the include and exclude expression might have caused the referenced = element not to be delivered. I'll clarify. >=20 > Apparently the element needn't contain any of changed-from,=20 > changed-to, or changed-by. I suppose that means it just tests for=20 > changes of any sort. Is that what is intended? In that case, what=20 > constitutes a change? Must the value be updated with a *different*=20 > value, or simply be updated, possibly with an identical value? Well, updated with the same value is not really a change in value, is = it? I'll add text. >=20 > For without attributes, or with changed-from or changed-to,=20 > how is the comparison done? Is it literal string comparison, or type=20 > specific comparison? (If type specific, what if the type is=20 > unknown to=20 > the server? (Consider a case where an element containing a URI is=20 > changed from "sip:foo@bar" to "sip:foo@BAR".) For simplicity, lets make it a string comparison. >=20 > Is there a constraint on the type of element that changed-by=20 > is applied=20 > to? Must it be decimal? Must the change be in a particular direction? Any numberical value. It doesn't necessarily have to be decimal. A = change in any direction is a change. I'll add text. >=20 > Section 5.4: >=20 > I find this example inconsistent with my understanding of the uri=20 > attribute. I thought it acted as a restriction on what the filter=20 > applies to. In this case I would expect that the subscription itself=20 > would have been addressed to sip:buddylist@domain.com, and the uri=20 > parameter used only to restrict a filter to a particular=20 > buddy in the list. >=20 > Section 5.6: >=20 > I have the same problem here as in 5.4, but it is even=20 > clearer, because=20 > the uri attribute is sued both ways. AFAIK there never is a presence=20 > document for sip:buddies@domain.com - only ones for each of=20 > the buddies.=20 > So the uri attribute shouldn't match anything. >=20 > Section 6 (schema): >=20 > The attribute 'domain' of is of type 'anyURI'. While I am an=20 > xml neophite this seems wrong. >=20 Changed to string. Thanks, Hisham >=20 >=20 >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jul 16 07:29: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 HAA23443 for ; Fri, 16 Jul 2004 07:29: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 1BlQuZ-0000c2-Qv for simple-archive@ietf.org; Fri, 16 Jul 2004 07:29:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BlQtZ-0000Ib-00 for simple-archive@ietf.org; Fri, 16 Jul 2004 07:28:54 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BlQsf-0007Uf-00; Fri, 16 Jul 2004 07:27:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BlQpO-0004Ko-FS; Fri, 16 Jul 2004 07:24:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BlQmw-00044H-As for simple@megatron.ietf.org; Fri, 16 Jul 2004 07:22: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 HAA23123 for ; Fri, 16 Jul 2004 07:22: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 1BlQmt-0005rR-Tj for simple@ietf.org; Fri, 16 Jul 2004 07:21:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BlQlt-0005XP-00 for simple@ietf.org; Fri, 16 Jul 2004 07:20:58 -0400 Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx with esmtp (Exim 4.12) id 1BlQkv-0004vO-00 for simple@ietf.org; Fri, 16 Jul 2004 07:19:57 -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 i6GBJdou004359; Fri, 16 Jul 2004 06:19:39 -0500 (CDT) Received: by eamrcnt750.exu.ericsson.se with Internet Mail Service (5.5.2657.72) id <3J9VH8N0>; Fri, 16 Jul 2004 06:18:13 -0500 Message-ID: From: "George Foti (QA/EMC)" To: "'hisham.khartabil@nokia.com'" , simple@ietf.org Date: Fri, 16 Jul 2004 06:18:31 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Subject: [Simple] RE: Comments Event Filter Function -01 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org 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 Hisham you wrote: > You would propagate it to Bob's presence server. The RLS is > not the PS (although they can be co-located). > Co-location. Thats what I had in mind all along. Thanks for the clarification. Rgds/gf > -----Original Message----- > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > Sent: Friday, July 16, 2004 4:00 AM > To: George Foti (QA/EMC); simple@ietf.org > Subject: RE: Comments Event Filter Function -01 > > > > > > -----Original Message----- > > From: ext George Foti (QA/EMC) [mailto:george.foti@ericsson.com] > > Sent: 15.July.2004 16:24 > > To: Khartabil Hisham (Nokia-TP-MSW/Helsinki); simple@ietf.org > > Subject: RE: Comments Event Filter Function -01 > > > > > > Comments inline Hisham > > /gf > > > Removing a filter is done in one way. Replacing a filter is > > > done in another way. Two filters to the same user is an > > > error. Having those 2 filters appear in the same request or > > > in separate requests does not make a difference. We shouldn't > > > overload the functionality. If something is clearly an error > > > (trying to replace a filter in a different way than is > > > specified), then the client must be told about it. > > > > > I dont get it. > > To modify an existing filter for a resource. I have 2 > > possible alternatives here : > > 1) Use the same filterid with a new content. > > 2) Use a new filterid that implicitly removes the old filter > > for that user and replace it with the new filter. That > > respects the rule of having one filter per resource. > > > > You seem to say that 2 is an error, and we should do that in > > 2 steps, first an explict remove, then add the new filter. > > What you are asking for is a filter replacement. For this, it > is defined that the same filter-id is used with new filter > contents. It's just 1 step. > > Adding new filters is done using new filter-ids. If this new > filter has a URI that conflicts with another filter URI, then > it is an error. > > So: > > 1. Removing is done using the remove attribute > 2. Replacing/modifying is done by re-using the filter-id > 3. Adding is done by creating new filter with new filter id > > > Can U elaborate on the rationale for that. > > Does it causes confusion for other cases > > > > > > > > > > Next, in the third paragraph, you have the example on > > > > myboddies@mydomain.com & bob@mydomain.com, it seems to me > > > > that the domain must be different for the RLS to extract the > > > > filter and propagate it, so Bob should have a different > > > > domain for the statement to apply. > > > > > > The example is correct. A filter is not propagated if Bob was > > > not part of the list, but is part of domain.com. > > > > Your statement is true but thats not what the text in the > > draft is saying. > > There is text for that: > > "There may be > situations where the filters were not propagated because > they address > a URI that in under the adminstrative domain of the RLS, > but are not > part of the resource list that the subscription was > addressed to. In > this case, it is the RLS responsibility to make sure than those > filters are applied to notifications issued." > > I'll make this text more normative. > > > If Bob was on the list and part of the domain, I dont see > > where to would you propagate the filter. > > You would propagate it to Bob's presence server. The RLS is > not the PS (although they can be co-located). > > > > > > > > > I had one comment I forgot to mention. > > In section 5.2.1 you talk about mismatch between the R-RI in > > SUBSCRIBE and URI in the filter. > > It would help to expand what mismatch means. > > I know you cover it in several places in the document. > > Optionally refer to the section where one can find the > pertinent text. > > > > > > Added some text about this in all sections that imply URI > matching is needed. > > Thanks, > Hisham > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jul 16 13:50: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 NAA19053 for ; Fri, 16 Jul 2004 13: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 1BlWqh-0001xA-E9 for simple-archive@ietf.org; Fri, 16 Jul 2004 13:50:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BlWph-0001cr-00 for simple-archive@ietf.org; Fri, 16 Jul 2004 13:49:18 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BlWop-0000yd-00; Fri, 16 Jul 2004 13:48:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BlWkK-0003mf-5I; Fri, 16 Jul 2004 13:43:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BlWXI-00017n-P8 for simple@megatron.ietf.org; Fri, 16 Jul 2004 13:30: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 NAA17571 for ; Fri, 16 Jul 2004 13:30: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 1BlWXF-0002ob-S2 for simple@ietf.org; Fri, 16 Jul 2004 13:30:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BlWWO-0002VK-00 for simple@ietf.org; Fri, 16 Jul 2004 13:29:21 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BlWVd-0001yG-00 for simple@ietf.org; Fri, 16 Jul 2004 13:28:33 -0400 Received: from dynamicsoft.com ([63.113.46.141]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i6GHSOGr003301 for ; Fri, 16 Jul 2004 13:28:25 -0400 (EDT) Message-ID: <40F81025.6090901@dynamicsoft.com> Date: Fri, 16 Jul 2004 13:28:05 -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] Updated XCAP spec now available and ready for wglc! X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org 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 just submitted an updated to the XCAP core specification. Until it appears in the archives, you can pick up a copy at: http://www.jdrosen.net/papers/draft-ietf-simple-xcap-03.txt This is a fairly major update, mostly in terms of document organization and clarity, which I think is vastly improved. Here are the resolutions to the various open issues, which are incorporated into this version: ISSUE 1: schema awareness - when it is needed? Only for validation ISSUE 2: positional insertions? They have been added ISSUE 3: PUT vs. POST Continue to use PUT. Server never modifies the document submitted via PUT. Rather, the client picks a URI, and if its not unique, the server rejects the request and suggests unique alternatives in the body of the error response. ISSUE 4: Document/element separators Using double tilde (~~) ISSUE 5: Multiple Insertions deferred to another document, to be debated separately from core xcap ISSUE 6: Selection by text element value decided not to include this feature ISSUE 7: Unique steps at each hop Uniqueness is required at each hop ISSUE 8: Etag scopes Etags are scoped to a document ISSUE 9a: Supported namespace discovery Added a capability application usage, in which the supported namespaces of the server can be listed ISSUE 9b: Etags useless for insert Documented this problem, suggest workarounds As such, there are no open issues that I am aware of. As a result, I believe this document is done, and now ready for working group last call (yay!). There are two TODOs in the document, which are questions I need assistance in answering. Once answered, text can be incorporated into the document. There are many changes in addition to the above issue resolutions. Many are clarifications, fixes, and other things discussed on the list and at the interim. The following is a summary of the main ones: * To fetch a document, -02 recommended using the If-Match header field to do a conditional get. This should have been If-None-Match, and has been corrected in this revision. * Added definitions section * Terminology cleanup. A key term here is "XCAP resource" which refers to a document, element, or attribute which follows XCAP naming and data validation constraints. * Beefed up the section on what an application usage has to specify when it defines its data validation rules. The section discusses XML schema, uniqueness constraints, URI constraints and referential integrity. XCAP now requires each application usage to explicitly call out uniqueness constraints, even if those constraints are also specified in the schema using the tag. * Explicitly say that XCAP servers are not responsible for referential integrity. This is the responsibility of the client. XCAP is not an RDBMS! * renamed "Data Interdependencies" to "Resource Interdependencies". This is commensurate with the change that the server doesnt update documents PUT to the server (XCAP issue 3). Indeed, this aspect of the application usage is talking about something quite different now. When a client PUTs a resource, the server changes the state of OTHER resources. Most interdependencies are expressed in schema; a PUT to an element changes the contents of all of the child elements and attributes. However, in some cases, there are inter-dependencies across docs, and the app usage needs to specify that. We have two examples so far - the index document created by the server in the list usage, and Miguel's directory usage. * terminology: XCAP User ID (XUI). This is the "username" present in the xcap URI. It need not be the actual "username". * removed "mandatory-ns", which was our approach for allowing the client to mandate that a server understand a particular namespace before processing a document. Instead, there is an application usage that contains a document that lists the server's capabilities, which includes namespaces, application usages and xcap extensions. [ISSUE 9] * clarified that a server can have multiple root services URIs, and that there is never interactions or information carryover across root services * clarified that the xcap root services URI (now called Xcap root URI) is a valid HTTP URL but doesnt actually refer to any existing resource * added usage of the ~~ path segment to separate the document and node selectors * added rules for escape coding. Note that the left bracket, right bracket and double quote need to be escaped. Also, since XML elements, attributes, and attribute values can contain unicode characters, any unicode characters outside of US-ASCII need to be escape coded. I lifted some text from rfc2396bis that documents how this escape coding is done. * comparison rules for the element and attribute names in the node selector against those in the document have been aligned with the XPath rules. In particular, the namespace bindings used to resolve namespace prefixes in the node selector are taken from those in scope for the context element. Also, if the element name in the node selector has no prefix, its namespace URI is null, *NOT* the default namespace of the context element. This is accoring to XPath. However, I can't see how this can work. Need to follow up on that with an Xpath expert. * The detailed conflict report document has two new errors - uniqueness failure and constraint-failure. no-xml-att-value has been renamed to not-xml-att-value for consistency. The no-element was removed; no-parent is used for all of these cases. cannot-insert now specifically refers to PUT operations that would not be idempotent. The uri-exists error has been generalized to uniqueness-failure, covering other uniqueness constraints that an application usage might impose. The schema uses substitution groups for extensibility. The spec says that XCAP extensions can add new elements. * added an application usage that contains capabilities of the server - supported auid, supported namespaces, and supported extensions. A single instance of this document is in the global directory with the name "index" * beefed up the server processing of PUT * clearly indicate that schema awareness is not needed to insert, only to validate [ISSUE 1] * added positional inserts [ISSUE 2]. Give guidance to clients on how to use them. * removed whole idea of server filling in URI. That is now handled by having the server reject non-unique URI [ISSUE 3] * Added the "path separator" which is a path segment between document selectors and node selectors, with value of double tilde [ISSUE 4] * The section on construction of the http URI makes it very clear that each step in the selection process when processing the node selector MUST result in a single element [ISSUE 7] * Etag scope is document wide still, as it was in -02. The wording was cleaned up on it [ISSUE 8] * Changed the mime type of application/xml-fragment-body to application/xcap-el+xml and application/xml-attribute-value to application/xcap-att+xml, per discussions during ietf 59 * clarified that escape encoding of xcap components only applies when they appear in a URI, so body components will not be escape encoded * Clarified that, in the case where the client does not do a positional insertion, the element gets inserted at the end * Changed read/update/write transaction section to "Conditional Operations", since etags doesnt give "transactional" behavior in the true definition. This section has been cleaned up a lot. It also includes an example of using the If-None-Match:* to do a forced creation. * Documented that conditional operations are useless for creation operations, and recommend that if conditioning is needed, the client instead modify the parent resource. [ISSUE 9] * Updated IANA registry to include namespace and schema registrations for xcap-caps document. Also, fixed up schema registrations, which apparently need to include a schema URN. I had thought these were assigned by IANA, and equal to a URL where the schema can be fetched from, but they are not. * mention that redirects are applicable here just as for any other http resources * added a bunch of text to clarify the "do we need filename extensions or not" issue. The answer is this: for well known documents, defined by the naming conventions in the application usage, it will say how the document is named. In other cases, a document has to be referenced from a well known place, so it doesnt matter how its named, as long as you have referential integrity. * documented idempotency requirements on PUT and DELETE requests. Describe the known cases for element and attribute insertions when the request results in a document that meets the data constraints of the application usage, but is not idempotent. * added a section on guidelines for application usage design, covering both schema design and naming convention design 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 Jul 16 13:55: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 NAA19363 for ; Fri, 16 Jul 2004 13:55: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 1BlWvT-0003cG-T7 for simple-archive@ietf.org; Fri, 16 Jul 2004 13:55:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BlWub-0003IX-00 for simple-archive@ietf.org; Fri, 16 Jul 2004 13:54:22 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BlWtm-0002eR-00; Fri, 16 Jul 2004 13: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 1BlWkN-0003nj-4f; Fri, 16 Jul 2004 13:43:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BlWc4-0001oF-KJ for simple@megatron.ietf.org; Fri, 16 Jul 2004 13:35: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 NAA17732 for ; Fri, 16 Jul 2004 13:35: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 1BlWc1-0004N7-Ni for simple@ietf.org; Fri, 16 Jul 2004 13:35:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BlWb1-00042Y-00 for simple@ietf.org; Fri, 16 Jul 2004 13:34:07 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BlWa0-0003Rr-00 for simple@ietf.org; Fri, 16 Jul 2004 13:33:04 -0400 Received: from dynamicsoft.com ([63.113.46.141]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i6GHWsGr003307 for ; Fri, 16 Jul 2004 13:32:54 -0400 (EDT) Message-ID: <40F81133.6010905@dynamicsoft.com> Date: Fri, 16 Jul 2004 13:32:35 -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] Multiple insertions in 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=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Folks, Per the list discussions on multiple insertions in xcap, I have put the multiple insertions feature into a separate document, which we can now debate and decide upon separately from the core spec. I left sufficient hooks into core xcap to allow such an extension, and others, should we decide to do them. This document was submitted before the -00 deadline, and has appeared. You can pick it up here: http://www.ietf.org/internet-drafts/draft-rosenberg-simple-xcap-multiple-00.txt The document needs work, but captures the conclusions I think we came to on how this would work. Comments welcome on this, including whether or not folks wish to proceed with this subsequent to the completion of core xcap. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sat Jul 17 14:11: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 OAA28115 for ; Sat, 17 Jul 2004 14:11: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 1BlteY-0000MD-Fd for simple-archive@ietf.org; Sat, 17 Jul 2004 14:11:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BltdY-00005z-00 for simple-archive@ietf.org; Sat, 17 Jul 2004 14:10:17 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bltcw-0007cy-00; Sat, 17 Jul 2004 14:09:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bltb3-00009H-1F; Sat, 17 Jul 2004 14:07:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BltZ6-0008LD-0G for simple@megatron.ietf.org; Sat, 17 Jul 2004 14:05: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 OAA27716 for ; Sat, 17 Jul 2004 14:05: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 1BltZ5-0006VL-0S for simple@ietf.org; Sat, 17 Jul 2004 14:05:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BltXm-0006AE-00 for simple@ietf.org; Sat, 17 Jul 2004 14:04:19 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1BltWy-0005uD-00 for simple@ietf.org; Sat, 17 Jul 2004 14:03:28 -0400 Received: from panther.cs.columbia.edu (IDENT:QCNgn+LKtc4dLOW3ml9OW3Ul3sOlp1hj@panther.cs.columbia.edu [128.59.16.122]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i6HI3Pfq009418 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Sat, 17 Jul 2004 14:03:25 -0400 (EDT) Received: from [128.59.16.206] (chairpc.cs.columbia.edu [128.59.16.206]) by panther.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id i6HI3OHr014476; Sat, 17 Jul 2004 14:03:25 -0400 Message-ID: <40F969EC.2010902@cs.columbia.edu> Date: Sat, 17 Jul 2004 14:03:24 -0400 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Simple] What are tuples? References: <57796.212.119.9.178.1089110888.squirrel@webmail.cs.columbia.edu> <40F306E6.3020903@dynamicsoft.com> In-Reply-To: <40F306E6.3020903@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 4.6.1.106153, Antispam-Core: 4.6.1.104326, Antispam-Data: 2004.7.16.107779 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, __PORN_PHRASE_15_0 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@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 [HUMAN] > Then there is "human" as a mode of communications - i.e., > person-to-person talking. I think the latter is really a communications > service, where the "devices" are vocal cords/ears, and the "network" is > the air. That's what I was referring to here. >> >> - [SERVICE] There seems to some consensus that all tuples are essentially > > I think that we have definitely been talking about three fundamentally > different pieces of data - services (representing the means of > communications), devices (representing the underlying shared resource in > which services are hosted) and presentity (the actual user, whose > characteristics and status are independent of the services or devices > they are using. i.e., it is the *user* thats in a meeting, its the > *user* thats on a phone). I agree that services and presentity have a clear "has many" relationship. I still don't see devices as usefully distinct. > > The think the watcher benefits because it provides what I think is > useful information for the watcher to make a choice. For example, "oh, i > know bob is travelling and has his cell phone with him, look at that, he > has sms on his phone, i will send him an sms". No different than a service. > > I also think that people tend to think about communications in terms of > devices. People say, "call me on my cell", such that the device is the > center point for choice and preference. People buy cell phone service to be reached. The device is a necessary, but not particularly interesting, implementation detail. This will become more obvious as we start separating numbers from individual pieces of plastic. > > Also keep in mind that watchers are not the only consumers of presence > documents. I think that the device information is incredibly useful for > presence servers in the process of composition. I disagree. > The whole notion of device has been a constant factor in our "what is a > tuple" discussions all along. Indeed, rpid talks about devices and says > a lot about what kind of information is associated with a device vs. a > service. Thus, I think we should trying and bring clarity to the > definition rather than remove all notion of device from rpid. The more I try, the less clear devices become :-) > 1. if a device is idle, like my PC, it means I have not accessed the > device or any services on it for some time. This is the classic meaning > of idle in todays IM systems Not really true. If I watch a video on my PC or have it cycle through a set of PPT slides, the IM will show "idle", although the PC is doing its job and I'm watching it. In practice, it seems to mean "haven't touched the mouse or keyboard"... > > 2. if a a service is idle, like my IM client, it means I havent used the > service (i.e., havent sent/receive an IM) for some time > > 3. if a person is idle, it means that they are bored and not doing anything > > Inheritance makes sense only when there is a is-a relationship between > the thing that is inhertiting and the thing that is the source of the > inheritance. Since services and devices and presentities are not the > same thing, I dont think we should be inheriting amongst them. > > I think that, the fewer places an attribute can appear (being associated > with a service, device or tuple), the less confusion there is about what > that attribute means. When it does appear in multiple places, it should > be because it is truly meaningful for a devices, presentities and > services. For example, location is meaningful for a device and for a > presentity. It is also useful for a human, for example (which is not the same as the presentity). Is the "human:" URI a service or a device? > > -Jonathan R. > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sat Jul 17 14:58: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 OAA00773 for ; Sat, 17 Jul 2004 14:58: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 1BluNv-0004lw-NU for simple-archive@ietf.org; Sat, 17 Jul 2004 14:58:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BluN3-0004W4-00 for simple-archive@ietf.org; Sat, 17 Jul 2004 14:57:18 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BluLz-00042t-00; Sat, 17 Jul 2004 14:56:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BluHg-0004cD-Ht; Sat, 17 Jul 2004 14:51:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BluGD-0004V5-Kv for simple@megatron.ietf.org; Sat, 17 Jul 2004 14:50: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 OAA00480 for ; Sat, 17 Jul 2004 14:50: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 1BluGB-0002md-V8 for simple@ietf.org; Sat, 17 Jul 2004 14:50:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BluFH-0002Xq-00 for simple@ietf.org; Sat, 17 Jul 2004 14:49:15 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1BluER-0002J3-00 for simple@ietf.org; Sat, 17 Jul 2004 14:48:23 -0400 Received: from panther.cs.columbia.edu (IDENT:WFuTNhb5O7QK8zogQZ0PCDXZh0+SkCRT@panther.cs.columbia.edu [128.59.16.122]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i6HImIfq015939 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Sat, 17 Jul 2004 14:48:19 -0400 (EDT) Received: from [128.59.16.206] (chairpc.cs.columbia.edu [128.59.16.206]) by panther.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id i6HImIHr018308 for ; Sat, 17 Jul 2004 14:48:18 -0400 Message-ID: <40F97472.7030006@cs.columbia.edu> Date: Sat, 17 Jul 2004 14:48:18 -0400 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) 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 X-PMX-Version: 4.6.1.106153, Antispam-Core: 4.6.1.104326, Antispam-Data: 2004.7.16.107779 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, __EVITE_CTYPE 0, __CT_TEXT_PLAIN 0, __CT 0, __CTE 0, __MIME_TEXT_ONLY 0, USER_AGENT 0.000' Content-Transfer-Encoding: 7bit Subject: [Simple] Address and person URIs X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org 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 In idle curiosity, I looked around a bit to see if others had thought about URIs representing postal and in-person resources. (2396bis explicitly mentions persons as resources.) One such discussion ist at http://www.mail-archive.com/www-talk@w3.org/msg00673.html While we obviously don't need or want to design such a thing now, having some estimation as to its practicality might guide us as to whether relying on some future definition is prudent. After all, we wouldn't want to have a spec that says "We need a perpetuum mobile here; the details are for future study.". The basic problem with a "human" URI is that there does not appear to be a unique, universally accepted identifier for humans except one that each human picks randomly from a very large space. References to the 'mark of the beast' are left to other discussion venues. (Even then, I suspect that lots of Chinese will randomly pick human:888888 [http://www.travelchinaguide.com/intro/social_customs/lucky_number.htm]) For human-to-human communication, it is also more often than not unnecessary to know which precise DNA instantiation will be meeting me. Indeed, for privacy reasons, such unique identification is undesirable. Thus, unique identifiers are the wrong model for identifying human-to-human interaction. While, therefore, a human is a resource, an identifier is unnecessary and undesirable, making a URI scheme dubious at best. The problems with a "postal" URI are less severe, but the discussions surrounding the civic address format in the geopriv working group have shown that this is far from trivial. With the CIPID vcard element, it also seems unclear as to why this would be helpful in practice. Henning _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sat Jul 17 17:01: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 RAA06890 for ; Sat, 17 Jul 2004 17:01: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 1BlwJC-0004RV-DX for simple-archive@ietf.org; Sat, 17 Jul 2004 17:01:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BlwID-0004C2-00 for simple-archive@ietf.org; Sat, 17 Jul 2004 17:00:26 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BlwHu-0003wQ-00; Sat, 17 Jul 2004 17:00:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BlwFQ-0000fH-EO; Sat, 17 Jul 2004 16:57:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BlwDN-0000Up-0O for simple@megatron.ietf.org; Sat, 17 Jul 2004 16:55: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 QAA06610 for ; Sat, 17 Jul 2004 16:55: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 1BlwDL-0002tK-MJ for simple@ietf.org; Sat, 17 Jul 2004 16:55:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BlwCP-0002e9-00 for simple@ietf.org; Sat, 17 Jul 2004 16:54:27 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BlwBw-0002O9-00 for simple@ietf.org; Sat, 17 Jul 2004 16:53:56 -0400 Received: from dynamicsoft.com ([63.113.46.29]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i6HKrjGr003890; Sat, 17 Jul 2004 16:53:45 -0400 (EDT) Message-ID: <40F991C5.5090600@dynamicsoft.com> Date: Sat, 17 Jul 2004 16:53: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: Simple WG , Robert Sparks , "'hisham.khartabil@nokia.com'" Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Updated xcap-list spec, ready for wglc X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org 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 just submitted an update to the xcap-list spec. Until it appears in the archives, you can pick up a copy at: http://www.jdrosen.net/papers/draft-ietf-simple-xcap-list-usage-03.txt There are no known issues. I believe this document is ready for working group last call. All of the previous issues I posted have been resolved. Here is the summary of the resolution: ISSUE 1: Scope of the entry-ref element scoped to an xcap-root. This is enforced by using a relative path reference (i.e., a path sequence starting from the xcap root) ISSUE 2: URI of entry as an attribute or element Remains an attribute to allow indexing, see issue 3 ISSUE 3: remove name as an index for entry Removed. URI is used as an index. Canonicalization rules are defined which should work well in pretty much every case. These rules are not the ones I had posted in my last note on the topic (which stripped all parameters and converted the domain to lowercase). That stripping removed too much necessary inforamtion. Rather, tokens and domains are converted to lowercase, escape coding is normalized, and uri parameters are lexically ordered. This means that, in the vast majority of cases, two canonicalized URI are lexically equal if their original URI are functionally equal. ISSUE 4: do we want a separate index document? I created this. Its a separate application usage in the same document. This was a major change and impacted a LOT of text. I think it added a great deal of clarity. Note that I had to change the schema for the list document after I submitted the core xcap spec. As a result, the examples in the core spec are not valid according to the schema in this doc. I will fix that in the next update to the core xcap spec. Here are the list of changes overall: * separated the document into two application usages. One, called resource-lists, contains lists of hierarchical resources, independent of how they are used. The other, rls-services, defines a document which contains the data needed for an RLS to operate. This includes the supported packages, along with either a element (imported from the resource-lists schema) or a element, which contains a URI pointing to a in a resource-list document. This allows a simple case where the list is embedded in the "buddy list", or where the list is separate, and therefore reusable by other applications. [ISSUE 4] * the RLS services document starts with and has a list of . Each has a "uri" param that contains the subscribeable URI. It then has either or , followed by which defines the allowed packages. * the rls-services application usage requires an XCAP server to maintain a global rls-services document containing the union of all of the elements for all users. The text explicitly calls out that the server need not actually construct this document; its contents can be created on the fly to process a request against it. * defined a URI canonicalization procedure that is used prior to placing a URI into a "uri" attribute of a element. This addresses the issues raised about using the URI as a unique index in XCAP selection [ISSUE 3] * defined detailed RLS processing procedures on how the element is fetched from the XCAP server, and how the resulting tree defined by is traversed and compacted into a flat list of unique URI, to which virtual subscriptions can be made. THis includes the possibility of making an authorization decision about the subscription using the presence-rules document. * Added examples * Rewrote the introduction to cleanly separate the notion of a resource list from a service which might access that resource list. * Removed the element, which was something required from past versions of xcap. * Removed the subscribeable and uri attributes from the element. List now has a single optional attribute, "name" * Consistent way of talking about elements and attributes. Elements are always described with angle brackets (i.e., as opposed to "list") and attributes use double quotes. * is now defined to have a "ref" attribute which contains an relative path reference; namely, its the part of an XCAP URI to the right of the root services URI. An example is given. Entry-ref can also have a display-name content and additional elements from other namespaces. THis causes the entry-ref to be forcefully scoped to refer to entries within the same xcap root [ISSUE 1] * used to say that the XCAP URI had to be on another server. It can also be on the local server. That has been clarified. The reference is in the "anchor" attribute of . It can contain a display name and a list of elements from other namespaces. * and are only meaningful for documents obtained from an xcap server. That has been specified. Furthermore, the spec is very clear that it is not the responsibility of the server to maintain referential integrity (that is, to make sure that the entry and list elements to which the references point always exist). * did not previously say that the XCAP URI had to resolve to a element within a resource-list document. It now says that. * removed "name" attribute of [ISSUE 3] * the element used to require that its "uri" attribute be a SIP or pres URI. However, thats not right. It depends on the service which is trying to use the resource list. The resource list format itself does not constrain this any longer. The processing logic of an RLS described in this document has it discarded non-sip and non-pres URI. * added appropriate escape encoding * added xml:lang attribute to display name * documented how both client generated and server assigned URIs work. 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 Jul 18 02:52:40 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19564 for ; Sun, 18 Jul 2004 02:52: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 1Bm5XM-0002zB-BL for simple-archive@ietf.org; Sun, 18 Jul 2004 02:52:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bm5WU-0002mM-00 for simple-archive@ietf.org; Sun, 18 Jul 2004 02:51:47 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bm5Vf-0002LX-00; Sun, 18 Jul 2004 02:50:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bm5NB-0000u7-Ek; Sun, 18 Jul 2004 02:42:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bm5Mp-0000hK-Pk for simple@megatron.ietf.org; Sun, 18 Jul 2004 02:41: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 CAA19150 for ; Sun, 18 Jul 2004 02:41: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 1Bm5Mm-0000Vg-M6 for simple@ietf.org; Sun, 18 Jul 2004 02:41:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bm5Lv-0000Fl-00 for simple@ietf.org; Sun, 18 Jul 2004 02:40:51 -0400 Received: from salvelinus.brooktrout.com ([204.176.205.6]) by ietf-mx with esmtp (Exim 4.12) id 1Bm5LB-00001N-00 for simple@ietf.org; Sun, 18 Jul 2004 02:40:05 -0400 Received: from nhmail2.needham.brooktrout.com (nhmail2.eng.brooktrout.com [204.176.205.242]) by salvelinus.brooktrout.com (8.12.5/8.12.5) with ESMTP id i6I6Z2WU008015 for ; Sun, 18 Jul 2004 02:35:03 -0400 (EDT) Received: by nhmail2.eng.brooktrout.com with Internet Mail Service (5.5.2653.19) id ; Sun, 18 Jul 2004 02:33:10 -0400 Message-ID: From: Eric Burger To: simple@ietf.org Date: Sun, 18 Jul 2004 02:33:09 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Simple] MSRP VISIT 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 There was an open issue raised in the text on the overlap of SEND and VISIT. Is there any need for VISIT in this document at all? Relays are out-of-scope, and the text's suggestion of just using SEND, even in the relay case, makes sense to me. One (more?) vote towards consensus... _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sun Jul 18 02:55: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 CAA19655 for ; Sun, 18 Jul 2004 02:55: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 1Bm5aH-0003dr-TC for simple-archive@ietf.org; Sun, 18 Jul 2004 02:55:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bm5ZM-0003Qm-00 for simple-archive@ietf.org; Sun, 18 Jul 2004 02:54:45 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bm5Yi-00032E-00; Sun, 18 Jul 2004 02:54:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bm5NC-0000uZ-Dt; Sun, 18 Jul 2004 02:42:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bm5Mp-0000hL-Pi for simple@megatron.ietf.org; Sun, 18 Jul 2004 02:41: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 CAA19155 for ; Sun, 18 Jul 2004 02:41: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 1Bm5Mn-0000Vl-9L for simple@ietf.org; Sun, 18 Jul 2004 02:41:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bm5Lv-0000Fu-00 for simple@ietf.org; Sun, 18 Jul 2004 02:40:52 -0400 Received: from salvelinus.brooktrout.com ([204.176.205.6]) by ietf-mx with esmtp (Exim 4.12) id 1Bm5LC-00001N-00 for simple@ietf.org; Sun, 18 Jul 2004 02:40:06 -0400 Received: from nhmail2.needham.brooktrout.com (nhmail2.eng.brooktrout.com [204.176.205.242]) by salvelinus.brooktrout.com (8.12.5/8.12.5) with ESMTP id i6I6Z5WV008017 for ; Sun, 18 Jul 2004 02:35:10 -0400 (EDT) Received: by nhmail2.eng.brooktrout.com with Internet Mail Service (5.5.2653.19) id ; Sun, 18 Jul 2004 02:33:14 -0400 Message-ID: From: Eric Burger To: simple@ietf.org Date: Sun, 18 Jul 2004 02:33:11 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Simple] STARTTLS in 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=AWL autolearn=no version=2.60 In Section 9.1, an open issue is, "There have since been proposals that we only allow start-tls at connection time" I was wondering, when else could you do it? The reason I ask is that if you did not start with TLS, would that not mean you received a msrp: URI? In that case, is it OK to then change to msrps:, without changing (re-INVITING) to actually change to msrps:? _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sun Jul 18 02:57:40 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19715 for ; Sun, 18 Jul 2004 02:57: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 1Bm5cB-00044n-RL for simple-archive@ietf.org; Sun, 18 Jul 2004 02:57:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bm5bD-0003rE-00 for simple-archive@ietf.org; Sun, 18 Jul 2004 02:56:39 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bm5aA-0003RF-00; Sun, 18 Jul 2004 02:55:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bm5ND-0000uj-91; Sun, 18 Jul 2004 02:42:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bm5Mq-0000hT-1t for simple@megatron.ietf.org; Sun, 18 Jul 2004 02:41: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 CAA19158 for ; Sun, 18 Jul 2004 02:41: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 1Bm5Mn-0000Vq-U8 for simple@ietf.org; Sun, 18 Jul 2004 02:41:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bm5Lw-0000G2-00 for simple@ietf.org; Sun, 18 Jul 2004 02:40:52 -0400 Received: from salvelinus.brooktrout.com ([204.176.205.6]) by ietf-mx with esmtp (Exim 4.12) id 1Bm5LC-00001N-01 for simple@ietf.org; Sun, 18 Jul 2004 02:40:06 -0400 Received: from nhmail2.needham.brooktrout.com (nhmail2.eng.brooktrout.com [204.176.205.242]) by salvelinus.brooktrout.com (8.12.5/8.12.5) with ESMTP id i6I6YsWU007981 for ; Sun, 18 Jul 2004 02:34:55 -0400 (EDT) Received: by nhmail2.eng.brooktrout.com with Internet Mail Service (5.5.2653.19) id ; Sun, 18 Jul 2004 02:33:02 -0400 Message-ID: From: Eric Burger To: simple@ietf.org Date: Sun, 18 Jul 2004 02:33:02 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Simple] MSRP chunking and MIME fragmentation X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org 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 Last I looked, MSRP is a transport protocol. Thus, I don't understand the normative statement in Section 6.3.1: "The sender MUST NOT include a completion-flag of "+" if the payload MIME type does not support content fragmentation." Is not the User Agent Server buffering and reconstructing messages? That said, if it does, we should point out in the security considerations section that someone can say they are sending a fragmented message and then never send anything again, holding resources forever at the UAS. If the UAS is not buffering and reconstructing messages, and we are saying you can only send things like "message/partial", there is no MSRP fragmentation: MSRP only EVER sends complete MIME objects. Given the usefulness of sending chunks as a proxy for streaming, I would suggest just dropping the normative statement. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sun Jul 18 03:00: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 DAA19860 for ; Sun, 18 Jul 2004 03:00: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 1Bm5fE-0004kC-V0 for simple-archive@ietf.org; Sun, 18 Jul 2004 03:00:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bm5eB-0004Vo-00 for simple-archive@ietf.org; Sun, 18 Jul 2004 02:59:44 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bm5di-0004Id-00; Sun, 18 Jul 2004 02:59:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bm5NH-0000vR-92; Sun, 18 Jul 2004 02:42:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bm5Mq-0000hV-Kd for simple@megatron.ietf.org; Sun, 18 Jul 2004 02:41: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 CAA19161 for ; Sun, 18 Jul 2004 02:41: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 1Bm5Mo-0000Vv-In for simple@ietf.org; Sun, 18 Jul 2004 02:41:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bm5Lw-0000GA-00 for simple@ietf.org; Sun, 18 Jul 2004 02:40:53 -0400 Received: from salvelinus.brooktrout.com ([204.176.205.6]) by ietf-mx with esmtp (Exim 4.12) id 1Bm5LC-00001N-02 for simple@ietf.org; Sun, 18 Jul 2004 02:40:06 -0400 Received: from nhmail2.needham.brooktrout.com (nhmail2.eng.brooktrout.com [204.176.205.242]) by salvelinus.brooktrout.com (8.12.5/8.12.5) with ESMTP id i6I6YtWU007986 for ; Sun, 18 Jul 2004 02:34:57 -0400 (EDT) Received: by nhmail2.eng.brooktrout.com with Internet Mail Service (5.5.2653.19) id ; Sun, 18 Jul 2004 02:33:04 -0400 Message-ID: From: Eric Burger To: simple@ietf.org Date: Sun, 18 Jul 2004 02:33:03 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Simple] UAS behavior in MSRP session initiation X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org 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 In section 6.5.1, step 4 of the answerer (UAS) states that if there are no relays, the UAS does not need to listen for a connection. Doesn't the UAS need to listen for a connection from the relay? Or, are we assuming that the relay connection is established, *in both directions* upon relay contact? If so, say so. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sun Jul 18 03:01: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 DAA19907 for ; Sun, 18 Jul 2004 03:01: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 1Bm5g7-00051C-TM for simple-archive@ietf.org; Sun, 18 Jul 2004 03:01:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bm5fB-0004jm-00 for simple-archive@ietf.org; Sun, 18 Jul 2004 03:00:46 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bm5e9-0004Ih-00; Sun, 18 Jul 2004 02:59:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bm5NH-0000vz-Uu; Sun, 18 Jul 2004 02:42:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bm5Mr-0000he-AG for simple@megatron.ietf.org; Sun, 18 Jul 2004 02:41: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 CAA19164 for ; Sun, 18 Jul 2004 02:41: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 1Bm5Mp-0000W0-7Z for simple@ietf.org; Sun, 18 Jul 2004 02:41:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bm5Lx-0000GI-00 for simple@ietf.org; Sun, 18 Jul 2004 02:40:53 -0400 Received: from salvelinus.brooktrout.com ([204.176.205.6]) by ietf-mx with esmtp (Exim 4.12) id 1Bm5LD-00001N-00 for simple@ietf.org; Sun, 18 Jul 2004 02:40:07 -0400 Received: from nhmail2.needham.brooktrout.com (nhmail2.eng.brooktrout.com [204.176.205.242]) by salvelinus.brooktrout.com (8.12.5/8.12.5) with ESMTP id i6I6YwWU007992 for ; Sun, 18 Jul 2004 02:34:59 -0400 (EDT) Received: by nhmail2.eng.brooktrout.com with Internet Mail Service (5.5.2653.19) id ; Sun, 18 Jul 2004 02:33:06 -0400 Message-ID: From: Eric Burger To: simple@ietf.org Date: Sun, 18 Jul 2004 02:33:05 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Simple] Something different at session termination time X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org 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 text says that a UAC "SHOULD NOT" generate a new SEND transaction after deciding to end a session. What makes this not a "MUST"? Under what circumstance would the UAC send something after closing a session? _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sun Jul 18 03:02: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 DAA19981 for ; Sun, 18 Jul 2004 03:02: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 1Bm5h4-0005Hz-UD for simple-archive@ietf.org; Sun, 18 Jul 2004 03:02:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bm5g4-00050h-00 for simple-archive@ietf.org; Sun, 18 Jul 2004 03:01:40 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bm5ez-0004Wh-00; Sun, 18 Jul 2004 03:00:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bm5NI-0000w4-FS; Sun, 18 Jul 2004 02:42:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bm5Mv-0000iX-9B for simple@megatron.ietf.org; Sun, 18 Jul 2004 02:41: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 CAA19181 for ; Sun, 18 Jul 2004 02:41: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 1Bm5Mt-0000WV-6F for simple@ietf.org; Sun, 18 Jul 2004 02:41:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bm5M0-0000Gp-00 for simple@ietf.org; Sun, 18 Jul 2004 02:40:57 -0400 Received: from salvelinus.brooktrout.com ([204.176.205.6]) by ietf-mx with esmtp (Exim 4.12) id 1Bm5LL-00001W-00 for simple@ietf.org; Sun, 18 Jul 2004 02:40:16 -0400 Received: from nhmail2.needham.brooktrout.com (nhmail2.eng.brooktrout.com [204.176.205.242]) by salvelinus.brooktrout.com (8.12.5/8.12.5) with ESMTP id i6I6YRWU007958; Sun, 18 Jul 2004 02:34:29 -0400 (EDT) Received: by nhmail2.eng.brooktrout.com with Internet Mail Service (5.5.2653.19) id ; Sun, 18 Jul 2004 02:32:36 -0400 Message-ID: From: Eric Burger To: seancolson@yahoo.com Subject: Chunking driver (was RE: [Simple] MSRP Boundary header) Date: Sun, 18 Jul 2004 02:32:35 -0400 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=AWL autolearn=no version=2.60 Ummm. Isn't the transport TCP? If you are on a LAN, aren't you going to be using 8K packets, anyway? E.g., I really don't get the chunking drive. Can't claim "small device": are you saying that these devices won't be surfing the web, getting e-mail, etc.? > -----Original Message----- > From: Sean Olson [mailto:seancolson@yahoo.com] > Sent: Tuesday, June 29, 2004 10:48 PM > To: 'Vijay Hampapur Hampapur Parthasarathy'; 'Ben Campbell' > Cc: simple@ietf.org > Subject: RE: [Simple] MSRP Boundary header > [snip] > > 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. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sun Jul 18 03:02: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 DAA20025 for ; Sun, 18 Jul 2004 03:02: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 1Bm5hE-0005JJ-Gg for simple-archive@ietf.org; Sun, 18 Jul 2004 03:02:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bm5gR-00053o-00 for simple-archive@ietf.org; Sun, 18 Jul 2004 03:02:04 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bm5fa-0004ck-00; Sun, 18 Jul 2004 03:01:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bm5NJ-0000w9-2N; Sun, 18 Jul 2004 02:42:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bm5Mv-0000iZ-UV for simple@megatron.ietf.org; Sun, 18 Jul 2004 02: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 CAA19184 for ; Sun, 18 Jul 2004 02: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 1Bm5Mt-0000Wa-Pt for simple@ietf.org; Sun, 18 Jul 2004 02:41:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bm5M1-0000Gx-00 for simple@ietf.org; Sun, 18 Jul 2004 02:40:57 -0400 Received: from salvelinus.brooktrout.com ([204.176.205.6]) by ietf-mx with esmtp (Exim 4.12) id 1Bm5LR-00001W-00 for simple@ietf.org; Sun, 18 Jul 2004 02:40:21 -0400 Received: from nhmail2.needham.brooktrout.com (nhmail2.eng.brooktrout.com [204.176.205.242]) by salvelinus.brooktrout.com (8.12.5/8.12.5) with ESMTP id i6I6YbWU007965; Sun, 18 Jul 2004 02:34:39 -0400 (EDT) Received: by nhmail2.eng.brooktrout.com with Internet Mail Service (5.5.2653.19) id ; Sun, 18 Jul 2004 02:32:46 -0400 Message-ID: From: Eric Burger To: Orit Levin Subject: Binary transport (was RE: [Simple] MSRP Boundary header) Date: Sun, 18 Jul 2004 02:32:45 -0400 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=AWL autolearn=no version=2.60 I think at least 8-bit transport absolutely, positively, must be supported. I'm surprised no one picked up on Orit's comment. To support the boundary mechanism, binary objects MUST be transmitted in network byte order. That would also ensure interoperability across platforms. Could this be normative text? With 8-bit transport, the proposed boundary mechanism still works. With network byte order, the proposed mechanism works in all cases. I would strongly suggest highlighting the transport of 8-bit objects in places like Section 6.3.2. We learned from SIP that when people don't see binary bodies, they don't expect to see binary bodies. Cullen had to write an Informational draft just to let people know that binary is good... > -----Original Message----- > From: Orit Levin [mailto:oritl@microsoft.com] > Sent: Tuesday, July 06, 2004 4:54 PM > To: Cullen Jennings; Ben Campbell; Vijay Kishen Hampapur Parthasarathy > Cc: Paul H Kyzivat; seancolson@yahoo.com; simple@ietf.org > Subject: RE: [Simple] MSRP Boundary header > [snip] > - Does the implicit assumption that all the data needs to be > encoded/escaped (no binary data in MSRP) work for everybody? _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sun Jul 18 03:02: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 DAA20046 for ; Sun, 18 Jul 2004 03:02: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 1Bm5hG-0005JY-BE for simple-archive@ietf.org; Sun, 18 Jul 2004 03:02:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bm5gX-00054Z-00 for simple-archive@ietf.org; Sun, 18 Jul 2004 03:02:10 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bm5fu-0004m3-00; Sun, 18 Jul 2004 03:01:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bm5NJ-0000wJ-O8; Sun, 18 Jul 2004 02:42:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bm5Mw-0000ib-Fy for simple@megatron.ietf.org; Sun, 18 Jul 2004 02: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 CAA19187 for ; Sun, 18 Jul 2004 02: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 1Bm5Mu-0000Wf-DE for simple@ietf.org; Sun, 18 Jul 2004 02:41:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bm5M1-0000H5-00 for simple@ietf.org; Sun, 18 Jul 2004 02:40:58 -0400 Received: from salvelinus.brooktrout.com ([204.176.205.6]) by ietf-mx with esmtp (Exim 4.12) id 1Bm5LT-00001a-00 for simple@ietf.org; Sun, 18 Jul 2004 02:40:23 -0400 Received: from nhmail2.needham.brooktrout.com (nhmail2.eng.brooktrout.com [204.176.205.242]) by salvelinus.brooktrout.com (8.12.5/8.12.5) with ESMTP id i6I6YrWU007980; Sun, 18 Jul 2004 02:34:55 -0400 (EDT) Received: by nhmail2.eng.brooktrout.com with Internet Mail Service (5.5.2653.19) id ; Sun, 18 Jul 2004 02:33:02 -0400 Message-ID: From: Eric Burger To: "Ben Campbell (E-mail)" Date: Sun, 18 Jul 2004 02:33:01 -0400 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 Subject: [Simple] MSRP Message Types X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org 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 Section 5.1: The last line of the section gives an example of an m-line that specifies reception of "message/cpim, plain text or HTML". First, shouldn't it be "message/cpim, message/text, or message/html"? Second, the example is an unadorned: m=message 9999 msrp * Is the reason that plain text and html are accepted because they are defaults, or because the example is missing the a-lines? Clarify the text. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sun Jul 18 03:03: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 DAA20110 for ; Sun, 18 Jul 2004 03:03: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 1Bm5iB-0005Yy-0z for simple-archive@ietf.org; Sun, 18 Jul 2004 03:03:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bm5hJ-0005K3-00 for simple-archive@ietf.org; Sun, 18 Jul 2004 03:02:58 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bm5gj-00052L-00; Sun, 18 Jul 2004 03:02:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bm5NK-0000wO-Cd; Sun, 18 Jul 2004 02:42:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bm5Mx-0000jA-3F for simple@megatron.ietf.org; Sun, 18 Jul 2004 02: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 CAA19190 for ; Sun, 18 Jul 2004 02: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 1Bm5Mv-0000Wk-0o for simple@ietf.org; Sun, 18 Jul 2004 02:41:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bm5M2-0000HE-00 for simple@ietf.org; Sun, 18 Jul 2004 02:40:59 -0400 Received: from salvelinus.brooktrout.com ([204.176.205.6]) by ietf-mx with esmtp (Exim 4.12) id 1Bm5LU-00001a-00 for simple@ietf.org; Sun, 18 Jul 2004 02:40:24 -0400 Received: from nhmail2.needham.brooktrout.com (nhmail2.eng.brooktrout.com [204.176.205.242]) by salvelinus.brooktrout.com (8.12.5/8.12.5) with ESMTP id i6I6Z0WU007996; Sun, 18 Jul 2004 02:35:01 -0400 (EDT) Received: by nhmail2.eng.brooktrout.com with Internet Mail Service (5.5.2653.19) id ; Sun, 18 Jul 2004 02:33:08 -0400 Message-ID: From: Eric Burger To: simple@ietf.org Date: Sun, 18 Jul 2004 02:33:08 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Cc: "Ben Campbell \(E-mail\)" Subject: [Simple] MSRP DSN Status codes X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org 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 still don't get it. The purpose of a DSN status code is to let you know that the delivery failed and why in an environment where you don't have a *direct* connection to the recipient. Clearly, DSN is a relay ONLY thing. Why? Because section 6.6.5.7 goes to great lengths to say that a 200 OK response becomes a 2.0.0. This is insane. You would get the 200 OK response, and know the message was delivered. End of story. In a failure mode, you would get the 500 response, or just not get one. If we're talking relays here, then why are relays not proxies, issuing 100-class responses to message accepted for relay and 200-, 500-, timeout, or whatever they get from upstream upon failure? That would make the whole REPORT thing obsolete and keep everything within MSRP. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sun Jul 18 03:04: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 DAA20168 for ; Sun, 18 Jul 2004 03:04: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 1Bm5j0-0005my-6M for simple-archive@ietf.org; Sun, 18 Jul 2004 03:04:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bm5i6-0005YP-00 for simple-archive@ietf.org; Sun, 18 Jul 2004 03:03:47 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bm5hE-000554-00; Sun, 18 Jul 2004 03:02:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bm5NL-0000wa-5u; Sun, 18 Jul 2004 02:42:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bm5Mz-0000jj-3S for simple@megatron.ietf.org; Sun, 18 Jul 2004 02:41: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 CAA19193 for ; Sun, 18 Jul 2004 02:41: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 1Bm5Mx-0000Wz-2E for simple@ietf.org; Sun, 18 Jul 2004 02:41:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bm5M4-0000He-00 for simple@ietf.org; Sun, 18 Jul 2004 02:41:01 -0400 Received: from salvelinus.brooktrout.com ([204.176.205.6]) by ietf-mx with esmtp (Exim 4.12) id 1Bm5LV-00001a-00 for simple@ietf.org; Sun, 18 Jul 2004 02:40:25 -0400 Received: from nhmail2.needham.brooktrout.com (nhmail2.eng.brooktrout.com [204.176.205.242]) by salvelinus.brooktrout.com (8.12.5/8.12.5) with ESMTP id i6I6YfWU007967; Sun, 18 Jul 2004 02:34:43 -0400 (EDT) Received: by nhmail2.eng.brooktrout.com with Internet Mail Service (5.5.2653.19) id ; Sun, 18 Jul 2004 02:32:50 -0400 Message-ID: From: Eric Burger To: Ben Campbell Subject: RE: [Simple] MSRP: delivery reports and transaction responses Date: Sun, 18 Jul 2004 02:32:49 -0400 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=AWL autolearn=no version=2.60 In theory, the DSN only says that the message got to the recipient's device. The DSN is something designed for Relays, not User Agents, to emit. What gets confusing is the User Agent Server is also a Relay, "forwarding" the message to the user. In reality, the MDN does not *guarantee* any other information, as well. Privacy considerations require the blocking of MDN's by the recipient. > -----Original Message----- > From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] > Sent: Thursday, July 01, 2004 11:54 AM > To: Eric Burger > Cc: Adam Roach; cboulton@ubiquity.com; simple@ietf.org > Subject: Re: [Simple] MSRP: delivery reports and transaction responses > > > One area I am not sure we are communicating: > > The "positive" report says _nothing_ about whether the user > has seen the > message. It merely confirms that the message was received by the > terminating device in the path. > > Does that still make it mirror a MDN? > > Eric Burger wrote: > > > Do I look blue in the face yet??? > > > > The reason for all of this bizarre flag / indicator > interaction is we are > > STILL trying to squeeze two different report notifications into one. > > > > Let's look at the requirements. > > > > #1: There is a need for positive acknowledgement, by > sender's request, that > > a message was delivered. This is an end-to-end issue, > mirroring the MDN. > > Note that local policy or security policy means the > recipient MUST be able > > to deny the sender's request for acknowledgement. > > > > #2: There is a need, by sender's request, for notification > of transport > > failure. This occurs when a relay can't send the message > on, or is queuing > > it for later delivery. This is a transport network > (hop-by-hop) issue, > > mirroring the DSN. > > > > Is there any reason not to have these two things separate, > orthogonal > > requests? > > > > Instead of nine-element matrixes with incompatible states, > we end up with: > > > > MDN Requested, tell me only failures or tell me failure/success > > DSN Requested, tell me only failures > > > > Experience with SMTP says, MUST NOT have every hop report > positive DSN's. > > Positive DSN's have no value, other than exposing the relay > network to > > potentially bad people. The thing of value is that the end > user got the > > message (MDN). > > > > Do I need to do _more_ text? > > > > > > > >>-----Original Message----- > >>From: Adam Roach [mailto:adam@dynamicsoft.com] > >>Sent: Thursday, June 17, 2004 6:13 PM > >>To: Mike Hammer > >>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 > >> > >> > >>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 Sun Jul 18 03:04: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 DAA20210 for ; Sun, 18 Jul 2004 03:04: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 1Bm5j7-0005nn-0p for simple-archive@ietf.org; Sun, 18 Jul 2004 03:04:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bm5iK-0005a3-00 for simple-archive@ietf.org; Sun, 18 Jul 2004 03:04:01 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bm5hi-0005JQ-00; Sun, 18 Jul 2004 03:03:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bm5NM-0000wf-2P; Sun, 18 Jul 2004 02:42:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bm5Mz-0000jl-Lb for simple@megatron.ietf.org; Sun, 18 Jul 2004 02:41: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 CAA19198 for ; Sun, 18 Jul 2004 02:41: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 1Bm5Mx-0000X4-JK for simple@ietf.org; Sun, 18 Jul 2004 02:41:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bm5M5-0000Hm-00 for simple@ietf.org; Sun, 18 Jul 2004 02:41:02 -0400 Received: from salvelinus.brooktrout.com ([204.176.205.6]) by ietf-mx with esmtp (Exim 4.12) id 1Bm5LW-00001a-00 for simple@ietf.org; Sun, 18 Jul 2004 02:40:26 -0400 Received: from nhmail2.needham.brooktrout.com (nhmail2.eng.brooktrout.com [204.176.205.242]) by salvelinus.brooktrout.com (8.12.5/8.12.5) with ESMTP id i6I6YpWU007977; Sun, 18 Jul 2004 02:34:52 -0400 (EDT) Received: by nhmail2.eng.brooktrout.com with Internet Mail Service (5.5.2653.19) id ; Sun, 18 Jul 2004 02:32:59 -0400 Message-ID: From: Eric Burger To: simple@ietf.org Subject: Suggested RTT text (was RE: [Simple] RE: [Sipping] RE: text/T140 andaudio/t140) Date: Sun, 18 Jul 2004 02:32:59 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Cc: "Drage, Keith \(Keith\)" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org 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 After 420 pages of "discussion", may I humbly propose the following text for the MSRP document: User interfaces and user communities for instant messaging and real-time text telephony are extremely similar. MSRP is not an ideal protocol for the negotiation and transport of real-time text. However, devices that implement MRSP SHOULD implement real-time text telephony, using standard SIP (RFC3261) and text/t140 (RFC2793bis) mechanisms. Rationale: 1. It looks like consensus to putting RTP under MSRP is far, far, away, assuming it even makes sense, which it probably doesn't. 2. A whole bunch (80%?) of the code for an IM device would be shared with a RTT device - character input, character display, Internet connectivity, SIP stack, etc. 3. We have a charter obligation to make protocols amenable to building devices that are accessible to everyone. This is an opportunity to meet the objections to trying to shoehorn RTT into MSRP (#1) with our Charter obligations (#3) without an undue burden on the implementer (#2). > -----Original Message----- > From: Drage, Keith (Keith) [mailto:drage@lucent.com] > Sent: Monday, July 05, 2004 5:54 AM > To: simple@ietf.org > Subject: RE: [Simple] RE: [Sipping] RE: text/T140 andaudio/t140 > was:[avt]C omments/questions on draft-ietf-av > > > Given the length of time this discussion has been going on, > and the number of messages exchanged, is it not about time we > reached some conclusions. These lists are to advance the > deliverables in the working groups concerned, so how do any > conclusions affect those deliverables. > > SIMPLE has a charter to produce instant messaging protocols. > I do not see in all the discussion of the advantages of > instant messaging versus real-time text removing that charter > item. Therefore I suggest we STOP that discussion, or the > proponents move it elsewhere. > > SIMPLE does not have a charter item to produce real-time text > protocols. There is already an existing capability in IETF > for real-time text protocols. It is not really up to SIMPLE > to discuss whether that works well or not, as it was not > developed under SIMPLEs charter. > > How terminals mix and match applications is not something > that IETF traditionally deals with. Therefore I would suggest > that any requirements that state RTT and IM must be > implemented in the same terminal are out of scope of IETF. > They should certainly be in some device specification rather > than in the MSRP specification which SIMPLE is specifically > delivering. > > I guess the questions as affecting MSRP really fall down to these: > > - Are there capabilities in MSRP that would lead to a > valid RTT protocol that works better than the existing IETF > solution, in addition to it fulfilling the requirements to > provide an IM protocol. From the exchange of messages I have > seem so far, it seems to me that the conclusion should be NO. > > - In order to deal with a body of users that have IM, and > prefer to use IM, and a body of users that have RTT, and > prefer to use RTT, is there a need to be able to interwork > the two protocols at some intermediate point, and not just > within the terminal by supporting both protocols under a > common user interface? I see that as an element of the > discussion just raised by Paul. Does such interworking, if > required, have any impact on the contents of MSRP? > > regards > > Keith > > Keith Drage > Lucent Technologies > drage@lucent.com > tel: +44 1793 776249 > > > > -----Original Message----- > > From: Arnoud van Wijk [mailto:a.vwijk@viataal.nl] > > Sent: 04 July 2004 10:43 > > To: hisham.khartabil@nokia.com; paulej@packetizer.com; > > pkyzivat@cisco.com; Guido.Gybels@rnid.org.uk > > Cc: fluffy@cisco.com; simple@ietf.org; gv@trace.wisc.edu; > > toip@snowshore.com; gunnar.hellstrom@omnitor.se; smundra@telogy.com > > Subject: RE: [Simple] RE: [Sipping] RE: text/T140 andaudio/t140 > > was:[avt]Comments/questions on draft-ietf-av > > > > > > Never say never. > > Have you tried interactive text/real-time text? > > Did you? > > > > First try it and THEN you can say if you like it or not. > > > > If you want to determine how useful it is. Test it. > > Use it > > Try it > > Compare it with IM. > > See the differences between IM and RTT/Interactive text. > > See that both text communication methods have their advantages and > > disadvantages. > > And use both for the best situations. > > > > And if you still don't want to use RTT/Interactive > > text..fine..I just hope > > that when I call you, that you can still receive my call. > > Just use it only > > when the other person uses Interactive text/RTT. > > Even if it is then 3-4 times per year. > > > > Can you with IM: > > * directly call the other? > > * forward the call? > > * put on hold? > > * have the call go to multiple terminals? > > * not being logged on a buddy list server, where you may get > > flooded by 20 > > users at the same time saying hi! And such? > > * being able to leave a message on an answering machine? > > * using a service that allows a ring notifivation as soon the > > other user is > > ready with his/her other phonecall? (ring back on busy). > > > > There are more.. but I am unfamiliar with voice calls. I am > > just enjoying my > > freedom of communications beyond the IM limitations. > > > > And I enjoy using IM also..even though I am forced to use > > Trillian, since > > there is NO one universal standard for IM right now! > > > > Interactive text is! > > > > Greetz > > > > Arnoud > > > > > > _______________________________________________ > Simple mailing 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 Sun Jul 18 03:12: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 DAA20481 for ; Sun, 18 Jul 2004 03:12: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 1Bm5qn-0007XY-OU for simple-archive@ietf.org; Sun, 18 Jul 2004 03:12:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bm5po-0007JM-00 for simple-archive@ietf.org; Sun, 18 Jul 2004 03:11:45 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bm5pI-00076F-00; Sun, 18 Jul 2004 03:11:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bm5iQ-0003ln-PJ; Sun, 18 Jul 2004 03:04:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bm5Nk-0000xW-Kl for simple@megatron.ietf.org; Sun, 18 Jul 2004 02:42: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 CAA19222 for ; Sun, 18 Jul 2004 02:42: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 1Bm5Ni-0000l2-If for simple@ietf.org; Sun, 18 Jul 2004 02:42:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bm5Mk-0000VJ-00 for simple@ietf.org; Sun, 18 Jul 2004 02:41:42 -0400 Received: from salvelinus.brooktrout.com ([204.176.205.6]) by ietf-mx with esmtp (Exim 4.12) id 1Bm5Lr-0000FT-00 for simple@ietf.org; Sun, 18 Jul 2004 02:40:47 -0400 Received: from nhmail2.needham.brooktrout.com (nhmail2.eng.brooktrout.com [204.176.205.242]) by salvelinus.brooktrout.com (8.12.5/8.12.5) with ESMTP id i6I6YTWU007961; Sun, 18 Jul 2004 02:34:31 -0400 (EDT) Received: by nhmail2.eng.brooktrout.com with Internet Mail Service (5.5.2653.19) id ; Sun, 18 Jul 2004 02:32:38 -0400 Message-ID: From: Eric Burger To: Cullen Jennings , Ben Campbell Subject: RE: [Simple] MSRP Boundary header Date: Sun, 18 Jul 2004 02:32:37 -0400 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=AWL autolearn=no version=2.60 This should be a NOTE in the text. > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: Tuesday, June 29, 2004 11:08 PM > To: Vijay Hampapur Hampapur Parthasarathy; Ben Campbell > Cc: simple@ietf.org > Subject: Re: [Simple] MSRP Boundary header > [snip] > > 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. [snip] _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sun Jul 18 03:14: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 DAA20549 for ; Sun, 18 Jul 2004 03:14: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 1Bm5s5-00001E-Hc for simple-archive@ietf.org; Sun, 18 Jul 2004 03:14:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bm5qw-0007YI-00 for simple-archive@ietf.org; Sun, 18 Jul 2004 03:12:55 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bm5q0-00076a-00; Sun, 18 Jul 2004 03:11:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bm5iR-0003m5-Dr; Sun, 18 Jul 2004 03:04:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bm5Nl-0000xY-AW for simple@megatron.ietf.org; Sun, 18 Jul 2004 02:42: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 CAA19225 for ; Sun, 18 Jul 2004 02:42: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 1Bm5Nj-0000l7-8L for simple@ietf.org; Sun, 18 Jul 2004 02:42:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bm5Mk-0000VR-00 for simple@ietf.org; Sun, 18 Jul 2004 02:41:43 -0400 Received: from salvelinus.brooktrout.com ([204.176.205.6]) by ietf-mx with esmtp (Exim 4.12) id 1Bm5Lr-0000FT-01 for simple@ietf.org; Sun, 18 Jul 2004 02:40:48 -0400 Received: from nhmail2.needham.brooktrout.com (nhmail2.eng.brooktrout.com [204.176.205.242]) by salvelinus.brooktrout.com (8.12.5/8.12.5) with ESMTP id i6I6Z0WU008006; Sun, 18 Jul 2004 02:35:01 -0400 (EDT) Received: by nhmail2.eng.brooktrout.com with Internet Mail Service (5.5.2653.19) id ; Sun, 18 Jul 2004 02:33:08 -0400 Message-ID: From: Eric Burger To: Ben Campbell , Simple WG Subject: RE: [Simple] MSRP: Miscellaneous REPORT issues Date: Sun, 18 Jul 2004 02:33:06 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Cc: Chris Boulton X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org 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 can live with DSN bodies being optional, so long as the normative language is that no body means EITHER success OR failure. Personally, I'm leaning toward no body for success because you want information for failure. We MUST, MUST, MUST chose one and only one meaning for no body. Having an empty body sometimes mean success and other times mean failure is a recipe for major interpretation, and thus interop, failure. That said, in the MOST STRONG SENSE POSSIBLE I suggest AGAINST having multiple DSN report types. That is an invitation for proprietary report formats EVERYWHERE, making the goal of interoperability evaporate. If the DSN format is too "heavyweight", then chose something other than RFC1894. I hear ASN.1 makes pretty compact messages x-\ By the way, in Section 6.6.2, a device that SHOULD generate DSN's cannot MUST generate them. Either they MUST or SHOULD. Also, a DSN MUST NOT have a Message-Receipt header. Have to put that in the security considerations section, too. > -----Original Message----- > From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] > Sent: Monday, June 28, 2004 4:21 PM > To: Simple WG > Cc: Cullen Jennings; Rohan Mahy; Adam Roach; Hisham Khartabil; Robert > Sparks; Chris Boulton > Subject: [Simple] MSRP: Miscellaneous REPORT issues > > > 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 > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sun Jul 18 03:15: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 DAA20720 for ; Sun, 18 Jul 2004 03: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 1Bm5tm-0000Wt-EQ for simple-archive@ietf.org; Sun, 18 Jul 2004 03:15:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bm5t5-0000J3-00 for simple-archive@ietf.org; Sun, 18 Jul 2004 03:15:08 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bm5sT-000007-00; Sun, 18 Jul 2004 03:14:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bm5iX-0003q0-LW; Sun, 18 Jul 2004 03:04:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bm5Np-0000xh-Ei for simple@megatron.ietf.org; Sun, 18 Jul 2004 02:42: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 CAA19237 for ; Sun, 18 Jul 2004 02:42: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 1Bm5Nn-0000lV-96 for simple@ietf.org; Sun, 18 Jul 2004 02:42:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bm5Mx-0000X9-00 for simple@ietf.org; Sun, 18 Jul 2004 02:41:56 -0400 Received: from salvelinus.brooktrout.com ([204.176.205.6]) by ietf-mx with esmtp (Exim 4.12) id 1Bm5M6-0000Hr-00 for simple@ietf.org; Sun, 18 Jul 2004 02:41:02 -0400 Received: from nhmail2.needham.brooktrout.com (nhmail2.eng.brooktrout.com [204.176.205.242]) by salvelinus.brooktrout.com (8.12.5/8.12.5) with ESMTP id i6I6YiWU007971; Sun, 18 Jul 2004 02:34:46 -0400 (EDT) Received: by nhmail2.eng.brooktrout.com with Internet Mail Service (5.5.2653.19) id ; Sun, 18 Jul 2004 02:32:53 -0400 Message-ID: From: Eric Burger To: hisham.khartabil@nokia.com, bcampbell@dynamicsoft.com, simple@ietf.org Subject: REPORT per Chunk or Message (was RE: [Simple] MSRP: Miscellaneous REPORT issues) Date: Sun, 18 Jul 2004 02:32:53 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Cc: 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=AWL autolearn=no version=2.60 I haven't heard consensus on this one. It jumped out at me during my reading of the text, as well. Once consensus is reached, it has to be put into the text. My vote: This is a tough one. If we say "per chunk", then once a chunk fails, does that put the onus on the Relay to reject all further chunks in the message? If not, then does this put a big burden on the network and User Agent Server to relay chunks that will never get assembled into a message? Conversely, what if we are chunking because this is streaming media? Losing a chunk shouldn't kill the session. I say, "kill it - you wanted to replace SMTP, you take all the semantics". A message is a message. If a chunk fails, the message fails. > -----Original Message----- > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > Sent: Tuesday, June 29, 2004 3:34 AM > To: bcampbell@dynamicsoft.com; simple@ietf.org > Cc: fluffy@cisco.com; rohan@cisco.com; adam@dynamicsoft.com; > cboulton@ubiquity.com; rsparks@dynamicsoft.com > Subject: RE: [Simple] MSRP: Miscellaneous REPORT issues > > > > > > -----Original Message----- > > From: simple-bounces@ietf.org > > [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 [snip] > > 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 [snip] _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sun Jul 18 05:13: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 FAA25757 for ; Sun, 18 Jul 2004 05:13: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 1Bm7jS-0003mw-V3 for simple-archive@ietf.org; Sun, 18 Jul 2004 05:13:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bm7hz-0003Q8-00 for simple-archive@ietf.org; Sun, 18 Jul 2004 05:11:48 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bm7h4-0002yu-00; Sun, 18 Jul 2004 05:10:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bm7dF-0000b9-Fl; Sun, 18 Jul 2004 05:06:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bm7YL-0000Hn-8S for simple@megatron.ietf.org; Sun, 18 Jul 2004 05:01: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 FAA25253 for ; Sun, 18 Jul 2004 05:01: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 1Bm7YI-0001GO-Ee for simple@ietf.org; Sun, 18 Jul 2004 05:01:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bm7XJ-000130-00 for simple@ietf.org; Sun, 18 Jul 2004 05:00:45 -0400 Received: from smtp.eweka.nl ([81.171.101.3]) by ietf-mx with esmtp (Exim 4.12) id 1Bm7WJ-0000dX-00 for simple@ietf.org; Sun, 18 Jul 2004 04:59:44 -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 i6I93qb0036612; Sun, 18 Jul 2004 11:03:57 +0200 (CEST) (envelope-from a.vwijk@viataal.nl) Message-Id: <200407180903.i6I93qb0036612@smtp.eweka.nl> From: "Arnoud van Wijk" To: "'Eric Burger'" , Subject: RE: Suggested RTT text (was RE: [Simple] RE: [Sipping] RE: text/T140 andaudio/t140) Date: Sun, 18 Jul 2004 10:59:35 +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.1441 Thread-Index: AcRslVhEcNu4hI6RQMizV5aMO/1FvAAEBGrQ In-Reply-To: Content-Transfer-Encoding: 7bit Cc: "'Drage, Keith \(Keith\)'" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org 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,MISSING_OUTLOOK_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Hello Eric, I am happy to see that we have the same view here! I so totally agree with you! And frankly..why would people object to this? This is the best of both worlds. Greetz Arnoud -----Original Message----- From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf Of Eric Burger Sent: zondag 18 juli 2004 8:33 To: simple@ietf.org Cc: Drage, Keith (Keith) Subject: Suggested RTT text (was RE: [Simple] RE: [Sipping] RE: text/T140 andaudio/t140) After 420 pages of "discussion", may I humbly propose the following text for the MSRP document: User interfaces and user communities for instant messaging and real-time text telephony are extremely similar. MSRP is not an ideal protocol for the negotiation and transport of real-time text. However, devices that implement MRSP SHOULD implement real-time text telephony, using standard SIP (RFC3261) and text/t140 (RFC2793bis) mechanisms. Rationale: 1. It looks like consensus to putting RTP under MSRP is far, far, away, assuming it even makes sense, which it probably doesn't. 2. A whole bunch (80%?) of the code for an IM device would be shared with a RTT device - character input, character display, Internet connectivity, SIP stack, etc. 3. We have a charter obligation to make protocols amenable to building devices that are accessible to everyone. This is an opportunity to meet the objections to trying to shoehorn RTT into MSRP (#1) with our Charter obligations (#3) without an undue burden on the implementer (#2). > -----Original Message----- > From: Drage, Keith (Keith) [mailto:drage@lucent.com] > Sent: Monday, July 05, 2004 5:54 AM > To: simple@ietf.org > Subject: RE: [Simple] RE: [Sipping] RE: text/T140 andaudio/t140 > was:[avt]C omments/questions on draft-ietf-av > > > Given the length of time this discussion has been going on, > and the number of messages exchanged, is it not about time we > reached some conclusions. These lists are to advance the > deliverables in the working groups concerned, so how do any > conclusions affect those deliverables. > > SIMPLE has a charter to produce instant messaging protocols. > I do not see in all the discussion of the advantages of > instant messaging versus real-time text removing that charter > item. Therefore I suggest we STOP that discussion, or the > proponents move it elsewhere. > > SIMPLE does not have a charter item to produce real-time text > protocols. There is already an existing capability in IETF > for real-time text protocols. It is not really up to SIMPLE > to discuss whether that works well or not, as it was not > developed under SIMPLEs charter. > > How terminals mix and match applications is not something > that IETF traditionally deals with. Therefore I would suggest > that any requirements that state RTT and IM must be > implemented in the same terminal are out of scope of IETF. > They should certainly be in some device specification rather > than in the MSRP specification which SIMPLE is specifically > delivering. > > I guess the questions as affecting MSRP really fall down to these: > > - Are there capabilities in MSRP that would lead to a > valid RTT protocol that works better than the existing IETF > solution, in addition to it fulfilling the requirements to > provide an IM protocol. From the exchange of messages I have > seem so far, it seems to me that the conclusion should be NO. > > - In order to deal with a body of users that have IM, and > prefer to use IM, and a body of users that have RTT, and > prefer to use RTT, is there a need to be able to interwork > the two protocols at some intermediate point, and not just > within the terminal by supporting both protocols under a > common user interface? I see that as an element of the > discussion just raised by Paul. Does such interworking, if > required, have any impact on the contents of MSRP? > > regards > > Keith > > Keith Drage > Lucent Technologies > drage@lucent.com > tel: +44 1793 776249 > > > > -----Original Message----- > > From: Arnoud van Wijk [mailto:a.vwijk@viataal.nl] > > Sent: 04 July 2004 10:43 > > To: hisham.khartabil@nokia.com; paulej@packetizer.com; > > pkyzivat@cisco.com; Guido.Gybels@rnid.org.uk > > Cc: fluffy@cisco.com; simple@ietf.org; gv@trace.wisc.edu; > > toip@snowshore.com; gunnar.hellstrom@omnitor.se; smundra@telogy.com > > Subject: RE: [Simple] RE: [Sipping] RE: text/T140 andaudio/t140 > > was:[avt]Comments/questions on draft-ietf-av > > > > > > Never say never. > > Have you tried interactive text/real-time text? > > Did you? > > > > First try it and THEN you can say if you like it or not. > > > > If you want to determine how useful it is. Test it. > > Use it > > Try it > > Compare it with IM. > > See the differences between IM and RTT/Interactive text. > > See that both text communication methods have their advantages and > > disadvantages. > > And use both for the best situations. > > > > And if you still don't want to use RTT/Interactive > > text..fine..I just hope > > that when I call you, that you can still receive my call. > > Just use it only > > when the other person uses Interactive text/RTT. > > Even if it is then 3-4 times per year. > > > > Can you with IM: > > * directly call the other? > > * forward the call? > > * put on hold? > > * have the call go to multiple terminals? > > * not being logged on a buddy list server, where you may get > > flooded by 20 > > users at the same time saying hi! And such? > > * being able to leave a message on an answering machine? > > * using a service that allows a ring notifivation as soon the > > other user is > > ready with his/her other phonecall? (ring back on busy). > > > > There are more.. but I am unfamiliar with voice calls. I am > > just enjoying my > > freedom of communications beyond the IM limitations. > > > > And I enjoy using IM also..even though I am forced to use > > Trillian, since > > there is NO one universal standard for IM right now! > > > > Interactive text is! > > > > Greetz > > > > Arnoud > > > > > > _______________________________________________ > Simple mailing 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 Sun Jul 18 09:19: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 JAA08141 for ; Sun, 18 Jul 2004 09:19: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 1BmBZG-00036Q-I8 for simple-archive@ietf.org; Sun, 18 Jul 2004 09:19:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BmBYJ-0002tf-00 for simple-archive@ietf.org; Sun, 18 Jul 2004 09:18:04 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BmBXo-0002gc-00; Sun, 18 Jul 2004 09:17:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BmBVM-0000OD-TG; Sun, 18 Jul 2004 09:15:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BmBUQ-0000IP-BF for simple@megatron.ietf.org; Sun, 18 Jul 2004 09:14: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 JAA07995 for ; Sun, 18 Jul 2004 09:14: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 1BmBUP-00024p-Fp for simple@ietf.org; Sun, 18 Jul 2004 09:14:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BmBTf-0001sW-00 for simple@ietf.org; Sun, 18 Jul 2004 09:13:16 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BmBTG-0001fp-00; Sun, 18 Jul 2004 09:12:50 -0400 Received: from dynamicsoft.com ([63.113.46.12]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i6IDCcGr004330; Sun, 18 Jul 2004 09:12:39 -0400 (EDT) Message-ID: <40FA7733.9000501@dynamicsoft.com> Date: Sun, 18 Jul 2004 09:12:19 -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: "'geopriv@ietf.org'" , Simple WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] common policy/ common policy caps schema issue X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.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,NEW_DOMAIN_EXTENSIONS autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Folks, While revising draft-rosenberg-simple-common-policy-caps, I ran into an issue in the schema design which I believe affects the documents developed in both simple and geopriv that make use of the XML schema substitutionGroup concept. The idea with a substitution group is that you could declare one element as a substitute for another. This would seemingly allow us to extend common policy or common policy caps with new policies/capabilities, and declare them to be conditions, actions, or transformations. And indeed, it does do this. However, there is a problem. The problem is that, when you create such an extension, you need to create a new schema that includes these extensions, and then specify that documents have to compliant to this new schema. This creates a major problem in systems where you want to develop independent extensions to the schema. Let me give an example. Lets say we have a base schema S1, which contains elements in the namespace N1. One group decides to add some new elements using substitution groups, so it creates schema S2, with elements in namespace N2 declared as substitutes for the right elements in S1. S2 will need to import S1, since the head element of the substitution group is defined there. Similarly, another group decides to add some new elements. So, it creates schema S3, with elements in namespace N3, declared as substitutes for elements in S1. S3 also imports S1, for the same reason. Now, a server or client wish to implement both extensions. So, it creates a document with elements from N1, N2 and N3. Which schema is this document compliant to? None of them! Take a look at each in turn: S1: the elements from N2 and N3 are in the instance document, but are not defined in S1. Since S1 was using substitution groups, it's schema doesn't have defined in its schema. Elements not defined in the schema cnanot be included. Thus, the document is not valid according to S1. S2: The elements from N3 are not defined in S2. S2, like S1, won't have declarations, so these elements are not allowed and the docuemnt is not valid. S3: The elements from N2 are not defined in S3. S3, like S1, won't have declarations, so these elements are not allowed and the docuemnt is not valid. If we go ahead and add declarations to S1, we will allow any kind of element to be added, thus defeating the constraint that we wanted with the substitution group. So, my conclusion was that substitution groups were useful in schemas where a single chain of extensions would be developed, and each new extension would include elements from the previous. Thus, you "extend" the schema by basically revising it and including new elements in the revised version. This is a valid model of extensibility in some environments, but I think we want a model that supports more distributed extensibility, where each extensions doesnt need to know about the other. The only way I know to do this is to remove the usage of substitution groups, and use the construct. This does mean that the schema validation cannot verify that new conditions, actions or transformations are appropriately placed in the document. But, I think this is the price we need to pay for the extensibility we need. Does anyone have a better idea? 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 Jul 18 09: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 JAA08499 for ; Sun, 18 Jul 2004 09: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 1BmBh4-0004nC-Tr for simple-archive@ietf.org; Sun, 18 Jul 2004 09:27:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BmBgR-0004a6-00 for simple-archive@ietf.org; Sun, 18 Jul 2004 09:26:29 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BmBfi-0004M3-00; Sun, 18 Jul 2004 09:25:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BmBeg-00016A-HT; Sun, 18 Jul 2004 09:24:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BmBXF-0000XG-MS for simple@megatron.ietf.org; Sun, 18 Jul 2004 09: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 JAA08064 for ; Sun, 18 Jul 2004 09:16: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 1BmBXE-0002fk-Vp for simple@ietf.org; Sun, 18 Jul 2004 09:16:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BmBWG-0002T9-00 for simple@ietf.org; Sun, 18 Jul 2004 09:15:57 -0400 Received: from hoemail1.lucent.com ([192.11.226.161]) by ietf-mx with esmtp (Exim 4.12) id 1BmBVD-00025N-00 for simple@ietf.org; Sun, 18 Jul 2004 09:14:51 -0400 Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id i6IDEmPK024706 for ; Sun, 18 Jul 2004 08:14:49 -0500 (CDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Sun, 18 Jul 2004 14:14:48 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB00C9F883E@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: Eric Burger , simple@ietf.org Subject: RE: Suggested RTT text (was RE: [Simple] RE: [Sipping] RE: text/T 140 andaudio/t140) Date: Sun, 18 Jul 2004 14:14:41 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Cc: "Drage, Keith \(Keith\)" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org 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 Sorry but NO. MSRP is the protocol definition, not the characteristics of an end device that may implement MSRP, and therefore should be independent of whether the UA is end user terminal, gateway or whatever. Additionally they are totally out of the current scope (abstract in IETF terms because they do not define MSRP). These words you have just proposed affect all UA and proxy implementations. If you want these words, put it in a device specification, and not the core MSRP definition. regards Keith > -----Original Message----- > From: Eric Burger [mailto:eburger@brooktrout.com] > Sent: 18 July 2004 07:33 > To: simple@ietf.org > Cc: Drage, Keith (Keith) > Subject: Suggested RTT text (was RE: [Simple] RE: [Sipping] RE: > text/T140 andaudio/t140) > > > After 420 pages of "discussion", may I humbly propose the > following text for > the MSRP document: > > User interfaces and user communities for instant messaging > and real-time > text telephony are extremely similar. MSRP is not an ideal > protocol for the > negotiation and transport of real-time text. However, devices that > implement MRSP SHOULD implement real-time text telephony, > using standard SIP > (RFC3261) and text/t140 (RFC2793bis) mechanisms. > > > > Rationale: > 1. It looks like consensus to putting RTP under MSRP is far, > far, away, > assuming it even makes sense, which it probably doesn't. > > 2. A whole bunch (80%?) of the code for an IM device would be > shared with a > RTT device - character input, character display, Internet > connectivity, SIP > stack, etc. > > 3. We have a charter obligation to make protocols amenable to building > devices that are accessible to everyone. > > This is an opportunity to meet the objections to trying to > shoehorn RTT into > MSRP (#1) with our Charter obligations (#3) without an undue > burden on the > implementer (#2). > > > -----Original Message----- > > From: Drage, Keith (Keith) [mailto:drage@lucent.com] > > Sent: Monday, July 05, 2004 5:54 AM > > To: simple@ietf.org > > Subject: RE: [Simple] RE: [Sipping] RE: text/T140 andaudio/t140 > > was:[avt]C omments/questions on draft-ietf-av > > > > > > Given the length of time this discussion has been going on, > > and the number of messages exchanged, is it not about time we > > reached some conclusions. These lists are to advance the > > deliverables in the working groups concerned, so how do any > > conclusions affect those deliverables. > > > > SIMPLE has a charter to produce instant messaging protocols. > > I do not see in all the discussion of the advantages of > > instant messaging versus real-time text removing that charter > > item. Therefore I suggest we STOP that discussion, or the > > proponents move it elsewhere. > > > > SIMPLE does not have a charter item to produce real-time text > > protocols. There is already an existing capability in IETF > > for real-time text protocols. It is not really up to SIMPLE > > to discuss whether that works well or not, as it was not > > developed under SIMPLEs charter. > > > > How terminals mix and match applications is not something > > that IETF traditionally deals with. Therefore I would suggest > > that any requirements that state RTT and IM must be > > implemented in the same terminal are out of scope of IETF. > > They should certainly be in some device specification rather > > than in the MSRP specification which SIMPLE is specifically > > delivering. > > > > I guess the questions as affecting MSRP really fall down to these: > > > > - Are there capabilities in MSRP that would lead to a > > valid RTT protocol that works better than the existing IETF > > solution, in addition to it fulfilling the requirements to > > provide an IM protocol. From the exchange of messages I have > > seem so far, it seems to me that the conclusion should be NO. > > > > - In order to deal with a body of users that have IM, and > > prefer to use IM, and a body of users that have RTT, and > > prefer to use RTT, is there a need to be able to interwork > > the two protocols at some intermediate point, and not just > > within the terminal by supporting both protocols under a > > common user interface? I see that as an element of the > > discussion just raised by Paul. Does such interworking, if > > required, have any impact on the contents of MSRP? > > > > regards > > > > Keith > > > > Keith Drage > > Lucent Technologies > > drage@lucent.com > > tel: +44 1793 776249 > > > > > > > -----Original Message----- > > > From: Arnoud van Wijk [mailto:a.vwijk@viataal.nl] > > > Sent: 04 July 2004 10:43 > > > To: hisham.khartabil@nokia.com; paulej@packetizer.com; > > > pkyzivat@cisco.com; Guido.Gybels@rnid.org.uk > > > Cc: fluffy@cisco.com; simple@ietf.org; gv@trace.wisc.edu; > > > toip@snowshore.com; gunnar.hellstrom@omnitor.se; > smundra@telogy.com > > > Subject: RE: [Simple] RE: [Sipping] RE: text/T140 andaudio/t140 > > > was:[avt]Comments/questions on draft-ietf-av > > > > > > > > > Never say never. > > > Have you tried interactive text/real-time text? > > > Did you? > > > > > > First try it and THEN you can say if you like it or not. > > > > > > If you want to determine how useful it is. Test it. > > > Use it > > > Try it > > > Compare it with IM. > > > See the differences between IM and RTT/Interactive text. > > > See that both text communication methods have their advantages and > > > disadvantages. > > > And use both for the best situations. > > > > > > And if you still don't want to use RTT/Interactive > > > text..fine..I just hope > > > that when I call you, that you can still receive my call. > > > Just use it only > > > when the other person uses Interactive text/RTT. > > > Even if it is then 3-4 times per year. > > > > > > Can you with IM: > > > * directly call the other? > > > * forward the call? > > > * put on hold? > > > * have the call go to multiple terminals? > > > * not being logged on a buddy list server, where you may get > > > flooded by 20 > > > users at the same time saying hi! And such? > > > * being able to leave a message on an answering machine? > > > * using a service that allows a ring notifivation as soon the > > > other user is > > > ready with his/her other phonecall? (ring back on busy). > > > > > > There are more.. but I am unfamiliar with voice calls. I am > > > just enjoying my > > > freedom of communications beyond the IM limitations. > > > > > > And I enjoy using IM also..even though I am forced to use > > > Trillian, since > > > there is NO one universal standard for IM right now! > > > > > > Interactive text is! > > > > > > Greetz > > > > > > Arnoud > > > > > > > > > > _______________________________________________ > > Simple mailing 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 Sun Jul 18 10:22: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 KAA11702 for ; Sun, 18 Jul 2004 10:22: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 1BmCYE-0000bx-94 for simple-archive@ietf.org; Sun, 18 Jul 2004 10:22:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BmCXH-0000PJ-00 for simple-archive@ietf.org; Sun, 18 Jul 2004 10:21:04 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BmCWW-00000a-00; Sun, 18 Jul 2004 10:20:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BmCS0-00034v-FW; Sun, 18 Jul 2004 10: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 1BmCQV-0002ai-5x for simple@megatron.ietf.org; Sun, 18 Jul 2004 10:14: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 KAA11137 for ; Sun, 18 Jul 2004 10:14: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 1BmCQU-0006m4-G4 for simple@ietf.org; Sun, 18 Jul 2004 10:14:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BmCPc-0006Zr-00 for simple@ietf.org; Sun, 18 Jul 2004 10:13:09 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BmCOm-0006BP-00; Sun, 18 Jul 2004 10:12:16 -0400 Received: from dynamicsoft.com ([63.113.46.12]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i6IEC5Gr004348; Sun, 18 Jul 2004 10:12:05 -0400 (EDT) Message-ID: <40FA8521.5040202@dynamicsoft.com> Date: Sun, 18 Jul 2004 10:11:45 -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 Cc: "'geopriv@ietf.org'" Subject: [Simple] updated common policy capabilities 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: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org 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 just submitted an update to the common policy capabilities document. THis spec defines a common format for representing policy capabilities, and is used by: http://www.ietf.org/internet-drafts/draft-rosenberg-simple-pres-policy-caps-00.txt http://www.ietf.org/internet-drafts/draft-guenther-geopriv-policy-caps-00.txt Until it appears, you can pick up a copy at: http://www.jdrosen.net/papers/draft-rosenberg-simple-common-policy-caps-01.txt Here are the changes: * no longer using substitution groups for extensibility (see my other post on this topic) * removed "supported permissions" terminology; consistently "policy capabilities" * namespace change to urn:ietf:params:xml:ns:policy-capabilities * added MIME type registration application/policy-caps+xml * Removed element, aligning with latest common-policy document * Updated example, validated it * Aligned application usage terminology and requirements with latest xcap document * fixed up schema registration - requesting URN instead of asking for IANA assignment * update to rfc3668 boilerplate Though this is still an individual I-D, there was agreement in simple that this would be a work item of the simple group. I just needed the extra week to revise it :(. There are no issues with this document that I am aware of. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sun Jul 18 11:22: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 LAA14525 for ; Sun, 18 Jul 2004 11:22: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 1BmDUO-0005c7-7T for simple-archive@ietf.org; Sun, 18 Jul 2004 11:22:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BmDTS-0005PR-00 for simple-archive@ietf.org; Sun, 18 Jul 2004 11:21:11 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BmDSw-0005Bk-00; Sun, 18 Jul 2004 11:20:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BmDQE-0001gB-4n; Sun, 18 Jul 2004 11:17:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BmDOg-0001Nl-F1 for simple@megatron.ietf.org; Sun, 18 Jul 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 LAA14239 for ; Sun, 18 Jul 2004 11:16: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 1BmDOf-0004Fg-Mh for simple@ietf.org; Sun, 18 Jul 2004 11:16:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BmDMg-0003sM-00 for simple@ietf.org; Sun, 18 Jul 2004 11:14:11 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1BmDM7-0003ft-00 for simple@ietf.org; Sun, 18 Jul 2004 11:13:35 -0400 Received: from [192.168.1.100] (c-67-164-133-175.client.comcast.net [67.164.133.175]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id i6IFDSKO067199 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Sun, 18 Jul 2004 10:13:29 -0500 (CDT) (envelope-from ben@nostrum.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <0520FA0A-D8CD-11D8-93B7-000D93B0AE1A@nostrum.com> Content-Transfer-Encoding: 7bit From: Ben Campbell Subject: Re: [Simple] MSRP chunking and MIME fragmentation Date: Sun, 18 Jul 2004 10:13:27 -0500 To: Eric Burger X-Mailer: Apple Mail (2.618) 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 In the forthcoming draft, we have removed the dependency on multipart/byteranges to support chunking. Therefore the text you mention is no longer relevant. On Jul 18, 2004, at 1:33 AM, Eric Burger wrote: > Last I looked, MSRP is a transport protocol. Thus, I don't understand > the > normative statement in Section 6.3.1: > > "The sender MUST NOT include a completion-flag of "+" if the payload > MIME > type does not support content fragmentation." > > Is not the User Agent Server buffering and reconstructing messages? > That > said, if it does, we should point out in the security considerations > section > that someone can say they are sending a fragmented message and then > never > send anything again, holding resources forever at the UAS. > > If the UAS is not buffering and reconstructing messages, and we are > saying > you can only send things like "message/partial", there is no MSRP > fragmentation: MSRP only EVER sends complete MIME objects. > > Given the usefulness of sending chunks as a proxy for streaming, I > would > suggest just dropping the normative statement. > > _______________________________________________ > Simple mailing 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 Sun Jul 18 11:23: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 LAA14572 for ; Sun, 18 Jul 2004 11:23: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 1BmDVI-0005p9-HC for simple-archive@ietf.org; Sun, 18 Jul 2004 11:23:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BmDUS-0005ce-00 for simple-archive@ietf.org; Sun, 18 Jul 2004 11:22:12 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BmDTa-0005Cw-00; Sun, 18 Jul 2004 11:21:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BmDQM-0001kW-MG; Sun, 18 Jul 2004 11:17:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BmDOk-0001Q1-0d for simple@megatron.ietf.org; Sun, 18 Jul 2004 11:16: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 LAA14249 for ; Sun, 18 Jul 2004 11:16: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 1BmDOj-0004GI-9D for simple@ietf.org; Sun, 18 Jul 2004 11:16:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BmDNl-00043z-00 for simple@ietf.org; Sun, 18 Jul 2004 11:15:17 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1BmDMZ-0003rI-00 for simple@ietf.org; Sun, 18 Jul 2004 11:14:03 -0400 Received: from [192.168.1.100] (c-67-164-133-175.client.comcast.net [67.164.133.175]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id i6IFDSKP067199 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Sun, 18 Jul 2004 10:14:01 -0500 (CDT) (envelope-from ben@nostrum.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <198C902E-D8CD-11D8-93B7-000D93B0AE1A@nostrum.com> Content-Transfer-Encoding: 7bit From: Ben Campbell Subject: Re: [Simple] UAS behavior in MSRP session initiation Date: Sun, 18 Jul 2004 10:14:01 -0500 To: Eric Burger X-Mailer: Apple Mail (2.618) 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 I believe that statement has been removed from the forthcoming draft. On Jul 18, 2004, at 1:33 AM, Eric Burger wrote: > In section 6.5.1, step 4 of the answerer (UAS) states that if there > are no > relays, the UAS does not need to listen for a connection. Doesn't the > UAS > need to listen for a connection from the relay? Or, are we assuming > that > the relay connection is established, *in both directions* upon relay > contact? If so, say so. > > _______________________________________________ > Simple mailing 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 Sun Jul 18 11:26: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 LAA14737 for ; Sun, 18 Jul 2004 11:26: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 1BmDYQ-0006U8-3l for simple-archive@ietf.org; Sun, 18 Jul 2004 11:26:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BmDXK-0006FL-00 for simple-archive@ietf.org; Sun, 18 Jul 2004 11:25:10 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BmDWR-0005qY-00; Sun, 18 Jul 2004 11: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 1BmDUk-0002FS-QA; Sun, 18 Jul 2004 11:22:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BmDRf-0001pw-Gt for simple@megatron.ietf.org; Sun, 18 Jul 2004 11:19: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 LAA14398 for ; Sun, 18 Jul 2004 11:19: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 1BmDRe-0004zE-PC for simple@ietf.org; Sun, 18 Jul 2004 11:19:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BmDQq-0004l3-00 for simple@ietf.org; Sun, 18 Jul 2004 11:18:29 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1BmDQA-0004WG-00 for simple@ietf.org; Sun, 18 Jul 2004 11:17:46 -0400 Received: from [192.168.1.100] (c-67-164-133-175.client.comcast.net [67.164.133.175]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id i6IFHddg067561 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Sun, 18 Jul 2004 10:17:40 -0500 (CDT) (envelope-from ben@nostrum.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <9AEECB8E-D8CD-11D8-93B7-000D93B0AE1A@nostrum.com> Content-Transfer-Encoding: 7bit From: Ben Campbell Subject: Re: [Simple] MSRP Message Types Date: Sun, 18 Jul 2004 10:17:38 -0500 To: Eric Burger X-Mailer: Apple Mail (2.618) Content-Transfer-Encoding: 7bit Cc: simple@ietf.org, "Ben Campbell \(E-mail\)" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org 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 On Jul 18, 2004, at 1:33 AM, Eric Burger wrote: > Section 5.1: > The last line of the section gives an example of an m-line that > specifies > reception of "message/cpim, plain text or HTML". > > First, shouldn't it be "message/cpim, message/text, or message/html"? > It should at least be consistent, either using descriptive terms for each or MIME content-types for each. > Second, the example is an unadorned: > m=message 9999 msrp * > > Is the reason that plain text and html are accepted because they are > defaults, or because the example is missing the a-lines? Clarify the > text. > If the example is missing the a-lines, it was a typo. > _______________________________________________ > Simple mailing 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 Sun Jul 18 11:29: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 LAA14895 for ; Sun, 18 Jul 2004 11:29: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 1BmDbC-00078K-Nx for simple-archive@ietf.org; Sun, 18 Jul 2004 11:29:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BmDaG-0006vO-00 for simple-archive@ietf.org; Sun, 18 Jul 2004 11:28:13 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BmDZg-0006ga-00; Sun, 18 Jul 2004 11:27:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BmDVc-0002M1-OB; Sun, 18 Jul 2004 11:23:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BmDUJ-0002EE-LC for simple@megatron.ietf.org; Sun, 18 Jul 2004 11:22: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 LAA14501 for ; Sun, 18 Jul 2004 11:22: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 1BmDUI-0005bX-ON for simple@ietf.org; Sun, 18 Jul 2004 11:22:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BmDTM-0005OT-00 for simple@ietf.org; Sun, 18 Jul 2004 11:21:04 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1BmDSU-0005Bz-00 for simple@ietf.org; Sun, 18 Jul 2004 11:20:10 -0400 Received: from [192.168.1.100] (c-67-164-133-175.client.comcast.net [67.164.133.175]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id i6IFK7n2067721 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Sun, 18 Jul 2004 10:20:08 -0500 (CDT) (envelope-from ben@nostrum.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ben Campbell Subject: Re: [Simple] MSRP DSN Status codes Date: Sun, 18 Jul 2004 10:20:07 -0500 To: Eric Burger X-Mailer: Apple Mail (2.618) Content-Transfer-Encoding: 7bit Cc: simple@ietf.org, "Ben Campbell \(E-mail\)" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org 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 On Jul 18, 2004, at 1:33 AM, Eric Burger wrote: > I still don't get it. The purpose of a DSN status code is to let you > know > that the delivery failed and why in an environment where you don't > have a > *direct* connection to the recipient. > > Clearly, DSN is a relay ONLY thing. Why? Because section 6.6.5.7 > goes to > great lengths to say that a 200 OK response becomes a 2.0.0. > > This is insane. You would get the 200 OK response, and know the > message was > delivered. End of story. > > In a failure mode, you would get the 500 response, or just not get one. > > If we're talking relays here, then why are relays not proxies, issuing > 100-class responses to message accepted for relay and 200-, 500-, > timeout, > or whatever they get from upstream upon failure? That would make the > whole > REPORT thing obsolete and keep everything within MSRP. > Failure reports are primarily a relay thing, but all endpoints have to know to expect them. Relays do not wait for downstream transactions because we wanted to avoid the timing issues that crop up in SIP for long relay chains. MSRP relays work more like SMTP relays than they do SIP proxies. > _______________________________________________ > Simple mailing 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 Sun Jul 18 11:38: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 LAA15281 for ; Sun, 18 Jul 2004 11:38: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 1BmDjt-0001Ib-Ju for simple-archive@ietf.org; Sun, 18 Jul 2004 11:38:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BmDix-000163-00 for simple-archive@ietf.org; Sun, 18 Jul 2004 11:37:12 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BmDic-0000tY-00; Sun, 18 Jul 2004 11:36:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BmDa4-0002v8-Sy; Sun, 18 Jul 2004 11:28:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BmDWG-0002UA-II for simple@megatron.ietf.org; Sun, 18 Jul 2004 11:24: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 LAA14637 for ; Sun, 18 Jul 2004 11:24: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 1BmDWF-00061v-OE for simple@ietf.org; Sun, 18 Jul 2004 11:24:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BmDVF-0005or-00 for simple@ietf.org; Sun, 18 Jul 2004 11:23:02 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1BmDUH-0005bB-00 for simple@ietf.org; Sun, 18 Jul 2004 11:22:02 -0400 Received: from [192.168.1.100] (c-67-164-133-175.client.comcast.net [67.164.133.175]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id i6IFLw6B067901 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Sun, 18 Jul 2004 10:21:59 -0500 (CDT) (envelope-from ben@nostrum.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <35A7ABB2-D8CE-11D8-93B7-000D93B0AE1A@nostrum.com> Content-Transfer-Encoding: 7bit From: Ben Campbell Subject: Re: Suggested RTT text (was RE: [Simple] RE: [Sipping] RE: text/T140 andaudio/t140) Date: Sun, 18 Jul 2004 10:21:58 -0500 To: Eric Burger X-Mailer: Apple Mail (2.618) Content-Transfer-Encoding: 7bit Cc: "Drage, Keith \(Keith\)" , 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 think that sort of statement belongs in the (apparently now dormant) SIMPLE architecture document, not in MSRP. On Jul 18, 2004, at 1:32 AM, Eric Burger wrote: > After 420 pages of "discussion", may I humbly propose the following > text for > the MSRP document: > > User interfaces and user communities for instant messaging and > real-time > text telephony are extremely similar. MSRP is not an ideal protocol > for the > negotiation and transport of real-time text. However, devices that > implement MRSP SHOULD implement real-time text telephony, using > standard SIP > (RFC3261) and text/t140 (RFC2793bis) mechanisms. > > > > Rationale: > 1. It looks like consensus to putting RTP under MSRP is far, far, away, > assuming it even makes sense, which it probably doesn't. > > 2. A whole bunch (80%?) of the code for an IM device would be shared > with a > RTT device - character input, character display, Internet > connectivity, SIP > stack, etc. > > 3. We have a charter obligation to make protocols amenable to building > devices that are accessible to everyone. > > This is an opportunity to meet the objections to trying to shoehorn > RTT into > MSRP (#1) with our Charter obligations (#3) without an undue burden on > the > implementer (#2). > >> -----Original Message----- >> From: Drage, Keith (Keith) [mailto:drage@lucent.com] >> Sent: Monday, July 05, 2004 5:54 AM >> To: simple@ietf.org >> Subject: RE: [Simple] RE: [Sipping] RE: text/T140 andaudio/t140 >> was:[avt]C omments/questions on draft-ietf-av >> >> >> Given the length of time this discussion has been going on, >> and the number of messages exchanged, is it not about time we >> reached some conclusions. These lists are to advance the >> deliverables in the working groups concerned, so how do any >> conclusions affect those deliverables. >> >> SIMPLE has a charter to produce instant messaging protocols. >> I do not see in all the discussion of the advantages of >> instant messaging versus real-time text removing that charter >> item. Therefore I suggest we STOP that discussion, or the >> proponents move it elsewhere. >> >> SIMPLE does not have a charter item to produce real-time text >> protocols. There is already an existing capability in IETF >> for real-time text protocols. It is not really up to SIMPLE >> to discuss whether that works well or not, as it was not >> developed under SIMPLEs charter. >> >> How terminals mix and match applications is not something >> that IETF traditionally deals with. Therefore I would suggest >> that any requirements that state RTT and IM must be >> implemented in the same terminal are out of scope of IETF. >> They should certainly be in some device specification rather >> than in the MSRP specification which SIMPLE is specifically >> delivering. >> >> I guess the questions as affecting MSRP really fall down to these: >> >> - Are there capabilities in MSRP that would lead to a >> valid RTT protocol that works better than the existing IETF >> solution, in addition to it fulfilling the requirements to >> provide an IM protocol. From the exchange of messages I have >> seem so far, it seems to me that the conclusion should be NO. >> >> - In order to deal with a body of users that have IM, and >> prefer to use IM, and a body of users that have RTT, and >> prefer to use RTT, is there a need to be able to interwork >> the two protocols at some intermediate point, and not just >> within the terminal by supporting both protocols under a >> common user interface? I see that as an element of the >> discussion just raised by Paul. Does such interworking, if >> required, have any impact on the contents of MSRP? >> >> regards >> >> Keith >> >> Keith Drage >> Lucent Technologies >> drage@lucent.com >> tel: +44 1793 776249 >> >> >>> -----Original Message----- >>> From: Arnoud van Wijk [mailto:a.vwijk@viataal.nl] >>> Sent: 04 July 2004 10:43 >>> To: hisham.khartabil@nokia.com; paulej@packetizer.com; >>> pkyzivat@cisco.com; Guido.Gybels@rnid.org.uk >>> Cc: fluffy@cisco.com; simple@ietf.org; gv@trace.wisc.edu; >>> toip@snowshore.com; gunnar.hellstrom@omnitor.se; smundra@telogy.com >>> Subject: RE: [Simple] RE: [Sipping] RE: text/T140 andaudio/t140 >>> was:[avt]Comments/questions on draft-ietf-av >>> >>> >>> Never say never. >>> Have you tried interactive text/real-time text? >>> Did you? >>> >>> First try it and THEN you can say if you like it or not. >>> >>> If you want to determine how useful it is. Test it. >>> Use it >>> Try it >>> Compare it with IM. >>> See the differences between IM and RTT/Interactive text. >>> See that both text communication methods have their advantages and >>> disadvantages. >>> And use both for the best situations. >>> >>> And if you still don't want to use RTT/Interactive >>> text..fine..I just hope >>> that when I call you, that you can still receive my call. >>> Just use it only >>> when the other person uses Interactive text/RTT. >>> Even if it is then 3-4 times per year. >>> >>> Can you with IM: >>> * directly call the other? >>> * forward the call? >>> * put on hold? >>> * have the call go to multiple terminals? >>> * not being logged on a buddy list server, where you may get >>> flooded by 20 >>> users at the same time saying hi! And such? >>> * being able to leave a message on an answering machine? >>> * using a service that allows a ring notifivation as soon the >>> other user is >>> ready with his/her other phonecall? (ring back on busy). >>> >>> There are more.. but I am unfamiliar with voice calls. I am >>> just enjoying my >>> freedom of communications beyond the IM limitations. >>> >>> And I enjoy using IM also..even though I am forced to use >>> Trillian, since >>> there is NO one universal standard for IM right now! >>> >>> Interactive text is! >>> >>> Greetz >>> >>> Arnoud >>> >>> >> >> _______________________________________________ >> Simple mailing 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 Sun Jul 18 11:40: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 LAA15368 for ; Sun, 18 Jul 2004 11:40: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 1BmDlp-0001jp-Ql for simple-archive@ietf.org; Sun, 18 Jul 2004 11:40:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BmDkl-0001VE-00 for simple-archive@ietf.org; Sun, 18 Jul 2004 11:39:03 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BmDjm-00016R-00; Sun, 18 Jul 2004 11:38:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BmDa5-0002vD-8e; Sun, 18 Jul 2004 11:28:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BmDWJ-0002UE-M7 for simple@megatron.ietf.org; Sun, 18 Jul 2004 11:24: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 LAA14647 for ; Sun, 18 Jul 2004 11:24: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 1BmDWI-00062H-UB for simple@ietf.org; Sun, 18 Jul 2004 11:24:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BmDVP-0005qB-00 for simple@ietf.org; Sun, 18 Jul 2004 11:23:12 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1BmDUr-0005dj-00 for simple@ietf.org; Sun, 18 Jul 2004 11:22:37 -0400 Received: from [192.168.1.100] (c-67-164-133-175.client.comcast.net [67.164.133.175]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id i6IFLw6C067901 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Sun, 18 Jul 2004 10:22:31 -0500 (CDT) (envelope-from ben@nostrum.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <496D910A-D8CE-11D8-93B7-000D93B0AE1A@nostrum.com> Content-Transfer-Encoding: 7bit From: Ben Campbell Subject: Re: [Simple] MSRP Boundary header Date: Sun, 18 Jul 2004 10:22:31 -0500 To: Eric Burger X-Mailer: Apple Mail (2.618) Content-Transfer-Encoding: 7bit Cc: Cullen Jennings , 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=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit The forthcoming revision has text to that effect. On Jul 18, 2004, at 1:32 AM, Eric Burger wrote: > This should be a NOTE in the text. > >> -----Original Message----- >> From: Cullen Jennings [mailto:fluffy@cisco.com] >> Sent: Tuesday, June 29, 2004 11:08 PM >> To: Vijay Hampapur Hampapur Parthasarathy; Ben Campbell >> Cc: simple@ietf.org >> Subject: Re: [Simple] MSRP Boundary header >> > [snip] >> >> 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. > [snip] > > _______________________________________________ > Simple mailing 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 Sun Jul 18 11:40: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 LAA15416 for ; Sun, 18 Jul 2004 11: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 1BmDm1-0001lC-Pe for simple-archive@ietf.org; Sun, 18 Jul 2004 11:40:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BmDky-0001X6-00 for simple-archive@ietf.org; Sun, 18 Jul 2004 11:39:17 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BmDkQ-0001J2-00; Sun, 18 Jul 2004 11:38:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BmDbc-00031i-Q5; Sun, 18 Jul 2004 11:29:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BmDZ9-0002ls-49 for simple@megatron.ietf.org; Sun, 18 Jul 2004 11:27: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 LAA14782 for ; Sun, 18 Jul 2004 11:27: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 1BmDZ8-0006g9-CZ for simple@ietf.org; Sun, 18 Jul 2004 11:27:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BmDY9-0006Rg-00 for simple@ietf.org; Sun, 18 Jul 2004 11:26:02 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1BmDX8-00066R-00 for simple@ietf.org; Sun, 18 Jul 2004 11:24:58 -0400 Received: from [192.168.1.100] (c-67-164-133-175.client.comcast.net [67.164.133.175]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id i6IFOr2D068286 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Sun, 18 Jul 2004 10:24:54 -0500 (CDT) (envelope-from ben@nostrum.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <9DD1348A-D8CE-11D8-93B7-000D93B0AE1A@nostrum.com> Content-Transfer-Encoding: 7bit From: Ben Campbell Subject: Re: [Simple] MSRP: Miscellaneous REPORT issues Date: Sun, 18 Jul 2004 10:24:52 -0500 To: Eric Burger X-Mailer: Apple Mail (2.618) Content-Transfer-Encoding: 7bit Cc: Chris Boulton , 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=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit The forthcoming draft adds a Status header field to the REPORT method, and makes the use of DSN optional. There has been some question, recently, whether we need DSN at all. For the amount of information carried in the DSN, it would not be too big an effort to make optional REPORT method headers that can carry the same thing, and have it better matched to MSRP. On Jul 18, 2004, at 1:33 AM, Eric Burger wrote: > I can live with DSN bodies being optional, so long as the normative > language > is that no body means EITHER success OR failure. Personally, I'm > leaning > toward no body for success because you want information for failure. > > We MUST, MUST, MUST chose one and only one meaning for no body. > Having an > empty body sometimes mean success and other times mean failure is a > recipe > for major interpretation, and thus interop, failure. > > That said, in the MOST STRONG SENSE POSSIBLE I suggest AGAINST having > multiple DSN report types. That is an invitation for proprietary > report > formats EVERYWHERE, making the goal of interoperability evaporate. > > If the DSN format is too "heavyweight", then chose something other than > RFC1894. I hear ASN.1 makes pretty compact messages x-\ > > > By the way, in Section 6.6.2, a device that SHOULD generate DSN's > cannot > MUST generate them. Either they MUST or SHOULD. > > Also, a DSN MUST NOT have a Message-Receipt header. Have to put that > in the > security considerations section, too. > >> -----Original Message----- >> From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] >> Sent: Monday, June 28, 2004 4:21 PM >> To: Simple WG >> Cc: Cullen Jennings; Rohan Mahy; Adam Roach; Hisham Khartabil; Robert >> Sparks; Chris Boulton >> Subject: [Simple] MSRP: Miscellaneous REPORT issues >> >> >> 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 >> > > _______________________________________________ > Simple mailing 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 Sun Jul 18 13:06: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 NAA20534 for ; Sun, 18 Jul 2004 13:06: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 1BmF76-0004xN-2b for simple-archive@ietf.org; Sun, 18 Jul 2004 13:06:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BmF6A-0004j8-00 for simple-archive@ietf.org; Sun, 18 Jul 2004 13:05:14 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BmF5E-0004IL-00; Sun, 18 Jul 2004 13:04:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BmEvd-0005qf-PF; Sun, 18 Jul 2004 12:54:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BmEt3-0005Bt-B1 for simple@megatron.ietf.org; Sun, 18 Jul 2004 12:51: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 MAA19808 for ; Sun, 18 Jul 2004 12:51: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 1BmEt2-0001nR-8O for simple@ietf.org; Sun, 18 Jul 2004 12:51:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BmErG-00015N-00 for simple@ietf.org; Sun, 18 Jul 2004 12:49:51 -0400 Received: from smtp017.mail.yahoo.com ([216.136.174.114]) by ietf-mx with smtp (Exim 4.12) id 1BmEpS-0000X5-00 for simple@ietf.org; Sun, 18 Jul 2004 12:47:58 -0400 Received: from unknown (HELO cranberry) (seancolson@4.41.208.58 with login) by smtp017.mail.yahoo.com with SMTP; 18 Jul 2004 16:47:57 -0000 From: "Sean Olson" To: "'Eric Burger'" Subject: RE: Chunking driver (was RE: [Simple] MSRP Boundary header) Date: Sun, 18 Jul 2004 09:48:03 -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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcRskhlgt3TicpU8RAGZHSZNUhswgQAVH1/w In-Reply-To: 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 Perfect. Move that number to 8K. That just makes the argument stronger. The point is that you can make an intelligent decision about the dividing line between where to chunk and where not to. Of course in that 8K packet, you are likely to put quite a few small IMs (for the relay and MCU scnearios). Which is even more reason not mess with scanning for a boundary. -----Original Message----- From: Eric Burger [mailto:eburger@brooktrout.com] Sent: Saturday, July 17, 2004 11:33 PM To: seancolson@yahoo.com Cc: simple@ietf.org Subject: Chunking driver (was RE: [Simple] MSRP Boundary header) Ummm. Isn't the transport TCP? If you are on a LAN, aren't you going to be using 8K packets, anyway? E.g., I really don't get the chunking drive. Can't claim "small device": are you saying that these devices won't be surfing the web, getting e-mail, etc.? > -----Original Message----- > From: Sean Olson [mailto:seancolson@yahoo.com] > Sent: Tuesday, June 29, 2004 10:48 PM > To: 'Vijay Hampapur Hampapur Parthasarathy'; 'Ben Campbell' > Cc: simple@ietf.org > Subject: RE: [Simple] MSRP Boundary header > [snip] > > 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. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sun Jul 18 13:08: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 NAA20689 for ; Sun, 18 Jul 2004 13:08: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 1BmF8z-0005Pd-UN for simple-archive@ietf.org; Sun, 18 Jul 2004 13:08:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BmF7y-0005AP-00 for simple-archive@ietf.org; Sun, 18 Jul 2004 13:07:07 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BmF71-0004lv-00; Sun, 18 Jul 2004 13:06:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BmEwO-0005xy-HI; Sun, 18 Jul 2004 12:55:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BmEuU-0005Qe-0w for simple@megatron.ietf.org; Sun, 18 Jul 2004 12:53: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 MAA19902 for ; Sun, 18 Jul 2004 12:53: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 1BmEuT-0002Df-4O for simple@ietf.org; Sun, 18 Jul 2004 12:53:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BmEtV-00020Q-00 for simple@ietf.org; Sun, 18 Jul 2004 12:52:10 -0400 Received: from smtp102.mail.sc5.yahoo.com ([216.136.174.140]) by ietf-mx with smtp (Exim 4.12) id 1BmEsb-0001iX-00 for simple@ietf.org; Sun, 18 Jul 2004 12:51:13 -0400 Received: from unknown (HELO cranberry) (seancolson@4.41.208.58 with login) by smtp102.mail.sc5.yahoo.com with SMTP; 18 Jul 2004 16:51:12 -0000 From: "Sean Olson" To: "'Eric Burger'" , Subject: RE: [Simple] MSRP chunking and MIME fragmentation Date: Sun, 18 Jul 2004 09:51: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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcRslD5WLtV6Do8lQPiJue03nWtF+wAUyDjA In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit 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 This seems to point out the need for three different flags: 1) Complete content 2) Fragmented content 3) Aborted content -----Original Message----- From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf Of Eric Burger Sent: Saturday, July 17, 2004 11:33 PM To: simple@ietf.org Subject: [Simple] MSRP chunking and MIME fragmentation Last I looked, MSRP is a transport protocol. Thus, I don't understand the normative statement in Section 6.3.1: "The sender MUST NOT include a completion-flag of "+" if the payload MIME type does not support content fragmentation." Is not the User Agent Server buffering and reconstructing messages? That said, if it does, we should point out in the security considerations section that someone can say they are sending a fragmented message and then never send anything again, holding resources forever at the UAS. If the UAS is not buffering and reconstructing messages, and we are saying you can only send things like "message/partial", there is no MSRP fragmentation: MSRP only EVER sends complete MIME objects. Given the usefulness of sending chunks as a proxy for streaming, I would suggest just dropping the normative statement. _______________________________________________ Simple mailing 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 Sun Jul 18 16:58: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 QAA02269 for ; Sun, 18 Jul 2004 16:58: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 1BmIk2-00041n-3c for simple-archive@ietf.org; Sun, 18 Jul 2004 16:58:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BmIj3-0003og-00 for simple-archive@ietf.org; Sun, 18 Jul 2004 16:57:38 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BmIiB-0003UE-00; Sun, 18 Jul 2004 16:56:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BmIg0-0006l0-Ne; Sun, 18 Jul 2004 16:54:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BmIdv-0006c0-Rk for simple@megatron.ietf.org; Sun, 18 Jul 2004 16:52: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 QAA01924 for ; Sun, 18 Jul 2004 16:52: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 1BmIdu-0002mn-EJ for simple@ietf.org; Sun, 18 Jul 2004 16:52:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BmIcy-0002bY-00 for simple@ietf.org; Sun, 18 Jul 2004 16:51:21 -0400 Received: from av9-1-sn4.m-sp.skanova.net ([81.228.10.108]) by ietf-mx with esmtp (Exim 4.12) id 1BmIcL-0002FI-00 for simple@ietf.org; Sun, 18 Jul 2004 16:50:41 -0400 Received: by av9-1-sn4.m-sp.skanova.net (Postfix, from userid 502) id B1D3837E77; Sun, 18 Jul 2004 22:50:10 +0200 (CEST) Received: from smtp2-1-sn4.m-sp.skanova.net (smtp2-1-sn4.m-sp.skanova.net [81.228.10.183]) by av9-1-sn4.m-sp.skanova.net (Postfix) with ESMTP id A2E4437E42; Sun, 18 Jul 2004 22:50:10 +0200 (CEST) Received: from vit (h50n2fls31o265.telia.com [217.208.189.50]) by smtp2-1-sn4.m-sp.skanova.net (Postfix) with SMTP id 5F7A837E52; Sun, 18 Jul 2004 22:50:10 +0200 (CEST) From: "Gunnar Hellstrom" To: , "Eric Burger" Subject: RE: Suggested RTT text (was RE: [Simple] RE: [Sipping] RE: text/T140 andaudio/t140) Date: Sun, 18 Jul 2004 22:50:07 +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) In-reply-to: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Importance: Normal Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Cc: STF267 , Toip list , "Drage, Keith \(Keith\)" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org 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 Eric, Good proposal. Some comments say that the MSRP protocol spec is not the right place for = this kind of terminal requirements. Is there anywhere, where relations to other real time conversational serv= ices like voice and video are mentioned. If it is, that is the right place for also requi= ring a possibility to enter real time text conversation. I have some small proposals for changes in the text: ( whereever it ois p= laced ) 1. Use the term "real time text conversation". From the discussions it is= apparent that direct end to end IM is seen as a real time service. I agree. The term us= ed to distinguish voice telephony, video telephony, video conferencing, text telephony and = total conversation is "real time conversational" services. 2. There is no need to say that the user interfaces and user communities = are EXTREMELY similar. It is enough that they are similar but also important that they = do not completely overlap, so there is still a reason to strongly recommend to implement bo= th. Therefore, I suggest to delete the word "extremely" So, here is my modified proposal for the text. I hope you can find the ri= ght place for it. "User interfaces and user communities for instant messaging and real-time text conversation have many similarities. MSRP is not an ideal protocol f= or the negotiation and transport of real-time text conversation. However, devic= es that implement MRSP SHOULD implement real-time text conversation, using standa= rd SIP (RFC3261) and text/t140 (RFC2793bis) mechanisms." 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 Eric Burger >Sent: Sunday, July 18, 2004 8:33 AM >To: simple@ietf.org >Cc: Drage, Keith (Keith) >Subject: Suggested RTT text (was RE: [Simple] RE: [Sipping] RE: >text/T140 andaudio/t140) > > >After 420 pages of "discussion", may I humbly propose the following text= for >the MSRP document: > >User interfaces and user communities for instant messaging and real-time >text telephony are extremely similar. MSRP is not an ideal protocol for= the >negotiation and transport of real-time text. However, devices that >implement MRSP SHOULD implement real-time text telephony, using standard= SIP >(RFC3261) and text/t140 (RFC2793bis) mechanisms. > > > >Rationale: >1. It looks like consensus to putting RTP under MSRP is far, far, away, >assuming it even makes sense, which it probably doesn't. > >2. A whole bunch (80%?) of the code for an IM device would be shared wit= h a >RTT device - character input, character display, Internet connectivity, = SIP >stack, etc. > >3. We have a charter obligation to make protocols amenable to building >devices that are accessible to everyone. > >This is an opportunity to meet the objections to trying to shoehorn RTT = into >MSRP (#1) with our Charter obligations (#3) without an undue burden on t= he >implementer (#2). > >> -----Original Message----- >> From: Drage, Keith (Keith) [mailto:drage@lucent.com] >> Sent: Monday, July 05, 2004 5:54 AM >> To: simple@ietf.org >> Subject: RE: [Simple] RE: [Sipping] RE: text/T140 andaudio/t140 >> was:[avt]C omments/questions on draft-ietf-av >> >> >> Given the length of time this discussion has been going on, >> and the number of messages exchanged, is it not about time we >> reached some conclusions. These lists are to advance the >> deliverables in the working groups concerned, so how do any >> conclusions affect those deliverables. >> >> SIMPLE has a charter to produce instant messaging protocols. >> I do not see in all the discussion of the advantages of >> instant messaging versus real-time text removing that charter >> item. Therefore I suggest we STOP that discussion, or the >> proponents move it elsewhere. >> >> SIMPLE does not have a charter item to produce real-time text >> protocols. There is already an existing capability in IETF >> for real-time text protocols. It is not really up to SIMPLE >> to discuss whether that works well or not, as it was not >> developed under SIMPLEs charter. >> >> How terminals mix and match applications is not something >> that IETF traditionally deals with. Therefore I would suggest >> that any requirements that state RTT and IM must be >> implemented in the same terminal are out of scope of IETF. >> They should certainly be in some device specification rather >> than in the MSRP specification which SIMPLE is specifically >> delivering. >> >> I guess the questions as affecting MSRP really fall down to these: >> >> - Are there capabilities in MSRP that would lead to a >> valid RTT protocol that works better than the existing IETF >> solution, in addition to it fulfilling the requirements to >> provide an IM protocol. From the exchange of messages I have >> seem so far, it seems to me that the conclusion should be NO. >> >> - In order to deal with a body of users that have IM, and >> prefer to use IM, and a body of users that have RTT, and >> prefer to use RTT, is there a need to be able to interwork >> the two protocols at some intermediate point, and not just >> within the terminal by supporting both protocols under a >> common user interface? I see that as an element of the >> discussion just raised by Paul. Does such interworking, if >> required, have any impact on the contents of MSRP? >> >> regards >> >> Keith >> >> Keith Drage >> Lucent Technologies >> drage@lucent.com >> tel: +44 1793 776249 >> >> >> > -----Original Message----- >> > From: Arnoud van Wijk [mailto:a.vwijk@viataal.nl] >> > Sent: 04 July 2004 10:43 >> > To: hisham.khartabil@nokia.com; paulej@packetizer.com; >> > pkyzivat@cisco.com; Guido.Gybels@rnid.org.uk >> > Cc: fluffy@cisco.com; simple@ietf.org; gv@trace.wisc.edu; >> > toip@snowshore.com; gunnar.hellstrom@omnitor.se; smundra@telogy.com >> > Subject: RE: [Simple] RE: [Sipping] RE: text/T140 andaudio/t140 >> > was:[avt]Comments/questions on draft-ietf-av >> > >> > >> > Never say never. >> > Have you tried interactive text/real-time text? >> > Did you? >> > >> > First try it and THEN you can say if you like it or not. >> > >> > If you want to determine how useful it is. Test it. >> > Use it >> > Try it >> > Compare it with IM. >> > See the differences between IM and RTT/Interactive text. >> > See that both text communication methods have their advantages and >> > disadvantages. >> > And use both for the best situations. >> > >> > And if you still don't want to use RTT/Interactive >> > text..fine..I just hope >> > that when I call you, that you can still receive my call. >> > Just use it only >> > when the other person uses Interactive text/RTT. >> > Even if it is then 3-4 times per year. >> > >> > Can you with IM: >> > * directly call the other? >> > * forward the call? >> > * put on hold? >> > * have the call go to multiple terminals? >> > * not being logged on a buddy list server, where you may get >> > flooded by 20 >> > users at the same time saying hi! And such? >> > * being able to leave a message on an answering machine? >> > * using a service that allows a ring notifivation as soon the >> > other user is >> > ready with his/her other phonecall? (ring back on busy). >> > >> > There are more.. but I am unfamiliar with voice calls. I am >> > just enjoying my >> > freedom of communications beyond the IM limitations. >> > >> > And I enjoy using IM also..even though I am forced to use >> > Trillian, since >> > there is NO one universal standard for IM right now! >> > >> > Interactive text is! >> > >> > Greetz >> > >> > Arnoud >> > >> > >> >> _______________________________________________ >> Simple mailing 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 Sun Jul 18 18:10: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 SAA06502 for ; Sun, 18 Jul 2004 18:10: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 1BmJrS-0003HO-GU for simple-archive@ietf.org; Sun, 18 Jul 2004 18:10:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BmJqV-00035z-00 for simple-archive@ietf.org; Sun, 18 Jul 2004 18:09:24 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BmJpl-0002jN-00; Sun, 18 Jul 2004 18:08:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BmJon-0000UN-ML; Sun, 18 Jul 2004 18:07:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BmJkk-0007e6-7I for simple@megatron.ietf.org; Sun, 18 Jul 2004 18:03: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 SAA05770 for ; Sun, 18 Jul 2004 18:03: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 1BmJki-0001xY-Qt for simple@ietf.org; Sun, 18 Jul 2004 18:03:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BmJjo-0001mU-00 for simple@ietf.org; Sun, 18 Jul 2004 18:02:29 -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 1BmJjA-0001ZT-00 for simple@ietf.org; Sun, 18 Jul 2004 18:01:48 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 18 Jul 2004 15:02:34 -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 i6IM1HNv011796; Sun, 18 Jul 2004 15:01:17 -0700 (PDT) Received: from [10.0.1.2] (sjc-vpn2-569.cisco.com [10.21.114.57]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id AQR25446; Sun, 18 Jul 2004 15:01:12 -0700 (PDT) User-Agent: Microsoft-Entourage/11.0.0.040405 Date: Sun, 18 Jul 2004 09:13:26 -0700 Subject: Re: Suggested RTT text (was RE: [Simple] RE: [Sipping] RE: text/T 140 andaudio/t140) From: Cullen Jennings To: "Drage, Keith (Keith)" , Eric Burger , "simple@ietf.org" Message-ID: In-Reply-To: <475FF955A05DD411980D00508B6D5FB00C9F883E@en0033exch001u.uk.lucent.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.4 required=5.0 tests=AWL,DATE_IN_PAST_03_06 autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Agee with Keith but also, if we did put those words in, I don't think it would in any way change the percentage of devices that did or did not support t140. On 7/18/04 6:14 AM, "Drage, Keith (Keith)" wrote: > Sorry but NO. > > MSRP is the protocol definition, not the characteristics of an end device that > may implement MSRP, and therefore should be independent of whether the UA is > end user terminal, gateway or whatever. Additionally they are totally out of > the current scope (abstract in IETF terms because they do not define MSRP). > > These words you have just proposed affect all UA and proxy implementations. > > If you want these words, put it in a device specification, and not the core > MSRP definition. > > regards > > Keith > >> -----Original Message----- >> From: Eric Burger [mailto:eburger@brooktrout.com] >> Sent: 18 July 2004 07:33 >> To: simple@ietf.org >> Cc: Drage, Keith (Keith) >> Subject: Suggested RTT text (was RE: [Simple] RE: [Sipping] RE: >> text/T140 andaudio/t140) >> >> >> After 420 pages of "discussion", may I humbly propose the >> following text for >> the MSRP document: >> >> User interfaces and user communities for instant messaging >> and real-time >> text telephony are extremely similar. MSRP is not an ideal >> protocol for the >> negotiation and transport of real-time text. However, devices that >> implement MRSP SHOULD implement real-time text telephony, >> using standard SIP >> (RFC3261) and text/t140 (RFC2793bis) mechanisms. >> >> >> >> Rationale: >> 1. It looks like consensus to putting RTP under MSRP is far, >> far, away, >> assuming it even makes sense, which it probably doesn't. >> >> 2. A whole bunch (80%?) of the code for an IM device would be >> shared with a >> RTT device - character input, character display, Internet >> connectivity, SIP >> stack, etc. >> >> 3. We have a charter obligation to make protocols amenable to building >> devices that are accessible to everyone. >> >> This is an opportunity to meet the objections to trying to >> shoehorn RTT into >> MSRP (#1) with our Charter obligations (#3) without an undue >> burden on the >> implementer (#2). >> >>> -----Original Message----- >>> From: Drage, Keith (Keith) [mailto:drage@lucent.com] >>> Sent: Monday, July 05, 2004 5:54 AM >>> To: simple@ietf.org >>> Subject: RE: [Simple] RE: [Sipping] RE: text/T140 andaudio/t140 >>> was:[avt]C omments/questions on draft-ietf-av >>> >>> >>> Given the length of time this discussion has been going on, >>> and the number of messages exchanged, is it not about time we >>> reached some conclusions. These lists are to advance the >>> deliverables in the working groups concerned, so how do any >>> conclusions affect those deliverables. >>> >>> SIMPLE has a charter to produce instant messaging protocols. >>> I do not see in all the discussion of the advantages of >>> instant messaging versus real-time text removing that charter >>> item. Therefore I suggest we STOP that discussion, or the >>> proponents move it elsewhere. >>> >>> SIMPLE does not have a charter item to produce real-time text >>> protocols. There is already an existing capability in IETF >>> for real-time text protocols. It is not really up to SIMPLE >>> to discuss whether that works well or not, as it was not >>> developed under SIMPLEs charter. >>> >>> How terminals mix and match applications is not something >>> that IETF traditionally deals with. Therefore I would suggest >>> that any requirements that state RTT and IM must be >>> implemented in the same terminal are out of scope of IETF. >>> They should certainly be in some device specification rather >>> than in the MSRP specification which SIMPLE is specifically >>> delivering. >>> >>> I guess the questions as affecting MSRP really fall down to these: >>> >>> - Are there capabilities in MSRP that would lead to a >>> valid RTT protocol that works better than the existing IETF >>> solution, in addition to it fulfilling the requirements to >>> provide an IM protocol. From the exchange of messages I have >>> seem so far, it seems to me that the conclusion should be NO. >>> >>> - In order to deal with a body of users that have IM, and >>> prefer to use IM, and a body of users that have RTT, and >>> prefer to use RTT, is there a need to be able to interwork >>> the two protocols at some intermediate point, and not just >>> within the terminal by supporting both protocols under a >>> common user interface? I see that as an element of the >>> discussion just raised by Paul. Does such interworking, if >>> required, have any impact on the contents of MSRP? >>> >>> regards >>> >>> Keith >>> >>> Keith Drage >>> Lucent Technologies >>> drage@lucent.com >>> tel: +44 1793 776249 >>> >>> >>>> -----Original Message----- >>>> From: Arnoud van Wijk [mailto:a.vwijk@viataal.nl] >>>> Sent: 04 July 2004 10:43 >>>> To: hisham.khartabil@nokia.com; paulej@packetizer.com; >>>> pkyzivat@cisco.com; Guido.Gybels@rnid.org.uk >>>> Cc: fluffy@cisco.com; simple@ietf.org; gv@trace.wisc.edu; >>>> toip@snowshore.com; gunnar.hellstrom@omnitor.se; >> smundra@telogy.com >>>> Subject: RE: [Simple] RE: [Sipping] RE: text/T140 andaudio/t140 >>>> was:[avt]Comments/questions on draft-ietf-av >>>> >>>> >>>> Never say never. >>>> Have you tried interactive text/real-time text? >>>> Did you? >>>> >>>> First try it and THEN you can say if you like it or not. >>>> >>>> If you want to determine how useful it is. Test it. >>>> Use it >>>> Try it >>>> Compare it with IM. >>>> See the differences between IM and RTT/Interactive text. >>>> See that both text communication methods have their advantages and >>>> disadvantages. >>>> And use both for the best situations. >>>> >>>> And if you still don't want to use RTT/Interactive >>>> text..fine..I just hope >>>> that when I call you, that you can still receive my call. >>>> Just use it only >>>> when the other person uses Interactive text/RTT. >>>> Even if it is then 3-4 times per year. >>>> >>>> Can you with IM: >>>> * directly call the other? >>>> * forward the call? >>>> * put on hold? >>>> * have the call go to multiple terminals? >>>> * not being logged on a buddy list server, where you may get >>>> flooded by 20 >>>> users at the same time saying hi! And such? >>>> * being able to leave a message on an answering machine? >>>> * using a service that allows a ring notifivation as soon the >>>> other user is >>>> ready with his/her other phonecall? (ring back on busy). >>>> >>>> There are more.. but I am unfamiliar with voice calls. I am >>>> just enjoying my >>>> freedom of communications beyond the IM limitations. >>>> >>>> And I enjoy using IM also..even though I am forced to use >>>> Trillian, since >>>> there is NO one universal standard for IM right now! >>>> >>>> Interactive text is! >>>> >>>> Greetz >>>> >>>> Arnoud >>>> >>>> >>> >>> _______________________________________________ >>> Simple mailing 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 Sun Jul 18 20:11: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 UAA13675 for ; Sun, 18 Jul 2004 20:11: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 1BmLkf-0004eC-3T for simple-archive@ietf.org; Sun, 18 Jul 2004 20:11:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BmLji-0004PQ-00 for simple-archive@ietf.org; Sun, 18 Jul 2004 20:10:30 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BmLig-0003yf-00; Sun, 18 Jul 2004 20:09:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BmLfo-00078D-Dd; Sun, 18 Jul 2004 20:06:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BmLa4-0006hW-Ki for simple@megatron.ietf.org; Sun, 18 Jul 2004 20:00: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 UAA13061 for ; Sun, 18 Jul 2004 20: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 1BmLa3-0002L6-1y for simple@ietf.org; Sun, 18 Jul 2004 20:00:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BmLZ7-00028P-00 for simple@ietf.org; Sun, 18 Jul 2004 19:59:33 -0400 Received: from salvelinus.brooktrout.com ([204.176.205.6]) by ietf-mx with esmtp (Exim 4.12) id 1BmLYL-0001vm-00; Sun, 18 Jul 2004 19:58:45 -0400 Received: from nhmail2.needham.brooktrout.com (nhmail2.eng.brooktrout.com [204.176.205.242]) by salvelinus.brooktrout.com (8.12.5/8.12.5) with ESMTP id i6INTZlm014713; Sun, 18 Jul 2004 19:29:47 -0400 (EDT) Received: by nhmail2.eng.brooktrout.com with Internet Mail Service (5.5.2653.19) id ; Sun, 18 Jul 2004 19:27:43 -0400 Message-ID: From: Eric Burger To: Jonathan Rosenberg , "'geopriv@ietf.org'" , Simple WG Subject: RE: [Simple] common policy/ common policy caps schema issue Date: Sun, 18 Jul 2004 19:27:34 -0400 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=AWL autolearn=no version=2.60 At a certain point, one has to ask, "Why XML?", especially if we lose the ability to leverage tools, verifiers, etc.. > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Sunday, July 18, 2004 9:12 AM > To: 'geopriv@ietf.org'; Simple WG > Subject: [Simple] common policy/ common policy caps schema issue [snip] > The only way I know to do this is to remove the usage of substitution > groups, and use the construct. This does mean that > the schema > validation cannot verify that new conditions, actions or > transformations > are appropriately placed in the document. But, I think this > is the price > we need to pay for the extensibility we need. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jul 19 05:26: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 FAA27346 for ; Mon, 19 Jul 2004 05:26: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 1BmUQF-0006BH-5U for simple-archive@ietf.org; Mon, 19 Jul 2004 05:26:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BmUPE-0005xb-00 for simple-archive@ietf.org; Mon, 19 Jul 2004 05:25:56 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BmUOf-0005j9-00; Mon, 19 Jul 2004 05:25:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BmUMF-00053N-RD; Mon, 19 Jul 2004 05: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 1BmULJ-00050H-82 for simple@megatron.ietf.org; Mon, 19 Jul 2004 05:21: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 FAA27065 for ; Mon, 19 Jul 2004 05:21:50 -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 1BmULG-00051T-UX for simple@ietf.org; Mon, 19 Jul 2004 05:21:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BmUKK-0004oS-00 for simple@ietf.org; Mon, 19 Jul 2004 05:20:52 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1BmUK3-0004by-00 for simple@ietf.org; Mon, 19 Jul 2004 05:20:35 -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 i6J9KZv02617 for ; Mon, 19 Jul 2004 12:20:36 +0300 (EET DST) X-Scanned: Mon, 19 Jul 2004 12:20:11 +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 i6J9KBd8004908 for ; Mon, 19 Jul 2004 12:20:11 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00vPuO2m; Mon, 19 Jul 2004 12:20: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 i6J9KAn15451 for ; Mon, 19 Jul 2004 12:20:10 +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, 19 Jul 2004 12:20:07 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Date: Mon, 19 Jul 2004 12:20:07 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7023EEB40@esebe019.ntc.nokia.com> Thread-Topic: WGLC: XCAP Base Thread-Index: AcRtcZVAzp0/SdI1T9SesxqVZ4UV4g== To: X-OriginalArrivalTime: 19 Jul 2004 09:20:07.0492 (UTC) FILETIME=[95305040:01C46D71] Content-Transfer-Encoding: quoted-printable Subject: [Simple] WGLC: XCAP Base X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org 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 WG chairs would like to start a Working Group Last Call on the = following internet draft as part of the SIMPLE Data Manipulation work to = be submitted to IESG: http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-03.txt (The draft may not be available on the above link for another couple of = days or so. Until it does, please fetch it from = http://www.softarmor.com/wgdb/docs/draft-ietf-simple-xcap-03.txt) This WGLC is 3 weeks long and will end on August 8th. Please send your comments to this mailing list and to the authors.=20 If you reviewed the draft and found no issues, please indicate so on the = mailing list. This will help us evaluate the level of review and group = consensus. Thanks, Hisham _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jul 19 05:32: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 FAA27674 for ; Mon, 19 Jul 2004 05:32: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 1BmUVt-0007aJ-4v for simple-archive@ietf.org; Mon, 19 Jul 2004 05:32:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BmUUt-0007KE-00 for simple-archive@ietf.org; Mon, 19 Jul 2004 05:31:48 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BmUTr-0006sI-00; Mon, 19 Jul 2004 05:30:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BmURM-0005ON-NK; Mon, 19 Jul 2004 05:28:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BmUNV-00056b-VN for simple@megatron.ietf.org; Mon, 19 Jul 2004 05:24: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 FAA27218 for ; Mon, 19 Jul 2004 05:24:07 -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 1BmUNT-0005Vn-M3 for simple@ietf.org; Mon, 19 Jul 2004 05:24:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BmUMZ-0005Hv-00 for simple@ietf.org; Mon, 19 Jul 2004 05:23:12 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1BmULz-00053X-00 for simple@ietf.org; Mon, 19 Jul 2004 05:22:36 -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 i6J9Max13852 for ; Mon, 19 Jul 2004 12:22:36 +0300 (EET DST) X-Scanned: Mon, 19 Jul 2004 12:22:33 +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 i6J9MX5k011315 for ; Mon, 19 Jul 2004 12:22:33 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00sbofxl; Mon, 19 Jul 2004 12:22:33 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 i6J9MVn17578 for ; Mon, 19 Jul 2004 12:22:31 +0300 (EET DST) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 19 Jul 2004 12:22:17 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 19 Jul 2004 12:22:16 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Date: Mon, 19 Jul 2004 12:22:17 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7023EEB41@esebe019.ntc.nokia.com> Thread-Topic: WGLC: XCAP List Usage Thread-Index: AcRtceJtYGGB4eV5SNuCFnjCsoByqw== To: X-OriginalArrivalTime: 19 Jul 2004 09:22:16.0916 (UTC) FILETIME=[E254D940:01C46D71] Content-Transfer-Encoding: quoted-printable Subject: [Simple] WGLC: XCAP List Usage X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org 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 WG chairs would like to start a Working Group Last Call on the = following internet draft as part of the SIMPLE Data Manipulation work to = be submitted to IESG: http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-list-usage-03.= txt (The draft may not be available on the above link for another couple of = days or so. Until it does, please fetch it from = http://www.softarmor.com/wgdb/docs/draft-ietf-simple-xcap-list-usage-03.t= xt) This WGLC is 3 weeks long and will end on August 8th. Please send your comments to this mailing list and to the authors.=20 If you reviewed the draft and found no issues, please indicate so on the = mailing list. This will help us evaluate the level of review and group = consensus. Thanks, Hisham _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jul 19 10: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 KAA17803 for ; Mon, 19 Jul 2004 10:00: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 1BmYgs-00037L-VB for simple-archive@ietf.org; Mon, 19 Jul 2004 10:00:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BmYfw-0002qJ-00 for simple-archive@ietf.org; Mon, 19 Jul 2004 09:59:29 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BmYfI-0002YW-00; Mon, 19 Jul 2004 09:58:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BmYTW-0004Ya-F2; Mon, 19 Jul 2004 09:46:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BmYPA-0003uc-5G for simple@megatron.ietf.org; Mon, 19 Jul 2004 09:42: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 JAA16382 for ; Mon, 19 Jul 2004 09:42: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 1BmYP9-0006Fn-Dj for simple@ietf.org; Mon, 19 Jul 2004 09:42:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BmYOJ-00060z-00 for simple@ietf.org; Mon, 19 Jul 2004 09:41:16 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BmYNM-0005XO-00 for simple@ietf.org; Mon, 19 Jul 2004 09:40:16 -0400 Received: from dynamicsoft.com ([63.113.46.12]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i6JDdpGr004848; Mon, 19 Jul 2004 09:39:52 -0400 (EDT) Message-ID: <40FBCF13.8010308@dynamicsoft.com> Date: Mon, 19 Jul 2004 09:39: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: Henning Schulzrinne Subject: Re: [Simple] Address and person URIs References: <40F97472.7030006@cs.columbia.edu> In-Reply-To: <40F97472.7030006@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: > In idle curiosity, I looked around a bit to see if others had thought > about URIs representing postal and in-person resources. (2396bis > explicitly mentions persons as resources.) One such discussion ist at > > http://www.mail-archive.com/www-talk@w3.org/msg00673.html > > While we obviously don't need or want to design such a thing now, having > some estimation as to its practicality might guide us as to whether > relying on some future definition is prudent. After all, we wouldn't > want to have a spec that says "We need a perpetuum mobile here; the > details are for future study.". The actual proposal at http://infomesh.net/2001/03/address/ seems reasonable to me. It looks old though, and I suspect went nowhere. I think it would actually be a lot of work to do this properly, given issues of variations in addressing structure and hierarchy, internationalization issues, equality, etc. > > The basic problem with a "human" URI is that there does not appear to be > a unique, universally accepted identifier for humans except one that > each human picks randomly from a very large space. References to the > 'mark of the beast' are left to other discussion venues. (Even then, I > suspect that lots of Chinese will randomly pick human:888888 > [http://www.travelchinaguide.com/intro/social_customs/lucky_number.htm]) I don't think we want to label a human, per se. What we really want for person to person communications is a place - i.e., "room 527". > > For human-to-human communication, it is also more often than not > unnecessary to know which precise DNA instantiation will be meeting me. > Indeed, for privacy reasons, such unique identification is undesirable. > Thus, unique identifiers are the wrong model for identifying > human-to-human interaction. While, therefore, a human is a resource, an > identifier is unnecessary and undesirable, making a URI scheme dubious > at best. Actually I suspect that, if you think of it in terms of "go here to talk to me", then the same postal URI structure would probably work, but just a different scheme. > > The problems with a "postal" URI are less severe, but the discussions > surrounding the civic address format in the geopriv working group have > shown that this is far from trivial. With the CIPID vcard element, it > also seems unclear as to why this would be helpful in practice. Well, another solution is to somehow define a URI scheme that just contains a reference to such a vcard. -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 Jul 19 10:03: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 KAA18103 for ; Mon, 19 Jul 2004 10:03: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 1BmYje-0003vS-6T for simple-archive@ietf.org; Mon, 19 Jul 2004 10:03:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BmYir-0003g5-00 for simple-archive@ietf.org; Mon, 19 Jul 2004 10:02:30 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BmYi1-0003MI-00; Mon, 19 Jul 2004 10:01:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BmYf8-0005RO-3L; Mon, 19 Jul 2004 09:58:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BmYUA-0004aO-H1 for simple@megatron.ietf.org; Mon, 19 Jul 2004 09:47: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 JAA16744 for ; Mon, 19 Jul 2004 09:47: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 1BmYU9-0007XV-3N for simple@ietf.org; Mon, 19 Jul 2004 09:47:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BmYTC-0007Gy-00 for simple@ietf.org; Mon, 19 Jul 2004 09:46:19 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BmYS9-0006lq-00 for simple@ietf.org; Mon, 19 Jul 2004 09:45:13 -0400 Received: from dynamicsoft.com ([63.113.46.12]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i6JDirGr004852; Mon, 19 Jul 2004 09:44:54 -0400 (EDT) Message-ID: <40FBD041.8060701@dynamicsoft.com> Date: Mon, 19 Jul 2004 09:44: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: Henning Schulzrinne Subject: Re: [Simple] What are tuples? References: <57796.212.119.9.178.1089110888.squirrel@webmail.cs.columbia.edu> <40F306E6.3020903@dynamicsoft.com> <40F969EC.2010902@cs.columbia.edu> In-Reply-To: <40F969EC.2010902@cs.columbia.edu> 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. Henning Schulzrinne wrote: >> The think the watcher benefits because it provides what I think is >> useful information for the watcher to make a choice. For example, "oh, >> i know bob is travelling and has his cell phone with him, look at >> that, he has sms on his phone, i will send him an sms". > > > No different than a service. What is no different than a service? > >> >> I also think that people tend to think about communications in terms >> of devices. People say, "call me on my cell", such that the device is >> the center point for choice and preference. > > > People buy cell phone service to be reached. The device is a necessary, > but not particularly interesting, implementation detail. This will > become more obvious as we start separating numbers from individual > pieces of plastic. I think we want solutions which model the concepts of interest that exist today. I don't see how one can deny that a "cell phone" doesnt exist or is meaningless as a concept in communications systems? > >> >> Also keep in mind that watchers are not the only consumers of presence >> documents. I think that the device information is incredibly useful >> for presence servers in the process of composition. > > > I disagree. Henning, I have given several examples of how the device identity is an extremely useful correlator. Can you please explain why you disagree with each of those cases? Its hard to rebut against "I disagree". > >> 1. if a device is idle, like my PC, it means I have not accessed the >> device or any services on it for some time. This is the classic >> meaning of idle in todays IM systems > > > Not really true. If I watch a video on my PC or have it cycle through a > set of PPT slides, the IM will show "idle", although the PC is doing its > job and I'm watching it. In practice, it seems to mean "haven't touched > the mouse or keyboard"... Thats fine. We can define "idle" for a device as not having touched the input sources of that device (keyboard, mouse). There is still clearly an "idle" for the device and an "idle" for the service that are distinct. > >> >> 2. if a a service is idle, like my IM client, it means I havent used >> the service (i.e., havent sent/receive an IM) for some time >> >> 3. if a person is idle, it means that they are bored and not doing >> anything >> >> Inheritance makes sense only when there is a is-a relationship between >> the thing that is inhertiting and the thing that is the source of the >> inheritance. Since services and devices and presentities are not the >> same thing, I dont think we should be inheriting amongst them. >> >> I think that, the fewer places an attribute can appear (being >> associated with a service, device or tuple), the less confusion there >> is about what that attribute means. When it does appear in multiple >> places, it should be because it is truly meaningful for a devices, >> presentities and services. For example, location is meaningful for a >> device and for a presentity. > > > It is also useful for a human, for example (which is not the same as the > presentity). Is the "human:" URI a service or a device? In the presence data model I have suggested, the "presentity" models the human, and so location is a characteristic of the presentity. -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 Jul 19 10:08: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 KAA18703 for ; Mon, 19 Jul 2004 10:08: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 1BmYoN-0005It-12 for simple-archive@ietf.org; Mon, 19 Jul 2004 10:08:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BmYnR-000533-00 for simple-archive@ietf.org; Mon, 19 Jul 2004 10:07:13 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BmYmW-0004XR-00; Mon, 19 Jul 2004 10:06:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BmYft-0005d3-SD; Mon, 19 Jul 2004 09:59:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BmYY9-0004kt-AD for simple@megatron.ietf.org; Mon, 19 Jul 2004 09:51: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 JAA17042 for ; Mon, 19 Jul 2004 09:51:22 -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 1BmYY8-0000jH-Fm for simple@ietf.org; Mon, 19 Jul 2004 09:51:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BmYX4-0000Tx-00 for simple@ietf.org; Mon, 19 Jul 2004 09:50:18 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BmYWF-0000Eu-00 for simple@ietf.org; Mon, 19 Jul 2004 09:49:27 -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 i6JDnNh19908; Mon, 19 Jul 2004 16:49:23 +0300 (EET DST) X-Scanned: Mon, 19 Jul 2004 16:49:18 +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 i6JDnILd001121; Mon, 19 Jul 2004 16:49:18 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00x1uK6Q; Mon, 19 Jul 2004 16:49:16 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 i6JDnFn06259; Mon, 19 Jul 2004 16:49:15 +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); Mon, 19 Jul 2004 16:49:10 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Date: Mon, 19 Jul 2004 16:49:10 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7023EEB44@esebe019.ntc.nokia.com> Thread-Topic: Proposed Agenda for SIMPLE WG in IETF 60 Thread-Index: AcRtlyrfvT/z7rOgSQiJYMYv7O4uPg== To: X-OriginalArrivalTime: 19 Jul 2004 13:49:10.0351 (UTC) FILETIME=[2B151DF0:01C46D97] Content-Transfer-Encoding: quoted-printable Cc: rsparks@dynamicsoft.com Subject: [Simple] Proposed Agenda for SIMPLE WG in IETF 60 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org 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 Here is an agenda proposal for the SIMPLE WG in IETF 60. Most of the = time slots are allocated to items with critical importance and have = urgent need to complete. Please provide feedback. The final agenda will be provided next week. MONDAY, August 2, 2004, 1300-1500 Afternoon Sessions I 13:00-13:05 Agenda Bashing, Chairs Report 13:05-14:15 MSRP Base (Ben) 14:15-15:00 MSRP Relay (Rohan, fluffy) TUESDAY, August 3, 2004, 0900-1130 Morning Sessions 9:00-9:10 XCAP Base/list usage (Jonathan) 9:10-10:25 XCAP usage for Authorisation rules (Jonathan) 10:25-10:30 XCAP Extension (Jonathan) 10:30-10:35 XCAP Directory usage (Miguel) 10:35-10:40 ICE Services with Presence (Jon) 10:40-11:30 Presence Data Model and "What is a tuple" (Jonathan) Thanks, Hisham _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jul 19 10:25: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 KAA21228 for ; Mon, 19 Jul 2004 10:25: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 1BmZ5R-0002DX-Af for simple-archive@ietf.org; Mon, 19 Jul 2004 10:25:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BmZ4B-0001tT-00 for simple-archive@ietf.org; Mon, 19 Jul 2004 10:24:32 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BmZ3K-0001YZ-00; Mon, 19 Jul 2004 10:23:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BmYsr-0002tM-MN; Mon, 19 Jul 2004 10:12:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BmYmo-0000z5-KP for simple@megatron.ietf.org; Mon, 19 Jul 2004 10:06: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 KAA18449 for ; Mon, 19 Jul 2004 10:06: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 1BmYmm-0004nN-VF for simple@ietf.org; Mon, 19 Jul 2004 10:06:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BmYlq-0004VK-00 for simple@ietf.org; Mon, 19 Jul 2004 10:05:34 -0400 Received: from viap106.atea.be ([194.78.143.106] helo=hrtades9.atea.be) by ietf-mx with esmtp (Exim 4.12) id 1BmYl1-0004AZ-00 for simple@ietf.org; Mon, 19 Jul 2004 10:04:43 -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 PHLB6RCZ; Mon, 19 Jul 2004 16:01:48 +0200 Received: by siemens.atea.be with Internet Mail Service (5.5.2653.19) id ; Mon, 19 Jul 2004 15:43:05 +0200 Message-ID: <6B546A602AD2D211BFF00008C7A428890B1E28F7@hrtades2.atea.be> From: Biot Olivier To: "'hisham.khartabil@nokia.com'" , simple@ietf.org Subject: RE: [Simple] WGLC: XCAP Base Date: Mon, 19 Jul 2004 15:43:01 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Cc: "'Jonathan Rosenberg'" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org 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 |From: hisham.khartabil@nokia.com | |The WG chairs would like to start a Working Group Last Call on |the following internet draft as part of the SIMPLE Data |Manipulation work to be submitted to IESG: | |http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-03.txt | |(The draft may not be available on the above link for another |couple of days or so. Until it does, please fetch it from |http://www.softarmor.com/wgdb/docs/draft-ietf-|simple-xcap-03.tx |t) | |This WGLC is 3 weeks long and will end on August 8th. | |Please send your comments to this mailing list and to the authors. | |If you reviewed the draft and found no issues, please indicate |so on the mailing list. This will help us evaluate the level |of review and group consensus. First impression is that it reads well! Some nits I found so far: General remark: Some lines with HTTP examples and XML schema have not been line-wrapped. This can probably be deferred till the very end. Page 18: [Question] The 2nd last paragraph of 6.3 does not contain RFC2119 language. Is this because RFC2616 (or to be more precise, sections 3 and 3.3 of RFC2396 regarding abs_path) mandates the escaping of "[", "]" and <"> in URIs and we don't want to duplicate requirements? Page 21: Caption and caption text, on 2 separate lines. Both should be removed. Pages 48--51: First sentence of 13.2.1 stops after one line. This introduction is missing entirely in the 3 other registration sections, and they also lack a blank line between section heading and section text. The 4 MIME media types are registered differently, more precisely the "Published specification" section, where once "RFCXXXX" is used, then "This specification." Page 51: File extension of application/xcap-caps+xml is the same as application/xcap-error+xml (.xe). Although files with this content will not be that common, I'd suggest .xer or .xml for the former and .xca or .xml for the latter. Maybe we can get rid of the ".xe[r]" or ".xc[a]" extension altogether as the documents written in those formats are valid XML documents. Page 54: Reference [1]: "W3C FirstEdition" should read either "W3C REC" or "W3C Recommendation". By the way, the current XML 1.0 specification is the 3rd edition: Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E. and F. Yergeau: "The Extensible Markup Language version 1.0 (3rd edition)". W3C recommendation, http://www.w3.org/TR/2004/REC-xml-20040204, February 2004. Note that [4] is a W3C candidate recommendation. That's all I found so far. Best regards, Olivier Biot _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jul 19 10:53: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 KAA23632 for ; Mon, 19 Jul 2004 10:53: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 1BmZW5-0001p2-G3 for simple-archive@ietf.org; Mon, 19 Jul 2004 10:53:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BmZV6-0001ZH-00 for simple-archive@ietf.org; Mon, 19 Jul 2004 10:52:21 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BmZUL-0001GC-00; Mon, 19 Jul 2004 10:51:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BmZMa-0000uc-Nd; Mon, 19 Jul 2004 10:43:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BmCzM-0007WU-Oh for simple@megatron.ietf.org; Sun, 18 Jul 2004 10:50: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 KAA13097 for ; Sun, 18 Jul 2004 10:50: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 1BmCzL-0006cc-VS for simple@ietf.org; Sun, 18 Jul 2004 10:50:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BmCyR-0006Q3-00 for simple@ietf.org; Sun, 18 Jul 2004 10:49:08 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1BmCxV-0006Dj-00; Sun, 18 Jul 2004 10:48:09 -0400 Received: from dynasty.cs.columbia.edu (dynasty.cs.columbia.edu [128.59.16.5]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i6IEm2fq008580 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 18 Jul 2004 10:48:03 -0400 (EDT) Received: from dynasty.cs.columbia.edu (localhost [127.0.0.1]) by dynasty.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i6IEm2K9019602; Sun, 18 Jul 2004 10:48:02 -0400 (EDT) Received: from localhost (xiaotaow@localhost) by dynasty.cs.columbia.edu (8.12.10/8.12.10/Submit) with ESMTP id i6IEm27T019599; Sun, 18 Jul 2004 10:48:02 -0400 (EDT) X-Authentication-Warning: dynasty.cs.columbia.edu: xiaotaow owned process doing -bs Date: Sun, 18 Jul 2004 10:48:01 -0400 (EDT) From: Xiaotao Wu To: Jonathan Rosenberg In-Reply-To: <40FA7733.9000501@dynamicsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-758783491-1090162081=:18329" X-PMX-Version: 4.6.1.106153, Antispam-Core: 4.6.1.104326, Antispam-Data: 2004.7.17.107809 X-PerlMx-Spam: Gauge=XIIIIIIII, Probability=18%, Report='INVALID_CHARSET 2, __TO_MALFORMED_2 0, __IN_REP_TO 0, __HAS_MSGID 0, __SANE_MSGID 0, __MIME_VERSION 0, __CT 0, __CTYPE_HAS_BOUNDARY 0, __CTYPE_MULTIPART 0, __C230066_P5 0, __NEW_DOMAIN_EXTENSIONS_1 0, EMAIL_ATTRIBUTION 0, QUOTED_EMAIL_TEXT 0, __MIME_TEXT_ONLY 0, __MIME_CHARSET_FARAWAY 0, X_AUTH_WARNING 0, IN_REP_TO 0' X-Mailman-Approved-At: Mon, 19 Jul 2004 10:43:29 -0400 Cc: "'geopriv@ietf.org'" , Simple WG Subject: [Simple] Re: [Geopriv] common policy/ common policy caps schema issue X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.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.4 required=5.0 tests=AWL,HTML_20_30, NEW_DOMAIN_EXTENSIONS autolearn=no version=2.60 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---559023410-758783491-1090162081=:18329 Content-Type: TEXT/PLAIN; charset=US-ASCII I think for substitutionGroup, you may need to define an abstract element/type as the 'base class'. For the real elements/types, the new type should be defined as the 'xs:extension' of the base abstract type, the new element should be defined as the 'substitutionGroup' as the base abstract element. See attached s1.xsd, s2.xsd, s3.xsd and test123.xml s1 defines abstract type 'action' and 'ActionType', and a real action 'reject' substitute 'action. The 'reject' action has the type 'RejectAction', extended from the abstract 'ActionType' s1 also defines a 'root' element that can have a sequence of actions. s2 imports s1, defines 'ring' action s3 imports s1, defines 'accept' action. test123.xml use all three schemas, and put all the actions from different schemas into the 'root' element. -Xiaotao =========================================================== Name : Xiaotao Wu Email : xiaotaow@cs.columbia.edu Homepage : http://www.cs.columbia.edu/~xiaotaow Phone : (212)939-7054, Fax: (801)751-0217 Phone-PC : (212)939-7133 SIP : sip:xiaotaow@conductor.cs.columbia.edu Office : Room 506, Mudd building, West 120th =========================================================== On Sun, 18 Jul 2004, Jonathan Rosenberg wrote: > Folks, > > While revising draft-rosenberg-simple-common-policy-caps, I ran into an > issue in the schema design which I believe affects the documents > developed in both simple and geopriv that make use of the XML schema > substitutionGroup concept. > > The idea with a substitution group is that you could declare one element > as a substitute for another. This would seemingly allow us to extend > common policy or common policy caps with new policies/capabilities, and > declare them to be conditions, actions, or transformations. And indeed, > it does do this. However, there is a problem. > > The problem is that, when you create such an extension, you need to > create a new schema that includes these extensions, and then specify > that documents have to compliant to this new schema. This creates a > major problem in systems where you want to develop independent > extensions to the schema. Let me give an example. > > Lets say we have a base schema S1, which contains elements in the > namespace N1. One group decides to add some new elements using > substitution groups, so it creates schema S2, with elements in namespace > N2 declared as substitutes for the right elements in S1. S2 will need to > import S1, since the head element of the substitution group is defined > there. Similarly, another group decides to add some new elements. So, it > creates schema S3, with elements in namespace N3, declared as > substitutes for elements in S1. S3 also imports S1, for the same reason. > > Now, a server or client wish to implement both extensions. So, it > creates a document with elements from N1, N2 and N3. Which schema is > this document compliant to? None of them! Take a look at each in turn: > > S1: the elements from N2 and N3 are in the instance document, but are > not defined in S1. Since S1 was using substitution groups, it's schema > doesn't have maxOccurs="unbounded"/> defined in its schema. Elements not defined in > the schema cnanot be included. Thus, the document is not valid according > to S1. > > S2: The elements from N3 are not defined in S2. S2, like S1, won't have > declarations, so these elements are not allowed and the > docuemnt is not valid. > > S3: The elements from N2 are not defined in S3. S3, like S1, won't have > declarations, so these elements are not allowed and the > docuemnt is not valid. > > > If we go ahead and add declarations to S1, we will allow any > kind of element to be added, thus defeating the constraint that we > wanted with the substitution group. > > So, my conclusion was that substitution groups were useful in schemas > where a single chain of extensions would be developed, and each new > extension would include elements from the previous. Thus, you "extend" > the schema by basically revising it and including new elements in the > revised version. This is a valid model of extensibility in some > environments, but I think we want a model that supports more distributed > extensibility, where each extensions doesnt need to know about the other. > > The only way I know to do this is to remove the usage of substitution > groups, and use the construct. This does mean that the schema > validation cannot verify that new conditions, actions or transformations > are appropriately placed in the document. But, I think this is the price > we need to pay for the extensibility we need. > > Does anyone have a better idea? > > 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 > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv > ---559023410-758783491-1090162081=:18329 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="s1.xsd" Content-ID: Content-Description: Content-Disposition: attachment; filename="s1.xsd" Content-Transfer-Encoding: BASE64 PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4NDQo8IS0t IGVkaXRlZCB3aXRoIFhNTFNQWSB2MjAwNCByZWwuIDQgVSAoaHR0cDovL3d3 dy54bWxzcHkuY29tKSBieSBYaWFvdGFvIFd1IChDb2x1bWJpYSBVbml2ZXJz aXR5IENvbXB1dGVyIFNjaWVuY2UgRGVwdCkgLS0+DQ0KPHhzOnNjaGVtYSBl bGVtZW50Rm9ybURlZmF1bHQ9InF1YWxpZmllZCIgYXR0cmlidXRlRm9ybURl ZmF1bHQ9InVucXVhbGlmaWVkIiB0YXJnZXROYW1lc3BhY2U9InhtbDpOMSIg eG1sbnM9InhtbDpOMSIgeG1sbnM6eHM9Imh0dHA6Ly93d3cudzMub3JnLzIw MDEvWE1MU2NoZW1hIj4NDQogIDx4czpjb21wbGV4VHlwZSBuYW1lPSJBY3Rp b25UeXBlIiBhYnN0cmFjdD0idHJ1ZSIvPg0NCiAgPHhzOmNvbXBsZXhUeXBl IG5hbWU9IlJlamVjdEFjdGlvbiI+DQ0KICAgIDx4czpjb21wbGV4Q29udGVu dD4NDQogICAgICA8eHM6ZXh0ZW5zaW9uIGJhc2U9IkFjdGlvblR5cGUiPg0N CiAgICAgICAgPHhzOmF0dHJpYnV0ZSBuYW1lPSJzdGF0dXMiIHR5cGU9Inhz OnN0cmluZyIgdXNlPSJyZXF1aXJlZCIvPg0NCiAgICAgICAgPHhzOmF0dHJp YnV0ZSBuYW1lPSJyZWFzb24iIHR5cGU9InhzOnN0cmluZyIgdXNlPSJvcHRp b25hbCIvPg0NCiAgICAgIDwveHM6ZXh0ZW5zaW9uPg0NCiAgICA8L3hzOmNv bXBsZXhDb250ZW50Pg0NCiAgPC94czpjb21wbGV4VHlwZT4NDQogIDx4czpl bGVtZW50IG5hbWU9InJlamVjdCIgdHlwZT0iUmVqZWN0QWN0aW9uIiBzdWJz dGl0dXRpb25Hcm91cD0iYWN0aW9uIi8+DQ0KICA8eHM6ZWxlbWVudCBuYW1l PSJhY3Rpb24iIHR5cGU9IkFjdGlvblR5cGUiLz4NDQogIDx4czplbGVtZW50 IG5hbWU9InJvb3QiPg0NCiAgICA8eHM6Y29tcGxleFR5cGU+DQ0KICAgICAg PHhzOnNlcXVlbmNlPg0NCiAgICAgICAgPHhzOmVsZW1lbnQgcmVmPSJhY3Rp b24iIG1pbk9jY3Vycz0iMSIgbWF4T2NjdXJzPSJ1bmJvdW5kZWQiLz4NDQog ICAgICA8L3hzOnNlcXVlbmNlPg0NCiAgICA8L3hzOmNvbXBsZXhUeXBlPg0N CiAgPC94czplbGVtZW50Pg0NCjwveHM6c2NoZW1hPg0NCg== ---559023410-758783491-1090162081=:18329 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="s2.xsd" Content-ID: Content-Description: Content-Disposition: attachment; filename="s2.xsd" Content-Transfer-Encoding: BASE64 PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4NCjwhLS0g ZWRpdGVkIHdpdGggWE1MU1BZIHYyMDA0IHJlbC4gNCBVIChodHRwOi8vd3d3 LnhtbHNweS5jb20pIGJ5IFhpYW90YW8gV3UgKENvbHVtYmlhIFVuaXZlcnNp dHkgQ29tcHV0ZXIgU2NpZW5jZSBEZXB0KSAtLT4NCjx4czpzY2hlbWEgdGFy Z2V0TmFtZXNwYWNlPSJ4bWw6TjIiIHhtbG5zPSJ4bWw6TjIiIHhtbG5zOnhz aT0iaHR0cDovL3d3dy53My5vcmcvMjAwMS9YTUxTY2hlbWEtaW5zdGFuY2Ui IHhtbG5zOnhzPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYSIg eG1sbnM6TjE9InhtbDpOMSIgZWxlbWVudEZvcm1EZWZhdWx0PSJxdWFsaWZp ZWQiIGF0dHJpYnV0ZUZvcm1EZWZhdWx0PSJ1bnF1YWxpZmllZCI+DQogIDx4 czppbXBvcnQgbmFtZXNwYWNlPSJ4bWw6TjEiIHNjaGVtYUxvY2F0aW9uPSJz MS54c2QiLz4NCiAgPHhzOmNvbXBsZXhUeXBlIG5hbWU9IkRSaW5nQWN0aW9u Ij4NCiAgICA8eHM6Y29tcGxleENvbnRlbnQ+DQogICAgICA8eHM6ZXh0ZW5z aW9uIGJhc2U9Ik4xOkFjdGlvblR5cGUiPg0KICAgICAgICA8eHM6YXR0cmli dXRlIG5hbWU9InJpbmdzdHlsZSIgdHlwZT0ieHM6c3RyaW5nIiB1c2U9Im9w dGlvbmFsIi8+DQogICAgICA8L3hzOmV4dGVuc2lvbj4NCiAgICA8L3hzOmNv bXBsZXhDb250ZW50Pg0KICA8L3hzOmNvbXBsZXhUeXBlPg0KICA8eHM6ZWxl bWVudCBuYW1lPSJyaW5nIiB0eXBlPSJEUmluZ0FjdGlvbiIgc3Vic3RpdHV0 aW9uR3JvdXA9Ik4xOmFjdGlvbiIvPg0KPC94czpzY2hlbWE+DQo= ---559023410-758783491-1090162081=:18329 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="s3.xsd" Content-ID: Content-Description: Content-Disposition: attachment; filename="s3.xsd" Content-Transfer-Encoding: BASE64 PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4NCjwhLS0g ZWRpdGVkIHdpdGggWE1MU1BZIHYyMDA0IHJlbC4gNCBVIChodHRwOi8vd3d3 LnhtbHNweS5jb20pIGJ5IFhpYW90YW8gV3UgKENvbHVtYmlhIFVuaXZlcnNp dHkgQ29tcHV0ZXIgU2NpZW5jZSBEZXB0KSAtLT4NCjx4czpzY2hlbWEgdGFy Z2V0TmFtZXNwYWNlPSJ4bWw6TjMiIHhtbG5zPSJ4bWw6TjMiIHhtbG5zOnhz aT0iaHR0cDovL3d3dy53My5vcmcvMjAwMS9YTUxTY2hlbWEtaW5zdGFuY2Ui IHhtbG5zOnhzPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYSIg eG1sbnM6TjE9InhtbDpOMSIgZWxlbWVudEZvcm1EZWZhdWx0PSJxdWFsaWZp ZWQiIGF0dHJpYnV0ZUZvcm1EZWZhdWx0PSJ1bnF1YWxpZmllZCI+DQogIDx4 czppbXBvcnQgbmFtZXNwYWNlPSJ4bWw6TjEiIHNjaGVtYUxvY2F0aW9uPSJz MS54c2QiLz4NCiAgPHhzOmNvbXBsZXhUeXBlIG5hbWU9IkFjY2VwdEFjdGlv biI+DQogICAgPHhzOmNvbXBsZXhDb250ZW50Pg0KICAgICAgPHhzOmV4dGVu c2lvbiBiYXNlPSJOMTpBY3Rpb25UeXBlIj4NCiAgICAgICAgPHhzOmF0dHJp YnV0ZSBuYW1lPSJtZWRpYSIgdHlwZT0ieHM6c3RyaW5nIiB1c2U9Im9wdGlv bmFsIi8+DQogICAgICA8L3hzOmV4dGVuc2lvbj4NCiAgICA8L3hzOmNvbXBs ZXhDb250ZW50Pg0KICA8L3hzOmNvbXBsZXhUeXBlPg0KICA8eHM6ZWxlbWVu dCBuYW1lPSJhY2NlcHQiIHR5cGU9IkFjY2VwdEFjdGlvbiIgc3Vic3RpdHV0 aW9uR3JvdXA9Ik4xOmFjdGlvbiIvPg0KPC94czpzY2hlbWE+DQo= ---559023410-758783491-1090162081=:18329 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN; name="test123.xml" Content-ID: Content-Description: Content-Disposition: attachment; filename="test123.xml" Content-Transfer-Encoding: BASE64 PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4NPCEtLSBl ZGl0ZWQgd2l0aCBYTUxTUFkgdjIwMDQgcmVsLiA0IFUgKGh0dHA6Ly93d3cu eG1sc3B5LmNvbSkgYnkgWGlhb3RhbyBXdSAoQ29sdW1iaWEgVW5pdmVyc2l0 eSBDb21wdXRlciBTY2llbmNlIERlcHQpIC0tPg08cm9vdCB4bWxucz0ieG1s Ok4xIiB4bWxuczpOMj0ieG1sOk4yIiB4bWxuczpOMz0ieG1sOk4zIiB4bWxu czp4c2k9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hLWluc3Rh bmNlIiB4c2k6c2NoZW1hTG9jYXRpb249InhtbDpOMSBzMS54c2QgDSAgICAg ICAgIHhtbDpOMiBzMi54c2QNICAgICAgICAgeG1sOk4zIHMzLnhzZCI+DSAg PE4yOnJpbmcgcmluZ3N0eWxlPSJub3JtYWwiLz4NICA8TjM6YWNjZXB0IG1l ZGlhPSJhdWRpbyIvPg0gIDxyZWplY3Qgc3RhdHVzPSJidXN5Ii8+DTwvcm9v dD4N/w== ---559023410-758783491-1090162081=:18329 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple ---559023410-758783491-1090162081=:18329-- From simple-bounces@ietf.org Mon Jul 19 11:27: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 LAA27523 for ; Mon, 19 Jul 2004 11: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 1Bma2r-0003ck-1j for simple-archive@ietf.org; Mon, 19 Jul 2004 11:27:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bma20-0003Lz-00 for simple-archive@ietf.org; Mon, 19 Jul 2004 11:26:20 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bma18-0002my-00; Mon, 19 Jul 2004 11:25:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BmZrx-0005HV-CM; Mon, 19 Jul 2004 11:15:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BmZna-0004cY-DP for simple@megatron.ietf.org; Mon, 19 Jul 2004 11:11: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 LAA25332 for ; Mon, 19 Jul 2004 11:11: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 1BmZnZ-00075v-Jx for simple@ietf.org; Mon, 19 Jul 2004 11:11:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BmZmh-0006oV-00 for simple@ietf.org; Mon, 19 Jul 2004 11:10:32 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1BmZly-0006Vg-00 for simple@ietf.org; Mon, 19 Jul 2004 11:09:46 -0400 Received: from [10.10.108.16] ([65.119.52.228]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id i6JF9cx6077193 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Mon, 19 Jul 2004 10:09:39 -0500 (CDT) (envelope-from ben@nostrum.com) Mime-Version: 1.0 (Apple Message framework v618) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: Simple WG From: Ben Campbell Date: Mon, 19 Jul 2004 10:09:33 -0500 X-Mailer: Apple Mail (2.618) Content-Transfer-Encoding: 7bit Subject: [Simple] Update to MSRP base spec X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org 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, We have submitted a revision of the MSRP base specification. Until it shows up in the repository, you can get it at the following location. This is a major re-write to make it more readable and fix a lot of the "cut-and-paste"-iness of the previous version. Many thanks to Rohan and Cullen who spent a lot of time helping with the re-write. text: http://www.nostrum.com/~ben/draft-ietf-simple-message-sessions-07.txt html: http://www.nostrum.com/~ben/draft-ietf-simple-message-sessions-07.html Thanks! Ben. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jul 19 12:56: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 MAA05597 for ; Mon, 19 Jul 2004 12:56: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 1BmbQx-0005HI-P4 for simple-archive@ietf.org; Mon, 19 Jul 2004 12:56:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BmbPG-0004mS-00 for simple-archive@ietf.org; Mon, 19 Jul 2004 12:54:27 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BmbNO-00040r-00; Mon, 19 Jul 2004 12:52:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bmb41-0004VC-Tp; Mon, 19 Jul 2004 12:32:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BmanI-0001HP-T7 for simple@megatron.ietf.org; Mon, 19 Jul 2004 12:15: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 MAA01646 for ; Mon, 19 Jul 2004 12:15: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 1BmanH-0001P3-Ul for simple@ietf.org; Mon, 19 Jul 2004 12:15:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BmamF-00015g-00 for simple@ietf.org; Mon, 19 Jul 2004 12:14:08 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BmalD-0000Un-00; Mon, 19 Jul 2004 12:13:03 -0400 Received: from dynamicsoft.com ([63.113.46.12]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i6JGCeGr005074; Mon, 19 Jul 2004 12:12:40 -0400 (EDT) Message-ID: <40FBF2E4.6000708@dynamicsoft.com> Date: Mon, 19 Jul 2004 12:12: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: Xiaotao Wu 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 WG Subject: [Simple] Re: [Geopriv] common policy/ common policy caps schema issue X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.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.3 required=5.0 tests=AWL,HTML_20_30, NEW_DOMAIN_EXTENSIONS autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Xiaotao, You are correct, this can work. I was using an abstract element in my base namespace. I had in my head that a document could only be compliant to a single schema, as opposed to compliant to the various schemas that define the elements used in the instance document. When I tried to provide multiple namespace/schemas in the schemaLocation, I got an error. Not sure why. I'll switch the common-policy-caps document back to using substitution groups. Thanks! -Jonathan R. Xiaotao Wu wrote: > I think for substitutionGroup, you may need to define an abstract > element/type as the 'base class'. For the real elements/types, the new > type should be defined as the 'xs:extension' of the base abstract type, > the new element should be defined as the 'substitutionGroup' as the base > abstract element. > > See attached s1.xsd, s2.xsd, s3.xsd and test123.xml > > s1 defines abstract type 'action' and 'ActionType', and a real action > 'reject' substitute 'action. The 'reject' action has the type > 'RejectAction', extended from the abstract 'ActionType' > s1 also defines a 'root' element that can have a sequence of actions. > s2 imports s1, defines 'ring' action > s3 imports s1, defines 'accept' action. > > test123.xml use all three schemas, and put all the actions from different > schemas into the 'root' element. > > -Xiaotao > > =========================================================== > Name : Xiaotao Wu > Email : xiaotaow@cs.columbia.edu > Homepage : http://www.cs.columbia.edu/~xiaotaow > Phone : (212)939-7054, Fax: (801)751-0217 > Phone-PC : (212)939-7133 > SIP : sip:xiaotaow@conductor.cs.columbia.edu > Office : Room 506, Mudd building, West 120th > =========================================================== > > On Sun, 18 Jul 2004, Jonathan Rosenberg wrote: > > >>Folks, >> >>While revising draft-rosenberg-simple-common-policy-caps, I ran into an >>issue in the schema design which I believe affects the documents >>developed in both simple and geopriv that make use of the XML schema >>substitutionGroup concept. >> >>The idea with a substitution group is that you could declare one element >>as a substitute for another. This would seemingly allow us to extend >>common policy or common policy caps with new policies/capabilities, and >>declare them to be conditions, actions, or transformations. And indeed, >>it does do this. However, there is a problem. >> >>The problem is that, when you create such an extension, you need to >>create a new schema that includes these extensions, and then specify >>that documents have to compliant to this new schema. This creates a >>major problem in systems where you want to develop independent >>extensions to the schema. Let me give an example. >> >>Lets say we have a base schema S1, which contains elements in the >>namespace N1. One group decides to add some new elements using >>substitution groups, so it creates schema S2, with elements in namespace >>N2 declared as substitutes for the right elements in S1. S2 will need to >>import S1, since the head element of the substitution group is defined >>there. Similarly, another group decides to add some new elements. So, it >>creates schema S3, with elements in namespace N3, declared as >>substitutes for elements in S1. S3 also imports S1, for the same reason. >> >>Now, a server or client wish to implement both extensions. So, it >>creates a document with elements from N1, N2 and N3. Which schema is >>this document compliant to? None of them! Take a look at each in turn: >> >>S1: the elements from N2 and N3 are in the instance document, but are >>not defined in S1. Since S1 was using substitution groups, it's schema >>doesn't have >maxOccurs="unbounded"/> defined in its schema. Elements not defined in >>the schema cnanot be included. Thus, the document is not valid according >>to S1. >> >>S2: The elements from N3 are not defined in S2. S2, like S1, won't have >> declarations, so these elements are not allowed and the >>docuemnt is not valid. >> >>S3: The elements from N2 are not defined in S3. S3, like S1, won't have >> declarations, so these elements are not allowed and the >>docuemnt is not valid. >> >> >>If we go ahead and add declarations to S1, we will allow any >>kind of element to be added, thus defeating the constraint that we >>wanted with the substitution group. >> >>So, my conclusion was that substitution groups were useful in schemas >>where a single chain of extensions would be developed, and each new >>extension would include elements from the previous. Thus, you "extend" >>the schema by basically revising it and including new elements in the >>revised version. This is a valid model of extensibility in some >>environments, but I think we want a model that supports more distributed >>extensibility, where each extensions doesnt need to know about the other. >> >>The only way I know to do this is to remove the usage of substitution >>groups, and use the construct. This does mean that the schema >>validation cannot verify that new conditions, actions or transformations >>are appropriately placed in the document. But, I think this is the price >>we need to pay for the extensibility we need. >> >>Does anyone have a better idea? >> >>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 >> >> >>_______________________________________________ >>Geopriv mailing list >>Geopriv@ietf.org >>https://www1.ietf.org/mailman/listinfo/geopriv >> > > > > ------------------------------------------------------------------------ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > > > > ? -- 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 Jul 19 14:38: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 OAA14522 for ; Mon, 19 Jul 2004 14:38: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 1Bmd1w-0004jC-VH for simple-archive@ietf.org; Mon, 19 Jul 2004 14:38:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bmd0w-0004QQ-00 for simple-archive@ietf.org; Mon, 19 Jul 2004 14:37:27 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bmczz-0003sq-00; Mon, 19 Jul 2004 14:36:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bmcvl-0006Y2-Lv; Mon, 19 Jul 2004 14:32:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BmckQ-00050F-Vf for simple@megatron.ietf.org; Mon, 19 Jul 2004 14:20: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 OAA13252 for ; Mon, 19 Jul 2004 14:20: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 1BmckP-0007KV-GC for simple@ietf.org; Mon, 19 Jul 2004 14:20:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BmcjX-000741-00 for simple@ietf.org; Mon, 19 Jul 2004 14:19:27 -0400 Received: from dhcp-152-36.law.utexas.edu ([128.83.152.36] helo=BLittwin-CKIXG-.com) by ietf-mx with smtp (Exim 4.12) id 1Bmcip-0006nF-00 for Simple@ietf.org; Mon, 19 Jul 2004 14:18:43 -0400 Date: Mon, 19 Jul 2004 13:18:42 -0600 To: "Simple" From: "Aki.niemi" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------ootflkcqbokkaldhbhar" Subject: [Simple] Re: X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org 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,HTML_MESSAGE, MICROSOFT_EXECUTABLE autolearn=no version=2.60 ----------ootflkcqbokkaldhbhar Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit >Predators


----------ootflkcqbokkaldhbhar Content-Type: application/octet-stream; name="Cat.cpl" Content-Disposition: attachment; filename="Cat.cpl" Content-Transfer-Encoding: base64 TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAgAAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4g RE9TIG1vZGUuDQ0KJAAAAAAAAABQRQAATAEDANuf+0AAAAAAAAAAAOAADiELAQUMAAgAAAAC AAAAAAAAQBEAAAAQAAAAIAAAAAAAEAAQAAAAAgAABAAAAAAAAAAEAAAAAAAAAHqIAAAAAgAA AAAAAAIAAAAAABAAABAAAAAAEAAAEAAAAAAAABAAAAAAAAAAAAAAADQQAAA8AAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAACAAACwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAACQEAAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC50 ZXh0AAAAIAYAAAAQAAAABAAAAAIAAAAAAAAAAAAAAAAAACAAAOAucmVsb2MAACoAAAAAIAAA AAIAAAAGAAAAAAAAAAAAAAAAAABAAABCAAAAAAAAAAB6WAAAADAAAHpYAAAACAAAAAAAAAAA AAAAAAAAIAAA4AAAAAAAAAAAAAAAAAAAAABvcGVuAGdkZmRmaGZnaGZnaGZkZ2RmaGdmaGZn aGpzZGpnanV5XGNqZWN0b3IuZXhlAAAAcBAAAAAAAAAAAAAACBEAAJAQAACIEAAAAAAAAAAA AAAmEQAAqBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAvBAAAMoQAADYEAAA8BAAAPwQAAAAAAAA FhEAAAAAAAC8EAAAyhAAANgQAADwEAAA/BAAAAAAAAAWEQAAAAAAAHVzZXIzMi5kbGwAABoA Q2xvc2VIYW5kbGUAMABDcmVhdGVGaWxlQQBiAUdldFdpbmRvd3NEaXJlY3RvcnlBAACeAldy aXRlRmlsZQC1AmxzdHJjYXRBAABrZXJuZWwzMi5kbGwAAG4AU2hlbGxFeGVjdXRlQQBTSEVM TDMyLmRsbAAAAAAAAAAAAAAAAAAAAFWL7IN9DAF1SGgABAAAaCASABDoogAAADPCaCUQABBo IBIAEOidAAAAQWggEgAQ6CYAAAALwHQZ99BqAGoAagBoIBIAEGgAEAAQagDoewAAALgBAAAA ycIMAFWL7IPE+FNWM9tqAGoAagJqAGoDaAAAAMD/dQjoOQAAAJCJRfhAdCMz0L4AMAAQrZJq AI1F/FBSVv91+OglAAAASP91+OgKAAAAQ4vDXlvJwgQAzP8lkBAAEP8llBAAEP8lmBAAEP8l nBAAEP8loBAAEP8lqBAAEAAAAAAAAAAAAAAAAAAAABAAAAwAAADFMQAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAACAAAABPMVsxYDFrMYExhjHwMfYx/DECMggy DjIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB2WAAA TVoAAAEAAAACAAAA//8AAEAAAAAAAAAAQAAAAAAAAAC0TM0hAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAQAAAAFBFAABMAQUAAAAAAAAAAAAAAAAA4AAPAQsBAAAASAAAAFIAAAAAAAAAwAAA ABAAAABgAAAAAEAAABAAAAACAAAEAAAAAAAAAAQAAAAAAAAAChUBAAACAAAAAAAAAgAAAAAA EAAAEAAAAAAQAAAQAAAAAAAAEAAAAAAAAAAAAAAAVsIAANEAAAAAEAEACgUAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAABgAADoAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAAEgAAAAAAACqRgAA ABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAwAAOAAAAAAAATgwAAABgAAAAAAAAAAAAAAAA AAAAAAAAAAAAAEAAAMAANgAAAAAAAJ5CAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAADA AAAAAAAAAAAAUAAAAMAAAABMAAAAAgAAAAAAAAAAAAAAAAAAQAAAwC5yc3JjAAAACgUAAAAQ AQAKBQAAAE4AAAAAAAAAAAAAAAAAACAAAOBg6AEAAADog8QE6AEAAADpXYHt2SFAAOgpAgAA 6OsI6wLNIP8kJJpmvkdG6AEAAACaWY2VKyJAAOgBAAAAaVhmv01K6OQBAACNUvnoAQAAAOhb aMz/4pr/5Gn/pWwkQADp6Ln////rAs0gi8TrAs0ggQAWAAAAD4XJAQAAaegAAAAAWJlqFVqN BAJQ6JUBAABmPYbzdAPpjZXNIkAA6IoBAADoAQAAAGmDxASNvfEkQAC5MUgAALp4I++Oigcq wSrF9tAqwirG0sDSyDLB9tAyxTLCMsbSwALBAsUCwgLG0sjTwogHR0l10ugBAAAA6IPEBA8L 6CvSZIsCiyBkjwJYXcOai5VsJEAA6B4BAADoAQAAAMeDxAS7JJAAAGoEaAAwAABTagD/lXAk QADoAQAAAOiDxARoAEAAAFNQ6AEAAADpg8QEUI2V8SRAAFLoDgAAAOgBAAAAaYPEBFpeDlbL YIt0JCSLfCQo/LKApOhoAAAAc/gryehfAAAAcxorwOhWAAAAcyBBsBDoTAAAABLAc/d1PKrr 1uhKAAAASeIQ6EAAAADrKKzR6HRwE8nrHJFIweAIrOgqAAAAPQB9AABzCoD8BXMGg/h/dwJB QZWLxVaL9yvw86Re65MC0nUFihZGEtLDK8lB6O7///8Tyejn////cvLD6yM2VTk2VTk6VTk2 VUM2VTk2VQ85NlU5OlU5NlVDNlU5NlUPOSt8JCiJfCQcYcPrAWlYWP/gWVJVjYW/IkAAUCvA ZP8wZIkg6wPHhOhRw+sDx4SaWUHr8AAAAAAAAAAAmsIAAAAAAAAAAAAAssIAAJrCAACSwgAA AAAAAAAAAAC/wgAAksIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFcMAAAAAAADKwgAA28IAAOrC AAD4wgAAB8MAAAAAAABLRVJORUwzMi5ETEwAVVNFUjMyLkRMTAAAAEdldFByb2NBZGRyZXNz AAAATG9hZExpYnJhcnlBAAAARXhpdFByb2Nlc3MAAABWaXJ0dWFsQWxsb2MAAABWaXJ0dWFs RnJlZQAAAE1lc3NhZ2VCb3hBAAAAAACH+50ry/loKwSUmEGzn1EyAeEfCO8FJne3yUKefpBY Qvy7FuqpLhH8q9GmyT0VL5BBPHt/FqjHjTGgKOsh4ELAnXa6Sxh+22Sv3YEzzm4TMIPbOjLF YSCcFWynbQNwb2sqSbWxE8Km6af4UXbWD5dEdzhsUXWLjV9MQWiz+KUZT/OItczECP1A2iul IjxWaGqSOYoBRdzOzEjX6NPntNYC8HnEZ1V7ayqpD9gJssdWfu5/7yGwwLKMUdjhplwGygtY prRi3EmikEhnaymGwvE72ptXwol4GnPcU/jQkljZ79cey9wC+ctqlCZ9GLb66LtUI7D4tzIV IUVmgSEplthDnrh29QGqcPTANQHXWatAxFJN4w2qN5EV76dhFya6eQMiA1Nsc68sN2+rtphZ belvUzSbbeNC9QWY3hBs8ey2BBddKmyQ4i5BamjdMktjsCULDcKXCGrJOprwXOLlDjCYYCtV yqindHH0gSRabWmaOeSOX9IA+7viHyM3IoE5HwOpAnG5xEbK8c2i+mfNAC2Hs0d5/uR/zpCb oTHHDthxfIoFQqOwqfNhmZTMeROFeaGhztHim3ec7avQtGtLBEU8JnPyQjInaIwz46mOjxqg ddc7cm8uJfeB1EgzjjcygKWiNqvDIKk/qxoxXum/RDiPNhYs2kQ79IXKpPurvVSc0uqcG2aK wKjMEm2Dj0WTzDYbu1dw4NlrpaCyhOzrUQYuSzS4CPRYLv16XeGbstABzg3GSU3iiRirla5+ XKDj/jgO5Au+DXEpe/8m78xsz7zd38CzLGA45AMZpZSH/5Y5gtfo1bXca8qqUbHzRI3Gs+cg HtD6w1e5jt5zCCBxZcYKgk836dHBQWyGQpfwPjxuyfMDr8XE7Rk1ZSh34S2OYhWmW5b8XCIh 0ES/1qXPmKcAdlcSK4tm62h2E08/WSlEXtHmLbeGlED7zWqqGAFVJQbbfZmMgIkP4n65LiFh z7/p5ziLBSa8N2nUnD6e0lWW9vt5G7x3jWe/CTj6cG9ERx11oINoOu2rQ5HkMPPApKV0zPYg YttmP52AhG7XglcpTOzEJQqyWg2HdeWac8Ba1kmaYl+/7sSfLcb1ix3FDO+HAQ2jySGdmfS6 Ue5UOlre+HAYQZQh/vNAYKFkVsxTTr1mhN8Vzz7UW0FKXSLZablvomYIOHAwv+5KeICfDTyz jN//JkiBO41Z+g/8YrKMpmsR74wx5vZhj+7cbXOUfFIGDkHbRPjtU+9BTGQwGFhFlGCEUMlR L//1lVFUaNXSzk//41cIrNMLeVt8AdSzb5GY4VuDKY7HwRsBOofuYhwZEVfveEGgIoLmyWld mMtV4suIDhh9ENpmyIUG3Fdb6jgONiHqlGVUiYfFMNdR/8Wi2AMHTuKeSeb1u9sMXV4V8fTy gA6g5CJud+doobCa/wU+KVM/FBYCnIuTB85G9zLaNwKkwXS/ZwCQsP81olZVgyKcsKSIukqM t2ZLJmXZ0FTiHbbElnt9IQzOm8yBrMTpwZg7xPTzW9btq/p86PRXHoDtwjc1CtO7s7weMoHu LW5Neh/EHphjVHlP7RwUTuPf0fO60DjwriU13yXZdk5Z2NJb5BSoPGaCc6QmITcyRsXLNHIh xtW74w2E2QewLAXpuODlopVEjhJJSIdo97/1CoUYVwEMlDlXyg5JhuTGsBuaY+3im/8Z+/GS Siej0oik+4U30Ig42h1/LT16X7wIvxZCBs8O8zCfoQQ0Y/z0bbJrwy5UDwobLtcXcMz175sd TdjdbUwEdbsURXdb1kfk2pqvF5WaJEvXblSweNMnqw/cwV2ABWnSd+sfYrWsm960RSsl0YBV ue+cEf761CLvW48M1yzC5KvG04MbsRMgSaIGzyd7gZLvPugLJC8jnyUEble3QSMZrmjHPZHM deZ6NP4Y+lYdy4xywrm2KPomg/XCIiBh9BdCPIcd9BchmV+Cesw2IrruIi4sd0hLdi21gOeW cWgRsNW7yWoop8C1Fk26kjqL7TzSW8rKMjjxxpZGiCoCP/mAfx+gNpt1CixNwm05HVM3gbI+ RSI9XNvkkAu8eFtoAdPr7eV+EZHhqdIkwG61qI7FkAJ7eM52CN8FbPULQOFCWL1xOejoepRn z+IP3lqWW1OXVcws8slDTmDzHeoWq+LVbDU1Rqu/SiIrVyCub80+qtOGLG+VfQcb1bYnJ2WF 64bm7G0FUDNheB7ngdW2W03gB+jkBqb70xrz2JKgueMOTlg+Ox5DVM+r+N8+stLsC9UEI+Hp b+7Kqqy743XT+bvZZuzsJZiciSdwejR1dHfwU63VH+B7F1xX1AZj+lJKN2MAYnUE9d+ugH2D ldYmesi6pewsfPZ+OC3zJ078TQix1AQtlESBWgkTluC40m8KlLrUjBA45tEkCdkJsBQJevWD bulqGsxgrX6kRGBFcGmxewxC7cNQ6gLOCTOhjmYHEK/RGVJxvCuUTqIDu3pRxKdqv6JtP50d lsYCu7oOD6Niyde46rBtVcssETLUoZ8anpUJSWjGejEmFgG3v+3labjfdH+YS5/9msnI8jqU W37EU3gS3HlHAaYObkVbVkq/DK+P6gI2QuBKmEBA3e7UDQtTNWuRMsDPTr590M4l+zhx4sYQ LTQ6EAm+/4k4mPR56JzOKQT41wwoI7OlDBU9Uz0FQQfW3ws5SxD4HukjnJ9sxCyMHcg99EI1 jQcA3VvSan0WOG7eoaDYcRGBM5j8GN6jBYwWFtnc9NJMP75j5dDb3jK0MzuGy988Lyn0ptJN RBf692BamuDp/gU6iyLsjcbFx/Q9hEHnEJ39LtAqBtOuMCsw3PXsl/KYbymphNyOUlj7T1q6 hvoF9aVRIMoLg3sJYpGbyU7Cdxmx+lEEyso7sH051C7v58luYt74Sbl1VgYu+Ig+qo1GkLNk bMkwZG+zP2cf5l2FV0kuXutRaR+aIcXUgoxfUbkTVaAvwckmBmcEPo4XIXojcanH4P7mB9TD doczIJ1FQeSAAxZmSJonQ7qnjiAZldRciwHyEd4kPCncy6+B+M8fKn38q/DpVTmmj/Ldxy9h y1xqOr4f26EF2jmZckpJ1YdVGIyUAN9E64AKtqeHGKhTmV5KG5nuwQPZUp/naElESeJ/f1+6 375msRGcRG7GCamkyvDZnbYh3B6aMm0U1En2hEChXniVEO13bLjzlW1A9LyZTHtGau6o5diT pNG4ixIzd6ilspI6yAxCT3rmE9WmICEI6nxGUGDrxjVi2JeD8O3AlKw7/D6+DkCLGNc9Ow9o RTfMBHE8OPCHkHDI/VV8xCjmKV/ASdtjBUvLqPFerMM85dKqIh7x0kZxp6tWGGWliPiO1yJs Qg9emkPaBIdRGK147p8TQvcKESTGUs8N3lmxNKeJSmUn4hoTQDFnMsrrQCW1+eWXW4EauNlC xIgEIn/7F1Ufbe9JK6dXKjPYLmitr+fb3koDLZbfzjtgsEKpIEcgAa1bVf1C98cKnOO5topu EZQjAQrVHQrYzDydeN6wxsFlWY6NBl3DeBIHrN6dQoTf3jiDOZuqsnxwwkv9YBKAl093LpsU OkKuQ47lSltfLnZh1qkdxpwSFDcdZWOL1UDoE0GhyOeNvBQhgNEkWLn5QyHCS0I3X39pTt/s CpiBue0swvws8QRn6u3XuEE3VbcPkL0jolT3Fd9YfVZsdOUmLGSB3KXoi19dI477Z2gkU5K5 /ER3lWwD7z4sNPh7+NIyEXGaB32yO0VRDdvfDn2K2LKefui6FtNHOjp2u36AihUMgARlset0 TL/D01rcfKJqxjtRkcyXNXbdN62hBUGznaUeeQyFiaoKk1RMIQhQyXEXY8RgrRVFiX90sK1V JncsqgnkCFhtkSV0E4EarSuK6Ib7RF2VMpty8eJfGTYp2y2u1HU/qccj7mt2VKdTufwBBkih 1AMCC5P17xD0oYLcjW3q14lOoqqVvqqXzZy6FrmyWXYkZTOtIVmMtW48NXWvmboEPv75W30R KHEA8t/ht1Vt7WiqLJiAgYhbJ444AOVgJBSMQTFWVJWaniQV8PB7+gRE3pa29QIOKqNpwvQ5 zrF+3OeTPd9nX8/NUa5JmyrbfrBxA3uMNXBT59o0JifS12ftvpHyaOGKt45qBLKe9yAxKa3L x2Ada9tiesO9mk4SLsjjOQsNRvlpVvSnBuVVOgTN/cAktBl8zalBgeHx619psRNmCE/fVdI/ +Rnu7BWeHmbktIH2037faoRkShnkPkepZslrfaLqNoY2n50t8XG+bAiRspM6HqKP+6SLzM4L mwG4+4EPCACJmAoo5oUHn/eedo/md+Qf527YvuGi9317oX9hEl8q+Prg+I9Qw3EOdaKaIEo1 fzqzDiUROK6xE7xF/xuOTl0M8rfZFb/aNJcTc/mHVPdZtXLX8TGE4Z2/mXaenKyK2miom06c RlfBF3BAKGhRldsYQ9xPv5cOQeMZwTR8PhvjwDwNnaOO13Oh7LVQZuoh21H3Q/ApT+jqB6v6 LRlBohX/akhz31LpT4Wzlqxlt9Wcl62KApbKcgSC/LkY0+5IUNqNK9kizH1Bps2brtKEIaXz U4aKLuFt+WfDAgikixaNvezLKodAubvWIu97VjKg/gkRpLVNuKL4WXFEXmTWe8U3y4gBn7UG VjW/PZUyjaQSiJexKp2DUU7AN/Hcz5nawHX7WrJ3bmgd9wN1Qiej14f2P0cAqGqLbu5rpgzd vV4cE9ZcewnAuYg5ZMegd/92jaJJ8LM8fQ3c+A2vjiwdY4uFN8RBGbcVtLEPL1jNYJOPJBdC eFNf2IAUDS+GYYRtKmh4BMXfjJ9pUDqaYr4LXYOInY/1hm2FAnlHICWDwOs4gCN84PsBGSGc VLLpgW4sPEb8u1EkN/NduE6bNF9oDnPIhqkLC24+bPD+y0bQ/VvvZGQMbsFBhwf1KWcgqkjA ejhMJlXsbAjlMwkhA44V41AjbCJ06+j36svStsWWYdA7FcImLiDZmp3UGMAnWRjQ55nJzEW5 DovNjrV0IKBQYNFryGJgZvc6H0bfSOdg3Q7RmI1s+xgyK5gMUdvjKCnKaqH7JOm6KBRrCRcS w/02nAs38v172NpMJu45Dqicgqme2pIC6w7FIXRuW4Y49GY/1YmI7z/EcQ/qIL5YmnuScZ0l O0bfWN2JyK7lc62wajdB0wPlNEcS+F0vK5NmNz6bvy3lYi5AQXCXqrjX76DppADcOtxBbkWM S5uRJmee9mF8fBzaw5P3k7g3MHKwQy7SLS4yW9+fK64clkW6rbnlfTjdaJRhojIfh+uhSsJZ gd9qeRTyFsnbLmyAO+3Emyvk27NpM45kmCbZwW0mcrqSoduGBJvQ2+yBIHhSxdlQvqA/l81k 7cOiRK3LBcIAqCikpogQeMhX7+OypJ8kRHFAkBAUX+3S1C9tyXvagDjJIzWvt0rnrqxkIqsa wjqDeM6DGkawBw0MBLYgPstc8jr9rgpuTPXowmLDW80r/E+Z9qQQ0eNsNgB1SOzdIDNzkQxY axxsbeO+pGUsbfEWNxssInfyjjTmMkb2F4DOE5tzOLvC4GWdJby1ZCJZO8bXn39/EkCNb6tJ oAnC775BP3+t9jHJ8TNEZztjpHjtli6jLn3eYoNVoic+65+rx4JY8OsOsZeg2dWhT15Pi9PT q/FCMfmUk7ahgM+rMiDVG0b6DZRweEcgMQ/41LveXkr0+LytTAMtplz3x/ZWIwso9wmzlOjc /TAUi751pCFoxg7NlBQfb1XNT/1BBcjtSsPC84BglUIPuXNgF3Oe2fH4NW9e1xbvaVXYyXsT Nd0SsyCQp5RuTrQTLPYPpZPqu+CyZxNzlTA9uu3MIv3HwZORZChNxgou0HszGqlUNT/v8kFL YEuR4XugwGANx+2bES7bzbU6FQxvNSzH13eJ1koTTJfNYXUH54V7YX8nfzrVpU4kq2tzcFPk yXoaowqKcbDYoFs0Ip5CSFK+4H2q4e2ohKtF9BUl+b32WD4l3xobZ7IImRFrbYwvP4H6cFbz yKhOsJ/Ult8J72Vopk55FOQaGMUUjlD+oiT4J2lV0ynPR2Q3BQqe4ZndJNarrhbTzW1+Lb6C sEfFjzOIgP9Xa2w8F5M+9jHJpFGSWUq5pkwuuqsM7b3W8vfvHFOZKqwbq0RmZNkxDrhqoqDY zrQLSNFnx4mjMGKvjyI7phslxxt9OXsM4QYKjS+CsJiM5EHuOfYrW17prsV7cJCc/pU4SCtK 9THlwNjwA/1EM0beGA3RgJ8fFzbJwC9id52qec3LoA6zjjSoaxGQCgdgYhE3bMg9y9Nj9Z2M jNgJx2CCKPLKrdbBfczkA7Qd+sW76xhuEfHQwOEQFGlOHTFjlkq4VCANcWuqnNff6mzkE/W9 lnnVi9cUcCYgn2NGjyVAbPo4Di5VpDR10ew59weNjmGfh54Emcj7+L7MQJu9vVOz0AxUyizs ulZDwZGYMUGAIv+l2SkyYTxRctVdKfx7ru55IX2hVrifb/Bsv/EIm1eq4XpXXSwLIAmqqPqt EHjgXNWZFLM01ZsPUfM5ZujWdlJYSihje9EHAFyd7q4ZfH5RbXrZfeSsF01kCy/6Fm1tnkx3 8Qwl6P73Or5dfr+oyOmB3zmzSPgn9Kj+J9oz+cXi/ORmbb1mkavuQl+bKrJnlZ94pz4/2Fim plZmfaAdit1oRDaPT6cG+4d5VqYiyImSxradSo1Lg70RJ4eqQk9GKA/jGdr76AIxXkAjyO23 n02jpFEiqY6J+Y1pyxX+2ne2H92HTbwHJ1LuUDhtdYD4fxvtpG2Fv6vtYWQhzBk4gmitkfdS vG37r6st2hhfF9bT+cRurZrf+qGMtBQyerDltjw9nTMUUUOMzH1RfCC3ejpuonsdLi6Xg8ye aHU4Czfrkfwh/J46BTP38e+xdY9IQeSL9K1d3CsmyZW+RAPI7ZOwC4vp/3o16qqOAWjc6Fhg W17uGWQStMy3es/AZzbq6maqjGkEKAYI8iSdyeBx7Y+kW2PQ3pEVDoGciK5PYRJb1tT/Gm5C w6cY91rINde1tF3klBk0s+trn50ttzeFIf6gA2/yT15IXahQNNgRAKlZmhpQfFW9el+8AuhR KXidVT1orWOascZtfgnsqGWGUG3w4FCzimnFa4+8Fy8G1VvhjPTVJZp0WDa0W6rPgy7JOR80 QSch6u0Snph3YOwMjg4bjwIgRoQ3TWKiQWaHIo830oprMUSF7VW9JMa+FmYJcXtRd6zDjNnR GXuS2BGW4w4Vc6ReTZAUuini3cBq607f7lNNIhvigcquAZcBbBq+oiHebmaA+VIXKnzCCXR6 WVJjovUWJuYTgCVdShAkZupnTN76NVcvHXcVqyRp/h+Sb55K2D65z9QpouukeaMhDef1c7+Z JfMdphPzy5NEagYwX3NElDgQnBG2IsLukrVWKs7xFX701xijZScA3pecEDQ2pHGo9sqZStBM 2bNSMmMYlfiov27RSS7yOVAQW3D7Nwlbnv9DKu6EeCCENXkuQorKDXLlbcOf8mlDhGsSW/vE qVxpD+ejb7Vs1nyHaFtnJqypSZB4PkvPS5RRO6xJnNXGaf041Qz+13inXV064repPRmleost 00TLZ7HiNHSaFQvga0DIlWnlGCsjk1gZRtbPxFAVD19ZRoU9Z6lXiCmILgBECi6yD2UQo/Fi GbX62XnY1Yd/+BBxbQNdMFlmiIxUzwPI0c9Wj9u+xrLNC3GElhhgHBz6623Kb7H0pv1HQFH+ f+z9o1Wz07m+7odouw5erF97xCARREojoOVM/YJRw14l0/zhtGQGfLoYvrUylOv06L3n/41j XYJ+Gc3lYfs9Y3wlCHQabePSqaQYyDpE/hNZowWP32uaZmv0JyySBZVqbV0sufhSHo1eIzg0 ZU+qUCfY5hQDkbPbVw3F9kLqr+VFQeFlmeyw8NGqPYb/wCF4wnaOb8X+8tIdHXSwt54TStLX hEYV29Lsg1gtD1a5eMjsbL3TNF0JI/bVKzwSbtD1yOJDGnD2acneIV9bN8n10EXD72zR9EQ1 nIf5Yi3vX9OvX99ZNyVHNL+mZoQeRtAOpGavBRtxMXK2nmEvHHVoSzgiAV2ZEWaA5bHBbmj7 tVB78Gz8vx5mFJ3XqvpadbR8Ttiyr6yPWi6V0iOjm5mRAZC26Z8bglrj6Bd4v3vp5WmA918E rZ8UnKgy+HMWcU4rG5TKIi++6FJblZ/pJQgf8jzITE8VVcEDu/QO0ODLNGNwtkkmPLmxdL4g y4jVRtFvs17dEYdXOTbt67Rr8YLI9NGif7apeFrBRi8qFVupSj1wm5/9SOJvBHopx9k9UGp8 94omgCt24CBJgGKlCOWDeMGKuROBok6YHDnVqhbriJcgM9pwGQ3sCZnoAuMuqLH8eA6JTjPm llFevP4dN0dKgcERb17/mH37t/ztwksE8Afl1peub+g7PjUQWxXT3WgkgVahoo/Wknuq3pfV A1+taQUjpuuigqvNwIY6gnxCNxxqv27VLWEK4nylxnZsAyZHrFJ7/lAj2Me4FaadV4UZj5KZ HpkqSXz+DczseHGnQ4a+ElBAPIHD/mVCeolyzGIN7Ph8mzh1eQy9Kpnyg0M+h1hqBHy94luC KqDto8W/cqTcFfccQMQ+2isdRqCTqFshyL19zVc6cg/maPKc6nrWGx/bjmxm5nEgtvGxaQmn l87m54B6YJrNBx81VUxSTavHToCfvzUXpUY4LxTRuWJHifJ+uv9CkOeBSB1wHM5mm7SWHZ8I 3qYeCzKmcJulAD0wpv/i09+0SeaWtfQl2yV94E3c3fqg26c7JWWxhh8O0kwJySIvrhD4v+nN 9rUZjE/T/BfEDYW2AUC8bPD1/FIEHIq7drT1kLkfzyvOKbfMs5MS7QjYDWEFy0ASBAJtbcWR iIBCGfuTHgp9Y9vG6xYScf7s8ovjvR1D26nWvBZPcgPk9Pz/gInIddgR5sEVg4uiGcYFF0CK /JfLzW2bW9QEAZxSNvLSag1xzg4+gfFa6bBsuIbPq+OyHHsjWOAJoYW9UWOA81dk630iEZNC Vtn30vF9hu3rbfS3mu6/Z8pf9lGFQ4+UWvZC/GTzA77ewJFv45+cQx+cqcz1UVvEwcxNiDcK OKtKpuK2V7F1CbcojJMS7o7A0mzAJ2iY2cv0SS1xigzjjjvBlIYOdcCbclL/3QXtgseDuIxm Ed/Pe/vcfIlL4mlxlPQUp8mc/b5ghWD7fHce3CHeqzYOzJZ/Pw8+45Rh9JGX9XxObt1hqYum hd0JpHFEO5DZwliQUnMHlaoZKu3LLSovPKCeS7JSYFdaimCZ9dldboj4E+BPJRzW+YrYCvZR R3PUl37TNOVdp519Ha46ySLLnnU+JW40/En2QgD8YmtZ2+8RhLaMi5YGK6O66bTyWKxRqCHR p/ez1Kd4PBPjN74uvW0N6zLnoG1uQ9rKY+Dr1cLVuxcBRB0Nrzr3guSvhu3Q01fROLPOlIXM OzkIo0jmNwZS/vyntbDSTaQ05XZWyJc0mJFjMt3IO7Mfx2CE+OG43QUqKuGPQPzT4yOjOmSr zV2XVHDpgYBMGkthDUKVCcV7C9Sa6la+MEWukbedSD7AmoFRPA3dD/iJcGloriytE7g8OEbt nOLR+5au9D94NsU3ipixqHzIreo8p9jtKxayWfaNAszz/9b2nanEMvXmKsS1SsrVQvojKNi2 9Ndc4RhKP8pLS749Ih1dxs+YeLeVRTRjz5hMtBnNxs0D2tW/7J4+aso2yHp9BMBmnakCGLFs z2hMaeyMqRkAo8i2NxeOhzfCtY1fVoD9oyzFRSZo7Gq6zuQuA3y0unbNcTqqTs5ZFij0+x+n OxMHyr/XkiagqimEm9r5pU3ZdQMoV0Rd07agYPzkxry3ixgszr8ToAhOMjP6ucwmwTn7s1nw GAdK+Vb9HE/6HrlUqDcC+/H7olvrWK4Y5HPObCG4BUct3JvagI1vgb6WJH5IYZ4Bs0MweQ7o p85kG0MwhHdZ20BWfX+9O+T5Gn7n+cvHZNR2wThBxQmxkdPnHhMd1NG20IkRPrcgo+mnHlUv S8wkTYsuebh3OnKVi2dyRgTMnvrETxrNzqWvVNea4yA0fYPfrJLXPZ84LWTci40NrHtaxfUB ItF1Cb2dco2D5Uu/VCPw+F1AfGchXHdOBGf0Qh5YUZYQ1kfUzMlEzUJLmFx8+B+s/rCuultV F84Eq1DZGDA6t0NDy0CHJl9L+SXFJENCZAzxxAUCm2V8iP/RD9z5SxdQhviZToSTgMRizOoe Jj/uMke9FE4VSih/lP1rgAFr9LjW7pf3uWGmq1g8CmhQb2SAGivbFiYkUrNE954dKOW8+Te0 jXzfp2/6ANVfPk+lN1ol97hinqvOB4J2Ua75MUWSFL9P+hSSHMaDY1oYms+0PYC2sempnr0x Ns8A2jQsngzAHHW17/wHyUqKc/cZWuilWRL4z8WzDlz14BGDFL2q/BDNoLtRYEwtaEDkBa9+ zNQgrranCyfKCBf2HaamvnHyAfissrFd/5racy3Pxrn0dL1+LozlWKjQU2Fw/24JTGZuyJFd ouTBHXIbWgP1qilMZvaGuO+BoXPWv236tm6yYdoD+bjk0gAJCk+iJ2cwO8eJUyupZeALULrj bLrOlXoJwxssSaCjMTgL/GfzlD1L28lNK+Le5ZJF/KMNpTUex4a8iPYJ8sF9BdhnRz/y2buh soARn8WVFZ4FSOE0Gj32dROBdqXVgtbvLHsk2vArjsmqUqlcKiQs1/dt96cGe7hQN0CHFPUq pei2eLxZfrrJ4Ndcy15hifgwKBSAJMiXm4IHkbJ7/Rxlpb5ee1tEmtgum8kNRuLqc46gjhE0 OZasP+oVGCKdl+rkN6B5PSDIaq9lEWbZ9N4c8SRwY/Z8hp8e6JEGeO1sOwKRqT9WB4liw1ce DDI9csY0QVPPhB/IyoXhX+bhjV1yGg2f54mLXlzvz3k6yu+9zkPIolxWdb7rG5kWGzNuatmi nP8mURji5LYaCCFFZS4ZsAT1ZHEOk0lGtAiuH2JdZ0QaB8LTdCF68KR3IJU4DD28lxj9+A5N FhQ4nhSq15DG4bXw0gNFQBl5pDooBCab5hUD5kAFauRk69yNu+pMAVXwdyjtc/P+qB3wJ4DC tVCMd0eOqm5Ql82qe2cMdsjstlaZHmWgEIgz1raiqjFRa8kGZ/cJqisLTY3fRC4Wv9jJHow/ at/rl6BSvkzh9uUm77xCdPyC8+j6mYkrLGzvQTJCk2uMj4uLYtpMcJ4UwTHJ6wIDZgYbvgNp BVJFG1pGvyB8AUhBnT+RBlZ8mPlQ2Rv92QnZmNIOO50e0A2JYZ8+RTujAWp8X7DS6BiR9g+4 kfSVS1qjfv/y77jmqoHJNK+rhXjJnrTO9WRFu40syCm+iGEPeXW2VOfjtebyRnlAf1hAQpiK bzF8qeigATg6GW1wQupxZLfvLO5qmApwmMNFDT1TxaJMe7XbHXgO2wprEnD7XeuTeO0Y6STT uw8EfjHFR4Nk0FuXj+DupoqX7c9KrWE7sPXk//9TWIHBpKEQBONWe1DDR3is0KVPt25kFcl3 gDUIt1xY13Qd70BeceARVPxrtFOU35eoBOTvr/wcsBAlxPyNuctHMA6Oq/9SWl8+JUOV6BX0 fZwHUycRKuESZzru5qCWVmG7jc4pKApcdnq94vqG4UcqU3F6CnV7w1ZvomCx/QlNQiFvLVlG i2dGAma1AV21xUFlYzQ60IULp/Bxe4OORvDd38BnSMxFBvMjV6GpLbVKzULc5cPNSx7TIhCI ZVbAhKrSYqu79fRg2FdqDF5t8cCbXc+Fr83njUNN9ERh3R7jn2sZU7GvzOsYmXi1A2XFoS2N wbOG7ZfqNfbGaao8yW0LdEABD0YYtZzp5dc1Cab2pTHZoKHXeZR96oa6tPaC2ZfIL8HZ6ZZI Uml6opVi89nAw1BRjlNuTym0mf1blb++G7qp0lVaod9l3OGU3wA8eHGz6f1Tq6oCUdVsEk59 Mc2gjlFLTNvX8YwuypyCpH/wUyBJXOtCcFD1d53mbXUM7s9x3XNeCa/MOJ3VtUe0L0y/ihli A8MVqIgU9FAqby0E+T40jHgPF3nYHn+eVpDOMjH/5d4kbsKfGtBkx9fFbUZ4HW6JvdfKW+Zh jffWp2gwabmfFf48Lb2lW4PXwkPT5SDS7/G2dFwd8yUvTv+HMokLWfNJ+CwS/xiNWjKZ3ESK qZINDFPA5PrfFhOsCMjuNAw02sFGlW9mIl8I40mB9+L0pamp0iTPZGFUhZ4kPPid1+Ji0gzd RJYToFjiOgmZ+c7nbrKEQ+8BGHbbIyr70gG5yvV6n7WPQutIhZSdjKnE8Y56ijn7FtmB/LmO F57i6wnleRO0N4IdLxC0s/1BBeoPBexcmoc5SS+HRiDIzOqF+n86GRzOsWp74Y/HEUAv/bNI 3CoZcMTk1YkYGs3+3MtaLGQxFLEXmT4H5Iru7eTp4du9voLPWMhvtvaZr+9Wa0KK5fVxmC0m Kl+A9/R71XEWL3b2VVQNdpEh+QDLW8I6ILKr8rr1LK1l3zU9FWUPhJz7Shp3jzQvIVc8ba5b fCiCtCb7cHhIwqyOs7MYOJ6yoU4v6XlCtguR+sKFvySwNnYGqU4C11piy3JJvWaVLREZs6Oy oASQQsyYo3u9Cw2yf3pe9o6359gsMHY832qXgL8N1qT9pZzODnUymlE4945BKwyMY2UoOUSw zTPSX7+CYuw8yE7+efFdxx9GRxIZQP0FPtLqKtMjlwPS2AO8x1ZIofTP1PNI+tPQFIpoTnkO biNG+U7ylM6s4h8VvgXpNfgbSodQuJLxV/wzJs0bpesl2QnWiMj1l2PrZjych7WzKP7fOffu YscdvKKbccNjyYdG8dBUrrcrVx6YLRrMHMFEyfolk7IebHL5ktuqRdD6mreQ5qySGlfN0aMZ FwAAfOuof0aSUlvq4xvzyd85z4psrt19U2JptkxM+40sNA7oMLkrrhBxwgNhEnHXBCEeEsKF G5QT4oF9S7OFJMXwNAKq7RLAdi5jzKK0jc0FMeg0/lzefXuEPUKYMg4scGuFw4o/TB66b5ew /ZE7CZ1SfJdyd3Np3bvXEYu82Ld48zQ6uU6w9P1ENgD7HPpSI9LaGCvnK553j8HhLpTpmfj7 gZ7OsCXeZyZFaG1BbOH5m1/OdNcIf6bgJAKqqTePlj6biFjiGMvnRnzvqWta/I1T/2Qm0Hfr DY5nqKshtcajnPPAEudK5Mr2Ez/GiYbx4Em3MzdMF3i+sbateLFncmc3u/Nh3UjXTAC9YR9b NDUSNiUFbQmPWTZZIvVX/j2DlEevwcJGVea0hEDu1zSp5GjCbI7FLAvqjBCQUHmX5UgugnCq vSgwnIc+pIWHz8U157TZ5EHX58QkXs5qXYwbQB/3EjDkK3HHSHFkOCICY7Lefv1+sed4+fZU 3W9k3j8NWOuWBYrGrhrT6lO9F17kXvurL/U6VEr5ZAxuICZpGWu6XVpwfexiwZpGkGmHWc3J WJ4q8n5JtkQqK3O1C7DXVJ80X5DfqXywnG4aghPMxy3BHMXx9L9CEJqd0UyajEs+HoLYxb8j fusPnopLJrANJzZpoBqsEohMUZAVbSoVe9gS6S9Li7w8lSMIdIUHX2+XdzbLVqvUqC8kFrSI X20ZmxntxkCoTKAqGGVpCo1YrvR0gfsfNquCVm5EaqL5weOyM3rhlBG8QhMt/RJoyceU7OaH VB8BOfpwByOOvB3tdek9dtspOq5BFG7K7bGMxuHt6MTO4ZP/bsby6fKnLPx6mt9HAy4rhsoU MII9JkmQqUzywBhl8TVuk6DPAPoOpAwxMUm8yleaq8UVs3OYA2sSFzephT+/K8SKfNvSlbRX CoRrsjRqRbweCt+M/Wc7seB1muFb8IRy6IrHBd9tsy6evZZUkfdDkr4e6oCU4xRuu8SqeTB7 srzwLv9FwfNVB96hk2dKycFpqs/dFt2F/PpYI7oTl4h8m0RRUPQdkmoKBh4HuKIdMGmQXsUc G7/68JumfqcWLgE2t5dDyZ/JLmR2PIKF+j24kZmwY7hVZIvnL+jF6Wb18xx4gVhSG9jpgrJR vb8TWLPYtszZwqI0YQnSv7CHxIiVXag6KgNS4//3bKo33/fYHpvr6/V20lj1ONB8zuhLdKk6 LMsW8y4aO5hnI7PBAMUpzsbSaXEbbpoAcV8G7FqaS5o5amJH08FYHjBIaekU5Id+STYNa2Pe uRA4Tc7Fjg7aqSA4UCT7CSftlZWha4K9sB3NfVnMzRWEZrLuyrT+YLJB3f7HvEV4OsgfNMIa D542soB1ly7zTjzzQW/DQzqHA6nDreTXW2Ce7Gc+iMlHv3w7Em2XaoTLV6Kf/McjEDvKvg9X qA7zoQKVmW+FXXAczxbR1i90+7BzGMDr+hCd8tH8PGDDSLGbRmoaMoa77hF5xejIxJbO84XF YxSQMYMGKbeu/livgTSNLokDT1bzOwh+JPRo3PSh885DJnZ4k3fOL/3ppK7QONLDcQHVgntZ n2pqskc6rfFgmhoh6uwSwP9jg+XYniY6TIsZxLGsFLvEJuO3YHGBi0h9/G1VmvDCwvt3tVVJ ntXXCqOmVE+hyWYHeJG2FpjUZNXxaDrtjQVO6hPEeQk9d42RX6hJj7jQRjnFdPdm+uzhc0vS SmZszNOdxDDYxMbi6+xxmvptkTAGntQn9IqFo9Vx+D8Rt24JueV6hdfLRkPnolyQH4Qojp37 r0LWbLCV+JfLnPAxr9D3YcmpHFwF3PpClfwnDmqU/54LoKn8rN4e5DhOziUE/GezwlMWoUR5 lFs5bnJIugNNrzMGDmDFsiTwbLhG9qER6Kv2RugC/FZy7PP4C756JW0icgk2QR0dMm58cySI J8YfLZVbu4jeQC5m003QIdQAQvdfvc7BcPFSVKTzOgsuYE+o2CxkPoe1cbQvQP87ipEAXYEP 5R01O1LEiMsYbHyKCgo8AifQAQGqrz23wvjBCsgeswYK7SsrbrzjguRWJ72KpQQ8EAaiRBrc EFj3TcsFzHp005wlEFEwm4wz7F+NTpxr7Pg/dZUrKtneE/r8wwgT67sdiIZZOdNgOnGY3J8B RjNKDUWR8xIKNPto2GXttJBQL2/wyLHn7ExjBTh3VEqwE+zMakjccbQzHA7coCUoXhE6dW6o z+7JWbJ15QgXV05ipkbvTvEAXaLe5/Oez1h/+htNPLgDz7zULO39CPvKdW2NgpYTWbIFQkeT RFgpNccxu1JeB0fKiYJaal/WA1t37V8J/MzqGgd0zg203yT5NDGrLTC/nf3SbiobYE/VoHsu 0zUj+qiX3LEkLQBOqFgKa1IqT/SHS7buije5t4x0irnUqHHI7k+GTgQyq7Vx57QNn2EgaCYd 0LbqxU1GUnwBo12nHoqBDzC+QxREKKe9YxnCRbE85TnmMwoBwU3c27dy9t8vgU54lQ7UfTw+ ElM81gDJ1XVL4Qcp5qWii4xDvgQEHzFK3TnrVfH4FXwabMofrPO1KbdQm7DUKmN2mhGyCtC/ rqbI/tHt+BXFDU0wGJwsXROITBrOUSJTT0Lg31xKWF5zB90BjxUnFNEhBL1lCHlvwGRbhqqF XGq/2KeVwV1WVOfzOrc2KBymkJ0nqguCbN+6S40HU+piGzZvp/Gwh324+Hv+dVKsIZO/oOSF blaaN05eh7lB4D85Yw8UKa5t+JpKfW0nHlwOJlOk3CHBiuKLqMwhw8f6/K9ay6KDsfmbC3LA UoQegXDINA2+25QA98toYPGb8o36Ad3nDKdQgSqaYXpT+VubUSlC/SrcJfo3t8+eEiLqFTSO exK5+j/j87m2jJ7UI0J+JgjRUMmpMzNfGRhciluxvuDgWx3aawN3+OJlk6DgzOjAq8yzeeFd 9AdHy43PWUb6XSInSrkXj6S45eC4GvsLedqmqRPjji8DqBYBvek/fUGJr7SkelA+wZwgVP9J /uDJvqCgQZBgZoabRLrTQzQlC38pgWpsvn7Sw/OH5sKMPVwywHS69lCw9csGc96vZIQfZIgu /GeYCzliSWDx/HxkmteVgVf7bb3wh8fvlRZ8SoBx671jJNUU3ivxeTjPslEY5wSJ2YkaA5rp v9wNTVCxxgLSDASTCRTsdBy+Cs5ID31AmQzvzD+3VgaflZ2YrsIZ4AqT4fJDj3RyVPRPBmUB hHz9DMwxZhDpqcVJMIv2UBpD1xr624xDr6pXdId3PTHG39bjSO92ojuu44hGPevrkLVvDmGm CiKGx9Sj34ryHyPUfTAPjJ9hkk8RmWxXJMAenXakVHLJDboG3JJF6vLKKKqx2NIKGNKfTB6s h0+iZIFfyW2ul2YTAZjSFF5AL0FNH/EabsXMlfxPYSlQ2u4LG1do/ejQimDXoWfybNcDtiKJ Lrwi+77w/ahI8dwUpaQFpbF7c4I29iFtH6GOk7PGe8xRhxXIZw7nscf98goRcWBfES5OkUMe JkAmxXkycLVNQDaxBOJ2ziOVePwWKMTYiQflkgj8M6kiOumV5BOK/xe0L7Pwo2Jqn5m1FAEa QB1Drk3XOkd2kSFf42QSlYyWAl7C1rJWsZdhX1dWIS/DjzeBFq3bzOCClwgzwiXRN+VYIMc2 dcY80QBV4V54eDYZS4A0u8cNnqPL1tLbvREv0nVbTKBe0jwddhL8yXKSauUtA8qA+HX+oFQw rHpyPTvbIICxkYyukP6r7AFxIXHDMjOo5oe0rT+ZCGTd53XMjzkfhMbUX1uUUEAxw3R3PBYp 9tDKzKWA2GCQ+fA0FjHvtQaaIKwYsC/9tX2RECRtg7q4APouvjzUPOXrFCWiu4GmQrMZXcWE BvCt9h7f3WXS//1ELaIhxNUv5Q2AgIT3fid18DimIx3vjMMrD7+wSGF+4wgxS3Su+PYFoABT NWso2i2RGMOUm0P6wVFelkiul3AUWYEsAcZT9YlfsoPZpQIdRrzj9BrkDLCC6NO9V0ED8vqM XAtGq7/YfJIA9Ve3o3FWE9+NYYLd64vDWR5KqLD3xp3pI+wWvNQ9P104aCR+VhICfZY3LCyP veBU3VmzJKQHd+f/TiuCS84RYcr+EVR9pFuwEhJRnhAGK8J2KX0csKdPELMK5y1SgmAWqFQt h9qn1LJo45ZsNGCITbOuJlE/I2y/WaKX1yCfFZg5NDZxpUOvtViO5npKNgYLZ+/Tw5pvkhyo 5oR0rG6doFMZOuMu/4U2nWJ2NOYoFM5DpsvWTYFyGtSU73I7t11TjMgL6MqwqbTe5Ri++bGu ieoWNBDDemwoOYc8Zvm5S1dWzpbCGIDZAELTfGBI287DBbPICp7A7uAehoTBaUkEw+kGPZFI aWZ3qVZIjFRnVILxmpiHqWNklh0PDHi7rt0ZhPGhb3u1re0UKJh6fvg2W8e5bd9PQ2S2QyHA YTKOQ4TWQUF0TyEiD4jmKTdnhiWjLeLrIhECXrFlN/mAIbHBXZ5ysQIFro2kQKo4F2bsVTHU mz8h9tlCrZYrV8cFqdf6Zd1+Xer9RhVvAZO8XhXGoFFe7vH8evygmmT23jHrqSGpk/BaxYyT c3S/QN8konU6SYKoRWNk/bZuvTEEWcc4AFUUHDKm/g6sRhoJJRYtGKcJcNFiDKS86Y8fWYca dZCAHXKv2A+RSx3vmGo4BZ4bv3dBIHK3kbtJ0QY97RWI2cvvDMuneSosON3MPrCCiga4r9JE IRBpPfzEralt58HDoiBr544igCZ129wbHVNDPDubG9ZUN0qG4dCsB5ZLpGU7QYNItY3cgoZK NZKmS8MXWbv00UgZKFrl0yR2l2JwlBRr862yXTrjAPw5QflIwe4eiyVZfKOnvmRhN5RIS5C+ KpnY3n8nCjdUXcpmuWjKIdJfBPD0C/FPR35DbetpAvXzopu1rgrF4IvdSdKJXaf8ZfsTkHVw GaFgIq97T4Lf3PCIF0owQnga6Nyiyzoq9IJGNupFBGl5Zlo4Sudqnlo2Ny92vgSgtwggf6Nm L5bH5G98rxZAIuuvSTrhX3jAydG22wxXkshrbRL3EhryfBInqHinNYd1CqNxmRkU6eWyXcdw tz5TQaZKn2g7eIYuXrhqmDhwP7SFOhSWKd6dTPFg4vpGl6wDHfd1Hw1Dewn5Lktv71v/nEr0 9jYMMHq8MQpct2gZIIyXFNg1ncDjb18pEfWmRpoOkDadDJzc4PM1ViAPFGPatcIqX28k+w1L yIbxoiXMkPReEbBD7YbMTpCiM/6Tg01SeZ4EkFjounck/fgVjkn2XD9WO5Yp+8adwn2fV91T DyquRKXzH7zzW/BThACB8QYfsoV/LX6sjfGYlbei66/xL2ZqHIcJ8mkW0Itf6W9GDous5NVe f//wHqw/jDODL9IwexSFUgcyDg3JzkrNa/Hp4drW/cch5YpVdTFmHrYl1KLNwizS3gHGnP1A lsAEeYJCiYWrAgm/4NHi2wYhFQkGEeNOAQp0yHm0ciAjSZVyVquGGgg+oKbfevpWfUYuhMbF XcL66RMiELNwRPH8QMA+RNatpxn12biOfDwgjWTbjpu6cht2bDCMh8Q9k1x7jimctcjBiRqd URrw3XTbRgNFLTrgrSIYLP+c/bcHNwzOP+gS5yMOS0BRJ013DXyTnw3dNeZYlT43h2xaEE9/ A/xksIgyCv9/U4UnAky5lFB5yt/Ruj6jJ4V31XEnyqXZrhbk2ICZniWRxIw4BvOQ4xh3VkS5 k4kNRuvcmgcLsC9sGrcNhHzv5+E9UV8Un547p8GM0wALn9ebwx0o4bC+r4kw3MGwQPRSwXHB wWz+JY2VnEjNicOrFIndCMDpWd+BNPTAWG4Fl6OsEqahYIhcxJVPlGlWJ6G70v42PZ2XesMY n/6473PhNDpBZ/Dx5SasVsTlUOoUhrUfvT3jyBUaEbSpEabJR6A6hk19QzdHI2T4VKN8EqtV 7FCZIY0PQyDwEKJWdyEt5kmarLKfOnYIruleWP1D3ENfrI0H59vbaloGT290NK1jZec57l4n FAI8jgxhR4q4U/FfxJtoHeUNwMpFp78fRMAgygCPWUhtfN35dh0RSaIcv4WmtAF6KFPUqvxG Z64LxQTDtMh2gdOyXovVzfSi9CVCL9xX+rmPgyTfJ7p6S8iqIxRBfr71p4tivqlewNTABdur bMcu/ajkieVmEHPrAv5xnCqHD23JF8enueTGS+zFdFF1XYIfPE0wGVPCnMq0MqQ9bahNb3pm bvlBB+qZZ0EDDuj9U0pu46pTcREfMZsEo54h1/3ljfbLpdQodgOL8jFdJGqPZI8Xg/tYWT1i JpFIzAjoDLMGlAY+N4jbgsq8vU3MjRoaJdRhDk43wRGjDNevmuRAfiNjCwH5FJ4JDWbxVM1Y 5mMmKYiNOTllBGzvmh9gYIDQ102qB71qPt6lniwCR3rue+FFi4v3ch8Jo8y4PP866Ud8G4Po W8A1fBRJY0uWeV2jr7fhnq4xWuQ+5I8gFIesMDuHGAbJT9TdT9OdaEQEkxPGVOZRFDVWKbqE viHCWSDkGSMmhzIuGcfwiGTara8zWnXHlDxaf7ALEHhTp7Xnvpyo2ok4/yVcvfcm6xAP3fqe 5zDzB66Dspd02sZNrcl38QeaJF7Mmd5oWz2B0Aufl1ubfegDgQDoCed5x87ZCCqJt9OzwfIo X7Y3b4hKX1r818CAXUyGF5mrSjxqZhmwWo8bTFutbLv2i9GWNVGLvYmGE8NdIT0//YtOkOi7 1I2Qq2I7a/r1JbbIAflnLf8r/rSAelhF0TMBSY8qJX35xuGOX/BMWHKo16Nsnioegsx+PaZ/ 2ps4QvhiEm6EdQzQXD9HTAAFeqEiKsTHEBHduJjzxFhVR5k1l+DRLlx0Mbb/uSqaTyAuCOBh rv42W+Ia5M9htNmsv025C8eNlCIPN8AdKTeQGQLoEyr5uYCqR9doIoUpbtM8wnnOL7GD3vCh icd4C8Rw1DnFqI3oKF1VN8mMGQbPLZOW813N2AXowaBGQ4cf6lYJ/dFQrdSWjVjFTeLLnIvR s7Kh/22vzCyCgFmiQwlTJGNAXWjnAKrEm4727TZPnTVb4KYHEz7PHxbzXaqgJHGyyanPg/FB GQ0dxlFWw+n1ZimjORDE7nbxNRB593z95ujIKNVMZVJWKgWXFDgasndhJ0NSsuUqrTg4IV8+ EXh4krrjO/O2LGq4Dhwu6FJv5ezWRfGlXwjs8NnYQ2Mb+wpCB2pmo6X8Gy0hW7AbXbRvHISQ m/eRakEoz6Dn6pcbdAcSegXKtdzXrMjTxi04wGxOozubS5yv8bPuKM34PQB28ArvccpNCXJq 5Y4EPtk0SKohSUZIAo+7EaUjI89OtI8iDUntHe4KbRCEgp6pB+yBziAeO26EEbYVjng1BHPT yi3P0n0LmU6hYOYtGuoRpup6uCZ0svWzYJKbaUQ3eEj3NJ50Sn0ZO9l62NtgI4f+3b77arEf HNmZ+c4GdwuPv75YZC4ybvl/oWG7fhWwo3kfsEmJvH7UTuMQPUOMskTMmDXKagz9VWfhKqaz NgH8D72IBwU/sFDS08buU0H5pOoHdi8aTt0EgMMD7I6kMN+zB9tZCpurx6Yq6LMPfZDDW/Sv 9FMhH7cj6yxRD0FpFBwuat50C9yYKp2vvGUJuwQWSAO0z27tgYJ7yZqsXh1B59ujHGrKIRM5 lcrRAgluWjYc0KWMG+LmeqMvk4H6rSlQ/CeQxiBkgeg8lOQmBAXgWCZoCQ835P78zHL4gZmD ZbBa6uT3pwjON7P1ZIarGy2l8VdqBe3CLOqzxeWe3W1/77V7Hk5ovZCnZjhoxhZkedf8TMKa fGNAHUporBBKfANGqpbGm6WTfzYNYHAJMPg7avF0JvmL0t/F7r07h7OQhxkRKaPtjYzNzFcc +OSrR3eR2NjGIeQsteAoOnce6otz/U0TcUSD0dyGnv6fL70QChWPb9c6zwBBV3AgNF6tGpFk /ZJdR+yjbLq+RIi+dLiEOswIq4GABeyRG/jJvxUbFzKj/DXktSM4JhMiYoWN8ZvS2mxaQRJg QiRO4UGpD6heegeLei44VB2AJuKPbt6mHafH7yGnk+44o2eSwwG/eASakqj6zTHjExrFbJyV k4mJUxLaUV7QJytDsB407ubKOWW/YAgmbqiBlELcLp89hVDxIjbQ30C9eaDb53IazUsiJ3J7 9sC44sX3inH3OaCMLo8vpfm9CqeU5oVGRZQRE+FS86UV93KqVznGs5euKeHFBtlMKJczGI6u F45IxIjQODYJ+uekcEe97ifHDJdvUM7hauVEpo9SBGvtw4fbHh71Q7r6ywWqcE5u04ZYhhY/ MgUYQnV2f5aKanpP3r+I/Ll6+qHCFaGJhREZksAhwjsez4mtwqgWi3LiyuIS4UmQKrYlxiuD Qp7mY/2IRjfLiZxDL6kVwYbsLle/UttAAbhyNU93kzQqhDZLCxhg/DYS/CGXCAwpYzHSI5Rk PWJvcBRafs16LLiKN6lFCuMKq2vXjKkWNc9eQYMDfMX+Xvq+xsQ+bymCCbyyr1f7DAnSjzNH Sr8723xOapIWaHW4F5dluhVrAEHhduTXUxFIU76wpCqLkLdu5igjrgLV1Z4lVxwM4DF3XCu/ dZZZL2CUPGZeqhhN8nDm2RXt61iWNbUOxvFj7/QpvpYnuEuagYBP94vHOv0VGC/5Y5gkXtqU J71IXW6WqC2Fw6TFzKgVZ+17+f03/r31dNTPHlf8FctPNbMGA3h4EmIl2grLWEwgVKBktEKm B3I/P7FCgg88iBGTawFUtVyS+gYiqyrgsnSDxqc1WB+FPvJeyTKi5JNzegdiroNAMT6VmvIx AH7NOdcaZ6homGo6LETMXnaSb2Af/poy6BY5au1daRO1Yi4dxbBI08ycTlR5tXoHOqArv/Ob Lv+wQKevIIV62f6tLH7m+FubXLtn3r5Qe/XR2PQPjYvQ3w8wLzfJm2Pqqx8JOT/RcUPcy/Tl J70QDScMprLqcnXDQOAxVZuJOTLuO+Y2uFayOrdlwjO6SvzEMnxhr8lPlqQNho0jETHaGkaz OQk8RBMEgNBwFWU87vB+04u80rS7ru0oRtslTzwpxG+YX9gujLXyzUfwop5F5PM8m24PadyQ 2HzYcg5Ce5Yit19dqyi0UHMmY3LtfdjWvsci+A3miSI9k+a/OWHOgdg8UydJgCnA4R1GLoGl F5X9uKtf3GwxXSxICwZene0JkW9g4FoKaRttGJcVHA96cJ6dxCAvhtFQdddbKySV9sf1RmKv y/jj/8NX3NmSLQPwD6ITIHBVmuqXvOjkEuPnWtASouwFnnW1jFfA+VmpSEjwD4zT5mVD3Brm OhsMHP1cSM06DwnpkEXvgrtuuLzrMDkeetKcT5WedsuwNhZWbHmqpjip73CtRexcKGBRYPAP 5vawjBDeOHiGnP9Fuk1J+sYmjnZgH7OKYPJoKl51CYg0szLX0erFPpKShqpnTgW9Wt1pqYw+ tmPSL5CbTntTqqgXIb4KyjUxV4tAkozbbX3QmFUNgquEeJAXzGPW+4mKvRFiN5m9P+OfEyT6 eFWUHtpNXDegfD+oEz6IwII4s8AQ+n22L72+X1vCGdpxwT0cyZbo3uEds25AIMqHXaLyQkqH CMqlgK1FffOpfTXOCnrImUqPVgUb2VX62KOOiW9uAXUSXk3Hpzid+LRr1DZ5asv6CScjOlgK raRb3c/syz88Yyfx2Y6PqquhjFUnrQXXnKL1baVEbMnHja1a+BEoPKst0J3Fb7UV08AVgTZm RIwF603OfWASTiUmYXmn1rTPtF+/pHaZnpM/3N0bT4JB3koxbKUGRcK7+7Daqnc4sfZqDGiY Rk+ZxeMHM7QyRz+Z5cf+Yool1Qcxl/eowk4Tf1OTi1cNKMhrkhnFIpSwB/OntYCRebQGuF6A aKC3dLxszwDDvAi7xK5sJso9WprsNsy1yaJUsmvmC7uLpImTI2HAhOEYeknKsOt4Cz6RO3Nr o+NiZar6EfO41IQcVYu+P6MNqDNajUWwHuXOoR3J3o5oOesp0qoVj4l+CDIf5eOFI8XvBjNO WAE7OiKbY4QzmxfANFATIRsggJuRnuMsyd7l+WgwKGESx8YwN34O8QetXaRpEfxBvIiy8M6t P4uf+FqBP1nAFZvW2md6qu3VHMfIAKwdxErzT13WnrFMHoqVTLF1TI0GTxVg1ual/g1eufYU Ys1wRYRkEXERJ+xe01pVG1n3cLu9H3MI9+mqG9CeGqEbQSluYVnHxC7a7/fu0dk1+Bgud+4M UliBjh7TMtH3S8Ix/sxrz6KFx6LJD4nFpxVJHwS0gL4fMJnumb2zA61Kx68gYDO7eeszSCdz E0Sek7brbUIcDej+UxgPeVfx7XLGxoK4yv30WibwMFrqWMEUoE17TRJG6fZtoB/REHC7qodw OYxdPb2lAzhu4dwHLGLEmAHHTH478ujdvgo93BnUBUOboLJVGRj+1IH+w0v08BEx2X7P8V+w sqeLt3egOowP58mh6JWS1arbVdb576yfFh2rGNNfD1hPWUKXgtZCb6dnR8X/dxft9tQExfgT QFlOHY5d+076HfnI2lXujCdiLznyii1A2DyiG+WGwLAgBf8RagOQjdnc6VLgzs8lsHeWYTz6 cEwV9X6dr8stATF6qk642etGr+EaT1BXzzGvZKacBVRlYBLEPG0MlRbf7LqPJWW5nSM6MJlN 9Vi0qW9OLW6LX/IAeUQb5uCkRFBQsMkqO+F5sA1Daw1sg03X09kCKKUUyK1d0n5N5ntCdT9g iKH2jJDRXuU1qXZGgtuscigSNvR9yrZ3jawci8czDGJ5+FDVvmEznllKh4CWgecS8iqsHVfs x6Y5co6eSxoLq1/3TlS7El/68oZkuhofLdjtOKLYhJH0r4t6HHkLCiB7ZD0gkC/vWHkiHu6L i24SCPDULYmBLHCpbeH//qXWfxrXxlI7DaPMFth2NpynNwTE8TUXQblRJXJc2C8LnEaiVhh5 Vj7DMBBG9l/x2FlFyGuMHgmJJklJ4pYMMCA8a2D87cecI3YGb40yRswdG4f7RJHqaEX95MZX +Z1Z7qEP2b6AGTwXn4D8Eo5GilZXWMhc6rtV0D6mtpwkqi0mQ4u46klCkSghSEnX1mwwA7eT NThucK5lM4kplBL5Sr+5faGhIqbuPpHUGdU6b4ntPzG82smfzX+Yby+8Tx9q5Ur6W982+4ht obsgs4k5zPA/991krmi1GCAKqdcQNRbrHn2LSOx5UwP7RMGq36oGk9WFW2nj4xRlp+zlvQXw lbKepx4Lu2Vn9eEXkP99HsNSqcxkJUchviENN47xEaGRJJzuVesIf4vMpVrRlj2auzFHz0Pz z9YvuM0a/hGN+h/iRgGEpC5OPqOi5lPLBPkdGLHAPsVid8mP5gjf79tg6Z5+8y/Tp3I2HXgL D2QRr+rTBrop+CLr+FusrxAxiXGLa8oUKMcppEkNd6B7wRcEYhCbzPe7NPsS7sQAMnFH2jNX kIXfNyySuh6bAAEu0mzoXsurVN4nzZrvi0Im8xh/ZxxZRGg74POhlkXIfaSk0hQ7czYk47qO DDu+1vj0j2WPQWVY00y57nC+kY9L/4TIe2SbnLBMCTKfb7vytvjwL8Cu/FAvUODEs/6dE01s H7KEM5VKueykBHJmCSsnSDHAQO2IV+k8djqb/XFpQ1GJhgsGAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAACAAMAAAAgAACADgAAAJAAAIAAAAAAAAAAAAAAAAAAAAIAAQAAAEAAAIACAAAAaAAAgAAA AAAAAAAAAAAAAAAAAQAAAAAAWAAAANAQAQAwAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEA AAAAAIAAAAAAEgEA6AIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAEAAACoAACAAAAAAAAA AAAAAAAAAAABAAAAAADAAAAA6BQBACIAAAAAAAAAAAAAACgAAAAgAAAAQAAAAAEAAQAAAAAA AAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAA////AAAAAAB//4AAf+GgAH//sAAAADAAIADX8A/+ Z5QIAo/2C/q/9gv6v/YL+r/2C/q/9gv6v/YL+r/2CAK/9g/+v/YH/z/2AAB/9gAAAAYAAf/y AAH/9AAB//YAAAAGAAH/8gAB//QAAf/2AAH/9gAB//YAAAAGAAD/+gAAf/wAAAAAgAA9/wAA GAMAAA39AAAH/gAAAAWAAAADwAAAAeAAAADgAAAA4AAAAOAAAADgAAAA4AAAAOAAAADgAAAA 4AAAAPAAAAD4AAAA//wAAP/8AAD//AAA//wAAP/8AAD//AAA//wAAP/8AAD//AAA//wAAP/8 AAD//gAA//8AAP//gAEoAAAAIAAAAEAAAAABAAQAAAAAAIACAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAvwAAvwAAAL+/AL8AAAC/AL8Av78AAMDAwACAgIAAAAD/AAD/AAAA//8A/wAAAP8A /wD//wAA////AAAAAAAAAAAAAAAAAAAAAAAIiIiIiIiIiIcAAAAAAAAAD3d3d3eAAAh4gAAA AAAAAA93d3d3d3d3eIgAAAAAAAAP//////////eIAAAAAAAAAHAAAAAAAACPiAd3d3eAAAAA iIiIiIiICPgHd3mXiAAAAP//////eIAAd3d3d4iAAADwzMzMzHiAd3d3d3eIgAAA8MzMzMx4 gHd3d3d3iIAAAPDMzMzMeIB3d3d3d4iAAADwzMzMzHiAd3d3d3eIgAAA8MzMzMx4gHd3d3d3 iIAAAPDMzMzMeIB3d3d3d4iAAADwAAAAAHiAd3d3d3eIgAAA///////4gHd3d3d3iIAAAAd3 d3d3d4B3d3d3d4iAAAAAAAAAAAAP//////94gAAAAAAAAAAIiIiIiIiIB4AAAAAAAAAAB3d3 d3d3d4BwAAAAAAAAAAd3d3d3d3eIAAAAAAAAAAAP////////eIAAAAAAAAAACIiIiIiIiAeA AAAAAAAAAAd3d3d3d3eAcAAAAAAAAAAHd3d3d3d3iAAAAAAAAAAAB3d3d3d3d4iAAAAAAAAA AAd3d3d3d3eIgAAAAAAAAAAHd3d3d3d3iIAAAAAAAAAAD////////4iAAAAAAAAAAAB3d3d3 d3d4gAAAAAAAAAAAB3d3d3d3d4AAAAAAAAAAAAAAAAAAAAAAgAA9/wAAGAMAAA39AAAH/gAA AAWAAAADwAAAAeAAAADgAAAA4AAAAOAAAADgAAAA4AAAAOAAAADgAAAA4AAAAPAAAAD4AAAA //wAAP/8AAD//AAA//wAAP/8AAD//AAA//wAAP/8AAD//AAA//wAAP/8AAD//gAA//8AAP// gAEAAAEAAgAgIAIAAQABADABAAABACAgEAABAAQA6AIAAAIAa2Elf68sQKNQdQoJRRucEQV0 f0HAKyV3tHwlDUCpIDZHpqBSSKZzYGDGA8C6U2bEs0WIOixCb1dAVifAxLhaZL7DBB5vQsVY g7JjoJSZNEfDNQNMWJkrt75iXR4cfWqQlEzHBieemiAQVhgGvEyysGsLEyx1kwigbb+BOb0K hoZEZ8F7xAnCLXs3D8cfkXexCFhZpHMolANxZMO3xWpflXOuMqxuiVtMpHgbullqskEhIoV0 OLOpeyM/NF4/iq/EX70vFWQRu2XAFYPCRJ58oJ8AWThoP5KfMBO0OFVOGgg0NVESTku6escA cBujmL9uAY9tFhGRdLNBDatwN56mL0lHPLyPWZ+seQJHQjzBUFwPFqCAiyBUUI3AhlI3ObFo VptuIrvBkW8fTBtJiCicC2TEGqYHUBS5RwVgpjdubGI6Eq2KXEiRGpKtbro6ZzRiwCFqBpUE Oi6+BsSOd2tKS8WwBZ6Eo4AiFZSrebcxQHJHYw/GU0RkLLAyWaYAVjYJmJW0Iqk8HFCYnqyt osGblZylt6d2Ww27K2KVq46QXwUNO1SzOWuQh7FBwg6DapoTawY4E5grHW+XDD9FThprXG4g e1oqA40BSiEfYXoNmkYYx2CJTTKSUcacIJUjhUIeDsVziZ3FMmmhgMIxN750rjB9tLarvYC+ FQGxUX93EWuHVV+qHl9DaWB5b0+MqD+FoacBXWtbZ54BdYNvolpCiX8hcndMNZtWUVZ5q1CB WUy5b0JXk4ymiDi0LT4kB7tAUbInvWe4KKA3xlVYQm6TPbiUZTyOSrJjMai3iolRFKCDPpdB bJURRWKKrq22AT5KPEcuuYe1pTW0o353jrNGGTMdk21Qpo+3IllOkgGPeR2fSzZzoWt3H8CT raMVFWu6OBqOo8YFLWIXiAFnu4VNp0CgYrMsLsRgpQqGCCKxqGQABT+RH7xuKKhEP3leE5U7 AoCkuceVeYh9jYqpgUual7N4NzWLwWFAcrJlNqlnFQMmuTYUHne0RSIjHYuVvyAygn9PoUov fTIrPUKGk40tGVCKui6HCh4qxVelvBg6JCceu20XsYdRbFIOGKw4jCRPSgHCbGQhWBs6xxeo sD1BVmA+ike0vhOyXimfnAuiSzEIu359Z5WNHAStv2h2JVNYu3irDQVmnRhXLak0FXlukXBz MF9vSoxKoXOxAjVNd0UBgSEmp3FNKQYiRAW5uJlpNQUnYVNMAhnDIwIwSn5Gtk8/nwupEYM0 ine4i1yuU8WPU8RUqa8IpnItAwGntGBsAGEGTGmiIWxwc6WaFaIsEYOuH1lslAcLQ6IiAwZb GTm5CSk3PTJAVmCKqYCPTS1WCW5FGCB5DGmNZj+rnqGVpl+3ljFxh0VeAAhLeHdiojgJfDdN PLACEadargJNkxpkIQMiI38YPkJHMkmlZDqIbAI1k3VpknuTcjCnqnA7TzSNOghHoU4UpmZZ SEuCLKyUZol3WUYSVXpcBp9/ZKDGkQKKBlo9C1W6FzdfLIvDkAw+EqAPL4ajxJpfs2mpposc KSatakNYqI9ptVAnmWi9QE2QTMd5ucc2W5WucIoteU95nUsJB4ONVqEDUwpWEG/FtKJYE6QS AQckagiGdBUeA5VdWKhmcC5akKFJUo0fsh0xfSGHKyKOwz0FOopnqBMlRTUIHqCdWDuSw4mf D2N9bsdZolENuaC4tMARQb8QaYxEKi14uJEnfQKYS3xdG5hzunCQSHewn6yUcF8moJGsBa5H GCqkbiMvV7MFJDRIfjIIOD8BAEIJtjx0EZxTvqcxNZm7TVMktA50gaCHPJGxLme5ECZRRZJD mDkXYHknaRMPaL+5cT6MKpGcWCQ= ----------ootflkcqbokkaldhbhar Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple ----------ootflkcqbokkaldhbhar-- From simple-bounces@ietf.org Mon Jul 19 14:47: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 OAA15378 for ; Mon, 19 Jul 2004 14:47: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 1BmdAo-0007XQ-8k for simple-archive@ietf.org; Mon, 19 Jul 2004 14:47:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bmd9s-0007EW-00 for simple-archive@ietf.org; Mon, 19 Jul 2004 14:46:41 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bmd99-0006tG-00; Mon, 19 Jul 2004 14:45:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bmd2H-0007bL-T2; Mon, 19 Jul 2004 14:38:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BmcwA-0006bt-GF for simple@megatron.ietf.org; Mon, 19 Jul 2004 14:32: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 OAA14017 for ; Mon, 19 Jul 2004 14:32: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 1Bmcw9-0002rI-Eq for simple@ietf.org; Mon, 19 Jul 2004 14:32:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BmcvD-0002aJ-00 for simple@ietf.org; Mon, 19 Jul 2004 14:31:32 -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 1Bmcuj-0002It-00 for simple@ietf.org; Mon, 19 Jul 2004 14:31:01 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 19 Jul 2004 11:32:25 -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 i6JIUR8a021706; Mon, 19 Jul 2004 11:30:28 -0700 (PDT) Received: from cisco.com ([161.44.79.221]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKF42951; Mon, 19 Jul 2004 14:30:26 -0400 (EDT) Message-ID: <40FC1342.2090101@cisco.com> Date: Mon, 19 Jul 2004 14:30: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: Suggested RTT text (was RE: [Simple] RE: [Sipping] RE: text/T140 andaudio/t140) References: <35A7ABB2-D8CE-11D8-93B7-000D93B0AE1A@nostrum.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: "Drage, Keith \(Keith\)" , 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 I agree with both Eric and Ben. I agree with Eric for now. If/when there is a more suitable document, then put the statement there too. Compared to the cost (420 pages of discussion?) incurred so far, putting these few words into MSRP is cheap. Paul Ben Campbell wrote: > I think that sort of statement belongs in the (apparently now dormant) > SIMPLE architecture document, not in MSRP. > > On Jul 18, 2004, at 1:32 AM, Eric Burger wrote: > >> After 420 pages of "discussion", may I humbly propose the following >> text for >> the MSRP document: >> >> User interfaces and user communities for instant messaging and real-time >> text telephony are extremely similar. MSRP is not an ideal protocol >> for the >> negotiation and transport of real-time text. However, devices that >> implement MRSP SHOULD implement real-time text telephony, using >> standard SIP >> (RFC3261) and text/t140 (RFC2793bis) mechanisms. >> >> >> >> Rationale: >> 1. It looks like consensus to putting RTP under MSRP is far, far, away, >> assuming it even makes sense, which it probably doesn't. >> >> 2. A whole bunch (80%?) of the code for an IM device would be shared >> with a >> RTT device - character input, character display, Internet >> connectivity, SIP >> stack, etc. >> >> 3. We have a charter obligation to make protocols amenable to building >> devices that are accessible to everyone. >> >> This is an opportunity to meet the objections to trying to shoehorn >> RTT into >> MSRP (#1) with our Charter obligations (#3) without an undue burden on >> the >> implementer (#2). >> >>> -----Original Message----- >>> From: Drage, Keith (Keith) [mailto:drage@lucent.com] >>> Sent: Monday, July 05, 2004 5:54 AM >>> To: simple@ietf.org >>> Subject: RE: [Simple] RE: [Sipping] RE: text/T140 andaudio/t140 >>> was:[avt]C omments/questions on draft-ietf-av >>> >>> >>> Given the length of time this discussion has been going on, >>> and the number of messages exchanged, is it not about time we >>> reached some conclusions. These lists are to advance the >>> deliverables in the working groups concerned, so how do any >>> conclusions affect those deliverables. >>> >>> SIMPLE has a charter to produce instant messaging protocols. >>> I do not see in all the discussion of the advantages of >>> instant messaging versus real-time text removing that charter >>> item. Therefore I suggest we STOP that discussion, or the >>> proponents move it elsewhere. >>> >>> SIMPLE does not have a charter item to produce real-time text >>> protocols. There is already an existing capability in IETF >>> for real-time text protocols. It is not really up to SIMPLE >>> to discuss whether that works well or not, as it was not >>> developed under SIMPLEs charter. >>> >>> How terminals mix and match applications is not something >>> that IETF traditionally deals with. Therefore I would suggest >>> that any requirements that state RTT and IM must be >>> implemented in the same terminal are out of scope of IETF. >>> They should certainly be in some device specification rather >>> than in the MSRP specification which SIMPLE is specifically >>> delivering. >>> >>> I guess the questions as affecting MSRP really fall down to these: >>> >>> - Are there capabilities in MSRP that would lead to a >>> valid RTT protocol that works better than the existing IETF >>> solution, in addition to it fulfilling the requirements to >>> provide an IM protocol. From the exchange of messages I have >>> seem so far, it seems to me that the conclusion should be NO. >>> >>> - In order to deal with a body of users that have IM, and >>> prefer to use IM, and a body of users that have RTT, and >>> prefer to use RTT, is there a need to be able to interwork >>> the two protocols at some intermediate point, and not just >>> within the terminal by supporting both protocols under a >>> common user interface? I see that as an element of the >>> discussion just raised by Paul. Does such interworking, if >>> required, have any impact on the contents of MSRP? >>> >>> regards >>> >>> Keith >>> >>> Keith Drage >>> Lucent Technologies >>> drage@lucent.com >>> tel: +44 1793 776249 >>> >>> >>>> -----Original Message----- >>>> From: Arnoud van Wijk [mailto:a.vwijk@viataal.nl] >>>> Sent: 04 July 2004 10:43 >>>> To: hisham.khartabil@nokia.com; paulej@packetizer.com; >>>> pkyzivat@cisco.com; Guido.Gybels@rnid.org.uk >>>> Cc: fluffy@cisco.com; simple@ietf.org; gv@trace.wisc.edu; >>>> toip@snowshore.com; gunnar.hellstrom@omnitor.se; smundra@telogy.com >>>> Subject: RE: [Simple] RE: [Sipping] RE: text/T140 andaudio/t140 >>>> was:[avt]Comments/questions on draft-ietf-av >>>> >>>> >>>> Never say never. >>>> Have you tried interactive text/real-time text? >>>> Did you? >>>> >>>> First try it and THEN you can say if you like it or not. >>>> >>>> If you want to determine how useful it is. Test it. >>>> Use it >>>> Try it >>>> Compare it with IM. >>>> See the differences between IM and RTT/Interactive text. >>>> See that both text communication methods have their advantages and >>>> disadvantages. >>>> And use both for the best situations. >>>> >>>> And if you still don't want to use RTT/Interactive >>>> text..fine..I just hope >>>> that when I call you, that you can still receive my call. >>>> Just use it only >>>> when the other person uses Interactive text/RTT. >>>> Even if it is then 3-4 times per year. >>>> >>>> Can you with IM: >>>> * directly call the other? >>>> * forward the call? >>>> * put on hold? >>>> * have the call go to multiple terminals? >>>> * not being logged on a buddy list server, where you may get >>>> flooded by 20 >>>> users at the same time saying hi! And such? >>>> * being able to leave a message on an answering machine? >>>> * using a service that allows a ring notifivation as soon the >>>> other user is >>>> ready with his/her other phonecall? (ring back on busy). >>>> >>>> There are more.. but I am unfamiliar with voice calls. I am >>>> just enjoying my >>>> freedom of communications beyond the IM limitations. >>>> >>>> And I enjoy using IM also..even though I am forced to use >>>> Trillian, since >>>> there is NO one universal standard for IM right now! >>>> >>>> Interactive text is! >>>> >>>> Greetz >>>> >>>> Arnoud >>>> >>>> >>> >>> _______________________________________________ >>> Simple mailing 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 Jul 19 19:23:50 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04251; Mon, 19 Jul 2004 19:23:50 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BmhUA-0003yX-HL; Mon, 19 Jul 2004 19:23:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BmfgG-0000O4-OV; Mon, 19 Jul 2004 17:28:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BmeLm-0004Dm-N5; Mon, 19 Jul 2004 16:03:02 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19785; Mon, 19 Jul 2004 16:03:00 -0400 (EDT) Message-Id: <200407192003.QAA19785@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, 19 Jul 2004 16:03:00 -0400 Cc: simple@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-xcap-list-usage-03.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-Score: 0.4 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : Extensible Markup Language (XML) Formats for Representing Resource Lists Author(s) : J. Rosenberg Filename : draft-ietf-simple-xcap-list-usage-03.txt Pages : 33 Date : 2004-7-19 In multimedia communications, presence and instant messaging systems, there is a need to define Uniform Resource Identifiers (URIs) that represent services which are associated with a group of users. One example is a presence list service. If a user sends a Session Initiation Protocol (SIP) SUBSCRIBE message to the URI representing the presence list service, the server will obtain the presence of the users in the associated group, and provide it to the sender. To facilitate definition of these services, this specification defines two Extensible Markup Language (XML) documents. One document contains service URIs, along with their service definition and a reference to the associated group of users. The second document contains the user lists which are referenced from the first. Both documents can created and managed with the XML Configuration Access Protocol (XCAP). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-list-usage-03.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-list-usage-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-xcap-list-usage-03.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-7-19152843.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-xcap-list-usage-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-xcap-list-usage-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-7-19152843.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 Jul 19 19:45:52 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09324; Mon, 19 Jul 2004 19:45:52 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BmhpU-0005Sq-7a; Mon, 19 Jul 2004 19:45:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BmhM7-00082R-Cj; Mon, 19 Jul 2004 19:15:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bmetw-0007MF-08 for simple@megatron.ietf.org; Mon, 19 Jul 2004 16:38:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26543 for ; Mon, 19 Jul 2004 16:38:17 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bmequ-0001qU-Io for simple@ietf.org; Mon, 19 Jul 2004 16:35:14 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by mx2.foretec.com with esmtp (Exim 4.24) id 1BmeF3-0004i8-6j for simple@ietf.org; Mon, 19 Jul 2004 15:56:05 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 19 Jul 2004 12:58:21 +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 i6JJtVIV010286; Mon, 19 Jul 2004 12:55:31 -0700 (PDT) Received: from cisco.com ([161.44.79.221]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKF52590; Mon, 19 Jul 2004 15:55:29 -0400 (EDT) Message-ID: <40FC2731.3080801@cisco.com> Date: Mon, 19 Jul 2004 15:55:29 -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] Address and person URIs References: <40F97472.7030006@cs.columbia.edu> <40FBCF13.8010308@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 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-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > Henning Schulzrinne wrote: > >> The basic problem with a "human" URI is that there does not appear to >> be a unique, universally accepted identifier for humans except one >> that each human picks randomly from a very large space. References to >> the 'mark of the beast' are left to other discussion venues. (Even >> then, I suspect that lots of Chinese will randomly pick human:888888 >> [http://www.travelchinaguide.com/intro/social_customs/lucky_number.htm]) > > I don't think we want to label a human, per se. What we really want for > person to person communications is a place - i.e., "room 527". Well, a place isn't always sufficient. We see this all the time in the movies: "Meet me in the bar of tha Acme Hotel at 7pm on April 1, 2005. I'll have a red carnation in my lapel." So we don't need a *globally* unique person identifier. We need a person identifier that is locally unique in the context of the time and location of the intended meeting. And the time is important too. The time we can deal with. With regular status it is NOW. We can use timed-status to cover some other time. I don't think location has to be part of the Contact, as long as it is provided as part of the (timed-)status along with the contact. Coming up with URIs for identifying people locally within a particular time-space region sounds like future research. Sounds like some sort of arbitary predicate would do the trick. >> For human-to-human communication, it is also more often than not >> unnecessary to know which precise DNA instantiation will be meeting >> me. Indeed, for privacy reasons, such unique identification is >> undesirable. Thus, unique identifiers are the wrong model for >> identifying human-to-human interaction. While, therefore, a human is a >> resource, an identifier is unnecessary and undesirable, making a URI >> scheme dubious at best. > > > Actually I suspect that, if you think of it in terms of "go here to talk > to me", then the same postal URI structure would probably work, but just > a different scheme. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jul 19 19:59:12 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11812; Mon, 19 Jul 2004 19:59:12 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bmi2N-00065I-Lj; Mon, 19 Jul 2004 19:59:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bmhcx-0000DL-Qq; Mon, 19 Jul 2004 19:32:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BmfwW-0006Gw-8Y for simple@megatron.ietf.org; Mon, 19 Jul 2004 17:45:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13434 for ; Mon, 19 Jul 2004 17:45:01 -0400 (EDT) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BmfwU-00071P-Ru for simple@ietf.org; Mon, 19 Jul 2004 17:45:05 -0400 Received: from panther.cs.columbia.edu (IDENT:SZ/GFBzF2v+T6vXys5QIXPsn5en+W56b@panther.cs.columbia.edu [128.59.16.122]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i6JLivfq022245 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Mon, 19 Jul 2004 17:44:57 -0400 (EDT) Received: from [128.59.16.206] (chairpc.cs.columbia.edu [128.59.16.206]) by panther.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id i6JLivHr010356; Mon, 19 Jul 2004 17:44:57 -0400 Message-ID: <40FC40D8.3090103@cs.columbia.edu> Date: Mon, 19 Jul 2004 17:44:56 -0400 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Simple] Address and person URIs References: <40F97472.7030006@cs.columbia.edu> <40FBCF13.8010308@dynamicsoft.com> <40FC2731.3080801@cisco.com> In-Reply-To: <40FC2731.3080801@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 4.6.1.106153, Antispam-Core: 4.6.1.104326, Antispam-Data: 2004.7.19.107869 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, QUOTED_EMAIL_TEXT 0, __MIME_TEXT_ONLY 0, REFERENCES 0.000, IN_REP_TO 0, USER_AGENT 0.000' X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f 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-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit >> I don't think we want to label a human, per se. What we really want >> for person to person communications is a place - i.e., "room 527". > > > Well, a place isn't always sufficient. We see this all the time in the > movies: "Meet me in the bar of tha Acme Hotel at 7pm on April 1, 2005. > I'll have a red carnation in my lapel." I suspect that one of the desirable properties would be that the person doesn't change identifiers just because they changed location. If you don't do that, it will get very confusing - is this URI the same person at a different location or a completely different person? (Imagine a friend finder service that works in physical space.) There is also the issue that you now have two ways to represent "location of a presentity", as a URI or as PIDF-LO, with contact information also available as a vCard. > > So we don't need a *globally* unique person identifier. We need a person > identifier that is locally unique in the context of the time and > location of the intended meeting. And the time is important too. > > The time we can deal with. With regular status it is NOW. We can use > timed-status to cover some other time. > > I don't think location has to be part of the Contact, as long as it is > provided as part of the (timed-)status along with the contact. > > Coming up with URIs for identifying people locally within a particular > time-space region sounds like future research. Sounds like some sort of > arbitary predicate would do the trick. > Do you want to define people by a game of twenty questions? Henning _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jul 19 20:15:11 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14235; Mon, 19 Jul 2004 20:15:11 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BmiHp-0006ge-Ol; Mon, 19 Jul 2004 20:15:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bmi7P-0003ZY-Ld; Mon, 19 Jul 2004 20:04:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BmhmP-0002QQ-0I for simple@megatron.ietf.org; Mon, 19 Jul 2004 19:42:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08312 for ; Mon, 19 Jul 2004 19:42:42 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BmhmP-00054h-5l for simple@ietf.org; Mon, 19 Jul 2004 19:42:46 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-5.cisco.com with ESMTP; 19 Jul 2004 16:44:39 -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 i6JNg9IV001496; Mon, 19 Jul 2004 16:42:09 -0700 (PDT) Received: from cisco.com ([161.44.79.221]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKF69935; Mon, 19 Jul 2004 19:42:08 -0400 (EDT) Message-ID: <40FC5C50.2080708@cisco.com> Date: Mon, 19 Jul 2004 19:42: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: Henning Schulzrinne Subject: Re: [Simple] Address and person URIs References: <40F97472.7030006@cs.columbia.edu> <40FBCF13.8010308@dynamicsoft.com> <40FC2731.3080801@cisco.com> <40FC40D8.3090103@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 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-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: >> >> Well, a place isn't always sufficient. We see this all the time in the >> movies: "Meet me in the bar of tha Acme Hotel at 7pm on April 1, 2005. >> I'll have a red carnation in my lapel." > > I suspect that one of the desirable properties would be that the person > doesn't change identifiers just because they changed location. If you > don't do that, it will get very confusing - is this URI the same person > at a different location or a completely different person? (Imagine a > friend finder service that works in physical space.) > > There is also the issue that you now have two ways to represent > "location of a presentity", as a URI or as PIDF-LO, with contact > information also available as a vCard. > >> So we don't need a *globally* unique person identifier. We need a >> person identifier that is locally unique in the context of the time >> and location of the intended meeting. And the time is important too. >> >> The time we can deal with. With regular status it is NOW. We can use >> timed-status to cover some other time. >> >> I don't think location has to be part of the Contact, as long as it is >> provided as part of the (timed-)status along with the contact. >> >> Coming up with URIs for identifying people locally within a particular >> time-space region sounds like future research. Sounds like some sort >> of arbitary predicate would do the trick. > > Do you want to define people by a game of twenty questions? Well, it would be easier if everyone just agreed to have a barcode branded on their forehead and an RFID chip embedded in them, each containing their UN assigned global person UUID. But I sense a lot of people don't want to be so easily or irrevokably identifiable. So weak forms of identification may be all that is generally acceptable. (Hence "I'll have a red carnation in my lapel" rather than "The SSN on my forehead will be 123-56-7890.") Unfortunately, this doesn't lend itself well to URIs or URNs, because the information isn't Unique. I think we continue to punt this one for now. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jul 19 20:28:11 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15248; Mon, 19 Jul 2004 20:28:11 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BmiUP-0006tU-VA; Mon, 19 Jul 2004 20:28:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BmiHM-0003uQ-Qj; Mon, 19 Jul 2004 20:14:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bmi5R-0002H6-MT for simple@megatron.ietf.org; Mon, 19 Jul 2004 20:02:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12410 for ; Mon, 19 Jul 2004 20:02:23 -0400 (EDT) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bmi5S-0006EE-Gv for simple@ietf.org; Mon, 19 Jul 2004 20:02:27 -0400 Received: from razor.cs.columbia.edu (IDENT:QwUoONXjJpmztWH+6Bt+4hg9XNI2z5mp@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i6K01xfq013344 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Mon, 19 Jul 2004 20:01:59 -0400 (EDT) Received: from [127.0.0.1] (IDENT:owIdftZmCxfqa40uffLujWENCe368E5z@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i6K01wjd014441; Mon, 19 Jul 2004 20:01:59 -0400 Message-ID: <40FC60F9.50800@cs.columbia.edu> Date: Mon, 19 Jul 2004 20:02:01 -0400 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 0.7.1 (Windows/20040626) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Simple] Address and person URIs References: <40F97472.7030006@cs.columbia.edu> <40FBCF13.8010308@dynamicsoft.com> <40FC2731.3080801@cisco.com> <40FC40D8.3090103@cs.columbia.edu> <40FC5C50.2080708@cisco.com> In-Reply-To: <40FC5C50.2080708@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 4.6.1.106153, Antispam-Core: 4.6.1.104326, Antispam-Data: 2004.7.19.107928 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' X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 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-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit Paul Kyzivat wrote: > Well, it would be easier if everyone just agreed to have a barcode > branded on their forehead and an RFID chip embedded in them, each > containing their UN assigned global person UUID. > > But I sense a lot of people don't want to be so easily or irrevokably > identifiable. So weak forms of identification may be all that is > generally acceptable. (Hence "I'll have a red carnation in my lapel" > rather than "The SSN on my forehead will be 123-56-7890.") > > Unfortunately, this doesn't lend itself well to URIs or URNs, because > the information isn't Unique. That would argue for my half-in-jest algorithm: a user-chosen random identifier with a one-to-many mapping from DNA instantiation to identifier. If you want to change personas or want multiple personalities, just pick another number. persona:1234567 will do. Indeed, RFC 3043 describes something similar, except that it is server-assigned. > > I think we continue to punt this one for now. > > Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jul 19 22:03:11 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21529; Mon, 19 Jul 2004 22:03:11 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BmjyO-00082b-U6; Mon, 19 Jul 2004 22:03:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bmjvz-0000n9-2S; Mon, 19 Jul 2004 22:00:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bmjtr-0007gI-W1 for simple@megatron.ietf.org; Mon, 19 Jul 2004 21:58:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21113 for ; Mon, 19 Jul 2004 21:58:33 -0400 (EDT) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bmjts-0007wY-PN for simple@ietf.org; Mon, 19 Jul 2004 21:58:39 -0400 Received: from razor.cs.columbia.edu (IDENT:0kNE7CPgeHoDvAjLTN4ZHLazawG8D76K@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i6K1wQfq004699 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Mon, 19 Jul 2004 21:58:26 -0400 (EDT) Received: from [127.0.0.1] (IDENT:CzsJXohkzl1FoV6fCsXgqI5VNqd7LuZc@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i6K1wPjd014766; Mon, 19 Jul 2004 21:58:26 -0400 Message-ID: <40FC7C42.2060703@cs.columbia.edu> Date: Mon, 19 Jul 2004 21:58:26 -0400 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 0.7.1 (Windows/20040626) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Simple WG , Jonathan Rosenberg Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 4.6.1.106153, Antispam-Core: 4.6.1.104326, Antispam-Data: 2004.7.19.107976 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, __EVITE_CTYPE 0, __CT_TEXT_PLAIN 0, __CT 0, __CTE 0, __MIME_TEXT_ONLY 0, USER_AGENT 0.000' X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Content-Transfer-Encoding: 7bit Subject: [Simple] Presence data model: devices X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Content-Transfer-Encoding: 7bit Let me try to formulate my concerns about devices somewhat less flippantly than in my earlier rush mail. I'm probably missing pieces, but we need to start somewhere. A fair treatment would probably require another draft... I have the following concerns: (1) Devices in the data model draft don't correspond exactly to the physical model that naive users have of a device. The data model states, for example, that ... it is perfectly acceptable to use this model to talk about that PC as being composed of two separate devices. There does not appear to be any clear-cut rule that would allow a presentity or watcher to decide whether a single physical device consists of one or more logical or virtual devices. Personal-area network devices such as assemblies of BlueTooth gadgets pose similar problems, as both a view as a single device or as individual devices are reasonable. Locally, we have created virtual multimedia devices that consist of multiple pieces of plastic (a projector, a speakerphone, an IP array microphone). They act exactly like one multimedia device in most senses. (2) Devices have ill-defined properties that are implied, but not stated, to the watcher. The only architectural motivational paragraph that I could find is in Section 4: "Furthermore, the concept of device adds the ability to correlate services together. The device models the underlying platform that supports all of the services on the phone. Its state therefore impacts all services." However, the types of states that are shared are implicit, not explicit. Clearly, devices do not share *all* states across services. For every possible state, there are plausible exceptions where services on the device do *not* share that state. I gave a few examples, but the burden is on the device proponent to prove that the watcher can unambiguously determine which states are indeed shared and why such knowledge is useful to the watcher. The likely case is that some states for some services are shared for some devices, while others are not. (I'm guessing that any reasonable device will have one shared location state, at least at GPS resolution, but the example above shows that you can violate even that assumption with a bit of forward thinking.) I agree that state inference models are useful - the draft alludes to that. However, many of these are probably best expressed as either local rules at the composer, based on local knowledge available to the composer, or as heuristics ("if my two mobile devices report two different locations, pick my Brand X cell phone since I carry that to job sites"; "if my cell phone service is reporting me as talking, mark presentity status as busy"). It is unclear how a watcher would benefit from such decontextualized knowledge. (3) Some of the motivating assumptions are short-term or debatable. For many users, devices represent the ability to communicate, not services. Frequently, users my statements like, "call me on my cell phone" ... It is debatable that users actually want to refer to a device, even though the current service=device abstraction encourages that. As soon as a service is available on multiple devices, users are just as likely to say "call me on my 3G service". Since a device in this model is not reachable itself (it only has a URN that does not resolve), this device notion can't actually be implemented by a user - the device tuple cannot be used to actually call the device. Thus, there is no functionality gain and the user still has to use a service tuple, with caller prefs or an explicitly labeled service, to do anything of use. If you want to call the Nokia-made blue cell phone of mine, there has to be a service tuple, with URI, that maps one-to-one to that device. If a service maps to multiple devices, I can't actually call that one piece of plastic. My proposal is simple: remove the notion of devices from the data model. If there is a need to allow one-to-many references (e.g., one service found at multiple locations due to uncertainties in where the presentity is), we should have appropriate means to express this by value or by reference for that particular service tuple and property. I would like to see examples of services that significantly benefit from adding devices and that cannot be similarly expressed by the summarization model across service instances. (= a property that is shared by all instances of a service or there there is at least one instance that can be selected is shown.) My basic contention is simplicity: we should have a minimalist data model that cannot be reduced any further. Henning _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Jul 20 04:17:49 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29218; Tue, 20 Jul 2004 04:17:49 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bmpoz-0004Gu-U6; Tue, 20 Jul 2004 04:17:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bmpjf-0003si-SO; Tue, 20 Jul 2004 04:12:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BmpcT-0002Io-Cu for simple@megatron.ietf.org; Tue, 20 Jul 2004 04:05:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28431 for ; Tue, 20 Jul 2004 04:04:59 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BmpcY-00048e-Tx for simple@ietf.org; Tue, 20 Jul 2004 04:05:07 -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 i6K84a700294; Tue, 20 Jul 2004 11:04:36 +0300 (EET DST) X-Scanned: Tue, 20 Jul 2004 11:04:29 +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 i6K84Tto031067; Tue, 20 Jul 2004 11:04:29 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00n3HM1l; Tue, 20 Jul 2004 11:04: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 i6K84Hn23130; Tue, 20 Jul 2004 11:04:17 +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, 20 Jul 2004 11:04:16 +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] Presence data model: devices x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Date: Tue, 20 Jul 2004 11:04:15 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7023EEB47@esebe019.ntc.nokia.com> Thread-Topic: [Simple] Presence data model: devices Thread-Index: AcRt/hNTYyQ/JSo9T5isqbR5BYxjbwALhn4A To: , , X-OriginalArrivalTime: 20 Jul 2004 08:04:16.0722 (UTC) FILETIME=[2721AB20:01C46E30] X-Spam-Score: 0.3 (/) X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48 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-Score: 0.3 (/) X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: simple-bounces@ietf.org=20 > [mailto:simple-bounces@ietf.org]On Behalf > Of ext Henning Schulzrinne > Sent: 20.July.2004 04:58 > To: Simple WG; Jonathan Rosenberg > Subject: [Simple] Presence data model: devices >=20 >=20 > Let me try to formulate my concerns about devices somewhat less=20 > flippantly than in my earlier rush mail. I'm probably missing pieces,=20 > but we need to start somewhere. A fair treatment would=20 > probably require=20 > another draft... >=20 > I have the following concerns: >=20 > (1) Devices in the data model draft don't correspond exactly to the=20 > physical model that naive users have of a device. The data=20 > model states,=20 > for example, that >=20 > ... it is perfectly > acceptable to use this model to talk about that PC as=20 > being composed > of two separate devices. >=20 > There does not appear to be any clear-cut rule that would allow a=20 > presentity or watcher to decide whether a single physical device=20 > consists of one or more logical or virtual devices. Personal-area=20 > network devices such as assemblies of BlueTooth gadgets pose similar=20 > problems, as both a view as a single device or as individual=20 > devices are=20 > reasonable. Locally, we have created virtual multimedia devices that=20 > consist of multiple pieces of plastic (a projector, a=20 > speakerphone, an=20 > IP array microphone). They act exactly like one multimedia device in=20 > most senses. Just thinking aloud here. If we state that a device is the equipment = used by a service, then it can be a virual device or one physical = device, depending on the service and the combination of equipment that = are needed for the service to be usable. So, for example, I'm using bluetooth to connect my mobile phone to my PC = that is connected to the internet, I therefore have email on my mobile. = The device that represents the email service would not be the mobile = phone alone, but the combination of the mobile phone and the PC. = Otherwise the service is not available. But the question is, do watchers care? they might. It is a little = misleading to represent the above service to be email on a mobile phone. = So in actual fact, I need a 3rd "device" that represents the combination = of a mobile phone and a PC. Does that need a tuple of its own? I don't = know, and I guess this is what Henning is arguing against. I believe it is useful for watchers to know the device the service is = available on. For example, I will only make voice calls to you if you = have voice on you PC since calling to you on your mobile phone will cost = me extra. I'm not sure yet if a tuple is needed, or if a device-id is sufficient = enough. In either case, something (characteristics) is needed to = identify that device as a PC, mobile, or a combination and therefore = will enable better GUI representation of that device (like an icon = rendered locally). >=20 > (2) Devices have ill-defined properties that are implied, but not=20 > stated, to the watcher. >=20 > The only architectural motivational paragraph that I could find is in=20 > Section 4: "Furthermore, the concept of device adds the ability to=20 > correlate services together. The device models the=20 > underlying platform=20 > that supports all of the services on the phone. Its state therefore=20 > impacts all services." >=20 > However, the types of states that are shared are implicit,=20 > not explicit.=20 > Clearly, devices do not share *all* states across services. For every=20 > possible state, there are plausible exceptions where services on the=20 > device do *not* share that state. I gave a few examples, but=20 > the burden=20 > is on the device proponent to prove that the watcher can=20 > unambiguously=20 > determine which states are indeed shared and why such knowledge is=20 > useful to the watcher. The likely case is that some states for some=20 > services are shared for some devices, while others are not. (I'm=20 > guessing that any reasonable device will have one shared=20 > location state,=20 > at least at GPS resolution, but the example above shows that you can=20 > violate even that assumption with a bit of forward thinking.) >=20 > I agree that state inference models are useful - the draft alludes to=20 > that. However, many of these are probably best expressed as=20 > either local=20 > rules at the composer, based on local knowledge available to the=20 > composer, or as heuristics ("if my two mobile devices report two=20 > different locations, pick my Brand X cell phone since I carry that to=20 > job sites"; "if my cell phone service is reporting me as=20 > talking, mark=20 > presentity status as busy"). It is unclear how a watcher=20 > would benefit=20 > from such decontextualized knowledge. I might agree that if a device state changes, then the presence state of = those services affected should change, and therefore no presence state = of a device is ever published, but rather those states of the services = are. I see this as local to the publisher though, and not the = compositor. If we agree that a tuple represents the presence state of something, = then I can buy that a device tuple is not needed. But again, a device ID = and characteristics mapped to a service is needed. Regards, Hisham >=20 > (3) Some of the motivating assumptions are short-term or debatable. >=20 > For many users, devices represent the ability > to communicate, not services. Frequently, users my=20 > statements like, > "call me on my cell phone" ... >=20 > It is debatable that users actually want to refer to a device, even=20 > though the current service=3Ddevice abstraction encourages=20 > that. As soon=20 > as a service is available on multiple devices, users are just=20 > as likely=20 > to say "call me on my 3G service". Since a device in this=20 > model is not=20 > reachable itself (it only has a URN that does not resolve),=20 > this device=20 > notion can't actually be implemented by a user - the device=20 > tuple cannot=20 > be used to actually call the device. Thus, there is no functionality=20 > gain and the user still has to use a service tuple, with=20 > caller prefs or=20 > an explicitly labeled service, to do anything of use. If you want to=20 > call the Nokia-made blue cell phone of mine, there has to be=20 > a service=20 > tuple, with URI, that maps one-to-one to that device. If a=20 > service maps=20 > to multiple devices, I can't actually call that one piece of plastic. >=20 > My proposal is simple: remove the notion of devices from the=20 > data model.=20 > If there is a need to allow one-to-many references (e.g., one service=20 > found at multiple locations due to uncertainties in where the=20 > presentity=20 > is), we should have appropriate means to express this by value or by=20 > reference for that particular service tuple and property. >=20 > I would like to see examples of services that significantly=20 > benefit from=20 > adding devices and that cannot be similarly expressed by the=20 > summarization model across service instances. (=3D a property that is=20 > shared by all instances of a service or there there is at least one=20 > instance that can be selected is shown.) >=20 > My basic contention is simplicity: we should have a minimalist data=20 > model that cannot be reduced any further. >=20 > Henning >=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 Jul 20 09:53:48 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20111; Tue, 20 Jul 2004 09:53:47 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bmv4B-0000NE-48; Tue, 20 Jul 2004 09:53:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BmuuC-0000lF-2X; Tue, 20 Jul 2004 09:43:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BmuqS-0007vw-UU for simple@megatron.ietf.org; Tue, 20 Jul 2004 09:39:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19168 for ; Tue, 20 Jul 2004 09:39:47 -0400 (EDT) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bmuqc-00009O-48 for simple@ietf.org; Tue, 20 Jul 2004 09:39:58 -0400 Received: from razor.cs.columbia.edu (IDENT:2wkuhWzLFLyMDVGp7eLFFHVkegf5ZI20@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i6KDdefq008033 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Tue, 20 Jul 2004 09:39:40 -0400 (EDT) Received: from [127.0.0.1] (IDENT:dU65dpK3N8WUbBx15P7WuYZF7+Ilnh7u@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i6KDddjd018306; Tue, 20 Jul 2004 09:39:39 -0400 Message-ID: <40FD209A.9060009@cs.columbia.edu> Date: Tue, 20 Jul 2004 09:39:38 -0400 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 0.7.1 (Windows/20040626) X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com Subject: Re: [Simple] Presence data model: devices References: <2038BCC78B1AD641891A0D1AE133DBB7023EEB47@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB7023EEB47@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 4.6.1.106153, Antispam-Core: 4.6.1.104326, Antispam-Data: 2004.7.19.107976 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, __CHILD_PORN_NOT_1 0, EMAIL_ATTRIBUTION 0, QUOTED_EMAIL_TEXT 0, __MIME_TEXT_ONLY 0, REFERENCES 0.000, IN_REP_TO 0, USER_AGENT 0.000' X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a 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-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > But the question is, do watchers care? they might. It is a little > misleading to represent the above service to be email on a mobile > phone. So in actual fact, I need a 3rd "device" that represents the > combination of a mobile phone and a PC. Does that need a tuple of its > own? I don't know, and I guess this is what Henning is arguing > against. I'm arguing that the watcher does not, in general, care how the service is provided. The watcher does not get a choice in the matter and is as likely to draw wrong conclusions, based on his mental model of what a device looks like, than right conclusions. Currently, many services are indeed tied to a single device in a fairly transparent manner. But single-service devices don't benefit from dividing service and device description. It's only if multiple services share a device (or multiple devices contribute to a service) that there is anything of interest. In the current design, the device model cannot be used to reliably reach one device ("call my blue Nokia cell phone") unless each service has only one device or there is a service that only reaches that one device. If that's the case, the service description itself can describe the device. (I doubt that this is useful in practice, but just in case.) > > I believe it is useful for watchers to know the device the service is > available on. For example, I will only make voice calls to you if you > have voice on you PC since calling to you on your mobile phone will > cost me extra. The device does not matter here - it's the knowledge of the cost of the *service* that matters. After all, it's not the device that charges you money, it's the service that does. It just happens that you are running the service on a specific device today. If I run my cell phone PCMCIA card on my PC, your assumption is suddenly wrong - calling my PC will indeed cost extra. Thus, simply assuming that "PC=free" is exactly the kind of implicit assumption that is probably mostly right, but will increasingly be dangerously wrong as the traditional device boundaries disappear. > > I'm not sure yet if a tuple is needed, or if a device-id is > sufficient enough. In either case, something (characteristics) is > needed to identify that device as a PC, mobile, or a combination and > therefore will enable better GUI representation of that device (like > an icon rendered locally). Again, I don't see how the knowledge of the device helps the *watcher*. I care what kind of service I'll be getting, in terms of quality and cost, but that depends on the service definition. Indeed, as noted, unless you map services to devices one-to-one, you can only guess that you'll get one of the N devices making up the service. > I might agree that if a device state changes, then the presence state > of those services affected should change, and therefore no presence > state of a device is ever published, but rather those states of the > services are. I see this as local to the publisher though, and not > the compositor. > > If we agree that a tuple represents the presence state of something, > then I can buy that a device tuple is not needed. But again, a device > ID and characteristics mapped to a service is needed. I don't see how a device ID helps at all. There are two cases, depending on the mapping: - A particular service maps to exactly one device. In that case, the properties of the device (speed, display size, media capabilities, etc.) are part of the service - for that service at that time, you only get those characteristics. Since many of the characteristics are indeed determined by the capabilities of the service provider and the service plan chosen by the user, not the piece of plastic in the user's pocket, the service-device distinction seems arbitrary. - A particular service maps to multiple devices, forking-style. In that case, the only advantage of having device tuples is that it allows you to enumerate the possible end points where your call might end up. You don't get a choice (although caller preferences might give you input), but you might get a hint. This, I believe, is however, much better coded as an enumeration of service capabilities as they are as likely to be constrained by the service offering as by the piece of plastic. Any other service constraints ("can't do X and Y at the same time because they share one device") rely on dubious assumptions about particular instances of plastic. I do agree that specifying the source and nature of data is a really good idea. For example, it might be valuable to provide indications of the type of idleness ("no communications", "no user input"), rather than having the watcher try to deduce this based on guesses what kind of cell phone a cell phone is. As mobile devices become basically multi-tasking pocket PCs with a screen that is as large as PC screens were about five years ago, it seems increasingly dubious to rely on classifications that might have been vaguely helpful in a single-line, single-purpose world of the Motorola StarTAC. > > Regards, Hisham > Henning _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Jul 20 10:24:38 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23364; Tue, 20 Jul 2004 10:24:37 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BmvY1-0000oW-Mr; Tue, 20 Jul 2004 10:24:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BmvR5-0006Dn-C5; Tue, 20 Jul 2004 10:17:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BmvII-0001qn-QL for simple@megatron.ietf.org; Tue, 20 Jul 2004 10:08:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21399 for ; Tue, 20 Jul 2004 10:08:32 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BmvIP-0000c4-1u for simple@ietf.org; Tue, 20 Jul 2004 10:08: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 i6KE8Gv06415; Tue, 20 Jul 2004 17:08:16 +0300 (EET DST) X-Scanned: Tue, 20 Jul 2004 17:08: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 i6KE8D7a020078; Tue, 20 Jul 2004 17:08:13 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00NzGhOi; Tue, 20 Jul 2004 17:07:41 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 i6KE7Xn29445; Tue, 20 Jul 2004 17:07:33 +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, 20 Jul 2004 17:07:31 +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] Presence data model: devices x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Date: Tue, 20 Jul 2004 17:07:30 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7023EEB50@esebe019.ntc.nokia.com> Thread-Topic: [Simple] Presence data model: devices Thread-Index: AcRuXyyzQ6mm+vdjRr2gGhaf6Ryp6wAAuVXQ To: X-OriginalArrivalTime: 20 Jul 2004 14:07:31.0584 (UTC) FILETIME=[E5E1B000:01C46E62] X-Spam-Score: 0.3 (/) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 Content-Transfer-Encoding: quoted-printable 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-Score: 0.3 (/) X-Scan-Signature: 995b2e24d23b953c94bac5288c432399 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: 20.July.2004 16:40 > To: Khartabil Hisham (Nokia-TP-MSW/Helsinki) > Cc: simple@ietf.org; jdrosen@dynamicsoft.com > Subject: Re: [Simple] Presence data model: devices >=20 >=20 > hisham.khartabil@nokia.com wrote: >=20 > > But the question is, do watchers care? they might. It is a little > > misleading to represent the above service to be email on a mobile > > phone. So in actual fact, I need a 3rd "device" that represents the > > combination of a mobile phone and a PC. Does that need a=20 > tuple of its > > own? I don't know, and I guess this is what Henning is arguing > > against. >=20 > I'm arguing that the watcher does not, in general, care how=20 > the service=20 > is provided. The watcher does not get a choice in the matter=20 > and is as=20 > likely to draw wrong conclusions, based on his mental model of what a=20 > device looks like, than right conclusions. >=20 > Currently, many services are indeed tied to a single device=20 > in a fairly=20 > transparent manner. But single-service devices don't benefit from=20 > dividing service and device description. It's only if=20 > multiple services=20 > share a device (or multiple devices contribute to a service)=20 > that there=20 > is anything of interest. >=20 > In the current design, the device model cannot be used to=20 > reliably reach=20 > one device ("call my blue Nokia cell phone") unless each service has=20 > only one device or there is a service that only reaches that=20 > one device.=20 > If that's the case, the service description itself can describe the=20 > device. (I doubt that this is useful in practice, but just in case.) >=20 >=20 > >=20 > > I believe it is useful for watchers to know the device the=20 > service is > > available on. For example, I will only make voice calls to=20 > you if you > > have voice on you PC since calling to you on your mobile phone will > > cost me extra. >=20 > The device does not matter here - it's the knowledge of the=20 > cost of the=20 > *service* that matters. After all, it's not the device that=20 > charges you=20 > money, it's the service that does. It just happens that you=20 > are running=20 > the service on a specific device today. If I run my cell phone PCMCIA=20 > card on my PC, your assumption is suddenly wrong - calling my PC will=20 > indeed cost extra. Thus, simply assuming that "PC=3Dfree" is=20 > exactly the=20 > kind of implicit assumption that is probably mostly right, but will=20 > increasingly be dangerously wrong as the traditional device=20 > boundaries=20 > disappear. >=20 >=20 > >=20 > > I'm not sure yet if a tuple is needed, or if a device-id is > > sufficient enough. In either case, something (characteristics) is > > needed to identify that device as a PC, mobile, or a combination and > > therefore will enable better GUI representation of that device (like > > an icon rendered locally). >=20 > Again, I don't see how the knowledge of the device helps the=20 > *watcher*.=20 > I care what kind of service I'll be getting, in terms of quality and=20 > cost, but that depends on the service definition. Indeed, as noted,=20 > unless you map services to devices one-to-one, you can only=20 > guess that=20 > you'll get one of the N devices making up the service. >=20 >=20 >=20 > > I might agree that if a device state changes, then the=20 > presence state > > of those services affected should change, and therefore no presence > > state of a device is ever published, but rather those states of the > > services are. I see this as local to the publisher though, and not > > the compositor. > >=20 > > If we agree that a tuple represents the presence state of something, > > then I can buy that a device tuple is not needed. But=20 > again, a device > > ID and characteristics mapped to a service is needed. >=20 > I don't see how a device ID helps at all. There are two=20 > cases, depending=20 > on the mapping: >=20 > - A particular service maps to exactly one device. In that case, the=20 > properties of the device (speed, display size, media=20 > capabilities, etc.)=20 > are part of the service - for that service at that time, you only get=20 > those characteristics. Since many of the characteristics are indeed=20 > determined by the capabilities of the service provider and=20 > the service=20 > plan chosen by the user, not the piece of plastic in the=20 > user's pocket,=20 > the service-device distinction seems arbitrary. >=20 > - A particular service maps to multiple devices,=20 > forking-style. In that=20 > case, the only advantage of having device tuples is that it=20 > allows you=20 > to enumerate the possible end points where your call might=20 > end up. You=20 > don't get a choice (although caller preferences might give=20 > you input),=20 > but you might get a hint. This, I believe, is however, much=20 > better coded=20 > as an enumeration of service capabilities as they are as likely to be=20 > constrained by the service offering as by the piece of plastic. A GRUU guarantees where a request will end up. You are making the = assumption that tuples for the same service will get merged. I'm not = making that assumption. My watchers will see 2 tuples for the same = service if they get published by different PUAs. Each tuple will have a = GRUU. It will then be helpful to have device characteristics for that = service and the GRUU will get you to that device. It does not have to be = device-ID as I earlier suggested, the service tuple can describe the = device. But if there are many services on that device, then describing = those characteristics on one place is sound. Tuple might be one place to = do so. Regards, Hisham >=20 > Any other service constraints ("can't do X and Y at the same time=20 > because they share one device") rely on dubious assumptions about=20 > particular instances of plastic. >=20 > I do agree that specifying the source and nature of data is a really=20 > good idea. For example, it might be valuable to provide=20 > indications of=20 > the type of idleness ("no communications", "no user input"),=20 > rather than=20 > having the watcher try to deduce this based on guesses what=20 > kind of cell=20 > phone a cell phone is. >=20 > As mobile devices become basically multi-tasking pocket PCs with a=20 > screen that is as large as PC screens were about five years ago, it=20 > seems increasingly dubious to rely on classifications that might have=20 > been vaguely helpful in a single-line, single-purpose world of the=20 > Motorola StarTAC. >=20 >=20 >=20 >=20 > >=20 > > Regards, Hisham > >=20 >=20 > Henning >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Jul 20 11:08:00 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26499; Tue, 20 Jul 2004 11:08:00 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BmwDz-0001RD-Hg; Tue, 20 Jul 2004 11:08:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BmwAU-0004RG-8F; Tue, 20 Jul 2004 11:04:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bmw0w-0001WK-5Y for simple@megatron.ietf.org; Tue, 20 Jul 2004 10:54:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25668 for ; Tue, 20 Jul 2004 10:54:39 -0400 (EDT) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bmw15-0001GI-1O for simple@ietf.org; Tue, 20 Jul 2004 10:54:52 -0400 Received: from panther.cs.columbia.edu (IDENT:DwVH954eHUuDE053PNP76vgeIObTkHGh@panther.cs.columbia.edu [128.59.16.122]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i6KEsWfq021875 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Tue, 20 Jul 2004 10:54:33 -0400 (EDT) Received: from [128.59.16.206] (chairpc.cs.columbia.edu [128.59.16.206]) by panther.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id i6KEsWHr023618; Tue, 20 Jul 2004 10:54:32 -0400 Message-ID: <40FD3228.40700@cs.columbia.edu> Date: Tue, 20 Jul 2004 10:54:32 -0400 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com Subject: Re: [Simple] Presence data model: devices References: <2038BCC78B1AD641891A0D1AE133DBB7023EEB50@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB7023EEB50@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 4.6.1.106153, Antispam-Core: 4.6.1.104326, Antispam-Data: 2004.7.19.107976 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, QUOTED_EMAIL_TEXT 0, __MIME_TEXT_ONLY 0, REFERENCES 0.000, IN_REP_TO 0, USER_AGENT 0.000' X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 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-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit > > A GRUU guarantees where a request will end up. You are making the Yes, but according to the data model draft, only services have GRUUs. Devices don't. > assumption that tuples for the same service will get merged. I'm not No, I'm not making this assumption. > making that assumption. My watchers will see 2 tuples for the same > service if they get published by different PUAs. Each tuple will have > a GRUU. It will then be helpful to have device characteristics for > that service and the GRUU will get you to that device. It does not > have to be device-ID as I earlier suggested, the service tuple can > describe the device. But if there are many services on that device, Indeed, that's what I'm suggesting for the case that a service has a set of properties. In any event, we need to be able to describe the set of properties (precaps, etc.) for services, which are more than just those for pieces of plastic. > then describing those characteristics on one place is sound. Tuple > might be one place to do so. This is simply a matter of saving space by reference. I think there are better ways to remove redundancy for space saving, e.g., through compression. > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Jul 20 11:30:12 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28149; Tue, 20 Jul 2004 11:30:12 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BmwZU-0001qY-62; Tue, 20 Jul 2004 11:30:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BmwSW-0001fn-Gm; Tue, 20 Jul 2004 11:23:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BmwEQ-0005h2-Ui for simple@megatron.ietf.org; Tue, 20 Jul 2004 11:08:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26542 for ; Tue, 20 Jul 2004 11:08:36 -0400 (EDT) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BmwEa-0001RX-1b for simple@ietf.org; Tue, 20 Jul 2004 11:08:49 -0400 Received: from panther.cs.columbia.edu (IDENT:wQ0IgImHbRowfgwV0j/UtKMXMSd8j6Fm@panther.cs.columbia.edu [128.59.16.122]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i6KF8Vfq024791 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Tue, 20 Jul 2004 11:08:31 -0400 (EDT) Received: from [128.59.16.206] (chairpc.cs.columbia.edu [128.59.16.206]) by panther.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id i6KF8VHr025018 for ; Tue, 20 Jul 2004 11:08:31 -0400 Message-ID: <40FD356F.70906@cs.columbia.edu> Date: Tue, 20 Jul 2004 11:08:31 -0400 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) 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 X-PMX-Version: 4.6.1.106153, Antispam-Core: 4.6.1.104326, Antispam-Data: 2004.7.19.107976 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, __EVITE_CTYPE 0, __CT_TEXT_PLAIN 0, __CT 0, __CTE 0, __MIME_TEXT_ONLY 0, USER_AGENT 0.000' X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Subject: [Simple] Data model: idle X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit I believe that the distinction of device and service idleness is of limited use. Without detailed knowledge of how a device is set up (virtual, physical, idle metrics), one can't deduce much either way. It seems unlikely that a watcher would have this As noted in the draft, a service can be active without human user interface (HMI) activity. Similarly, a device can be in use without HMI activity. Since only SIMPLE-based services are going to be publishing status, there is no problem with the service component reporting the reasoning for its indication of idle or activity, such as HMI activity, media input, active applications or some kind of physical presence sensor (there are security systems that log the user off when the RFID tag is removed from the vicinity). The composer can then draw the right conclusion and deduce the presentity or service status by a logical merging or selection operation. This seems much more explicit than trying to guess or proscribe how idleness is being detected. Henning _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Jul 20 12:53:49 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04733; Tue, 20 Jul 2004 12:53:49 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BmxsR-0003A4-Ci; Tue, 20 Jul 2004 12: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 1BmxhL-00015W-IK; Tue, 20 Jul 2004 12:42:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BmxWZ-0005vy-Ff for simple@megatron.ietf.org; Tue, 20 Jul 2004 12:31:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02991 for ; Tue, 20 Jul 2004 12:31:24 -0400 (EDT) Received: from hostree27.alcatel.com ([143.209.238.39] helo=auds959.usa.alcatel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BmxWk-0002nt-1q for simple@ietf.org; Tue, 20 Jul 2004 12:31:38 -0400 Received: from alcatel.com (localhost [127.0.0.1]) by auds959.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id i6KGUTHB021661; Tue, 20 Jul 2004 11:30:29 -0500 (CDT) Message-ID: <40FD48A3.BE4EA775@alcatel.com> Date: Tue, 20 Jul 2004 11:30:27 -0500 From: Alex Audu X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [Simple] Presence data model: devices References: <40FC7C42.2060703@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Content-Transfer-Encoding: 7bit Cc: Jonathan Rosenberg , Simple WG 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-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Content-Transfer-Encoding: 7bit I guess one thing to think about is "can a service map to multiple devices?" I think it certainly can. We have seen how telephony service has grown from being supported on only the black phone, to now being supported on a multitude of newer, more versatile devices. It is not uncommon for Joe to ask a friend "can you call me back on my land-line phone? I can't hear you very well on this cell phone". Modes of communication vary. They can include audio/visual (send audio and receive video after appropriate translations, send audio and receive audio, send video and receive audio, send video and receive video), sensory, and tactile communication modes. It is possible but rare that one device can support all these modes; however it most likely that the various modes will be supported on different devices optimized for each mode. So, I am not sure if we can dimish the importance of device addressability. Regards, Alex. Henning Schulzrinne wrote: > Let me try to formulate my concerns about devices somewhat less > flippantly than in my earlier rush mail. I'm probably missing pieces, > but we need to start somewhere. A fair treatment would probably require > another draft... > > I have the following concerns: > > (1) Devices in the data model draft don't correspond exactly to the > physical model that naive users have of a device. The data model states, > for example, that > > ... it is perfectly > acceptable to use this model to talk about that PC as being composed > of two separate devices. > > There does not appear to be any clear-cut rule that would allow a > presentity or watcher to decide whether a single physical device > consists of one or more logical or virtual devices. Personal-area > network devices such as assemblies of BlueTooth gadgets pose similar > problems, as both a view as a single device or as individual devices are > reasonable. Locally, we have created virtual multimedia devices that > consist of multiple pieces of plastic (a projector, a speakerphone, an > IP array microphone). They act exactly like one multimedia device in > most senses. > > (2) Devices have ill-defined properties that are implied, but not > stated, to the watcher. > > The only architectural motivational paragraph that I could find is in > Section 4: "Furthermore, the concept of device adds the ability to > correlate services together. The device models the underlying platform > that supports all of the services on the phone. Its state therefore > impacts all services." > > However, the types of states that are shared are implicit, not explicit. > Clearly, devices do not share *all* states across services. For every > possible state, there are plausible exceptions where services on the > device do *not* share that state. I gave a few examples, but the burden > is on the device proponent to prove that the watcher can unambiguously > determine which states are indeed shared and why such knowledge is > useful to the watcher. The likely case is that some states for some > services are shared for some devices, while others are not. (I'm > guessing that any reasonable device will have one shared location state, > at least at GPS resolution, but the example above shows that you can > violate even that assumption with a bit of forward thinking.) > > I agree that state inference models are useful - the draft alludes to > that. However, many of these are probably best expressed as either local > rules at the composer, based on local knowledge available to the > composer, or as heuristics ("if my two mobile devices report two > different locations, pick my Brand X cell phone since I carry that to > job sites"; "if my cell phone service is reporting me as talking, mark > presentity status as busy"). It is unclear how a watcher would benefit > from such decontextualized knowledge. > > (3) Some of the motivating assumptions are short-term or debatable. > > For many users, devices represent the ability > to communicate, not services. Frequently, users my statements like, > "call me on my cell phone" ... > > It is debatable that users actually want to refer to a device, even > though the current service=device abstraction encourages that. As soon > as a service is available on multiple devices, users are just as likely > to say "call me on my 3G service". Since a device in this model is not > reachable itself (it only has a URN that does not resolve), this device > notion can't actually be implemented by a user - the device tuple cannot > be used to actually call the device. Thus, there is no functionality > gain and the user still has to use a service tuple, with caller prefs or > an explicitly labeled service, to do anything of use. If you want to > call the Nokia-made blue cell phone of mine, there has to be a service > tuple, with URI, that maps one-to-one to that device. If a service maps > to multiple devices, I can't actually call that one piece of plastic. > > My proposal is simple: remove the notion of devices from the data model. > If there is a need to allow one-to-many references (e.g., one service > found at multiple locations due to uncertainties in where the presentity > is), we should have appropriate means to express this by value or by > reference for that particular service tuple and property. > > I would like to see examples of services that significantly benefit from > adding devices and that cannot be similarly expressed by the > summarization model across service instances. (= a property that is > shared by all instances of a service or there there is at least one > instance that can be selected is shown.) > > My basic contention is simplicity: we should have a minimalist data > model that cannot be reduced any further. > > Henning > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Jul 20 13:02:32 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05595; Tue, 20 Jul 2004 13:02:32 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bmy0r-0003Gm-U9; Tue, 20 Jul 2004 13: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 1Bmxvx-0005CL-CP; Tue, 20 Jul 2004 12:57:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BmxhO-0001A7-7w for simple@megatron.ietf.org; Tue, 20 Jul 2004 12:42:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03893 for ; Tue, 20 Jul 2004 12:42:35 -0400 (EDT) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BmxhY-0002zI-2P for simple@ietf.org; Tue, 20 Jul 2004 12:42:49 -0400 Received: from panther.cs.columbia.edu (IDENT:SEbaf+1cX3n4bYf+DCY2V1HGeBppSxUa@panther.cs.columbia.edu [128.59.16.122]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i6KGgRfq012329 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Tue, 20 Jul 2004 12:42:28 -0400 (EDT) Received: from [128.59.16.206] (chairpc.cs.columbia.edu [128.59.16.206]) by panther.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id i6KGgRHr001806; Tue, 20 Jul 2004 12:42:27 -0400 Message-ID: <40FD4B73.4060009@cs.columbia.edu> Date: Tue, 20 Jul 2004 12:42:27 -0400 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: alex.audu@alcatel.com Subject: Re: [Simple] Presence data model: devices References: <40FC7C42.2060703@cs.columbia.edu> <40FD48A3.BE4EA775@alcatel.com> In-Reply-To: <40FD48A3.BE4EA775@alcatel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 4.6.1.106153, Antispam-Core: 4.6.1.104326, Antispam-Data: 2004.7.19.107976 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, __PORN_PHRASE_15_0 0, QUOTED_EMAIL_TEXT 0, __MIME_TEXT_ONLY 0, REFERENCES 0.000, IN_REP_TO 0, USER_AGENT 0.000' X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 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-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit > "can you call me back on my land-line phone? I can't hear you very well on > this > cell phone". None of this requires a device abstraction. The caller can only choose the mobility modality if (1) there are two separate service entries (one stationary, one mobile) or (2) there is one service entry and the caller uses caller preferences that the callee chooses to honor. Neither requires nor benefits from a device tuple. (Devices tuples cannot be contacted directly.) In many cases, we'll have a single watcher-visible modality that encompasses multiple devices. For example, on trips to Europe, I carry both my GSM phone (works in both places) and my CDMA phone (works in only one, but is cheaper). I want the caller to reach my mobile service, but don't necessarily want to have to expose the devices as that's none of the caller's business. Thus, I need the ability to declare a mobile *service* (which is then routed according to my service preferences to one of my phones, e.g., depending on how much an incoming call is going to cost me.) [The proposed model allows this, as far as I can tell, so no disagreement here.] > > Modes of communication vary. They can include audio/visual (send audio and > receive > video after appropriate translations, send audio and receive audio, send > video and > receive audio, send video and receive video), sensory, and tactile > communication modes. > It is possible but rare that one device can support all these modes; > however it most likely > that the various modes will be supported on different devices optimized for > each mode. > So, I am not sure if we can dimish the importance of device addressability. I don't think anybody is arguing that we outlaw one-device service tuples if the user wants to publish these. Only services are addressable in the proposed model. Thus, the presence of device tuples does not help or hinder their addressability. Henning _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Jul 20 14:55:45 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15540; Tue, 20 Jul 2004 14:55:45 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BmzmQ-0005Bm-Iy; Tue, 20 Jul 2004 14:55:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bmzjs-0003ay-2u; Tue, 20 Jul 2004 14:53:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BmzWn-0008JB-Rk for simple@megatron.ietf.org; Tue, 20 Jul 2004 14:39:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14299 for ; Tue, 20 Jul 2004 14:39:48 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BmzWx-0004vy-Nz for simple@ietf.org; Tue, 20 Jul 2004 14:40:02 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 20 Jul 2004 11:40:53 -0700 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 i6KIdBIX021254; Tue, 20 Jul 2004 11:39:14 -0700 (PDT) Received: from cisco.com ([161.44.79.221]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKG24915; Tue, 20 Jul 2004 14:39:10 -0400 (EDT) Message-ID: <40FD66CE.2080806@cisco.com> Date: Tue, 20 Jul 2004 14:39:10 -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] Presence data model: devices References: <2038BCC78B1AD641891A0D1AE133DBB7023EEB50@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit Cc: jdrosen@dynamicsoft.com, 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-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > >>- A particular service maps to multiple devices, >>forking-style. In that >>case, the only advantage of having device tuples is that it >>allows you >>to enumerate the possible end points where your call might >>end up. You >>don't get a choice (although caller preferences might give >>you input), >>but you might get a hint. This, I believe, is however, much >>better coded >>as an enumeration of service capabilities as they are as likely to be >>constrained by the service offering as by the piece of plastic. > > A GRUU guarantees where a request will end up. > You are making the assumption that tuples for the same service > will get merged. Henning was enumerating the cases. This one case assumes the service forks to multiple devices. If there is indeed to be presence information from each of those then yes, presumably it is being merged. He covered the other cases as well. > I'm not making that assumption. > My watchers will see 2 tuples for the same service if they get > published by different PUAs. Each tuple will have a GRUU. Then by the terminology we are using here, they are two different services, not one. > It will then be helpful to have device characteristics for that > service and the GRUU will get you to that device. Because they are separate services, we are back at the degenerate case where service = device, and "device characteristics" can be associated with the service. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Jul 20 22:13:54 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29943; Tue, 20 Jul 2004 22:13:54 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bn6cW-0008HL-I9; Tue, 20 Jul 2004 22:14:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bn2IB-0003Jp-D7; Tue, 20 Jul 2004 17: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 1Bn1CD-0003nq-CQ; Tue, 20 Jul 2004 16:26:41 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27249; Tue, 20 Jul 2004 16:26:39 -0400 (EDT) Message-Id: <200407202026.QAA27249@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 20 Jul 2004 16:26:38 -0400 Cc: simple@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-xcap-package-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-Score: 0.4 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e --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) Document Format for Indicating Changes in XML Configuration Access Protocol (XCAP) Resources Author(s) : J. Rosenberg Filename : draft-ietf-simple-xcap-package-02.txt Pages : 17 Date : 2004-7-20 This specification defines a document format that can be used to describe the differences between versions of resources managed by the Extensible Markup Language (XML) Configuration Access Protocol (XCAP). Documents of this format can be delivered to clients using a number of means, including the Session Initiation Protocol (SIP) event package for configuration data. By subscribing to this event package, clients can learn about document changes made by other clients. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-package-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-xcap-package-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-xcap-package-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-7-20160439.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-xcap-package-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-xcap-package-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-7-20160439.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 Tue Jul 20 22:19:11 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00920; Tue, 20 Jul 2004 22:19:11 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bn6hd-00006q-UD; Tue, 20 Jul 2004 22:19:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bn2IE-0003Kr-LM; Tue, 20 Jul 2004 17:36:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bn1CQ-0003oW-5y; Tue, 20 Jul 2004 16:26:54 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27303; Tue, 20 Jul 2004 16:26:51 -0400 (EDT) Message-Id: <200407202026.QAA27303@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 20 Jul 2004 16:26:51 -0400 Cc: simple@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-xcap-03.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-Score: 0.4 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : The Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Author(s) : J. Rosenberg Filename : draft-ietf-simple-xcap-03.txt Pages : 57 Date : 2004-7-20 This specification defines the Extensible Markup Language (XML) Configuration Access Protocol (XCAP). XCAP allows a client to read, write and modify application configuration data, stored in XML format on a server. XCAP maps XML document sub-trees and element attributes to HTTP URIs, so that these components can be directly accessed by HTTP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-03.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-03.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-03.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-7-20160446.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-xcap-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-xcap-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-7-20160446.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 Tue Jul 20 22:24:00 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01411; Tue, 20 Jul 2004 22:24:00 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bn6mJ-0000F2-AS; Tue, 20 Jul 2004 22:24:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bn2IQ-0003QQ-99; Tue, 20 Jul 2004 17: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 1Bn1Cm-0003tC-Uy; Tue, 20 Jul 2004 16:27:17 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27397; Tue, 20 Jul 2004 16:27:14 -0400 (EDT) Message-Id: <200407202027.QAA27397@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 20 Jul 2004 16:27:14 -0400 Cc: simple@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-message-sessions-07.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-Score: 0.4 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : The Message Session Relay Protocol Author(s) : B. Campbell, et al. Filename : draft-ietf-simple-message-sessions-07.txt Pages : 52 Date : 2004-7-20 This document describes the Message Session Relay Protocol (MSRP), a protocol for transmitting a series of related instant messages in the context of a session. Message sessions are treated like any other media stream when setup via a rendezvous or session setup protocol such as the Session Initiation Protocol (SIP). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-message-sessions-07.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-message-sessions-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-message-sessions-07.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-7-20160453.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-message-sessions-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-message-sessions-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-7-20160453.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 Tue Jul 20 22:52:33 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08063; Tue, 20 Jul 2004 22:52:32 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bn7Dv-0002LA-Qg; Tue, 20 Jul 2004 22:52:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bn6rN-00008e-As; Tue, 20 Jul 2004 22:29:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bn2M1-0005Ld-UD for simple@megatron.ietf.org; Tue, 20 Jul 2004 17:40:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09346 for ; Tue, 20 Jul 2004 17:40:51 -0400 (EDT) Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bn2ME-0002Zv-2Z for simple@ietf.org; Tue, 20 Jul 2004 17:41:07 -0400 Received: from dynamicsoft.com ([63.113.46.70]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i6KLecGr006611 for ; Tue, 20 Jul 2004 17:40:39 -0400 (EDT) Message-ID: <40FD9142.6030301@dynamicsoft.com> Date: Tue, 20 Jul 2004 17:40: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: Simple WG Content-Type: multipart/mixed; boundary="------------050400040800050708070105" X-Spam-Score: 0.1 (/) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 Subject: [Simple] [Fwd: I-D ACTION:draft-rosenberg-simple-pres-policy-caps-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-Score: 0.1 (/) X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc This is a multi-part message in MIME format. --------------050400040800050708070105 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Folks, In case you were wondering, there is no material change in this version. I submitted a refresh just to keep it in the archives. Once we settle the what-is-a-tuple and presence auth issues, this can be revised to line up. 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 --------------050400040800050708070105 Content-Type: message/rfc822; name="I-D ACTION:draft-rosenberg-simple-pres-policy-caps-01.txt" Content-Disposition: inline; filename="I-D ACTION:draft-rosenberg-simple-pres-policy-caps-01.txt" Received: from proofpoint-01.dynamicsoft.com ([63.113.45.180]) by DYN-EXCH-01.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id P1XGM6L7; Tue, 20 Jul 2004 17:19:39 -0400 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [192.168.4.30]) by proofpoint-01.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id i6KLJbnc031465 for ; Tue, 20 Jul 2004 17:19:38 -0400 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by mail1.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id i6KLJZUv022375 for ; Tue, 20 Jul 2004 17:19:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bn0wW-00051r-Al; Tue, 20 Jul 2004 16:10:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bn0bs-00084t-8t for i-d-announce@megatron.ietf.org; Tue, 20 Jul 2004 15:49:08 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21245 for ; Tue, 20 Jul 2004 15:49:06 -0400 (EDT) Message-Id: <200407201949.PAA21245@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 20 Jul 2004 15:49:06 -0400 Subject: I-D ACTION:draft-rosenberg-simple-pres-policy-caps-01.txt X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: internet-drafts@ietf.org List-Id: i-d-announce.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: i-d-announce-bounces@ietf.org Errors-To: i-d-announce-bounces@ietf.org X-Proofpoint-Spam-Score: 0 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : An Extensible Markup Language (XML) Representation for Expressing Presence Policy Capabilities Author(s) : J. Rosenberg Filename : draft-rosenberg-simple-pres-policy-caps-01.txt Pages : 7 Date : 2004-7-20 An important component of presence services is policy. Policy systems allow the presentity to grant access to specific pieces of information to specific watchers. To allow for interoperability between clients which set such policies, and servers which execute them, it is necessary for clients to be able to determine the capabilities of the server to which it is connected. This specification defines a set of Extensible Markup Language (XML) elements for expressing presence policy capabilities. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-rosenberg-simple-pres-policy-caps-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-rosenberg-simple-pres-policy-caps-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-rosenberg-simple-pres-policy-caps-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-7-20155359.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-rosenberg-simple-pres-policy-caps-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-rosenberg-simple-pres-policy-caps-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --NextPart-- --------------050400040800050708070105 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 --------------050400040800050708070105-- From simple-bounces@ietf.org Tue Jul 20 23:02:27 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08825; Tue, 20 Jul 2004 23:02:27 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bn7NW-0002Uk-BH; Tue, 20 Jul 2004 23: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 1Bn6uB-00049q-T3; Tue, 20 Jul 2004 22:32:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bn38n-0000sd-Sk for simple@megatron.ietf.org; Tue, 20 Jul 2004 18:31:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18838 for ; Tue, 20 Jul 2004 18:31:14 -0400 (EDT) Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bn390-00056r-LG for simple@ietf.org; Tue, 20 Jul 2004 18:31:32 -0400 Received: from dynamicsoft.com ([63.113.46.70]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i6KMUlGr006720; Tue, 20 Jul 2004 18:30:48 -0400 (EDT) Message-ID: <40FD9D03.2080202@dynamicsoft.com> Date: Tue, 20 Jul 2004 18:30: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: Henning Schulzrinne References: <40FC7C42.2060703@cs.columbia.edu> In-Reply-To: <40FC7C42.2060703@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 249cd1efd3d5e0d09114abe826a41235 Content-Transfer-Encoding: 7bit Cc: Simple WG Subject: [Simple] Re: Presence data model: devices X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f8ee348dcc4be4a59bc395f7cd6343ad Content-Transfer-Encoding: 7bit Thanks for articulating. Responses inline. Henning Schulzrinne wrote: > Let me try to formulate my concerns about devices somewhat less > flippantly than in my earlier rush mail. I'm probably missing pieces, > but we need to start somewhere. A fair treatment would probably require > another draft... > > I have the following concerns: > > (1) Devices in the data model draft don't correspond exactly to the > physical model that naive users have of a device. The data model states, > for example, that > > ... it is perfectly > acceptable to use this model to talk about that PC as being composed > of two separate devices. > > There does not appear to be any clear-cut rule that would allow a > presentity or watcher to decide whether a single physical device > consists of one or more logical or virtual devices. Let me try to clarify. As far as a watcher is concerned, "device" is a representation of a physically distinct entity that houses services. Now, as a presence server or publisher, I can map reality into that view anyway I like. If a user has a bluetooth device and a cell phone that it would like a watcher to see as separate, it would provide the watcher with two devices. If it wants the watcher to see them as one, it would provide one. In that regard, it is a *model* of reality, by trying to map reality into a notion of services and devices. Personal-area > network devices such as assemblies of BlueTooth gadgets pose similar > problems, as both a view as a single device or as individual devices are > reasonable. Right. And a presence server could represent them either way. Locally, we have created virtual multimedia devices that > consist of multiple pieces of plastic (a projector, a speakerphone, an > IP array microphone). They act exactly like one multimedia device in > most senses. Fine, you can do that too. > > (2) Devices have ill-defined properties that are implied, but not > stated, to the watcher. > > The only architectural motivational paragraph that I could find is in > Section 4: "Furthermore, the concept of device adds the ability to > correlate services together. The device models the underlying platform > that supports all of the services on the phone. Its state therefore > impacts all services." > > However, the types of states that are shared are implicit, not explicit. > Clearly, devices do not share *all* states across services. Fair enough. I think a further refinement would be that the device concept models those aspects of the device that are shared across services. Here are some in that category: geolocation on/off status CPU power memory screen capabilities If something is not shared across services that run on the device, you would not include it as part of your device characteristics. For every > possible state, there are plausible exceptions where services on the > device do *not* share that state. I gave a few examples, but the burden > is on the device proponent to prove that the watcher can unambiguously > determine which states are indeed shared and why such knowledge is > useful to the watcher. This is a good point, and that is why I would argue that, by deifnition, the device characteristics would be shared across services on that device. The likely case is that some states for some > services are shared for some devices, while others are not. (I'm > guessing that any reasonable device will have one shared location state, > at least at GPS resolution, but the example above shows that you can > violate even that assumption with a bit of forward thinking.) And when its no longer true, we can model it as multiple devices. > > I agree that state inference models are useful - the draft alludes to > that. However, many of these are probably best expressed as either local > rules at the composer, based on local knowledge available to the > composer, Ah. There is the rub. How does the composer obtain these "local rules". One of my strong motivations in proposing this way of modeling devices has come from experiences in building these things, where that whole process of correlating together these bits of information from various places is hard. Presence sources in the network, such as registrars, HLRs, IP PBXs, 802.11 APs and so on, each know a bit of information. Many of them know about devices (like the 802.11 ap, which knows about the mac address of my device), and some know about services too. Each of these has the ability to generate information about some aspect of the user. To correlate them together without this headache of provisioning and configuration, it would be great if we had a common, well understood way to include correlation identifiers. That way, when the HLR says, "this device is no longer registered", the compositor can know that, as a result, a whole bunch of services (namely, those which run on the device) are no longer available. Thus, I continue to maintain that watchers are NOT the only consumers of presence documents. PUAs, in form of PC clients, cell phones, HLRs, APs, and lots of other things, are also publishers of information, and this correlation is a key part of making it work. or as heuristics ("if my two mobile devices report two > different locations, pick my Brand X cell phone since I carry that to > job sites"; "if my cell phone service is reporting me as talking, mark > presentity status as busy"). And how should I correlate the information from the cell phone network about the presentity, without such identifiers?? > It is unclear how a watcher would benefit > from such decontextualized knowledge. > > (3) Some of the motivating assumptions are short-term or debatable. > > For many users, devices represent the ability > to communicate, not services. Frequently, users my statements like, > "call me on my cell phone" ... > > It is debatable that users actually want to refer to a device, even > though the current service=device abstraction encourages that. Right now, the world talks about devices. Are you saying that people don't say, "call my cell"? I say that all the time. My wife says it all the time. So do my coworkers. The reality is, that today, I believe that the vast majority of people think and talk in terms of devices. I want a system that is actually useful and meaningful today. If we deliver something that ignores a concept which is so prevalent today, and I suspect for years and years to come, I think we are doing the industry a disservice. Even tomorrow, I don't see the notion of device going away. And even if it does, fine. The model doesnt require devices to be present. As soon > as a service is available on multiple devices, users are just as likely > to say "call me on my 3G service". Well, when that day arrives some ten years hence, we can happily support that by simply electing to NOT include device information in the presence documents. The model does not mandate that you always indicate all of the information. Indeed, the notion of using a device ID as a link was based on the idea that I might often not want to say anything about the device, and just ratehr give the user the hint that these services were running on the same device, whatever it might be. Since a device in this model is not > reachable itself (it only has a URN that does not resolve), this device > notion can't actually be implemented by a user - the device tuple cannot > be used to actually call the device. That is not so. An implementation could show the user a picture of the devices - say, cell phone, PC, work phone. If you select the cell phone icon and hit "call" on your display, the implementation would go to the tuple which represents the cell phone, find all of the services which run on that phone, find the one which understands how to be called, and calls it. If, however, another implementation wants to render this as a list of services, and not even mention the device, it can do that too. > Thus, there is no functionality > gain and the user still has to use a service tuple, with caller prefs or > an explicitly labeled service, to do anything of use. Not so. As I say above, from the device, you would obtain the services, and then invoke the services. Caller prefs should not be needed in any model we come up with. If you want to > call the Nokia-made blue cell phone of mine, there has to be a service > tuple, with URI, that maps one-to-one to that device. Yes. I do buy the argument that it might not be useful to have presence documents that get published to watchers that include JUST devices, and no services. I think I may have even indicated somewhere that this was an open question. > If a service maps > to multiple devices, I can't actually call that one piece of plastic. Sure. That doesnt devalue the notion of a device. Just because some services might run on multiple devices, and just because the model allows me to represent that, does not mean it is not useful to support the ability to "make a call to a device". > > My proposal is simple: remove the notion of devices from the data model. > If there is a need to allow one-to-many references (e.g., one service > found at multiple locations due to uncertainties in where the presentity > is), we should have appropriate means to express this by value or by > reference for that particular service tuple and property. The device concept is, in fact, a way to represent that information by reference. > > I would like to see examples of services that significantly benefit from > adding devices and that cannot be similarly expressed by the > summarization model across service instances. (= a property that is > shared by all instances of a service or there there is at least one > instance that can be selected is shown.) Much of the correlation problems at a presence server, in performing composition, motivate the need to talk about devices. I've mentioned some of that above. From a watcher perspective (that is, an end user), I believe that end users are very much used to thinking today about devices as their focal point. Thats why devices have been part of our discussions over the years. The model allows that, and allows for documents to NOT talk about devices if they want. > > My basic contention is simplicity: we should have a minimalist data > model that cannot be reduced any further. The concept of device is not new. RPID is full of references to devices. The what-is-a-tuple discussions have talked about device, service and presentity views for a long time. All I am doing here is trying to put some meaning around that. The fact that these concepts have been with us all this time tells me that these ARE things people need. However, this "what is a tuple" problem has plagued us because these have not been properly defined and understood. I don't see how a proposal which tries to define them makes things more complicated. If we go forward with what we have today (that is, without the model I propose, or some kind of similar model), do you believe we will have interoperable systems? 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 Jul 20 23:06:00 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09136; Tue, 20 Jul 2004 23:06:00 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bn7Qx-0002ZC-M0; Tue, 20 Jul 2004 23:06:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bn6wV-0007c1-GZ; Tue, 20 Jul 2004 22:34:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bn3gr-0004j7-Jo for simple@megatron.ietf.org; Tue, 20 Jul 2004 19:06:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25209 for ; Tue, 20 Jul 2004 19:06:26 -0400 (EDT) Received: from hostree27.alcatel.com ([143.209.238.39] helo=auds959.usa.alcatel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bn3h5-0006y7-TA for simple@ietf.org; Tue, 20 Jul 2004 19:06:44 -0400 Received: from alcatel.com (localhost [127.0.0.1]) by auds959.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id i6KN5iHB000453; Tue, 20 Jul 2004 18:05:44 -0500 (CDT) Message-ID: <40FDA546.D434A114@alcatel.com> Date: Tue, 20 Jul 2004 18:05:42 -0500 From: Alex Audu X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Simple] New I-D: presence data model and its relationship to ourpresence work References: <40F2EB3D.6080104@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Content-Transfer-Encoding: 7bit Cc: Simple WG 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-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Content-Transfer-Encoding: 7bit Hello Jonathan, After reading your simple-presence-data-model- draft, it occured to me that the definition of a presentity could be broadened out more than it currently is to mean: Model of information about a "user" whom the presence data is trying to describe. The "user" could be a person, (place) or thing. The information consists of an identifier for the presentity, its characteristics, status, and capabilities. The only thing that is being brought out here is the "capability" part. This describes what the presentity is capable of doing. In other words, the "service" it can render. A person can render a certain type of service,..and so can devices or systems, or a place. For example, the hospital renders a healing service. Any comments? Regards, Alex. Jonathan Rosenberg wrote: > Folks, > > I've just submitted an I-D on a presence data model for SIMPLE, which > will appear shortly in the archives. Until then, you can pick it up from: > > http://www.jdrosen.net/papers/draft-rosenberg-simple-presence-data-model-00.txt > > This I-D is a further elaboration on the model I discussed at the > interim, and it further analyzes the meaning of operations like > composition, publication, and filtering as they relate to the data > model. Composition in particular gets a lot of discussion, since its > fundamentally about manipulating presence data, and then is intimately > related with the presence data model. The document distills a lot of > concepts that have been discussed over the years of this group, which > have afaik remain undocumented (for example, Henning's pivot operations, > and the presence server processing flow that we discussed on the list > some months back). > > After writing this, I had a lot more clarity in my mind about how all of > our presence work fit together, and an particular, I feel that it > answers the question of "what is a tuple" in a sufficiently clear way > that we can have some interoperability of presence document > interpretation across implementations. > > The document proposes a concrete plan of attack for how this data model > affects our ongoing work. Mostly its minor changes to the presence > related documents. > > I'd like to try and see if we can agree on the following points: > > 1. the data model makes sense, > 2. the data model gives people the flexibility they need to represent > the systems they are interested in, > 3. the data model makes it sufficiently clear about what a tuple is to > create interoperable presence systems, > 4. the plan of attack makes sense given the previous 3 > > Comments in any of these four categories are most welcome. > > I'll be starting some other threads, and in particular, responding to > Henning's recent note, and referring to some of the concepts described > in here as part of the discussion. > > As such, the main point of this note is really to encourage people to > please take a look at this document. At this point, I feel that we are > really stuck on resolving this "what is a tuple" question in order to > produce a coherent set of specs. In as much as I hope this document > unstucks us, I think its a key part of moving forward. Please take a > look and comment. > > 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 Tue Jul 20 23:22:28 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11283; Tue, 20 Jul 2004 23:22:28 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bn7gt-0002zu-EC; Tue, 20 Jul 2004 23:22:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bn7DM-0004fz-40; Tue, 20 Jul 2004 22: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 1Bn6qK-00085r-3Y for simple@megatron.ietf.org; Tue, 20 Jul 2004 22:28:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02506 for ; Tue, 20 Jul 2004 22:28:25 -0400 (EDT) Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bn6qV-0000UQ-9F for simple@ietf.org; Tue, 20 Jul 2004 22:28:44 -0400 Received: from dynamicsoft.com ([63.113.46.5]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i6L2S8Gr006879; Tue, 20 Jul 2004 22:28:09 -0400 (EDT) Message-ID: <40FDD4A5.3010900@dynamicsoft.com> Date: Tue, 20 Jul 2004 22:27: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: alex.audu@alcatel.com Subject: Re: [Simple] New I-D: presence data model and its relationship to ourpresence work References: <40F2EB3D.6080104@dynamicsoft.com> <40FDA546.D434A114@alcatel.com> In-Reply-To: <40FDA546.D434A114@alcatel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 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-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit inline. Alex Audu wrote: > Hello Jonathan, > > After reading your simple-presence-data-model- draft, it occured to me that the > definition > of a presentity could be broadened out more than it currently is to mean: > > Model of information about a "user" whom the presence data is trying to > describe. > The "user" could be a person, (place) or thing. The information consists of an > identifier > for the presentity, its characteristics, status, and capabilities. > > The only thing that is being brought out here is the "capability" part. This > describes > what the presentity is capable of doing. In other words, the "service" it can > render. > A person can render a certain type of service,..and so can devices or systems, > or a place. > For example, the hospital renders a healing service. > > Any comments? I'm not really sure I follow. The rest of the presence document will contain information on communications services and devices, which are about the communications capabilities of a person. Thats what our target application is for presence. I don't quite see how this is extended to 'hospitals rendering healing services'. -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 Jul 20 23:38:37 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12949; Tue, 20 Jul 2004 23:38:37 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bn7wX-0003OA-6f; Tue, 20 Jul 2004 23:38:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bn7hZ-0000PX-I5; Tue, 20 Jul 2004 23: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 1Bn7Ij-0007Td-7B for simple@megatron.ietf.org; Tue, 20 Jul 2004 22:57:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08497 for ; Tue, 20 Jul 2004 22:57:46 -0400 (EDT) Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bn7Iz-0002Qy-LU for simple@ietf.org; Tue, 20 Jul 2004 22:58:05 -0400 Received: from dynamicsoft.com ([63.113.46.5]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i6L2vPGr006913; Tue, 20 Jul 2004 22:57:25 -0400 (EDT) Message-ID: <40FDDB81.10307@dynamicsoft.com> Date: Tue, 20 Jul 2004 22:57:05 -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] Presence data model: devices References: <40FC7C42.2060703@cs.columbia.edu> <40FD48A3.BE4EA775@alcatel.com> <40FD4B73.4060009@cs.columbia.edu> In-Reply-To: <40FD4B73.4060009@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Content-Transfer-Encoding: 7bit Cc: alex.audu@alcatel.com, 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-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Content-Transfer-Encoding: 7bit I think my reply to your initial post covered most of what I would otherwise say throughout the thread, but to emphasize here: Henning Schulzrinne wrote: > >> "can you call me back on my land-line phone? I can't hear you very >> well on >> this >> cell phone". > > > None of this requires a device abstraction. The caller can only choose > the mobility modality if > > (1) there are two separate service entries (one stationary, one mobile) > > or > > (2) there is one service entry and the caller uses caller preferences > that the callee chooses to honor. > > Neither requires nor benefits from a device tuple. (Devices tuples > cannot be contacted directly.) > > In many cases, we'll have a single watcher-visible modality that > encompasses multiple devices. For example, on trips to Europe, I carry > both my GSM phone (works in both places) and my CDMA phone (works in > only one, but is cheaper). Great example. Let me give you a case for something I dont know how to do without the notion of a device. You have two phones, this CDMA and GSM one. Lets say they both work (i.e., you are in the U.S). Your presence document indicates a voice service and a SIP messaging service on the GSM phone, and an sms service on the CDMA phone. Lets say I'm talking to you on your GSM phone, which is low on power. While talking, you say, "hey, can you send me a message, but send it to me other phone since I am about to run out of ...." and at that moment, the call ends since power is out. I want to send you a message now, but not to the gsm phone. I have no way to know which of the two messaging services is accessible on that phone, or another phone, without device information. Indeed, a convenient user interface would show user "henning" with two device icons, each a cell phone. Perhaps one has "gsm" inside, and the other "cdma" (again, these are DEVICE characteristics). So, if you say to someone, "call my gsm", it becomes very easy for me, or anyone else, to call it, or PTT it, or sms it, or access any of the other services avaialble on it. Without a device concept, I can't do that. It is true that, in this case, device ID will suffice. However, the device has characteristics and status that are independent of the services; and placing them into the service causes unneeded repitition and lack of clarity about what they apply to. These characteristics ARE about the device; putting them into service is artificial. I want the caller to reach my mobile service, > but don't necessarily want to have to expose the devices as that's none > of the caller's business. Well, thats OK. There is nothing that says you HAVE to report on your devices if you don't want to. If you want to just indicate services to the watcher thats fine. Thus, I need the ability to declare a mobile > *service* (which is then routed according to my service preferences to > one of my phones, e.g., depending on how much an incoming call is going > to cost me.) [The proposed model allows this, as far as I can tell, so > no disagreement here.] Right. The point is, the model I am proposing represents what seems to me, to be the minimum of the concepts we've been talking about and assuming all along. -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 Jul 20 23:55:39 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14019; Tue, 20 Jul 2004 23:55:39 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bn8D1-0003aH-F0; Tue, 20 Jul 2004 23:55:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bn7pk-0001db-L0; Tue, 20 Jul 2004 23:31:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bn7bU-0004ea-UK for simple@megatron.ietf.org; Tue, 20 Jul 2004 23:17:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10654 for ; Tue, 20 Jul 2004 23:17:09 -0400 (EDT) Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bn7bl-0002qH-0C for simple@ietf.org; Tue, 20 Jul 2004 23:17:29 -0400 Received: from dynamicsoft.com ([63.113.46.5]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i6L3GqGr006918; Tue, 20 Jul 2004 23:16:52 -0400 (EDT) Message-ID: <40FDE010.7070909@dynamicsoft.com> Date: Tue, 20 Jul 2004 23:16: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: Henning Schulzrinne Subject: Re: [Simple] Presence data model: devices References: <2038BCC78B1AD641891A0D1AE133DBB7023EEB47@esebe019.ntc.nokia.com> <40FD209A.9060009@cs.columbia.edu> In-Reply-To: <40FD209A.9060009@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 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-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Content-Transfer-Encoding: 7bit inline. Henning Schulzrinne wrote: > I don't see how a device ID helps at all. There are two cases, depending > on the mapping: > > - A particular service maps to exactly one device. In that case, the > properties of the device (speed, display size, media capabilities, etc.) > are part of the service - for that service at that time, you only get > those characteristics. Since many of the characteristics are indeed > determined by the capabilities of the service provider and the service > plan chosen by the user, not the piece of plastic in the user's pocket, > the service-device distinction seems arbitrary. For the one device/one service case, if that was the only case, I agree the separation has little meaning. > > - A particular service maps to multiple devices, forking-style. In that > case, the only advantage of having device tuples is that it allows you > to enumerate the possible end points where your call might end up. You > don't get a choice (although caller preferences might give you input), > but you might get a hint. This, I believe, is however, much better coded > as an enumeration of service capabilities as they are as likely to be > constrained by the service offering as by the piece of plastic. There are other benefits. If my presence server receives information that says that the service runs on multiple devices, and it separately learns that one device fails, it can know that the service is still available. From a watcher perspective, I think it helps in selecting. Lets say I have a messaging service which I see runs on a mobile device and a fixed device, and a voice service on a fixed device. If I know you are traveling, I might be inclined to use the messaging service, since there is the possibility you can be reached. You've missed the third, key case, though: - A particular device maps to multiple services Now, this one is really interesting for both watchers and presence servers as consumers. For watchers, it allows you infer important correlation that can help you make a choice. Some examples: * Jon told me to contact him on his cell. I see that his cell has sms and voice, but his voice service reports its busy. So I'll send him an sms to that phone * Jon is PTTing with me. The quality stinks. He says, "go circuit". I'd like to call him back on the circuit voice on the same device his PTT service is on (since I know he's got that). * Bob and I are talking. I see from his presence doc that he has a videophone app on the same PC running his voice softphone app. I want to also use video to talk to him. His softphone doesnt do video, so a reinvite won't help. His pres doc indicates two video devices - one is on his PC as well, another is a hard videophone somewhere else. Since I know he's at the PC with the softphone, I contact the videophone on the PC too. I am sure there are many others. > > As mobile devices become basically multi-tasking pocket PCs with a > screen that is as large as PC screens were about five years ago, it > seems increasingly dubious to rely on classifications that might have > been vaguely helpful in a single-line, single-purpose world of the > Motorola StarTAC. How is your multi-tasking pocket PC not a device? "device" is not some short lived concept. There are always going to be devices. In fact, the more powerful they get, the more services can run on them, and the more interesting the ability to correlate those services, and extract common information, becomes. -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 Jul 21 00:03:57 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14630; Wed, 21 Jul 2004 00:03:57 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bn8L3-0003vY-R9; Wed, 21 Jul 2004 00:04:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bn8D8-0006ag-JO; Tue, 20 Jul 2004 23:56:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bn7r4-0001yX-5l for simple@megatron.ietf.org; Tue, 20 Jul 2004 23:33:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12584 for ; Tue, 20 Jul 2004 23:33:15 -0400 (EDT) Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bn7rK-0003JL-VJ for simple@ietf.org; Tue, 20 Jul 2004 23:33:35 -0400 Received: from dynamicsoft.com ([63.113.46.5]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i6L3KYGr006924; Tue, 20 Jul 2004 23:20:34 -0400 (EDT) Message-ID: <40FDE0EE.3000603@dynamicsoft.com> Date: Tue, 20 Jul 2004 23:20: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: Paul Kyzivat Subject: Re: [Simple] Address and person URIs References: <40F97472.7030006@cs.columbia.edu> <40FBCF13.8010308@dynamicsoft.com> <40FC2731.3080801@cisco.com> <40FC40D8.3090103@cs.columbia.edu> <40FC5C50.2080708@cisco.com> In-Reply-To: <40FC5C50.2080708@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 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-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Content-Transfer-Encoding: 7bit I'm fine to punt, but I think this is a case where the perfect is a serious enemy of the good. I think that a service URI of the form: uri:inperson is sufficient, without any additional per-user data. We can leave it to the human to figure out how to resolve the URI. Indeed, the presentity placetype (home, work, etc.) would probably suffice, since a watcher can ususally infer how to find them within that place. We just need a way to say, "come talk to me". Does that cover EVERY case? No way. Does it cover many of the important ones? Yes. -Jonathan R. Paul Kyzivat wrote: > > > Henning Schulzrinne wrote: > >>> >>> Well, a place isn't always sufficient. We see this all the time in >>> the movies: "Meet me in the bar of tha Acme Hotel at 7pm on April 1, >>> 2005. I'll have a red carnation in my lapel." >> >> >> I suspect that one of the desirable properties would be that the >> person doesn't change identifiers just because they changed location. >> If you don't do that, it will get very confusing - is this URI the >> same person at a different location or a completely different person? >> (Imagine a friend finder service that works in physical space.) >> >> There is also the issue that you now have two ways to represent >> "location of a presentity", as a URI or as PIDF-LO, with contact >> information also available as a vCard. >> >>> So we don't need a *globally* unique person identifier. We need a >>> person identifier that is locally unique in the context of the time >>> and location of the intended meeting. And the time is important too. >>> >>> The time we can deal with. With regular status it is NOW. We can use >>> timed-status to cover some other time. >>> >>> I don't think location has to be part of the Contact, as long as it >>> is provided as part of the (timed-)status along with the contact. >>> >>> Coming up with URIs for identifying people locally within a >>> particular time-space region sounds like future research. Sounds like >>> some sort of arbitary predicate would do the trick. >> >> >> Do you want to define people by a game of twenty questions? > > > Well, it would be easier if everyone just agreed to have a barcode > branded on their forehead and an RFID chip embedded in them, each > containing their UN assigned global person UUID. > > But I sense a lot of people don't want to be so easily or irrevokably > identifiable. So weak forms of identification may be all that is > generally acceptable. (Hence "I'll have a red carnation in my lapel" > rather than "The SSN on my forehead will be 123-56-7890.") > > Unfortunately, this doesn't lend itself well to URIs or URNs, because > the information isn't Unique. > > I think we continue to punt this one for now. > > Paul > -- 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 Jul 21 00:17:45 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15435; Wed, 21 Jul 2004 00:17:45 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bn8YP-00047o-Ep; Wed, 21 Jul 2004 00:18:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bn8Us-0002QM-BM; Wed, 21 Jul 2004 00:14:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bn8Gg-0000fb-4E for simple@megatron.ietf.org; Tue, 20 Jul 2004 23:59:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14442 for ; Tue, 20 Jul 2004 23:59:43 -0400 (EDT) Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bn8Gx-0003f1-4z for simple@ietf.org; Wed, 21 Jul 2004 00:00:03 -0400 Received: from dynamicsoft.com ([63.113.46.5]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i6L3xYGr006966; Tue, 20 Jul 2004 23:59:34 -0400 (EDT) Message-ID: <40FDEA12.3040702@dynamicsoft.com> Date: Tue, 20 Jul 2004 23:59: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: "Vijay K. Gurbani" Subject: Re: [Simple] New I-D: presence data model and its relationship to our presence work References: <40F2EB3D.6080104@dynamicsoft.com> <40F558A8.3010905@lucent.com> In-Reply-To: <40F558A8.3010905@lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Content-Transfer-Encoding: 7bit Cc: IETF 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-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Content-Transfer-Encoding: 7bit Thanks for the comments, Vijay. Sorry for the delay in responding. More inline. Vijay K. Gurbani wrote: > To me, a presentity has always corresponded to a human (or a > group of humans, as in a call center); it is the presence > state of the human we are trying to model, not the devices > commanded by it. Unfortunately, in current usage, a > presentity can be anything -- a VM server, a bot, a person, > and so on. In think your model is closer to a presentity > being a user. The model says that there is something called a presentity, and the attributes we ascribe to it are ones more typically associated with a human user. That doesnt preclude you from trying to model a bot or a VM server with it. You may just find that the model comes up short. I think thats OK. If we tried to accurately and completely model all of the communications systems out there, we would never be done and never do anything actually useable. > (1) You note (in Section 5) that "The terminlogy here is > confusing: we talk about the presentity as a data element > and the presentity as the entire thing being modeled..." > What if we used the term "actor" for the entire thing being > modeled? As in, "The entity attribute in the > element is always present, and identifies the > actor described in the document." > Other terms: target, principal, addressee I tend to prefer calling the whole thing presentity, primarily because that is closest in alignment with the model that rfc2778 presents. I think that the "inside" thing currently called presentity could be called something else; "user" is, itself, not a bad choice, since it conveys the most common case. > > (2) In Section 2 (Definitions), the primary difference > between "Privacy Filtering" and "Watcher Filtering" > appears to be who is requesting the filter to be applied. Yes. > The watcher is in the latter, and the presentity is in > the former. Mostly. Other interested parties can provide privacy rules - the operator, for example, or a group. For example, my enterprise my have something to say about what information gets distributed. While you explicitly mention the watcher > when discussing "Watcher Filtering", maybe you should > also mention the presentity when discussing "Privacy > Filtering." I will add some text on who provides these filters. > > (3) Page 9, s/offering a choice to the presentity/offering > a choice to the watcher/ fixed, thanks. > > Thanks for compiling this. It distills in a clear fashion > a lot of ideas we have discussed on the WG mailing list. 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 Wed Jul 21 03:42:50 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24905; Wed, 21 Jul 2004 03:42:50 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BnBkj-0006Fq-Hy; Wed, 21 Jul 2004 03:43:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BnBg0-0001Xx-Qm; Wed, 21 Jul 2004 03:38:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BnBai-0007ae-GO; Wed, 21 Jul 2004 03:32:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24373; Wed, 21 Jul 2004 03:32:38 -0400 (EDT) Received: from albatross.ericsson.se ([193.180.251.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BnBaq-00068q-4Z; Wed, 21 Jul 2004 03:32:59 -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 i6L7WRWR002172; Wed, 21 Jul 2004 09:32:27 +0200 (MEST) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Wed, 21 Jul 2004 09:32:27 +0200 Received: from mail.lmf.ericsson.se (dossier.lmf.ericsson.se [131.160.11.13]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 32RBNMH2; Wed, 21 Jul 2004 09:32:23 +0200 Received: from ericsson.com (EFO9N000L5C7100.lmf.ericsson.se [131.160.31.157]) by mail.lmf.ericsson.se (Postfix) with ESMTP id F36F618AA2; Wed, 21 Jul 2004 10:32:16 +0300 (EEST) Message-ID: <40FE1C00.9040206@ericsson.com> Date: Wed, 21 Jul 2004 10:32:16 +0300 X-Sybari-Trust: 2eee6654 100f6658 4e60b4b8 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: SIMPLE mailing list , XCON Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Jul 2004 07:32:27.0417 (UTC) FILETIME=[DF829890:01C46EF4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit Subject: [Simple] [Fwd: WG last call: draft-ietf-mmusic-sdp-comedia-08.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-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: 7bit Folks, note that I am cross posting XCON and SIMPLE, but that responses to this email should be sent to MMUSIC. This is to inform you that the connection-oriented media for SDP (a.k.a. comedia) draft is under WG LC. Some of the mechanisms in this draft, such as the setup and connid attributes, may be of interest of MSRP and BFCP; so, I suggest you have a look at it and provide comments, should you have them. Thanks, Gonzalo -------- Original Message -------- Subject: WG last call: draft-ietf-mmusic-sdp-comedia-08.txt Date: Tue, 20 Jul 2004 17:46:34 +0100 From: Colin Perkins To: mmusic (E-mail) CC: yon@dialout.net, Gonzalo Camarillo , Joerg Ott References: <200407191954.PAA19379@ietf.org> This is to announce a working group last call on the comedia draft. Please send any final comments on this draft to the mailing list by 4 August 2004. If there are no substantive issues raised by that time, we will request the IESG consider this for publication as a proposed standard RFC. Colin On 19 Jul 2004, at 20:54, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Multiparty Multimedia Session Control > Working Group of the IETF. > > Title : Connection-Oriented Media Transport in the > Session Description Protocol (SDP) > Author(s) : D. Yon, G. Camarillo > Filename : draft-ietf-mmusic-sdp-comedia-08.txt > Pages : 13 > Date : 2004-7-19 > > This document describes how to express media transport over > connection-oriented protocols using the Session Description Protocol > (SDP). It defines the SDP TCP protocol identifier, the SDP setup > attribute, which describes the connection setup procedure, and the > SDP connid attribute, which provides a connection identifier. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-comedia > -08.txt _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jul 21 04:11:55 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26633; Wed, 21 Jul 2004 04:11:55 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BnCD1-0006oi-A0; Wed, 21 Jul 2004 04: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 1BnBt7-0000io-SJ; Wed, 21 Jul 2004 03:51:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BnBjb-0002ch-JR for simple@megatron.ietf.org; Wed, 21 Jul 2004 03:41:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24853 for ; Wed, 21 Jul 2004 03:41:49 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BnBju-0006FL-Fa for simple@ietf.org; Wed, 21 Jul 2004 03:42:10 -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 i6L7fUv13999; Wed, 21 Jul 2004 10:41:30 +0300 (EET DST) X-Scanned: Wed, 21 Jul 2004 10:41:03 +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 i6L7f3aA011189; Wed, 21 Jul 2004 10:41:03 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00KDVa05; Wed, 21 Jul 2004 10:41:02 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 i6L7euu05149; Wed, 21 Jul 2004 10:40:57 +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, 21 Jul 2004 10:40:56 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 21 Jul 2004 10:40:56 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [Simple] Presence data model: devices Date: Wed, 21 Jul 2004 10:40:55 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7023EEB53@esebe019.ntc.nokia.com> Thread-Topic: [Simple] Presence data model: devices Thread-Index: AcRujK0MYxqaUCNwRRyqH0OC7ux2mQAaSB5A To: X-OriginalArrivalTime: 21 Jul 2004 07:40:56.0349 (UTC) FILETIME=[0EDB74D0:01C46EF6] X-Spam-Score: 0.3 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: quoted-printable Cc: jdrosen@dynamicsoft.com, 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-Score: 0.3 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: 20.July.2004 21:39 > To: Khartabil Hisham (Nokia-TP-MSW/Helsinki) > Cc: hgs@cs.columbia.edu; jdrosen@dynamicsoft.com; simple@ietf.org > Subject: Re: [Simple] Presence data model: devices >=20 >=20 >=20 >=20 > hisham.khartabil@nokia.com wrote: > >=20 > >>- A particular service maps to multiple devices,=20 > >>forking-style. In that=20 > >>case, the only advantage of having device tuples is that it=20 > >>allows you=20 > >>to enumerate the possible end points where your call might=20 > >>end up. You=20 > >>don't get a choice (although caller preferences might give=20 > >>you input),=20 > >>but you might get a hint. This, I believe, is however, much=20 > >>better coded=20 > >>as an enumeration of service capabilities as they are as=20 > likely to be=20 > >>constrained by the service offering as by the piece of plastic. > >=20 > > A GRUU guarantees where a request will end up. > > You are making the assumption that tuples for the same service > > will get merged. >=20 > Henning was enumerating the cases. This one case assumes the service=20 > forks to multiple devices. If there is indeed to be presence=20 > information=20 > from each of those then yes, presumably it is being merged. >=20 > He covered the other cases as well. >=20 > > I'm not making that assumption. > > My watchers will see 2 tuples for the same service if they get > > published by different PUAs. Each tuple will have a GRUU. >=20 > Then by the terminology we are using here, they are two different=20 > services, not one. I don't agree here. They are the same service. You can communicate with = me in exactly the same fassion. Are you telling me that the IM on one = device is not the same service as IM on another? A service does not equal a device. /Hisham >=20 > > It will then be helpful to have device characteristics for that > > service and the GRUU will get you to that device. >=20 > Because they are separate services, we are back at the=20 > degenerate case=20 > where service =3D device, and "device characteristics" can be=20 > associated=20 > with the service. >=20 > Paul >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jul 21 13:49:36 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07772; Wed, 21 Jul 2004 13:49:36 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BnLE9-0006MQ-Hi; Wed, 21 Jul 2004 13:50:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BnKzS-0008Mf-KB; Wed, 21 Jul 2004 13:34:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BnKsP-00008E-2Y for simple@megatron.ietf.org; Wed, 21 Jul 2004 13:27:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05822 for ; Wed, 21 Jul 2004 13:27:29 -0400 (EDT) Received: from auds952.usa.alcatel.com ([143.209.238.7]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BnKsk-00064S-6z for simple@ietf.org; Wed, 21 Jul 2004 13:27:57 -0400 Received: from alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id i6LHQo1t020175; Wed, 21 Jul 2004 12:26:51 -0500 (CDT) Message-ID: <40FEA759.5D142758@alcatel.com> Date: Wed, 21 Jul 2004 12:26:49 -0500 From: Alex Audu X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Simple] New I-D: presence data model and its relationship toourpresence work References: <40F2EB3D.6080104@dynamicsoft.com> <40FDA546.D434A114@alcatel.com> <40FDD4A5.3010900@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: 7bit Cc: Simple WG 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-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: 7bit Hi Jonathan, The example with the "hospital rendering healing service" may not apply to our immediate mandate,..but the point I was trying to make was that the notion of a presentity could could be applicable to a much broader case if it is realized that a presentity could represent a person, place or thing (sort of like a noun). Now, an object (both animate and inanimate) has a capability attribute. This is nothing more than the service the object can render. So we have: A Presentity contains the following attrributes: - characteristics (hard state info) - Status (dynamic/soft state info) (including activciy, mood, location, etc) - Capability (service it can render) I am just curious as to what effect, if any, this has on the ongoing debate about service and device. Regards, Alex. Jonathan Rosenberg wrote: > inline. > > Alex Audu wrote: > > > Hello Jonathan, > > > > After reading your simple-presence-data-model- draft, it occured to me that the > > definition > > of a presentity could be broadened out more than it currently is to mean: > > > > Model of information about a "user" whom the presence data is trying to > > describe. > > The "user" could be a person, (place) or thing. The information consists of an > > identifier > > for the presentity, its characteristics, status, and capabilities. > > > > The only thing that is being brought out here is the "capability" part. This > > describes > > what the presentity is capable of doing. In other words, the "service" it can > > render. > > A person can render a certain type of service,..and so can devices or systems, > > or a place. > > For example, the hospital renders a healing service. > > > > Any comments? > > I'm not really sure I follow. The rest of the presence document will > contain information on communications services and devices, which are > about the communications capabilities of a person. Thats what our target > application is for presence. I don't quite see how this is extended to > 'hospitals rendering healing services'. > > -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 Jul 21 14:12:07 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08990; Wed, 21 Jul 2004 14:12:06 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BnLZw-0006YP-63; Wed, 21 Jul 2004 14:12:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BnLSo-0000il-34; Wed, 21 Jul 2004 14:05:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BnLIb-0006Fw-IQ for simple@megatron.ietf.org; Wed, 21 Jul 2004 13:54:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08008 for ; Wed, 21 Jul 2004 13:54:36 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BnLIy-0006OH-Vx for simple@ietf.org; Wed, 21 Jul 2004 13:55:02 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 21 Jul 2004 13:59:08 -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 i6LHs2GX028793; Wed, 21 Jul 2004 13:54:02 -0400 (EDT) Received: from cisco.com ([161.44.79.221]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKH01065; Wed, 21 Jul 2004 13:54:01 -0400 (EDT) Message-ID: <40FEADB8.7020607@cisco.com> Date: Wed, 21 Jul 2004 13:54: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: Jonathan Rosenberg Subject: Re: [Simple] Presence data model: devices References: <40FC7C42.2060703@cs.columbia.edu> <40FD48A3.BE4EA775@alcatel.com> <40FD4B73.4060009@cs.columbia.edu> <40FDDB81.10307@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit Cc: alex.audu@alcatel.com, 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-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit Jonathan, There is one point in here that I want to comment on... Paul Jonathan Rosenberg wrote: > > You have two phones, this CDMA and GSM one. Lets say they both work > (i.e., you are in the U.S). Your presence document indicates a voice > service and a SIP messaging service on the GSM phone, and an sms service > on the CDMA phone. Lets say I'm talking to you on your GSM phone, which > is low on power. While talking, you say, "hey, can you send me a > message, but send it to me other phone since I am about to run out of > ...." and at that moment, the call ends since power is out. I want to > send you a message now, but not to the gsm phone. I have no way to know > which of the two messaging services is accessible on that phone, or > another phone, without device information. > > Indeed, a convenient user interface would show user "henning" with two > device icons, each a cell phone. Perhaps one has "gsm" inside, and the > other "cdma" (again, these are DEVICE characteristics). So, if you say > to someone, "call my gsm", it becomes very easy for me, or anyone else, > to call it, or PTT it, or sms it, or access any of the other services > avaialble on it. Without a device concept, I can't do that. As long as the data model has a many:many relationship between services and devices there is going to be a problem deciding what is the best, most convenient, user model. Most of the user models of this sort of thing are tree oriented one way or another. A many:many model has to be unwound using repetition to be displayed as a tree. So either the top level view can be devices, with services within and possibly replicated, or else the top level can be services, with devices within, possibly replicated. The case you describe, while real, is a fairly obscure one. I think it would be sufficient to have the service view, and for each service to list the associated device(s). This need to replicate would be simpler if the device is simply an attribute rather than a separate item that has state that also needs to be replicated. (Of course another UI might show services and devices at the same level, with cross references between them, but that doesn't sound like a very appealing UI.) Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jul 21 14:20:16 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09687; Wed, 21 Jul 2004 14:20:16 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BnLho-0006f4-NQ; Wed, 21 Jul 2004 14:20:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BnLbu-0003OW-LK; Wed, 21 Jul 2004 14:14:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BnLWW-0001Gu-NN for simple@megatron.ietf.org; Wed, 21 Jul 2004 14:09:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08791 for ; Wed, 21 Jul 2004 14:08:59 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BnLWv-0006WV-Bw for simple@ietf.org; Wed, 21 Jul 2004 14:09:25 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 21 Jul 2004 14:08:30 -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 i6LI8SP9012437; Wed, 21 Jul 2004 14:08:28 -0400 (EDT) Received: from cisco.com ([161.44.79.221]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKH02540; Wed, 21 Jul 2004 14:08:25 -0400 (EDT) Message-ID: <40FEB118.9070707@cisco.com> Date: Wed, 21 Jul 2004 14:08:24 -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] Presence data model: devices References: <2038BCC78B1AD641891A0D1AE133DBB7023EEB53@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit Cc: jdrosen@dynamicsoft.com, 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-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > >> > You are making the assumption that tuples for the same service >> > will get merged. >> >>Henning was enumerating the cases. This one case assumes the service >>forks to multiple devices. If there is indeed to be presence >>information >>from each of those then yes, presumably it is being merged. >> >>He covered the other cases as well. >> >> > I'm not making that assumption. >> > My watchers will see 2 tuples for the same service if they get >> > published by different PUAs. Each tuple will have a GRUU. >> >>Then by the terminology we are using here, they are two different >>services, not one. > > I don't agree here. They are the same service. > You can communicate with me in exactly the same fassion. > Are you telling me that the IM on one device is not the > same service as IM on another? Yes. You don't communicate in exactly the same fashion - you use a different address for one than the other. Jonathan't data model explicitly states that the contact address serves as a UID for each service. > A service does not equal a device. Agreed. As Jonathan has described, there can be a many:many relationship between services and devices. But when a service is associated with multiple devices it still must have a single address. Behind the scenes it may fork to one or the other of those devices, but to the watcher, to be a single service, it must have a single address. If this were not the case, then either a tuple describing a service would require multiple contacts (not permitted) or else it would be necessary to have multiple tuples describing (aspects of) the same service. Jonathan's data model explicitly jetisons that approach. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jul 21 14:26:56 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10332; Wed, 21 Jul 2004 14:26:55 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BnLoI-0006lx-D6; Wed, 21 Jul 2004 14:27:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BnLkt-00060d-2x; Wed, 21 Jul 2004 14:23:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BnLfb-0004Tg-00 for simple@megatron.ietf.org; Wed, 21 Jul 2004 14:18:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09552 for ; Wed, 21 Jul 2004 14:18:21 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BnLfz-0006df-O9 for simple@ietf.org; Wed, 21 Jul 2004 14:18:48 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 21 Jul 2004 14:22:55 -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 i6LIHnGX002774; Wed, 21 Jul 2004 14:17:50 -0400 (EDT) Received: from cisco.com ([161.44.79.221]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKH03501; Wed, 21 Jul 2004 14:17:49 -0400 (EDT) Message-ID: <40FEB34D.2030400@cisco.com> Date: Wed, 21 Jul 2004 14:17: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: Jonathan Rosenberg Subject: Re: [Simple] Presence data model: devices References: <2038BCC78B1AD641891A0D1AE133DBB7023EEB47@esebe019.ntc.nokia.com> <40FD209A.9060009@cs.columbia.edu> <40FDE010.7070909@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit Cc: simple@ietf.org, 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-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > There are other benefits. > > If my presence server receives information that says that the service > runs on multiple devices, and it separately learns that one device > fails, it can know that the service is still available. > > From a watcher perspective, I think it helps in selecting. Lets say I > have a messaging service which I see runs on a mobile device and a fixed > device, and a voice service on a fixed device. If I know you are > traveling, I might be inclined to use the messaging service, since there > is the possibility you can be reached. > > You've missed the third, key case, though: > > > - A particular device maps to multiple services > > Now, this one is really interesting for both watchers and presence > servers as consumers. > > For watchers, it allows you infer important correlation that can help > you make a choice. Some examples: > > * Jon told me to contact him on his cell. I see that his cell has sms > and voice, but his voice service reports its busy. So I'll send him an > sms to that phone > > * Jon is PTTing with me. The quality stinks. He says, "go circuit". I'd > like to call him back on the circuit voice on the same device his PTT > service is on (since I know he's got that). All of the above work just as well if service tuples contain device id(s) for purposes of correlation, without any separate device state. > * Bob and I are talking. I see from his presence doc that he has a > videophone app on the same PC running his voice softphone app. I want to > also use video to talk to him. His softphone doesnt do video, so a > reinvite won't help. His pres doc indicates two video devices - one is > on his PC as well, another is a hard videophone somewhere else. Since I > know he's at the PC with the softphone, I contact the videophone on the > PC too. As an example it works, but it seems far fetched. Since a video phone should be able to do voice-only calls, why would you want to run both a voice-only softphone and a soft-video-phone on the same PC at the same time? (Among other problems, they will have to compete for the audio resources of the PC, so they can't both be in a call at the same time.) Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jul 21 14:29:39 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10498; Wed, 21 Jul 2004 14:29:39 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BnLqv-0006nu-2S; Wed, 21 Jul 2004 14:30:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BnLlJ-000622-Jx; Wed, 21 Jul 2004 14:24:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BnLhv-0005Eq-4j for simple@megatron.ietf.org; Wed, 21 Jul 2004 14:20:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09714 for ; Wed, 21 Jul 2004 14:20:45 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BnLiJ-0006f7-TO for simple@ietf.org; Wed, 21 Jul 2004 14:21:12 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 21 Jul 2004 14:25: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 i6LIKEP9014502; Wed, 21 Jul 2004 14:20:14 -0400 (EDT) Received: from cisco.com ([161.44.79.221]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKH03752; Wed, 21 Jul 2004 14:20:12 -0400 (EDT) Message-ID: <40FEB3DC.3050104@cisco.com> Date: Wed, 21 Jul 2004 14:20:12 -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] Address and person URIs References: <40F97472.7030006@cs.columbia.edu> <40FBCF13.8010308@dynamicsoft.com> <40FC2731.3080801@cisco.com> <40FC40D8.3090103@cs.columbia.edu> <40FC5C50.2080708@cisco.com> <40FDE0EE.3000603@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 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-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > I'm fine to punt, but I think this is a case where the perfect is a > serious enemy of the good. > > I think that a service URI of the form: > > uri:inperson > > is sufficient, without any additional per-user data. We can leave it to > the human to figure out how to resolve the URI. Indeed, the presentity > placetype (home, work, etc.) would probably suffice, since a watcher > can ususally infer how to find them within that place. We just need a > way to say, "come talk to me". Does that cover EVERY case? No way. Does > it cover many of the important ones? Yes. I am fine with that, although it may be difficult to register such a uri scheme. Paul > -Jonathan R. > > Paul Kyzivat wrote: > >> >> >> Henning Schulzrinne wrote: >> >>>> >>>> Well, a place isn't always sufficient. We see this all the time in >>>> the movies: "Meet me in the bar of tha Acme Hotel at 7pm on April 1, >>>> 2005. I'll have a red carnation in my lapel." >>> >>> >>> >>> I suspect that one of the desirable properties would be that the >>> person doesn't change identifiers just because they changed location. >>> If you don't do that, it will get very confusing - is this URI the >>> same person at a different location or a completely different person? >>> (Imagine a friend finder service that works in physical space.) >>> >>> There is also the issue that you now have two ways to represent >>> "location of a presentity", as a URI or as PIDF-LO, with contact >>> information also available as a vCard. >>> >>>> So we don't need a *globally* unique person identifier. We need a >>>> person identifier that is locally unique in the context of the time >>>> and location of the intended meeting. And the time is important too. >>>> >>>> The time we can deal with. With regular status it is NOW. We can use >>>> timed-status to cover some other time. >>>> >>>> I don't think location has to be part of the Contact, as long as it >>>> is provided as part of the (timed-)status along with the contact. >>>> >>>> Coming up with URIs for identifying people locally within a >>>> particular time-space region sounds like future research. Sounds >>>> like some sort of arbitary predicate would do the trick. >>> >>> >>> >>> Do you want to define people by a game of twenty questions? >> >> >> >> Well, it would be easier if everyone just agreed to have a barcode >> branded on their forehead and an RFID chip embedded in them, each >> containing their UN assigned global person UUID. >> >> But I sense a lot of people don't want to be so easily or irrevokably >> identifiable. So weak forms of identification may be all that is >> generally acceptable. (Hence "I'll have a red carnation in my lapel" >> rather than "The SSN on my forehead will be 123-56-7890.") >> >> Unfortunately, this doesn't lend itself well to URIs or URNs, because >> the information isn't Unique. >> >> I think we continue to punt this one for now. >> >> Paul >> > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jul 21 15:11:57 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14082; Wed, 21 Jul 2004 15:11:56 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BnMVr-0007Lt-1y; Wed, 21 Jul 2004 15:12:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BnMQN-0007K1-LD; Wed, 21 Jul 2004 15:06:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BnMKE-0001E4-F2 for simple@megatron.ietf.org; Wed, 21 Jul 2004 15:00:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12820 for ; Wed, 21 Jul 2004 15:00:20 -0400 (EDT) Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BnMKb-0007CS-BU for simple@ietf.org; Wed, 21 Jul 2004 15:00:47 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i6LIwo57025446; Wed, 21 Jul 2004 11:58:51 -0700 (PDT) Received: from [67.164.0.247] (carbuncle.qualcomm.com [129.46.227.161]) by neophyte.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i6LIwk9Y020407; Wed, 21 Jul 2004 11:58:47 -0700 (PDT) Mime-Version: 1.0 X-Sender: hardie@mage.qualcomm.com Message-Id: In-Reply-To: <40FEB3DC.3050104@cisco.com> References: <40F97472.7030006@cs.columbia.edu> <40FBCF13.8010308@dynamicsoft.com> <40FC2731.3080801@cisco.com> <40FC40D8.3090103@cs.columbia.edu> <40FC5C50.2080708@cisco.com> <40FDE0EE.3000603@dynamicsoft.com> <40FEB3DC.3050104@cisco.com> Date: Wed, 21 Jul 2004 11:58:44 -0700 To: Paul Kyzivat , Jonathan Rosenberg From: Ted Hardie Subject: Re: [Simple] Address and person URIs Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-PMX-Version: 4.6.0.99824 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d 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-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 At 2:20 PM -0400 7/21/04, Paul Kyzivat wrote: >Jonathan Rosenberg wrote: >>I'm fine to punt, but I think this is a case where the perfect is a >>serious enemy of the good. >> >>I think that a service URI of the form: >> >>uri:inperson >> >>is sufficient, without any additional per-user data. We can leave >>it to the human to figure out how to resolve the URI. Indeed, the >>presentity placetype (home, work, etc.) would probably suffice, >>since a watcher can ususally infer how to find them within that >>place. We just need a way to say, "come talk to me". Does that >>cover EVERY case? No way. Does it cover many of the important ones? >>Yes. > >I am fine with that, although it may be difficult to register such a >uri scheme. > > Paul I would certainly suggest running it by the uri mailing list as soon as you can. But a worked description of the scheme might be needed before you do that, as a bare proposal of "what about an inperson scheme?" seems likely to attract ideas far different from those the working group has in mind. regards, Ted Hardie _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jul 21 15:30:44 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16259; Wed, 21 Jul 2004 15:30:44 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BnMo0-0007di-IL; Wed, 21 Jul 2004 15:31:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BnMgj-00010T-GW; Wed, 21 Jul 2004 15:23:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BnMVc-0002zA-5y for simple@megatron.ietf.org; Wed, 21 Jul 2004 15:12:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14118 for ; Wed, 21 Jul 2004 15:12:06 -0400 (EDT) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BnMW0-0007M5-E8 for simple@ietf.org; Wed, 21 Jul 2004 15:12:33 -0400 Received: from panther.cs.columbia.edu (IDENT:i2aNGfFVjnaPUFOqAB8uykKD4FLF2XTI@panther.cs.columbia.edu [128.59.16.122]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i6LJBBfq001221 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Wed, 21 Jul 2004 15:11:12 -0400 (EDT) Received: from [128.59.16.206] (chairpc.cs.columbia.edu [128.59.16.206]) by panther.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id i6LJB9Hr029615; Wed, 21 Jul 2004 15:11:09 -0400 Message-ID: <40FEBFCD.8020109@cs.columbia.edu> Date: Wed, 21 Jul 2004 15:11:09 -0400 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Simple] Address and person URIs References: <40F97472.7030006@cs.columbia.edu> <40FBCF13.8010308@dynamicsoft.com> <40FC2731.3080801@cisco.com> <40FC40D8.3090103@cs.columbia.edu> <40FC5C50.2080708@cisco.com> <40FDE0EE.3000603@dynamicsoft.com> <40FEB3DC.3050104@cisco.com> In-Reply-To: <40FEB3DC.3050104@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 4.6.1.106153, Antispam-Core: 4.6.1.104326, Antispam-Data: 2004.7.21.108206 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, __MIME_TEXT_ONLY 0, REFERENCES 0.000, IN_REP_TO 0, USER_AGENT 0.000' X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 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-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit > I am fine with that, although it may be difficult to register such a uri > scheme. > In a different context (emergency services and tel URIs), I've thought about a 'service' URI which indicates a generic content-oriented communication service. This addresses the current deficiency of the tel URI (really, URN) that can't express services nicely. There may be a connnection there, i.e., urn:service:inperson might do the trick. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jul 21 20:00:34 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06149; Wed, 21 Jul 2004 20:00:34 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BnR1E-0004Wn-CB; Wed, 21 Jul 2004 20:01:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BnOwl-0003ox-Pn; Wed, 21 Jul 2004 17:48:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BnN98-0002uw-0m; Wed, 21 Jul 2004 15:52: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 PAA18424; Wed, 21 Jul 2004 15:52:55 -0400 (EDT) Message-Id: <200407211952.PAA18424@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, 21 Jul 2004 15:52:55 -0400 Cc: simple@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-msrp-relays-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-Score: 0.4 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 --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 : Relay Extensions for Message Sessions Relay Protocol (MSRP) Author(s) : C. Jennings, R. Mahy Filename : draft-ietf-simple-msrp-relays-01.txt Pages : 28 Date : 2004-7-21 The SIMPLE Working Group uses two separate models for conveying instant messages. Pager-mode messages stand alone, whereas Session-mode messages are setup as part of a session using the SIP protocol. MSRP (Message Sessions Relay Protocol) is a protocol for near-real-time, peer-to-peer exchange of binary content without intermediaries, which is designed to be signaled using a separate rendezvous protocol such as SIP. This document introduces the notion of message relay intermediaries to MSRP and describes the extensions necessary to use them. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-msrp-relays-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-msrp-relays-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-msrp-relays-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-7-21153422.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-msrp-relays-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-msrp-relays-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-7-21153422.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 Wed Jul 21 23:42:01 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29386; Wed, 21 Jul 2004 23:42:01 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BnUTa-0001te-6k; Wed, 21 Jul 2004 23:42:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BnUOb-00022Y-VA; Wed, 21 Jul 2004 23:37:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BnUNb-0001Wq-0g for simple@megatron.ietf.org; Wed, 21 Jul 2004 23:36:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29125 for ; Wed, 21 Jul 2004 23:36:20 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BnUO4-0001qJ-Hz for simple@ietf.org; Wed, 21 Jul 2004 23:36:53 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 21 Jul 2004 20:27:20 -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 i6M3Ot8a021807; Wed, 21 Jul 2004 20:24:55 -0700 (PDT) Received: from cisco.com ([161.44.79.221]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKH42709; Wed, 21 Jul 2004 23:24:54 -0400 (EDT) Message-ID: <40FF3386.6080303@cisco.com> Date: Wed, 21 Jul 2004 23:24:54 -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 , Simple WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Content-Transfer-Encoding: 7bit Subject: [Simple] Comments on draft-ietf-simple-message-sessions-07 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Content-Transfer-Encoding: 7bit Ben, This is great!!! It is really coherent and readable now. The following are a few things I found in a first read thru, up to the examples. These are largely nits. Paul 4.4 Connection Model, 3rd paragraph: s/hostname port of the URL/hostname part of the URL/ ^ 5. MSRP URLs transports. A MSRP URL with multiple, contradictory transports is invalid, unless some other document specifies meaning for the particular combination of transport parameters. I don't understand the above. The specified syntax for the url only permits a single transport token, so it is syntactically impossible to have contradictory transports in a single url. An MSRP URL server part identifies a participant in an MSRP session. If the server part contains a numeric IP address, it MUST also contain a port. The resource part identifies a particular session The term 'server' is defined in RFC2396, but it isn't used in the definition of the MSRP_urls, so its reference here is undefined. This could be fixed by changing the syntax to: MSRP_urls = msrp-scheme "://" server ["/" resource] ";" transport server = [userinfo "@"] hostport msrp-scheme = "msrp" / "msrps" resource = 1*unreserved transport = "tcp" / token This definition is consistent with the one in 2396, in that the same names are used for the same parts of the url, though this is more restrictive. 5.1 URL comparison "The host part is compared as case insensitive". What if it is an ip address? is it compared char by char? (What about leading zeros?) Is port comparison char by char, or numeric? (leading zeros again.) 6.1.1 Delivering SEND requests The default disposition of body is "render". If the sender wants different disposition, it MAY insert a Content-Disposition header. Since MSRP is a binary protocol, transfer encoding MUST be "binary". Are we supposing any particular semantic to content-dispositions? The ones defined with mime aren't especially specific, and the ones defined with sip aren't especially meaningful. 6.3.1 Receiving SEND requests What is done with the body is outside the scope of MSRP and largely determined by the MIME type. The body MAY be rendered after the whole message is received or partially rendered as it is being received. Content-Disposition was mentioned earlier. Perhaps it should also be mentioned here, as in: What is done with the body is outside the scope of MSRP and largely determined by the MIME Content-Type and Content-Disposition. The body MAY be rendered after the whole message is received or partially rendered as it is being received. If we were going to discuss the significance of content dispostions, someplace near here would be a good place to do it. 7.1 SDP Offer-Answer Exchanges for MSRP Sessions While MSRP could theoretically carry any media type, "message" is appropriate. For MSRP, the port number is always ignored--the actual port number is provided in an MSRP URL. Instead "9" is used, which is an innocuous value which is assigned to the discard port. The protocol is always "msrp", and the value of the format list is always a single asterisk character ("*"). I thought we determined that the same address+port can't be used for more than one media session in the same SDP. If so, then it must be possible to use other port values, in order to permit multiple msrp sessions in same offer or answer. Or do we have another answer to that? (I only remember this fuzzily - I may be crazy.) All types listed in either the accept-types or accept-wrapped-types attributes MAY include a max-size parameter, indicating the largest message it is willing to accept of that type. Max-size refers to the complete message, not the size of any one chunk. Senders MUST NOT exceed the max-size limit, if any, when sending messages of any listed type. If a type is listed without the parameter, then no preset size limit exists. Its weird to associate the size with a type, but make the size apply to the message. The size should apply to the encoded body part representing the type. This is especially important when a type might be placed in a wrapper that can also contain other types. 9. Formal Syntax No definition of namespace. Syntax of Report-Success and Report-Failure doesn't have for the "receipt-type" parameter referenced in section 6.1.2: REPORT requests MAY include a body. If a body is included, it SHOULD be of the DSN MIME type detailed in RFC1894 [8], but MAY be of some other type if the sender of the SEND request indicated support in the "receipt-type" parameter of the respective Report-Success or Report-Failure header field. This parameter contains the alternative That's all for now. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jul 22 07:34:30 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11296; Thu, 22 Jul 2004 07:34:30 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bnbqn-0007oW-Um; Thu, 22 Jul 2004 07:35:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bnbcj-0002sn-Od; Thu, 22 Jul 2004 07:20:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BnbaW-0001qm-JJ for simple@megatron.ietf.org; Thu, 22 Jul 2004 07:18:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09760 for ; Thu, 22 Jul 2004 07:18:11 -0400 (EDT) Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bnbb3-0007ZO-SF for simple@ietf.org; Thu, 22 Jul 2004 07:18:46 -0400 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by goliath.siemens.de (8.12.6/8.12.6) with ESMTP id i6MBI8qO013695; Thu, 22 Jul 2004 13:18:08 +0200 Received: from moody.mchh.siemens.de (moody.mchh.siemens.de [139.21.205.85]) by mail3.siemens.de (8.11.7/8.11.7) with ESMTP id i6MBI8306336; Thu, 22 Jul 2004 13:18:08 +0200 (MEST) Received: from mchh246e.mchh.siemens.de (mchh246e.mchh.siemens.de [139.21.200.56]) by moody.mchh.siemens.de (8.12.6/8.12.6) with ESMTP id i6MBI7U9000844; Thu, 22 Jul 2004 13:18:07 +0200 Received: by mchh246e.mchh.siemens.de with Internet Mail Service (5.5.2657.72) id <374A0R8Z>; Thu, 22 Jul 2004 13:18:07 +0200 Message-ID: From: Leis Peter To: Simple WG Subject: comment on [Simple] Updated XCAP spec now available and ready fo r wglc! Date: Thu, 22 Jul 2004 13:18:06 +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-Spam-Score: 0.0 (/) X-Scan-Signature: 2a9ffb6f997442a3b543bcdaf483b990 Content-Transfer-Encoding: quoted-printable Cc: "'Jonathan Rosenberg'" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 515708a075ffdf0a79d1c83b601e2afd Content-Transfer-Encoding: quoted-printable one comment on draft-ietf-simple-xcap-03=20 while you have a definition of "XCAP server" in the Definitions = section, a definition of "XCAP client" is missing in the Definitions section Regards Peter -----Urspr=FCngliche Nachricht----- Von: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] Im = Auftrag von Jonathan Rosenberg Gesendet: Freitag, 16. Juli 2004 19:28 An: Simple WG Betreff: [Simple] Updated XCAP spec now available and ready for wglc! Folks, I've just submitted an updated to the XCAP core specification. Until it = appears in the archives, you can pick up a copy at: http://www.jdrosen.net/papers/draft-ietf-simple-xcap-03.txt This is a fairly major update, mostly in terms of document organization = and clarity, which I think is vastly improved. Here are the resolutions to the various open issues, which are=20 incorporated into this version: ISSUE 1: schema awareness - when it is needed? Only for validation ISSUE 2: positional insertions? They have been added ISSUE 3: PUT vs. POST Continue to use PUT. Server never modifies the document submitted via PUT. Rather, the=20 client picks a URI, and if its not unique, the server rejects the=20 request and suggests unique alternatives in the body of the error = response. ISSUE 4: Document/element separators Using double tilde (~~) ISSUE 5: Multiple Insertions deferred to another document, to be debated separately from core = xcap ISSUE 6: Selection by text element value decided not to include this feature ISSUE 7: Unique steps at each hop Uniqueness is required at each hop ISSUE 8: Etag scopes Etags are scoped to a document ISSUE 9a: Supported namespace discovery Added a capability application usage, in which the supported=20 namespaces of the server can be listed ISSUE 9b: Etags useless for insert Documented this problem, suggest workarounds As such, there are no open issues that I am aware of. As a result, I=20 believe this document is done, and now ready for working group last = call=20 (yay!). There are two TODOs in the document, which are questions I need=20 assistance in answering. Once answered, text can be incorporated into=20 the document. There are many changes in addition to the above issue resolutions. Many = are clarifications, fixes, and other things discussed on the list and = at=20 the interim. The following is a summary of the main ones: * To fetch a document, -02 recommended using the If-Match header field = to do a conditional get. This should have been If-None-Match, and has been corrected in this revision. * Added definitions section * Terminology cleanup. A key term here is "XCAP resource" which refers to a document, element, or attribute which follows XCAP naming and data validation constraints. * Beefed up the section on what an application usage has to specify when it defines its data validation rules. The section discusses XML schema, uniqueness constraints, URI constraints and referential integrity. XCAP now requires each application usage to explicitly call out uniqueness constraints, even if those constraints are also specified in the schema using the tag. * Explicitly say that XCAP servers are not responsible for referential integrity. This is the responsibility of the client. XCAP is not an RDBMS! * renamed "Data Interdependencies" to "Resource Interdependencies". This is commensurate with the change that the server doesnt update documents PUT to the server (XCAP issue 3). Indeed, this aspect of the application usage is talking about something quite different now. When a client PUTs a resource, the server changes the state of = OTHER resources. Most interdependencies are expressed in schema; a PUT to an element changes the contents of all of the child elements and attributes. However, in some cases, there are inter-dependencies across docs, and the app usage needs to specify that. We have two examples so far - the index document created by the server in the list usage, and Miguel's directory usage. * terminology: XCAP User ID (XUI). This is the "username" present in the xcap URI. It need not be the actual "username". * removed "mandatory-ns", which was our approach for allowing the client to mandate that a server understand a particular namespace before processing a document. Instead, there is an application usage that contains a document that lists the server's capabilities, which includes namespaces, application usages and xcap extensions. [ISSUE 9] * clarified that a server can have multiple root services URIs, and = that there is never interactions or information carryover across root = services * clarified that the xcap root services URI (now called Xcap root URI) is a valid HTTP URL but doesnt actually refer to any existing resource * added usage of the ~~ path segment to separate the document and node selectors * added rules for escape coding. Note that the left bracket, right bracket and double quote need to be escaped. Also, since XML elements, attributes, and attribute values can contain unicode characters, any unicode characters outside of US-ASCII need to be escape coded. I lifted some text from rfc2396bis that documents how this escape coding is done. * comparison rules for the element and attribute names in the node selector against those in the document have been aligned with the XPath rules. In particular, the namespace bindings used to resolve namespace prefixes in the node selector are taken from those in scope for the context element. Also, if the element name in the node selector has no prefix, its namespace URI is null, *NOT* the default namespace of the context element. This is accoring to XPath. However, I can't see how this can work. Need to follow up on that with an Xpath expert. * The detailed conflict report document has two new errors - uniqueness failure and constraint-failure. no-xml-att-value has been renamed to not-xml-att-value for consistency. The no-element was removed; no-parent is used for all of these cases. cannot-insert now specifically refers to PUT operations that would not be idempotent. The uri-exists error has been generalized to uniqueness-failure, covering other uniqueness constraints that an application usage might impose. The schema uses substitution groups for extensibility. The spec says that XCAP extensions can add new elements. * added an application usage that contains capabilities of the server - supported auid, supported namespaces, and supported extensions. A single instance of this document is in the global directory with the name "index" * beefed up the server processing of PUT * clearly indicate that schema awareness is not needed to insert, only to validate [ISSUE 1] * added positional inserts [ISSUE 2]. Give guidance to clients on how to use them. * removed whole idea of server filling in URI. That is now handled by having the server reject non-unique URI [ISSUE 3] * Added the "path separator" which is a path segment between document selectors and node selectors, with value of double tilde [ISSUE 4] * The section on construction of the http URI makes it very clear that each step in the selection process when processing the node selector MUST result in a single element [ISSUE 7] * Etag scope is document wide still, as it was in -02. The wording was cleaned up on it [ISSUE 8] * Changed the mime type of application/xml-fragment-body to application/xcap-el+xml and application/xml-attribute-value to application/xcap-att+xml, per discussions during ietf 59 * clarified that escape encoding of xcap components only applies when they appear in a URI, so body components will not be escape encoded * Clarified that, in the case where the client does not do a positional insertion, the element gets inserted at the end * Changed read/update/write transaction section to "Conditional Operations", since etags doesnt give "transactional" behavior in the true definition. This section has been cleaned up a lot. It also includes an example of using the If-None-Match:* to do a forced creation. * Documented that conditional operations are useless for creation operations, and recommend that if conditioning is needed, the client instead modify the parent resource. [ISSUE 9] * Updated IANA registry to include namespace and schema registrations for xcap-caps document. Also, fixed up schema registrations, which apparently need to include a schema URN. I had thought these were assigned by IANA, and equal to a URL where the schema can be fetched from, but they are not. * mention that redirects are applicable here just as for any other http resources * added a bunch of text to clarify the "do we need filename extensions or not" issue. The answer is this: for well known documents, defined by the naming conventions in the application usage, it will say how the document is named. In other cases, a document has to be referenced from a well known place, so it doesnt matter how its named, as long as you have referential integrity. * documented idempotency requirements on PUT and DELETE requests. Describe the known cases for element and attribute insertions when the request results in a document that meets the data constraints of the application usage, but is not idempotent. * added a section on guidelines for application usage design, covering both schema design and naming convention design 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 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jul 22 10:46:40 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26445; Thu, 22 Jul 2004 10:46:40 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bneqr-0002wk-Mu; Thu, 22 Jul 2004 10:47:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BnenR-0006ss-MN; Thu, 22 Jul 2004 10:43:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bneid-0004mu-Vx for simple@megatron.ietf.org; Thu, 22 Jul 2004 10:38:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25824 for ; Thu, 22 Jul 2004 10:38:45 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BnejC-0002os-NU for simple@ietf.org; Thu, 22 Jul 2004 10:39:24 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 22 Jul 2004 10:43: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 i6MEcDGX009262; Thu, 22 Jul 2004 10:38:14 -0400 (EDT) Received: from cisco.com ([161.44.79.221]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKH68286; Thu, 22 Jul 2004 10:38:13 -0400 (EDT) Message-ID: <40FFD155.9020209@cisco.com> Date: Thu, 22 Jul 2004 10:38: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] Comments on draft-ietf-simple-message-sessions-07 References: <40FF3386.6080303@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c 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-Score: 0.2 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: 7bit A few more comments, starting with the examples: 11.1 - the numbering of the messages doesn't agree with what is in the diagram. Also, message 5 is missing a blank line between Content-Type and the body. 11.3 - I find the sysadmin example highly unlikely. Why would MSRP (rather than page mode MESSAGE) be used for this? A session would first have to be established. This would only make sense if there was already a session established, or there was expectation that many such messages will be sent using the same session. 11.4 - I presume the last message in this example was intended to be REPORT, not SEND. 11.5 - Nice example! s/MSPR/MSRP/ Toward the end, when the MSRP session is set up to the nurse, I believe "art thou hither" would be sent, just as it was to the other attempts. 12. Extensibility I believe the decision was that we didn't need version numbers because sessions are established using another protocol (e.g. SIP) which can handle version negotiation. But we don't have any provision for versions there either. The only options I can see that are open for revisions are: - use a different scheme name (not msrp) in the urls. (ugh) - invent a new a-line to carry versioning information that can be negotiated. Another possibility, if we plan now, is to put a little more extensibility into the msrp url, such as: MSRP_urls = msrp-scheme "://" server ["/" resource] ";" transport *( ";" msrp-option ) server = [userinfo "@"] hostport msrp-scheme = "msrp" / "msrps" resource = 1*unreserved transport = "tcp" / token msrp-option = gen-param This would of course require a change to the comparison rules for urls, and could make comparison somewhat more complex. I think we just have a clear idea of a workable strategy for moving to a revised protocol. That's it, Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jul 22 14:30:03 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12553; Thu, 22 Jul 2004 14:30:02 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BniL3-0006UJ-8H; Thu, 22 Jul 2004 14:30:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bni2f-0001bg-TG; Thu, 22 Jul 2004 14:11:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BnhtP-0006ed-P7; Thu, 22 Jul 2004 14:02:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10258; Thu, 22 Jul 2004 14:02:06 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net ([66.12.12.130] helo=bdsl.greycouncil.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bnhu0-00062x-5W; Thu, 22 Jul 2004 14:02:45 -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 i6MI23KS015686; Thu, 22 Jul 2004 13:02:04 -0500 Message-ID: <4100011B.9020808@softarmor.com> Date: Thu, 22 Jul 2004 13:02:03 -0500 From: Dean Willis User-Agent: Mozilla Thunderbird 0.7 (X11/20040615) X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip@ietf.org, sipping@ietf.org, xcon@ietf.org, iptel@ietf.org, simple@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Subject: [Simple] Softarmor web site going down for rehoming X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit The softarmor web site and email relay (and my email) will be down this afternoon for rehoming. Although the machine should only be down briefly, it could take awhile for DNS changes to propagate through. If you get desperate, try talking to host "spectra.softarmor.com" or the backup site at "kevlar.softarmor.com". Thanks, -- Dean _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jul 22 19:56:39 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01775; Thu, 22 Jul 2004 19:56:39 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BnnRA-0002HW-Bw; Thu, 22 Jul 2004 19:57:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bnn6w-0002kN-Q7; Thu, 22 Jul 2004 19:36:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bnmt3-0001jw-11 for simple@megatron.ietf.org; Thu, 22 Jul 2004 19:22:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28381 for ; Thu, 22 Jul 2004 19:22:01 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bnmtg-0001T3-Bd for simple@ietf.org; Thu, 22 Jul 2004 19:22:45 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 22 Jul 2004 16:24:00 -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 i6MNLS8c018724; Thu, 22 Jul 2004 16:21:30 -0700 (PDT) Received: from cisco.com ([161.44.79.221]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKI17549; Thu, 22 Jul 2004 19:21:27 -0400 (EDT) Message-ID: <41004BF7.4090806@cisco.com> Date: Thu, 22 Jul 2004 19:21:27 -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: Rohan Mahy , Cullen Jennings References: <200407211952.PAA18424@ietf.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Content-Transfer-Encoding: 7bit Cc: simple@ietf.org Subject: [Simple] Re: draft-ietf-simple-msrp-relays-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-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Content-Transfer-Encoding: 7bit Rohan/Cullen, I read thru the relays draft. It is starting to shape up. I consider this to be very critical work, and would like to help any way I can. I made notes, attached below, while reading. I gather the doc is a snapshot of work in progress, so some of these may be too picky - just pointing out things that have been put off for now. Paul Section 3 - Overview: It would be helpful to have some explanation with the messages in this section - what point each is trying to illustrate. SEND requests are sent hop-by-hop. (Each relay that receives a SEND request acknowledges receipt of the request before forwarding the content in other SEND requests.) All other requests are sent end-to-end. This isn't consistent with the definitions. SEND requests are e2e by that definition, which says nothing about responses. They also have hop by hop responses. Other reqeusts are also e2e but don't have responses. When the Report-Failure header is set appropriately, MSRP Nodes respond to SEND requests by taking the last (rightmost) URI in the ^^^^^^^^^^^^^^^^??? From-Path and placing that in a To-Path header in the response, and placing their URI in the From-Path of the response. Likwise, when Isn't it the *first* URI that should be used to address the previous hop? 4.4 Time-related headers Specifically an Expires header in an AUTH request indicates how long the provided URIs will be valid. I am thinking this is going to cause a problem unless there is some way to renew one. Otherwise it is always possible that a session will want to extend beyond the expiration. This can of course be dealt with by switching to a new one, either before or after the old one expires. But if so, that needs to be pointed out. If that can happen it will put a premium on ensuring the switchover from one stream to another is seamless. (I guess that is a good thing.) 5.2.3 Receiving AUTH requests When a relay receives an AUTH request, it must digest challenge the request. ... If there are additional URIs in the To-Path header, the relay attempts to forward the AUTH request to the remaining relays. These sound like successive steps. But in reality I think they are alternatives - if the AUTH request is addressed *to* the relay then it must challenge it. If the the AUTH request is routed thru the relay (indicated by the presence of additional URIs in the To-Path) then it should forward it without challenging. Need different words to say this. 5.2.3 Receiving AUTH requests Note: A successful AUTH response returns a Route header which contains a base MSRP URI that the client can use to create a number of different URIs which are all associated with the current connection. How are the new uris derived? The msrp url syntax doesn't permit slashes in the resource part. So to do this will require reserving a character from 'unreserved' as a delimiter. What there is to choose from are: -_.!~*'() I gather you mean to start with something like: msrp:a.example.com:1234/agic456 and derive from it things like: msrp:a.example.com:1234/agic456!1 msrp:a.example.com:1234/agic456!x msrp:a.example.com:1234/agic456!xy 7. Finding MSRP Servers If the hostport of an msrps: URI is an IPv4 address or an IPv6 reference and no port number is provided, use the default port number assigned by IANA. If the hostport is a domain name and an explicit port number is provided, attempt to lookup a valid address record (A or AAAA) for the domain name. Connect using the TLS over the default transport (TCP) with the default port number. ^^^^^^^ ??? Shouldn't the explict port number be used here??? _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jul 22 21:05:22 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05871; Thu, 22 Jul 2004 21:05:21 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BnoVg-00037d-0w; Thu, 22 Jul 2004 21:06:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BnoOX-0002RU-Bz; Thu, 22 Jul 2004 20:58:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BnoFr-0005YA-72 for simple@megatron.ietf.org; Thu, 22 Jul 2004 20:49:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04710 for ; Thu, 22 Jul 2004 20:49:41 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BnoGW-0002uU-7u for simple@ietf.org; Thu, 22 Jul 2004 20:50:24 -0400 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 22 Jul 2004 17:49:56 -0700 X-BrightmailFiltered: true Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i6N0n8x3020780; Thu, 22 Jul 2004 17:49:09 -0700 (PDT) Received: from [127.0.0.1] (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id AVO76712; Thu, 22 Jul 2004 17:47:56 -0700 (PDT) In-Reply-To: <41004BF7.4090806@cisco.com> References: <200407211952.PAA18424@ietf.org> <41004BF7.4090806@cisco.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <4CAAF940-DC42-11D8-B267-0003938AF740@cisco.com> Content-Transfer-Encoding: 7bit From: Rohan Mahy Subject: Re: [Simple] Re: draft-ietf-simple-msrp-relays-01.txt Date: Thu, 22 Jul 2004 17:50:31 -0700 To: Paul Kyzivat X-Mailer: Apple Mail (2.618) X-Spam-Score: 2.3 (++) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Content-Transfer-Encoding: 7bit Cc: Cullen Jennings , Rohan Mahy , Rohan Mahy , 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-Score: 2.3 (++) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Content-Transfer-Encoding: 7bit On Jul 22, 2004, at 4:21 PM, Paul Kyzivat wrote: > Rohan/Cullen, > > I read thru the relays draft. It is starting to shape up. I consider > this to be very critical work, and would like to help any way I can. > > I made notes, attached below, while reading. I gather the doc is a > snapshot of work in progress, so some of these may be too picky - just > pointing out things that have been put off for now. > > Paul > > Section 3 - Overview: > > It would be helpful to have some explanation with the messages in this > section - what point each is trying to illustrate. > > SEND requests are sent hop-by-hop. (Each relay that receives a SEND > request acknowledges receipt of the request before forwarding the > content in other SEND requests.) All other requests are sent > end-to-end. > > This isn't consistent with the definitions. SEND requests are e2e by > that definition, which says nothing about responses. They also have > hop by hop responses. Other reqeusts are also e2e but don't have > responses. No, complete messages are sent e2e, but a SEND request is purely a one hop issue. I can send one 5 SEND requests with chunks of one message over one hop, the next hop can send 1 SEND request, and the last hop can send 3 SEND requests, all for the same message. > > When the Report-Failure header is set appropriately, MSRP Nodes > respond to SEND requests by taking the last (rightmost) URI in the > ^^^^^^^^^^^^^^^^??? > From-Path and placing that in a To-Path header in the response, and > placing their URI in the From-Path of the response. Likwise, when > > Isn't it the *first* URI that should be used to address the previous > hop? ah, possibly ;-) > > 4.4 Time-related headers > > Specifically an Expires header in an AUTH request indicates how long > the provided URIs will be valid. > > I am thinking this is going to cause a problem unless there is some > way to renew one. Otherwise it is always possible that a session will > want to extend beyond the expiration. This can of course be dealt with > by switching to a new one, either before or after the old one expires. > But if so, that needs to be pointed out. > > If that can happen it will put a premium on ensuring the switchover > from one stream to another is seamless. (I guess that is a good > thing.) > > 5.2.3 Receiving AUTH requests > > When a relay receives an AUTH request, it must digest challenge the > request. > ... > If there are additional URIs in the To-Path header, the relay > attempts to forward the AUTH request to the remaining relays. > > These sound like successive steps. But in reality I think they are > alternatives - if the AUTH request is addressed *to* the relay then it > must challenge it. If the the AUTH request is routed thru the relay > (indicated by the presence of additional URIs in the To-Path) then it > should forward it without challenging. Need different words to say > this. if the request is addressed to the relay it challenges. If the AUTH request is merely passing through a session-specific address on this relay that's fine. Then there is someone trying to route through a random relay, without having authenticated to it, which is not allowed. > 5.2.3 Receiving AUTH requests > > Note: A successful AUTH response returns a Route header which > contains a base MSRP URI that the client can use to create a number > of different URIs which are all associated with the current > connection. > > How are the new uris derived? The msrp url syntax doesn't permit > slashes in the resource part. So to do this will require reserving a > character from 'unreserved' as a delimiter. What there is to choose > from are: > > -_.!~*'() > > I gather you mean to start with something like: > > msrp:a.example.com:1234/agic456 > > and derive from it things like: > > msrp:a.example.com:1234/agic456!1 > msrp:a.example.com:1234/agic456!x > msrp:a.example.com:1234/agic456!xy i actually had semicolons in mind, but I screwed up > 7. Finding MSRP Servers > > If the hostport of an msrps: URI is an IPv4 address or an IPv6 > reference and no port number is provided, use the default port > number > assigned by IANA. If the hostport is a domain name and an explicit > port number is provided, attempt to lookup a valid address record (A > or AAAA) for the domain name. Connect using the TLS over the > default > transport (TCP) with the default port number. > ^^^^^^^ ??? > > Shouldn't the explict port number be used here??? "... and no port number is provided..." I'm trying to cover the relay discovery case here. These URIs are not in an SDP. thx, -r > > > > > > _______________________________________________ > Simple mailing 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 Jul 23 02:07:27 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12377; Fri, 23 Jul 2004 02:07:27 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BntE4-0006tk-MW; Fri, 23 Jul 2004 02:08:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bnt1f-0003gU-Dm; Fri, 23 Jul 2004 01:55:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bnsue-0007T1-PS; Fri, 23 Jul 2004 01:48:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03813; Fri, 23 Jul 2004 01:48:07 -0400 (EDT) Received: from [65.208.0.180] (helo=spectra.softarmor.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BnsvL-0006ZU-IX; Fri, 23 Jul 2004 01:48:52 -0400 Received: from [206.176.144.210] (206-176-144-210.waymark.net [206.176.144.210] (may be forged)) (authenticated bits=0) by spectra.softarmor.com (8.12.8/8.12.8) with ESMTP id i6N5lXoP008539 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 23 Jul 2004 00:47:35 -0500 Message-ID: <4100A674.8080803@softarmor.com> Date: Fri, 23 Jul 2004 00:47:32 -0500 From: Dean Willis User-Agent: Mozilla Thunderbird 0.6 (X11/20040502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip@ietf.org, sipping@ietf.org, xcon@ietf.org, iptel@ietf.org, simple@ietf.org References: <4100011B.9020808@softarmor.com> In-Reply-To: <4100011B.9020808@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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Subject: [Simple] Re: [Sipping] Softarmor web site going down for rehoming X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Dean Willis wrote: > > The softarmor web site and email relay (and my email) will be down this > afternoon for rehoming. Although the machine should only be down > briefly, it could take awhile for DNS changes to propagate through. We appear to be back in operation. I believe we should also be about twice as fast now, as we've doubled the available bandwidth. -- Dean _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jul 23 07:10:32 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11054; Fri, 23 Jul 2004 07:10:32 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BnxxQ-0003cN-2g; Fri, 23 Jul 2004 07:11:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bnxur-0007IX-IK; Fri, 23 Jul 2004 07:08:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bnxn5-0004NW-EQ for simple@megatron.ietf.org; Fri, 23 Jul 2004 07:00:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10228 for ; Fri, 23 Jul 2004 07:00:36 -0400 (EDT) Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bnxnp-0003NZ-Up for simple@ietf.org; Fri, 23 Jul 2004 07:01:26 -0400 Received: from dynamicsoft.com ([63.113.46.7]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i6NB0ReE001277; Fri, 23 Jul 2004 07:00:27 -0400 (EDT) Message-ID: <4100EFB4.1070804@dynamicsoft.com> Date: Fri, 23 Jul 2004 07:00:04 -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: Leis Peter Subject: Re: comment on [Simple] Updated XCAP spec now available and ready fo r wglc! 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 mail3.dynamicsoft.com id i6NB0ReE001277 X-Spam-Score: 0.0 (/) X-Scan-Signature: 223e3c753032a50d5dc4443c921c3fcd 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-Score: 0.0 (/) X-Scan-Signature: 71f780ffdd80c541d3e75aa5f2710d3d Content-Transfer-Encoding: quoted-printable Good point, definition added. Thanks, Jonathan R. Leis Peter wrote: > one comment on draft-ietf-simple-xcap-03=20 >=20 > while you have a definition of "XCAP server" in the Definitions section= , > a definition of "XCAP client" is missing in the Definitions section >=20 > Regards > Peter >=20 > -----Urspr=FCngliche Nachricht----- > Von: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] Im Auftra= g von Jonathan Rosenberg > Gesendet: Freitag, 16. Juli 2004 19:28 > An: Simple WG > Betreff: [Simple] Updated XCAP spec now available and ready for wglc! >=20 >=20 > Folks, >=20 > I've just submitted an updated to the XCAP core specification. Until it= =20 > appears in the archives, you can pick up a copy at: >=20 > http://www.jdrosen.net/papers/draft-ietf-simple-xcap-03.txt >=20 > This is a fairly major update, mostly in terms of document organization= =20 > and clarity, which I think is vastly improved. >=20 > Here are the resolutions to the various open issues, which are=20 > incorporated into this version: >=20 > ISSUE 1: schema awareness - when it is needed? > Only for validation >=20 > ISSUE 2: positional insertions? > They have been added >=20 > ISSUE 3: PUT vs. POST > Continue to use PUT. > Server never modifies the document submitted via PUT. Rather, the=20 > client picks a URI, and if its not unique, the server rejects the=20 > request and suggests unique alternatives in the body of the error respo= nse. >=20 > ISSUE 4: Document/element separators > Using double tilde (~~) >=20 > ISSUE 5: Multiple Insertions > deferred to another document, to be debated separately from core xca= p >=20 > ISSUE 6: Selection by text element value > decided not to include this feature >=20 > ISSUE 7: Unique steps at each hop > Uniqueness is required at each hop >=20 > ISSUE 8: Etag scopes > Etags are scoped to a document >=20 > ISSUE 9a: Supported namespace discovery > Added a capability application usage, in which the supported=20 > namespaces of the server can be listed >=20 > ISSUE 9b: Etags useless for insert > Documented this problem, suggest workarounds >=20 >=20 > As such, there are no open issues that I am aware of. As a result, I=20 > believe this document is done, and now ready for working group last cal= l=20 > (yay!). >=20 > There are two TODOs in the document, which are questions I need=20 > assistance in answering. Once answered, text can be incorporated into=20 > the document. >=20 > There are many changes in addition to the above issue resolutions. Many= =20 > are clarifications, fixes, and other things discussed on the list and a= t=20 > the interim. The following is a summary of the main ones: >=20 > * To fetch a document, -02 recommended using the If-Match header field = to > do a conditional get. This should have been If-None-Match, and has been > corrected in this revision. >=20 > * Added definitions section >=20 > * Terminology cleanup. A key term here is "XCAP resource" which refers > to a document, element, or attribute which follows XCAP naming and > data validation constraints. >=20 > * Beefed up the section on what an application usage has to specify > when it defines its data validation rules. The section discusses XML > schema, uniqueness constraints, URI constraints and referential > integrity. XCAP now > requires each application usage to explicitly call out uniqueness > constraints, even if those constraints are also specified in the > schema using the tag. >=20 > * Explicitly say that XCAP servers are not responsible for referential > integrity. This is the responsibility of the client. XCAP is not an > RDBMS! >=20 > * renamed "Data Interdependencies" to "Resource > Interdependencies". This is commensurate with the change that the > server doesnt update documents PUT to the server (XCAP issue > 3). Indeed, this aspect > of the application usage is talking about something quite different > now. When a client PUTs a resource, the server changes the state of OTH= ER > resources. Most interdependencies are expressed in schema; a PUT to an > element changes the contents of all of the child elements and > attributes. However, in some cases, there are inter-dependencies > across docs, and the app usage needs to specify that. We have two > examples so far - the index document created by the server in the list > usage, and Miguel's directory usage. >=20 > * terminology: XCAP User ID (XUI). This is the "username" present in > the xcap URI. It need not be the actual "username". >=20 > * removed "mandatory-ns", which was our approach for allowing the > client to mandate that a server understand a particular namespace > before processing a document. Instead, there is an application usage > that contains a document that lists the server's capabilities, which > includes namespaces, application usages and xcap extensions. [ISSUE 9] >=20 > * clarified that a server can have multiple root services URIs, and tha= t > there is never interactions or information carryover across root servic= es >=20 > * clarified that the xcap root services URI (now called Xcap root URI) > is a valid HTTP URL but doesnt actually refer to any existing resource >=20 > * added usage of the ~~ path segment to separate the document and node > selectors >=20 > * added rules for escape coding. Note that the left bracket, right > bracket and double quote need to be escaped. Also, since XML elements, > attributes, and attribute values can contain unicode characters, any > unicode characters outside of US-ASCII need to be escape coded. I > lifted some text from rfc2396bis that documents how this escape coding > is done. >=20 > * comparison rules for the element and attribute names in the node > selector against those in the document have been aligned with the > XPath rules. In particular, the namespace bindings used to resolve > namespace prefixes in the node selector are taken from those in scope > for the context element. Also, if the element name in the node > selector has no prefix, its namespace URI is null, *NOT* the default > namespace of the context element. This is accoring to XPath. However, > I can't see how this can work. Need to follow up on that with an Xpath > expert. >=20 > * The detailed conflict report document has two new errors - > uniqueness failure and constraint-failure. no-xml-att-value has been > renamed to not-xml-att-value for consistency. The no-element was > removed; no-parent is used for all of these cases. cannot-insert now > specifically refers to PUT operations that would not be > idempotent. The uri-exists error has been generalized to > uniqueness-failure, covering other uniqueness constraints that an > application usage might impose. The schema uses substitution groups > for extensibility. The spec says that XCAP extensions can add new > elements. >=20 > * added an application usage that contains capabilities of the server > - supported auid, supported namespaces, and supported extensions. A > single instance of this document is in the global directory with the > name "index" >=20 > * beefed up the server processing of PUT >=20 > * clearly indicate that schema awareness is not needed to insert, only > to validate [ISSUE 1] >=20 > * added positional inserts [ISSUE 2]. Give guidance to clients on how > to use them. >=20 > * removed whole idea of server filling in URI. That is now handled by > having the server reject non-unique URI [ISSUE 3] >=20 > * Added the "path separator" which is a path segment between document > selectors and node selectors, with value of double tilde [ISSUE 4] >=20 > * The section on construction of the http URI makes it very clear that > each step in the selection process when processing the node selector > MUST result in a single element [ISSUE 7] >=20 > * Etag scope is document wide still, as it was in -02. The wording was > cleaned up on it [ISSUE 8] >=20 > * Changed the mime type of application/xml-fragment-body to > application/xcap-el+xml and application/xml-attribute-value to > application/xcap-att+xml, per discussions during ietf 59 >=20 > * clarified that escape encoding of xcap components only applies when > they appear in a URI, so body components will not be escape encoded >=20 > * Clarified that, in the case where the client does not do a > positional insertion, the element gets inserted at the end >=20 > * Changed read/update/write transaction section to "Conditional > Operations", since etags doesnt give "transactional" behavior in the > true definition. This section has been cleaned up a lot. It also > includes an example of using the If-None-Match:* to do a forced > creation. >=20 > * Documented that conditional operations are useless for creation > operations, and recommend that if conditioning is needed, the client > instead modify the parent resource. [ISSUE 9] >=20 > * Updated IANA registry to include namespace and schema registrations > for xcap-caps document. Also, fixed up schema registrations, which > apparently need to include a schema URN. I had thought these were > assigned by IANA, and equal to a URL where the schema can be fetched > from, but they are not. >=20 > * mention that redirects are applicable here just as for any other > http resources >=20 > * added a bunch of text to clarify the "do we need filename extensions > or not" issue. The answer is this: for well known documents, defined > by the naming conventions in the application usage, it will say how > the document is named. In other cases, a document has to be referenced > from a well known place, so it doesnt matter how its named, as long as > you have referential integrity. >=20 > * documented idempotency requirements on PUT and DELETE > requests. Describe the known cases for element and attribute > insertions when the request results in a document that meets the data > constraints of the application usage, but is not idempotent. >=20 > * added a section on guidelines for application usage design, covering > both schema design and naming convention design >=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 Fri Jul 23 10:58:51 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00076; Fri, 23 Jul 2004 10:58:51 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bo1WP-0008B8-9J; Fri, 23 Jul 2004 10: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 1Bo1S7-0006Kj-T2; Fri, 23 Jul 2004 10:55:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bnjt4-0003F6-K1 for simple@megatron.ietf.org; Thu, 22 Jul 2004 16:09:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24199 for ; Thu, 22 Jul 2004 16:09:52 -0400 (EDT) Received: from web90102.mail.scd.yahoo.com ([66.218.94.73]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Bnjtg-0000YT-1i for simple@ietf.org; Thu, 22 Jul 2004 16:10:33 -0400 Message-ID: <20040722200917.92239.qmail@web90102.mail.scd.yahoo.com> Received: from [12.47.48.5] by web90102.mail.scd.yahoo.com via HTTP; Thu, 22 Jul 2004 13:09:17 PDT Date: Thu, 22 Jul 2004 13:09:17 -0700 (PDT) From: kamal Rometra To: aki.niemi@nokia.com, simple@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 X-Mailman-Approved-At: Fri, 23 Jul 2004 10:55:13 -0400 Subject: [Simple] Regarding throttle for notifications X-BeenThere: simple@ietf.org X-Mailman-Version: 2.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="===============0994451682==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a --===============0994451682== Content-Type: multipart/alternative; boundary="0-170230013-1090526957=:89751" --0-170230013-1090526957=:89751 Content-Type: text/plain; charset=us-ascii Hi, I have a clarification on the use of throttle in sending NOTIFY messages while using "eventlist" extension where user can subscribe to multiple presenties in a single Subscribe using Buddy List Uri. Consider the case of a User subscribing to 100 presentites in one subscription using a SIP entity let's say "Buddy list" with a valid sip uri. Subscribing to this list will result in notification for status of all the 100 presentities. It may not be possible to send the status of all presentities in a single NOTIFY, so Notifier may have to send multiple NOTIFY messages in this case. Does the Notifier need to use "throttle value" between 2 Notifications provided its sent by client in Event header parameter of SUBSCRIBE request ? Once NOTIFYs are sent for initial SUBSCRIBE, and this subscription is for a longer duration, any changes in presentites's status will be sent as NOTIFY containing only updated status. If there are cases like notifier sends one NOTIFY with changed status of one presentity belonging to buddy list and detects change in status of another presentity of buddy list, he needs to send another NOTIFY. Can throttle value be used in this case too ?? Thanks --------------------------------- Do you Yahoo!? Vote for the stars of Yahoo!'s next ad campaign! --0-170230013-1090526957=:89751 Content-Type: text/html; charset=us-ascii
Hi,
 
I  have a clarification on the use of throttle in sending NOTIFY messages while using "eventlist" extension where user can subscribe to multiple presenties in a single Subscribe using Buddy List Uri.
 
Consider the case of a User subscribing to 100 presentites in one subscription using a SIP entity let's say "Buddy list" with a valid sip uri. Subscribing to this list will result in notification for status of all the 100 presentities. It may not be possible to send the status of all presentities in a single NOTIFY, so Notifier may have to send multiple NOTIFY messages in this case.
Does the Notifier need to use "throttle value" between 2 Notifications provided its sent by client in Event header parameter of SUBSCRIBE request ?
 
Once NOTIFYs are sent for initial SUBSCRIBE, and this subscription is for a longer duration, any changes in presentites's status will be sent as NOTIFY containing only updated status.
If there are cases like notifier sends one NOTIFY with changed status of one presentity belonging to buddy list and detects change in status of another presentity of buddy list, he needs to send another NOTIFY. Can throttle value be used in this case too ??
 
Thanks
 
 

 

Do you Yahoo!?
Vote for the stars of Yahoo!'s next ad campaign! --0-170230013-1090526957=:89751-- --===============0994451682== 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 --===============0994451682==-- From simple-bounces@ietf.org Fri Jul 23 14:07:43 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14966; Fri, 23 Jul 2004 14:07:43 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bo4TA-0003SA-Jv; Fri, 23 Jul 2004 14:08:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bo4NI-0004tm-Ik; Fri, 23 Jul 2004 14:02:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bo4Ku-0003uf-55 for simple@megatron.ietf.org; Fri, 23 Jul 2004 14:00:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14388 for ; Fri, 23 Jul 2004 13:59:59 -0400 (EDT) Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bo4Lh-0003HF-PO for simple@ietf.org; Fri, 23 Jul 2004 14:00:51 -0400 Received: from dynamicsoft.com ([63.113.46.16]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i6NHx0eE001545; Fri, 23 Jul 2004 13:59:00 -0400 (EDT) Message-ID: <410151CD.2090001@dynamicsoft.com> Date: Fri, 23 Jul 2004 13:58: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: Henning Schulzrinne Subject: Re: [Simple] Address and person URIs References: <40F97472.7030006@cs.columbia.edu> <40FBCF13.8010308@dynamicsoft.com> <40FC2731.3080801@cisco.com> <40FC40D8.3090103@cs.columbia.edu> <40FC5C50.2080708@cisco.com> <40FDE0EE.3000603@dynamicsoft.com> <40FEB3DC.3050104@cisco.com> <40FEBFCD.8020109@cs.columbia.edu> In-Reply-To: <40FEBFCD.8020109@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Cc: Paul Kyzivat , 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-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit inline. Henning Schulzrinne wrote: >> I am fine with that, although it may be difficult to register such a >> uri scheme. >> > > In a different context (emergency services and tel URIs), I've thought > about a 'service' URI which indicates a generic content-oriented > communication service. This addresses the current deficiency of the tel > URI (really, URN) that can't express services nicely. > > There may be a connnection there, i.e., > > urn:service:inperson To be clear, is your intent here that urn:service would be defined as allowing registered values through an IANA registry or something? i.e., if I come up with a new service, foo, I could register it and thus urn:service:foo would be defined? I'm not sure how one would properly define the scope of "service" in such a context... -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 Jul 23 15:07:55 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19293; Fri, 23 Jul 2004 15:07:55 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bo5PT-0004Zc-UP; Fri, 23 Jul 2004 15:08:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bo5HJ-0006Cu-WB; Fri, 23 Jul 2004 15:00:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bo5FQ-00044i-UU for simple@megatron.ietf.org; Fri, 23 Jul 2004 14:58:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18487 for ; Fri, 23 Jul 2004 14:58:23 -0400 (EDT) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bo5GF-0004QG-1n for simple@ietf.org; Fri, 23 Jul 2004 14:59:16 -0400 Received: from panther.cs.columbia.edu (IDENT:vvBnbJzre8rrRQTYBr0oU3ufXYUcBGos@panther.cs.columbia.edu [128.59.16.122]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i6NIwBfq021436 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Fri, 23 Jul 2004 14:58:11 -0400 (EDT) Received: from [128.59.16.206] (chairpc.cs.columbia.edu [128.59.16.206]) by panther.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id i6NIwAHr028614; Fri, 23 Jul 2004 14:58:11 -0400 Message-ID: <41015FC2.4040701@cs.columbia.edu> Date: Fri, 23 Jul 2004 14:58:10 -0400 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Simple] Address and person URIs References: <40F97472.7030006@cs.columbia.edu> <40FBCF13.8010308@dynamicsoft.com> <40FC2731.3080801@cisco.com> <40FC40D8.3090103@cs.columbia.edu> <40FC5C50.2080708@cisco.com> <40FDE0EE.3000603@dynamicsoft.com> <40FEB3DC.3050104@cisco.com> <40FEBFCD.8020109@cs.columbia.edu> <410151CD.2090001@dynamicsoft.com> In-Reply-To: <410151CD.2090001@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 4.6.1.106153, Antispam-Core: 4.6.1.104326, Antispam-Data: 2004.7.23.108397 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, __NEW_DOMAIN_EXTENSIONS_2 0, QUOTED_EMAIL_TEXT 0, __MIME_TEXT_ONLY 0, REFERENCES 0.000, IN_REP_TO 0, USER_AGENT 0.000' X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit Cc: Paul Kyzivat , 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-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit > To be clear, is your intent here that urn:service would be defined as > allowing registered values through an IANA registry or something? i.e., > if I come up with a new service, foo, I could register it and thus > urn:service:foo would be defined? Yes. > > I'm not sure how one would properly define the scope of "service" in > such a context... Depends on what you mean by "scope". If you mean "what does the foo service really mean, i.e., what do I get", I'd punt: the registrant defines the meaning of the service. I had one simple model in mind: Define by resolution. Each service is associated with a DNS resolving hierarchy, e.g., urn:service:sos.arpa is the service defined by the DNS resolution mechanism sos.arpa. The assumption is that any proxy that resolves this domain has to know what request information is necessary to do the resolution, e.g., by location or other request property. This doesn't necessarily fit the 'real human being' one all that well, but some other services, including urn:service:pizzahut urn:service:directory-service work reasonably well, as long as each service can agree on a resolution mechanism. This is somewhat akin to an IP-level anycast service: "I want any suitable instance of this service and you figure out what that might be". This is obviously very rough thinking at this stage. As has been pointed out in private email, it is not clear that the URN definition matches this particularly well. However, one could argue that something like an ISBN URN has somewhat similar properties, albeit with a much more precise contract as to what one might get back. Henning _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jul 23 19:49:43 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04666; Fri, 23 Jul 2004 19:49:43 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bo9oE-0008LD-Mp; Fri, 23 Jul 2004 19:50:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bo9hx-0001C0-Qk; Fri, 23 Jul 2004 19:44:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bo9f6-0000OZ-QS for simple@megatron.ietf.org; Fri, 23 Jul 2004 19:41:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04444 for ; Fri, 23 Jul 2004 19:41:11 -0400 (EDT) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bo9fx-0008Gv-AW for simple@ietf.org; Fri, 23 Jul 2004 19:42:06 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.191); Fri, 23 Jul 2004 16:42:01 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 23 Jul 2004 16:40:33 -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 Date: Fri, 23 Jul 2004 16:40:31 -0700 Message-ID: Thread-Topic: UPDATED draft-levin-simple-interdomain-reqs-01.txt Thread-Index: AcRxDnFOtWdJqm9uTeedrLuhlxpUpA== From: "Orit Levin" To: X-OriginalArrivalTime: 23 Jul 2004 23:40:33.0013 (UTC) FILETIME=[720CAA50:01C4710E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: quoted-printable Cc: Avshalom Houri , Edwin Aoki Subject: [Simple] UPDATED draft-levin-simple-interdomain-reqs-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-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: quoted-printable Guys, We have submitted a new revised version of the "inter-domain profile and requirements" draft. We are not going to request for a lot to discuss the content of this draft during the busy San Diego meeting. Instead, please, read the draft and send all your comments to the list. Thanks, Orit.=20 ________________________________________ A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Inter-domain Requirements for SIMPLE Author(s) : O. Levin, et al. Filename : draft-levin-simple-interdomain-reqs-01.txt Pages : 18 Date : 2004-7-21 =09 This document identifies a SIP/SIMPLE profile for inter-domain communications and documents best current practices regarding security and 'good citizenship' behavior that operators should use when interconnecting SIP/SIMPLE clouds. The purpose of this document is to serve as the reference for the SIP/SIMPLE community towards inter-domain interoperability and also to identify new requirements specific to the inter-domain interface. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-levin-simple-interdomain-reqs- 01.txt To remove yourself from the I-D Announcement list, send a message to=20 i-d-announce-request at ietf.org with the word unsubscribe in the body of the message. =20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20 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-levin-simple-interdomain-reqs-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jul 23 19:59:12 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04878; Fri, 23 Jul 2004 19:59:12 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bo9xP-0008Op-MW; Fri, 23 Jul 2004 20:00:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bo9vP-0003rs-TR; Fri, 23 Jul 2004 19:58:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bo9vB-0003gj-TS for simple@megatron.ietf.org; Fri, 23 Jul 2004 19:57:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04838 for ; Fri, 23 Jul 2004 19:57:48 -0400 (EDT) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bo9w2-0008O4-F1 for simple@ietf.org; Fri, 23 Jul 2004 19:58:43 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.191); Fri, 23 Jul 2004 16:57:16 -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, 23 Jul 2004 16:57:49 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 23 Jul 2004 16:57:14 -0700 Message-ID: Thread-Topic: syntax in draft-ietf-simple-cipid-03 Thread-Index: AcRxEMa4VR1BJ5VcRjOeIuV81gC1hQ== From: "Orit Levin" To: "Henning Schulzrinne" X-OriginalArrivalTime: 23 Jul 2004 23:57:49.0761 (UTC) FILETIME=[DBFFDB10:01C47110] X-Spam-Score: 0.1 (/) X-Scan-Signature: 43317e64100dd4d87214c51822b582d1 Cc: simple@ietf.org Subject: [Simple] syntax in draft-ietf-simple-cipid-03 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.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="===============2046157831==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: 17e5edc4dfd335965c1d21372171c01c This is a multi-part message in MIME format. --===============2046157831== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C47110.C6FF977E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C47110.C6FF977E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Henning, The new appears in the text of draft-ietf-simple-cipid-03 but was unfortunately omitted from the XML schema. I would like to confirm the right syntax of the by running the following example through you and the list: =20 open on-the-phone sip:tom-pc@example.com Tom Jones Tom Jones =20 Is this compliant with the XML schema that will be included in the next version? =20 Thanks a lot, Orit. =20 ------_=_NextPart_001_01C47110.C6FF977E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 
Henning,
The new =
<display-element> appears in the text of =
draft-ietf-simple-cipid-03 but was unfortunately omitted from the XML =
schema.
I would =
like to confirm the right syntax of the <display-name> by running =
the following example through you and the =
list:
 
    <?xml =
version=3D"1.0" =
encoding=3D"UTF-8"?>
       &nbs=
p; <presence =
xmlns=3D"urn:ietf:params:xml:ns:pidf"
<=
font
size=3D2 face=3D"Courier New">       &nbs=
p;           =
xmlns:es=3D"urn:ietf:params:xml:ns:pidf:rpid-status"
        =
           xmlns:c=
i=3D"urn:ietf:params:xml:ns:pidf:cipid"
       &nbs= p;  = entity=3D"sip:t-jones@example.com">
=
       &nbs=
p;   <tuple =
id=3D"0">
       &nbs=
p;     <status>
       &nbs=
p;       =
<basic>open</basic>
       &nbs=
p;            =
; <es:activities>
       &nbs=
p;       =
<es:activity>on-the-phone</es:activity>
       &nbs= p;     = </es:activities>
       &nbs=
p;     </status>
       &nbs=
p;     =
<contact>sip:tom-pc@example.com</contact>
= 
       &nbs=
p;     <ci:display-name>Tom =
Jones</ci:display-name>
       &nbs=
p;   </tuple>
       &nbs=
p;   <ci:display-name>Tom =
Jones</ci:display-name>
       &nbs=
p; </presence>
 
Is this =
compliant with the XML schema that will be included in the next =
version?
 
Thanks a =
lot,
Orit.

 

------_=_NextPart_001_01C47110.C6FF977E-- --===============2046157831== 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 --===============2046157831==-- From simple-bounces@ietf.org Fri Jul 23 21:29:15 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08687; Fri, 23 Jul 2004 21:29:15 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BoBMY-00010Y-H6; Fri, 23 Jul 2004 21:30:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BoBJg-0005e8-5s; Fri, 23 Jul 2004 21:27:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BoBA0-00047q-Ga for simple@megatron.ietf.org; Fri, 23 Jul 2004 21:17:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08353 for ; Fri, 23 Jul 2004 21:17:10 -0400 (EDT) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BoBAp-0000uh-0Q for simple@ietf.org; Fri, 23 Jul 2004 21:18:07 -0400 Received: from razor.cs.columbia.edu (IDENT:g6ZsjcZRNMzpA6LYmMnFGu30BH9fiv7F@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i6O1H1fq025704 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Fri, 23 Jul 2004 21:17:02 -0400 (EDT) Received: from [127.0.0.1] (IDENT:GDkHhiLNMJzknBTLfI+6Cp0MXWKCYbzs@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i6O1H1jd008946; Fri, 23 Jul 2004 21:17:01 -0400 Message-ID: <4101B88D.1050508@cs.columbia.edu> Date: Fri, 23 Jul 2004 21:17:01 -0400 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 0.7.1 (Windows/20040626) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Orit Levin References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 4.6.1.106153, Antispam-Core: 4.6.1.104326, Antispam-Data: 2004.7.23.108434 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' X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: 7bit Cc: simple@ietf.org Subject: [Simple] Re: syntax in draft-ietf-simple-cipid-03 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: 7bit Oops - I had updated the schema, but not copied it into the draft. (If somebody knows how to include files within CDATA, let me know...). You can see the schema at http://www.cs.columbia.edu/sip/draft/cipid/cipid.xsd Extensions in PIDF appear before , so your tuple example is slightly wrong, since the PIDF schema reads, in part, Thanks for catching this. Orit Levin wrote: > Henning, > > The new appears in the text of draft-ietf-simple-cipid-03 but was unfortunately omitted from the XML schema. > > I would like to confirm the right syntax of the by running the following example through you and the list: > > > > > > > xmlns:es="urn:ietf:params:xml:ns:pidf:rpid-status" > > xmlns:ci="urn:ietf:params:xml:ns:pidf:cipid" > > entity="sip:t-jones@example.com"> > > > > > > open > > > > on-the-phone > > > > > > sip:tom-pc@example.com > > Tom Jones > > > > Tom Jones > > > > > > Is this compliant with the XML schema that will be included in the next version? > > > > Thanks a lot, > > Orit. > > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jul 26 05:56:53 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11812; Mon, 26 Jul 2004 05:56:53 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bp2FR-00037a-FG; Mon, 26 Jul 2004 05:58:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bp2Bq-00025y-LC; Mon, 26 Jul 2004 05:54:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bp2BF-0001ze-St for simple@megatron.ietf.org; Mon, 26 Jul 2004 05:54:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11709 for ; Mon, 26 Jul 2004 05:53:59 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bp2Cb-00035Q-UL for simple@ietf.org; Mon, 26 Jul 2004 05:55:27 -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 i6Q9rwh04623 for ; Mon, 26 Jul 2004 12:53:58 +0300 (EET DST) X-Scanned: Mon, 26 Jul 2004 12:53:37 +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 i6Q9rbaw023028 for ; Mon, 26 Jul 2004 12:53:37 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00ty2Jtw; Mon, 26 Jul 2004 12:53:35 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 i6Q9rYn13073 for ; Mon, 26 Jul 2004 12:53:34 +0300 (EET DST) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 26 Jul 2004 12:53:35 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 26 Jul 2004 12:53:34 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Date: Mon, 26 Jul 2004 12:53:34 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7023EEB6E@esebe019.ntc.nokia.com> Thread-Topic: WGLC: XCAP Usage for Manipulating Presence Document Contents Thread-Index: AcRy9mnVYL8o8t/mTcySzuHzSzCl3w== To: X-OriginalArrivalTime: 26 Jul 2004 09:53:34.0403 (UTC) FILETIME=[6A4AE130:01C472F6] X-Spam-Score: 0.3 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: quoted-printable Subject: [Simple] WGLC: XCAP Usage for Manipulating Presence Document Contents X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: quoted-printable The WG chairs would like to start a Working Group Last Call on the = following internet draft as part of the SIMPLE Data Manipulation work to = be submitted to IESG: http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-pidf-manipulat= ion-usage-01.txt This WGLC is 2 weeks long and will end on August 8th. Please send your comments to this mailing list and to the authors.=20 If you reviewed the draft and found no issues, please indicate so on the = mailing list. This will help us evaluate the level of review and group = consensus. Thanks, Hisham _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jul 26 06:27:25 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12880; Mon, 26 Jul 2004 06:27:24 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bp2iz-0003Ub-G7; Mon, 26 Jul 2004 06:28:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bp2fo-0006ry-0i; Mon, 26 Jul 2004 06:25:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bp2fQ-0006ju-9u for simple@megatron.ietf.org; Mon, 26 Jul 2004 06:25:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12812 for ; Mon, 26 Jul 2004 06:25:09 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bp2gm-0003T0-Kv for simple@ietf.org; Mon, 26 Jul 2004 06:26:38 -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 i6QAP3h20839 for ; Mon, 26 Jul 2004 13:25:03 +0300 (EET DST) X-Scanned: Mon, 26 Jul 2004 13:24:53 +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 i6QAOrnV007441 for ; Mon, 26 Jul 2004 13:24:53 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00RNqm4t; Mon, 26 Jul 2004 13:24: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 i6QAOqu12639 for ; Mon, 26 Jul 2004 13:24:52 +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); Mon, 26 Jul 2004 13:24:47 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Date: Mon, 26 Jul 2004 13:24:47 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7023EEB71@esebe019.ntc.nokia.com> Thread-Topic: SIMPLE WG Agenda at IETF 60 Thread-Index: AcRy+sZQmulo3h4OTDyi8iC/DjtN1w== To: X-OriginalArrivalTime: 26 Jul 2004 10:24:47.0535 (UTC) FILETIME=[C6C423F0:01C472FA] X-Spam-Score: 0.3 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Content-Transfer-Encoding: quoted-printable Subject: [Simple] SIMPLE WG Agenda at IETF 60 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: quoted-printable It can be found at: http://www.softarmor.com/simple/meets/ietf60/agenda.html Regards, Hisham _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jul 26 09:22:12 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24517; Mon, 26 Jul 2004 09:22:12 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bp5S8-0006be-Sv; Mon, 26 Jul 2004 09:23:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bp5JQ-0006Gf-OD; Mon, 26 Jul 2004 09:14:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bp58C-0004YP-1D for simple@megatron.ietf.org; Mon, 26 Jul 2004 09:03:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22771 for ; Mon, 26 Jul 2004 09:03:02 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bp59X-00067m-Ib for simple@ietf.org; Mon, 26 Jul 2004 09:04:30 -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 i6QD2wk20388 for ; Mon, 26 Jul 2004 16:02:58 +0300 (EET DST) X-Scanned: Mon, 26 Jul 2004 16:02: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 i6QD2oBN012614 for ; Mon, 26 Jul 2004 16:02:50 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00ohTk6S; Mon, 26 Jul 2004 16:02:48 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 i6QD2gn26729 for ; Mon, 26 Jul 2004 16:02:42 +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, 26 Jul 2004 16:02:37 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Date: Mon, 26 Jul 2004 16:02:37 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7023EEB78@esebe019.ntc.nokia.com> Thread-Topic: IESG comments on is-composing draft Thread-Index: AcRzENM/pLhz6yRVTjaXyfCp07mqVQ== To: X-OriginalArrivalTime: 26 Jul 2004 13:02:38.0089 (UTC) FILETIME=[D3A7FF90:01C47310] X-Spam-Score: 0.3 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: quoted-printable Subject: [Simple] IESG comments on is-composing 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: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: quoted-printable The IESG has reviewed the is-composing draft, and there were some minor = comments which require an update to the draft. The comments can be found = in the issue-tracker at: https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dview_id&dTag= =3D11689&rfc_flag=3D0 Regards, Hisham _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jul 26 14:32:05 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22037; Mon, 26 Jul 2004 14:32:05 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BpAI4-0002uH-P5; Mon, 26 Jul 2004 14:33:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bp9sT-0001zY-5t; Mon, 26 Jul 2004 14:07:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bp9YP-0004HX-Qq for simple@megatron.ietf.org; Mon, 26 Jul 2004 13:46:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16062 for ; Mon, 26 Jul 2004 13:46:24 -0400 (EDT) Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bp9Zp-00010o-P2 for simple@ietf.org; Mon, 26 Jul 2004 13:47:55 -0400 Received: from dynamicsoft.com ([63.113.46.52]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i6QHj7eE004084; Mon, 26 Jul 2004 13:45:07 -0400 (EDT) Message-ID: <4105430F.1070509@dynamicsoft.com> Date: Mon, 26 Jul 2004 13:44:47 -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] Address and person URIs References: <40F97472.7030006@cs.columbia.edu> <40FBCF13.8010308@dynamicsoft.com> <40FC2731.3080801@cisco.com> <40FC40D8.3090103@cs.columbia.edu> <40FC5C50.2080708@cisco.com> <40FDE0EE.3000603@dynamicsoft.com> <40FEB3DC.3050104@cisco.com> <40FEBFCD.8020109@cs.columbia.edu> <410151CD.2090001@dynamicsoft.com> <41015FC2.4040701@cs.columbia.edu> In-Reply-To: <41015FC2.4040701@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: 7bit Cc: Paul Kyzivat , 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-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: 7bit inline. Henning Schulzrinne wrote: >> >> I'm not sure how one would properly define the scope of "service" in >> such a context... > > > Depends on what you mean by "scope". If you mean "what does the foo > service really mean, i.e., what do I get", I'd punt: the registrant > defines the meaning of the service. No. What I meant was, what are the set of things for which it would be valid for me to register wtihin this namespace. For example, is this OK: urn:service:dog-washing-service Or how about this: urn:service:soap-binding:method-name "service" is sufficiently broad that there is almost nothing that ISNT a service by someones definition... > > I had one simple model in mind: Define by resolution. Each service is > associated with a DNS resolving hierarchy, e.g., > > urn:service:sos.arpa > > is the service defined by the DNS resolution mechanism sos.arpa. The > assumption is that any proxy that resolves this domain has to know what > request information is necessary to do the resolution, e.g., by location > or other request property. Not sure I follow here. I was hoping to avoid anything that actually requires resolution in the dns. I think this increases complexity well beyond what we need for the problem at hand. > > This doesn't necessarily fit the 'real human being' one all that well, > but some other services, including > > urn:service:pizzahut > urn:service:directory-service > > work reasonably well, as long as each service can agree on a resolution > mechanism. This is somewhat akin to an IP-level anycast service: "I want > any suitable instance of this service and you figure out what that might > be". Well, I just think that this is a problem for someone else to solve... -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 Jul 26 14:34:54 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22484; Mon, 26 Jul 2004 14:34:54 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BpAKn-00033M-5A; Mon, 26 Jul 2004 14:36:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BpA8r-0007W5-1l; Mon, 26 Jul 2004 14: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 1Bp9hY-0006uK-LP for simple@megatron.ietf.org; Mon, 26 Jul 2004 13:55:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17281 for ; Mon, 26 Jul 2004 13:55:51 -0400 (EDT) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bp9iy-0001Mm-QJ for simple@ietf.org; Mon, 26 Jul 2004 13:57:22 -0400 Received: from panther.cs.columbia.edu (IDENT:w/0ChR/fT7oA/IhQ4bkN59a0NUKz3eEd@panther.cs.columbia.edu [128.59.16.122]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i6QHthlD011968 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Mon, 26 Jul 2004 13:55:44 -0400 (EDT) Received: from [128.59.16.206] (chairpc.cs.columbia.edu [128.59.16.206]) by panther.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id i6QHthHr024691; Mon, 26 Jul 2004 13:55:43 -0400 Message-ID: <4105459F.5040207@cs.columbia.edu> Date: Mon, 26 Jul 2004 13:55:43 -0400 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com Subject: Re: [Simple] IESG comments on is-composing draft References: <2038BCC78B1AD641891A0D1AE133DBB7023EEB78@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB7023EEB78@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 4.6.1.106153, Antispam-Core: 4.6.1.104326, Antispam-Data: 2004.7.25.108501 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, __MIME_TEXT_ONLY 0, REFERENCES 0.000, IN_REP_TO 0, USER_AGENT 0.000' X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 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-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit I've tried to address most of these comments in a revised working version, http://www.cs.columbia.edu/sip/draft/iscomposing/draft-ietf-simple-iscomposing-03.html In particular, references to SDP have been removed since the details are likely to depend strongly on the particulars of the session mode protocol. For example, in MSRP, a new a: element negotiates the content types, rather than using the standard m-line mechanism. Clearly, SDPng or some non-SIP protocol would be different yet again. Since this is really just another media type, it does not seem particularly helpful to repeat how to do negotiation for each such session-mode protocol. hisham.khartabil@nokia.com wrote: > The IESG has reviewed the is-composing draft, and there were some minor comments which require an update to the draft. The comments can be found in > the issue-tracker at: > > https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=11689&rfc_flag=0 > > 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 Tue Jul 27 08:22:08 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08807; Tue, 27 Jul 2004 08:22:08 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BpQzl-0006hh-Cg; Tue, 27 Jul 2004 08:23:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BpQwP-0005P6-Ul; Tue, 27 Jul 2004 08:20:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BpQt3-0004yi-IU for simple@megatron.ietf.org; Tue, 27 Jul 2004 08:16:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08548 for ; Tue, 27 Jul 2004 08:16:52 -0400 (EDT) Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BpQud-0006cj-Ro for simple@ietf.org; Tue, 27 Jul 2004 08:18:33 -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 i6RCGnD19582 for ; Tue, 27 Jul 2004 15:16:49 +0300 (EET DST) X-Scanned: Tue, 27 Jul 2004 15:16:45 +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 i6RCGjiY013425 for ; Tue, 27 Jul 2004 15:16:45 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00gVX8CO; Tue, 27 Jul 2004 15:16:39 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 i6RCGVn12331 for ; Tue, 27 Jul 2004 15:16:31 +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); Tue, 27 Jul 2004 15:16:29 +0300 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 27 Jul 2004 15:16:28 +0300 Received: esebe013.ntc.nokia.com 172.21.138.52 from 172.21.81.16 172.21.81.16 via HTTP with MS-WebStorage 6.0.6249 Received: from esdhcp09nok08116.ntc.nokia.com by esebe013.ntc.nokia.com; 27 Jul 2004 15:16:29 +0300 Subject: Re: [Simple] Regarding throttle for notifications From: Aki Niemi To: ext kamal Rometra In-Reply-To: <20040722200917.92239.qmail@web90102.mail.scd.yahoo.com> References: <20040722200917.92239.qmail@web90102.mail.scd.yahoo.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Nokia-M/Espoo Message-Id: <1090930588.3723.21.camel@esdhcp09nok08116.ntc.nokia.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 27 Jul 2004 15:16:29 +0300 X-OriginalArrivalTime: 27 Jul 2004 12:16:28.0863 (UTC) FILETIME=[8B7B64F0:01C473D3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 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-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: 7bit Hi, Inline. On Thu, 2004-07-22 at 23:09, ext kamal Rometra wrote: > Hi, > > I have a clarification on the use of throttle in sending NOTIFY > messages while using "eventlist" extension where user can subscribe to > multiple presenties in a single Subscribe using Buddy List Uri. > > Consider the case of a User subscribing to 100 presentites in one > subscription using a SIP entity let's say "Buddy list" with a valid > sip uri. Subscribing to this list will result in notification for > status of all the 100 presentities. It may not be possible to send the > status of all presentities in a single NOTIFY, so Notifier may have to > send multiple NOTIFY messages in this case. > Does the Notifier need to use "throttle value" between 2 Notifications > provided its sent by client in Event header parameter of SUBSCRIBE > request ? Yes, if one was provided by the subscriber and accepted by the notifier. > Once NOTIFYs are sent for initial SUBSCRIBE, and this subscription is > for a longer duration, any changes in presentites's status will be > sent as NOTIFY containing only updated status. > If there are cases like notifier sends one NOTIFY with changed status > of one presentity belonging to buddy list and detects change in status > of another presentity of buddy list, he needs to send another NOTIFY. > Can throttle value be used in this case too ?? The event list draft actually already talks about this. In order to rate limit, the notifier may buffer resource state notifications and send them in batches (i.e., a single RLMI body, and one or more individual notifications of resource state sent in a multipart/related MIME body). The throttle value merely indicates the rate limit imposed by the subscriber, which the notifier can use to implement this batching of notifications. Another thing to consider is whether the list notifications contain full or partial state. As explained in the throttle draft [1], there are two alternative buffering policies that the notifier can use, depending on the notification type. If operating in full-state mode, each arriving notification simply overwrites any previously buffered notifications. If operating in partial-state mode, the state of the arriving notification needs to be merged with any previously buffered notification. Cheers, Aki [1] http://www.ietf.org/internet-drafts/draft-niemi-sipping-event-throttle-01.txt > > Thanks > > > > > > ______________________________________________________________________ > Do you Yahoo!? > Vote for the stars of Yahoo!'s next ad campaign! > > ______________________________________________________________________ > _______________________________________________ > Simple mailing 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 Jul 27 13:37:27 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01099; Tue, 27 Jul 2004 13:37:27 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BpVuv-0004oG-Tb; Tue, 27 Jul 2004 13:39:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BpVpM-0004t8-4g; Tue, 27 Jul 2004 13: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 1BpVmN-0004Po-Il for simple@megatron.ietf.org; Tue, 27 Jul 2004 13:30:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00760 for ; Tue, 27 Jul 2004 13:30:18 -0400 (EDT) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BpVo0-0004hw-FS for simple@ietf.org; Tue, 27 Jul 2004 13:32:02 -0400 Received: from panther.cs.columbia.edu (IDENT:jEmm31pCoku4iQvDn+99naP97qsutCWq@panther.cs.columbia.edu [128.59.16.122]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i6RHU1lD017964 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Tue, 27 Jul 2004 13:30:01 -0400 (EDT) Received: from [128.59.16.206] (chairpc.cs.columbia.edu [128.59.16.206]) by panther.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id i6RHU0Hr003466; Tue, 27 Jul 2004 13:30:00 -0400 Message-ID: <41069118.6090603@cs.columbia.edu> Date: Tue, 27 Jul 2004 13:30:00 -0400 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Simple] Address and person URIs References: <40F97472.7030006@cs.columbia.edu> <40FBCF13.8010308@dynamicsoft.com> <40FC2731.3080801@cisco.com> <40FC40D8.3090103@cs.columbia.edu> <40FC5C50.2080708@cisco.com> <40FDE0EE.3000603@dynamicsoft.com> In-Reply-To: <40FDE0EE.3000603@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 4.6.1.106153, Antispam-Core: 4.6.1.104326, Antispam-Data: 2004.7.26.108628 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' X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Content-Transfer-Encoding: 7bit Cc: Paul Kyzivat , 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-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Content-Transfer-Encoding: 7bit Maybe the right model is to use a scheme, as in inperson: Schemes can define any means of communication. Indeed, URIs like mailto: (or im:) don't directly define protocols, but rather modes of communication. We already have common, albeit non-standard, URIs such as about: without any further elements. One could generalize this to inperson:some-identifier where the identifier is only locally defined (e.g., it's just the presentity URI in our case), with no global semantics. Jonathan Rosenberg wrote: > I'm fine to punt, but I think this is a case where the perfect is a > serious enemy of the good. > > I think that a service URI of the form: > > uri:inperson > > is sufficient, without any additional per-user data. We can leave it to > the human to figure out how to resolve the URI. Indeed, the presentity > placetype (home, work, etc.) would probably suffice, since a watcher > can ususally infer how to find them within that place. We just need a > way to say, "come talk to me". Does that cover EVERY case? No way. Does > it cover many of the important ones? Yes. > > -Jonathan R. > > Paul Kyzivat wrote: > >> >> >> Henning Schulzrinne wrote: >> >>>> >>>> Well, a place isn't always sufficient. We see this all the time in >>>> the movies: "Meet me in the bar of tha Acme Hotel at 7pm on April 1, >>>> 2005. I'll have a red carnation in my lapel." >>> >>> >>> >>> I suspect that one of the desirable properties would be that the >>> person doesn't change identifiers just because they changed location. >>> If you don't do that, it will get very confusing - is this URI the >>> same person at a different location or a completely different person? >>> (Imagine a friend finder service that works in physical space.) >>> >>> There is also the issue that you now have two ways to represent >>> "location of a presentity", as a URI or as PIDF-LO, with contact >>> information also available as a vCard. >>> >>>> So we don't need a *globally* unique person identifier. We need a >>>> person identifier that is locally unique in the context of the time >>>> and location of the intended meeting. And the time is important too. >>>> >>>> The time we can deal with. With regular status it is NOW. We can use >>>> timed-status to cover some other time. >>>> >>>> I don't think location has to be part of the Contact, as long as it >>>> is provided as part of the (timed-)status along with the contact. >>>> >>>> Coming up with URIs for identifying people locally within a >>>> particular time-space region sounds like future research. Sounds >>>> like some sort of arbitary predicate would do the trick. >>> >>> >>> >>> Do you want to define people by a game of twenty questions? >> >> >> >> Well, it would be easier if everyone just agreed to have a barcode >> branded on their forehead and an RFID chip embedded in them, each >> containing their UN assigned global person UUID. >> >> But I sense a lot of people don't want to be so easily or irrevokably >> identifiable. So weak forms of identification may be all that is >> generally acceptable. (Hence "I'll have a red carnation in my lapel" >> rather than "The SSN on my forehead will be 123-56-7890.") >> >> Unfortunately, this doesn't lend itself well to URIs or URNs, because >> the information isn't Unique. >> >> I think we continue to punt this one for now. >> >> Paul >> > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jul 28 04:59:17 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15437; Wed, 28 Jul 2004 04:59:16 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BpkJB-0002EE-He; Wed, 28 Jul 2004 05:01:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BpkAi-0007uI-MK; Wed, 28 Jul 2004 04:52:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bpk6X-0007A3-Vd for simple@megatron.ietf.org; Wed, 28 Jul 2004 04:48:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15070 for ; Wed, 28 Jul 2004 04:48:04 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bpk8K-00024L-C7 for simple@ietf.org; Wed, 28 Jul 2004 04:49:56 -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 i6S8m1m18924; Wed, 28 Jul 2004 11:48:01 +0300 (EET DST) X-Scanned: Wed, 28 Jul 2004 11:47:19 +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 i6S8lJn1021972; Wed, 28 Jul 2004 11:47:19 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00RDNzU5; Wed, 28 Jul 2004 11:47:17 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 i6S8lGn25193; Wed, 28 Jul 2004 11:47:16 +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, 28 Jul 2004 11:47:10 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Date: Wed, 28 Jul 2004 11:47:07 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7023EEB8B@esebe019.ntc.nokia.com> Thread-Topic: Comments on draft-ietf-somple-xcap-03 Thread-Index: AcR0f3d9gG7jG72bTy64sXITwYa8Qw== To: X-OriginalArrivalTime: 28 Jul 2004 08:47:10.0226 (UTC) FILETIME=[785D3720:01C4747F] X-Spam-Score: 0.3 (/) X-Scan-Signature: a3f7094ccc62748c06b21fcf44c073ee Content-Transfer-Encoding: quoted-printable Cc: jdrosen@dynamicsoft.com Subject: [Simple] Comments on draft-ietf-somple-xcap-03 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 0bb031f3a6fb29f760794ac9bf1997ae Content-Transfer-Encoding: quoted-printable Most of the comments are nits. When fixed, I believe the draft is ready. Section 1 ---------- - 1st para: s/by the end user themselves/by end users themselves - 2nd para: 2x presence list mentioned. Change to resource list. Also = add a reference. - 2nd para: s/for the list of is to/for the list is to - 3rd para: "specified by the SIMPLE working group". I suggest removing = reference to the working group, unless you believe it will exist for = ever an all readers of the RFC will know about it ;) Section 2 ---------- - 1st para: Change "The principal task of XCAP is to allow clients to read, write, modify, create and delete pieces of that data." to=20 "The principal task of XCAP is to allow clients to read, write, modify, create and delete all or pieces of that data." - 1st para: s/XCAP points a document/XCAP points to a document Section 5.1 ------------ - 1st para: s/name name/name Section 5.4 ------------ - Second para: "As an example, the RLS services application usage allows an RLS to obtain the contents of a resource list when the RLS receives a SUBSCRIBE request for a SIP URI identifying an RLS service. The application usage specifies that the list of service definitions is present within a specific document with a specific name within the global tree. This allows the RLS to perform a single XCAP request to fetch the service definition for the service associated with the SIP URI in a SUBSCRIBE request." I could not understand this paragraph. What is it trying to say? From = what I read it is trying to say that a SIP URI can be used to derive the = XCAP URI to fetch the document from the XCAP server. Clearly wrong, but = that's what I read. Please rephrase this paragraph (I would suggest text = if I knew what it is trying to say). Section 6 ---------- - 1st para: s/with a escape coded/with an escape coded - 1st para: s/It is piece of/It is a piece of Section 6.3 ------------ - I believe it is beneficial for the double forward slash // be = available in the BNF. It means all occurrences of the element in the = document. For example "//watcher" means all watcher elements. Therefore not requiring all the = elements on the path to the watcher element to be included. An xcap PUT example would be: PUT = http://xcap.example.com/services/resource-list/users/bill/fr.xml/~~//list= [@name"friends"] If this is adopted, then you need to modify the sentences later in the = chapter that discuss context and child elements. - The node-selector does not contain the leading forward slash "/"? An = XCAP URI takes the form http://xcaproot/document/~~/node-selector Where are the / before and after ~~ defined. Maybe something in section = 6 is needed. "The URI is constructed by concatenating the XCAP root with the document selector with the path separator with a escape coded form of the node selector. A forward slash "/" is placed = between each concatenation" - 4th para: s/MUST be escaped coded/MUST be escape coded - 5th para: s/discussions an examples/discussions and examples - 8th para: says that an element name can be wildcarded. I believe it is = important to add text saying that even when a wildcard is used, the = element must still be unique. - 12 para: It says that "If the result is a no-match, the node selector = is invalid". This is incorrect. no-match is not the same an invalid as = far as I understood. no-match results in insertions for PUT and 404 for = GET ,while invalid results in an error response being returned. If = believe this sentence needs to be removed. - 15th para: There is a TODO that needs to be done or removed. - Figure 3 appears in this section, but figures 1 and 2 appear no where, = nor any figures after figure 3. Either remove the figure name and number = here or add figure numbers to all the figures in the document. Note that = figure 3 is referenced on page 24. Section 7 ---------- - 5th para: s/will dictate involve a/will dictate a - 6th para: I suggest changing the sentence "a subsequent DELETE to the = same URI should find the resource deleted" to "a subsequent DELETE to = the same URI should not find the resource". Section 7.4 ------------ - 2nd para: s/To create this this element/To create this element - The URI in the PUT example towards the end of the section is truncated Section 7.5 ------------ - Some text on the idempotent requirements would be useful - Some text on no-match would be useful Section 7.6 ------------ - Some text on no-match would be useful Section 7.7 ------------ - The URI in the PUT example towards the end of the section is truncated Section 7.8 ------------- - Some text on the idempotent requirements would be useful - Some text on no-match would be useful Section 7.9 ------------ - Some text on no-match would be useful Section 7.10 ------------- - last para: s/a when a/when a - last para: 304 response??? Section 8.2.1 ----------- - 1st para: s/doocuments/documents - 3rd para:=20 " If the parent URI has a path separator, the document selector is extracted, and that document is retrieved. If the document does not exist, the server MUST return a 409 response, and SHOULD include a detailed conflict report including the element. If it does exist, the node selector is extracted, and unescaped (recall that the node selector is escape coded). The node selector is applied to the document based on the matching operations discussed in Section 6.3. If the result is a no-match or invalid, the server MUST return a 409 response, and SHOULD include a detailed conflict report including the element." Is the last sentence correct? I don't think so. A no-match in this case = means an insertion. An invalid means that multiple elements where = selected. A in the conflict report does that make sense in = this case - 4th para: talks about target selector. What is target selector? It is = not defined anywhere. I believe this paragraph can be removed if the = correction to the previous paragraph as made as suggested above. Section 8.2.5 -------------- - 2nd para: "First, the server checks that the final document is = compliant to the schema." Does that mean it checks that the document is = valid according to the schema? If so, then the text should mention that = if the insertion is for a namespace that the server does not understand, = the validation cannot be made. Section 8.5 ----------- - 1st para: There is a TODO. Will we see etags in DELETE responses? I = think we should. It does change the document. - As in the client section, this section should mention when a server = generates a 2xx and when it generates a 4xx using If-match and = if-not-match headers. Section 9 ---------- The schema validates as does the example ;) (using XMLSpy) Section 12 ----------- - I have nothing extra to add to this security consideration section, = but it just seems a little too small. Perhaps examining scenarios would = make it took more like the homework was done. Regards, Hisham _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jul 28 05:18:00 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16153; Wed, 28 Jul 2004 05:18:00 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BpkbJ-0002Ud-Bl; Wed, 28 Jul 2004 05:19:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BpkXF-0002Mu-Qc; Wed, 28 Jul 2004 05:15:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BpkTC-0001nY-5T for simple@megatron.ietf.org; Wed, 28 Jul 2004 05:11:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15914 for ; Wed, 28 Jul 2004 05:11:28 -0400 (EDT) Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BpkUv-0002PJ-Rd for simple@ietf.org; Wed, 28 Jul 2004 05:13:21 -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 i6S9BNm22325; Wed, 28 Jul 2004 12:11:23 +0300 (EET DST) X-Scanned: Wed, 28 Jul 2004 12:10:24 +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 i6S9ANW4028606; Wed, 28 Jul 2004 12:10:24 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00sfxw7J; Wed, 28 Jul 2004 12:10:00 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 i6S99wn15990; Wed, 28 Jul 2004 12:09:58 +0300 (EET DST) Received: from kusti.research.nokia.com ([172.21.56.13]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 28 Jul 2004 12:09:58 +0300 Received: from nokia.com (xitami.research.nokia.com [172.21.40.110]) by kusti.research.nokia.com (Postfix) with ESMTP id C54C793B6A; Wed, 28 Jul 2004 12:09:56 +0300 (EEST) Message-ID: <41076D39.9090508@nokia.com> Date: Wed, 28 Jul 2004 12:09:13 +0300 From: Jari Urpalainen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: jdrosen@dynamicsoft.com Subject: Re: [Simple] WGLC: XCAP Base References: <2038BCC78B1AD641891A0D1AE133DBB7023EEB40@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB7023EEB40@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Jul 2004 09:09:58.0389 (UTC) FILETIME=[A7DA5250:01C47482] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b 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-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit A few comments/questions. 8.5 Managing Etags As Jonathan has interpreted (complying with rfc2616) that a node or even an attribute of an xml-document can be regarded as a resource is it allowable to send the document ETag after partial delete which is then actually an ETag of a different resource ? I would certainly prefer that it is still being sent as otherwise you introduce a second deficiency into safe updates of the document (the first one being partial append). This would mean that only partial modifies are safe. I can think only ugly solutions to this IMO annoying problem which is mostly due to the fact that partial updates were (naturally) not thought when http was created. 6.3 Node selector Although I have already commented on the default namespace issue I'll repeat it here: XPath 1.0 has the interpretation that namespace uri is null if the location step prefix is empty. The upcoming XPath 2.0 seems to use the element context which is the only sane way in XCAP, too. So just clearly state that in the text (otherwise compliant with XPath 1.0). 7 Client Operations I am sorry to repeat but I still don't understand idempotent delete. What should the server do during "a subsequent DELETE to the same URI should FIND the resource deleted..." ? I don't understand find here. --------------- I still miss non-default namespace examples. Also in all examples where location steps exist there should be more predicates to imply that each step has to point to a single element. Also I havn't noticed any discussions in the mailing lists about caching proxies as they will certainly try to cache responses unless Cache-Control or Expires headers are used. So some recommendations are needed in the text. BR, Jari _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jul 28 06:41:30 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19770; Wed, 28 Jul 2004 06:41:30 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bplu7-0003gZ-KX; Wed, 28 Jul 2004 06:43:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BpllJ-00055n-7m; Wed, 28 Jul 2004 06:34:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bplkv-0004zB-HF for simple@megatron.ietf.org; Wed, 28 Jul 2004 06:33:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19372 for ; Wed, 28 Jul 2004 06:33:51 -0400 (EDT) Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bplmd-0003ZU-Sh for simple@ietf.org; Wed, 28 Jul 2004 06:35:45 -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 i6SAXiD00557; Wed, 28 Jul 2004 13:33:44 +0300 (EET DST) X-Scanned: Wed, 28 Jul 2004 13:33: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 i6SAXOkJ022598; Wed, 28 Jul 2004 13:33:24 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 006CzyiE; Wed, 28 Jul 2004 13:33:24 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 i6SAXNu18498; Wed, 28 Jul 2004 13:33:23 +0300 (EET DST) Subject: [Simple] Comments on XCAP List Usage From: Jari Urpalainen To: ext Jonathan Rosenberg Content-Type: text/plain Message-Id: <1091010760.15943.43.camel@xitami.research.nokia.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Date: Wed, 28 Jul 2004 13:32:40 +0300 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab 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-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Hi! In chapter 3.4.6 there must be a typo, instead of If-None-Match If-Match is needed. I have some trouble understanding why the service document can contain also the list data with entrys etc.. If the document split is being done why not use this referencing always ? Furthermore, if indexing is meant only to find service element for a particular uri, I would propose a simpler format, i.e. joe/services.xml/~~/services[@uri=... jim/services.xml/~~/services[@uri=... What am I missing ? So you may have some other use cases in your mind. BR, Jari _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jul 28 06:55:53 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20459; Wed, 28 Jul 2004 06:55:52 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bpm83-0003to-Aw; Wed, 28 Jul 2004 06:57:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bpm4d-0007lT-MD; Wed, 28 Jul 2004 06:54:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bpm3v-0007dZ-HV for simple@megatron.ietf.org; Wed, 28 Jul 2004 06:53:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20354 for ; Wed, 28 Jul 2004 06:53:28 -0400 (EDT) Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bpm5U-0003rQ-5m for simple@ietf.org; Wed, 28 Jul 2004 06:55:23 -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 i6SArDm21492; Wed, 28 Jul 2004 13:53:13 +0300 (EET DST) X-Scanned: Wed, 28 Jul 2004 13:52:38 +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 i6SAqcbM022718; Wed, 28 Jul 2004 13:52:38 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00W0lRdz; Wed, 28 Jul 2004 13:52:37 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 i6SAqan22229; Wed, 28 Jul 2004 13:52:36 +0300 (EET DST) Subject: Re: [Simple] Multiple insertions in XCAP From: Jari Urpalainen To: ext Jonathan Rosenberg In-Reply-To: <40F81133.6010905@dynamicsoft.com> References: <40F81133.6010905@dynamicsoft.com> Content-Type: text/plain Message-Id: <1091011913.15943.63.camel@xitami.research.nokia.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Date: Wed, 28 Jul 2004 13:51:53 +0300 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a 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-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit On Fri, 2004-07-16 at 20:32, ext Jonathan Rosenberg wrote: > Folks, > > Per the list discussions on multiple insertions in xcap, I have put the > multiple insertions feature into a separate document, which we can now > debate and decide upon separately from the core spec. I left sufficient > hooks into core xcap to allow such an extension, and others, should we > decide to do them. This document was submitted before the -00 deadline, > and has appeared. You can pick it up here: > > http://www.ietf.org/internet-drafts/draft-rosenberg-simple-xcap-multiple-00.txt > > The document needs work, but captures the conclusions I think we came to > on how this would work. > > Comments welcome on this, including whether or not folks wish to proceed > with this subsequent to the completion of core xcap. > > Thanks, > Jonathan R. In the end of Chapter 2, you write "As an example, if positional ...". Do you mean if you delete like ../bar[1] | ../bar[2] and you do delete nodes one-by-one then the wrong second bar will be deleted ? Well I have implemented this so that I first search the nodelist and after that I'll do the delete. BR, Jari _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jul 28 09:52:39 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00296; Wed, 28 Jul 2004 09:52:39 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bpot7-00074M-5i; Wed, 28 Jul 2004 09:54:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bpokb-0006w4-QT; Wed, 28 Jul 2004 09:45:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BpoiH-0006Yg-Ji for simple@megatron.ietf.org; Wed, 28 Jul 2004 09:43:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29782 for ; Wed, 28 Jul 2004 09:43:19 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bpok5-0006ud-9X for simple@ietf.org; Wed, 28 Jul 2004 09:45:14 -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 i6SDhFm29511; Wed, 28 Jul 2004 16:43:15 +0300 (EET DST) X-Scanned: Wed, 28 Jul 2004 16:42:17 +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 i6SDgHIZ023009; Wed, 28 Jul 2004 16:42:17 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00HqqajL; Wed, 28 Jul 2004 16:42:16 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 i6SDgEn27801; Wed, 28 Jul 2004 16:42:14 +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); Wed, 28 Jul 2004 16:42:07 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Date: Wed, 28 Jul 2004 16:42:06 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7023EEB8F@esebe019.ntc.nokia.com> Thread-Topic: Comments on draft-ietf-simple-xcap-list-usage-03 Thread-Index: AcR0qKwC7iuVCPA6Q3Gv0V7VK3gfbA== To: X-OriginalArrivalTime: 28 Jul 2004 13:42:07.0025 (UTC) FILETIME=[AC7A7210:01C474A8] X-Spam-Score: 0.3 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: quoted-printable Cc: jdrosen@dynamicsoft.com Subject: [Simple] Comments on draft-ietf-simple-xcap-list-usage-03 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: quoted-printable Most of the comments are nits. When fixed, I believe the draft is ready. Abstract and Intro --------------------- They talk about presence list service. Where is presence list service = defined. Where is presence list server defined? I think any reference to = this service should be removed from the abstract. It can be defined in = the introduction before it is used as an example for resource lists. - 1st para in abstract: s/ can created / can be created Section 3.1 ------------- - 6th para: s/ sequence elements / sequence of elements - 7th para: s/ - 7th para: s/ - 10th para: s/ are the purposes / are for the purposes - an reference a . Any reason why it cannot reference = and ? I don't feel strongly about this. - I don't feel strongly about this either, but I was just wondering = about the possibility of the server just using an element = instead of the and element. The server would = realise that it needs to retrieve a referenced entry by examining the = URI in the entry. If it is an XCAP URI, then it knows it needs to fetch = it. Section 3.4.4 -------------- - It does not stat how uniqueness is determined to the "name" attribute. Section 3.4.6 --------------- - last para: "Any characters that are escape encoded are un-escaped, and only re-escaped if they cannot be represented within their component of the URL" What does the second part of that sentence mean? Please elaborate. Section 4.4.4 -------------- - last bullet: s/ fail the with / fail with Section 4.5 ------------ - last bullet: s/ Section 8.2 ------------ - Reference 17 is not used anywhere. Remove. Regards, Hisham _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jul 28 10:49:09 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04817; Wed, 28 Jul 2004 10:49:09 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bpplo-000851-VL; Wed, 28 Jul 2004 10:51:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BppdX-0005dE-3f; Wed, 28 Jul 2004 10:42:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bppc9-00055H-5w for simple@megatron.ietf.org; Wed, 28 Jul 2004 10:41:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04288 for ; Wed, 28 Jul 2004 10:41:03 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bppdx-0007vk-SE for simple@ietf.org; Wed, 28 Jul 2004 10:42:59 -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 i6SEf1k01538 for ; Wed, 28 Jul 2004 17:41:01 +0300 (EET DST) X-Scanned: Wed, 28 Jul 2004 17:40:24 +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 i6SEeOaI016501 for ; Wed, 28 Jul 2004 17:40:24 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00O0ewIk; Wed, 28 Jul 2004 17:40:24 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 i6SEeNn19216 for ; Wed, 28 Jul 2004 17:40:23 +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); Wed, 28 Jul 2004 17:40:23 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 28 Jul 2004 17:40:22 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Date: Wed, 28 Jul 2004 17:40:22 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7023EEB92@esebe019.ntc.nokia.com> Thread-Topic: Comments on draft-ietf-simple-xcap-pidf-manipulation-usage-01 Thread-Index: AcR0sM/O6jj52h8qT1WMfKkMZcGvmA== To: X-OriginalArrivalTime: 28 Jul 2004 14:40:22.0762 (UTC) FILETIME=[D01994A0:01C474B0] X-Spam-Score: 0.3 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: quoted-printable Cc: eva-maria.leppanen@nokia.com, Markus.Isomaki@nokia.com Subject: [Simple] Comments on draft-ietf-simple-xcap-pidf-manipulation-usage-01 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: quoted-printable Most of the comments are nits. When fixed, I believe the draft is ready. Abstract --------- - Change "...as one of the inputs based on which ..." to "...as one of = the inputs on which .." Section 1 --------- - last para: change "from the Section 4" to "from Section 4" Section 3 ----------- - The first paragraph references a requirements document that will never = be published. Remove the reference to that document. If the PUBLISH RFC = has something about the framework. you can reference that instead. - There is text that say: "One reasonable compositor policy is that the XCAP manipulated presence document is used as the default presence state in absence of any soft state set by SIP PUBLISH, and the soft state augments or overrides the default state." Remove that text as this draft is not the place for it. It might be that = this pidf document published using xcap has the same weight as any other = publishe pidf document. Section 5 ----------- - Remove the second paragraph. It has nothing new. - You can also reference RPID, CPID, prescaps and future-status drafts = in this section Section 9 ---------- - This section can be removed in its entirety. It duplicates section 5 = and has nothing new. Section 10 ----------- - I believe it is more appropriate to have an XCAP example rather than a = PIDF example. Just wrap your example with a PUT http://... Section 11 ----------- - Lets not recommend implementing basic authentication. Section 14 ------------ - Remove. Section 16 ----------- - Remove reference 11. Thanks, Hisham _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jul 28 16:34:56 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03060; Wed, 28 Jul 2004 16:34:56 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BpvAU-00069X-27; Wed, 28 Jul 2004 16:36:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bpv0d-0005m9-Q3; Wed, 28 Jul 2004 16:26:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BpurP-0004Nu-9b for simple@megatron.ietf.org; Wed, 28 Jul 2004 16:17:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02020 for ; Wed, 28 Jul 2004 16:17:09 -0400 (EDT) Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BputH-0005qG-2J for simple@ietf.org; Wed, 28 Jul 2004 16:19:08 -0400 Received: from [192.168.1.100] (c-67-164-133-175.client.comcast.net [67.164.133.175]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id i6SKFSuK024804 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 28 Jul 2004 15:15:31 -0500 (CDT) (envelope-from ben@nostrum.com) Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ben Campbell Date: Wed, 28 Jul 2004 15:15:28 -0500 To: Rohan Mahy , Cullen Jennings X-Mailer: Apple Mail (2.618) X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Cc: Simple WG Subject: [Simple] Comments on draft-ietf-simple-msrp-relays-01 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Overall, this looks really good. Some nits: I think we are inconsistent on whether success reports should be sent for entire message only, or per chunk. 5.1.1 2nd paragraph: It says the client MUST be able to form a connection with each relay. I thought the client would only connect with the first relay, which connects with the next, etc. 5.1.5 Generaly, it seems like connection management for client to foreign-relay connections should be identical as client to client connections. Consider that a client connecting to a foreign relay need not have implemented the relay extension. 5.2.3 Does a relay challenge an AUTH that has is just relayed through it? 5.2.3 Paragraph 4 is confusing. 5.2.4 paragraph 1: I think you mean Report-Failure, rather than Report-Success. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jul 28 16:52:32 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04265; Wed, 28 Jul 2004 16:52:32 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BpvRX-0006WA-Bu; Wed, 28 Jul 2004 16:54:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BpvO2-0001wr-BE; Wed, 28 Jul 2004 16:50:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BpvEe-0008Mu-35 for simple@megatron.ietf.org; Wed, 28 Jul 2004 16:41:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03574 for ; Wed, 28 Jul 2004 16:41:10 -0400 (EDT) Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BpvGW-0006HH-UT for simple@ietf.org; Wed, 28 Jul 2004 16:43:09 -0400 Received: from [192.168.1.100] (c-67-164-133-175.client.comcast.net [67.164.133.175]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id i6SKf2he026778 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 28 Jul 2004 15:41:02 -0500 (CDT) (envelope-from ben@nostrum.com) In-Reply-To: <40FF3386.6080303@cisco.com> References: <40FF3386.6080303@cisco.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <70840A86-E0D6-11D8-93B7-000D93B0AE1A@nostrum.com> Content-Transfer-Encoding: 7bit From: Ben Campbell Date: Wed, 28 Jul 2004 15:41:02 -0500 To: Paul Kyzivat X-Mailer: Apple Mail (2.618) X-Spam-Score: 0.3 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Content-Transfer-Encoding: 7bit Cc: Simple WG Subject: [Simple] Re: Comments on draft-ietf-simple-message-sessions-07 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Content-Transfer-Encoding: 7bit On Jul 21, 2004, at 10:24 PM, Paul Kyzivat wrote: [...] > 5. MSRP URLs > > transports. A MSRP URL with multiple, contradictory transports > is > invalid, unless some other document specifies meaning for the > particular combination of transport parameters. > > I don't understand the above. The specified syntax for the url only > permits a single transport token, so it is syntactically impossible to > have contradictory transports in a single url. > It is impossible now. But if someone does an SCTP extension, we don't want URLs that include both a TCP and an SCTP token. > > 5.1 URL comparison > > "The host part is compared as case insensitive". What if it is an ip > address? is it compared char by char? (What about leading zeros?) > > Is port comparison char by char, or numeric? (leading zeros again.) > Hmm. How do we do that for other schemes? > 6.1.1 Delivering SEND requests > > The default disposition of body is "render". If the sender wants > different disposition, it MAY insert a Content-Disposition header. > Since MSRP is a binary protocol, transfer encoding MUST be "binary". > > Are we supposing any particular semantic to content-dispositions? The > ones defined with mime aren't especially specific, and the ones > defined with sip aren't especially meaningful. > It seems to me the same level of vagueness that is appropriate for email is appropriate here. (How's that for a cop-out.) Or in other words: I don't know, does anyone care? [...] > 7.1 SDP Offer-Answer Exchanges for MSRP Sessions > > While MSRP could theoretically carry any media type, "message" is > appropriate. For MSRP, the port number is always ignored--the > actual port number is provided in an MSRP URL. Instead "9" is > used, which is an innocuous value which is assigned to the > discard > port. The protocol is always "msrp", and the value of the format > list is always a single asterisk character ("*"). > > I thought we determined that the same address+port can't be used for > more than one media session in the same SDP. If so, then it must be > possible to use other port values, in order to permit multiple msrp > sessions in same offer or answer. Or do we have another answer to > that? (I only remember this fuzzily - I may be crazy.) > I think you are right. Maybe we need to go back to allowing any value there, with a "SHOULD be 9 if that does not create a conflict" clause. > All types listed in either the accept-types or > accept-wrapped-types attributes MAY include a max-size parameter, > indicating the largest message it is willing to accept of that > type. Max-size refers to the complete message, not the size of > any one chunk. Senders MUST NOT exceed the max-size limit, if > any, when sending messages of any listed type. If a type is > listed without the parameter, then no preset size limit exists. > > Its weird to associate the size with a type, but make the size apply > to the message. The size should apply to the encoded body part > representing the type. This is especially important when a type might > be placed in a wrapper that can also contain other types. I think we have a terminology problem. The remember, a message of type "foo/bar" can be sent as many chunks. The point was, the max-size refers to the entire "foo/bar" message, not each individual chunk. [...] _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jul 28 16:55:19 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04382; Wed, 28 Jul 2004 16:55:19 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BpvUE-0006Yd-Kb; Wed, 28 Jul 2004 16:57:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BpvO7-00022X-5j; Wed, 28 Jul 2004 16:50:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BpvHu-0000Rw-O4 for simple@megatron.ietf.org; Wed, 28 Jul 2004 16:44:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03752 for ; Wed, 28 Jul 2004 16:44:32 -0400 (EDT) Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BpvJn-0006L6-ID for simple@ietf.org; Wed, 28 Jul 2004 16:46:32 -0400 Received: from [192.168.1.100] (c-67-164-133-175.client.comcast.net [67.164.133.175]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id i6SKiVlZ027012 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 28 Jul 2004 15:44:31 -0500 (CDT) (envelope-from ben@nostrum.com) In-Reply-To: <40FFD155.9020209@cisco.com> References: <40FF3386.6080303@cisco.com> <40FFD155.9020209@cisco.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ben Campbell Subject: Re: [Simple] Comments on draft-ietf-simple-message-sessions-07 Date: Wed, 28 Jul 2004 15:44:30 -0500 To: Paul Kyzivat X-Mailer: Apple Mail (2.618) X-Spam-Score: 0.3 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da 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-Score: 0.3 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: 7bit On Jul 22, 2004, at 9:38 AM, Paul Kyzivat wrote: > A few more comments, starting with the examples: > > 11.1 - the numbering of the messages doesn't agree with what is in the > diagram. Also, message 5 is missing a blank line between Content-Type > and the body. > > 11.3 - I find the sysadmin example highly unlikely. Why would MSRP > (rather than page mode MESSAGE) be used for this? A session would > first have to be established. This would only make sense if there was > already a session established, or there was expectation that many such > messages will be sent using the same session. > OK, would a better example be to have a conference owner say "this conference is about to end"? > 11.4 - I presume the last message in this example was intended to be > REPORT, not SEND. > Yes. > 11.5 - Nice example! s/MSPR/MSRP/ > Toward the end, when the MSRP session is set up to the nurse, I > believe "art thou hither" would be sent, just as it was to the other > attempts. > > 12. Extensibility > > I believe the decision was that we didn't need version numbers because > sessions are established using another protocol (e.g. SIP) which can > handle version negotiation. But we don't have any provision for > versions there either. The only options I can see that are open for > revisions are: > > - use a different scheme name (not msrp) in the urls. (ugh) > That is sort of what I was assuming... > - invent a new a-line to carry versioning information that can be > negotiated. > > Another possibility, if we plan now, is to put a little more > extensibility into the msrp url, such as: > > MSRP_urls = msrp-scheme "://" server ["/" > resource] ";" transport *( ";" msrp-option ) > server = [userinfo "@"] hostport > msrp-scheme = "msrp" / "msrps" > resource = 1*unreserved > transport = "tcp" / token > msrp-option = gen-param > > This would of course require a change to the comparison rules for > urls, and could make comparison somewhat more complex. > > I think we just have a clear idea of a workable strategy for moving to > a revised protocol. I don't have a strong opinion here. Others? _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jul 28 18:44:04 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12647; Wed, 28 Jul 2004 18:44:03 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BpxBT-0008U1-Kr; Wed, 28 Jul 2004 18:46:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bpx3x-0001g5-9K; Wed, 28 Jul 2004 18:38:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bpx1w-0001Pd-Ms for simple@megatron.ietf.org; Wed, 28 Jul 2004 18:36:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12246 for ; Wed, 28 Jul 2004 18:36:10 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bpx3n-0008LY-OW for simple@ietf.org; Wed, 28 Jul 2004 18:38:11 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 28 Jul 2004 18:41: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 i6SMZX8Z015498; Wed, 28 Jul 2004 18:35:35 -0400 (EDT) Received: from cisco.com ([161.44.79.221]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKL72011; Wed, 28 Jul 2004 18:35:33 -0400 (EDT) Message-ID: <41082A35.1070202@cisco.com> Date: Wed, 28 Jul 2004 18:35:33 -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 References: <40FF3386.6080303@cisco.com> <70840A86-E0D6-11D8-93B7-000D93B0AE1A@nostrum.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 Content-Transfer-Encoding: 7bit Cc: Simple WG Subject: [Simple] Re: Comments on draft-ietf-simple-message-sessions-07 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de Content-Transfer-Encoding: 7bit Ben Campbell wrote: > > On Jul 21, 2004, at 10:24 PM, Paul Kyzivat wrote: > > [...] > >> 5. MSRP URLs >> >> transports. A MSRP URL with multiple, contradictory transports is >> invalid, unless some other document specifies meaning for the >> particular combination of transport parameters. >> >> I don't understand the above. The specified syntax for the url only >> permits a single transport token, so it is syntactically impossible to >> have contradictory transports in a single url. > > It is impossible now. But if someone does an SCTP extension, we don't > want URLs that include both a TCP and an SCTP token. You miss my point, I think. My point is not that we don't have two different kinds of transports to conflict. It is that the specified syntax for a msrp url doesn't allow there to be two transport parameters at all. For instance, an MSRP URL with multiple, conflicting transports might be: msrp://host.example.com:8493/asfd34;tcp;sctp But that isn't legal according to the syntax: MSRP_urls = msrp-scheme "://" [userinfo "@"] hostport ["/" resource] ";" transport msrp-scheme = "msrp" / "msrps" resource = 1*unreserved transport = "tcp" / token If an sctp extension was defined, then msrp://host.example.com:8493/asfd34;sctp would be legal, but that doesn't have multiple conflicting transports. For multiple conflicting transports, the syntax must permit the transport parameter to be repeated. I don't really see why it would be useful to have multiple transport parameters, so I see no reason to change the syntax for that. So I think it would be sufficient to remove the highlighted sentence above. >> 5.1 URL comparison >> >> "The host part is compared as case insensitive". What if it is an ip >> address? is it compared char by char? (What about leading zeros?) >> >> Is port comparison char by char, or numeric? (leading zeros again.) >> > > Hmm. How do we do that for other schemes? I believe each scheme has its own comparison rules. For sip comparison is at least component by component. 3261 is not specific on whether the port is compared numerically or alphanumerically, but I know of at least one stack that compares them numerically. Similarly, I don't really know if ip addresses are to be compared numerically or alphanumerically. That is why I am asking. If the assumption here is that entire urls can be compared alphanumerically, it puts constraints on the creators of those URLs to write them in canonical form. But I see no requirement to do so. >> 6.1.1 Delivering SEND requests >> >> The default disposition of body is "render". If the sender wants >> different disposition, it MAY insert a Content-Disposition header. >> Since MSRP is a binary protocol, transfer encoding MUST be "binary". >> >> Are we supposing any particular semantic to content-dispositions? The >> ones defined with mime aren't especially specific, and the ones >> defined with sip aren't especially meaningful. >> > > It seems to me the same level of vagueness that is appropriate for email > is appropriate here. (How's that for a cop-out.) Or in other words: I > don't know, does anyone care? Well, do the people implementing IM know what mail programs do? Is it even written down? Are mail and IM sufficiently similar to know what to do? E.g. suppose I want to send LoTR.mpg as a message. When it arrives there are at least two possibilities: - the receiving client could render it directly, as streaming video - it could be stored for future viewing. I suspect this could be distinguished by the content-disposition - 'render' means play it now, while perhaps 'attachment' means save it for later. But in other sip contexts I see 'attachment' used as a random catchall. We can leave it vague for now in the interest of getting something done. But I think it calls for followup work. >> 7.1 SDP Offer-Answer Exchanges for MSRP Sessions >> >> All types listed in either the accept-types or >> accept-wrapped-types attributes MAY include a max-size parameter, >> indicating the largest message it is willing to accept of that >> type. Max-size refers to the complete message, not the size of >> any one chunk. Senders MUST NOT exceed the max-size limit, if >> any, when sending messages of any listed type. If a type is >> listed without the parameter, then no preset size limit exists. >> >> Its weird to associate the size with a type, but make the size apply >> to the message. The size should apply to the encoded body part >> representing the type. This is especially important when a type might >> be placed in a wrapper that can also contain other types. > > I think we have a terminology problem. The remember, a message of type > "foo/bar" can be sent as many chunks. The point was, the max-size refers > to the entire "foo/bar" message, not each individual chunk. I think you miss my point again. It has nothing to do with chunking. Suppose that max sizes have been declared as follows: - text/plain: 128 - text/html: 1024 Now suppose I have a message that contains: - multipart/alternative - text/plain - size 256 - text/html - size 512 and suppose the total size of the multipart/alternative is 1500 (256 + 512 + some extra). What limits apply, and to what? - Is it ok because there is no limit for multipart/alternative and that is all that matters? - Is it bad because 256 exceeds the max size for text/plain? - Is it bad because 1500 exceeds the size for text/plain? - ??? And does it make sense to include the message headers in the limit? The size of the headers is an independent variable vs the size of the body. It can't help with buffering strategy, because you have to read the headers before you know what type the body is. And if the size applies to the reassembled message, it is built after headers have been processed anyway. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jul 28 18:55:59 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13198; Wed, 28 Jul 2004 18:55:59 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BpxN1-0000Ec-9X; Wed, 28 Jul 2004 18:58:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BpxFO-0003Nn-BW; Wed, 28 Jul 2004 18:50:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BpxAk-0002pi-LF for simple@megatron.ietf.org; Wed, 28 Jul 2004 18:45:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12686 for ; Wed, 28 Jul 2004 18:45:15 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BpxCe-0008UY-NW for simple@ietf.org; Wed, 28 Jul 2004 18:47:17 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 28 Jul 2004 15:47:59 -0700 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 i6SMiiCv013317; Wed, 28 Jul 2004 15:44:45 -0700 (PDT) Received: from cisco.com ([161.44.79.221]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKL72637; Wed, 28 Jul 2004 18:44:43 -0400 (EDT) Message-ID: <41082C5B.1090502@cisco.com> Date: Wed, 28 Jul 2004 18:44:43 -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] Comments on draft-ietf-simple-message-sessions-07 References: <40FF3386.6080303@cisco.com> <40FFD155.9020209@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 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-Score: 0.2 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: 7bit Ben Campbell wrote: > > On Jul 22, 2004, at 9:38 AM, Paul Kyzivat wrote: > >> A few more comments, starting with the examples: >> >> 11.1 - the numbering of the messages doesn't agree with what is in the >> diagram. Also, message 5 is missing a blank line between Content-Type >> and the body. >> >> 11.3 - I find the sysadmin example highly unlikely. Why would MSRP >> (rather than page mode MESSAGE) be used for this? A session would >> first have to be established. This would only make sense if there was >> already a session established, or there was expectation that many such >> messages will be sent using the same session. >> > > OK, would a better example be to have a conference owner say "this > conference is about to end"? Yes, that is a much better one! (Wish I had thought of it.) >> 12. Extensibility >> >> I believe the decision was that we didn't need version numbers because >> sessions are established using another protocol (e.g. SIP) which can >> handle version negotiation. But we don't have any provision for >> versions there either. The only options I can see that are open for >> revisions are: >> >> - use a different scheme name (not msrp) in the urls. (ugh) > > That is sort of what I was assuming... Ugh! That would be unpleasant. Do the keepers of scheme names want us using them for version control? >> - invent a new a-line to carry versioning information that can be >> negotiated. >> >> Another possibility, if we plan now, is to put a little more >> extensibility into the msrp url, such as: >> >> MSRP_urls = msrp-scheme "://" server ["/" >> resource] ";" transport *( ";" msrp-option ) >> server = [userinfo "@"] hostport >> msrp-scheme = "msrp" / "msrps" >> resource = 1*unreserved >> transport = "tcp" / token >> msrp-option = gen-param >> >> This would of course require a change to the comparison rules for >> urls, and could make comparison somewhat more complex. >> >> I think we just have a clear idea of a workable strategy for moving to >> a revised protocol. > > I don't have a strong opinion here. Others? I'm pretty confident that this protocol will need to be revised. I also suspect we are going to need extra url parameters for something. In fact, it seems that Rohan has already had in mind the use of parameters to multiplex a single msrp url assigned by a relay for multiple sessions at the client. If we need url parameters anyway then using one to convey the protocol version is little extra pain. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jul 28 19:05:57 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13826; Wed, 28 Jul 2004 19:05:56 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BpxWe-0000RH-Te; Wed, 28 Jul 2004 19:07:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BpxT0-0005re-19; Wed, 28 Jul 2004 19:04:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BpxPS-0005EY-D0 for simple@megatron.ietf.org; Wed, 28 Jul 2004 19:00:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13459 for ; Wed, 28 Jul 2004 19:00:27 -0400 (EDT) Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BpxRL-0000JH-FZ for simple@ietf.org; Wed, 28 Jul 2004 19:02:28 -0400 Received: from [192.168.1.100] (c-67-164-133-175.client.comcast.net [67.164.133.175]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id i6SN0Jkq038071 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 28 Jul 2004 18:00:20 -0500 (CDT) (envelope-from ben@nostrum.com) In-Reply-To: <41082A35.1070202@cisco.com> References: <40FF3386.6080303@cisco.com> <70840A86-E0D6-11D8-93B7-000D93B0AE1A@nostrum.com> <41082A35.1070202@cisco.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ben Campbell Date: Wed, 28 Jul 2004 18:00:17 -0500 To: Paul Kyzivat X-Mailer: Apple Mail (2.618) X-Spam-Score: 0.3 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit Cc: Simple WG Subject: [Simple] Re: Comments on draft-ietf-simple-message-sessions-07 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit On Jul 28, 2004, at 5:35 PM, Paul Kyzivat wrote: > > I think you miss my point again. It has nothing to do with chunking. > > Suppose that max sizes have been declared as follows: > > - text/plain: 128 > - text/html: 1024 > > Now suppose I have a message that contains: > > - multipart/alternative > - text/plain - size 256 > - text/html - size 512 > > and suppose the total size of the multipart/alternative is 1500 (256 + > 512 + some extra). > > What limits apply, and to what? > - Is it ok because there is no limit for multipart/alternative > and that is all that matters? > - Is it bad because 256 exceeds the max size for text/plain? > - Is it bad because 1500 exceeds the size for text/plain? > - ??? > OK, I get it now. I interpret it to mean this is okay _if_ the imbedded text/plain does not exceed any limit for text plain _and_ the text/html does not exceed its limit, etc. If their had been a limit specified on multipart/alternative, then it would imply to the entire object. > And does it make sense to include the message headers in the limit? > The size of the headers is an independent variable vs the size of the > body. It can't help with buffering strategy, because you have to read > the headers before you know what type the body is. And if the size > applies to the reassembled message, it is built after headers have > been processed anyway. I don't think the headers should count here. We are talking about content size. > > Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jul 28 20:50:59 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19297; Wed, 28 Jul 2004 20:50:59 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BpzAJ-0002EJ-OM; Wed, 28 Jul 2004 20:53:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bpz3o-0007Ep-Rr; Wed, 28 Jul 2004 20:46:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bpz0O-0005Uj-SR for simple@megatron.ietf.org; Wed, 28 Jul 2004 20:42:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18479 for ; Wed, 28 Jul 2004 20:42:43 -0400 (EDT) Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bpz2J-0001wQ-49 for simple@ietf.org; Wed, 28 Jul 2004 20:44:44 -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 i6T0gCLp000367 for ; Wed, 28 Jul 2004 19:42:12 -0500 From: Robert Sparks To: simple@ietf.org Content-Type: text/plain Message-Id: <1091061664.1984.12.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Date: Wed, 28 Jul 2004 19:41:05 -0500 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Subject: [Simple] WG call for comment: Auth48 changes to winfo-package X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Folks - Celebration is in order! The core set of drafts are finally working their way out of the process. We've had many months since IESG approval to acquire feedback on these drafts. Time has told us that we did a very good job - most of them require very little tweaking. -winfo-package got some feedback that suggests adding several words. The meaning doesn't change, but there have been good points brought forth for clarification. We need, as a group, to look through the new words and verify that this is what we've agreed to say. Jonathan will post the proposed edits that add significant text shortly (there are the usual editorial fixes, but we do not need to review those here). Please send a note to the list confirming your agreement with them before Aug 7. Thanks, RjS _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jul 29 10:42:22 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16075; Thu, 29 Jul 2004 10:42:22 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BqC91-0005fw-Lv; Thu, 29 Jul 2004 10:44:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BqBUQ-0005Z0-FY; Thu, 29 Jul 2004 10:02:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BqB1N-0007SD-R7 for simple@megatron.ietf.org; Thu, 29 Jul 2004 09:32:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03369 for ; Thu, 29 Jul 2004 07:07:35 -0400 (EDT) Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bq8n6-0002LG-8D for simple@ietf.org; Thu, 29 Jul 2004 07:09:43 -0400 Received: from dynamicsoft.com ([63.113.46.26]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i6TB7MeE005964; Thu, 29 Jul 2004 07:07:22 -0400 (EDT) Message-ID: <4108DA56.1060803@dynamicsoft.com> Date: Thu, 29 Jul 2004 07:07: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: Robert Sparks Subject: Re: [Simple] WG call for comment: Auth48 changes to winfo-package References: <1091061664.1984.12.camel@localhost.localdomain> In-Reply-To: <1091061664.1984.12.camel@localhost.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2f46977da373544777a750d5247d6ccc 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-Score: 0.0 (/) X-Scan-Signature: 14278aea5bdd1edf35ec09ffb7b61f9d Content-Transfer-Encoding: 7bit Folks, Here are the changes I think need to be made to the document. Mostly they are clarifications. Two of the changes are based on some brief email exchanges that occurred while the docs were sitting with rfc-editor. Those changes deal with two issues that were raised: 1. When someone does a fetch, the subscription FSM is created, goes into the active state and then is immmediately terminated and destoryed. You don't want to get notifications for each of these transitions, and this was raised on the list. So, text has been added saying that you SHOULD NOT send notifications in transient states. 2. The current document has a transition from waiting back to pending in the case where the subscription comes back. But, it never will; it would show up as a new subscription that goes into pending. As such, the transition from waiting back to pending was removed. Instead, when another subscription arrives, you can remove the one in the waiting state, and that is described. Below are the set of proposed diffs to reflect these two issues plus general clarifications: Section 1, first paragraph: OLD: The SIP event framework is described in RFC 3265 [1]. It defines a NEW: The Session Initiation Protocol (SIP) event framework is described in ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ RFC 3265 [1]. It defines a Section 2, second paragraph: OLD: the "inner" subscribers, subscriptions, and notifications - those NEW: the "inner" subscriptions, subscribers and notifications - those ^^^^^^^^^^^^^^^^^^^^^^^^^^ Section 3.1, first paragraph: OLD: The motivating application for this package is presence NEW: The motivating application for this template-package is presence ^^^^^^^^^ Section 4.4, second paragraph: OLD: how long a user maintains its subscription. Typically, watcherinfo subscriptions will be timed to span the lifetime of the subscriptions being watcher, and therefore range from minutes to days. NEW: how long a user maintains its subscription. Typically, watcherinfo subscriptions will be timed to span the lifetime of the subscriptions being watched, and therefore range from minutes to days. ^ Section 4.5, second paragraph: OLD: The body of the watcherinfo notification contains a watcher information document. This document describes some or all of the watchers for a given package, and the state of their subscriptions. NEW: The body of the watcherinfo notification contains a watcher information document. This document describes some or all of the watchers for a resource within a given package, and the state of ^^^^^^^^^^^^^^^^^^^^^ their subscriptions. Section 4.7, second paragraph: OLD: Watcherinfo notifications MAY be generated for watcher information on package foo, when the subscription state for a user on package foo changes. The watcher information package therefore needs a model of subscription state. NEW (add text and split into two paragraphs): Each watcherinfo subscription is associated with a set of "inner" subscriptions being watched. This set is defined by the URI in the Request URI of the watcherinfo SUBSCRIBE request, along with the parent event package of the watcherinfo subscription. The parent event package is obtained by removing the trailing ".winfo" from the value of the Event header field from the watcherinfo SUBSCRIBE request. If the Event header field in the watcherinfo subscription has a value of "presence.winfo", the parent event package is "presence". If the Event header field has a value of "presence.winfo.winfo", the parent event package is "presence.winfo". Normally, the URI in the Request URI of the watcherinfo SUBSCRIBE identifies an address-of-record within the domain. In that case, the set of subscriptions to be watched are all of the subscriptions for the parent event package that have been made to the resource in the Request URI of the watcherinfo SUBSCRIBE. However, the Request URI can contin a URI that defines a larger collection of resources. For example, sip:all-resources@example.com might be defined within example.com to refer to all resources. In that case, a watcherinfo subscription for "presence.winfo" to sip:all-resources@example.com is requesting notifications any time the state of any presence subscription for any resource within example.com changes. A watcherinfo notifier MAY generate a notification any time the state of any of the watched subscriptions changes. Because a watcherinfo subscription is made to a collection of subscriptions, the watcher information package needs a model of subscription state. Section 4.7.1, second paragraph: OLD: Initially, there is no state allocated for a subscription (the init state). When a SUBSCRIBE request arrives, the subscription FSM is created. NEW: When a SUBSCRIBE request arrives, the subscription FSM is created in the init state. This state is transient. Section 4.7.1, last paragraph on page 9: OLD: The waiting state is similar to pending, in that no notifications are generated. However, if the subscription is approved or denied, the FSM is destroyed. NEW: The waiting state is similar to pending, in that no notifications are generated. However, if the subscription is approved or denied, the FSM enters the terminated state, and is destroyed. Furthermore, if another subscription is received to the same resource, from the same watcher, for the same event package, event package parameters and filter in the body of the SUBSCRIBE request (if one was present initially), the FSM enters the terminated state with a "giveup" event, and is destroyed. This transition occurs because, on arrival of a new subscription with identical parameters, it will enter the pending state, making the waiting state for the prior subscription redundant. Section 4.7.1, figure 1: replace figure with this (transition from waiting to pending has been removed): subscribe, policy= +----------+ reject | |<------------------------+ +------------>|terminated|<---------+ | | | | | | | | | |noresource | | +----------+ |rejected | | ^noresource |deactivated | | |rejected |probation | | |deactivated |timeout |noresource | |probation | |rejected | |giveup | |giveup | | | |approved +-------+ +-------+ +-------+ | | |subscribe| |approved| | | | init |-------->|pending|------->|active | | | |no policy| | | | | | | | | | | | +-------+ +-------+ +-------+ | | | ^ | | subscribe, | | | +-----------------------------------+ | policy = accept | +-------+ | | | | | | |waiting|----------+ +----------->| | timeout | | +-------+ Section 4.7.1, bottom of page 10: OLD: Of course, policy may never be specified for the subscription. As a result, the server can generate a giveup event to move the waiting subscription to the terminated state. The amount of time to wait before issuing a giveup event is system dependent. If, while in the waiting state, the subscription is refreshed through another SUBSCRIBE, it moves back into the pending state. NEW (delete last sentence): Of course, policy may never be specified for the subscription. As a result, the server can generate a giveup event to move the waiting subscription to the terminated state. The amount of time to wait before issuing a giveup event is system dependent. Section 4.7.1, last paragraph page 10: OLD: The giveup event is generated in either the waiting or pending states to destroy resources associated with unauthorized subscriptions. NEW: The giveup event is generated in either the waiting or pending states to destroy resources associated with unauthorized subscriptions. This event is generated when a giveup timer fires. This timer is set to a timeout value when entering either the pending or waiting states. Section 4.7.1, first paragraph page 11: OLD: that servers, which retain state for unauthorized subscriptions, add policies which prohibit a particular subscriber from having more than some number of pending or waiting subscriptions. NEW: that servers that retain state for unauthorized subscriptions add ^^^^^ ^ policies which prohibit a particular subscriber from having more than some number of pending or waiting subscriptions. Section 4.7.2: Add this as the last paragraph in the section: Frequently, states in the subscription state machine will be transient. For example, if an authorized watcher performs a fetch operation, this will cause the state machine to be created, transition from init to active, and then from active to terminated, followed by a destruction of the FSM. In such cases, watcherinfo notifications SHOULD NOT be sent for any transient states. In the prior example, the server wouldn't send any notifications, since all of the states are transient. Section 5, last message on page 14: OLD: NOTIFY sip:joe@pc34.example.com SIP/2.0 Via: SIP/2.0/UDP server19.example.com;branch=z9hG4bKnasaii From: sip:joe@example.com;tag=xyzygg To: sip:joe@example.com;tag=123aa9 Call-ID: 9987@pc34.example.com CSeq: 1288 NOTIFY Contact: sip:server19.example.com Event: presence.winfo Max-Forwards: 70 Content-Type: application/watcherinfo+xml Content-Length: ... NEW: NOTIFY sip:joe@pc34.example.com SIP/2.0 Via: SIP/2.0/UDP server19.example.com;branch=z9hG4bKnasaii From: sip:joe@example.com;tag=xyzygg To: sip:joe@example.com;tag=123aa9 Call-ID: 9987@pc34.example.com CSeq: 1288 NOTIFY Contact: sip:server19.example.com Event: presence.winfo Subscription-State: active Max-Forwards: 70 Content-Type: application/watcherinfo+xml Content-Length: ... Section 5, last message on page 15: OLD: NOTIFY sip:joe@pc34.example.com SIP/2.0 Via: SIP/2.0/UDP server19.example.com;branch=z9hG4bKnasaij From: sip:joe@example.com;tag=xyzygg To: sip:joe@example.com;tag=123aa9 Call-ID: 9987@pc34.example.com CSeq: 1289 NOTIFY Contact: sip:server19.example.com Event: presence.winfo Max-Forwards: 70 Content-Type: application/watcherinfo+xml Content-Length: ... NEW (add Subsription-State header): NOTIFY sip:joe@pc34.example.com SIP/2.0 Via: SIP/2.0/UDP server19.example.com;branch=z9hG4bKnasaij From: sip:joe@example.com;tag=xyzygg To: sip:joe@example.com;tag=123aa9 Call-ID: 9987@pc34.example.com CSeq: 1289 NOTIFY Contact: sip:server19.example.com Event: presence.winfo Subscription-State: active Max-Forwards: 70 Content-Type: application/watcherinfo+xml Content-Length: ... Section 6.2, second paragraph: OLD: information. To prevent that, watchers MAY use the SIPS scheme when subscribing to a watcherinfo resource. Notifiers for watcherinfo MUST support TLS and SIPS as if they were a proxy (see Section 26.3.1 of RFC 3261). NEW: information. To prevent that, watchers MAY use the sips URI scheme when ^^^^^^^^ subscribing to a watcherinfo resource. Notifiers for watcherinfo MUST support TLS and sips as if they were a proxy (see Section 26.3.1 ^^^^ of RFC 3261). Section 11, authors address: OLD: Jonathan Rosenberg dynamicsoft 72 Eagle Rock Avenue First Floor East Hanover, NJ 07936 NEW: Jonathan Rosenberg dynamicsoft 600 Lanidex Plaza Parsippany, NJ 07054 Thanks, Jonathan R. Robert Sparks wrote: > Folks - > > Celebration is in order! > > The core set of drafts are finally working their way out > of the process. > > We've had many months since IESG approval to acquire feedback on these > drafts. Time has told us that we did a very good job - most > of them require very little tweaking. > > -winfo-package got some feedback that suggests adding several > words. The meaning doesn't change, but there have been good > points brought forth for clarification. We need, as a group, > to look through the new words and verify that this is what we've > agreed to say. > > Jonathan will post the proposed edits that add significant > text shortly (there are the usual editorial fixes, but we > do not need to review those here). Please send a note to the > list confirming your agreement with them before Aug 7. > > Thanks, > > RjS > > > _______________________________________________ > 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 Jul 29 15:42:09 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04746; Thu, 29 Jul 2004 15:42:09 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BqGp0-00026m-MH; Thu, 29 Jul 2004 15:44:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BqGe3-000873-Ez; Thu, 29 Jul 2004 15:32:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BqG9J-0004Ms-Cm for simple@megatron.ietf.org; Thu, 29 Jul 2004 15:01:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01638 for ; Thu, 29 Jul 2004 15:00:58 -0400 (EDT) Received: from web54010.mail.yahoo.com ([206.190.36.234]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1BqGBI-0001Y9-KQ for simple@ietf.org; Thu, 29 Jul 2004 15:03:10 -0400 Message-ID: <20040729190028.75819.qmail@web54010.mail.yahoo.com> Received: from [12.47.48.5] by web54010.mail.yahoo.com via HTTP; Thu, 29 Jul 2004 12:00:28 PDT Date: Thu, 29 Jul 2004 12:00:28 -0700 (PDT) From: kamal Rometra To: simple@ietf.org, adam@dynamicsoft.com MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Subject: [Simple] SUBSCRIBE with Expire=0 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.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="===============1663156165==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe --===============1663156165== Content-Type: multipart/alternative; boundary="0-1633326270-1091127628=:21010" --0-1633326270-1091127628=:21010 Content-Type: text/plain; charset=us-ascii Hi, I have a clarfication on SUBSCRIBE for eventlist extension with Expires=0. In this case, RLS responds to SUBSCRIBE Request and sends final NOTIFY request containing full state information (status of all the resources of the list) with Subscription-State header containing value "terminated" and reason "timeout". If the list consists of 100 buddies, content to be sent in body of NOTIFY request is large, It may not be possible to send full information in one NOTIFY. How should RLS send NOTIFY requests in this case ? Thanks, KR --------------------------------- Do you Yahoo!? Express yourself with Y! Messenger! Free. Download now. --0-1633326270-1091127628=:21010 Content-Type: text/html; charset=us-ascii
Hi,
 
I have a clarfication on SUBSCRIBE for eventlist extension with Expires=0.
In this case, RLS responds to SUBSCRIBE Request and sends final NOTIFY request containing full state information (status of all the resources of the list) with Subscription-State header containing value "terminated" and reason "timeout".
 
If the list consists of 100 buddies, content to be sent in body of NOTIFY request is large, It may not be possible to send full information in one NOTIFY.
 
How should RLS send NOTIFY requests in this case ?
 
 
Thanks,
KR
 
 
 

Do you Yahoo!?
Express yourself with Y! Messenger! Free. Download now. --0-1633326270-1091127628=:21010-- --===============1663156165== 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 --===============1663156165==-- From simple-bounces@ietf.org Thu Jul 29 16:09:01 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06163; Thu, 29 Jul 2004 16:09:01 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BqHEu-0002a5-So; Thu, 29 Jul 2004 16:11:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BqGh7-0000sM-Mx; Thu, 29 Jul 2004 15:36:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BqGU1-0005u8-2X for simple@megatron.ietf.org; Thu, 29 Jul 2004 15:22:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03608 for ; Thu, 29 Jul 2004 15:22:21 -0400 (EDT) Received: from web54010.mail.yahoo.com ([206.190.36.234]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1BqGVz-0001qY-EF for simple@ietf.org; Thu, 29 Jul 2004 15:24:33 -0400 Message-ID: <20040729192150.83881.qmail@web54010.mail.yahoo.com> Received: from [12.47.48.5] by web54010.mail.yahoo.com via HTTP; Thu, 29 Jul 2004 12:21:50 PDT Date: Thu, 29 Jul 2004 12:21:50 -0700 (PDT) From: kamal Rometra To: simple@ietf.org, adam@dynamicsoft.com MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Subject: [Simple] NOTIFY requests for eventlist X-BeenThere: simple@ietf.org X-Mailman-Version: 2.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="===============0403604035==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 --===============0403604035== Content-Type: multipart/alternative; boundary="0-821001977-1091128910=:83442" --0-821001977-1091128910=:83442 Content-Type: text/plain; charset=us-ascii Hi, I have a clarifcation on RLS sending NOTIFY requests for eventlist extension. When a user subscribes to a list, RLS sends 200 OK back followed by NOTIFY request. RLS may have to fork the request and get status for the buddies of the list from other servers in the network. The first NOTIFY is supposed to contain fullstate=true in the rlmi body. If the list consists of large number of resources, Does RLS need to add all the resources in the rlmi body of the first NOTIFY or can it be broken into multiple NOTIFY requests ? Can RLS send only rlmi in first NOTIFY and add multipart/mixed content in subsequent NOTIFY requests ? If throttle is not supported, Does RLS need to wait for response to first NOTIFY request before sending another one OR can it send multiple NOTIFY requests one after the other for a single SUBSCIRBE ? Thanks a lot. --------------------------------- Do you Yahoo!? Yahoo! Mail - You care about security. So do we. --0-821001977-1091128910=:83442 Content-Type: text/html; charset=us-ascii
Hi,
 
I have a clarifcation on RLS sending NOTIFY requests for eventlist extension.
 
When a user subscribes to a list, RLS sends 200 OK back followed by NOTIFY request. RLS may have to fork the request and get status for the buddies of the list from other servers in the network.
 
The first NOTIFY is supposed to contain fullstate=true in the rlmi body. If the list consists of large number of resources, Does RLS need to add all the resources in the rlmi body of the first NOTIFY or can it be broken into multiple NOTIFY requests ?
 
Can RLS send only rlmi in first NOTIFY and add multipart/mixed content in subsequent NOTIFY requests ?
 
If throttle is not supported, Does RLS need to wait for response to first NOTIFY request before sending another one OR can it send multiple NOTIFY requests one after the other for a single SUBSCIRBE ?
 
Thanks a lot.
 
 

Do you Yahoo!?
Yahoo! Mail - You care about security. So do we. --0-821001977-1091128910=:83442-- --===============0403604035== 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 --===============0403604035==-- From simple-bounces@ietf.org Fri Jul 30 10:22:12 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09405; Fri, 30 Jul 2004 10:22:12 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BqYJF-0008LH-3z; Fri, 30 Jul 2004 10:24:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BqY0e-00017P-1k; Fri, 30 Jul 2004 10:05:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BqXlR-0007eV-1L for simple@megatron.ietf.org; Fri, 30 Jul 2004 09:49:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23098 for ; Fri, 30 Jul 2004 03:59:08 -0400 (EDT) Received: from can.cs.columbia.edu ([128.59.16.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BqSKT-0003Uq-7w for simple@ietf.org; Fri, 30 Jul 2004 04:01:27 -0400 Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by can.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i6R3Mrbl001145 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 26 Jul 2004 23:22:57 -0400 (EDT) Received: from razor.cs.columbia.edu (IDENT:sFy68fAyp25mfLO8H1ewJEcutT9gszWM@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i6R3BtlD023705 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Mon, 26 Jul 2004 23:11:55 -0400 (EDT) Received: from [127.0.0.1] (IDENT:MRbUSUXA6YXSH7KcNLx6fzdPoyUpQsQH@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i6R3Bsjd015243; Mon, 26 Jul 2004 23:11:54 -0400 Message-ID: <4105C7F9.5070901@cs.columbia.edu> Date: Mon, 26 Jul 2004 23:11:53 -0400 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 0.7.1 (Windows/20040626) X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com Subject: Re: [Simple] Presence data model: devices References: <2038BCC78B1AD641891A0D1AE133DBB7023EEB53@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB7023EEB53@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 4.6.1.106153, Antispam-Core: 4.6.1.104326, Antispam-Data: 2004.7.26.108628 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' X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Cc: pkyzivat@cisco.com, 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-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > I don't agree here. They are the same service. You can communicate > with me in exactly the same fassion. Are you telling me that the IM > on one device is not the same service as IM on another? > > A service does not equal a device. There may be yet another terminology confusion. Some of us (and I think the Data Model) use 'service' to refer to what one might also call a service instance, i.e., a particular reachable URI of a particular service type. Thus, the service [class] 'IM' might have many service instances, located on some varying number of devices, however defined. (Multiple instances could be on one device.) _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jul 30 11:04:55 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13503; Fri, 30 Jul 2004 11:04:55 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BqYya-00013q-Fi; Fri, 30 Jul 2004 11:07:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BqYtY-0004lY-H6; Fri, 30 Jul 2004 11:02:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BqYX9-0003ki-A3 for simple@megatron.ietf.org; Fri, 30 Jul 2004 10:38:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11237 for ; Fri, 30 Jul 2004 10:38:53 -0400 (EDT) Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BqYZL-0000S9-Jv for simple@ietf.org; Fri, 30 Jul 2004 10:41:15 -0400 Received: from [10.10.108.16] ([65.119.52.228]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id i6UEcdLC050044 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 30 Jul 2004 09:38:40 -0500 (CDT) (envelope-from ben@nostrum.com) In-Reply-To: <4108DA56.1060803@dynamicsoft.com> References: <1091061664.1984.12.camel@localhost.localdomain> <4108DA56.1060803@dynamicsoft.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <222EC56B-E236-11D8-93B7-000D93B0AE1A@nostrum.com> Content-Transfer-Encoding: 7bit From: Ben Campbell Subject: Re: [Simple] WG call for comment: Auth48 changes to winfo-package Date: Fri, 30 Jul 2004 09:38:33 -0500 To: Jonathan Rosenberg X-Mailer: Apple Mail (2.618) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit Cc: simple@ietf.org, Robert Sparks X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: 7bit I agree with all the changes, with one question below: On Jul 29, 2004, at 6:07 AM, Jonathan Rosenberg wrote: [...] > > OLD: > > Watcherinfo notifications MAY be generated for watcher information on > package foo, when the subscription state for a user on package foo > changes. The watcher information package therefore needs a model of > subscription state. > > NEW (add text and split into two paragraphs): > > Each watcherinfo subscription is associated with a set of "inner" > subscriptions being watched. This set is defined by the URI in the > Request URI of the watcherinfo SUBSCRIBE request, along with the > parent event package of the watcherinfo subscription. The parent event > package is obtained by removing the trailing ".winfo" from the value > of the Event header field from the watcherinfo SUBSCRIBE request. If > the Event header field in the watcherinfo subscription has a value of > "presence.winfo", the parent event package is "presence". If the Event > header field has a value of "presence.winfo.winfo", the parent event > package is "presence.winfo". Normally, the URI in the Request URI of > the watcherinfo SUBSCRIBE identifies an address-of-record within the > domain. In that case, the set of subscriptions to be watched are all > of the subscriptions for the parent event package that have been made > to the resource in the Request URI of the watcherinfo SUBSCRIBE. > However, the Request URI can contin a URI that defines a larger > collection of resources. For example, sip:all-resources@example.com > might be defined within example.com to refer to all resources. In that > case, a watcherinfo subscription for "presence.winfo" to > sip:all-resources@example.com is requesting notifications any time the > state of any presence subscription for any resource within example.com > changes. A watcherinfo notifier MAY generate a notification any time > the state of any of the watched subscriptions changes. > Do you mean to only allow winfo subscriptions to _larger_ scopes that "all subscribers to a resource?" Is it possible to have something like "sip:AoLUsersWatchingBen@example.com" that only tells me about watchers in the AoL domain, but not watchers from some other domain? (I am not expressing a strong feeling that this is needed; I am only trying to understand the intent.) > Because a watcherinfo subscription is made to a collection of > subscriptions, the watcher information package needs a model of > subscription state. > [...] _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sat Jul 31 14:49:32 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09603; Sat, 31 Jul 2004 14:49:31 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bqyxk-0003ld-QQ; Sat, 31 Jul 2004 14:52:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BqynE-00089V-SY; Sat, 31 Jul 2004 14: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 1Bqybb-00062D-C8; Sat, 31 Jul 2004 14:29:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08872; Sat, 31 Jul 2004 14:29:13 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bqye5-0003Vs-3e; Sat, 31 Jul 2004 14:31:50 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 31 Jul 2004 11:29:44 -0700 X-BrightmailFiltered: true Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i6VHSdtn013065; Sat, 31 Jul 2004 10:28:40 -0700 (PDT) Received: from [127.0.0.1] (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id AVV10439; Sat, 31 Jul 2004 11:27:28 -0700 (PDT) In-Reply-To: <200407280151.VAA27512@ietf.org> References: <200407280151.VAA27512@ietf.org> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Rohan Mahy Date: Sat, 31 Jul 2004 11:30:17 -0700 To: zhangpeihao@citiz.net X-Mailer: Apple Mail (2.618) X-Spam-Score: 2.3 (++) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit Cc: "sip@ietf.org" , Rohan Mahy , sip-implementors , SIMPLE Subject: [Simple] Re: [Sip] Where can I find a free SIMPLE server? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 2.3 (++) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit Hello, Please do not cross-post to multiple lists. For example, the SIP list is for development of the SIP protocol, not for implementation questions such as this. (If anyone answers your question on the sip-implementors or SIMPLE lists, please only copy a single mailing list.) You may be interested in SIMPLEt. The next one will be in November in the Seattle area: http://www.sipit.net/ Thanks, -rohan co-chair SIP WG On Jul 27, 2004, at 6:49 PM, zhangpeihao wrote: > Hi all, > > I have created a SIMPLE client, I want test it now. > > Where can I find a free SIMPLE server for test? > > Thanks, > > zhangpeihao > zhangpeihao@citiz.net > 2004-07-28 > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple