From mailman-admin@ietf.org Sat May 1 10:25: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 KAA19825 for ; Sat, 1 May 2004 10:25:02 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJvQN-0006a5-9J for simple-archive@ietf.org; Sat, 01 May 2004 10:25:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJvPN-0006Lj-00 for simple-archive@ietf.org; Sat, 01 May 2004 10:24:01 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJvOM-00066S-00 for simple-archive@ietf.org; Sat, 01 May 2004 10:22:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJuGm-00084s-Vg for simple-archive@ietf.org; Sat, 01 May 2004 09:11:04 -0400 Date: Sat, 01 May 2004 09:11:04 -0400 Message-ID: <20040501131104.27207.73925.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: simple-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: mailman-admin@ietf.org Errors-To: mailman-admin@ietf.org X-BeenThere: mailman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, simple-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. *************************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. *************************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. Thanks! Passwords for simple-archive@ietf.org: List Password // URL ---- -------- simple@ietf.org onahda https://www1.ietf.org/mailman/options/simple/simple-archive%40ietf.org From exim@www1.ietf.org Sat May 1 12:54:28 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01611 for ; Sat, 1 May 2004 12:54:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJxHd-000848-3K for simple-archive@odin.ietf.org; Sat, 01 May 2004 12:24:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i41GO9kX031004 for simple-archive@odin.ietf.org; Sat, 1 May 2004 12:24:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJv7z-0004nP-DT for simple-web-archive@optimus.ietf.org; Sat, 01 May 2004 10:06: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 KAA17156 for ; Sat, 1 May 2004 10:06: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 1BJv7x-0002c2-CB for simple-web-archive@ietf.org; Sat, 01 May 2004 10:06:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJv71-0002PZ-00 for simple-web-archive@ietf.org; Sat, 01 May 2004 10:05:04 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJv69-0002DM-00 for simple-web-archive@ietf.org; Sat, 01 May 2004 10:04:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJuD3-0004cg-II for simple-web-archive@ietf.org; Sat, 01 May 2004 09:07:13 -0400 Date: Sat, 01 May 2004 09:07:13 -0400 Message-ID: <20040501130713.27207.35736.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: simple-web-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: mailman-admin@ietf.org Errors-To: mailman-admin@ietf.org X-BeenThere: mailman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, simple-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. *************************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. *************************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. Thanks! Passwords for simple-web-archive@ietf.org: List Password // URL ---- -------- simple@ietf.org fuasex https://www1.ietf.org/mailman/options/simple/simple-web-archive%40ietf.org From simple-admin@ietf.org Sat May 1 14:40: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 OAA18403 for ; Sat, 1 May 2004 14:40: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 1BJzPw-0002LN-Hc for simple-archive@ietf.org; Sat, 01 May 2004 14:40:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJzOe-00022X-00 for simple-archive@ietf.org; Sat, 01 May 2004 14:39:32 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJzNd-0001kr-00; Sat, 01 May 2004 14:38:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJz9m-0005Pv-UR; Sat, 01 May 2004 14:24:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJz6U-0002j0-4t for simple@optimus.ietf.org; Sat, 01 May 2004 14:20: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 OAA14686 for ; Sat, 1 May 2004 14:20: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 1BJz2p-0003r6-I2 for simple@ietf.org; Sat, 01 May 2004 14:16:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJyyL-0002cE-00 for simple@ietf.org; Sat, 01 May 2004 14:12:23 -0400 Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx with esmtp (Exim 4.12) id 1BJye4-0006B0-00 for simple@ietf.org; Sat, 01 May 2004 13:51:24 -0400 Received: from cs.columbia.edu (chairpc.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i41HpLZ2018855 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 1 May 2004 13:51:22 -0400 (EDT) Message-ID: <4093E399.9030508@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040421 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Simple WG Subject: Re: [Simple] Update to xcap authorization rules - rpid type References: <4092A750.3080501@dynamicsoft.com> In-Reply-To: <4092A750.3080501@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 4.6.0.97784, Antispam-Core: 4.6.0.97340, Antispam-Data: 2004.4.30.99508 X-PerlMx-Spam: Gauge=IIIIIIII, Probability=8%, Report='__MOZILLA_MSGID 0, __HAS_MSGID 0, __SANE_MSGID 0, __USER_AGENT 0, X_ACCEPT_LANG 0, __MIME_VERSION 0, __TO_MALFORMED_2 0, __REFERENCES 0, __IN_REP_TO 0, __EVITE_CTYPE 0, __CT_TEXT_PLAIN 0, __CT 0, __CTE 0, __UNUSABLE_MSGID 0, QUOTED_EMAIL_TEXT 0, __MIME_TEXT_ONLY 0, REFERENCES 0.000, IN_REP_TO 0, USER_AGENT 0.000' Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 01 May 2004 13:51:21 -0400 X-Spam-Checker-Version: SpamAssassin 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'm not sure I completely understand the item below, but one potential concern is that this may mix conditions and actions in one element, with less-than-clear expressions. It is probably less efficient, but clearer, in my opinion, to keep the two separate, even if it means expressing them as two or more separate rules. We don't necessarily want to design to a user interface, but the more sub-clauses and conditions something has, the more difficult it becomes to write simple GUIs for it. (This also greatly complicates translation into other rule mechanisms.) Thus, I'd prefer an explicit equality condition on (say) class and placetype, with an associated list of included objects. Doing the same thing in two ways, just because they are two different attributes, doesn't strike me as a minimalist design. > * Formerly, each of the permissions granted access to an rpid type, > and allowed you to indicate which tuple, identified by class, it was > included in. There were several problems here. One, identified by > Markus, is the lack of a short-hand for saying "tuples of all > classes". Another problem is that it only allowed usage of the "class" > attribute as a means for selecting which tuples to include it in. I > have figured out how to extend this to a bunch of different selectors, > and have included ones for class, placetype, privacy, relationship, > sphere and contact-type. This is done by defining all of the > provide-foo elements as sets, rather than boolean, and the set members > identify the tuple-selector criteria by RIPD element name/value. So, > for example, to include the placetype attribute in all tuples where > placetype has a value of home OR the class is friend: > > > > home > friend > > > > Since, according to the common-policy rules, composition of sets is > done by union, the above is identical to: > > > > friend > > > > > > home > > > > which could appear in the same or separate permission documents. > > Its also possible to explicitly say "all-tuples". I don't have > qualifiers for things like "all tuples that include any class", but > these can easily be added under the set definition. If folks want to > explicitly see something added, please comment. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Sat May 1 14:50:19 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18858 for ; Sat, 1 May 2004 14:50:19 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJzWy-0006jO-S9 for simple-archive@odin.ietf.org; Sat, 01 May 2004 14:48:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i41Im8xr025870 for simple-archive@odin.ietf.org; Sat, 1 May 2004 14:48:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJzPz-0003wu-Ud for simple-web-archive@optimus.ietf.org; Sat, 01 May 2004 14:40: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 OAA18421 for ; Sat, 1 May 2004 14:40: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 1BJzPx-0002LS-8K for simple-web-archive@ietf.org; Sat, 01 May 2004 14:40:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJzOe-00022e-00 for simple-web-archive@ietf.org; Sat, 01 May 2004 14:39:33 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJzNd-0001kr-00; Sat, 01 May 2004 14:38:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJz9m-0005Pv-UR; Sat, 01 May 2004 14:24:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJz6U-0002j0-4t for simple@optimus.ietf.org; Sat, 01 May 2004 14:20: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 OAA14686 for ; Sat, 1 May 2004 14:20: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 1BJz2p-0003r6-I2 for simple@ietf.org; Sat, 01 May 2004 14:16:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJyyL-0002cE-00 for simple@ietf.org; Sat, 01 May 2004 14:12:23 -0400 Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx with esmtp (Exim 4.12) id 1BJye4-0006B0-00 for simple@ietf.org; Sat, 01 May 2004 13:51:24 -0400 Received: from cs.columbia.edu (chairpc.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i41HpLZ2018855 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 1 May 2004 13:51:22 -0400 (EDT) Message-ID: <4093E399.9030508@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040421 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Simple WG Subject: Re: [Simple] Update to xcap authorization rules - rpid type References: <4092A750.3080501@dynamicsoft.com> In-Reply-To: <4092A750.3080501@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 4.6.0.97784, Antispam-Core: 4.6.0.97340, Antispam-Data: 2004.4.30.99508 X-PerlMx-Spam: Gauge=IIIIIIII, Probability=8%, Report='__MOZILLA_MSGID 0, __HAS_MSGID 0, __SANE_MSGID 0, __USER_AGENT 0, X_ACCEPT_LANG 0, __MIME_VERSION 0, __TO_MALFORMED_2 0, __REFERENCES 0, __IN_REP_TO 0, __EVITE_CTYPE 0, __CT_TEXT_PLAIN 0, __CT 0, __CTE 0, __UNUSABLE_MSGID 0, QUOTED_EMAIL_TEXT 0, __MIME_TEXT_ONLY 0, REFERENCES 0.000, IN_REP_TO 0, USER_AGENT 0.000' Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 01 May 2004 13:51:21 -0400 X-Spam-Checker-Version: SpamAssassin 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 Content-Transfer-Encoding: 7bit I'm not sure I completely understand the item below, but one potential concern is that this may mix conditions and actions in one element, with less-than-clear expressions. It is probably less efficient, but clearer, in my opinion, to keep the two separate, even if it means expressing them as two or more separate rules. We don't necessarily want to design to a user interface, but the more sub-clauses and conditions something has, the more difficult it becomes to write simple GUIs for it. (This also greatly complicates translation into other rule mechanisms.) Thus, I'd prefer an explicit equality condition on (say) class and placetype, with an associated list of included objects. Doing the same thing in two ways, just because they are two different attributes, doesn't strike me as a minimalist design. > * Formerly, each of the permissions granted access to an rpid type, > and allowed you to indicate which tuple, identified by class, it was > included in. There were several problems here. One, identified by > Markus, is the lack of a short-hand for saying "tuples of all > classes". Another problem is that it only allowed usage of the "class" > attribute as a means for selecting which tuples to include it in. I > have figured out how to extend this to a bunch of different selectors, > and have included ones for class, placetype, privacy, relationship, > sphere and contact-type. This is done by defining all of the > provide-foo elements as sets, rather than boolean, and the set members > identify the tuple-selector criteria by RIPD element name/value. So, > for example, to include the placetype attribute in all tuples where > placetype has a value of home OR the class is friend: > > > > home > friend > > > > Since, according to the common-policy rules, composition of sets is > done by union, the above is identical to: > > > > friend > > > > > > home > > > > which could appear in the same or separate permission documents. > > Its also possible to explicitly say "all-tuples". I don't have > qualifiers for things like "all tuples that include any class", but > these can easily be added under the set definition. If folks want to > explicitly see something added, please comment. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Sat May 1 15:56: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 PAA22092 for ; Sat, 1 May 2004 15:56: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 1BK0av-00011M-Rv for simple-archive@ietf.org; Sat, 01 May 2004 15:56:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BK0Zy-0000p6-00 for simple-archive@ietf.org; Sat, 01 May 2004 15:55:18 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BK0ZR-0000d7-00; Sat, 01 May 2004 15:54:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BK0P3-000630-Uq; Sat, 01 May 2004 15:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BK0DZ-0000yq-Md for simple@optimus.ietf.org; Sat, 01 May 2004 15:32: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 PAA21295 for ; Sat, 1 May 2004 15:32:08 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BK0DY-0004Hm-Cq for simple@ietf.org; Sat, 01 May 2004 15:32:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BK0Cd-00046z-00 for simple@ietf.org; Sat, 01 May 2004 15:31:12 -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 1BK0Bs-0003jx-00 for simple@ietf.org; Sat, 01 May 2004 15:30:24 -0400 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i41JTpSu017680; Sat, 1 May 2004 12:29:52 -0700 (PDT) Received: from [10.0.0.107] (sjc-vpn2-1062.cisco.com [10.21.116.38]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id AOO95343; Sat, 1 May 2004 12:29:50 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Subject: Re: [Simple] MSRP: DSN lifetime open issue From: Cullen Jennings To: , , Message-ID: In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701797918@esebe019.ntc.nokia.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 30 Apr 2004 08:30:00 -1000 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 Every real IM system I use, including SMS, supports stored messages. Seems like a desirable property of an "Instant" messaging system. Not sure what that means for DSN. On 4/16/04 12:22 AM, "hisham.khartabil@nokia.com" wrote: > This is a session mode instant messaging, therefore I would think that > participants would not care about any DSNs after the session has been torn > down. If they want the DSN, then they need to wait before tearing down the > session. > > In page mode, you would need to allow the DSN to come days later. But that is > not the issue here. > > I guess I'm suggesting that all outstanding DSNs are discarded. I don't think > that the penalty that the relay has to try to send the DSN anyway is such a > huge problem. If it is, then we probably need to send a MSRP level BYE request > that traverses relays. > > /Hisham > >> -----Original Message----- >> From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of >> ext Ben Campbell >> Sent: 15.April.2004 18:31 >> To: Simple WG >> Subject: [Simple] MSRP: DSN lifetime open issue >> >> >> One open issue concerning MSRP usage of DSN that I would like >> to close >> on is, what happens to DSNs after a session is torn down? >> >> Example: >> >> A R B >> SEND-------> >> <---------OK >> SEND----X >> <---session teardown---> >> <-----REPORT >> >> >> In this example, A sends a message to B via relay R. The >> A-->R hop works >> fine. The R->B hop failes, due to a tcp error. For the sake >> of argument, >> consider this to be a worst case TCP error where the TCP stack has to >> work through the entire retransmission sequence before it >> gives up, that >> is, a non-trivial amount of time passes. >> >> A and B tear down the session. But since R is not session >> stateful, it >> does not know about this. >> >> So, the question becomes, what happens to outstanding DSN after a >> session is closed? Do they just get dropped? (This is not as >> simple as >> it sounds, since if a relay is not aware of the session >> closure, it will >> still try to send the DSN, wasting resources.) >> >> Or, do we want to be able to deliver DSN outside of the scope of the >> session in which it was generated? >> >> I have had several offline discussions with people, and have gotten >> opinions that range from allowing DSN to be sent days later, >> to assuming >> that all outstanding DSN just get discarded. >> >> Thoughts? >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple >> > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Sat May 1 16:11:44 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22844 for ; Sat, 1 May 2004 16:11:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BK0lV-0006I5-Qv for simple-archive@odin.ietf.org; Sat, 01 May 2004 16:07:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i41K7D9s024176 for simple-archive@odin.ietf.org; Sat, 1 May 2004 16:07:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BK0ay-0002k5-1X for simple-web-archive@optimus.ietf.org; Sat, 01 May 2004 15:56: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 PAA22112 for ; Sat, 1 May 2004 15:56: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 1BK0aw-00011R-KW for simple-web-archive@ietf.org; Sat, 01 May 2004 15:56:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BK0Zy-0000pD-00 for simple-web-archive@ietf.org; Sat, 01 May 2004 15:55:19 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BK0ZR-0000d7-00; Sat, 01 May 2004 15:54:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BK0P3-000630-Uq; Sat, 01 May 2004 15:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BK0DZ-0000yq-Md for simple@optimus.ietf.org; Sat, 01 May 2004 15:32: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 PAA21295 for ; Sat, 1 May 2004 15:32:08 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BK0DY-0004Hm-Cq for simple@ietf.org; Sat, 01 May 2004 15:32:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BK0Cd-00046z-00 for simple@ietf.org; Sat, 01 May 2004 15:31:12 -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 1BK0Bs-0003jx-00 for simple@ietf.org; Sat, 01 May 2004 15:30:24 -0400 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i41JTpSu017680; Sat, 1 May 2004 12:29:52 -0700 (PDT) Received: from [10.0.0.107] (sjc-vpn2-1062.cisco.com [10.21.116.38]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id AOO95343; Sat, 1 May 2004 12:29:50 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Subject: Re: [Simple] MSRP: DSN lifetime open issue From: Cullen Jennings To: , , Message-ID: In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701797918@esebe019.ntc.nokia.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 30 Apr 2004 08:30:00 -1000 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 Content-Transfer-Encoding: 7bit Every real IM system I use, including SMS, supports stored messages. Seems like a desirable property of an "Instant" messaging system. Not sure what that means for DSN. On 4/16/04 12:22 AM, "hisham.khartabil@nokia.com" wrote: > This is a session mode instant messaging, therefore I would think that > participants would not care about any DSNs after the session has been torn > down. If they want the DSN, then they need to wait before tearing down the > session. > > In page mode, you would need to allow the DSN to come days later. But that is > not the issue here. > > I guess I'm suggesting that all outstanding DSNs are discarded. I don't think > that the penalty that the relay has to try to send the DSN anyway is such a > huge problem. If it is, then we probably need to send a MSRP level BYE request > that traverses relays. > > /Hisham > >> -----Original Message----- >> From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of >> ext Ben Campbell >> Sent: 15.April.2004 18:31 >> To: Simple WG >> Subject: [Simple] MSRP: DSN lifetime open issue >> >> >> One open issue concerning MSRP usage of DSN that I would like >> to close >> on is, what happens to DSNs after a session is torn down? >> >> Example: >> >> A R B >> SEND-------> >> <---------OK >> SEND----X >> <---session teardown---> >> <-----REPORT >> >> >> In this example, A sends a message to B via relay R. The >> A-->R hop works >> fine. The R->B hop failes, due to a tcp error. For the sake >> of argument, >> consider this to be a worst case TCP error where the TCP stack has to >> work through the entire retransmission sequence before it >> gives up, that >> is, a non-trivial amount of time passes. >> >> A and B tear down the session. But since R is not session >> stateful, it >> does not know about this. >> >> So, the question becomes, what happens to outstanding DSN after a >> session is closed? Do they just get dropped? (This is not as >> simple as >> it sounds, since if a relay is not aware of the session >> closure, it will >> still try to send the DSN, wasting resources.) >> >> Or, do we want to be able to deliver DSN outside of the scope of the >> session in which it was generated? >> >> I have had several offline discussions with people, and have gotten >> opinions that range from allowing DSN to be sent days later, >> to assuming >> that all outstanding DSN just get discarded. >> >> Thoughts? >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple >> > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon May 3 05:29: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 FAA16713 for ; Mon, 3 May 2004 05:29: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 1BKZl9-0004rk-4h for simple-archive@ietf.org; Mon, 03 May 2004 05:29:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKZhn-0004IJ-00 for simple-archive@ietf.org; Mon, 03 May 2004 05:25:44 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BKZe5-0003cX-00; Mon, 03 May 2004 05:21:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKZUZ-0003z9-Uv; Mon, 03 May 2004 05:12:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKZT8-0003YH-GH for simple@optimus.ietf.org; Mon, 03 May 2004 05:10: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 FAA15885 for ; Mon, 3 May 2004 05:10: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 1BKZT5-0001lM-53 for simple@ietf.org; Mon, 03 May 2004 05:10:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKZPZ-0001EY-00 for simple@ietf.org; Mon, 03 May 2004 05:06:54 -0400 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1BKZN0-0000kC-00 for simple@ietf.org; Mon, 03 May 2004 05:04:14 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i43928H10389; Mon, 3 May 2004 12:02:08 +0300 (EET DST) X-Scanned: Mon, 3 May 2004 12:01:48 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i4391mZC032388; Mon, 3 May 2004 12:01:48 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00cudoqe; Mon, 03 May 2004 12:01: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 i4391eH12327; Mon, 3 May 2004 12:01: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); Mon, 3 May 2004 12:01:38 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] WGLC: partial notification Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797A02@esebe019.ntc.nokia.com> Thread-Topic: [Simple] WGLC: partial notification Thread-Index: AcQupqFOST9kXntESVu3HVwK1rkaWACRCMIw To: , , Cc: , X-OriginalArrivalTime: 03 May 2004 09:01:38.0943 (UTC) FILETIME=[3EA268F0:01C430ED] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 3 May 2004 12:01:38 +0300 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 Schmidt Christian [mailto:christian-schmidt@siemens.com] > Sent: 30.April.2004 14:28 > To: Khartabil Hisham (Nokia-TP-MSW/Helsinki); pkyzivat@cisco.com; > rsparks@dynamicsoft.com > Cc: Lonnfors Mikko (Nokia-NRC/Helsinki); simple@ietf.org > Subject: AW: [Simple] WGLC: partial notification >=20 >=20 > Hi Hisham, >=20 > this proposal would not solve the problem with a missing=20 > NOTIFY (full or partial).=20 Can you demonstrate why with some flows? >=20 > What=B4s about the following proposal: > The notifier must not issue a NOTIFY (full or partial),=20 > before it receives a 200 for the last issued NOTIFY (full or=20 > partial). After experation of a timer t, the notifier should=20 > send a full NOTIFY. If a NOTIFY transaction does not complete, the subscription is = terminated. If you are suggesting that timer t is less than 64*T1 (timer = F, that's when the transaction terminates and subsequently the = subscription), then you are suggesting support for overlapping NOTIFYs. Sending a full state NOTIFY after timer t does not help since if no = response arrives for the partial NOTIFY, the subscription will = terminate. /Hisham >=20 > This would also work without version number and would cover=20 > reordering and packet loss cases. >=20 > Regards, > Christian >=20 >=20 >=20 > -----Urspr=FCngliche Nachricht----- > Von: simple-admin@ietf.org [mailto:simple-admin@ietf.org] Im=20 > Auftrag von hisham.khartabil@nokia.com > Gesendet: Freitag, 30. April 2004 08:27 > An: pkyzivat@cisco.com; rsparks@dynamicsoft.com > Cc: mikko.lonnfors@nokia.com; simple@ietf.org > Betreff: RE: [Simple] WGLC: partial notification >=20 >=20 > Ok, I also agree that overlapping partial NOTIFYs complicate=20 > things without benefit. I also would like to propose=20 > explicitly disallowing overlapping full state and partial.=20 > I.e. A notifier must not issue a partial state NOTIFY without=20 > first receiving the 200 for a full state NOTIFY. I believe=20 > the converse is also required: the notifier must not issue a=20 > full state NOTIFY before it receives a 200 for a partial state NOTIFY. >=20 > With all there restrictions, we can do without the version attribute. >=20 > Regards, > Hisham >=20 > > -----Original Message----- > > From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] > > Sent: 29.April.2004 21:47 > > To: Robert Sparks > > Cc: Khartabil Hisham (Nokia-TP-MSW/Helsinki); Lonnfors Mikko > > (Nokia-NRC/Helsinki); simple@ietf.org > > Subject: Re: [Simple] WGLC: partial notification > >=20 > >=20 > >=20 > >=20 > > Robert Sparks wrote: > > > Aside from that I'd like for you to think through this again > > > from viewpoints besides active attack (use a transient malfunction > > > of the application (above the layer that would screw up=20 > basic SIP)), > > > I'm ready to let this go as long as we have _a_ solid solution to > > > dealing with reordered/missing notifies. > >=20 > > I'm not going to start down the path to speculation about how=20 > > to recover=20 > > from arbitrary malfunctions of an application. That is just plain=20 > > impossible without some characterization of the kinds of=20 > malfunctions=20 > > that are to be recovered from. > >=20 > > > So, backing out a layer, lets look at my original question of > > > whether or not we allow overlapping ->partial<- NOTIFYs at all > > > in this case. > >=20 > > I don't see any compelling need to support overlapping=20 > > partial notifies.=20 > > It is very difficult to see how to make them work. > >=20 > > I can imagine a case where there might be some motivation:=20 > I sent one=20 > > notification and have had no response. But I already have a=20 > bunch of=20 > > additional changes that you should know about. It might be=20 > > advantageous=20 > > to start sending them as soon as possible. But until you know=20 > > the prior=20 > > one has been handled it isn't safe to send the new one. > >=20 > > > Why would you want to? What value would doing that bring?=20 > > >=20 > > > 3261 and even presence-10 left sending full-state presence > > > NOTIFYs open. We wouldn't be changing that. If an application > > > for some reason decided it needed to send a new full-state > > > notify while a partial-state notify was pending, it could. > > > So any of the arguments for allowing it from the 3261/presence-10 > > > are still satisfied. Can you see any use case where allowing > > > a server to send overlapping partial NOTIFYs is a good idea? > > > If not, disallowing it seems a powerful simplification. > > > > >=20 > > I agree. > >=20 > > Paul > >=20 > >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon May 3 05:34:20 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17067 for ; Mon, 3 May 2004 05:34:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKZoZ-0002oF-Bc for simple-archive@odin.ietf.org; Mon, 03 May 2004 05:32:43 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i439WgCt010703 for simple-archive@odin.ietf.org; Mon, 3 May 2004 05:32:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKZlD-00011Y-HP for simple-web-archive@optimus.ietf.org; Mon, 03 May 2004 05:29: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 FAA16733 for ; Mon, 3 May 2004 05:29: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 1BKZlA-0004rt-48 for simple-web-archive@ietf.org; Mon, 03 May 2004 05:29:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKZho-0004IZ-00 for simple-web-archive@ietf.org; Mon, 03 May 2004 05:25:46 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BKZe5-0003cX-00; Mon, 03 May 2004 05:21:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKZUZ-0003z9-Uv; Mon, 03 May 2004 05:12:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKZT8-0003YH-GH for simple@optimus.ietf.org; Mon, 03 May 2004 05:10: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 FAA15885 for ; Mon, 3 May 2004 05:10: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 1BKZT5-0001lM-53 for simple@ietf.org; Mon, 03 May 2004 05:10:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKZPZ-0001EY-00 for simple@ietf.org; Mon, 03 May 2004 05:06:54 -0400 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1BKZN0-0000kC-00 for simple@ietf.org; Mon, 03 May 2004 05:04:14 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i43928H10389; Mon, 3 May 2004 12:02:08 +0300 (EET DST) X-Scanned: Mon, 3 May 2004 12:01:48 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i4391mZC032388; Mon, 3 May 2004 12:01:48 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00cudoqe; Mon, 03 May 2004 12:01: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 i4391eH12327; Mon, 3 May 2004 12:01: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); Mon, 3 May 2004 12:01:38 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] WGLC: partial notification Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797A02@esebe019.ntc.nokia.com> Thread-Topic: [Simple] WGLC: partial notification Thread-Index: AcQupqFOST9kXntESVu3HVwK1rkaWACRCMIw To: , , Cc: , X-OriginalArrivalTime: 03 May 2004 09:01:38.0943 (UTC) FILETIME=[3EA268F0:01C430ED] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 3 May 2004 12:01:38 +0300 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 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Schmidt Christian [mailto:christian-schmidt@siemens.com] > Sent: 30.April.2004 14:28 > To: Khartabil Hisham (Nokia-TP-MSW/Helsinki); pkyzivat@cisco.com; > rsparks@dynamicsoft.com > Cc: Lonnfors Mikko (Nokia-NRC/Helsinki); simple@ietf.org > Subject: AW: [Simple] WGLC: partial notification >=20 >=20 > Hi Hisham, >=20 > this proposal would not solve the problem with a missing=20 > NOTIFY (full or partial).=20 Can you demonstrate why with some flows? >=20 > What=B4s about the following proposal: > The notifier must not issue a NOTIFY (full or partial),=20 > before it receives a 200 for the last issued NOTIFY (full or=20 > partial). After experation of a timer t, the notifier should=20 > send a full NOTIFY. If a NOTIFY transaction does not complete, the subscription is = terminated. If you are suggesting that timer t is less than 64*T1 (timer = F, that's when the transaction terminates and subsequently the = subscription), then you are suggesting support for overlapping NOTIFYs. Sending a full state NOTIFY after timer t does not help since if no = response arrives for the partial NOTIFY, the subscription will = terminate. /Hisham >=20 > This would also work without version number and would cover=20 > reordering and packet loss cases. >=20 > Regards, > Christian >=20 >=20 >=20 > -----Urspr=FCngliche Nachricht----- > Von: simple-admin@ietf.org [mailto:simple-admin@ietf.org] Im=20 > Auftrag von hisham.khartabil@nokia.com > Gesendet: Freitag, 30. April 2004 08:27 > An: pkyzivat@cisco.com; rsparks@dynamicsoft.com > Cc: mikko.lonnfors@nokia.com; simple@ietf.org > Betreff: RE: [Simple] WGLC: partial notification >=20 >=20 > Ok, I also agree that overlapping partial NOTIFYs complicate=20 > things without benefit. I also would like to propose=20 > explicitly disallowing overlapping full state and partial.=20 > I.e. A notifier must not issue a partial state NOTIFY without=20 > first receiving the 200 for a full state NOTIFY. I believe=20 > the converse is also required: the notifier must not issue a=20 > full state NOTIFY before it receives a 200 for a partial state NOTIFY. >=20 > With all there restrictions, we can do without the version attribute. >=20 > Regards, > Hisham >=20 > > -----Original Message----- > > From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] > > Sent: 29.April.2004 21:47 > > To: Robert Sparks > > Cc: Khartabil Hisham (Nokia-TP-MSW/Helsinki); Lonnfors Mikko > > (Nokia-NRC/Helsinki); simple@ietf.org > > Subject: Re: [Simple] WGLC: partial notification > >=20 > >=20 > >=20 > >=20 > > Robert Sparks wrote: > > > Aside from that I'd like for you to think through this again > > > from viewpoints besides active attack (use a transient malfunction > > > of the application (above the layer that would screw up=20 > basic SIP)), > > > I'm ready to let this go as long as we have _a_ solid solution to > > > dealing with reordered/missing notifies. > >=20 > > I'm not going to start down the path to speculation about how=20 > > to recover=20 > > from arbitrary malfunctions of an application. That is just plain=20 > > impossible without some characterization of the kinds of=20 > malfunctions=20 > > that are to be recovered from. > >=20 > > > So, backing out a layer, lets look at my original question of > > > whether or not we allow overlapping ->partial<- NOTIFYs at all > > > in this case. > >=20 > > I don't see any compelling need to support overlapping=20 > > partial notifies.=20 > > It is very difficult to see how to make them work. > >=20 > > I can imagine a case where there might be some motivation:=20 > I sent one=20 > > notification and have had no response. But I already have a=20 > bunch of=20 > > additional changes that you should know about. It might be=20 > > advantageous=20 > > to start sending them as soon as possible. But until you know=20 > > the prior=20 > > one has been handled it isn't safe to send the new one. > >=20 > > > Why would you want to? What value would doing that bring?=20 > > >=20 > > > 3261 and even presence-10 left sending full-state presence > > > NOTIFYs open. We wouldn't be changing that. If an application > > > for some reason decided it needed to send a new full-state > > > notify while a partial-state notify was pending, it could. > > > So any of the arguments for allowing it from the 3261/presence-10 > > > are still satisfied. Can you see any use case where allowing > > > a server to send overlapping partial NOTIFYs is a good idea? > > > If not, disallowing it seems a powerful simplification. > > > > >=20 > > I agree. > >=20 > > Paul > >=20 > >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon May 3 06:00:30 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17989 for ; Mon, 3 May 2004 06: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 1BKaFT-00022b-5s for simple-archive@ietf.org; Mon, 03 May 2004 06:00:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKaBQ-0001QR-00 for simple-archive@ietf.org; Mon, 03 May 2004 05:56:22 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BKa6n-0000dG-00; Mon, 03 May 2004 05:51:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKa0e-00075S-91; Mon, 03 May 2004 05:45:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKZua-0005CB-L8 for simple@optimus.ietf.org; Mon, 03 May 2004 05:38: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 FAA17254 for ; Mon, 3 May 2004 05:38:52 -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 1BKZuX-0006Rx-4p for simple@ietf.org; Mon, 03 May 2004 05:38:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKZr7-0005wu-00 for simple@ietf.org; Mon, 03 May 2004 05:35:22 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BKZnv-0005KD-00 for simple@ietf.org; Mon, 03 May 2004 05:32:04 -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 i439W2v28609; Mon, 3 May 2004 12:32:02 +0300 (EET DST) X-Scanned: Mon, 3 May 2004 12:30:51 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i439UpcK021892; Mon, 3 May 2004 12:30:51 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 008qNsaB; Mon, 03 May 2004 12:30:50 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 i439UiH14139; Mon, 3 May 2004 12:30:44 +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); Mon, 3 May 2004 12:30:44 +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 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF01C1DEC8@esebe004.ntc.nokia.com> Thread-Topic: Comments on draft-ietf-simple-partial-notify-02 Thread-Index: AcQtPtY6iL6H1WczSoeK6QeEpHYrwAADYouA To: , Cc: , X-OriginalArrivalTime: 03 May 2004 09:30:44.0815 (UTC) FILETIME=[4F4155F0:01C430F1] Content-Transfer-Encoding: quoted-printable Subject: [Simple] RE: Comments on draft-ietf-simple-partial-notify-02 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 3 May 2004 12:30:44 +0300 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable >=20 > I have a couple of non-fundamental observations on the partial notify=20 > draft. >=20 > Obs 1: Overall style challenge: Overuse of requirements language in=20 > descriptive passages. >=20 > People tend to use RFC 2119 requirements language when describing how=20 > things work, rather than when describing actual requirements. >=20 > This is subtle, and many (most?) people don't understand the=20 > difference. You can probably get away with ignoring me here, but it=20 > might be worth > thinking about. It has big implications on the establishment=20 > of formal=20 > compatibility documents -- when people say "MUST" everytime they mean=20 > "does", it makes the real requirements hard to identify. >=20 > As an example, the text in this draft: >=20 > 4.4 Presence agent generation of partial notifications >=20 > If the presence agent decides to send notifications according to=20 > this > specification that include a presence document, the presence agent > MUST build a presence document according to the PIDF extension for > Partial Presence [2] and MUST set the Content-Type header field to > the value 'application/pidf-partial+xml'. >=20 > Tuple ids are used to match tuples across subsequent notifications. > Presence agent MUST use the same tuple ids for tuples which are > identical between subsequent notifications and MUST allocate > different tuple ids for tuples which are different from previously > sent tuples. Presence agents MUST keep tuple ids consistent until=20 > the > next full state presence documentis delivered. The decision on > whether tuple ids are the same or different is left up to > PA's local > policy. >=20 >=20 > Would perhaps be more clearly written as: >=20 > 4.4 Presence agent generation of partial notifications >=20 > If the presence agent decides to send partial notifications in=20 > response > to this subscription, it constructs the partial presence documents > as specified in the PIDF extension for Partial Presence > [2]. As required=20 > by [2], the presence agent sets the Content-Type header=20 > field of each=20 > partial presence document to the value=20 > 'application/pidf-partial+xml'. >=20 > Further requirements apply to partial presence documents, as=20 > follow: >=20 > Tuple ids are used by clients to match tuples across subsequent=20 > notifications. For this matching to succeed, the Presence Agent=20 > MUST > not vary the tuple ids for tuples that have not changed since they > were previously sent on this subscription and and MUST > allocate different=20 > tuple ids for tuples that are different from previously=20 > sent tuples.=20 > Presence agents MUST keep tuple ids consistent until the=20 > next full-state=20 > presence document has been sent and acknowledged. The=20 > decision on whether=20 > tuple ids are the same or different in the next full-state=20 > presence document > is left up to PA's local policy. >=20 >=20 > In the first paragraph, we are describing how the presence agent does=20 > something by way of example. In the second and third, we are stating=20 > requirements that vary from the general way of building presence=20 > documents, i.e, "new requirements". I've also polished the English=20 > slightly. Right, I think I understand your concern. I will try to polish use of RFC2119 requirements language in the next version. > Obs 2: Section 5: > ... The PA accepts the subscription and, based on the "q" parameter=20 > value, selects to send ... >=20 > The phrase "selects to send" is a bit awkward as English construction. > "Selects" has the connotation of choosing from a menu, which is not=20 > quite what we want here. > "Decides to send" might work better. Whatever you choose should align=20 > with the wording you've decided to use in the (elsewhere discussed)=20 > discussion of how the server decided whether or not it was going to=20 > provide partial notifications for this subscription. Right, I will change that and try to align it with the rest of the text. >=20 > Obs 3: Use of domain names in examples: >=20 > Some examples use domain names in "somewhere.com". This probably needs > to be changed to a domain reserved in RFC 2606. Perhaps ".test"? >=20 > After all, "somewhere.com" is a real domain:=20 > Somewhere.Com, LLC > 25 Forest Circle > Winchester, MA 01890 > US Yes, this will be changed to example.com. Thanks - Mikko >=20 > -- > Dean >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon May 3 06:32:29 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19363 for ; Mon, 3 May 2004 06:32:29 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKakQ-0007Eq-79 for simple-archive@ietf.org; Mon, 03 May 2004 06:32:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKagE-0006ZP-00 for simple-archive@ietf.org; Mon, 03 May 2004 06:28:11 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BKacG-0005vW-00; Mon, 03 May 2004 06:24:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKaVU-0002xu-OY; Mon, 03 May 2004 06:17:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKaTo-00022u-3Y for simple@optimus.ietf.org; Mon, 03 May 2004 06:15: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 FAA16635 for ; Mon, 3 May 2004 05:27: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 1BKZj5-0004WA-5J for simple@ietf.org; Mon, 03 May 2004 05:27:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKZfy-0003wy-00 for simple@ietf.org; Mon, 03 May 2004 05:23:52 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BKZdB-0003Rp-00 for simple@ietf.org; Mon, 03 May 2004 05:20:57 -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 i439Ktv15053; Mon, 3 May 2004 12:20:55 +0300 (EET DST) X-Scanned: Mon, 3 May 2004 12:20:27 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i439KRcR016519; Mon, 3 May 2004 12:20:27 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00IOIVf6; Mon, 03 May 2004 12:20:25 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i439KPH26119; Mon, 3 May 2004 12:20:25 +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, 3 May 2004 12:20: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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Presence Rules Issue 1: Provide Contact URI defaults Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797A07@esebe019.ntc.nokia.com> Thread-Topic: [Simple] Presence Rules Issue 1: Provide Contact URI defaults Thread-Index: AcQu7Mmq8E/XW/VFQLWjZdhZ2S7DTQCAr54w To: , X-OriginalArrivalTime: 03 May 2004 09:20:21.0378 (UTC) FILETIME=[DBA86620:01C430EF] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 3 May 2004 12:20:21 +0300 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 vote for 1. /Hisham > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > ext Jonathan Rosenberg > Sent: 30.April.2004 22:30 > To: Simple WG > Subject: [Simple] Presence Rules Issue 1: Provide Contact URI defaults >=20 >=20 > There is currently a permission called provide-contact-uri that=20 > specifies which tuples the contact-uri should be provided in.=20 > Like many=20 > of the other permissions, you can specify which tuples to=20 > include it in=20 > based on the values of a few other rpid parameters. >=20 > The problem is that, for privacy safety, the default of all of these=20 > sets needs to be the empty set. As a result, the default will be that=20 > you never include a contact URI. If you want one in every=20 > tuple, you'd=20 > have to add this: >=20 > > > >=20 > in every permission statement. Or, you could turn it on "globally" by=20 > specifying a rule that applied to everyone (i.e., all domains you=20 > communicate with), which granted just this specific permission. >=20 > There is also no way to say that the contact URI is to be provided in=20 > "barebones" tuples that have no other RPID information in them. >=20 > My concern is that I think that, in practice, it will be=20 > expected that=20 > contact is nearly always provided, and so you'll have to have this=20 > permission pretty much all the time. The "real" default - in terms of=20 > what a user might expect - is not the same as the default of the=20 > permission itself. >=20 > Our options are: >=20 > 1. who cares, its fine, just add the permission > 2. remove the provide-contact-uri permission, and always include a=20 > contact uri >=20 > My proposal is (1). Thoughts? >=20 > -Jonathan R. > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon May 3 06:36:54 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19702 for ; Mon, 3 May 2004 06:36:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKanQ-0000fz-Et for simple-archive@odin.ietf.org; Mon, 03 May 2004 06:35:36 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i43AZaD2002600 for simple-archive@odin.ietf.org; Mon, 3 May 2004 06:35:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKakX-0008JR-Lw for simple-web-archive@optimus.ietf.org; Mon, 03 May 2004 06:32: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 GAA19381 for ; Mon, 3 May 2004 06:32: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 1BKakT-0007FS-Mb for simple-web-archive@ietf.org; Mon, 03 May 2004 06:32:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKagF-0006Zd-00 for simple-web-archive@ietf.org; Mon, 03 May 2004 06:28:13 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BKacG-0005vW-00; Mon, 03 May 2004 06:24:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKaVU-0002xu-OY; Mon, 03 May 2004 06:17:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKaTo-00022u-3Y for simple@optimus.ietf.org; Mon, 03 May 2004 06:15: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 FAA16635 for ; Mon, 3 May 2004 05:27: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 1BKZj5-0004WA-5J for simple@ietf.org; Mon, 03 May 2004 05:27:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKZfy-0003wy-00 for simple@ietf.org; Mon, 03 May 2004 05:23:52 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BKZdB-0003Rp-00 for simple@ietf.org; Mon, 03 May 2004 05:20:57 -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 i439Ktv15053; Mon, 3 May 2004 12:20:55 +0300 (EET DST) X-Scanned: Mon, 3 May 2004 12:20:27 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i439KRcR016519; Mon, 3 May 2004 12:20:27 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00IOIVf6; Mon, 03 May 2004 12:20:25 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i439KPH26119; Mon, 3 May 2004 12:20:25 +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, 3 May 2004 12:20: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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Presence Rules Issue 1: Provide Contact URI defaults Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797A07@esebe019.ntc.nokia.com> Thread-Topic: [Simple] Presence Rules Issue 1: Provide Contact URI defaults Thread-Index: AcQu7Mmq8E/XW/VFQLWjZdhZ2S7DTQCAr54w To: , X-OriginalArrivalTime: 03 May 2004 09:20:21.0378 (UTC) FILETIME=[DBA86620:01C430EF] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 3 May 2004 12:20:21 +0300 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 Content-Transfer-Encoding: quoted-printable I vote for 1. /Hisham > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > ext Jonathan Rosenberg > Sent: 30.April.2004 22:30 > To: Simple WG > Subject: [Simple] Presence Rules Issue 1: Provide Contact URI defaults >=20 >=20 > There is currently a permission called provide-contact-uri that=20 > specifies which tuples the contact-uri should be provided in.=20 > Like many=20 > of the other permissions, you can specify which tuples to=20 > include it in=20 > based on the values of a few other rpid parameters. >=20 > The problem is that, for privacy safety, the default of all of these=20 > sets needs to be the empty set. As a result, the default will be that=20 > you never include a contact URI. If you want one in every=20 > tuple, you'd=20 > have to add this: >=20 > > > >=20 > in every permission statement. Or, you could turn it on "globally" by=20 > specifying a rule that applied to everyone (i.e., all domains you=20 > communicate with), which granted just this specific permission. >=20 > There is also no way to say that the contact URI is to be provided in=20 > "barebones" tuples that have no other RPID information in them. >=20 > My concern is that I think that, in practice, it will be=20 > expected that=20 > contact is nearly always provided, and so you'll have to have this=20 > permission pretty much all the time. The "real" default - in terms of=20 > what a user might expect - is not the same as the default of the=20 > permission itself. >=20 > Our options are: >=20 > 1. who cares, its fine, just add the permission > 2. remove the provide-contact-uri permission, and always include a=20 > contact uri >=20 > My proposal is (1). Thoughts? >=20 > -Jonathan R. > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon May 3 06:39: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 GAA19764 for ; Mon, 3 May 2004 06:39:25 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKar8-0000Wu-GW for simple-archive@ietf.org; Mon, 03 May 2004 06:39:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKanE-0007hQ-00 for simple-archive@ietf.org; Mon, 03 May 2004 06:35:25 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BKajF-00073B-00; Mon, 03 May 2004 06:31:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKaeA-0005jK-GF; Mon, 03 May 2004 06:26:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKaZj-0004IB-G6 for simple@optimus.ietf.org; Mon, 03 May 2004 06:21:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18826 for ; Mon, 3 May 2004 06:21: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 1BKaZf-0005SM-Na for simple@ietf.org; Mon, 03 May 2004 06:21:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKaWL-0004ul-00 for simple@ietf.org; Mon, 03 May 2004 06:17:59 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1BKaTq-0004Pr-00 for simple@ietf.org; Mon, 03 May 2004 06:15:22 -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 i43AF7J10480; Mon, 3 May 2004 13:15:07 +0300 (EET DST) X-Scanned: Mon, 3 May 2004 13:14:54 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i43AEsuc028161; Mon, 3 May 2004 13:14:54 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 007aJaov; Mon, 03 May 2004 13:14:52 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 i43AEkH05997; Mon, 3 May 2004 13:14:46 +0300 (EET DST) Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 3 May 2004 13:14:39 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] WGLC: partial notification Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797A0A@esebe019.ntc.nokia.com> Thread-Topic: [Simple] WGLC: partial notification Thread-Index: AcQw896paM3O6UBVQOqny6z6gyhzRwAAsWjg To: , , Cc: , X-OriginalArrivalTime: 03 May 2004 10:14:39.0066 (UTC) FILETIME=[716423A0:01C430F7] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 3 May 2004 13:14:38 +0300 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 Schmidt Christian [mailto:christian-schmidt@siemens.com] > Sent: 03.May.2004 12:47 > To: Khartabil Hisham (Nokia-TP-MSW/Helsinki); Schmidt Christian; > pkyzivat@cisco.com; rsparks@dynamicsoft.com > Cc: Lonnfors Mikko (Nokia-NRC/Helsinki); simple@ietf.org > Subject: AW: [Simple] WGLC: partial notification >=20 >=20 > Hi Hisham, >=20 > please see my comments in the text, >=20 > best regards > Chrisitan >=20 >=20 >=20 > > Hi Hisham, > >=20 > > this proposal would not solve the problem with a missing=20 > > NOTIFY (full or partial).=20 >=20 > Can you demonstrate why with some flows? >=20 > Christian: > Take for example the following flow > ----> SUBSCRIBE > <---- 200 > <---- NOTIFY1 (full) > ----> 200 > <-X-- NOTIFY2 (full) > <---- NOTIFY3 (partial) >=20 > The Receiver would not know, that NOTIFY2 was lost and take=20 > NOTIFY3 as partial change on basis of NOTIFY1. That could=20 > lead to incorrect information. Same in the following case. > ----> SUBSCRIBE > <---- 200 > <---- NOTIFY1 (full) > ----> 200 > <-X-- NOTIFY2 (partial) > <---- NOTIFY3 (partial) These scenarios are no different than what we have been discussing. = Version solves those problem. We have tracked a little back and started = questioning the need for overlapping NOTIFYs. Why does disallowing = overlapping partial NOTIFYs not solve the problem (which is what you = were suggesting)? >=20 >=20 >=20 > >=20 > > What=B4s about the following proposal: > > The notifier must not issue a NOTIFY (full or partial),=20 > > before it receives a 200 for the last issued NOTIFY (full or=20 > > partial). After experation of a timer t, the notifier should=20 > > send a full NOTIFY. >=20 > If a NOTIFY transaction does not complete, the subscription=20 > is terminated.=20 >=20 > If you are suggesting that timer t is less than 64*T1 (timer=20 > F, that's when the transaction terminates and subsequently=20 > the subscription), then you are suggesting support for=20 > overlapping NOTIFYs. >=20 > Sending a full state NOTIFY after timer t does not help since=20 > if no response arrives for the partial NOTIFY, the=20 > subscription will terminate. >=20 > Christian: > If the notifier get no 200 for his last NOTIFY, either the=20 > NOTIFY or the 200 was lost. Therefor the receiver possibly=20 > can not benefit from a partial notification. If the receiver=20 > gets a new upgrade and reply a 200, the notifier knows, that=20 > the receiver is in sync again. Timer t should be selected=20 > high enough, that overlapping NOTIFYs are nearly excluded. > Is it necessary, that packet loss (timer F) will=20 > automatically lead to a termination of the subscription? This=20 > could lead to additional and perhaps not needed messages (new=20 > subscription). If sender of a NOTIFY (notifier) does not get a 200 for it and Timer F = fires, it terminates the subscription. What is the point of sending a = full NOTIFY if the subscription will termiante anyway? /Hisham >=20 >=20 > /Hisham >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon May 3 06:41:54 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19892 for ; Mon, 3 May 2004 06:41:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKasQ-0003CB-4X for simple-archive@odin.ietf.org; Mon, 03 May 2004 06:40:46 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i43AekK8012281 for simple-archive@odin.ietf.org; Mon, 3 May 2004 06:40:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKarD-0002hU-BR for simple-web-archive@optimus.ietf.org; Mon, 03 May 2004 06:39: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 GAA19782 for ; Mon, 3 May 2004 06:39: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 1BKar9-0000X3-CO for simple-web-archive@ietf.org; Mon, 03 May 2004 06:39:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKanF-0007hd-00 for simple-web-archive@ietf.org; Mon, 03 May 2004 06:35:27 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BKajF-00073B-00; Mon, 03 May 2004 06:31:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKaeA-0005jK-GF; Mon, 03 May 2004 06:26:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKaZj-0004IB-G6 for simple@optimus.ietf.org; Mon, 03 May 2004 06:21:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18826 for ; Mon, 3 May 2004 06:21: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 1BKaZf-0005SM-Na for simple@ietf.org; Mon, 03 May 2004 06:21:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKaWL-0004ul-00 for simple@ietf.org; Mon, 03 May 2004 06:17:59 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1BKaTq-0004Pr-00 for simple@ietf.org; Mon, 03 May 2004 06:15:22 -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 i43AF7J10480; Mon, 3 May 2004 13:15:07 +0300 (EET DST) X-Scanned: Mon, 3 May 2004 13:14:54 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i43AEsuc028161; Mon, 3 May 2004 13:14:54 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 007aJaov; Mon, 03 May 2004 13:14:52 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 i43AEkH05997; Mon, 3 May 2004 13:14:46 +0300 (EET DST) Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 3 May 2004 13:14:39 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] WGLC: partial notification Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797A0A@esebe019.ntc.nokia.com> Thread-Topic: [Simple] WGLC: partial notification Thread-Index: AcQw896paM3O6UBVQOqny6z6gyhzRwAAsWjg To: , , Cc: , X-OriginalArrivalTime: 03 May 2004 10:14:39.0066 (UTC) FILETIME=[716423A0:01C430F7] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 3 May 2004 13:14:38 +0300 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 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Schmidt Christian [mailto:christian-schmidt@siemens.com] > Sent: 03.May.2004 12:47 > To: Khartabil Hisham (Nokia-TP-MSW/Helsinki); Schmidt Christian; > pkyzivat@cisco.com; rsparks@dynamicsoft.com > Cc: Lonnfors Mikko (Nokia-NRC/Helsinki); simple@ietf.org > Subject: AW: [Simple] WGLC: partial notification >=20 >=20 > Hi Hisham, >=20 > please see my comments in the text, >=20 > best regards > Chrisitan >=20 >=20 >=20 > > Hi Hisham, > >=20 > > this proposal would not solve the problem with a missing=20 > > NOTIFY (full or partial).=20 >=20 > Can you demonstrate why with some flows? >=20 > Christian: > Take for example the following flow > ----> SUBSCRIBE > <---- 200 > <---- NOTIFY1 (full) > ----> 200 > <-X-- NOTIFY2 (full) > <---- NOTIFY3 (partial) >=20 > The Receiver would not know, that NOTIFY2 was lost and take=20 > NOTIFY3 as partial change on basis of NOTIFY1. That could=20 > lead to incorrect information. Same in the following case. > ----> SUBSCRIBE > <---- 200 > <---- NOTIFY1 (full) > ----> 200 > <-X-- NOTIFY2 (partial) > <---- NOTIFY3 (partial) These scenarios are no different than what we have been discussing. = Version solves those problem. We have tracked a little back and started = questioning the need for overlapping NOTIFYs. Why does disallowing = overlapping partial NOTIFYs not solve the problem (which is what you = were suggesting)? >=20 >=20 >=20 > >=20 > > What=B4s about the following proposal: > > The notifier must not issue a NOTIFY (full or partial),=20 > > before it receives a 200 for the last issued NOTIFY (full or=20 > > partial). After experation of a timer t, the notifier should=20 > > send a full NOTIFY. >=20 > If a NOTIFY transaction does not complete, the subscription=20 > is terminated.=20 >=20 > If you are suggesting that timer t is less than 64*T1 (timer=20 > F, that's when the transaction terminates and subsequently=20 > the subscription), then you are suggesting support for=20 > overlapping NOTIFYs. >=20 > Sending a full state NOTIFY after timer t does not help since=20 > if no response arrives for the partial NOTIFY, the=20 > subscription will terminate. >=20 > Christian: > If the notifier get no 200 for his last NOTIFY, either the=20 > NOTIFY or the 200 was lost. Therefor the receiver possibly=20 > can not benefit from a partial notification. If the receiver=20 > gets a new upgrade and reply a 200, the notifier knows, that=20 > the receiver is in sync again. Timer t should be selected=20 > high enough, that overlapping NOTIFYs are nearly excluded. > Is it necessary, that packet loss (timer F) will=20 > automatically lead to a termination of the subscription? This=20 > could lead to additional and perhaps not needed messages (new=20 > subscription). If sender of a NOTIFY (notifier) does not get a 200 for it and Timer F = fires, it terminates the subscription. What is the point of sending a = full NOTIFY if the subscription will termiante anyway? /Hisham >=20 >=20 > /Hisham >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon May 3 06:55:58 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20539 for ; Mon, 3 May 2004 06:55:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKb6H-0008BL-P2 for simple-archive@odin.ietf.org; Mon, 03 May 2004 06:55:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i43At5o9031446 for simple-archive@odin.ietf.org; Mon, 3 May 2004 06:55:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKb4v-0007gh-3u for simple-web-archive@optimus.ietf.org; Mon, 03 May 2004 06:53: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 GAA18007 for ; Mon, 3 May 2004 06:00:31 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKaFU-00022l-5Q for simple-web-archive@ietf.org; Mon, 03 May 2004 06:00:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKaBS-0001Qh-00 for simple-web-archive@ietf.org; Mon, 03 May 2004 05:56:24 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BKa6n-0000dG-00; Mon, 03 May 2004 05:51:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKa0e-00075S-91; Mon, 03 May 2004 05:45:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKZua-0005CB-L8 for simple@optimus.ietf.org; Mon, 03 May 2004 05:38: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 FAA17254 for ; Mon, 3 May 2004 05:38:52 -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 1BKZuX-0006Rx-4p for simple@ietf.org; Mon, 03 May 2004 05:38:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKZr7-0005wu-00 for simple@ietf.org; Mon, 03 May 2004 05:35:22 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BKZnv-0005KD-00 for simple@ietf.org; Mon, 03 May 2004 05:32:04 -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 i439W2v28609; Mon, 3 May 2004 12:32:02 +0300 (EET DST) X-Scanned: Mon, 3 May 2004 12:30:51 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i439UpcK021892; Mon, 3 May 2004 12:30:51 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 008qNsaB; Mon, 03 May 2004 12:30:50 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 i439UiH14139; Mon, 3 May 2004 12:30:44 +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); Mon, 3 May 2004 12:30:44 +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 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF01C1DEC8@esebe004.ntc.nokia.com> Thread-Topic: Comments on draft-ietf-simple-partial-notify-02 Thread-Index: AcQtPtY6iL6H1WczSoeK6QeEpHYrwAADYouA To: , Cc: , X-OriginalArrivalTime: 03 May 2004 09:30:44.0815 (UTC) FILETIME=[4F4155F0:01C430F1] Content-Transfer-Encoding: quoted-printable Subject: [Simple] RE: Comments on draft-ietf-simple-partial-notify-02 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 3 May 2004 12:30:44 +0300 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 Content-Transfer-Encoding: quoted-printable >=20 > I have a couple of non-fundamental observations on the partial notify=20 > draft. >=20 > Obs 1: Overall style challenge: Overuse of requirements language in=20 > descriptive passages. >=20 > People tend to use RFC 2119 requirements language when describing how=20 > things work, rather than when describing actual requirements. >=20 > This is subtle, and many (most?) people don't understand the=20 > difference. You can probably get away with ignoring me here, but it=20 > might be worth > thinking about. It has big implications on the establishment=20 > of formal=20 > compatibility documents -- when people say "MUST" everytime they mean=20 > "does", it makes the real requirements hard to identify. >=20 > As an example, the text in this draft: >=20 > 4.4 Presence agent generation of partial notifications >=20 > If the presence agent decides to send notifications according to=20 > this > specification that include a presence document, the presence agent > MUST build a presence document according to the PIDF extension for > Partial Presence [2] and MUST set the Content-Type header field to > the value 'application/pidf-partial+xml'. >=20 > Tuple ids are used to match tuples across subsequent notifications. > Presence agent MUST use the same tuple ids for tuples which are > identical between subsequent notifications and MUST allocate > different tuple ids for tuples which are different from previously > sent tuples. Presence agents MUST keep tuple ids consistent until=20 > the > next full state presence documentis delivered. The decision on > whether tuple ids are the same or different is left up to > PA's local > policy. >=20 >=20 > Would perhaps be more clearly written as: >=20 > 4.4 Presence agent generation of partial notifications >=20 > If the presence agent decides to send partial notifications in=20 > response > to this subscription, it constructs the partial presence documents > as specified in the PIDF extension for Partial Presence > [2]. As required=20 > by [2], the presence agent sets the Content-Type header=20 > field of each=20 > partial presence document to the value=20 > 'application/pidf-partial+xml'. >=20 > Further requirements apply to partial presence documents, as=20 > follow: >=20 > Tuple ids are used by clients to match tuples across subsequent=20 > notifications. For this matching to succeed, the Presence Agent=20 > MUST > not vary the tuple ids for tuples that have not changed since they > were previously sent on this subscription and and MUST > allocate different=20 > tuple ids for tuples that are different from previously=20 > sent tuples.=20 > Presence agents MUST keep tuple ids consistent until the=20 > next full-state=20 > presence document has been sent and acknowledged. The=20 > decision on whether=20 > tuple ids are the same or different in the next full-state=20 > presence document > is left up to PA's local policy. >=20 >=20 > In the first paragraph, we are describing how the presence agent does=20 > something by way of example. In the second and third, we are stating=20 > requirements that vary from the general way of building presence=20 > documents, i.e, "new requirements". I've also polished the English=20 > slightly. Right, I think I understand your concern. I will try to polish use of RFC2119 requirements language in the next version. > Obs 2: Section 5: > ... The PA accepts the subscription and, based on the "q" parameter=20 > value, selects to send ... >=20 > The phrase "selects to send" is a bit awkward as English construction. > "Selects" has the connotation of choosing from a menu, which is not=20 > quite what we want here. > "Decides to send" might work better. Whatever you choose should align=20 > with the wording you've decided to use in the (elsewhere discussed)=20 > discussion of how the server decided whether or not it was going to=20 > provide partial notifications for this subscription. Right, I will change that and try to align it with the rest of the text. >=20 > Obs 3: Use of domain names in examples: >=20 > Some examples use domain names in "somewhere.com". This probably needs > to be changed to a domain reserved in RFC 2606. Perhaps ".test"? >=20 > After all, "somewhere.com" is a real domain:=20 > Somewhere.Com, LLC > 25 Forest Circle > Winchester, MA 01890 > US Yes, this will be changed to example.com. Thanks - Mikko >=20 > -- > Dean >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon May 3 06:57: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 GAA20561 for ; Mon, 3 May 2004 06:57: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 1BKb92-0003R8-Dt for simple-archive@ietf.org; Mon, 03 May 2004 06:57:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKb5a-0002nO-00 for simple-archive@ietf.org; Mon, 03 May 2004 06:54:24 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BKb1o-00021w-00; Mon, 03 May 2004 06:50:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKatd-0003aN-BP; Mon, 03 May 2004 06:42:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKas0-0002ox-Da for simple@optimus.ietf.org; Mon, 03 May 2004 06:40:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17795 for ; Mon, 3 May 2004 05: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 1BKa8s-00012z-TB for simple@ietf.org; Mon, 03 May 2004 05:53:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKa5O-0000Tx-00 for simple@ietf.org; Mon, 03 May 2004 05:50:07 -0400 Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx with esmtp (Exim 4.12) id 1BKa2m-000006-00 for simple@ietf.org; Mon, 03 May 2004 05:47:24 -0400 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by goliath.siemens.de (8.11.7/8.11.7) with ESMTP id i439lEM29734; Mon, 3 May 2004 11:47:14 +0200 (MEST) 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 i439lDl27553; Mon, 3 May 2004 11:47:13 +0200 (MEST) Received: from mchh274e.mchh.siemens.de (mchh274e.mchh.siemens.de [139.21.200.84]) by moody.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id LAA29017; Mon, 3 May 2004 11:47:12 +0200 (MET DST) Received: by mchh274e.mchh.siemens.de with Internet Mail Service (5.5.2657.72) id ; Mon, 3 May 2004 11:47:11 +0200 Message-ID: From: Schmidt Christian To: "'hisham.khartabil@nokia.com'" , Schmidt Christian , pkyzivat@cisco.com, rsparks@dynamicsoft.com Cc: mikko.lonnfors@nokia.com, simple@ietf.org Subject: AW: [Simple] WGLC: partial notification 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 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 3 May 2004 11:47:03 +0200 X-Spam-Checker-Version: SpamAssassin 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 Hisham, please see my comments in the text, best regards Chrisitan > Hi Hisham, >=20 > this proposal would not solve the problem with a missing=20 > NOTIFY (full or partial).=20 Can you demonstrate why with some flows? Christian: Take for example the following flow ----> SUBSCRIBE <---- 200 <---- NOTIFY1 (full) ----> 200 <-X-- NOTIFY2 (full) <---- NOTIFY3 (partial) The Receiver would not know, that NOTIFY2 was lost and take NOTIFY3 as = partial change on basis of NOTIFY1. That could lead to incorrect = information. Same in the following case. ----> SUBSCRIBE <---- 200 <---- NOTIFY1 (full) ----> 200 <-X-- NOTIFY2 (partial) <---- NOTIFY3 (partial) >=20 > What=B4s about the following proposal: > The notifier must not issue a NOTIFY (full or partial),=20 > before it receives a 200 for the last issued NOTIFY (full or=20 > partial). After experation of a timer t, the notifier should=20 > send a full NOTIFY. If a NOTIFY transaction does not complete, the subscription is = terminated.=20 If you are suggesting that timer t is less than 64*T1 (timer F, that's = when the transaction terminates and subsequently the subscription), = then you are suggesting support for overlapping NOTIFYs. Sending a full state NOTIFY after timer t does not help since if no = response arrives for the partial NOTIFY, the subscription will = terminate. Christian: If the notifier get no 200 for his last NOTIFY, either the NOTIFY or = the 200 was lost. Therefor the receiver possibly can not benefit from a = partial notification. If the receiver gets a new upgrade and reply a = 200, the notifier knows, that the receiver is in sync again. Timer t = should be selected high enough, that overlapping NOTIFYs are nearly = excluded. Is it necessary, that packet loss (timer F) will automatically lead to = a termination of the subscription? This could lead to additional and = perhaps not needed messages (new subscription). /Hisham _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon May 3 07:14: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 HAA21228 for ; Mon, 3 May 2004 07:14: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 1BKbPH-0006FZ-Bi for simple-archive@ietf.org; Mon, 03 May 2004 07:14:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKbMP-0005kL-00 for simple-archive@ietf.org; Mon, 03 May 2004 07:11:47 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BKbK1-0005Ho-00; Mon, 03 May 2004 07:09:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKbFw-000374-Lr; Mon, 03 May 2004 07:05:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKbDN-0001s2-6R for simple@optimus.ietf.org; Mon, 03 May 2004 07:02: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 HAA20901 for ; Mon, 3 May 2004 07:02:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKbDI-00048B-VM for simple@ietf.org; Mon, 03 May 2004 07:02:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKbAG-0003cp-00 for simple@ietf.org; Mon, 03 May 2004 06:59:14 -0400 Received: from thoth.sbs.de ([192.35.17.2]) by ietf-mx with esmtp (Exim 4.12) id 1BKb78-00033N-00 for simple@ietf.org; Mon, 03 May 2004 06:55:58 -0400 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by thoth.sbs.de (8.11.7/8.11.7) with ESMTP id i43AtpS21258; Mon, 3 May 2004 12:55:51 +0200 (MEST) Received: from blues.mchh.siemens.de (blues.mchh.siemens.de [139.21.204.206]) by mail2.siemens.de (8.11.7/8.11.7) with ESMTP id i43AtnM26160; Mon, 3 May 2004 12:55:49 +0200 (MEST) Received: from mchh275e.mchh.siemens.de (mchh275e.mchh.siemens.de [139.21.200.61]) by blues.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id MAA15962; Mon, 3 May 2004 12:55:10 +0200 (MET DST) Received: by mchh275e.mchh.siemens.de with Internet Mail Service (5.5.2657.72) id ; Mon, 3 May 2004 12:55:44 +0200 Message-ID: From: Schmidt Christian To: "'hisham.khartabil@nokia.com'" , pkyzivat@cisco.com, rsparks@dynamicsoft.com Cc: mikko.lonnfors@nokia.com, simple@ietf.org Subject: AW: [Simple] WGLC: partial notification 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 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 3 May 2004 12:55:44 +0200 X-Spam-Checker-Version: SpamAssassin 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 Hisham, >=20 > please see my comments in the text, >=20 > best regards > Chrisitan >=20 >=20 >=20 > > Hi Hisham, > >=20 > > this proposal would not solve the problem with a missing=20 > > NOTIFY (full or partial).=20 >=20 > Can you demonstrate why with some flows? >=20 > Christian: > Take for example the following flow > ----> SUBSCRIBE > <---- 200 > <---- NOTIFY1 (full) > ----> 200 > <-X-- NOTIFY2 (full) > <---- NOTIFY3 (partial) >=20 > The Receiver would not know, that NOTIFY2 was lost and take=20 > NOTIFY3 as partial change on basis of NOTIFY1. That could=20 > lead to incorrect information. Same in the following case. > ----> SUBSCRIBE > <---- 200 > <---- NOTIFY1 (full) > ----> 200 > <-X-- NOTIFY2 (partial) > <---- NOTIFY3 (partial) These scenarios are no different than what we have been discussing. = Version solves those problem. We have tracked a little back and started = questioning the need for overlapping NOTIFYs. Why does disallowing = overlapping partial NOTIFYs not solve the problem (which is what you = were suggesting)? Christian: Disallowing overlapping partial NOTIFYs combined with versioning solve = the problem. Disallowing overlapping partial NOTIFYs without versioning would not = solve the problem. The version attribute, you need anyway to avoid mistakes in case of = reordered full NOTIFYs. >=20 >=20 >=20 > >=20 > > What=B4s about the following proposal: > > The notifier must not issue a NOTIFY (full or partial),=20 > > before it receives a 200 for the last issued NOTIFY (full or=20 > > partial). After experation of a timer t, the notifier should=20 > > send a full NOTIFY. >=20 > If a NOTIFY transaction does not complete, the subscription=20 > is terminated.=20 >=20 > If you are suggesting that timer t is less than 64*T1 (timer=20 > F, that's when the transaction terminates and subsequently=20 > the subscription), then you are suggesting support for=20 > overlapping NOTIFYs. >=20 > Sending a full state NOTIFY after timer t does not help since=20 > if no response arrives for the partial NOTIFY, the=20 > subscription will terminate. >=20 > Christian: > If the notifier get no 200 for his last NOTIFY, either the=20 > NOTIFY or the 200 was lost. Therefor the receiver possibly=20 > can not benefit from a partial notification. If the receiver=20 > gets a new upgrade and reply a 200, the notifier knows, that=20 > the receiver is in sync again. Timer t should be selected=20 > high enough, that overlapping NOTIFYs are nearly excluded. > Is it necessary, that packet loss (timer F) will=20 > automatically lead to a termination of the subscription? This=20 > could lead to additional and perhaps not needed messages (new=20 > subscription). If sender of a NOTIFY (notifier) does not get a 200 for it and Timer F = fires, it terminates the subscription. What is the point of sending a = full NOTIFY if the subscription will termiante anyway? Christian: Is it possible, to avoid this unnecessary termination of the = subscription (caused by the loss of a single packet) by an additional = NOTIFY? This would increase efficiency. /Hisham >=20 >=20 > /Hisham >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon May 3 07:19:09 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21328 for ; Mon, 3 May 2004 07:19:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKbQ4-00070e-4J for simple-archive@odin.ietf.org; Mon, 03 May 2004 07:15:32 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i43BFWRn026930 for simple-archive@odin.ietf.org; Mon, 3 May 2004 07:15:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKbPI-0006SK-MP for simple-web-archive@optimus.ietf.org; Mon, 03 May 2004 07:14: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 HAA21246 for ; Mon, 3 May 2004 07:14: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 1BKbPI-0006Fh-62 for simple-web-archive@ietf.org; Mon, 03 May 2004 07:14:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKbMR-0005kZ-00 for simple-web-archive@ietf.org; Mon, 03 May 2004 07:11:49 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BKbK1-0005Ho-00; Mon, 03 May 2004 07:09:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKbFw-000374-Lr; Mon, 03 May 2004 07:05:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKbDN-0001s2-6R for simple@optimus.ietf.org; Mon, 03 May 2004 07:02: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 HAA20901 for ; Mon, 3 May 2004 07:02:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKbDI-00048B-VM for simple@ietf.org; Mon, 03 May 2004 07:02:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKbAG-0003cp-00 for simple@ietf.org; Mon, 03 May 2004 06:59:14 -0400 Received: from thoth.sbs.de ([192.35.17.2]) by ietf-mx with esmtp (Exim 4.12) id 1BKb78-00033N-00 for simple@ietf.org; Mon, 03 May 2004 06:55:58 -0400 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by thoth.sbs.de (8.11.7/8.11.7) with ESMTP id i43AtpS21258; Mon, 3 May 2004 12:55:51 +0200 (MEST) Received: from blues.mchh.siemens.de (blues.mchh.siemens.de [139.21.204.206]) by mail2.siemens.de (8.11.7/8.11.7) with ESMTP id i43AtnM26160; Mon, 3 May 2004 12:55:49 +0200 (MEST) Received: from mchh275e.mchh.siemens.de (mchh275e.mchh.siemens.de [139.21.200.61]) by blues.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id MAA15962; Mon, 3 May 2004 12:55:10 +0200 (MET DST) Received: by mchh275e.mchh.siemens.de with Internet Mail Service (5.5.2657.72) id ; Mon, 3 May 2004 12:55:44 +0200 Message-ID: From: Schmidt Christian To: "'hisham.khartabil@nokia.com'" , pkyzivat@cisco.com, rsparks@dynamicsoft.com Cc: mikko.lonnfors@nokia.com, simple@ietf.org Subject: AW: [Simple] WGLC: partial notification 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 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 3 May 2004 12:55:44 +0200 X-Spam-Checker-Version: SpamAssassin 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 Content-Transfer-Encoding: quoted-printable > Hi Hisham, >=20 > please see my comments in the text, >=20 > best regards > Chrisitan >=20 >=20 >=20 > > Hi Hisham, > >=20 > > this proposal would not solve the problem with a missing=20 > > NOTIFY (full or partial).=20 >=20 > Can you demonstrate why with some flows? >=20 > Christian: > Take for example the following flow > ----> SUBSCRIBE > <---- 200 > <---- NOTIFY1 (full) > ----> 200 > <-X-- NOTIFY2 (full) > <---- NOTIFY3 (partial) >=20 > The Receiver would not know, that NOTIFY2 was lost and take=20 > NOTIFY3 as partial change on basis of NOTIFY1. That could=20 > lead to incorrect information. Same in the following case. > ----> SUBSCRIBE > <---- 200 > <---- NOTIFY1 (full) > ----> 200 > <-X-- NOTIFY2 (partial) > <---- NOTIFY3 (partial) These scenarios are no different than what we have been discussing. = Version solves those problem. We have tracked a little back and started = questioning the need for overlapping NOTIFYs. Why does disallowing = overlapping partial NOTIFYs not solve the problem (which is what you = were suggesting)? Christian: Disallowing overlapping partial NOTIFYs combined with versioning solve = the problem. Disallowing overlapping partial NOTIFYs without versioning would not = solve the problem. The version attribute, you need anyway to avoid mistakes in case of = reordered full NOTIFYs. >=20 >=20 >=20 > >=20 > > What=B4s about the following proposal: > > The notifier must not issue a NOTIFY (full or partial),=20 > > before it receives a 200 for the last issued NOTIFY (full or=20 > > partial). After experation of a timer t, the notifier should=20 > > send a full NOTIFY. >=20 > If a NOTIFY transaction does not complete, the subscription=20 > is terminated.=20 >=20 > If you are suggesting that timer t is less than 64*T1 (timer=20 > F, that's when the transaction terminates and subsequently=20 > the subscription), then you are suggesting support for=20 > overlapping NOTIFYs. >=20 > Sending a full state NOTIFY after timer t does not help since=20 > if no response arrives for the partial NOTIFY, the=20 > subscription will terminate. >=20 > Christian: > If the notifier get no 200 for his last NOTIFY, either the=20 > NOTIFY or the 200 was lost. Therefor the receiver possibly=20 > can not benefit from a partial notification. If the receiver=20 > gets a new upgrade and reply a 200, the notifier knows, that=20 > the receiver is in sync again. Timer t should be selected=20 > high enough, that overlapping NOTIFYs are nearly excluded. > Is it necessary, that packet loss (timer F) will=20 > automatically lead to a termination of the subscription? This=20 > could lead to additional and perhaps not needed messages (new=20 > subscription). If sender of a NOTIFY (notifier) does not get a 200 for it and Timer F = fires, it terminates the subscription. What is the point of sending a = full NOTIFY if the subscription will termiante anyway? Christian: Is it possible, to avoid this unnecessary termination of the = subscription (caused by the loss of a single packet) by an additional = NOTIFY? This would increase efficiency. /Hisham >=20 >=20 > /Hisham >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon May 3 07:56:06 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22510 for ; Mon, 3 May 2004 07:56:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKbvW-0001GT-GJ for simple-archive@odin.ietf.org; Mon, 03 May 2004 07:48:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i43Bm27X004857 for simple-archive@odin.ietf.org; Mon, 3 May 2004 07:48:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKbrL-00080V-Be for simple-web-archive@optimus.ietf.org; Mon, 03 May 2004 07:43: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 GAA20579 for ; Mon, 3 May 2004 06:57:56 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKb93-0003RE-5D for simple-web-archive@ietf.org; Mon, 03 May 2004 06:57:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKb5c-0002ne-00 for simple-web-archive@ietf.org; Mon, 03 May 2004 06:54:25 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BKb1o-00021w-00; Mon, 03 May 2004 06:50:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKatd-0003aN-BP; Mon, 03 May 2004 06:42:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKas0-0002ox-Da for simple@optimus.ietf.org; Mon, 03 May 2004 06:40:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17795 for ; Mon, 3 May 2004 05: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 1BKa8s-00012z-TB for simple@ietf.org; Mon, 03 May 2004 05:53:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKa5O-0000Tx-00 for simple@ietf.org; Mon, 03 May 2004 05:50:07 -0400 Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx with esmtp (Exim 4.12) id 1BKa2m-000006-00 for simple@ietf.org; Mon, 03 May 2004 05:47:24 -0400 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by goliath.siemens.de (8.11.7/8.11.7) with ESMTP id i439lEM29734; Mon, 3 May 2004 11:47:14 +0200 (MEST) 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 i439lDl27553; Mon, 3 May 2004 11:47:13 +0200 (MEST) Received: from mchh274e.mchh.siemens.de (mchh274e.mchh.siemens.de [139.21.200.84]) by moody.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id LAA29017; Mon, 3 May 2004 11:47:12 +0200 (MET DST) Received: by mchh274e.mchh.siemens.de with Internet Mail Service (5.5.2657.72) id ; Mon, 3 May 2004 11:47:11 +0200 Message-ID: From: Schmidt Christian To: "'hisham.khartabil@nokia.com'" , Schmidt Christian , pkyzivat@cisco.com, rsparks@dynamicsoft.com Cc: mikko.lonnfors@nokia.com, simple@ietf.org Subject: AW: [Simple] WGLC: partial notification 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 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 3 May 2004 11:47:03 +0200 X-Spam-Checker-Version: SpamAssassin 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 Content-Transfer-Encoding: quoted-printable Hi Hisham, please see my comments in the text, best regards Chrisitan > Hi Hisham, >=20 > this proposal would not solve the problem with a missing=20 > NOTIFY (full or partial).=20 Can you demonstrate why with some flows? Christian: Take for example the following flow ----> SUBSCRIBE <---- 200 <---- NOTIFY1 (full) ----> 200 <-X-- NOTIFY2 (full) <---- NOTIFY3 (partial) The Receiver would not know, that NOTIFY2 was lost and take NOTIFY3 as = partial change on basis of NOTIFY1. That could lead to incorrect = information. Same in the following case. ----> SUBSCRIBE <---- 200 <---- NOTIFY1 (full) ----> 200 <-X-- NOTIFY2 (partial) <---- NOTIFY3 (partial) >=20 > What=B4s about the following proposal: > The notifier must not issue a NOTIFY (full or partial),=20 > before it receives a 200 for the last issued NOTIFY (full or=20 > partial). After experation of a timer t, the notifier should=20 > send a full NOTIFY. If a NOTIFY transaction does not complete, the subscription is = terminated.=20 If you are suggesting that timer t is less than 64*T1 (timer F, that's = when the transaction terminates and subsequently the subscription), = then you are suggesting support for overlapping NOTIFYs. Sending a full state NOTIFY after timer t does not help since if no = response arrives for the partial NOTIFY, the subscription will = terminate. Christian: If the notifier get no 200 for his last NOTIFY, either the NOTIFY or = the 200 was lost. Therefor the receiver possibly can not benefit from a = partial notification. If the receiver gets a new upgrade and reply a = 200, the notifier knows, that the receiver is in sync again. Timer t = should be selected high enough, that overlapping NOTIFYs are nearly = excluded. Is it necessary, that packet loss (timer F) will automatically lead to = a termination of the subscription? This could lead to additional and = perhaps not needed messages (new subscription). /Hisham _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon May 3 07:59: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 HAA22673 for ; Mon, 3 May 2004 07:59:52 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKc6z-0006O8-GL for simple-archive@ietf.org; Mon, 03 May 2004 07:59:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKc3p-0005o3-00 for simple-archive@ietf.org; Mon, 03 May 2004 07:56:38 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BKc0y-0005HN-00; Mon, 03 May 2004 07:53:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKbvV-0001Fg-5s; Mon, 03 May 2004 07:48:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKbrG-00080V-0B for simple@optimus.ietf.org; Mon, 03 May 2004 07:43: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 GAA20612 for ; Mon, 3 May 2004 06:58:15 -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 1BKb9M-0003VB-Hz for simple@ietf.org; Mon, 03 May 2004 06:58:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKb65-0002sO-00 for simple@ietf.org; Mon, 03 May 2004 06:54:54 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1BKb33-0002IL-00 for simple@ietf.org; Mon, 03 May 2004 06:51:45 -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 i43ApbJ23969; Mon, 3 May 2004 13:51:37 +0300 (EET DST) X-Scanned: Mon, 3 May 2004 13:51:27 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i43ApRoi006295; Mon, 3 May 2004 13:51:27 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00UJgY2O; Mon, 03 May 2004 13:51:25 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i43AeEH26446; Mon, 3 May 2004 13:40:15 +0300 (EET DST) Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 3 May 2004 13:40:14 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] WGLC: partial notification Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF01D17312@esebe004.ntc.nokia.com> Thread-Topic: [Simple] WGLC: partial notification Thread-Index: AcQuGno+S8hkiNZPTmuNIx+A90HBigAYOHCgAJ955eA= To: , , Cc: X-OriginalArrivalTime: 03 May 2004 10:40:14.0291 (UTC) FILETIME=[0474E230:01C430FB] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 3 May 2004 13:40:14 +0300 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, Related to this issue it occurred to me that winfo (draft-ietf-simple-winfo-package-05) may also suffer from this. As far as I can tell "version" and "state" handling is quite similar (in winfo version is scoped to the subscription) in both cases (winfo and partial notify) and winfo also doesn't prohibit sending new NOTIFYs if there exists a pending NOTIFY. =20 Thoughts? - Mikko > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org] On=20 > Behalf Of ext hisham.khartabil@nokia.com > Sent: Friday, April 30, 2004 9:27 AM > To: pkyzivat@cisco.com; rsparks@dynamicsoft.com > Cc: Lonnfors Mikko (Nokia-NRC/Helsinki); simple@ietf.org > Subject: RE: [Simple] WGLC: partial notification >=20 >=20 > Ok, I also agree that overlapping partial NOTIFYs complicate=20 > things without benefit. I also would like to propose=20 > explicitly disallowing overlapping full state and partial.=20 > I.e. A notifier must not issue a partial state NOTIFY without=20 > first receiving the 200 for a full state NOTIFY. I believe=20 > the converse is also required: the notifier must not issue a=20 > full state NOTIFY before it receives a 200 for a partial state NOTIFY. >=20 > With all there restrictions, we can do without the version attribute. >=20 > Regards, > Hisham >=20 > > -----Original Message----- > > From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] > > Sent: 29.April.2004 21:47 > > To: Robert Sparks > > Cc: Khartabil Hisham (Nokia-TP-MSW/Helsinki); Lonnfors Mikko=20 > > (Nokia-NRC/Helsinki); simple@ietf.org > > Subject: Re: [Simple] WGLC: partial notification > >=20 > >=20 > >=20 > >=20 > > Robert Sparks wrote: > > > Aside from that I'd like for you to think through this again from=20 > > > viewpoints besides active attack (use a transient=20 > malfunction of the=20 > > > application (above the layer that would screw up basic SIP)), I'm=20 > > > ready to let this go as long as we have _a_ solid solution to=20 > > > dealing with reordered/missing notifies. > >=20 > > I'm not going to start down the path to speculation about how > > to recover=20 > > from arbitrary malfunctions of an application. That is just plain=20 > > impossible without some characterization of the kinds of=20 > malfunctions=20 > > that are to be recovered from. > >=20 > > > So, backing out a layer, lets look at my original question of=20 > > > whether or not we allow overlapping ->partial<- NOTIFYs at all in=20 > > > this case. > >=20 > > I don't see any compelling need to support overlapping > > partial notifies.=20 > > It is very difficult to see how to make them work. > >=20 > > I can imagine a case where there might be some motivation:=20 > I sent one > > notification and have had no response. But I already have a=20 > bunch of=20 > > additional changes that you should know about. It might be=20 > > advantageous=20 > > to start sending them as soon as possible. But until you know=20 > > the prior=20 > > one has been handled it isn't safe to send the new one. > >=20 > > > Why would you want to? What value would doing that bring? > > >=20 > > > 3261 and even presence-10 left sending full-state=20 > presence NOTIFYs=20 > > > open. We wouldn't be changing that. If an application for some=20 > > > reason decided it needed to send a new full-state notify while a=20 > > > partial-state notify was pending, it could. So any of the=20 > arguments=20 > > > for allowing it from the 3261/presence-10 are still=20 > satisfied. Can=20 > > > you see any use case where allowing a server to send overlapping=20 > > > partial NOTIFYs is a good idea? If not, disallowing it seems a=20 > > > powerful simplification. > > > > >=20 > > I agree. > >=20 > > Paul > >=20 > >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon May 3 08:34:26 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24784 for ; Mon, 3 May 2004 08:34:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKcQd-0006m8-AM for simple-archive@odin.ietf.org; Mon, 03 May 2004 08:20:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i43CKBTi026044 for simple-archive@odin.ietf.org; Mon, 3 May 2004 08:20:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKc71-0005TO-5P for simple-web-archive@optimus.ietf.org; Mon, 03 May 2004 07:59: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 HAA22691 for ; Mon, 3 May 2004 07:59: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 1BKc70-0006OE-9u for simple-web-archive@ietf.org; Mon, 03 May 2004 07:59:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKc3q-0005oH-00 for simple-web-archive@ietf.org; Mon, 03 May 2004 07:56:40 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BKc0y-0005HN-00; Mon, 03 May 2004 07:53:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKbvV-0001Fg-5s; Mon, 03 May 2004 07:48:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKbrG-00080V-0B for simple@optimus.ietf.org; Mon, 03 May 2004 07:43: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 GAA20612 for ; Mon, 3 May 2004 06:58:15 -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 1BKb9M-0003VB-Hz for simple@ietf.org; Mon, 03 May 2004 06:58:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKb65-0002sO-00 for simple@ietf.org; Mon, 03 May 2004 06:54:54 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1BKb33-0002IL-00 for simple@ietf.org; Mon, 03 May 2004 06:51:45 -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 i43ApbJ23969; Mon, 3 May 2004 13:51:37 +0300 (EET DST) X-Scanned: Mon, 3 May 2004 13:51:27 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i43ApRoi006295; Mon, 3 May 2004 13:51:27 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00UJgY2O; Mon, 03 May 2004 13:51:25 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i43AeEH26446; Mon, 3 May 2004 13:40:15 +0300 (EET DST) Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 3 May 2004 13:40:14 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] WGLC: partial notification Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF01D17312@esebe004.ntc.nokia.com> Thread-Topic: [Simple] WGLC: partial notification Thread-Index: AcQuGno+S8hkiNZPTmuNIx+A90HBigAYOHCgAJ955eA= To: , , Cc: X-OriginalArrivalTime: 03 May 2004 10:40:14.0291 (UTC) FILETIME=[0474E230:01C430FB] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 3 May 2004 13:40:14 +0300 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 Content-Transfer-Encoding: quoted-printable Hi, Related to this issue it occurred to me that winfo (draft-ietf-simple-winfo-package-05) may also suffer from this. As far as I can tell "version" and "state" handling is quite similar (in winfo version is scoped to the subscription) in both cases (winfo and partial notify) and winfo also doesn't prohibit sending new NOTIFYs if there exists a pending NOTIFY. =20 Thoughts? - Mikko > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org] On=20 > Behalf Of ext hisham.khartabil@nokia.com > Sent: Friday, April 30, 2004 9:27 AM > To: pkyzivat@cisco.com; rsparks@dynamicsoft.com > Cc: Lonnfors Mikko (Nokia-NRC/Helsinki); simple@ietf.org > Subject: RE: [Simple] WGLC: partial notification >=20 >=20 > Ok, I also agree that overlapping partial NOTIFYs complicate=20 > things without benefit. I also would like to propose=20 > explicitly disallowing overlapping full state and partial.=20 > I.e. A notifier must not issue a partial state NOTIFY without=20 > first receiving the 200 for a full state NOTIFY. I believe=20 > the converse is also required: the notifier must not issue a=20 > full state NOTIFY before it receives a 200 for a partial state NOTIFY. >=20 > With all there restrictions, we can do without the version attribute. >=20 > Regards, > Hisham >=20 > > -----Original Message----- > > From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] > > Sent: 29.April.2004 21:47 > > To: Robert Sparks > > Cc: Khartabil Hisham (Nokia-TP-MSW/Helsinki); Lonnfors Mikko=20 > > (Nokia-NRC/Helsinki); simple@ietf.org > > Subject: Re: [Simple] WGLC: partial notification > >=20 > >=20 > >=20 > >=20 > > Robert Sparks wrote: > > > Aside from that I'd like for you to think through this again from=20 > > > viewpoints besides active attack (use a transient=20 > malfunction of the=20 > > > application (above the layer that would screw up basic SIP)), I'm=20 > > > ready to let this go as long as we have _a_ solid solution to=20 > > > dealing with reordered/missing notifies. > >=20 > > I'm not going to start down the path to speculation about how > > to recover=20 > > from arbitrary malfunctions of an application. That is just plain=20 > > impossible without some characterization of the kinds of=20 > malfunctions=20 > > that are to be recovered from. > >=20 > > > So, backing out a layer, lets look at my original question of=20 > > > whether or not we allow overlapping ->partial<- NOTIFYs at all in=20 > > > this case. > >=20 > > I don't see any compelling need to support overlapping > > partial notifies.=20 > > It is very difficult to see how to make them work. > >=20 > > I can imagine a case where there might be some motivation:=20 > I sent one > > notification and have had no response. But I already have a=20 > bunch of=20 > > additional changes that you should know about. It might be=20 > > advantageous=20 > > to start sending them as soon as possible. But until you know=20 > > the prior=20 > > one has been handled it isn't safe to send the new one. > >=20 > > > Why would you want to? What value would doing that bring? > > >=20 > > > 3261 and even presence-10 left sending full-state=20 > presence NOTIFYs=20 > > > open. We wouldn't be changing that. If an application for some=20 > > > reason decided it needed to send a new full-state notify while a=20 > > > partial-state notify was pending, it could. So any of the=20 > arguments=20 > > > for allowing it from the 3261/presence-10 are still=20 > satisfied. Can=20 > > > you see any use case where allowing a server to send overlapping=20 > > > partial NOTIFYs is a good idea? If not, disallowing it seems a=20 > > > powerful simplification. > > > > >=20 > > I agree. > >=20 > > Paul > >=20 > >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon May 3 08:47: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 IAA25621 for ; Mon, 3 May 2004 08:47: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 1BKcr0-0005pq-HC for simple-archive@ietf.org; Mon, 03 May 2004 08:47:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKcl5-0004xB-00 for simple-archive@ietf.org; Mon, 03 May 2004 08:41:22 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BKcf2-00045M-00; Mon, 03 May 2004 08:35:04 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BKcf0-0002Sq-Pw; Mon, 03 May 2004 08:35:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKcRV-0007IV-3r; Mon, 03 May 2004 08:21:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKcAd-0006sX-7O for simple@optimus.ietf.org; Mon, 03 May 2004 08:03: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 IAA22839 for ; Mon, 3 May 2004 08:03:37 -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 1BKcAc-0006yM-5P for simple@ietf.org; Mon, 03 May 2004 08:03:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKc7E-0006P7-00 for simple@ietf.org; Mon, 03 May 2004 08:00:09 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BKc4F-0005s7-00 for simple@ietf.org; Mon, 03 May 2004 07:57:03 -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 i43Bt6v11831; Mon, 3 May 2004 14:55:06 +0300 (EET DST) X-Scanned: Mon, 3 May 2004 14:54:57 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i43Bsvbv029166; Mon, 3 May 2004 14:54:57 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 002yuTxl; Mon, 03 May 2004 14:54:56 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 i43BstH24431; Mon, 3 May 2004 14:54:55 +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, 3 May 2004 14:54:48 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] WGLC: partial notification Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797A0D@esebe019.ntc.nokia.com> Thread-Topic: [Simple] WGLC: partial notification Thread-Index: AcQw/VWJM6WsuchxT5a+tYMNawjmLgAB6Yqg To: , , Cc: , X-OriginalArrivalTime: 03 May 2004 11:54:48.0219 (UTC) FILETIME=[6F201EB0:01C43105] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 3 May 2004 14:54:47 +0300 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 Schmidt Christian [mailto:christian-schmidt@siemens.com] > Sent: 03.May.2004 13:56 > To: Khartabil Hisham (Nokia-TP-MSW/Helsinki); pkyzivat@cisco.com; > rsparks@dynamicsoft.com > Cc: Lonnfors Mikko (Nokia-NRC/Helsinki); simple@ietf.org > Subject: AW: [Simple] WGLC: partial notification >=20 >=20 > > Hi Hisham, > >=20 > > please see my comments in the text, > >=20 > > best regards > > Chrisitan > >=20 > >=20 > >=20 > > > Hi Hisham, > > >=20 > > > this proposal would not solve the problem with a missing=20 > > > NOTIFY (full or partial).=20 > >=20 > > Can you demonstrate why with some flows? > >=20 > > Christian: > > Take for example the following flow > > ----> SUBSCRIBE > > <---- 200 > > <---- NOTIFY1 (full) > > ----> 200 > > <-X-- NOTIFY2 (full) > > <---- NOTIFY3 (partial) > >=20 > > The Receiver would not know, that NOTIFY2 was lost and take=20 > > NOTIFY3 as partial change on basis of NOTIFY1. That could=20 > > lead to incorrect information. Same in the following case. > > ----> SUBSCRIBE > > <---- 200 > > <---- NOTIFY1 (full) > > ----> 200 > > <-X-- NOTIFY2 (partial) > > <---- NOTIFY3 (partial) >=20 > These scenarios are no different than what we have been=20 > discussing. Version solves those problem. We have tracked a=20 > little back and started questioning the need for overlapping=20 > NOTIFYs. Why does disallowing overlapping partial NOTIFYs not=20 > solve the problem (which is what you were suggesting)? >=20 > Christian: > Disallowing overlapping partial NOTIFYs combined with=20 > versioning solve the problem. > Disallowing overlapping partial NOTIFYs without versioning=20 > would not solve the problem. This is what I was asking you to demonstrate with flows. > The version attribute, you need anyway to avoid mistakes in=20 > case of reordered full NOTIFYs. How can the NOTIFYs be reordered when the suggestion is that the = notifier not send one before the previous one completes? >=20 >=20 > >=20 > >=20 > >=20 > > >=20 > > > What=B4s about the following proposal: > > > The notifier must not issue a NOTIFY (full or partial),=20 > > > before it receives a 200 for the last issued NOTIFY (full or=20 > > > partial). After experation of a timer t, the notifier should=20 > > > send a full NOTIFY. > >=20 > > If a NOTIFY transaction does not complete, the subscription=20 > > is terminated.=20 > >=20 > > If you are suggesting that timer t is less than 64*T1 (timer=20 > > F, that's when the transaction terminates and subsequently=20 > > the subscription), then you are suggesting support for=20 > > overlapping NOTIFYs. > >=20 > > Sending a full state NOTIFY after timer t does not help since=20 > > if no response arrives for the partial NOTIFY, the=20 > > subscription will terminate. > >=20 > > Christian: > > If the notifier get no 200 for his last NOTIFY, either the=20 > > NOTIFY or the 200 was lost. Therefor the receiver possibly=20 > > can not benefit from a partial notification. If the receiver=20 > > gets a new upgrade and reply a 200, the notifier knows, that=20 > > the receiver is in sync again. Timer t should be selected=20 > > high enough, that overlapping NOTIFYs are nearly excluded. > > Is it necessary, that packet loss (timer F) will=20 > > automatically lead to a termination of the subscription? This=20 > > could lead to additional and perhaps not needed messages (new=20 > > subscription). >=20 > If sender of a NOTIFY (notifier) does not get a 200 for it=20 > and Timer F fires, it terminates the subscription. What is=20 > the point of sending a full NOTIFY if the subscription will=20 > termiante anyway? >=20 > Christian: > Is it possible, to avoid this unnecessary termination of the=20 > subscription (caused by the loss of a single packet) by an=20 > additional NOTIFY? This would increase efficiency. No. This behaviour is in RFC 3265. /Hisham >=20 >=20 > /Hisham >=20 > >=20 > >=20 > > /Hisham > >=20 > >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon May 3 08:54: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 IAA26016 for ; Mon, 3 May 2004 08:54: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 1BKcxW-0006mi-N1 for simple-archive@ietf.org; Mon, 03 May 2004 08:54:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKcrJ-0005sD-00 for simple-archive@ietf.org; Mon, 03 May 2004 08:47:47 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BKclO-0004zJ-00; Mon, 03 May 2004 08:41:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKce0-0002Fo-JT; Mon, 03 May 2004 08:34:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKcO7-0005he-P5 for simple@optimus.ietf.org; Mon, 03 May 2004 08:17: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 IAA23343 for ; Mon, 3 May 2004 08:17:33 -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 1BKcO6-0001O1-Mv for simple@ietf.org; Mon, 03 May 2004 08:17:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKcIe-0000VZ-00 for simple@ietf.org; Mon, 03 May 2004 08:11:58 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1BKcEi-0007aV-00 for simple@ietf.org; Mon, 03 May 2004 08:07:52 -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 i43C7hJ18414; Mon, 3 May 2004 15:07:43 +0300 (EET DST) X-Scanned: Mon, 3 May 2004 15:07:19 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i43C7Jie024950; Mon, 3 May 2004 15:07:19 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00zV03jy; Mon, 03 May 2004 15:07:18 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 i43C7BH02933; Mon, 3 May 2004 15:07:11 +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, 3 May 2004 15:07:11 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 3 May 2004 15:07:11 +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: partial notification Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797A0E@esebe019.ntc.nokia.com> Thread-Topic: [Simple] WGLC: partial notification Thread-Index: AcQuGno+S8hkiNZPTmuNIx+A90HBigAYOHCgAJ955eAAAw1PsA== To: , , Cc: X-OriginalArrivalTime: 03 May 2004 12:07:11.0148 (UTC) FILETIME=[29F216C0:01C43107] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 3 May 2004 15:07:10 +0300 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 Actually, the text is described in = draft-ietf-simple-winfo-format-04.txt: "version: This attribute allows the recipient of watcherinfo documents to properly order them. Versions start at 0, and increment by one for each new document sent to a subscriber. Versions are scoped within a watcherinfo subscription. Versions MUST be representable using a 32 bit integer. However, versions do not wrap." and "The version number MUST be initialized with the value of the "version" attribute from the "watcherinfo" element in the first document received. Each time a new document is received, the value of the local version number, and the "version" attribute in the new document, are compared. If the value in the new document is one higher than the local version number, the local version number is increased by one, and the document is processed. If the value in the document is more than one higher than the local version number, the local version number is set to the value in the new document, the document is processed, and the watcherinfo subscriber SHOULD generate a refresh request to trigger a full state notification. If the value in the document is less than the local version, the document is discarded without processing." If the problem exists for partial notification, then it also exists for = winfo, and for any event package that defines partial state. The text = quoted above to winfo is much similar to what I suggested for the use of = version. /Hisham > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > ext mikko.lonnfors@nokia.com > Sent: 03.May.2004 13:40 > To: Khartabil Hisham (Nokia-TP-MSW/Helsinki); rsparks@dynamicsoft.com; > jdrosen@dynamicsoft.com > Cc: simple@ietf.org > Subject: RE: [Simple] WGLC: partial notification >=20 >=20 > Hi, >=20 > Related to this issue it occurred to me that winfo > (draft-ietf-simple-winfo-package-05) may also suffer from this. As far > as I can tell "version" and "state" handling is quite similar=20 > (in winfo > version is scoped to the subscription) in both cases (winfo=20 > and partial > notify) and winfo also doesn't prohibit sending new NOTIFYs if there > exists a pending NOTIFY. =20 >=20 > Thoughts? > - Mikko >=20 > > -----Original Message----- > > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org] On=20 > > Behalf Of ext hisham.khartabil@nokia.com > > Sent: Friday, April 30, 2004 9:27 AM > > To: pkyzivat@cisco.com; rsparks@dynamicsoft.com > > Cc: Lonnfors Mikko (Nokia-NRC/Helsinki); simple@ietf.org > > Subject: RE: [Simple] WGLC: partial notification > >=20 > >=20 > > Ok, I also agree that overlapping partial NOTIFYs complicate=20 > > things without benefit. I also would like to propose=20 > > explicitly disallowing overlapping full state and partial.=20 > > I.e. A notifier must not issue a partial state NOTIFY without=20 > > first receiving the 200 for a full state NOTIFY. I believe=20 > > the converse is also required: the notifier must not issue a=20 > > full state NOTIFY before it receives a 200 for a partial=20 > state NOTIFY. > >=20 > > With all there restrictions, we can do without the version=20 > attribute. > >=20 > > Regards, > > Hisham > >=20 > > > -----Original Message----- > > > From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] > > > Sent: 29.April.2004 21:47 > > > To: Robert Sparks > > > Cc: Khartabil Hisham (Nokia-TP-MSW/Helsinki); Lonnfors Mikko=20 > > > (Nokia-NRC/Helsinki); simple@ietf.org > > > Subject: Re: [Simple] WGLC: partial notification > > >=20 > > >=20 > > >=20 > > >=20 > > > Robert Sparks wrote: > > > > Aside from that I'd like for you to think through this=20 > again from=20 > > > > viewpoints besides active attack (use a transient=20 > > malfunction of the=20 > > > > application (above the layer that would screw up basic=20 > SIP)), I'm=20 > > > > ready to let this go as long as we have _a_ solid solution to=20 > > > > dealing with reordered/missing notifies. > > >=20 > > > I'm not going to start down the path to speculation about how > > > to recover=20 > > > from arbitrary malfunctions of an application. That is just plain=20 > > > impossible without some characterization of the kinds of=20 > > malfunctions=20 > > > that are to be recovered from. > > >=20 > > > > So, backing out a layer, lets look at my original question of=20 > > > > whether or not we allow overlapping ->partial<- NOTIFYs=20 > at all in=20 > > > > this case. > > >=20 > > > I don't see any compelling need to support overlapping > > > partial notifies.=20 > > > It is very difficult to see how to make them work. > > >=20 > > > I can imagine a case where there might be some motivation:=20 > > I sent one > > > notification and have had no response. But I already have a=20 > > bunch of=20 > > > additional changes that you should know about. It might be=20 > > > advantageous=20 > > > to start sending them as soon as possible. But until you know=20 > > > the prior=20 > > > one has been handled it isn't safe to send the new one. > > >=20 > > > > Why would you want to? What value would doing that bring? > > > >=20 > > > > 3261 and even presence-10 left sending full-state=20 > > presence NOTIFYs=20 > > > > open. We wouldn't be changing that. If an application for some=20 > > > > reason decided it needed to send a new full-state=20 > notify while a=20 > > > > partial-state notify was pending, it could. So any of the=20 > > arguments=20 > > > > for allowing it from the 3261/presence-10 are still=20 > > satisfied. Can=20 > > > > you see any use case where allowing a server to send=20 > overlapping=20 > > > > partial NOTIFYs is a good idea? If not, disallowing it seems a=20 > > > > powerful simplification. > > > > > > >=20 > > > I agree. > > >=20 > > > Paul > > >=20 > > >=20 > >=20 > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon May 3 09:07: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 JAA26944 for ; Mon, 3 May 2004 09:07: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 1BKdAk-00017R-1F for simple-archive@ietf.org; Mon, 03 May 2004 09:07:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKd7O-0000W8-00 for simple-archive@ietf.org; Mon, 03 May 2004 09:04:24 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BKd3l-0007gQ-00; Mon, 03 May 2004 09:00:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKclG-0008H9-KR; Mon, 03 May 2004 08:41:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKcWh-000854-KQ for simple@optimus.ietf.org; Mon, 03 May 2004 08:26: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 IAA23996 for ; Mon, 3 May 2004 08:26: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 1BKcWg-0002a3-Fu for simple@ietf.org; Mon, 03 May 2004 08:26:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKcPt-0001bn-00 for simple@ietf.org; Mon, 03 May 2004 08:19:27 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BKcKv-0000ha-00 for simple@ietf.org; Mon, 03 May 2004 08:14:17 -0400 Received: from dynamicsoft.com ([63.113.46.116]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i43CDgus023513; Mon, 3 May 2004 08:13:43 -0400 (EDT) Message-ID: <4096374C.2040305@dynamicsoft.com> 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 CC: Simple WG Subject: Re: [Simple] Update to xcap authorization rules - rpid type References: <4092A750.3080501@dynamicsoft.com> <4093E399.9030508@cs.columbia.edu> In-Reply-To: <4093E399.9030508@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 03 May 2004 08:13:00 -0400 X-Spam-Checker-Version: SpamAssassin 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: > I'm not sure I completely understand the item below, but one potential > concern is that this may mix conditions and actions in one element, with > less-than-clear expressions. It is probably less efficient, but clearer, > in my opinion, to keep the two separate, even if it means expressing > them as two or more separate rules. I'm not sure how to do that. You are correct that the permissions do define conditions, and in particular, they specify the conditions under which a particular rpid element is included in the presence document. For example, "include placeype in tuples where the class is "friend"". However, those are different conditions than what the condition element specifies, which is, "should this permission be applied to the processing of this subscription". As such, I don't know how to use these conditions to specify a rule like the example above. > > We don't necessarily want to design to a user interface, but the more > sub-clauses and conditions something has, the more difficult it becomes > to write simple GUIs for it. (This also greatly complicates translation > into other rule mechanisms.) OK, fair enough - that would argue for going back to having simply a boolean for inclusion of these elements or not. But it seems we want more than that, no? > > Thus, I'd prefer an explicit equality condition on (say) class and > placetype, with an associated list of included objects. As I mention, I dont know how this would work. Lets say my presence document has two tuples, one with class of "friend" and the other with class of "work". Both include the "placetype" element. If you had a condition that specified an equality condition on class: home This would remove the placetype element (since no permission is granted for it). When would this rule be applied to a subscription? It matches for one tuple, but not another. What would it mean to apply the entire rule only for one tuple? Indeed, it occurs to me that we have a similar problem for the existing element, which can have different values in different tuples. > > Doing the same thing in two ways, just because they are two different > attributes, doesn't strike me as a minimalist design. Agree with that. If we can find a model whereby the conditional aspects of this can be placed in the section, I agree its definitely better. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon May 3 09:41:27 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28753 for ; Mon, 3 May 2004 09:41:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKd4w-0006n3-7Y for simple-archive@odin.ietf.org; Mon, 03 May 2004 09:01:50 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i43D1okR026088 for simple-archive@odin.ietf.org; Mon, 3 May 2004 09:01:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKcr6-0000cC-Rz for simple-web-archive@optimus.ietf.org; Mon, 03 May 2004 08:47: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 IAA25642 for ; Mon, 3 May 2004 08:47: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 1BKcr5-0005qU-Ht for simple-web-archive@ietf.org; Mon, 03 May 2004 08:47:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKcl9-0004xh-00 for simple-web-archive@ietf.org; Mon, 03 May 2004 08:41:25 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BKcf2-00045M-00; Mon, 03 May 2004 08:35:04 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BKcf0-0002Sq-Pw; Mon, 03 May 2004 08:35:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKcRV-0007IV-3r; Mon, 03 May 2004 08:21:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKcAd-0006sX-7O for simple@optimus.ietf.org; Mon, 03 May 2004 08:03: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 IAA22839 for ; Mon, 3 May 2004 08:03:37 -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 1BKcAc-0006yM-5P for simple@ietf.org; Mon, 03 May 2004 08:03:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKc7E-0006P7-00 for simple@ietf.org; Mon, 03 May 2004 08:00:09 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BKc4F-0005s7-00 for simple@ietf.org; Mon, 03 May 2004 07:57:03 -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 i43Bt6v11831; Mon, 3 May 2004 14:55:06 +0300 (EET DST) X-Scanned: Mon, 3 May 2004 14:54:57 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i43Bsvbv029166; Mon, 3 May 2004 14:54:57 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 002yuTxl; Mon, 03 May 2004 14:54:56 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 i43BstH24431; Mon, 3 May 2004 14:54:55 +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, 3 May 2004 14:54:48 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] WGLC: partial notification Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797A0D@esebe019.ntc.nokia.com> Thread-Topic: [Simple] WGLC: partial notification Thread-Index: AcQw/VWJM6WsuchxT5a+tYMNawjmLgAB6Yqg To: , , Cc: , X-OriginalArrivalTime: 03 May 2004 11:54:48.0219 (UTC) FILETIME=[6F201EB0:01C43105] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 3 May 2004 14:54:47 +0300 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 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Schmidt Christian [mailto:christian-schmidt@siemens.com] > Sent: 03.May.2004 13:56 > To: Khartabil Hisham (Nokia-TP-MSW/Helsinki); pkyzivat@cisco.com; > rsparks@dynamicsoft.com > Cc: Lonnfors Mikko (Nokia-NRC/Helsinki); simple@ietf.org > Subject: AW: [Simple] WGLC: partial notification >=20 >=20 > > Hi Hisham, > >=20 > > please see my comments in the text, > >=20 > > best regards > > Chrisitan > >=20 > >=20 > >=20 > > > Hi Hisham, > > >=20 > > > this proposal would not solve the problem with a missing=20 > > > NOTIFY (full or partial).=20 > >=20 > > Can you demonstrate why with some flows? > >=20 > > Christian: > > Take for example the following flow > > ----> SUBSCRIBE > > <---- 200 > > <---- NOTIFY1 (full) > > ----> 200 > > <-X-- NOTIFY2 (full) > > <---- NOTIFY3 (partial) > >=20 > > The Receiver would not know, that NOTIFY2 was lost and take=20 > > NOTIFY3 as partial change on basis of NOTIFY1. That could=20 > > lead to incorrect information. Same in the following case. > > ----> SUBSCRIBE > > <---- 200 > > <---- NOTIFY1 (full) > > ----> 200 > > <-X-- NOTIFY2 (partial) > > <---- NOTIFY3 (partial) >=20 > These scenarios are no different than what we have been=20 > discussing. Version solves those problem. We have tracked a=20 > little back and started questioning the need for overlapping=20 > NOTIFYs. Why does disallowing overlapping partial NOTIFYs not=20 > solve the problem (which is what you were suggesting)? >=20 > Christian: > Disallowing overlapping partial NOTIFYs combined with=20 > versioning solve the problem. > Disallowing overlapping partial NOTIFYs without versioning=20 > would not solve the problem. This is what I was asking you to demonstrate with flows. > The version attribute, you need anyway to avoid mistakes in=20 > case of reordered full NOTIFYs. How can the NOTIFYs be reordered when the suggestion is that the = notifier not send one before the previous one completes? >=20 >=20 > >=20 > >=20 > >=20 > > >=20 > > > What=B4s about the following proposal: > > > The notifier must not issue a NOTIFY (full or partial),=20 > > > before it receives a 200 for the last issued NOTIFY (full or=20 > > > partial). After experation of a timer t, the notifier should=20 > > > send a full NOTIFY. > >=20 > > If a NOTIFY transaction does not complete, the subscription=20 > > is terminated.=20 > >=20 > > If you are suggesting that timer t is less than 64*T1 (timer=20 > > F, that's when the transaction terminates and subsequently=20 > > the subscription), then you are suggesting support for=20 > > overlapping NOTIFYs. > >=20 > > Sending a full state NOTIFY after timer t does not help since=20 > > if no response arrives for the partial NOTIFY, the=20 > > subscription will terminate. > >=20 > > Christian: > > If the notifier get no 200 for his last NOTIFY, either the=20 > > NOTIFY or the 200 was lost. Therefor the receiver possibly=20 > > can not benefit from a partial notification. If the receiver=20 > > gets a new upgrade and reply a 200, the notifier knows, that=20 > > the receiver is in sync again. Timer t should be selected=20 > > high enough, that overlapping NOTIFYs are nearly excluded. > > Is it necessary, that packet loss (timer F) will=20 > > automatically lead to a termination of the subscription? This=20 > > could lead to additional and perhaps not needed messages (new=20 > > subscription). >=20 > If sender of a NOTIFY (notifier) does not get a 200 for it=20 > and Timer F fires, it terminates the subscription. What is=20 > the point of sending a full NOTIFY if the subscription will=20 > termiante anyway? >=20 > Christian: > Is it possible, to avoid this unnecessary termination of the=20 > subscription (caused by the loss of a single packet) by an=20 > additional NOTIFY? This would increase efficiency. No. This behaviour is in RFC 3265. /Hisham >=20 >=20 > /Hisham >=20 > >=20 > >=20 > > /Hisham > >=20 > >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon May 3 09:42:52 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28953 for ; Mon, 3 May 2004 09:42:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKd5n-0007DB-Cm for simple-archive@odin.ietf.org; Mon, 03 May 2004 09:02:43 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i43D2hAK027716 for simple-archive@odin.ietf.org; Mon, 3 May 2004 09:02:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKcxZ-0001ms-4m for simple-web-archive@optimus.ietf.org; Mon, 03 May 2004 08:54: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 IAA26034 for ; Mon, 3 May 2004 08:54: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 1BKcxX-0006mv-Ou for simple-web-archive@ietf.org; Mon, 03 May 2004 08:54:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKcrL-0005sR-00 for simple-web-archive@ietf.org; Mon, 03 May 2004 08:47:51 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BKclO-0004zJ-00; Mon, 03 May 2004 08:41:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKce0-0002Fo-JT; Mon, 03 May 2004 08:34:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKcO7-0005he-P5 for simple@optimus.ietf.org; Mon, 03 May 2004 08:17: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 IAA23343 for ; Mon, 3 May 2004 08:17:33 -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 1BKcO6-0001O1-Mv for simple@ietf.org; Mon, 03 May 2004 08:17:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKcIe-0000VZ-00 for simple@ietf.org; Mon, 03 May 2004 08:11:58 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1BKcEi-0007aV-00 for simple@ietf.org; Mon, 03 May 2004 08:07:52 -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 i43C7hJ18414; Mon, 3 May 2004 15:07:43 +0300 (EET DST) X-Scanned: Mon, 3 May 2004 15:07:19 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i43C7Jie024950; Mon, 3 May 2004 15:07:19 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00zV03jy; Mon, 03 May 2004 15:07:18 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 i43C7BH02933; Mon, 3 May 2004 15:07:11 +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, 3 May 2004 15:07:11 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 3 May 2004 15:07:11 +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: partial notification Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797A0E@esebe019.ntc.nokia.com> Thread-Topic: [Simple] WGLC: partial notification Thread-Index: AcQuGno+S8hkiNZPTmuNIx+A90HBigAYOHCgAJ955eAAAw1PsA== To: , , Cc: X-OriginalArrivalTime: 03 May 2004 12:07:11.0148 (UTC) FILETIME=[29F216C0:01C43107] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 3 May 2004 15:07:10 +0300 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 Content-Transfer-Encoding: quoted-printable Actually, the text is described in = draft-ietf-simple-winfo-format-04.txt: "version: This attribute allows the recipient of watcherinfo documents to properly order them. Versions start at 0, and increment by one for each new document sent to a subscriber. Versions are scoped within a watcherinfo subscription. Versions MUST be representable using a 32 bit integer. However, versions do not wrap." and "The version number MUST be initialized with the value of the "version" attribute from the "watcherinfo" element in the first document received. Each time a new document is received, the value of the local version number, and the "version" attribute in the new document, are compared. If the value in the new document is one higher than the local version number, the local version number is increased by one, and the document is processed. If the value in the document is more than one higher than the local version number, the local version number is set to the value in the new document, the document is processed, and the watcherinfo subscriber SHOULD generate a refresh request to trigger a full state notification. If the value in the document is less than the local version, the document is discarded without processing." If the problem exists for partial notification, then it also exists for = winfo, and for any event package that defines partial state. The text = quoted above to winfo is much similar to what I suggested for the use of = version. /Hisham > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > ext mikko.lonnfors@nokia.com > Sent: 03.May.2004 13:40 > To: Khartabil Hisham (Nokia-TP-MSW/Helsinki); rsparks@dynamicsoft.com; > jdrosen@dynamicsoft.com > Cc: simple@ietf.org > Subject: RE: [Simple] WGLC: partial notification >=20 >=20 > Hi, >=20 > Related to this issue it occurred to me that winfo > (draft-ietf-simple-winfo-package-05) may also suffer from this. As far > as I can tell "version" and "state" handling is quite similar=20 > (in winfo > version is scoped to the subscription) in both cases (winfo=20 > and partial > notify) and winfo also doesn't prohibit sending new NOTIFYs if there > exists a pending NOTIFY. =20 >=20 > Thoughts? > - Mikko >=20 > > -----Original Message----- > > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org] On=20 > > Behalf Of ext hisham.khartabil@nokia.com > > Sent: Friday, April 30, 2004 9:27 AM > > To: pkyzivat@cisco.com; rsparks@dynamicsoft.com > > Cc: Lonnfors Mikko (Nokia-NRC/Helsinki); simple@ietf.org > > Subject: RE: [Simple] WGLC: partial notification > >=20 > >=20 > > Ok, I also agree that overlapping partial NOTIFYs complicate=20 > > things without benefit. I also would like to propose=20 > > explicitly disallowing overlapping full state and partial.=20 > > I.e. A notifier must not issue a partial state NOTIFY without=20 > > first receiving the 200 for a full state NOTIFY. I believe=20 > > the converse is also required: the notifier must not issue a=20 > > full state NOTIFY before it receives a 200 for a partial=20 > state NOTIFY. > >=20 > > With all there restrictions, we can do without the version=20 > attribute. > >=20 > > Regards, > > Hisham > >=20 > > > -----Original Message----- > > > From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] > > > Sent: 29.April.2004 21:47 > > > To: Robert Sparks > > > Cc: Khartabil Hisham (Nokia-TP-MSW/Helsinki); Lonnfors Mikko=20 > > > (Nokia-NRC/Helsinki); simple@ietf.org > > > Subject: Re: [Simple] WGLC: partial notification > > >=20 > > >=20 > > >=20 > > >=20 > > > Robert Sparks wrote: > > > > Aside from that I'd like for you to think through this=20 > again from=20 > > > > viewpoints besides active attack (use a transient=20 > > malfunction of the=20 > > > > application (above the layer that would screw up basic=20 > SIP)), I'm=20 > > > > ready to let this go as long as we have _a_ solid solution to=20 > > > > dealing with reordered/missing notifies. > > >=20 > > > I'm not going to start down the path to speculation about how > > > to recover=20 > > > from arbitrary malfunctions of an application. That is just plain=20 > > > impossible without some characterization of the kinds of=20 > > malfunctions=20 > > > that are to be recovered from. > > >=20 > > > > So, backing out a layer, lets look at my original question of=20 > > > > whether or not we allow overlapping ->partial<- NOTIFYs=20 > at all in=20 > > > > this case. > > >=20 > > > I don't see any compelling need to support overlapping > > > partial notifies.=20 > > > It is very difficult to see how to make them work. > > >=20 > > > I can imagine a case where there might be some motivation:=20 > > I sent one > > > notification and have had no response. But I already have a=20 > > bunch of=20 > > > additional changes that you should know about. It might be=20 > > > advantageous=20 > > > to start sending them as soon as possible. But until you know=20 > > > the prior=20 > > > one has been handled it isn't safe to send the new one. > > >=20 > > > > Why would you want to? What value would doing that bring? > > > >=20 > > > > 3261 and even presence-10 left sending full-state=20 > > presence NOTIFYs=20 > > > > open. We wouldn't be changing that. If an application for some=20 > > > > reason decided it needed to send a new full-state=20 > notify while a=20 > > > > partial-state notify was pending, it could. So any of the=20 > > arguments=20 > > > > for allowing it from the 3261/presence-10 are still=20 > > satisfied. Can=20 > > > > you see any use case where allowing a server to send=20 > overlapping=20 > > > > partial NOTIFYs is a good idea? If not, disallowing it seems a=20 > > > > powerful simplification. > > > > > > >=20 > > > I agree. > > >=20 > > > Paul > > >=20 > > >=20 > >=20 > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon May 3 09:52:07 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29545 for ; Mon, 3 May 2004 09:52:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKdjL-0007gD-9I for simple-archive@odin.ietf.org; Mon, 03 May 2004 09:43:35 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i43DhZrO029518 for simple-archive@odin.ietf.org; Mon, 3 May 2004 09:43:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKdAm-0007we-8q for simple-web-archive@optimus.ietf.org; Mon, 03 May 2004 09:07: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 JAA26962 for ; Mon, 3 May 2004 09:07: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 1BKdAk-00017a-L4 for simple-web-archive@ietf.org; Mon, 03 May 2004 09:07:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKd7Q-0000WG-00 for simple-web-archive@ietf.org; Mon, 03 May 2004 09:04:25 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BKd3l-0007gQ-00; Mon, 03 May 2004 09:00:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKclG-0008H9-KR; Mon, 03 May 2004 08:41:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKcWh-000854-KQ for simple@optimus.ietf.org; Mon, 03 May 2004 08:26: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 IAA23996 for ; Mon, 3 May 2004 08:26: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 1BKcWg-0002a3-Fu for simple@ietf.org; Mon, 03 May 2004 08:26:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKcPt-0001bn-00 for simple@ietf.org; Mon, 03 May 2004 08:19:27 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BKcKv-0000ha-00 for simple@ietf.org; Mon, 03 May 2004 08:14:17 -0400 Received: from dynamicsoft.com ([63.113.46.116]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i43CDgus023513; Mon, 3 May 2004 08:13:43 -0400 (EDT) Message-ID: <4096374C.2040305@dynamicsoft.com> 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 CC: Simple WG Subject: Re: [Simple] Update to xcap authorization rules - rpid type References: <4092A750.3080501@dynamicsoft.com> <4093E399.9030508@cs.columbia.edu> In-Reply-To: <4093E399.9030508@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 03 May 2004 08:13:00 -0400 X-Spam-Checker-Version: SpamAssassin 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 Content-Transfer-Encoding: 7bit inline. Henning Schulzrinne wrote: > I'm not sure I completely understand the item below, but one potential > concern is that this may mix conditions and actions in one element, with > less-than-clear expressions. It is probably less efficient, but clearer, > in my opinion, to keep the two separate, even if it means expressing > them as two or more separate rules. I'm not sure how to do that. You are correct that the permissions do define conditions, and in particular, they specify the conditions under which a particular rpid element is included in the presence document. For example, "include placeype in tuples where the class is "friend"". However, those are different conditions than what the condition element specifies, which is, "should this permission be applied to the processing of this subscription". As such, I don't know how to use these conditions to specify a rule like the example above. > > We don't necessarily want to design to a user interface, but the more > sub-clauses and conditions something has, the more difficult it becomes > to write simple GUIs for it. (This also greatly complicates translation > into other rule mechanisms.) OK, fair enough - that would argue for going back to having simply a boolean for inclusion of these elements or not. But it seems we want more than that, no? > > Thus, I'd prefer an explicit equality condition on (say) class and > placetype, with an associated list of included objects. As I mention, I dont know how this would work. Lets say my presence document has two tuples, one with class of "friend" and the other with class of "work". Both include the "placetype" element. If you had a condition that specified an equality condition on class: home This would remove the placetype element (since no permission is granted for it). When would this rule be applied to a subscription? It matches for one tuple, but not another. What would it mean to apply the entire rule only for one tuple? Indeed, it occurs to me that we have a similar problem for the existing element, which can have different values in different tuples. > > Doing the same thing in two ways, just because they are two different > attributes, doesn't strike me as a minimalist design. Agree with that. If we can find a model whereby the conditional aspects of this can be placed in the section, I agree its definitely better. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon May 3 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 KAA03403 for ; Mon, 3 May 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 1BKeH1-0003xT-4o for simple-archive@ietf.org; Mon, 03 May 2004 10:18:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKeAL-0002oP-00 for simple-archive@ietf.org; Mon, 03 May 2004 10:11:31 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BKe1t-0001Wm-00; Mon, 03 May 2004 10:02:45 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BKe1t-0003yj-VL; Mon, 03 May 2004 10:02:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKdkm-0008LY-5s; Mon, 03 May 2004 09:45:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKdLA-0000Fq-SD for simple@optimus.ietf.org; Mon, 03 May 2004 09:18: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 JAA27326 for ; Mon, 3 May 2004 09:18: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 1BKdL9-0002lw-8K for simple@ietf.org; Mon, 03 May 2004 09:18:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKdI1-0002DG-00 for simple@ietf.org; Mon, 03 May 2004 09:15:23 -0400 Received: from david.siemens.de ([192.35.17.14]) by ietf-mx with esmtp (Exim 4.12) id 1BKdFC-0001jH-00 for simple@ietf.org; Mon, 03 May 2004 09:12:26 -0400 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by david.siemens.de (8.11.7/8.11.7) with ESMTP id i43DBAj20176; Mon, 3 May 2004 15:11:10 +0200 (MEST) Received: from blues.mchh.siemens.de (blues.mchh.siemens.de [139.21.204.206]) by mail2.siemens.de (8.11.7/8.11.7) with ESMTP id i43DBAM01531; Mon, 3 May 2004 15:11:10 +0200 (MEST) Received: from mchh248e.mchh.siemens.de (mchh248e.mchh.siemens.de [139.21.200.58]) by blues.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id PAA03118; Mon, 3 May 2004 15:10:34 +0200 (MET DST) Received: by mchh248e.mchh.siemens.de with Internet Mail Service (5.5.2657.72) id ; Mon, 3 May 2004 15:11:08 +0200 Message-ID: From: Schmidt Christian To: "'hisham.khartabil@nokia.com'" , Schmidt Christian , pkyzivat@cisco.com, rsparks@dynamicsoft.com Cc: mikko.lonnfors@nokia.com, simple@ietf.org Subject: AW: [Simple] WGLC: partial notification 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 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 3 May 2004 15:11:05 +0200 X-Spam-Checker-Version: SpamAssassin 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 Hisham, thank you for the clarification (especially the hint to RFC3265, = section 3.2.2).=20 - Disallowing overlapping partial and allowing overlapping full NOTIFYs = combined with versioning solve the problem. - Disallowing overlapping partial allowing overlapping full NOTIFYs = without versioning would not solve the problem. >This is what I was asking you to demonstrate with flows. Example: ----> SUBSCRIBE <---- 200 -- NOTIFY1 (full) <---- NOTIFY2 (full)=20 ----> 200 (NOTIFY2) <-- ----> 200 (NOTIFY1) Assume reordering of NOTIFY1 and NOTIFY2. Without version number, the = user could not discover reordering. The user would assume the contents of NOTIFY1 as actual information, = but this would be wrong. - Disallowing any overlapping NOTIFY (both partial and full) without = versioning would solve the problem. Regards, Christian -----Urspr=FCngliche Nachricht----- Von: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com]=20 Gesendet: Montag, 3. Mai 2004 13:55 An: christian-schmidt@siemens.com; pkyzivat@cisco.com; = rsparks@dynamicsoft.com Cc: mikko.lonnfors@nokia.com; simple@ietf.org Betreff: RE: [Simple] WGLC: partial notification > -----Original Message----- > From: ext Schmidt Christian [mailto:christian-schmidt@siemens.com] > Sent: 03.May.2004 13:56 > To: Khartabil Hisham (Nokia-TP-MSW/Helsinki); pkyzivat@cisco.com; > rsparks@dynamicsoft.com > Cc: Lonnfors Mikko (Nokia-NRC/Helsinki); simple@ietf.org > Subject: AW: [Simple] WGLC: partial notification >=20 >=20 > > Hi Hisham, > >=20 > > please see my comments in the text, > >=20 > > best regards > > Chrisitan > >=20 > >=20 > >=20 > > > Hi Hisham, > > >=20 > > > this proposal would not solve the problem with a missing=20 > > > NOTIFY (full or partial).=20 > >=20 > > Can you demonstrate why with some flows? > >=20 > > Christian: > > Take for example the following flow > > ----> SUBSCRIBE > > <---- 200 > > <---- NOTIFY1 (full) > > ----> 200 > > <-X-- NOTIFY2 (full) > > <---- NOTIFY3 (partial) > >=20 > > The Receiver would not know, that NOTIFY2 was lost and take=20 > > NOTIFY3 as partial change on basis of NOTIFY1. That could=20 > > lead to incorrect information. Same in the following case. > > ----> SUBSCRIBE > > <---- 200 > > <---- NOTIFY1 (full) > > ----> 200 > > <-X-- NOTIFY2 (partial) > > <---- NOTIFY3 (partial) >=20 > These scenarios are no different than what we have been=20 > discussing. Version solves those problem. We have tracked a=20 > little back and started questioning the need for overlapping=20 > NOTIFYs. Why does disallowing overlapping partial NOTIFYs not=20 > solve the problem (which is what you were suggesting)? >=20 > Christian: > Disallowing overlapping partial NOTIFYs combined with=20 > versioning solve the problem. > Disallowing overlapping partial NOTIFYs without versioning=20 > would not solve the problem. This is what I was asking you to demonstrate with flows. > The version attribute, you need anyway to avoid mistakes in=20 > case of reordered full NOTIFYs. How can the NOTIFYs be reordered when the suggestion is that the = notifier not send one before the previous one completes? >=20 >=20 > >=20 > >=20 > >=20 > > >=20 > > > What=B4s about the following proposal: > > > The notifier must not issue a NOTIFY (full or partial),=20 > > > before it receives a 200 for the last issued NOTIFY (full or=20 > > > partial). After experation of a timer t, the notifier should=20 > > > send a full NOTIFY. > >=20 > > If a NOTIFY transaction does not complete, the subscription=20 > > is terminated.=20 > >=20 > > If you are suggesting that timer t is less than 64*T1 (timer=20 > > F, that's when the transaction terminates and subsequently=20 > > the subscription), then you are suggesting support for=20 > > overlapping NOTIFYs. > >=20 > > Sending a full state NOTIFY after timer t does not help since > > if no response arrives for the partial NOTIFY, the=20 > > subscription will terminate. > >=20 > > Christian: > > If the notifier get no 200 for his last NOTIFY, either the=20 > > NOTIFY or the 200 was lost. Therefor the receiver possibly=20 > > can not benefit from a partial notification. If the receiver=20 > > gets a new upgrade and reply a 200, the notifier knows, that=20 > > the receiver is in sync again. Timer t should be selected=20 > > high enough, that overlapping NOTIFYs are nearly excluded. > > Is it necessary, that packet loss (timer F) will=20 > > automatically lead to a termination of the subscription? This=20 > > could lead to additional and perhaps not needed messages (new=20 > > subscription). >=20 > If sender of a NOTIFY (notifier) does not get a 200 for it=20 > and Timer F fires, it terminates the subscription. What is=20 > the point of sending a full NOTIFY if the subscription will=20 > termiante anyway? >=20 > Christian: > Is it possible, to avoid this unnecessary termination of the=20 > subscription (caused by the loss of a single packet) by an=20 > additional NOTIFY? This would increase efficiency. No. This behaviour is in RFC 3265. /Hisham >=20 >=20 > /Hisham >=20 > >=20 > >=20 > > /Hisham > >=20 > >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon May 3 10:25:29 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04774 for ; Mon, 3 May 2004 10:25:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKeMN-0001MP-DH for simple-archive@odin.ietf.org; Mon, 03 May 2004 10:23:56 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i43ENtmo005230 for simple-archive@odin.ietf.org; Mon, 3 May 2004 10:23:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKeH4-0007T9-2z for simple-web-archive@optimus.ietf.org; Mon, 03 May 2004 10:18: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 KAA03421 for ; Mon, 3 May 2004 10:18: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 1BKeH1-0003xc-ST for simple-web-archive@ietf.org; Mon, 03 May 2004 10:18:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKeAN-0002oX-00 for simple-web-archive@ietf.org; Mon, 03 May 2004 10:11:33 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BKe1t-0001Wm-00; Mon, 03 May 2004 10:02:45 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BKe1t-0003yj-VL; Mon, 03 May 2004 10:02:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKdkm-0008LY-5s; Mon, 03 May 2004 09:45:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKdLA-0000Fq-SD for simple@optimus.ietf.org; Mon, 03 May 2004 09:18: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 JAA27326 for ; Mon, 3 May 2004 09:18: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 1BKdL9-0002lw-8K for simple@ietf.org; Mon, 03 May 2004 09:18:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKdI1-0002DG-00 for simple@ietf.org; Mon, 03 May 2004 09:15:23 -0400 Received: from david.siemens.de ([192.35.17.14]) by ietf-mx with esmtp (Exim 4.12) id 1BKdFC-0001jH-00 for simple@ietf.org; Mon, 03 May 2004 09:12:26 -0400 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by david.siemens.de (8.11.7/8.11.7) with ESMTP id i43DBAj20176; Mon, 3 May 2004 15:11:10 +0200 (MEST) Received: from blues.mchh.siemens.de (blues.mchh.siemens.de [139.21.204.206]) by mail2.siemens.de (8.11.7/8.11.7) with ESMTP id i43DBAM01531; Mon, 3 May 2004 15:11:10 +0200 (MEST) Received: from mchh248e.mchh.siemens.de (mchh248e.mchh.siemens.de [139.21.200.58]) by blues.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id PAA03118; Mon, 3 May 2004 15:10:34 +0200 (MET DST) Received: by mchh248e.mchh.siemens.de with Internet Mail Service (5.5.2657.72) id ; Mon, 3 May 2004 15:11:08 +0200 Message-ID: From: Schmidt Christian To: "'hisham.khartabil@nokia.com'" , Schmidt Christian , pkyzivat@cisco.com, rsparks@dynamicsoft.com Cc: mikko.lonnfors@nokia.com, simple@ietf.org Subject: AW: [Simple] WGLC: partial notification 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 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 3 May 2004 15:11:05 +0200 X-Spam-Checker-Version: SpamAssassin 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 Content-Transfer-Encoding: quoted-printable Hi Hisham, thank you for the clarification (especially the hint to RFC3265, = section 3.2.2).=20 - Disallowing overlapping partial and allowing overlapping full NOTIFYs = combined with versioning solve the problem. - Disallowing overlapping partial allowing overlapping full NOTIFYs = without versioning would not solve the problem. >This is what I was asking you to demonstrate with flows. Example: ----> SUBSCRIBE <---- 200 -- NOTIFY1 (full) <---- NOTIFY2 (full)=20 ----> 200 (NOTIFY2) <-- ----> 200 (NOTIFY1) Assume reordering of NOTIFY1 and NOTIFY2. Without version number, the = user could not discover reordering. The user would assume the contents of NOTIFY1 as actual information, = but this would be wrong. - Disallowing any overlapping NOTIFY (both partial and full) without = versioning would solve the problem. Regards, Christian -----Urspr=FCngliche Nachricht----- Von: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com]=20 Gesendet: Montag, 3. Mai 2004 13:55 An: christian-schmidt@siemens.com; pkyzivat@cisco.com; = rsparks@dynamicsoft.com Cc: mikko.lonnfors@nokia.com; simple@ietf.org Betreff: RE: [Simple] WGLC: partial notification > -----Original Message----- > From: ext Schmidt Christian [mailto:christian-schmidt@siemens.com] > Sent: 03.May.2004 13:56 > To: Khartabil Hisham (Nokia-TP-MSW/Helsinki); pkyzivat@cisco.com; > rsparks@dynamicsoft.com > Cc: Lonnfors Mikko (Nokia-NRC/Helsinki); simple@ietf.org > Subject: AW: [Simple] WGLC: partial notification >=20 >=20 > > Hi Hisham, > >=20 > > please see my comments in the text, > >=20 > > best regards > > Chrisitan > >=20 > >=20 > >=20 > > > Hi Hisham, > > >=20 > > > this proposal would not solve the problem with a missing=20 > > > NOTIFY (full or partial).=20 > >=20 > > Can you demonstrate why with some flows? > >=20 > > Christian: > > Take for example the following flow > > ----> SUBSCRIBE > > <---- 200 > > <---- NOTIFY1 (full) > > ----> 200 > > <-X-- NOTIFY2 (full) > > <---- NOTIFY3 (partial) > >=20 > > The Receiver would not know, that NOTIFY2 was lost and take=20 > > NOTIFY3 as partial change on basis of NOTIFY1. That could=20 > > lead to incorrect information. Same in the following case. > > ----> SUBSCRIBE > > <---- 200 > > <---- NOTIFY1 (full) > > ----> 200 > > <-X-- NOTIFY2 (partial) > > <---- NOTIFY3 (partial) >=20 > These scenarios are no different than what we have been=20 > discussing. Version solves those problem. We have tracked a=20 > little back and started questioning the need for overlapping=20 > NOTIFYs. Why does disallowing overlapping partial NOTIFYs not=20 > solve the problem (which is what you were suggesting)? >=20 > Christian: > Disallowing overlapping partial NOTIFYs combined with=20 > versioning solve the problem. > Disallowing overlapping partial NOTIFYs without versioning=20 > would not solve the problem. This is what I was asking you to demonstrate with flows. > The version attribute, you need anyway to avoid mistakes in=20 > case of reordered full NOTIFYs. How can the NOTIFYs be reordered when the suggestion is that the = notifier not send one before the previous one completes? >=20 >=20 > >=20 > >=20 > >=20 > > >=20 > > > What=B4s about the following proposal: > > > The notifier must not issue a NOTIFY (full or partial),=20 > > > before it receives a 200 for the last issued NOTIFY (full or=20 > > > partial). After experation of a timer t, the notifier should=20 > > > send a full NOTIFY. > >=20 > > If a NOTIFY transaction does not complete, the subscription=20 > > is terminated.=20 > >=20 > > If you are suggesting that timer t is less than 64*T1 (timer=20 > > F, that's when the transaction terminates and subsequently=20 > > the subscription), then you are suggesting support for=20 > > overlapping NOTIFYs. > >=20 > > Sending a full state NOTIFY after timer t does not help since > > if no response arrives for the partial NOTIFY, the=20 > > subscription will terminate. > >=20 > > Christian: > > If the notifier get no 200 for his last NOTIFY, either the=20 > > NOTIFY or the 200 was lost. Therefor the receiver possibly=20 > > can not benefit from a partial notification. If the receiver=20 > > gets a new upgrade and reply a 200, the notifier knows, that=20 > > the receiver is in sync again. Timer t should be selected=20 > > high enough, that overlapping NOTIFYs are nearly excluded. > > Is it necessary, that packet loss (timer F) will=20 > > automatically lead to a termination of the subscription? This=20 > > could lead to additional and perhaps not needed messages (new=20 > > subscription). >=20 > If sender of a NOTIFY (notifier) does not get a 200 for it=20 > and Timer F fires, it terminates the subscription. What is=20 > the point of sending a full NOTIFY if the subscription will=20 > termiante anyway? >=20 > Christian: > Is it possible, to avoid this unnecessary termination of the=20 > subscription (caused by the loss of a single packet) by an=20 > additional NOTIFY? This would increase efficiency. No. This behaviour is in RFC 3265. /Hisham >=20 >=20 > /Hisham >=20 > >=20 > >=20 > > /Hisham > >=20 > >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon May 3 10:52: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 KAA06233 for ; Mon, 3 May 2004 10:52: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 1BKeoK-0006NH-CA for simple-archive@ietf.org; Mon, 03 May 2004 10:52:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKenR-0006KF-00 for simple-archive@ietf.org; Mon, 03 May 2004 10:51:54 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BKen0-0006H2-00; Mon, 03 May 2004 10:51:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKefr-0006YR-AG; Mon, 03 May 2004 10:44:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKeS4-0002Xs-Py for simple@optimus.ietf.org; Mon, 03 May 2004 10:29: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 KAA04976 for ; Mon, 3 May 2004 10:29:44 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKeS2-00059D-Hy for simple@ietf.org; Mon, 03 May 2004 10:29:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKeQw-00056Z-00 for simple@ietf.org; Mon, 03 May 2004 10:28:38 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1BKeQm-000559-00 for simple@ietf.org; Mon, 03 May 2004 10:28:28 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 03 May 2004 07:27:58 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i43ERr0S007529; Mon, 3 May 2004 07:27:55 -0700 (PDT) Received: from cisco.com ([161.44.79.59]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AIC41048; Mon, 3 May 2004 10:27:52 -0400 (EDT) Message-ID: <409656E7.8060401@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: christian-schmidt@siemens.com, rsparks@dynamicsoft.com, mikko.lonnfors@nokia.com, simple@ietf.org Subject: Re: [Simple] WGLC: partial notification References: <2038BCC78B1AD641891A0D1AE133DBB701797A0D@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 03 May 2004 10:27:51 -0400 X-Spam-Checker-Version: SpamAssassin 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: > >>If sender of a NOTIFY (notifier) does not get a 200 for it >>and Timer F fires, it terminates the subscription. What is >>the point of sending a full NOTIFY if the subscription will >>termiante anyway? >> >>Christian: >>Is it possible, to avoid this unnecessary termination of the >>subscription (caused by the loss of a single packet) by an >>additional NOTIFY? This would increase efficiency. The normal retransmission mechanisms are still in effect. If the notify or its response is lost, the notifier will retransmit it. Its only after the retransmissions have been tried to no avail that the subscription is terminated. Or am I missing something? Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon May 3 11:07:55 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07115 for ; Mon, 3 May 2004 11:07:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKevE-0003d7-C3 for simple-archive@odin.ietf.org; Mon, 03 May 2004 10:59:56 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i43ExupC013951 for simple-archive@odin.ietf.org; Mon, 3 May 2004 10:59:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKeoN-0001eH-Iu for simple-web-archive@optimus.ietf.org; Mon, 03 May 2004 10:52: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 KAA06252 for ; Mon, 3 May 2004 10:52: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 1BKeoL-0006NM-1W for simple-web-archive@ietf.org; Mon, 03 May 2004 10:52:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKenS-0006KN-00 for simple-web-archive@ietf.org; Mon, 03 May 2004 10:51:55 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BKen0-0006H2-00; Mon, 03 May 2004 10:51:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKefr-0006YR-AG; Mon, 03 May 2004 10:44:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKeS4-0002Xs-Py for simple@optimus.ietf.org; Mon, 03 May 2004 10:29: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 KAA04976 for ; Mon, 3 May 2004 10:29:44 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKeS2-00059D-Hy for simple@ietf.org; Mon, 03 May 2004 10:29:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKeQw-00056Z-00 for simple@ietf.org; Mon, 03 May 2004 10:28:38 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1BKeQm-000559-00 for simple@ietf.org; Mon, 03 May 2004 10:28:28 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 03 May 2004 07:27:58 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i43ERr0S007529; Mon, 3 May 2004 07:27:55 -0700 (PDT) Received: from cisco.com ([161.44.79.59]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AIC41048; Mon, 3 May 2004 10:27:52 -0400 (EDT) Message-ID: <409656E7.8060401@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: christian-schmidt@siemens.com, rsparks@dynamicsoft.com, mikko.lonnfors@nokia.com, simple@ietf.org Subject: Re: [Simple] WGLC: partial notification References: <2038BCC78B1AD641891A0D1AE133DBB701797A0D@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 03 May 2004 10:27:51 -0400 X-Spam-Checker-Version: SpamAssassin 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 Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > >>If sender of a NOTIFY (notifier) does not get a 200 for it >>and Timer F fires, it terminates the subscription. What is >>the point of sending a full NOTIFY if the subscription will >>termiante anyway? >> >>Christian: >>Is it possible, to avoid this unnecessary termination of the >>subscription (caused by the loss of a single packet) by an >>additional NOTIFY? This would increase efficiency. The normal retransmission mechanisms are still in effect. If the notify or its response is lost, the notifier will retransmit it. Its only after the retransmissions have been tried to no avail that the subscription is terminated. Or am I missing something? Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon May 3 13:27:43 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15129 for ; Mon, 3 May 2004 13:27:43 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKhEF-0003y9-EW for simple-archive@ietf.org; Mon, 03 May 2004 13:27:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKhDK-0003uC-00 for simple-archive@ietf.org; Mon, 03 May 2004 13:26:46 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BKhCv-0003q0-00; Mon, 03 May 2004 13:26:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKh11-0000hd-NA; Mon, 03 May 2004 13:14:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKgp6-0005g7-5o for simple@optimus.ietf.org; Mon, 03 May 2004 13:01: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 NAA13927 for ; Mon, 3 May 2004 13:01: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 1BKgp4-0001SO-Fm for simple@ietf.org; Mon, 03 May 2004 13:01:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKgo7-0001Lx-00 for simple@ietf.org; Mon, 03 May 2004 13:00:44 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BKgnD-0001AI-00 for simple@ietf.org; Mon, 03 May 2004 12:59:47 -0400 Received: from dynamicsoft.com (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.12.10/8.12.10) with ESMTP id i43GusLp019261; Mon, 3 May 2004 11:56:54 -0500 Message-ID: <40967A19.9040806@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings CC: hisham.khartabil@nokia.com, simple@ietf.org Subject: Re: [Simple] MSRP: DSN lifetime open issue References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 03 May 2004 11:58:01 -0500 X-Spam-Checker-Version: SpamAssassin 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 model is a little different here, though. None of those systems that I am aware of have anything at all like the concept of doing an SDP exchange between endpoints to initiate a message session. So, I don't expect that mid-stream messages will suddenly start going to some long-lived store and forward service (I define long-lived here to mean longer than something a normal MSRP relay does as a normal part of relaying messages). Rather, I expect that if the destination user was not available, the SIP fabric may proxy or redirect you to a message store of some kind. This is exactly analogous to a voice call being directed to a voice mail service. When this happens, the message store _is_ the destination of the message session. A DSN tells you a message has reached the message store. I think the mechanism of delivery between that store and the final recipient is out of scope. A mechanism of acknowledging final delivery would be nice, but I don't think it is the same as an in-session DSN. I know I am in the minority on the following point, but I think we have a perfectly good system for doing this now. If the SIP fabric cannot reach the final destination, it redirects you to a "mailto" URI. From that point on, delivery notification follows email methods, not message session methods. Cullen Jennings wrote: > Every real IM system I use, including SMS, supports stored messages. Seems > like a desirable property of an "Instant" messaging system. Not sure what > that means for DSN. > > > > On 4/16/04 12:22 AM, "hisham.khartabil@nokia.com" > wrote: > > >>This is a session mode instant messaging, therefore I would think that >>participants would not care about any DSNs after the session has been torn >>down. If they want the DSN, then they need to wait before tearing down the >>session. >> >>In page mode, you would need to allow the DSN to come days later. But that is >>not the issue here. >> >>I guess I'm suggesting that all outstanding DSNs are discarded. I don't think >>that the penalty that the relay has to try to send the DSN anyway is such a >>huge problem. If it is, then we probably need to send a MSRP level BYE request >>that traverses relays. >> >>/Hisham >> >> >>>-----Original Message----- >>>From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of >>>ext Ben Campbell >>>Sent: 15.April.2004 18:31 >>>To: Simple WG >>>Subject: [Simple] MSRP: DSN lifetime open issue >>> >>> >>>One open issue concerning MSRP usage of DSN that I would like >>>to close >>>on is, what happens to DSNs after a session is torn down? >>> >>>Example: >>> >>>A R B >>>SEND-------> >>><---------OK >>> SEND----X >>><---session teardown---> >>><-----REPORT >>> >>> >>>In this example, A sends a message to B via relay R. The >>>A-->R hop works >>>fine. The R->B hop failes, due to a tcp error. For the sake >>>of argument, >>>consider this to be a worst case TCP error where the TCP stack has to >>>work through the entire retransmission sequence before it >>>gives up, that >>>is, a non-trivial amount of time passes. >>> >>>A and B tear down the session. But since R is not session >>>stateful, it >>>does not know about this. >>> >>>So, the question becomes, what happens to outstanding DSN after a >>>session is closed? Do they just get dropped? (This is not as >>>simple as >>>it sounds, since if a relay is not aware of the session >>>closure, it will >>>still try to send the DSN, wasting resources.) >>> >>>Or, do we want to be able to deliver DSN outside of the scope of the >>>session in which it was generated? >>> >>>I have had several offline discussions with people, and have gotten >>>opinions that range from allowing DSN to be sent days later, >>>to assuming >>>that all outstanding DSN just get discarded. >>> >>>Thoughts? >>> >>>_______________________________________________ >>>Simple mailing list >>>Simple@ietf.org >>>https://www1.ietf.org/mailman/listinfo/simple >>> >> >>_______________________________________________ >>Simple mailing list >>Simple@ietf.org >>https://www1.ietf.org/mailman/listinfo/simple >> _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon May 3 13:42:55 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16010 for ; Mon, 3 May 2004 13:42:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKhLq-0005g4-68 for simple-archive@odin.ietf.org; Mon, 03 May 2004 13:35:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i43HZYhq021825 for simple-archive@odin.ietf.org; Mon, 3 May 2004 13:35:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKhEI-0003Uq-4t for simple-web-archive@optimus.ietf.org; Mon, 03 May 2004 13:27: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 NAA15146 for ; Mon, 3 May 2004 13:27:43 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKhEG-0003yE-4C for simple-web-archive@ietf.org; Mon, 03 May 2004 13:27:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKhDL-0003uJ-00 for simple-web-archive@ietf.org; Mon, 03 May 2004 13:26:47 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BKhCv-0003q0-00; Mon, 03 May 2004 13:26:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKh11-0000hd-NA; Mon, 03 May 2004 13:14:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKgp6-0005g7-5o for simple@optimus.ietf.org; Mon, 03 May 2004 13:01: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 NAA13927 for ; Mon, 3 May 2004 13:01: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 1BKgp4-0001SO-Fm for simple@ietf.org; Mon, 03 May 2004 13:01:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKgo7-0001Lx-00 for simple@ietf.org; Mon, 03 May 2004 13:00:44 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BKgnD-0001AI-00 for simple@ietf.org; Mon, 03 May 2004 12:59:47 -0400 Received: from dynamicsoft.com (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.12.10/8.12.10) with ESMTP id i43GusLp019261; Mon, 3 May 2004 11:56:54 -0500 Message-ID: <40967A19.9040806@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings CC: hisham.khartabil@nokia.com, simple@ietf.org Subject: Re: [Simple] MSRP: DSN lifetime open issue References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 03 May 2004 11:58:01 -0500 X-Spam-Checker-Version: SpamAssassin 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 Content-Transfer-Encoding: 7bit The model is a little different here, though. None of those systems that I am aware of have anything at all like the concept of doing an SDP exchange between endpoints to initiate a message session. So, I don't expect that mid-stream messages will suddenly start going to some long-lived store and forward service (I define long-lived here to mean longer than something a normal MSRP relay does as a normal part of relaying messages). Rather, I expect that if the destination user was not available, the SIP fabric may proxy or redirect you to a message store of some kind. This is exactly analogous to a voice call being directed to a voice mail service. When this happens, the message store _is_ the destination of the message session. A DSN tells you a message has reached the message store. I think the mechanism of delivery between that store and the final recipient is out of scope. A mechanism of acknowledging final delivery would be nice, but I don't think it is the same as an in-session DSN. I know I am in the minority on the following point, but I think we have a perfectly good system for doing this now. If the SIP fabric cannot reach the final destination, it redirects you to a "mailto" URI. From that point on, delivery notification follows email methods, not message session methods. Cullen Jennings wrote: > Every real IM system I use, including SMS, supports stored messages. Seems > like a desirable property of an "Instant" messaging system. Not sure what > that means for DSN. > > > > On 4/16/04 12:22 AM, "hisham.khartabil@nokia.com" > wrote: > > >>This is a session mode instant messaging, therefore I would think that >>participants would not care about any DSNs after the session has been torn >>down. If they want the DSN, then they need to wait before tearing down the >>session. >> >>In page mode, you would need to allow the DSN to come days later. But that is >>not the issue here. >> >>I guess I'm suggesting that all outstanding DSNs are discarded. I don't think >>that the penalty that the relay has to try to send the DSN anyway is such a >>huge problem. If it is, then we probably need to send a MSRP level BYE request >>that traverses relays. >> >>/Hisham >> >> >>>-----Original Message----- >>>From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of >>>ext Ben Campbell >>>Sent: 15.April.2004 18:31 >>>To: Simple WG >>>Subject: [Simple] MSRP: DSN lifetime open issue >>> >>> >>>One open issue concerning MSRP usage of DSN that I would like >>>to close >>>on is, what happens to DSNs after a session is torn down? >>> >>>Example: >>> >>>A R B >>>SEND-------> >>><---------OK >>> SEND----X >>><---session teardown---> >>><-----REPORT >>> >>> >>>In this example, A sends a message to B via relay R. The >>>A-->R hop works >>>fine. The R->B hop failes, due to a tcp error. For the sake >>>of argument, >>>consider this to be a worst case TCP error where the TCP stack has to >>>work through the entire retransmission sequence before it >>>gives up, that >>>is, a non-trivial amount of time passes. >>> >>>A and B tear down the session. But since R is not session >>>stateful, it >>>does not know about this. >>> >>>So, the question becomes, what happens to outstanding DSN after a >>>session is closed? Do they just get dropped? (This is not as >>>simple as >>>it sounds, since if a relay is not aware of the session >>>closure, it will >>>still try to send the DSN, wasting resources.) >>> >>>Or, do we want to be able to deliver DSN outside of the scope of the >>>session in which it was generated? >>> >>>I have had several offline discussions with people, and have gotten >>>opinions that range from allowing DSN to be sent days later, >>>to assuming >>>that all outstanding DSN just get discarded. >>> >>>Thoughts? >>> >>>_______________________________________________ >>>Simple mailing list >>>Simple@ietf.org >>>https://www1.ietf.org/mailman/listinfo/simple >>> >> >>_______________________________________________ >>Simple mailing list >>Simple@ietf.org >>https://www1.ietf.org/mailman/listinfo/simple >> _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon May 3 23:24: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 XAA20021 for ; Mon, 3 May 2004 23:24: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 1BKqXQ-0005dL-PH for simple-archive@ietf.org; Mon, 03 May 2004 23:24:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKqWU-0005UQ-00 for simple-archive@ietf.org; Mon, 03 May 2004 23:23:11 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BKqVa-0005LW-00; Mon, 03 May 2004 23:22:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKqRU-0000DD-RO; Mon, 03 May 2004 23:18:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKqNA-0007nb-9C for simple@optimus.ietf.org; Mon, 03 May 2004 23:13: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 XAA18923 for ; Mon, 3 May 2004 23:13: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 1BKqN8-0003Y7-Go for simple@ietf.org; Mon, 03 May 2004 23:13:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKqLz-0003LL-00 for simple@ietf.org; Mon, 03 May 2004 23:12:20 -0400 Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx with esmtp (Exim 4.12) id 1BKqKl-00033h-00 for simple@ietf.org; Mon, 03 May 2004 23:11:03 -0400 Received: from cs.columbia.edu (pool-138-89-96-135.mad.east.verizon.net [138.89.96.135]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i443AwZ2001611 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 3 May 2004 23:10:59 -0400 (EDT) Message-ID: <409709BD.3070509@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040421 X-Accept-Language: en-us, en, de MIME-Version: 1.0 To: Jonathan Rosenberg CC: Simple WG Subject: Re: [Simple] Update to xcap authorization rules - rpid type References: <4092A750.3080501@dynamicsoft.com> <4093E399.9030508@cs.columbia.edu> <4096374C.2040305@dynamicsoft.com> In-Reply-To: <4096374C.2040305@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 4.6.0.97784, Antispam-Core: 4.6.0.97340, Antispam-Data: 2004.5.3.99658 X-PerlMx-Spam: Gauge=XXIIIIIII, Probability=27%, Report='Y_NJABL_DUL 3, __HAS_MSGID 0, __SANE_MSGID 0, __USER_AGENT 0, X_ACCEPT_LANG 0, __MIME_VERSION 0, __TO_MALFORMED_2 0, __REFERENCES 0, __IN_REP_TO 0, __EVITE_CTYPE 0, __CT_TEXT_PLAIN 0, __CT 0, __CTE 0, __UNUSABLE_MSGID 0, EMAIL_ATTRIBUTION 0, QUOTED_EMAIL_TEXT 0, __MIME_TEXT_ONLY 0, RELAY_IN_NJABL_ORG 0, __MOZILLA_MSGID 0, REFERENCES 0.000, IN_REP_TO 0, USER_AGENT 0.000' Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 03 May 2004 23:10:53 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Trying to take a step back, maybe we need to examiane a more fundamental assumption that we have just silently made, namely whether rules logically come before or after composition. Another way of saying this is that rules could (logically) apply to tuples individually, and all allowed tuples are combined into one presence object. I haven't thought through all the implications, but it seems like this would be cleaner and avoid many of the problems discussed in this thread. I suspect it will also make rules simpler, since you don't have to specify as many conditions for all the combinations. This is independent of whether a tuple specifies a device, presentity or service, although the rules may differ a bit depending on the choice made by a user. Jonathan Rosenberg wrote: > I'm not sure how to do that. You are correct that the permissions do > define conditions, and in particular, they specify the conditions under > which a particular rpid element is included in the presence document. > For example, "include placeype in tuples where the class is "friend"". this is relatively easy for the rules-specifies-per-tuple behavior > > However, those are different conditions than what the condition element > specifies, which is, "should this permission be applied to the > processing of this subscription". As such, I don't know how to use these > conditions to specify a rule like the example above. Elements which (legitimately) can differ among tuples for the same presentity don't seem to be suitable as conditions. There are dangers of allowing such conditions: imagine where two devices publish tuples for one presentity, both using a different value for variable A. The compositor comes online and gets first one tuple from one device, then the other some minutes later from the other. By the combined rules, the subscription might fail, by per-tuple rules it would succeed - privacy-unsafe and unpredictable. > OK, fair enough - that would argue for going back to having simply a > boolean for inclusion of these elements or not. But it seems we want > more than that, no? Having some realistic use cases might help. I think a set of test cases that we can use for 'regression testing' as we try to simplify or expand things wouldn't hurt. > > Agree with that. If we can find a model whereby the conditional aspects > of this can be placed in the section, I agree its > definitely better. Let's try. It may mean that the conditions for subscriptions and inclusion can't quite be the same, for the race condition I mention above. Making subscription depend on rapidly-changing conditions is probably not such a hot idea in any event - it means that subscriptions can succeed and then fail for the same watcher and presentity minutes apart. Unless you do polite blocking, you leak information since the subscriber can 'poll' and detect that a sensitive condition has changed. ("Ah, Alice must have left work now since she's blocking my subscription attempts.") The difference between polite blocking and simply not delivering the sensitive tuple seems minor. > > Thanks, > Jonathan R. > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon May 3 23:27:41 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20372 for ; Mon, 3 May 2004 23:27:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKqYi-0001xn-Cq for simple-archive@odin.ietf.org; Mon, 03 May 2004 23:25:28 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i443PS2O007548 for simple-archive@odin.ietf.org; Mon, 3 May 2004 23:25:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKqXT-0001Y4-HL for simple-web-archive@optimus.ietf.org; Mon, 03 May 2004 23: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 XAA20039 for ; Mon, 3 May 2004 23:24: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 1BKqXR-0005dS-HJ for simple-web-archive@ietf.org; Mon, 03 May 2004 23:24:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKqWV-0005UX-00 for simple-web-archive@ietf.org; Mon, 03 May 2004 23:23:12 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BKqVa-0005LW-00; Mon, 03 May 2004 23:22:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKqRU-0000DD-RO; Mon, 03 May 2004 23:18:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKqNA-0007nb-9C for simple@optimus.ietf.org; Mon, 03 May 2004 23:13: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 XAA18923 for ; Mon, 3 May 2004 23:13: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 1BKqN8-0003Y7-Go for simple@ietf.org; Mon, 03 May 2004 23:13:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKqLz-0003LL-00 for simple@ietf.org; Mon, 03 May 2004 23:12:20 -0400 Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx with esmtp (Exim 4.12) id 1BKqKl-00033h-00 for simple@ietf.org; Mon, 03 May 2004 23:11:03 -0400 Received: from cs.columbia.edu (pool-138-89-96-135.mad.east.verizon.net [138.89.96.135]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i443AwZ2001611 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 3 May 2004 23:10:59 -0400 (EDT) Message-ID: <409709BD.3070509@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040421 X-Accept-Language: en-us, en, de MIME-Version: 1.0 To: Jonathan Rosenberg CC: Simple WG Subject: Re: [Simple] Update to xcap authorization rules - rpid type References: <4092A750.3080501@dynamicsoft.com> <4093E399.9030508@cs.columbia.edu> <4096374C.2040305@dynamicsoft.com> In-Reply-To: <4096374C.2040305@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 4.6.0.97784, Antispam-Core: 4.6.0.97340, Antispam-Data: 2004.5.3.99658 X-PerlMx-Spam: Gauge=XXIIIIIII, Probability=27%, Report='Y_NJABL_DUL 3, __HAS_MSGID 0, __SANE_MSGID 0, __USER_AGENT 0, X_ACCEPT_LANG 0, __MIME_VERSION 0, __TO_MALFORMED_2 0, __REFERENCES 0, __IN_REP_TO 0, __EVITE_CTYPE 0, __CT_TEXT_PLAIN 0, __CT 0, __CTE 0, __UNUSABLE_MSGID 0, EMAIL_ATTRIBUTION 0, QUOTED_EMAIL_TEXT 0, __MIME_TEXT_ONLY 0, RELAY_IN_NJABL_ORG 0, __MOZILLA_MSGID 0, REFERENCES 0.000, IN_REP_TO 0, USER_AGENT 0.000' Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 03 May 2004 23:10:53 -0400 X-Spam-Checker-Version: SpamAssassin 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 Content-Transfer-Encoding: 7bit Trying to take a step back, maybe we need to examiane a more fundamental assumption that we have just silently made, namely whether rules logically come before or after composition. Another way of saying this is that rules could (logically) apply to tuples individually, and all allowed tuples are combined into one presence object. I haven't thought through all the implications, but it seems like this would be cleaner and avoid many of the problems discussed in this thread. I suspect it will also make rules simpler, since you don't have to specify as many conditions for all the combinations. This is independent of whether a tuple specifies a device, presentity or service, although the rules may differ a bit depending on the choice made by a user. Jonathan Rosenberg wrote: > I'm not sure how to do that. You are correct that the permissions do > define conditions, and in particular, they specify the conditions under > which a particular rpid element is included in the presence document. > For example, "include placeype in tuples where the class is "friend"". this is relatively easy for the rules-specifies-per-tuple behavior > > However, those are different conditions than what the condition element > specifies, which is, "should this permission be applied to the > processing of this subscription". As such, I don't know how to use these > conditions to specify a rule like the example above. Elements which (legitimately) can differ among tuples for the same presentity don't seem to be suitable as conditions. There are dangers of allowing such conditions: imagine where two devices publish tuples for one presentity, both using a different value for variable A. The compositor comes online and gets first one tuple from one device, then the other some minutes later from the other. By the combined rules, the subscription might fail, by per-tuple rules it would succeed - privacy-unsafe and unpredictable. > OK, fair enough - that would argue for going back to having simply a > boolean for inclusion of these elements or not. But it seems we want > more than that, no? Having some realistic use cases might help. I think a set of test cases that we can use for 'regression testing' as we try to simplify or expand things wouldn't hurt. > > Agree with that. If we can find a model whereby the conditional aspects > of this can be placed in the section, I agree its > definitely better. Let's try. It may mean that the conditions for subscriptions and inclusion can't quite be the same, for the race condition I mention above. Making subscription depend on rapidly-changing conditions is probably not such a hot idea in any event - it means that subscriptions can succeed and then fail for the same watcher and presentity minutes apart. Unless you do polite blocking, you leak information since the subscriber can 'poll' and detect that a sensitive condition has changed. ("Ah, Alice must have left work now since she's blocking my subscription attempts.") The difference between polite blocking and simply not delivering the sensitive tuple seems minor. > > Thanks, > Jonathan R. > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue May 4 02:51: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 CAA12481 for ; Tue, 4 May 2004 02:51: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 1BKtlw-0007cQ-VD for simple-archive@ietf.org; Tue, 04 May 2004 02:51:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKtkw-0007Rd-00 for simple-archive@ietf.org; Tue, 04 May 2004 02:50:19 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BKtk6-0007IF-00; Tue, 04 May 2004 02:49:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKter-0006eX-SG; Tue, 04 May 2004 02:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKtbS-0005tL-8S for simple@optimus.ietf.org; Tue, 04 May 2004 02:40: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 CAA12097 for ; Tue, 4 May 2004 02:40: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 1BKtbO-0005jV-G9 for simple@ietf.org; Tue, 04 May 2004 02:40:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKtaY-0005Zm-00 for simple@ietf.org; Tue, 04 May 2004 02:39:34 -0400 Received: from itri.org.tw ([210.68.176.20] helo=maillog.itri.org.tw) by ietf-mx with esmtp (Exim 4.12) id 1BKta9-0005NM-00 for simple@ietf.org; Tue, 04 May 2004 02:39:10 -0400 Received: from mail.itri.org.tw (mail [140.96.157.2]) by maillog.itri.org.tw (8.11.6+Sun/8.11.6) with ESMTP id i446dkr07757 for ; Tue, 4 May 2004 14:39:46 +0800 (CST) Received: from ms2.itri.org.tw ([140.96.151.157]) by mail.itri.org.tw (8.11.6+Sun/8.11.6) with ESMTP id i446ZEo16635 for ; Tue, 4 May 2004 14:35:15 +0800 (CST) Received: from 11091017891 ([140.96.254.153]) by ms2.itri.org.tw (Lotus Domino Release 5.0.11) with ESMTP id 2004050414382582:19085 ; Tue, 4 May 2004 14:38:25 +0800 From: =?big5?B?s6+rVMx4IFwoQ2h1bi1NaW4gQ2hlblwp?= To: "'Simple WG'" Subject: [Simple] XCAP implementation MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <409709BD.3070509@cs.columbia.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Thread-Index: AcQxhvsEbxXiWyDYQRGCLLpGpwWWqAAFzoKQ X-MIMETrack: Itemize by SMTP Server on MS2/ITRI(Release 5.0.11 |July 24, 2002) at 2004-05-04 02:38:26 PM, Serialize by Router on MS2/ITRI(Release 5.0.11 |July 24, 2002) at 2004-05-04 02:38:28 PM, Serialize complete at 2004-05-04 02:38:28 PM Message-ID: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="big5" Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 4 May 2004 14:38:24 +0800 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,MISSING_OUTLOOK_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Hello, I would like to ask some questions about XCAP implementation. 1. Can XCAP be implemented with current web servers (ex. Apache or IIS)? If it can, please explains howsimply. 2. From the discussion thread "[Simple] PUT vs POST in XCAP", it seems we have to write apache modules to handle PUT, but how about GET an element from XML document? Should I write another module to handle it? Thanks for your kindly answer. Best regards, Chun-Min Chen _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue May 4 02:53:46 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12636 for ; Tue, 4 May 2004 02:53:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKtnX-0000PY-Jq for simple-archive@odin.ietf.org; Tue, 04 May 2004 02:53:00 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i446qxUw001580 for simple-archive@odin.ietf.org; Tue, 4 May 2004 02:52:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKtm2-0000BF-5S for simple-web-archive@optimus.ietf.org; Tue, 04 May 2004 02: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 CAA12499 for ; Tue, 4 May 2004 02:51: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 1BKtly-0007cd-E0 for simple-web-archive@ietf.org; Tue, 04 May 2004 02:51:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKtkx-0007Rm-00 for simple-web-archive@ietf.org; Tue, 04 May 2004 02:50:19 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BKtk6-0007IF-00; Tue, 04 May 2004 02:49:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKter-0006eX-SG; Tue, 04 May 2004 02:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKtbS-0005tL-8S for simple@optimus.ietf.org; Tue, 04 May 2004 02:40: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 CAA12097 for ; Tue, 4 May 2004 02:40: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 1BKtbO-0005jV-G9 for simple@ietf.org; Tue, 04 May 2004 02:40:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKtaY-0005Zm-00 for simple@ietf.org; Tue, 04 May 2004 02:39:34 -0400 Received: from itri.org.tw ([210.68.176.20] helo=maillog.itri.org.tw) by ietf-mx with esmtp (Exim 4.12) id 1BKta9-0005NM-00 for simple@ietf.org; Tue, 04 May 2004 02:39:10 -0400 Received: from mail.itri.org.tw (mail [140.96.157.2]) by maillog.itri.org.tw (8.11.6+Sun/8.11.6) with ESMTP id i446dkr07757 for ; Tue, 4 May 2004 14:39:46 +0800 (CST) Received: from ms2.itri.org.tw ([140.96.151.157]) by mail.itri.org.tw (8.11.6+Sun/8.11.6) with ESMTP id i446ZEo16635 for ; Tue, 4 May 2004 14:35:15 +0800 (CST) Received: from 11091017891 ([140.96.254.153]) by ms2.itri.org.tw (Lotus Domino Release 5.0.11) with ESMTP id 2004050414382582:19085 ; Tue, 4 May 2004 14:38:25 +0800 From: =?big5?B?s6+rVMx4IFwoQ2h1bi1NaW4gQ2hlblwp?= To: "'Simple WG'" Subject: [Simple] XCAP implementation MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <409709BD.3070509@cs.columbia.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Thread-Index: AcQxhvsEbxXiWyDYQRGCLLpGpwWWqAAFzoKQ X-MIMETrack: Itemize by SMTP Server on MS2/ITRI(Release 5.0.11 |July 24, 2002) at 2004-05-04 02:38:26 PM, Serialize by Router on MS2/ITRI(Release 5.0.11 |July 24, 2002) at 2004-05-04 02:38:28 PM, Serialize complete at 2004-05-04 02:38:28 PM Message-ID: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="big5" Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 4 May 2004 14:38:24 +0800 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,MISSING_OUTLOOK_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello, I would like to ask some questions about XCAP implementation. 1. Can XCAP be implemented with current web servers (ex. Apache or IIS)? If it can, please explains howsimply. 2. From the discussion thread "[Simple] PUT vs POST in XCAP", it seems we have to write apache modules to handle PUT, but how about GET an element from XML document? Should I write another module to handle it? Thanks for your kindly answer. Best regards, Chun-Min Chen _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue May 4 03:43: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 DAA14778 for ; Tue, 4 May 2004 03:43: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 1BKuaI-0001GD-D9 for simple-archive@ietf.org; Tue, 04 May 2004 03:43:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKuZF-00015K-00 for simple-archive@ietf.org; Tue, 04 May 2004 03:42:18 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BKuYG-0000pf-00; Tue, 04 May 2004 03:41:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKuUA-0001ts-OZ; Tue, 04 May 2004 03:37:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKuRi-0001Kq-4f for simple@optimus.ietf.org; Tue, 04 May 2004 03:34:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14168 for ; Tue, 4 May 2004 03:34:28 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKuRf-0007Kb-Lt for simple@ietf.org; Tue, 04 May 2004 03:34:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKuQh-0007AH-00 for simple@ietf.org; Tue, 04 May 2004 03:33:27 -0400 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1BKuQH-000708-00 for simple@ietf.org; Tue, 04 May 2004 03:33:01 -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 i447W7H12026; Tue, 4 May 2004 10:32:08 +0300 (EET DST) X-Scanned: Tue, 4 May 2004 10:32:04 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i447W4B0026657; Tue, 4 May 2004 10:32:04 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00VL6qfk; Tue, 04 May 2004 10:31: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 i447VMH16695; Tue, 4 May 2004 10:31:22 +0300 (EET DST) Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 4 May 2004 10:31: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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] WGLC on isComposing draft Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797A17@esebe019.ntc.nokia.com> Thread-Topic: [Simple] WGLC on isComposing draft Thread-Index: AcQojfBzIs5s2Jn2RMabqVHSsqsLJQJGy4cA To: , Cc: X-OriginalArrivalTime: 04 May 2004 07:31:21.0489 (UTC) FILETIME=[CBFE4810:01C431A9] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 4 May 2004 10:31:19 +0300 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 Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: 22.April.2004 20:18 > To: Paul Kyzivat > Cc: Khartabil Hisham (Nokia-TP-MSW/Helsinki); simple@ietf.org > Subject: Re: [Simple] WGLC on isComposing draft >=20 >=20 >=20 >=20 >=20 > Paul Kyzivat wrote: >=20 > > I like it. I see one new thing that I consider small: > >=20 > > - I'm a little concerned about the idle timeout being as=20 > small as 10=20 > > seconds. Personally, I am often inclined to stop and think=20 > in the middle=20 > > of composing an IM, which could trigger the idle transition fairly=20 > > often. This might generate more traffic than we might like. >=20 > I'm happy to raise it to 30 seconds. It is a configured=20 > interval, so you=20 > could have a philosopher mode that triggers messages less=20 > frequently and=20 > an ADD mode that indicates idle sooner... >=20 It is a SHOULD in the draft, so that claiming it is configurable is not = really true. I think 30 seconds is way too long. I felt 10 seconds was = more appropriate. Are you composing if you are sitting and thinking what = you want to type for more than 10 seconds? I don't know. Perhaps 15 = seconds does it. /Hisham _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue May 4 03:50:02 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15099 for ; Tue, 4 May 2004 03:50:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKuc3-0004Uw-LR for simple-archive@odin.ietf.org; Tue, 04 May 2004 03:45:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i447jBYL017284 for simple-archive@odin.ietf.org; Tue, 4 May 2004 03:45:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKuaL-0003tN-Rv for simple-web-archive@optimus.ietf.org; Tue, 04 May 2004 03:43: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 DAA14796 for ; Tue, 4 May 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 1BKuaJ-0001GQ-Id for simple-web-archive@ietf.org; Tue, 04 May 2004 03:43:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKuZG-00015S-00 for simple-web-archive@ietf.org; Tue, 04 May 2004 03:42:18 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BKuYG-0000pf-00; Tue, 04 May 2004 03:41:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKuUA-0001ts-OZ; Tue, 04 May 2004 03:37:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKuRi-0001Kq-4f for simple@optimus.ietf.org; Tue, 04 May 2004 03:34:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14168 for ; Tue, 4 May 2004 03:34:28 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKuRf-0007Kb-Lt for simple@ietf.org; Tue, 04 May 2004 03:34:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKuQh-0007AH-00 for simple@ietf.org; Tue, 04 May 2004 03:33:27 -0400 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1BKuQH-000708-00 for simple@ietf.org; Tue, 04 May 2004 03:33:01 -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 i447W7H12026; Tue, 4 May 2004 10:32:08 +0300 (EET DST) X-Scanned: Tue, 4 May 2004 10:32:04 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i447W4B0026657; Tue, 4 May 2004 10:32:04 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00VL6qfk; Tue, 04 May 2004 10:31: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 i447VMH16695; Tue, 4 May 2004 10:31:22 +0300 (EET DST) Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 4 May 2004 10:31: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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] WGLC on isComposing draft Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797A17@esebe019.ntc.nokia.com> Thread-Topic: [Simple] WGLC on isComposing draft Thread-Index: AcQojfBzIs5s2Jn2RMabqVHSsqsLJQJGy4cA To: , Cc: X-OriginalArrivalTime: 04 May 2004 07:31:21.0489 (UTC) FILETIME=[CBFE4810:01C431A9] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 4 May 2004 10:31:19 +0300 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 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: 22.April.2004 20:18 > To: Paul Kyzivat > Cc: Khartabil Hisham (Nokia-TP-MSW/Helsinki); simple@ietf.org > Subject: Re: [Simple] WGLC on isComposing draft >=20 >=20 >=20 >=20 >=20 > Paul Kyzivat wrote: >=20 > > I like it. I see one new thing that I consider small: > >=20 > > - I'm a little concerned about the idle timeout being as=20 > small as 10=20 > > seconds. Personally, I am often inclined to stop and think=20 > in the middle=20 > > of composing an IM, which could trigger the idle transition fairly=20 > > often. This might generate more traffic than we might like. >=20 > I'm happy to raise it to 30 seconds. It is a configured=20 > interval, so you=20 > could have a philosopher mode that triggers messages less=20 > frequently and=20 > an ADD mode that indicates idle sooner... >=20 It is a SHOULD in the draft, so that claiming it is configurable is not = really true. I think 30 seconds is way too long. I felt 10 seconds was = more appropriate. Are you composing if you are sitting and thinking what = you want to type for more than 10 seconds? I don't know. Perhaps 15 = seconds does it. /Hisham _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue May 4 04:17: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 EAA16490 for ; Tue, 4 May 2004 04:17:22 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKv7C-0000Dr-B0 for simple-archive@ietf.org; Tue, 04 May 2004 04:17:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKv6E-00000w-00 for simple-archive@ietf.org; Tue, 04 May 2004 04:16:22 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BKv5D-0007cl-00; Tue, 04 May 2004 04:15:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKuvK-0000fS-PX; Tue, 04 May 2004 04:05:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKust-00007p-EA for simple@optimus.ietf.org; Tue, 04 May 2004 04:02: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 EAA15911 for ; Tue, 4 May 2004 04:02:33 -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 1BKusq-0005GB-Oz for simple@ietf.org; Tue, 04 May 2004 04:02:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKus8-00054x-00 for simple@ietf.org; Tue, 04 May 2004 04:01:49 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1BKurT-0004sE-00 for simple@ietf.org; Tue, 04 May 2004 04:01:07 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i44810J28903 for ; Tue, 4 May 2004 11:01:00 +0300 (EET DST) X-Scanned: Tue, 4 May 2004 11:01:04 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i44814P0014205 for ; Tue, 4 May 2004 11:01:04 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00Y6tRAp; Tue, 04 May 2004 11:01:03 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 i44813H05667 for ; Tue, 4 May 2004 11:01: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); Tue, 4 May 2004 11:01:03 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] WGLC on RPID, CIPID and future status Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797A1C@esebe019.ntc.nokia.com> Thread-Topic: WGLC on RPID, CIPID and future status Thread-Index: AcQs7nuIRm2/mALrSE+wzKo/hIbYJgEvtk+A To: X-OriginalArrivalTime: 04 May 2004 08:01:03.0160 (UTC) FILETIME=[F1F3B380:01C431AD] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 4 May 2004 11:01:03 +0300 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 It has been a week since we announced the WGLC, but no comments have = been made. The working group chairs and the editor would really = appreciate reviews and comments, including nits if you have any. We = cannot finish this work and pass to IESG if it does not receive enough = attention from the working group. If you reviewed the drafts and had no comments, please indicate so. Thanks, Hisham > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > ext hisham.khartabil@nokia.com > Sent: 28.April.2004 10:00 > To: simple@ietf.org > Subject: [Simple] WGLC on RPID, CIPID and future status >=20 >=20 > The WG chairs would like to start a Working Group Last Call=20 > on the following drafts as part of the SIMPLE PIDF profile to=20 > be submitted to IESG: >=20 > http://www.ietf.org/internet-drafts/draft-ietf-simple-rpid-03.txt > http://www.ietf.org/internet-drafts/draft-ietf-simple-cipid-01.txt > http://www.ietf.org/internet-drafts/draft-ietf-simple-future-01.txt >=20 > This WGLC will end on May 11th. >=20 > Please send your comments to this mailing list and to the authors.=20 >=20 > If you reviewed the draft and found no issues, please=20 > indicate so on the mailing list. This will help us evaluate=20 > the level of review and group consensus. >=20 > Thanks, > Hisham >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue May 4 04:19:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16593 for ; Tue, 4 May 2004 04:19:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKv8A-0003vh-5g for simple-archive@odin.ietf.org; Tue, 04 May 2004 04:18:22 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i448IMZf015106 for simple-archive@odin.ietf.org; Tue, 4 May 2004 04:18:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKv7F-0003dT-Ji for simple-web-archive@optimus.ietf.org; Tue, 04 May 2004 04:17:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16508 for ; Tue, 4 May 2004 04:17: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 1BKv7C-0000Dw-VN for simple-web-archive@ietf.org; Tue, 04 May 2004 04:17:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKv6F-000014-00 for simple-web-archive@ietf.org; Tue, 04 May 2004 04:16:23 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BKv5D-0007cl-00; Tue, 04 May 2004 04:15:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKuvK-0000fS-PX; Tue, 04 May 2004 04:05:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKust-00007p-EA for simple@optimus.ietf.org; Tue, 04 May 2004 04:02: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 EAA15911 for ; Tue, 4 May 2004 04:02:33 -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 1BKusq-0005GB-Oz for simple@ietf.org; Tue, 04 May 2004 04:02:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKus8-00054x-00 for simple@ietf.org; Tue, 04 May 2004 04:01:49 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1BKurT-0004sE-00 for simple@ietf.org; Tue, 04 May 2004 04:01:07 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i44810J28903 for ; Tue, 4 May 2004 11:01:00 +0300 (EET DST) X-Scanned: Tue, 4 May 2004 11:01:04 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i44814P0014205 for ; Tue, 4 May 2004 11:01:04 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00Y6tRAp; Tue, 04 May 2004 11:01:03 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 i44813H05667 for ; Tue, 4 May 2004 11:01: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); Tue, 4 May 2004 11:01:03 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] WGLC on RPID, CIPID and future status Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797A1C@esebe019.ntc.nokia.com> Thread-Topic: WGLC on RPID, CIPID and future status Thread-Index: AcQs7nuIRm2/mALrSE+wzKo/hIbYJgEvtk+A To: X-OriginalArrivalTime: 04 May 2004 08:01:03.0160 (UTC) FILETIME=[F1F3B380:01C431AD] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 4 May 2004 11:01:03 +0300 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 Content-Transfer-Encoding: quoted-printable It has been a week since we announced the WGLC, but no comments have = been made. The working group chairs and the editor would really = appreciate reviews and comments, including nits if you have any. We = cannot finish this work and pass to IESG if it does not receive enough = attention from the working group. If you reviewed the drafts and had no comments, please indicate so. Thanks, Hisham > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > ext hisham.khartabil@nokia.com > Sent: 28.April.2004 10:00 > To: simple@ietf.org > Subject: [Simple] WGLC on RPID, CIPID and future status >=20 >=20 > The WG chairs would like to start a Working Group Last Call=20 > on the following drafts as part of the SIMPLE PIDF profile to=20 > be submitted to IESG: >=20 > http://www.ietf.org/internet-drafts/draft-ietf-simple-rpid-03.txt > http://www.ietf.org/internet-drafts/draft-ietf-simple-cipid-01.txt > http://www.ietf.org/internet-drafts/draft-ietf-simple-future-01.txt >=20 > This WGLC will end on May 11th. >=20 > Please send your comments to this mailing list and to the authors.=20 >=20 > If you reviewed the draft and found no issues, please=20 > indicate so on the mailing list. This will help us evaluate=20 > the level of review and group consensus. >=20 > Thanks, > Hisham >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue May 4 06:59: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 GAA22519 for ; Tue, 4 May 2004 06:59:41 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKxeI-0000Iw-EO for simple-archive@ietf.org; Tue, 04 May 2004 06:59:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKxbz-0007Pt-00 for simple-archive@ietf.org; Tue, 04 May 2004 06:57:20 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BKxaR-00072l-02; Tue, 04 May 2004 06:55:43 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BKxVX-00050b-1f; Tue, 04 May 2004 06:50:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKxIj-0000Wr-0f; Tue, 04 May 2004 06:37:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKw5F-00084u-T0 for simple@optimus.ietf.org; Tue, 04 May 2004 05:19: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 FAA18351 for ; Tue, 4 May 2004 05:19:22 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKw5C-0003mu-Fr for simple@ietf.org; Tue, 04 May 2004 05:19:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKw4D-0003c8-00 for simple@ietf.org; Tue, 04 May 2004 05:18:22 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BKw3B-0003HP-00 for simple@ietf.org; Tue, 04 May 2004 05:17:17 -0400 Received: from dynamicsoft.com ([63.113.46.11]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i449G5us024323; Tue, 4 May 2004 05:16:06 -0400 (EDT) Message-ID: <40975F3C.9090704@dynamicsoft.com> 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 CC: Simple WG Subject: Re: [Simple] Update to xcap authorization rules - rpid type References: <4092A750.3080501@dynamicsoft.com> <4093E399.9030508@cs.columbia.edu> <4096374C.2040305@dynamicsoft.com> <409709BD.3070509@cs.columbia.edu> In-Reply-To: <409709BD.3070509@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 04 May 2004 05:15:40 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > Trying to take a step back, maybe we need to examiane a more fundamental > assumption that we have just silently made, namely whether rules > logically come before or after composition. Another way of saying this > is that rules could (logically) apply to tuples individually, and all > allowed tuples are combined into one presence object. I agree that we definitely need to examine this fundamental model assumption. I've been thinking along similar lines, and in fact just posted on the two models. > > I haven't thought through all the implications, but it seems like this > would be cleaner and avoid many of the problems discussed in this > thread. I suspect it will also make rules simpler, since you don't have > to specify as many conditions for all the combinations. I'm not sure. I can't really see how this would work. I keep bumping into this same wall, which is that specify, when a subscription arrives, the set of permissions (in terms of transformations and actions) to apply. That is quite different from using conditions to determine to which tuples a permission applies. Another point. The model I had implicitly in mind (which I called model I in my other note), is that the presence server builds up an uber presence document with everything in it, and then permissions determine who sees what. That seems, to me, to be a much closer match conceptually to the privacy model we and geopriv are using - that there is some core information to which access is being granted. Thats quite different from view authorization policy as a set of guidelines that define how composition works; it was far from obvious to me how our privacy rules would work in such a case. Its no longer about giving access to information, its about guiding composition. How do you define privacy orders? > > This is independent of whether a tuple specifies a device, presentity or > service, although the rules may differ a bit depending on the choice > made by a user. > > Jonathan Rosenberg wrote: > > >> I'm not sure how to do that. You are correct that the permissions do >> define conditions, and in particular, they specify the conditions >> under which a particular rpid element is included in the presence >> document. For example, "include placeype in tuples where the class is >> "friend"". > > > this is relatively easy for the rules-specifies-per-tuple behavior Can you provide a concerete description of how it would work? > > >> >> However, those are different conditions than what the condition >> element specifies, which is, "should this permission be applied to the >> processing of this subscription". As such, I don't know how to use >> these conditions to specify a rule like the example above. > > > Elements which (legitimately) can differ among tuples for the same > presentity don't seem to be suitable as conditions. There are dangers of > allowing such conditions: imagine where two devices publish tuples for > one presentity, both using a different value for variable A. The > compositor comes online and gets first one tuple from one device, then > the other some minutes later from the other. By the combined rules, the > subscription might fail, by per-tuple rules it would succeed - > privacy-unsafe and unpredictable. Perhaps I am misunderstanding, but it sounds like you are arguing against having conditions that are based on presence values? > > > >> OK, fair enough - that would argue for going back to having simply a >> boolean for inclusion of these elements or not. But it seems we want >> more than that, no? > > > Having some realistic use cases might help. I think a set of test cases > that we can use for 'regression testing' as we try to simplify or expand > things wouldn't hurt. What I had in mind for this were cases where you anticipated that the data was more sensitive for one type of tuple than another. FOr example, assuming a device view, I might want to allow people to see placetype for my fixed work phone (its always "work"), but not see it for my mobile (where its value depends on my geographic location). I'll try and think of more use cases; it may well be that there isnt anything particularly pressing that motivates this need. I definitely think we need to be able to provide specific tuples based on presence attribute values - thats needed for any basic system with lying, for example. > > >> >> Agree with that. If we can find a model whereby the conditional >> aspects of this can be placed in the section, I agree its >> definitely better. > > > Let's try. It may mean that the conditions for subscriptions and > inclusion can't quite be the same, for the race condition I mention > above. OK, so now I'm really confused about what you had in mind... > Making subscription depend on rapidly-changing conditions is > probably not such a hot idea in any event - it means that subscriptions > can succeed and then fail for the same watcher and presentity minutes > apart. Don't you already have this problem with the condition? > Unless you do polite blocking, you leak information since the > subscriber can 'poll' and detect that a sensitive condition has changed. > ("Ah, Alice must have left work now since she's blocking my subscription > attempts.") Yup. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue May 4 06:59:57 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22622 for ; Tue, 4 May 2004 06:59:57 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKxeY-0000Kx-6N for simple-archive@ietf.org; Tue, 04 May 2004 06:59:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKxcH-0007UR-00 for simple-archive@ietf.org; Tue, 04 May 2004 06:57:37 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BKxaR-00073e-01; Tue, 04 May 2004 06:55:43 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BKxVn-00050k-5j; Tue, 04 May 2004 06:50:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKxIj-0000XF-Ic; Tue, 04 May 2004 06:37:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKw6I-0008KZ-Ia for simple@optimus.ietf.org; Tue, 04 May 2004 05:20:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18378 for ; Tue, 4 May 2004 05:20: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 1BKw6E-0003xz-RS for simple@ietf.org; Tue, 04 May 2004 05:20:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKw5G-0003nW-00 for simple@ietf.org; Tue, 04 May 2004 05:19:26 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1BKw4x-0003d6-00 for simple@ietf.org; Tue, 04 May 2004 05:19:08 -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 i449INk07225; Tue, 4 May 2004 12:18:23 +0300 (EET DST) X-Scanned: Tue, 4 May 2004 12:18:15 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i449IF6C024614; Tue, 4 May 2004 12:18:15 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00qprRg1; Tue, 04 May 2004 12:18:12 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 i449HpH08331; Tue, 4 May 2004 12:17:51 +0300 (EET DST) Subject: Re: [Simple] XCAP implementation From: Jari Urpalainen To: ext =?UTF-8?Q?=E9=99=B3=E4=BF=8A?= =?UTF-8?Q?=E5=BF=9E?= "\\(Chun-Min Chen\\)" Cc: "'Simple WG'" In-Reply-To: References: Content-Type: text/plain; charset=UTF-8 Message-Id: <1083662269.20325.27.camel@xitami.research.nokia.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mgw-int1.ntc.nokia.com id i449HpH08331 Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 04 May 2004 12:17:49 +0300 X-Spam-Checker-Version: SpamAssassin 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 On Tue, 2004-05-04 at 09:38, ext =E9=99=B3=E4=BF=8A=E5=BF=9E \(Chun-Min C= hen\) wrote: > Hello, >=20 > I would like to ask some questions about XCAP implementation. >=20 > 1. Can XCAP be implemented with current web servers (ex. Apache or IIS)= ? If > it can, please explains howsimply. >=20 > 2. From the discussion thread "[Simple] PUT vs POST in XCAP", it seems= we > have to write apache modules to handle PUT, but how about GET an elemen= t > from XML document? Should I write another module to handle it? >=20 > Thanks for your kindly answer. > Best regards, > Chun-Min Chen >=20 I have written an Apache module to handle XCAP requests. This module will handle all methods, currently GET, PUT and DELETE. It is fairly easy to get the header information and payload from Apache and then return within xcap-module the requested payload. This "glue" code for Apache is fairly simple to implement. However, as Apache usually acts as a multiprocess and multithreaded engine some resource locking is required when several requests for the same resource are handled at the same time. That may not be so trivial. Furthermore, subscription handling for events requires also a sip-stack and some tweaking between them is needed as well.=20 The XML and XPATH manipulations are otherwise straightforward but especially default namespace handling needs careful coding. There are still quite a lot of other issues as well, but hopefully this helps somewhat. BR, Jari _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue May 4 07:00:30 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22759 for ; Tue, 4 May 2004 07: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 1BKxf4-0000VO-Ft for simple-archive@ietf.org; Tue, 04 May 2004 07:00:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKxck-0007c4-00 for simple-archive@ietf.org; Tue, 04 May 2004 06:58:07 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BKxaT-00072w-00; Tue, 04 May 2004 06:55:45 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BKxRQ-0004w0-Cv; Tue, 04 May 2004 06:46:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKxIZ-0000QC-LO; Tue, 04 May 2004 06:37:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKvjz-00047u-Gx for simple@optimus.ietf.org; Tue, 04 May 2004 04:57: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 EAA17902 for ; Tue, 4 May 2004 04:57: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 1BKvjw-0007ic-9j for simple@ietf.org; Tue, 04 May 2004 04:57:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKvj0-0007YE-00 for simple@ietf.org; Tue, 04 May 2004 04:56:27 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BKvic-0007Ne-00 for simple@ietf.org; Tue, 04 May 2004 04:56:02 -0400 Received: from dynamicsoft.com ([63.113.46.11]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i448tous024303 for ; Tue, 4 May 2004 04:55:52 -0400 (EDT) Message-ID: <40975A80.5070409@dynamicsoft.com> 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] Presence Rules Issue 3: Specifying views Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 04 May 2004 04:55:28 -0400 X-Spam-Checker-Version: SpamAssassin 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 the previous version of the draft, there was a permission that allowed the presentity to say something about the view created by the presence server - presentity view, service view, watcher view. There were a bunch of problems with this. One of them was that there really isnt a strict privacy ordering amongst these choices. Second was that the meaning of constructing these views is still sufficiently ill-defined that it was hard to figure out what it might mean. Indeed, there's a reasonable question about whether it even makes sense to include directions on how composition is done as part of the auhtorization policies. It depends on the model that the system is operating under. In one model, the presence server collects presence data from various sources, composes it together, and creates an uber-presence doc that has everything in it. Once that is done, *then* the authorization policy is applied, reducing information sent to any particular watcher. Call this model I. In another model, however, the authorization policies themselves effectively guide the composition process, and instruct the presence server how to create the presence document from the raw data for each particular watcher. Call this model II. In model I, its clear that it would be out of scope for the authorization documents to say anything about how the presence document is composed. Perhaps some other xcap document could define that, but it would be presence-rules, and its unlikely that such a policy statement would fit under the scope of common-policy. In model II, its not so; one could argue that you can always represent, in some way, composition as an algorithm that can operate with increasing levels of data presented to watchers, and therefore could be controlled within the context of our privacy framework. I'm inclined to go for model I, and if others agree, explicitly describe that in the document. Assuming this is the case, we still have some issues. Lets say the presence server computes a document with two tuples, both specifying a phone. One specifies a work phone, the other, a home phone. For both, the presence server generates the uber-document with only the basic status and the rpid element. If the user sets the authorization policy such that placetype is not provided, the resulting presence document makes little sense; it would present two tuples that don't give any context about *why* there are two - that context has been removed by the presence authorization policies. As a result, I think it makes sense to further specify that, after the authorization policies are applied, the presence server looks at the remaining tuples. If it turns out that two tuples no longer differ in any way except basic or contact URI (assuming the same scheme), that they be merged together into a single tuple by the presence server before distribution. This might require the presence server to place a different contact into the merged tuple. The merged basic status would be computed with an OR operation (i.e., open as long as any are open). That's kind of neat, since it does allow for some amount of control over views. If you don't want to reveal inforamtion about your various devices to a watcher, then tell the presence server to remove the contact type and the prescaps information which would be needed to specify exactly that to the watcher. ANother nice artifact of this is that, if you don't specify any permissions except allow/deny for the overall subscription, the resulting presence document would always end up having no more than one tuple for any particular contact URI scheme. If you had a way to specify that only tuples with particular URI schemes were to be included in a document, that would give the presentity the ability to, virtually independently of the composition process used by the presence server, cause the server to spit out a bare bones presence doc. So, this got me thinking further. The combination of tuples when they don't differ, as I propose above, might be more controllable. We could specify permissions that indicate that, if two tuples differ by presence attribute X, then the presence server still do the merging operation, but it combines the differing values in some way that would be defined on an attribute-by-attribute basis, possibly including dropping of that attribute. In other words, rather than try to specify composition in terms of types of views, it effectively gets specified by defining which presence attributes get combined together, and which don't. So, some specific questions to ask the group: (1) do you think we should be following model I or model II [I vote for I] (2) should we add a permission that grants access to tuples based on contact URI scheme [I vote for yes] (3) should we specify that, if authorization policies remove data which results in two tuples being the same, they be combined [I vote for yes] (4) should we define additional permissions that specify that certain presence attributes should be aggregated together in a tuple-combining process [not sure] Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue May 4 07:12:24 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23859 for ; Tue, 4 May 2004 07:12:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKxjY-0008Fa-RM for simple-archive@odin.ietf.org; Tue, 04 May 2004 07:05:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i44B5894031703 for simple-archive@odin.ietf.org; Tue, 4 May 2004 07:05:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKxeM-0006hr-Rd for simple-web-archive@optimus.ietf.org; Tue, 04 May 2004 06:59: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 GAA22520 for ; Tue, 4 May 2004 06:59: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 1BKxeI-0000J2-FM for simple-web-archive@ietf.org; Tue, 04 May 2004 06:59:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKxc0-0007Q0-00 for simple-web-archive@ietf.org; Tue, 04 May 2004 06:57:21 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BKxaR-00072l-02; Tue, 04 May 2004 06:55:43 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BKxVX-00050b-1f; Tue, 04 May 2004 06:50:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKxIj-0000Wr-0f; Tue, 04 May 2004 06:37:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKw5F-00084u-T0 for simple@optimus.ietf.org; Tue, 04 May 2004 05:19: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 FAA18351 for ; Tue, 4 May 2004 05:19:22 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKw5C-0003mu-Fr for simple@ietf.org; Tue, 04 May 2004 05:19:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKw4D-0003c8-00 for simple@ietf.org; Tue, 04 May 2004 05:18:22 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BKw3B-0003HP-00 for simple@ietf.org; Tue, 04 May 2004 05:17:17 -0400 Received: from dynamicsoft.com ([63.113.46.11]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i449G5us024323; Tue, 4 May 2004 05:16:06 -0400 (EDT) Message-ID: <40975F3C.9090704@dynamicsoft.com> 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 CC: Simple WG Subject: Re: [Simple] Update to xcap authorization rules - rpid type References: <4092A750.3080501@dynamicsoft.com> <4093E399.9030508@cs.columbia.edu> <4096374C.2040305@dynamicsoft.com> <409709BD.3070509@cs.columbia.edu> In-Reply-To: <409709BD.3070509@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 04 May 2004 05:15:40 -0400 X-Spam-Checker-Version: SpamAssassin 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 Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > Trying to take a step back, maybe we need to examiane a more fundamental > assumption that we have just silently made, namely whether rules > logically come before or after composition. Another way of saying this > is that rules could (logically) apply to tuples individually, and all > allowed tuples are combined into one presence object. I agree that we definitely need to examine this fundamental model assumption. I've been thinking along similar lines, and in fact just posted on the two models. > > I haven't thought through all the implications, but it seems like this > would be cleaner and avoid many of the problems discussed in this > thread. I suspect it will also make rules simpler, since you don't have > to specify as many conditions for all the combinations. I'm not sure. I can't really see how this would work. I keep bumping into this same wall, which is that specify, when a subscription arrives, the set of permissions (in terms of transformations and actions) to apply. That is quite different from using conditions to determine to which tuples a permission applies. Another point. The model I had implicitly in mind (which I called model I in my other note), is that the presence server builds up an uber presence document with everything in it, and then permissions determine who sees what. That seems, to me, to be a much closer match conceptually to the privacy model we and geopriv are using - that there is some core information to which access is being granted. Thats quite different from view authorization policy as a set of guidelines that define how composition works; it was far from obvious to me how our privacy rules would work in such a case. Its no longer about giving access to information, its about guiding composition. How do you define privacy orders? > > This is independent of whether a tuple specifies a device, presentity or > service, although the rules may differ a bit depending on the choice > made by a user. > > Jonathan Rosenberg wrote: > > >> I'm not sure how to do that. You are correct that the permissions do >> define conditions, and in particular, they specify the conditions >> under which a particular rpid element is included in the presence >> document. For example, "include placeype in tuples where the class is >> "friend"". > > > this is relatively easy for the rules-specifies-per-tuple behavior Can you provide a concerete description of how it would work? > > >> >> However, those are different conditions than what the condition >> element specifies, which is, "should this permission be applied to the >> processing of this subscription". As such, I don't know how to use >> these conditions to specify a rule like the example above. > > > Elements which (legitimately) can differ among tuples for the same > presentity don't seem to be suitable as conditions. There are dangers of > allowing such conditions: imagine where two devices publish tuples for > one presentity, both using a different value for variable A. The > compositor comes online and gets first one tuple from one device, then > the other some minutes later from the other. By the combined rules, the > subscription might fail, by per-tuple rules it would succeed - > privacy-unsafe and unpredictable. Perhaps I am misunderstanding, but it sounds like you are arguing against having conditions that are based on presence values? > > > >> OK, fair enough - that would argue for going back to having simply a >> boolean for inclusion of these elements or not. But it seems we want >> more than that, no? > > > Having some realistic use cases might help. I think a set of test cases > that we can use for 'regression testing' as we try to simplify or expand > things wouldn't hurt. What I had in mind for this were cases where you anticipated that the data was more sensitive for one type of tuple than another. FOr example, assuming a device view, I might want to allow people to see placetype for my fixed work phone (its always "work"), but not see it for my mobile (where its value depends on my geographic location). I'll try and think of more use cases; it may well be that there isnt anything particularly pressing that motivates this need. I definitely think we need to be able to provide specific tuples based on presence attribute values - thats needed for any basic system with lying, for example. > > >> >> Agree with that. If we can find a model whereby the conditional >> aspects of this can be placed in the section, I agree its >> definitely better. > > > Let's try. It may mean that the conditions for subscriptions and > inclusion can't quite be the same, for the race condition I mention > above. OK, so now I'm really confused about what you had in mind... > Making subscription depend on rapidly-changing conditions is > probably not such a hot idea in any event - it means that subscriptions > can succeed and then fail for the same watcher and presentity minutes > apart. Don't you already have this problem with the condition? > Unless you do polite blocking, you leak information since the > subscriber can 'poll' and detect that a sensitive condition has changed. > ("Ah, Alice must have left work now since she's blocking my subscription > attempts.") Yup. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue May 4 07:12:54 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23890 for ; Tue, 4 May 2004 07:12:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKxja-0008HD-DT for simple-archive@odin.ietf.org; Tue, 04 May 2004 07:05:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i44B5Am8031811 for simple-archive@odin.ietf.org; Tue, 4 May 2004 07:05:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKxed-0006jE-Ls for simple-web-archive@optimus.ietf.org; Tue, 04 May 2004 07:00: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 GAA22640 for ; Tue, 4 May 2004 06:59: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 1BKxeZ-0000LA-Ic for simple-web-archive@ietf.org; Tue, 04 May 2004 06:59:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKxcI-0007Ue-00 for simple-web-archive@ietf.org; Tue, 04 May 2004 06:57:38 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BKxaR-00073e-01; Tue, 04 May 2004 06:55:43 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BKxVn-00050k-5j; Tue, 04 May 2004 06:50:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKxIj-0000XF-Ic; Tue, 04 May 2004 06:37:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKw6I-0008KZ-Ia for simple@optimus.ietf.org; Tue, 04 May 2004 05:20:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18378 for ; Tue, 4 May 2004 05:20: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 1BKw6E-0003xz-RS for simple@ietf.org; Tue, 04 May 2004 05:20:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKw5G-0003nW-00 for simple@ietf.org; Tue, 04 May 2004 05:19:26 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1BKw4x-0003d6-00 for simple@ietf.org; Tue, 04 May 2004 05:19:08 -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 i449INk07225; Tue, 4 May 2004 12:18:23 +0300 (EET DST) X-Scanned: Tue, 4 May 2004 12:18:15 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i449IF6C024614; Tue, 4 May 2004 12:18:15 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00qprRg1; Tue, 04 May 2004 12:18:12 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 i449HpH08331; Tue, 4 May 2004 12:17:51 +0300 (EET DST) Subject: Re: [Simple] XCAP implementation From: Jari Urpalainen To: ext =?UTF-8?Q?=E9=99=B3=E4=BF=8A?= =?UTF-8?Q?=E5=BF=9E?= "\\(Chun-Min Chen\\)" Cc: "'Simple WG'" In-Reply-To: References: Content-Type: text/plain; charset=UTF-8 Message-Id: <1083662269.20325.27.camel@xitami.research.nokia.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mgw-int1.ntc.nokia.com id i449HpH08331 Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 04 May 2004 12:17:49 +0300 X-Spam-Checker-Version: SpamAssassin 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 Content-Transfer-Encoding: quoted-printable On Tue, 2004-05-04 at 09:38, ext =E9=99=B3=E4=BF=8A=E5=BF=9E \(Chun-Min C= hen\) wrote: > Hello, >=20 > I would like to ask some questions about XCAP implementation. >=20 > 1. Can XCAP be implemented with current web servers (ex. Apache or IIS)= ? If > it can, please explains howsimply. >=20 > 2. From the discussion thread "[Simple] PUT vs POST in XCAP", it seems= we > have to write apache modules to handle PUT, but how about GET an elemen= t > from XML document? Should I write another module to handle it? >=20 > Thanks for your kindly answer. > Best regards, > Chun-Min Chen >=20 I have written an Apache module to handle XCAP requests. This module will handle all methods, currently GET, PUT and DELETE. It is fairly easy to get the header information and payload from Apache and then return within xcap-module the requested payload. This "glue" code for Apache is fairly simple to implement. However, as Apache usually acts as a multiprocess and multithreaded engine some resource locking is required when several requests for the same resource are handled at the same time. That may not be so trivial. Furthermore, subscription handling for events requires also a sip-stack and some tweaking between them is needed as well.=20 The XML and XPATH manipulations are otherwise straightforward but especially default namespace handling needs careful coding. There are still quite a lot of other issues as well, but hopefully this helps somewhat. BR, Jari _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue May 4 07:13:40 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23990 for ; Tue, 4 May 2004 07:13:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKxjd-0008JH-5s for simple-archive@odin.ietf.org; Tue, 04 May 2004 07:05:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i44B5DX0031939 for simple-archive@odin.ietf.org; Tue, 4 May 2004 07:05:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKxf9-0006uo-Dd for simple-web-archive@optimus.ietf.org; Tue, 04 May 2004 07:00: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 HAA22777 for ; Tue, 4 May 2004 07: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 1BKxf5-0000W3-6t for simple-web-archive@ietf.org; Tue, 04 May 2004 07:00:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKxcl-0007cJ-00 for simple-web-archive@ietf.org; Tue, 04 May 2004 06:58:08 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BKxaT-00072w-00; Tue, 04 May 2004 06:55:45 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BKxRQ-0004w0-Cv; Tue, 04 May 2004 06:46:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKxIZ-0000QC-LO; Tue, 04 May 2004 06:37:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKvjz-00047u-Gx for simple@optimus.ietf.org; Tue, 04 May 2004 04:57: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 EAA17902 for ; Tue, 4 May 2004 04:57: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 1BKvjw-0007ic-9j for simple@ietf.org; Tue, 04 May 2004 04:57:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKvj0-0007YE-00 for simple@ietf.org; Tue, 04 May 2004 04:56:27 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BKvic-0007Ne-00 for simple@ietf.org; Tue, 04 May 2004 04:56:02 -0400 Received: from dynamicsoft.com ([63.113.46.11]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i448tous024303 for ; Tue, 4 May 2004 04:55:52 -0400 (EDT) Message-ID: <40975A80.5070409@dynamicsoft.com> 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] Presence Rules Issue 3: Specifying views Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 04 May 2004 04:55:28 -0400 X-Spam-Checker-Version: SpamAssassin 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 Content-Transfer-Encoding: 7bit In the previous version of the draft, there was a permission that allowed the presentity to say something about the view created by the presence server - presentity view, service view, watcher view. There were a bunch of problems with this. One of them was that there really isnt a strict privacy ordering amongst these choices. Second was that the meaning of constructing these views is still sufficiently ill-defined that it was hard to figure out what it might mean. Indeed, there's a reasonable question about whether it even makes sense to include directions on how composition is done as part of the auhtorization policies. It depends on the model that the system is operating under. In one model, the presence server collects presence data from various sources, composes it together, and creates an uber-presence doc that has everything in it. Once that is done, *then* the authorization policy is applied, reducing information sent to any particular watcher. Call this model I. In another model, however, the authorization policies themselves effectively guide the composition process, and instruct the presence server how to create the presence document from the raw data for each particular watcher. Call this model II. In model I, its clear that it would be out of scope for the authorization documents to say anything about how the presence document is composed. Perhaps some other xcap document could define that, but it would be presence-rules, and its unlikely that such a policy statement would fit under the scope of common-policy. In model II, its not so; one could argue that you can always represent, in some way, composition as an algorithm that can operate with increasing levels of data presented to watchers, and therefore could be controlled within the context of our privacy framework. I'm inclined to go for model I, and if others agree, explicitly describe that in the document. Assuming this is the case, we still have some issues. Lets say the presence server computes a document with two tuples, both specifying a phone. One specifies a work phone, the other, a home phone. For both, the presence server generates the uber-document with only the basic status and the rpid element. If the user sets the authorization policy such that placetype is not provided, the resulting presence document makes little sense; it would present two tuples that don't give any context about *why* there are two - that context has been removed by the presence authorization policies. As a result, I think it makes sense to further specify that, after the authorization policies are applied, the presence server looks at the remaining tuples. If it turns out that two tuples no longer differ in any way except basic or contact URI (assuming the same scheme), that they be merged together into a single tuple by the presence server before distribution. This might require the presence server to place a different contact into the merged tuple. The merged basic status would be computed with an OR operation (i.e., open as long as any are open). That's kind of neat, since it does allow for some amount of control over views. If you don't want to reveal inforamtion about your various devices to a watcher, then tell the presence server to remove the contact type and the prescaps information which would be needed to specify exactly that to the watcher. ANother nice artifact of this is that, if you don't specify any permissions except allow/deny for the overall subscription, the resulting presence document would always end up having no more than one tuple for any particular contact URI scheme. If you had a way to specify that only tuples with particular URI schemes were to be included in a document, that would give the presentity the ability to, virtually independently of the composition process used by the presence server, cause the server to spit out a bare bones presence doc. So, this got me thinking further. The combination of tuples when they don't differ, as I propose above, might be more controllable. We could specify permissions that indicate that, if two tuples differ by presence attribute X, then the presence server still do the merging operation, but it combines the differing values in some way that would be defined on an attribute-by-attribute basis, possibly including dropping of that attribute. In other words, rather than try to specify composition in terms of types of views, it effectively gets specified by defining which presence attributes get combined together, and which don't. So, some specific questions to ask the group: (1) do you think we should be following model I or model II [I vote for I] (2) should we add a permission that grants access to tuples based on contact URI scheme [I vote for yes] (3) should we specify that, if authorization policies remove data which results in two tuples being the same, they be combined [I vote for yes] (4) should we define additional permissions that specify that certain presence attributes should be aggregated together in a tuple-combining process [not sure] Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue May 4 08:47: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 IAA28199 for ; Tue, 4 May 2004 08:47: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 1BKzKq-0007Lh-G3 for simple-archive@ietf.org; Tue, 04 May 2004 08:47:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKzJl-0007Hj-00 for simple-archive@ietf.org; Tue, 04 May 2004 08:46:38 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BKzIo-0007Ew-00; Tue, 04 May 2004 08:45:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKzFL-00034h-LC; Tue, 04 May 2004 08:42:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKzCx-0001vf-9y for simple@optimus.ietf.org; Tue, 04 May 2004 08:39: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 IAA27876 for ; Tue, 4 May 2004 08:39:32 -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 1BKzCv-0006l6-Tj for simple@ietf.org; Tue, 04 May 2004 08:39:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKzC2-0006Z2-00 for simple@ietf.org; Tue, 04 May 2004 08:38:39 -0400 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1BKzBB-0006N6-00 for simple@ietf.org; Tue, 04 May 2004 08:37:45 -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 i44CXuH25831; Tue, 4 May 2004 15:33:56 +0300 (EET DST) X-Scanned: Tue, 4 May 2004 15:33:39 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i44CXdw8012445; Tue, 4 May 2004 15:33:39 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00E9PBLh; Tue, 04 May 2004 15:33:37 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 i44CXaH12669; Tue, 4 May 2004 15:33:36 +0300 (EET DST) Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 4 May 2004 15:33:22 +0300 Received: from trebe003.NOE.Nokia.com ([172.22.232.175]) by esebe016.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 4 May 2004 15:33:22 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] WGLC on RPID, CIPID and future status Message-ID: Thread-Topic: WGLC on RPID, CIPID and future status Thread-Index: AcQs7nuIRm2/mALrSE+wzKo/hIbYJgEvtk+AAAGp3/A= To: , Cc: X-OriginalArrivalTime: 04 May 2004 12:33:22.0159 (UTC) FILETIME=[FCC117F0:01C431D3] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 4 May 2004 15:33:21 +0300 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Hi, I'd have a couple of comments as follows: CIPID-01: - 1. Introduction (the middle chapter): also "sound" and "map" elements = could be mentioned. - 1. Introduction (the middle chapter): the following sentence "All can = be used for a presentity=20 or for a tuple (or both)." could be clarified. I quess that the = presentity here means presence information=20 under the element but the presentity related information may = also be included in a tuple as well. I was also thinking whether is should be mentioned that the CIPID = elements can be placed also inside the=20 element. - 3. Example (texts before the XML document): "Fig. Figure 1." - 3. Example (texts after the XML document): Figure 1 mentioned again. - 3. Example (tuple id=3D"c8dqui"): the element should be = after the element. - 4. Schema: I propose removal of the "xmlns:pidf" definition because it = has not been used in the XML Schema - 4. Schema: the same figure related comments apply here (extra figure = texts). - 4. Schema: shouldn't the "tuple" word be removed from the annotation = since CIPID elements can also be used outside tuples? - 4. Schema: the sound and map elements have not been defined in the XML = Schema - 5.1: the "cpim" should be removed from the content type mentioned in = the "Description" - References ([4]): old version of the RPID reference FUTURE-01: - 2. Timed-Status Element (3rd chapter): the first sentence says that = "the element may contain any PIDF status extension". In = addition to any PIDF extension it can contain the note and basic = elements of PIDF. - 2. Timed-Status Element: after reading the chapter it was unlear to me = what the PA should do if the element indicates the = current time (e.g. should the PA leave the information = out of the notify)? - 3. Example & 4. Schema: the figure texts are twice. - 4. Schema: shouldn't the PIDF namespace be imported in the XML Schema? - 5.1: the "cpim" should be removed from the content type mentioned in = the "Description" - References: RPID and CIPID references to be updated RPID-03: - I have earlier sent comments which are still valid (for the v. 03) and = thus not sending them again. BR, Eva > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > ext hisham.khartabil@nokia.com > Sent: 04 May, 2004 11:01 > To: simple@ietf.org > Subject: RE: [Simple] WGLC on RPID, CIPID and future status >=20 >=20 > It has been a week since we announced the WGLC, but no=20 > comments have been made. The working group chairs and the=20 > editor would really appreciate reviews and comments,=20 > including nits if you have any. We cannot finish this work=20 > and pass to IESG if it does not receive enough attention from=20 > the working group. >=20 > If you reviewed the drafts and had no comments, please indicate so. >=20 > Thanks, > Hisham >=20 > > -----Original Message----- > > From: simple-admin@ietf.org=20 > [mailto:simple-admin@ietf.org]On Behalf Of > > ext hisham.khartabil@nokia.com > > Sent: 28.April.2004 10:00 > > To: simple@ietf.org > > Subject: [Simple] WGLC on RPID, CIPID and future status > >=20 > >=20 > > The WG chairs would like to start a Working Group Last Call=20 > > on the following drafts as part of the SIMPLE PIDF profile to=20 > > be submitted to IESG: > >=20 > > http://www.ietf.org/internet-drafts/draft-ietf-simple-rpid-03.txt > > http://www.ietf.org/internet-drafts/draft-ietf-simple-cipid-01.txt > > http://www.ietf.org/internet-drafts/draft-ietf-simple-future-01.txt > >=20 > > This WGLC will end on May 11th. > >=20 > > Please send your comments to this mailing list and to the authors.=20 > >=20 > > If you reviewed the draft and found no issues, please=20 > > indicate so on the mailing list. This will help us evaluate=20 > > the level of review and group consensus. > >=20 > > Thanks, > > Hisham > >=20 > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue May 4 08:58:55 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28665 for ; Tue, 4 May 2004 08:58:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKzRM-0006Hf-R2 for simple-archive@odin.ietf.org; Tue, 04 May 2004 08:54:28 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i44CsSGx024151 for simple-archive@odin.ietf.org; Tue, 4 May 2004 08:54:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKzKs-0004mW-JN for simple-web-archive@optimus.ietf.org; Tue, 04 May 2004 08:47: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 IAA28217 for ; Tue, 4 May 2004 08:47: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 1BKzKr-0007Lm-7D for simple-web-archive@ietf.org; Tue, 04 May 2004 08:47:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKzJm-0007Hq-00 for simple-web-archive@ietf.org; Tue, 04 May 2004 08:46:39 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BKzIo-0007Ew-00; Tue, 04 May 2004 08:45:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKzFL-00034h-LC; Tue, 04 May 2004 08:42:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKzCx-0001vf-9y for simple@optimus.ietf.org; Tue, 04 May 2004 08:39: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 IAA27876 for ; Tue, 4 May 2004 08:39:32 -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 1BKzCv-0006l6-Tj for simple@ietf.org; Tue, 04 May 2004 08:39:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKzC2-0006Z2-00 for simple@ietf.org; Tue, 04 May 2004 08:38:39 -0400 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1BKzBB-0006N6-00 for simple@ietf.org; Tue, 04 May 2004 08:37:45 -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 i44CXuH25831; Tue, 4 May 2004 15:33:56 +0300 (EET DST) X-Scanned: Tue, 4 May 2004 15:33:39 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i44CXdw8012445; Tue, 4 May 2004 15:33:39 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00E9PBLh; Tue, 04 May 2004 15:33:37 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 i44CXaH12669; Tue, 4 May 2004 15:33:36 +0300 (EET DST) Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 4 May 2004 15:33:22 +0300 Received: from trebe003.NOE.Nokia.com ([172.22.232.175]) by esebe016.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 4 May 2004 15:33:22 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] WGLC on RPID, CIPID and future status Message-ID: Thread-Topic: WGLC on RPID, CIPID and future status Thread-Index: AcQs7nuIRm2/mALrSE+wzKo/hIbYJgEvtk+AAAGp3/A= To: , Cc: X-OriginalArrivalTime: 04 May 2004 12:33:22.0159 (UTC) FILETIME=[FCC117F0:01C431D3] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 4 May 2004 15:33:21 +0300 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 Content-Transfer-Encoding: quoted-printable Hi, I'd have a couple of comments as follows: CIPID-01: - 1. Introduction (the middle chapter): also "sound" and "map" elements = could be mentioned. - 1. Introduction (the middle chapter): the following sentence "All can = be used for a presentity=20 or for a tuple (or both)." could be clarified. I quess that the = presentity here means presence information=20 under the element but the presentity related information may = also be included in a tuple as well. I was also thinking whether is should be mentioned that the CIPID = elements can be placed also inside the=20 element. - 3. Example (texts before the XML document): "Fig. Figure 1." - 3. Example (texts after the XML document): Figure 1 mentioned again. - 3. Example (tuple id=3D"c8dqui"): the element should be = after the element. - 4. Schema: I propose removal of the "xmlns:pidf" definition because it = has not been used in the XML Schema - 4. Schema: the same figure related comments apply here (extra figure = texts). - 4. Schema: shouldn't the "tuple" word be removed from the annotation = since CIPID elements can also be used outside tuples? - 4. Schema: the sound and map elements have not been defined in the XML = Schema - 5.1: the "cpim" should be removed from the content type mentioned in = the "Description" - References ([4]): old version of the RPID reference FUTURE-01: - 2. Timed-Status Element (3rd chapter): the first sentence says that = "the element may contain any PIDF status extension". In = addition to any PIDF extension it can contain the note and basic = elements of PIDF. - 2. Timed-Status Element: after reading the chapter it was unlear to me = what the PA should do if the element indicates the = current time (e.g. should the PA leave the information = out of the notify)? - 3. Example & 4. Schema: the figure texts are twice. - 4. Schema: shouldn't the PIDF namespace be imported in the XML Schema? - 5.1: the "cpim" should be removed from the content type mentioned in = the "Description" - References: RPID and CIPID references to be updated RPID-03: - I have earlier sent comments which are still valid (for the v. 03) and = thus not sending them again. BR, Eva > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > ext hisham.khartabil@nokia.com > Sent: 04 May, 2004 11:01 > To: simple@ietf.org > Subject: RE: [Simple] WGLC on RPID, CIPID and future status >=20 >=20 > It has been a week since we announced the WGLC, but no=20 > comments have been made. The working group chairs and the=20 > editor would really appreciate reviews and comments,=20 > including nits if you have any. We cannot finish this work=20 > and pass to IESG if it does not receive enough attention from=20 > the working group. >=20 > If you reviewed the drafts and had no comments, please indicate so. >=20 > Thanks, > Hisham >=20 > > -----Original Message----- > > From: simple-admin@ietf.org=20 > [mailto:simple-admin@ietf.org]On Behalf Of > > ext hisham.khartabil@nokia.com > > Sent: 28.April.2004 10:00 > > To: simple@ietf.org > > Subject: [Simple] WGLC on RPID, CIPID and future status > >=20 > >=20 > > The WG chairs would like to start a Working Group Last Call=20 > > on the following drafts as part of the SIMPLE PIDF profile to=20 > > be submitted to IESG: > >=20 > > http://www.ietf.org/internet-drafts/draft-ietf-simple-rpid-03.txt > > http://www.ietf.org/internet-drafts/draft-ietf-simple-cipid-01.txt > > http://www.ietf.org/internet-drafts/draft-ietf-simple-future-01.txt > >=20 > > This WGLC will end on May 11th. > >=20 > > Please send your comments to this mailing list and to the authors.=20 > >=20 > > If you reviewed the draft and found no issues, please=20 > > indicate so on the mailing list. This will help us evaluate=20 > > the level of review and group consensus. > >=20 > > Thanks, > > Hisham > >=20 > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue May 4 09: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 JAA28738 for ; Tue, 4 May 2004 09: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 1BKzXF-0000DX-Pb for simple-archive@ietf.org; Tue, 04 May 2004 09:00:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKzWK-0000At-00 for simple-archive@ietf.org; Tue, 04 May 2004 08:59:37 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BKzVu-00008f-00; Tue, 04 May 2004 08:59:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKzRt-0006Ie-25; Tue, 04 May 2004 08:55:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKzKw-0004mp-OJ for simple@optimus.ietf.org; Tue, 04 May 2004 08:47: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 IAA28228 for ; Tue, 4 May 2004 08:47: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 1BKzKv-0007MG-EP for simple@ietf.org; Tue, 04 May 2004 08:47:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKzJq-0007IO-00 for simple@ietf.org; Tue, 04 May 2004 08:46:42 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx with esmtp (Exim 4.12) id 1BKzJI-0007Ey-00 for simple@ietf.org; Tue, 04 May 2004 08:46:08 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 04 May 2004 05:47:40 -0700 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 i44CjZpI027699; Tue, 4 May 2004 08:45:36 -0400 (EDT) Received: from cisco.com ([161.44.79.59]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AID10238; Tue, 4 May 2004 08:45:35 -0400 (EDT) Message-ID: <4097906E.8080003@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Campbell CC: Cullen Jennings , hisham.khartabil@nokia.com, simple@ietf.org Subject: Re: [Simple] MSRP: DSN lifetime open issue References: <40967A19.9040806@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 04 May 2004 08:45:34 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Ben Campbell wrote: > > I know I am in the minority on the following point, but I think we have > a perfectly good system for doing this now. If the SIP fabric cannot > reach the final destination, it redirects you to a "mailto" URI. From > that point on, delivery notification follows email methods, not message > session methods. I think that is a fine idea! It would be a good thing if there was more uniformity and continuity between all these communications systems - email, IM, and voice. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue May 4 09:07:11 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29033 for ; Tue, 4 May 2004 09:07:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKzZo-0000Yo-TZ for simple-archive@odin.ietf.org; Tue, 04 May 2004 09:03:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i44D3Chi002149 for simple-archive@odin.ietf.org; Tue, 4 May 2004 09:03:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKzXH-0008Kz-Rq for simple-web-archive@optimus.ietf.org; Tue, 04 May 2004 09:00: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 JAA28756 for ; Tue, 4 May 2004 09:00: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 1BKzXG-0000Dd-Fd for simple-web-archive@ietf.org; Tue, 04 May 2004 09:00:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKzWL-0000B0-00 for simple-web-archive@ietf.org; Tue, 04 May 2004 08:59:37 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BKzVu-00008f-00; Tue, 04 May 2004 08:59:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKzRt-0006Ie-25; Tue, 04 May 2004 08:55:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKzKw-0004mp-OJ for simple@optimus.ietf.org; Tue, 04 May 2004 08:47: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 IAA28228 for ; Tue, 4 May 2004 08:47: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 1BKzKv-0007MG-EP for simple@ietf.org; Tue, 04 May 2004 08:47:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKzJq-0007IO-00 for simple@ietf.org; Tue, 04 May 2004 08:46:42 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx with esmtp (Exim 4.12) id 1BKzJI-0007Ey-00 for simple@ietf.org; Tue, 04 May 2004 08:46:08 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 04 May 2004 05:47:40 -0700 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 i44CjZpI027699; Tue, 4 May 2004 08:45:36 -0400 (EDT) Received: from cisco.com ([161.44.79.59]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AID10238; Tue, 4 May 2004 08:45:35 -0400 (EDT) Message-ID: <4097906E.8080003@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Campbell CC: Cullen Jennings , hisham.khartabil@nokia.com, simple@ietf.org Subject: Re: [Simple] MSRP: DSN lifetime open issue References: <40967A19.9040806@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 04 May 2004 08:45:34 -0400 X-Spam-Checker-Version: SpamAssassin 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 Content-Transfer-Encoding: 7bit Ben Campbell wrote: > > I know I am in the minority on the following point, but I think we have > a perfectly good system for doing this now. If the SIP fabric cannot > reach the final destination, it redirects you to a "mailto" URI. From > that point on, delivery notification follows email methods, not message > session methods. I think that is a fine idea! It would be a good thing if there was more uniformity and continuity between all these communications systems - email, IM, and voice. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue May 4 09:15: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 JAA29320 for ; Tue, 4 May 2004 09:15:47 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKzm0-0000vk-H3 for simple-archive@ietf.org; Tue, 04 May 2004 09:15:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKzkx-0000rt-00 for simple-archive@ietf.org; Tue, 04 May 2004 09:14:44 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BKzkc-0000oK-00; Tue, 04 May 2004 09:14:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKzeU-0001wH-S0; Tue, 04 May 2004 09:08:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKzbA-0000fX-OW for simple@optimus.ietf.org; Tue, 04 May 2004 09:04: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 JAA28908 for ; Tue, 4 May 2004 09:04: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 1BKzb9-0000QQ-6d for simple@ietf.org; Tue, 04 May 2004 09:04:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKzaA-0000NQ-00 for simple@ietf.org; Tue, 04 May 2004 09:03:35 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx with esmtp (Exim 4.12) id 1BKzZT-0000Iy-00 for simple@ietf.org; Tue, 04 May 2004 09:02:51 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 04 May 2004 05:58:16 -0700 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 i44D2IYu000721; Tue, 4 May 2004 09:02:19 -0400 (EDT) Received: from cisco.com ([161.44.79.59]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AID11118; Tue, 4 May 2004 09:02:18 -0400 (EDT) Message-ID: <4097945A.3050203@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Simple WG Subject: Re: [Simple] Presence Rules Issue 3: Specifying views References: <40975A80.5070409@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 04 May 2004 09:02:18 -0400 X-Spam-Checker-Version: SpamAssassin 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: [snip] > As a result, I think it makes sense to further specify that, after the > authorization policies are applied, the presence server looks at the > remaining tuples. If it turns out that two tuples no longer differ in > any way except basic or contact URI (assuming the same scheme), that > they be merged together into a single tuple by the presence server > before distribution. This might require the presence server to place a > different contact into the merged tuple. The merged basic status would > be computed with an OR operation (i.e., open as long as any are open). I'm not ready to comment on the whole thing yet. But I want to comment on this part. I am concerned about creating a presence composition mechanism that effectively *requires* the PS to be able to construct a synthetic contact address. This really raises the bar for a PS, because it potentially puts it in the loop for all sip traffic - effectivly causing it to implement the same type of decision logic that a proxy has. I can see that for certain kinds of integrated systems this would be a reasonable thing to do. But it could be quite a pain for other kinds of PS that simply layer on other independent sip components. Maybe it is a worthwhile tradeoff to set the bar that high, but we should think hard about it before making that kind of decision. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue May 4 09:18:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29567 for ; Tue, 4 May 2004 09:18:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKznp-0004dE-LR for simple-archive@odin.ietf.org; Tue, 04 May 2004 09:17:41 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i44DHfCA017799 for simple-archive@odin.ietf.org; Tue, 4 May 2004 09:17:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKzm3-0003ym-Fa for simple-web-archive@optimus.ietf.org; Tue, 04 May 2004 09:15:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29340 for ; Tue, 4 May 2004 09:15: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 1BKzm1-0000vx-S7 for simple-web-archive@ietf.org; Tue, 04 May 2004 09:15:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKzky-0000s0-00 for simple-web-archive@ietf.org; Tue, 04 May 2004 09:14:44 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BKzkc-0000oK-00; Tue, 04 May 2004 09:14:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKzeU-0001wH-S0; Tue, 04 May 2004 09:08:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKzbA-0000fX-OW for simple@optimus.ietf.org; Tue, 04 May 2004 09:04: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 JAA28908 for ; Tue, 4 May 2004 09:04: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 1BKzb9-0000QQ-6d for simple@ietf.org; Tue, 04 May 2004 09:04:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKzaA-0000NQ-00 for simple@ietf.org; Tue, 04 May 2004 09:03:35 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx with esmtp (Exim 4.12) id 1BKzZT-0000Iy-00 for simple@ietf.org; Tue, 04 May 2004 09:02:51 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 04 May 2004 05:58:16 -0700 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 i44D2IYu000721; Tue, 4 May 2004 09:02:19 -0400 (EDT) Received: from cisco.com ([161.44.79.59]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AID11118; Tue, 4 May 2004 09:02:18 -0400 (EDT) Message-ID: <4097945A.3050203@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Simple WG Subject: Re: [Simple] Presence Rules Issue 3: Specifying views References: <40975A80.5070409@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 04 May 2004 09:02:18 -0400 X-Spam-Checker-Version: SpamAssassin 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 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: [snip] > As a result, I think it makes sense to further specify that, after the > authorization policies are applied, the presence server looks at the > remaining tuples. If it turns out that two tuples no longer differ in > any way except basic or contact URI (assuming the same scheme), that > they be merged together into a single tuple by the presence server > before distribution. This might require the presence server to place a > different contact into the merged tuple. The merged basic status would > be computed with an OR operation (i.e., open as long as any are open). I'm not ready to comment on the whole thing yet. But I want to comment on this part. I am concerned about creating a presence composition mechanism that effectively *requires* the PS to be able to construct a synthetic contact address. This really raises the bar for a PS, because it potentially puts it in the loop for all sip traffic - effectivly causing it to implement the same type of decision logic that a proxy has. I can see that for certain kinds of integrated systems this would be a reasonable thing to do. But it could be quite a pain for other kinds of PS that simply layer on other independent sip components. Maybe it is a worthwhile tradeoff to set the bar that high, but we should think hard about it before making that kind of decision. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue May 4 09:29: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 JAA00302 for ; Tue, 4 May 2004 09:29: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 1BKzzP-0001xI-TV for simple-archive@ietf.org; Tue, 04 May 2004 09:29:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKzyW-0001t7-00 for simple-archive@ietf.org; Tue, 04 May 2004 09:28:45 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BKzxb-0001q3-00; Tue, 04 May 2004 09:27:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKztx-0006Cg-Em; Tue, 04 May 2004 09:24:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKzsb-0005vp-IQ for simple@optimus.ietf.org; Tue, 04 May 2004 09:22: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 JAA29905 for ; Tue, 4 May 2004 09:22:34 -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 1BKzsZ-0001Wq-Va for simple@ietf.org; Tue, 04 May 2004 09:22:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKzrg-0001T3-00 for simple@ietf.org; Tue, 04 May 2004 09:21:41 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BKzr8-0001Q6-00 for simple@ietf.org; Tue, 04 May 2004 09:21:06 -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 i44DL5v13110 for ; Tue, 4 May 2004 16:21:05 +0300 (EET DST) X-Scanned: Tue, 4 May 2004 16:20:56 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i44DKtRB030587 for ; Tue, 4 May 2004 16:20:56 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00bSJ7bE; Tue, 04 May 2004 16:20:54 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i44DKsH21584 for ; Tue, 4 May 2004 16:20:54 +0300 (EET DST) Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 4 May 2004 16:20:54 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Open issues and changes to prescaps Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF01C1DEDC@esebe004.ntc.nokia.com> Thread-Topic: [Simple] Open issues and changes to prescaps Thread-Index: AcQnhl6CB6fHHHY+SBy4y+j88Sx6CgEmastAAWsFl5A= To: , X-OriginalArrivalTime: 04 May 2004 13:20:54.0712 (UTC) FILETIME=[A1022380:01C431DA] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 4 May 2004 16:20:53 +0300 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Hi, Below it is proposed that element would be removed from ,