From mailman-admin@ietf.org Sun Feb 1 09:56: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 JAA19633 for ; Sun, 1 Feb 2004 09:56:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnJ1K-0000Zn-00 for simple-archive@ietf.org; Sun, 01 Feb 2004 09:56:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnIcN-00029A-00 for simple-archive@ietf.org; Sun, 01 Feb 2004 09:30:38 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AnIOx-0006UO-01 for simple-archive@ietf.org; Sun, 01 Feb 2004 09:16:43 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1AnIIR-0004nR-3G for simple-archive@ietf.org; Sun, 01 Feb 2004 09:09:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnIIP-0002Al-Lf for simple-archive@ietf.org; Sun, 01 Feb 2004 09:09:57 -0500 Date: Sun, 01 Feb 2004 09:09:57 -0500 Message-ID: <20040201140957.1364.27352.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 Sun Feb 1 10:10:38 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22074 for ; Sun, 1 Feb 2004 10:10:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnJEh-0003Nn-2C for simple-archive@odin.ietf.org; Sun, 01 Feb 2004 10:10:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i11FAB2A012999 for simple-archive@odin.ietf.org; Sun, 1 Feb 2004 10:10:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnJEg-0003Na-T9 for simple-web-archive@optimus.ietf.org; Sun, 01 Feb 2004 10:10:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21764 for ; Sun, 1 Feb 2004 10:10:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnJEe-0003ot-00 for simple-web-archive@ietf.org; Sun, 01 Feb 2004 10:10:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnIgs-0003By-00 for simple-web-archive@ietf.org; Sun, 01 Feb 2004 09:35:16 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AnIPB-0006VG-02 for simple-web-archive@ietf.org; Sun, 01 Feb 2004 09:16:57 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1AnIFN-0004QF-16 for simple-web-archive@ietf.org; Sun, 01 Feb 2004 09:06:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnIFL-0007jN-W7 for simple-web-archive@ietf.org; Sun, 01 Feb 2004 09:06:47 -0500 Date: Sun, 01 Feb 2004 09:06:47 -0500 Message-ID: <20040201140647.1364.41917.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 Mon Feb 2 08:48:16 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12143 for ; Mon, 2 Feb 2004 08:48:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AneQz-0001xn-00 for simple-archive@ietf.org; Mon, 02 Feb 2004 08:48:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnePW-0001bO-00 for simple-archive@ietf.org; Mon, 02 Feb 2004 08:46:47 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AneNA-00013O-05; Mon, 02 Feb 2004 08:44:20 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1Ane3q-0007DE-8p; Mon, 02 Feb 2004 08:24:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ane3g-0005fh-1z; Mon, 02 Feb 2004 08:24:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AndGa-0002YH-MN for simple@optimus.ietf.org; Mon, 02 Feb 2004 07:33:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07164 for ; Mon, 2 Feb 2004 07:33:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AndGa-0007Xh-00 for simple@ietf.org; Mon, 02 Feb 2004 07:33:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AndFb-0007Rl-00 for simple@ietf.org; Mon, 02 Feb 2004 07:32:28 -0500 Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx with esmtp (Exim 4.12) id 1AndEc-0007Ic-00 for simple@ietf.org; Mon, 02 Feb 2004 07:31:26 -0500 Received: from eamrcnt748.exu.ericsson.se (eamrcnt748.exu.ericsson.se [138.85.133.46]) by imr2.ericy.com (8.12.10/8.12.10) with ESMTP id i12CUuFX006910 for ; Mon, 2 Feb 2004 06:30:56 -0600 (CST) Received: from eamrcnt750.exu.ericsson.se ([138.85.133.51]) by eamrcnt748.exu.ericsson.se with Microsoft SMTPSVC(5.0.2195.6713); Mon, 2 Feb 2004 06:27:02 -0600 Received: by eamrcnt750.exu.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Mon, 2 Feb 2004 06:30:52 -0600 Message-ID: <2DBF697D5B36014ABA46E66A96107DA02C94DB@lmc37.lmc.ericsson.se> From: "George Foti (QC/EMC)" To: simple@ietf.org MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 02 Feb 2004 12:27:02.0343 (UTC) FILETIME=[DC5CC570:01C3E987] Subject: [Simple] Comments on Pres-Filter-Reqs-03 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.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, 2 Feb 2004 06:30:05 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 HI, I have few questions/comments on the presence filter requirements 03 draft: Req C1 : It does not seem that this is a requirment on the watcher, rather the presence server. Otherwise, I dont get that one. Req C6: I wonder the usefulness of the requirement. It seems more natural to say what you want rather what you dont want to see. Req D1 & Req I4 : I conclude from those 2 requirements that there can be multiple filters within a single SUBSCRIBE. If that is the case, I would like to understand whether the presence server is expected to ensure that the 2 filters dont contradict each other. Req G7: Is this a watcher requirement or a presence server requirement. Req. I1: This is a presence server requirement. Also, I dont understand the reasons for it and what would the PS send the watcher in this case. Req I6: I dont understand that one. May be wording changes can clarify it a bit better, Rgd/gf Ericsson Canada This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Feb 2 08:48:50 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12221 for ; Mon, 2 Feb 2004 08:48:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AneR4-00014G-Kb for simple-archive@odin.ietf.org; Mon, 02 Feb 2004 08:48:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i12DmMrP004100 for simple-archive@odin.ietf.org; Mon, 2 Feb 2004 08:48:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AneR4-000143-H9 for simple-web-archive@optimus.ietf.org; Mon, 02 Feb 2004 08:48:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12164 for ; Mon, 2 Feb 2004 08:48:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AneR3-0001yM-00 for simple-web-archive@ietf.org; Mon, 02 Feb 2004 08:48:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnePX-0001bm-00 for simple-web-archive@ietf.org; Mon, 02 Feb 2004 08:46:48 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AneNA-00013O-05; Mon, 02 Feb 2004 08:44:20 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1Ane3q-0007DE-8p; Mon, 02 Feb 2004 08:24:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ane3g-0005fh-1z; Mon, 02 Feb 2004 08:24:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AndGa-0002YH-MN for simple@optimus.ietf.org; Mon, 02 Feb 2004 07:33:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07164 for ; Mon, 2 Feb 2004 07:33:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AndGa-0007Xh-00 for simple@ietf.org; Mon, 02 Feb 2004 07:33:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AndFb-0007Rl-00 for simple@ietf.org; Mon, 02 Feb 2004 07:32:28 -0500 Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx with esmtp (Exim 4.12) id 1AndEc-0007Ic-00 for simple@ietf.org; Mon, 02 Feb 2004 07:31:26 -0500 Received: from eamrcnt748.exu.ericsson.se (eamrcnt748.exu.ericsson.se [138.85.133.46]) by imr2.ericy.com (8.12.10/8.12.10) with ESMTP id i12CUuFX006910 for ; Mon, 2 Feb 2004 06:30:56 -0600 (CST) Received: from eamrcnt750.exu.ericsson.se ([138.85.133.51]) by eamrcnt748.exu.ericsson.se with Microsoft SMTPSVC(5.0.2195.6713); Mon, 2 Feb 2004 06:27:02 -0600 Received: by eamrcnt750.exu.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Mon, 2 Feb 2004 06:30:52 -0600 Message-ID: <2DBF697D5B36014ABA46E66A96107DA02C94DB@lmc37.lmc.ericsson.se> From: "George Foti (QC/EMC)" To: simple@ietf.org MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 02 Feb 2004 12:27:02.0343 (UTC) FILETIME=[DC5CC570:01C3E987] Subject: [Simple] Comments on Pres-Filter-Reqs-03 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.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, 2 Feb 2004 06:30:05 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 HI, I have few questions/comments on the presence filter requirements 03 draft: Req C1 : It does not seem that this is a requirment on the watcher, rather the presence server. Otherwise, I dont get that one. Req C6: I wonder the usefulness of the requirement. It seems more natural to say what you want rather what you dont want to see. Req D1 & Req I4 : I conclude from those 2 requirements that there can be multiple filters within a single SUBSCRIBE. If that is the case, I would like to understand whether the presence server is expected to ensure that the 2 filters dont contradict each other. Req G7: Is this a watcher requirement or a presence server requirement. Req. I1: This is a presence server requirement. Also, I dont understand the reasons for it and what would the PS send the watcher in this case. Req I6: I dont understand that one. May be wording changes can clarify it a bit better, Rgd/gf Ericsson Canada This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Feb 3 05:07:16 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00393 for ; Tue, 3 Feb 2004 05:07:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnxSe-0002CH-00 for simple-archive@ietf.org; Tue, 03 Feb 2004 05:07:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnxRg-00027M-00 for simple-archive@ietf.org; Tue, 03 Feb 2004 05:06:16 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AnxRW-00022f-00; Tue, 03 Feb 2004 05:06:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnxRT-0001uL-85; Tue, 03 Feb 2004 05:06:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnxQl-0001ly-VK for simple@optimus.ietf.org; Tue, 03 Feb 2004 05:05:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00361 for ; Tue, 3 Feb 2004 05:05:17 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnxQi-00022E-00 for simple@ietf.org; Tue, 03 Feb 2004 05:05:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnxPn-0001xP-00 for simple@ietf.org; Tue, 03 Feb 2004 05:04:19 -0500 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1AnxPX-0001sK-00 for simple@ietf.org; Tue, 03 Feb 2004 05:04:03 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i13A43Z04196 for ; Tue, 3 Feb 2004 12:04:03 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 3 Feb 2004 12:03:14 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 3 Feb 2004 12:03:13 +0200 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Comments on Pres-Filter-Reqs-03 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017976C1@esebe019.ntc.nokia.com> Thread-Topic: [Simple] Comments on Pres-Filter-Reqs-03 Thread-Index: AcPpj/duvOmxwqsbSx2Iws4v2UOoZQArAg0A To: , X-OriginalArrivalTime: 03 Feb 2004 10:03:13.0252 (UTC) FILETIME=[EF6FBA40:01C3EA3C] 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, 3 Feb 2004 12:03:11 +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.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable George, Thanks for the comments. > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > ext George Foti (QC/EMC) > Sent: 02.February.2004 14:30 > To: simple@ietf.org > Subject: [Simple] Comments on Pres-Filter-Reqs-03 >=20 >=20 > HI, >=20 > I have few questions/comments on the presence filter=20 > requirements 03 draft: >=20 > Req C1 : It does not seem that this is a requirment on the=20 > watcher, rather the presence server. Otherwise, I dont get that one. You are correct. >=20 > Req C6: I wonder the usefulness of the requirement. It seems=20 > more natural to say what you want rather what you dont want to see.=20 The requirement states what you want. >=20 > Req D1 & Req I4 : I conclude from those 2 requirements that=20 > there can be multiple filters within a single SUBSCRIBE. If=20 > that is the case, I would like to understand whether the=20 > presence server is expected to ensure that the 2 filters dont=20 > contradict each other. Yes it is. > =20 > Req G7: Is this a watcher requirement or a presence server=20 > requirement.=20 Server. >=20 > Req. I1: This is a presence server requirement. Also, I dont=20 > understand the reasons for it and what would the PS send the=20 > watcher in this case. Polite blocking. You might not want to tell a watcher that he's not = allowed to see certain parts of your presence information. So you accept = the filter, but give false information. >=20 > Req I6: I dont understand that one. May be wording changes=20 > can clarify it a bit better, An RLS fans out subscriptions. If there is a filter for someone is = domain1.com, the RLS should not forward that filter to domian2.com. /Hisham >=20 > Rgd/gf > Ericsson Canada=20 >=20 >=20 > This communication is confidential and intended solely for=20 > the addressee(s). Any unauthorized review, use, disclosure or=20 > distribution is prohibited. If you believe this message has=20 > been sent to you in error, please notify the sender by=20 > replying to this transmission and delete the message without=20 > disclosing it. Thank you. >=20 > E-mail including attachments is susceptible to data=20 > corruption, interruption, unauthorized amendment, tampering=20 > and viruses, and we only send and receive e-mails on the=20 > basis that we are not liable for any such corruption,=20 > interception, amendment, tampering or viruses or any=20 > consequences thereof. >=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 Feb 3 05:07:49 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 FAA00420 for ; Tue, 3 Feb 2004 05:07:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnxSj-00028k-Bu for simple-archive@odin.ietf.org; Tue, 03 Feb 2004 05:07:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i13A7LAL008222 for simple-archive@odin.ietf.org; Tue, 3 Feb 2004 05:07:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnxSi-00028S-Fz for simple-web-archive@optimus.ietf.org; Tue, 03 Feb 2004 05:07:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00414 for ; Tue, 3 Feb 2004 05:07:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnxSf-0002CL-00 for simple-web-archive@ietf.org; Tue, 03 Feb 2004 05:07:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnxRg-00027T-00 for simple-web-archive@ietf.org; Tue, 03 Feb 2004 05:06:17 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AnxRW-00022f-00; Tue, 03 Feb 2004 05:06:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnxRT-0001uL-85; Tue, 03 Feb 2004 05:06:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnxQl-0001ly-VK for simple@optimus.ietf.org; Tue, 03 Feb 2004 05:05:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00361 for ; Tue, 3 Feb 2004 05:05:17 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnxQi-00022E-00 for simple@ietf.org; Tue, 03 Feb 2004 05:05:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnxPn-0001xP-00 for simple@ietf.org; Tue, 03 Feb 2004 05:04:19 -0500 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1AnxPX-0001sK-00 for simple@ietf.org; Tue, 03 Feb 2004 05:04:03 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i13A43Z04196 for ; Tue, 3 Feb 2004 12:04:03 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 3 Feb 2004 12:03:14 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 3 Feb 2004 12:03:13 +0200 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Comments on Pres-Filter-Reqs-03 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017976C1@esebe019.ntc.nokia.com> Thread-Topic: [Simple] Comments on Pres-Filter-Reqs-03 Thread-Index: AcPpj/duvOmxwqsbSx2Iws4v2UOoZQArAg0A To: , X-OriginalArrivalTime: 03 Feb 2004 10:03:13.0252 (UTC) FILETIME=[EF6FBA40:01C3EA3C] 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, 3 Feb 2004 12:03:11 +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.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable George, Thanks for the comments. > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > ext George Foti (QC/EMC) > Sent: 02.February.2004 14:30 > To: simple@ietf.org > Subject: [Simple] Comments on Pres-Filter-Reqs-03 >=20 >=20 > HI, >=20 > I have few questions/comments on the presence filter=20 > requirements 03 draft: >=20 > Req C1 : It does not seem that this is a requirment on the=20 > watcher, rather the presence server. Otherwise, I dont get that one. You are correct. >=20 > Req C6: I wonder the usefulness of the requirement. It seems=20 > more natural to say what you want rather what you dont want to see.=20 The requirement states what you want. >=20 > Req D1 & Req I4 : I conclude from those 2 requirements that=20 > there can be multiple filters within a single SUBSCRIBE. If=20 > that is the case, I would like to understand whether the=20 > presence server is expected to ensure that the 2 filters dont=20 > contradict each other. Yes it is. > =20 > Req G7: Is this a watcher requirement or a presence server=20 > requirement.=20 Server. >=20 > Req. I1: This is a presence server requirement. Also, I dont=20 > understand the reasons for it and what would the PS send the=20 > watcher in this case. Polite blocking. You might not want to tell a watcher that he's not = allowed to see certain parts of your presence information. So you accept = the filter, but give false information. >=20 > Req I6: I dont understand that one. May be wording changes=20 > can clarify it a bit better, An RLS fans out subscriptions. If there is a filter for someone is = domain1.com, the RLS should not forward that filter to domian2.com. /Hisham >=20 > Rgd/gf > Ericsson Canada=20 >=20 >=20 > This communication is confidential and intended solely for=20 > the addressee(s). Any unauthorized review, use, disclosure or=20 > distribution is prohibited. If you believe this message has=20 > been sent to you in error, please notify the sender by=20 > replying to this transmission and delete the message without=20 > disclosing it. Thank you. >=20 > E-mail including attachments is susceptible to data=20 > corruption, interruption, unauthorized amendment, tampering=20 > and viruses, and we only send and receive e-mails on the=20 > basis that we are not liable for any such corruption,=20 > interception, amendment, tampering or viruses or any=20 > consequences thereof. >=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 Feb 3 07:29:24 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06399 for ; Tue, 3 Feb 2004 07:29:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnzgC-0002jb-00 for simple-archive@ietf.org; Tue, 03 Feb 2004 07:29:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnzfI-0002dt-00 for simple-archive@ietf.org; Tue, 03 Feb 2004 07:28:29 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Anzex-0002YI-00; Tue, 03 Feb 2004 07:28:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Anzeq-0007NS-ON; Tue, 03 Feb 2004 07:28:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnzeA-0007FK-VB for simple@optimus.ietf.org; Tue, 03 Feb 2004 07:27:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06335 for ; Tue, 3 Feb 2004 07:27:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnzeA-0002W8-00 for simple@ietf.org; Tue, 03 Feb 2004 07:27:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnzdH-0002Qp-00 for simple@ietf.org; Tue, 03 Feb 2004 07:26:23 -0500 Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx with esmtp (Exim 4.12) id 1AnzcO-0002Fz-00 for simple@ietf.org; Tue, 03 Feb 2004 07:25:28 -0500 Received: from eamrcnt748.exu.ericsson.se (eamrcnt748.exu.ericsson.se [138.85.133.46]) by imr1.ericy.com (8.12.10/8.12.10) with ESMTP id i13COqbj014327 for ; Tue, 3 Feb 2004 06:24:52 -0600 (CST) Received: from eamrcnt750.exu.ericsson.se ([138.85.133.51]) by eamrcnt748.exu.ericsson.se with Microsoft SMTPSVC(5.0.2195.6713); Tue, 3 Feb 2004 06:21:03 -0600 Received: by eamrcnt750.exu.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Tue, 3 Feb 2004 06:24:53 -0600 Message-ID: <2DBF697D5B36014ABA46E66A96107DA02C94E4@lmc37.lmc.ericsson.se> From: "George Foti (QC/EMC)" To: "'hisham.khartabil@nokia.com'" , simple@ietf.org Subject: RE: [Simple] Comments on Pres-Filter-Reqs-03 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 03 Feb 2004 12:21:03.0062 (UTC) FILETIME=[30A09760:01C3EA50] Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.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, 3 Feb 2004 06:24:07 -0600 X-Spam-Checker-Version: SpamAssassin 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 I have more questions/comments Hisham, 1) I initially understood that these are requirments on the watcher and not the PS. Now there are clearly a mix of both which is okay, as long as the scope clearly states that, and that it is clear from the requirement whether this is a PS or a watcher requirement. With that in mind, Req C1 needs to be clarified, as it incorrect the way it is currently stated. 2) You did not sepcifically address the behavior of the PS when it comes to a SUBSCRIBE holding multilple filters. Is the PS suppose to check that the filters dont contradict each other, or is this a watcher problem, or even an implmentation issue I would like to see the requirement clearer in that regard. 3) You misunderstood my comment on Req C6, so I will reword - I wonder the usefulness of the requirement. It seems more natural for a watcher to state in a filter what he would like to receieve, rather what he does not want to receieve. 4) Finally, I would like to add a requirement in which the watcher indicates his *willingness* to receive binary XML. This allows PS to conveny presence information in that format, if it supports that, but does not oblige compliance. Thanks. /gf > -----Original Message----- > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > Sent: Tuesday, February 03, 2004 5:03 AM > To: George Foti (QC/EMC); simple@ietf.org > Subject: RE: [Simple] Comments on Pres-Filter-Reqs-03 > > > George, > > Thanks for the comments. > > > -----Original Message----- > > From: simple-admin@ietf.org > [mailto:simple-admin@ietf.org]On Behalf Of > > ext George Foti (QC/EMC) > > Sent: 02.February.2004 14:30 > > To: simple@ietf.org > > Subject: [Simple] Comments on Pres-Filter-Reqs-03 > > > > > > HI, > > > > I have few questions/comments on the presence filter > > requirements 03 draft: > > > > Req C1 : It does not seem that this is a requirment on the > > watcher, rather the presence server. Otherwise, I dont get that one. > > You are correct. > > > > > Req C6: I wonder the usefulness of the requirement. It seems > > more natural to say what you want rather what you dont want to see. > > The requirement states what you want. > > > > Req D1 & Req I4 : I conclude from those 2 requirements that > > there can be multiple filters within a single SUBSCRIBE. If > > that is the case, I would like to understand whether the > > presence server is expected to ensure that the 2 filters dont > > contradict each other. > > Yes it is. > > > > > Req G7: Is this a watcher requirement or a presence server > > requirement. > > Server. > > > > > Req. I1: This is a presence server requirement. Also, I dont > > understand the reasons for it and what would the PS send the > > watcher in this case. > > Polite blocking. You might not want to tell a watcher that > he's not allowed to see certain parts of your presence > information. So you accept the filter, but give false information. > > > > > Req I6: I dont understand that one. May be wording changes > > can clarify it a bit better, > > An RLS fans out subscriptions. If there is a filter for > someone is domain1.com, the RLS should not forward that > filter to domian2.com. > > /Hisham > > > > > Rgd/gf > > Ericsson Canada > > > > > > This communication is confidential and intended solely for > > the addressee(s). Any unauthorized review, use, disclosure or > > distribution is prohibited. If you believe this message has > > been sent to you in error, please notify the sender by > > replying to this transmission and delete the message without > > disclosing it. Thank you. > > > > E-mail including attachments is susceptible to data > > corruption, interruption, unauthorized amendment, tampering > > and viruses, and we only send and receive e-mails on the > > basis that we are not liable for any such corruption, > > interception, amendment, tampering or viruses or any > > consequences thereof. > > > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > > > This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Feb 3 07:29:56 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 HAA06438 for ; Tue, 3 Feb 2004 07:29:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnzgE-0007cc-Lj for simple-archive@odin.ietf.org; Tue, 03 Feb 2004 07:29:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i13CTQag029294 for simple-archive@odin.ietf.org; Tue, 3 Feb 2004 07:29:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnzgE-0007cP-I7 for simple-web-archive@optimus.ietf.org; Tue, 03 Feb 2004 07:29:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06417 for ; Tue, 3 Feb 2004 07:29:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnzgD-0002jp-00 for simple-web-archive@ietf.org; Tue, 03 Feb 2004 07:29:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnzfJ-0002e1-00 for simple-web-archive@ietf.org; Tue, 03 Feb 2004 07:28:30 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Anzex-0002YI-00; Tue, 03 Feb 2004 07:28:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Anzeq-0007NS-ON; Tue, 03 Feb 2004 07:28:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnzeA-0007FK-VB for simple@optimus.ietf.org; Tue, 03 Feb 2004 07:27:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06335 for ; Tue, 3 Feb 2004 07:27:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnzeA-0002W8-00 for simple@ietf.org; Tue, 03 Feb 2004 07:27:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnzdH-0002Qp-00 for simple@ietf.org; Tue, 03 Feb 2004 07:26:23 -0500 Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx with esmtp (Exim 4.12) id 1AnzcO-0002Fz-00 for simple@ietf.org; Tue, 03 Feb 2004 07:25:28 -0500 Received: from eamrcnt748.exu.ericsson.se (eamrcnt748.exu.ericsson.se [138.85.133.46]) by imr1.ericy.com (8.12.10/8.12.10) with ESMTP id i13COqbj014327 for ; Tue, 3 Feb 2004 06:24:52 -0600 (CST) Received: from eamrcnt750.exu.ericsson.se ([138.85.133.51]) by eamrcnt748.exu.ericsson.se with Microsoft SMTPSVC(5.0.2195.6713); Tue, 3 Feb 2004 06:21:03 -0600 Received: by eamrcnt750.exu.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Tue, 3 Feb 2004 06:24:53 -0600 Message-ID: <2DBF697D5B36014ABA46E66A96107DA02C94E4@lmc37.lmc.ericsson.se> From: "George Foti (QC/EMC)" To: "'hisham.khartabil@nokia.com'" , simple@ietf.org Subject: RE: [Simple] Comments on Pres-Filter-Reqs-03 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 03 Feb 2004 12:21:03.0062 (UTC) FILETIME=[30A09760:01C3EA50] Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.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, 3 Feb 2004 06:24:07 -0600 X-Spam-Checker-Version: SpamAssassin 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 I have more questions/comments Hisham, 1) I initially understood that these are requirments on the watcher and not the PS. Now there are clearly a mix of both which is okay, as long as the scope clearly states that, and that it is clear from the requirement whether this is a PS or a watcher requirement. With that in mind, Req C1 needs to be clarified, as it incorrect the way it is currently stated. 2) You did not sepcifically address the behavior of the PS when it comes to a SUBSCRIBE holding multilple filters. Is the PS suppose to check that the filters dont contradict each other, or is this a watcher problem, or even an implmentation issue I would like to see the requirement clearer in that regard. 3) You misunderstood my comment on Req C6, so I will reword - I wonder the usefulness of the requirement. It seems more natural for a watcher to state in a filter what he would like to receieve, rather what he does not want to receieve. 4) Finally, I would like to add a requirement in which the watcher indicates his *willingness* to receive binary XML. This allows PS to conveny presence information in that format, if it supports that, but does not oblige compliance. Thanks. /gf > -----Original Message----- > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > Sent: Tuesday, February 03, 2004 5:03 AM > To: George Foti (QC/EMC); simple@ietf.org > Subject: RE: [Simple] Comments on Pres-Filter-Reqs-03 > > > George, > > Thanks for the comments. > > > -----Original Message----- > > From: simple-admin@ietf.org > [mailto:simple-admin@ietf.org]On Behalf Of > > ext George Foti (QC/EMC) > > Sent: 02.February.2004 14:30 > > To: simple@ietf.org > > Subject: [Simple] Comments on Pres-Filter-Reqs-03 > > > > > > HI, > > > > I have few questions/comments on the presence filter > > requirements 03 draft: > > > > Req C1 : It does not seem that this is a requirment on the > > watcher, rather the presence server. Otherwise, I dont get that one. > > You are correct. > > > > > Req C6: I wonder the usefulness of the requirement. It seems > > more natural to say what you want rather what you dont want to see. > > The requirement states what you want. > > > > Req D1 & Req I4 : I conclude from those 2 requirements that > > there can be multiple filters within a single SUBSCRIBE. If > > that is the case, I would like to understand whether the > > presence server is expected to ensure that the 2 filters dont > > contradict each other. > > Yes it is. > > > > > Req G7: Is this a watcher requirement or a presence server > > requirement. > > Server. > > > > > Req. I1: This is a presence server requirement. Also, I dont > > understand the reasons for it and what would the PS send the > > watcher in this case. > > Polite blocking. You might not want to tell a watcher that > he's not allowed to see certain parts of your presence > information. So you accept the filter, but give false information. > > > > > Req I6: I dont understand that one. May be wording changes > > can clarify it a bit better, > > An RLS fans out subscriptions. If there is a filter for > someone is domain1.com, the RLS should not forward that > filter to domian2.com. > > /Hisham > > > > > Rgd/gf > > Ericsson Canada > > > > > > This communication is confidential and intended solely for > > the addressee(s). Any unauthorized review, use, disclosure or > > distribution is prohibited. If you believe this message has > > been sent to you in error, please notify the sender by > > replying to this transmission and delete the message without > > disclosing it. Thank you. > > > > E-mail including attachments is susceptible to data > > corruption, interruption, unauthorized amendment, tampering > > and viruses, and we only send and receive e-mails on the > > basis that we are not liable for any such corruption, > > interception, amendment, tampering or viruses or any > > consequences thereof. > > > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > > > This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Feb 3 07:48: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 HAA07025 for ; Tue, 3 Feb 2004 07:48:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnzyX-0004bl-00 for simple-archive@ietf.org; Tue, 03 Feb 2004 07:48:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnzxW-0004Ux-00 for simple-archive@ietf.org; Tue, 03 Feb 2004 07:47:19 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AnzwY-0004OK-00; Tue, 03 Feb 2004 07:46:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnzwH-0000q3-EJ; Tue, 03 Feb 2004 07:46:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Anzvb-0000o7-MS for simple@optimus.ietf.org; Tue, 03 Feb 2004 07:45:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06896 for ; Tue, 3 Feb 2004 07:45:18 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Anzva-0004I8-00 for simple@ietf.org; Tue, 03 Feb 2004 07:45:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Anzuc-0004C3-00 for simple@ietf.org; Tue, 03 Feb 2004 07:44:19 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1Anzth-000463-00 for simple@ietf.org; Tue, 03 Feb 2004 07:43:21 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i13ChKM13124 for ; Tue, 3 Feb 2004 14:43:20 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 3 Feb 2004 14:43:13 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 3 Feb 2004 14:43:13 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 3 Feb 2004 14:43:12 +0200 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Comments on Pres-Filter-Reqs-03 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017976CB@esebe019.ntc.nokia.com> Thread-Topic: [Simple] Comments on Pres-Filter-Reqs-03 Thread-Index: AcPqUL8d6VOxSGeCRo65uZbAlDBKVQAAcBKg To: , X-OriginalArrivalTime: 03 Feb 2004 12:43:12.0840 (UTC) FILETIME=[493C9C80:01C3EA53] 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, 3 Feb 2004 14:43:12 +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.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext George Foti (QC/EMC) [mailto:george.foti@ericsson.com] > Sent: 03.February.2004 14:24 > To: Khartabil Hisham (Nokia-TP/Helsinki); simple@ietf.org > Subject: RE: [Simple] Comments on Pres-Filter-Reqs-03 >=20 >=20 > I have more questions/comments Hisham, >=20 > 1) I initially understood that these are requirments on the=20 > watcher and not the PS. Now there are clearly a mix of both=20 > which is okay, as long as the scope clearly states that, and=20 > that it is clear from the requirement whether this is a PS or=20 > a watcher requirement. With that in mind, Req C1 needs to be=20 > clarified, as it incorrect the way it is currently stated. These are requirements for the filtering solution. Some things are = required by the client, others by the server >=20 > 2) You did not sepcifically address the behavior of the PS=20 > when it comes to a SUBSCRIBE holding multilple filters. > Is the PS suppose to check that the filters dont contradict=20 > each other, or is this a watcher problem, or even an=20 > implmentation issue > I would like to see the requirement clearer in that regard. You are tapping into the solution space. New versions of the solution = drafts will be available shortly. >=20 > 3) You misunderstood my comment on Req C6, so I will reword -=20 > I wonder the usefulness of the requirement. It seems more=20 > natural for a watcher to state in a filter what he would like=20 > to receieve, rather what he does not want to receieve. A watcher can ask for information to be included in the notification = using a namespace. Allowing the watcher to exclude elements that are in = the namespace that are of no interest to him is what this requirement is = talking about. >=20 > 4) Finally, I would like to add a requirement in which the=20 > watcher indicates his *willingness* to receive binary XML.=20 > This allows PS to conveny presence information in that=20 > format, if it supports that, but does not oblige compliance. Excuse my ignorance, but I don't know what binary XML is. In any case, I = think this is a general issue, not specific for requests carrying = filters. Thanks again for the comments. Hisham >=20 > Thanks. >=20 > /gf >=20 > > -----Original Message----- > > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > > Sent: Tuesday, February 03, 2004 5:03 AM > > To: George Foti (QC/EMC); simple@ietf.org > > Subject: RE: [Simple] Comments on Pres-Filter-Reqs-03 > >=20 > >=20 > > George, > >=20 > > Thanks for the comments. > >=20 > > > -----Original Message----- > > > From: simple-admin@ietf.org=20 > > [mailto:simple-admin@ietf.org]On Behalf Of > > > ext George Foti (QC/EMC) > > > Sent: 02.February.2004 14:30 > > > To: simple@ietf.org > > > Subject: [Simple] Comments on Pres-Filter-Reqs-03 > > >=20 > > >=20 > > > HI, > > >=20 > > > I have few questions/comments on the presence filter=20 > > > requirements 03 draft: > > >=20 > > > Req C1 : It does not seem that this is a requirment on the=20 > > > watcher, rather the presence server. Otherwise, I dont=20 > get that one. > >=20 > > You are correct. > >=20 > > >=20 > > > Req C6: I wonder the usefulness of the requirement. It seems=20 > > > more natural to say what you want rather what you dont=20 > want to see.=20 > >=20 > > The requirement states what you want. > > >=20 > > > Req D1 & Req I4 : I conclude from those 2 requirements that=20 > > > there can be multiple filters within a single SUBSCRIBE. If=20 > > > that is the case, I would like to understand whether the=20 > > > presence server is expected to ensure that the 2 filters dont=20 > > > contradict each other. > >=20 > > Yes it is. > >=20 > > > =20 > > > Req G7: Is this a watcher requirement or a presence server=20 > > > requirement.=20 > >=20 > > Server. > >=20 > > >=20 > > > Req. I1: This is a presence server requirement. Also, I dont=20 > > > understand the reasons for it and what would the PS send the=20 > > > watcher in this case. > >=20 > > Polite blocking. You might not want to tell a watcher that=20 > > he's not allowed to see certain parts of your presence=20 > > information. So you accept the filter, but give false information. > >=20 > > >=20 > > > Req I6: I dont understand that one. May be wording changes=20 > > > can clarify it a bit better, > >=20 > > An RLS fans out subscriptions. If there is a filter for=20 > > someone is domain1.com, the RLS should not forward that=20 > > filter to domian2.com. > >=20 > > /Hisham > >=20 > > >=20 > > > Rgd/gf > > > Ericsson Canada=20 > > >=20 > > >=20 > > > This communication is confidential and intended solely for=20 > > > the addressee(s). Any unauthorized review, use, disclosure or=20 > > > distribution is prohibited. If you believe this message has=20 > > > been sent to you in error, please notify the sender by=20 > > > replying to this transmission and delete the message without=20 > > > disclosing it. Thank you. > > >=20 > > > E-mail including attachments is susceptible to data=20 > > > corruption, interruption, unauthorized amendment, tampering=20 > > > and viruses, and we only send and receive e-mails on the=20 > > > basis that we are not liable for any such corruption,=20 > > > interception, amendment, tampering or viruses or any=20 > > > consequences thereof. > > >=20 > > > _______________________________________________ > > > Simple mailing list > > > Simple@ietf.org > > > https://www1.ietf.org/mailman/listinfo/simple > > >=20 > >=20 >=20 >=20 > This communication is confidential and intended solely for=20 > the addressee(s). Any unauthorized review, use, disclosure or=20 > distribution is prohibited. If you believe this message has=20 > been sent to you in error, please notify the sender by=20 > replying to this transmission and delete the message without=20 > disclosing it. Thank you. >=20 > E-mail including attachments is susceptible to data=20 > corruption, interruption, unauthorized amendment, tampering=20 > and viruses, and we only send and receive e-mails on the=20 > basis that we are not liable for any such corruption,=20 > interception, amendment, tampering or viruses or any=20 > consequences thereof. >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Feb 3 07:48:52 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 HAA07074 for ; Tue, 3 Feb 2004 07:48:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnzyZ-0000yZ-F8 for simple-archive@odin.ietf.org; Tue, 03 Feb 2004 07:48:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i13CmNcG003745 for simple-archive@odin.ietf.org; Tue, 3 Feb 2004 07:48:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnzyZ-0000yK-Bj for simple-web-archive@optimus.ietf.org; Tue, 03 Feb 2004 07:48:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07043 for ; Tue, 3 Feb 2004 07:48:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnzyY-0004bq-00 for simple-web-archive@ietf.org; Tue, 03 Feb 2004 07:48:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnzxX-0004V5-00 for simple-web-archive@ietf.org; Tue, 03 Feb 2004 07:47:20 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AnzwY-0004OK-00; Tue, 03 Feb 2004 07:46:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnzwH-0000q3-EJ; Tue, 03 Feb 2004 07:46:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Anzvb-0000o7-MS for simple@optimus.ietf.org; Tue, 03 Feb 2004 07:45:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06896 for ; Tue, 3 Feb 2004 07:45:18 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Anzva-0004I8-00 for simple@ietf.org; Tue, 03 Feb 2004 07:45:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Anzuc-0004C3-00 for simple@ietf.org; Tue, 03 Feb 2004 07:44:19 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1Anzth-000463-00 for simple@ietf.org; Tue, 03 Feb 2004 07:43:21 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i13ChKM13124 for ; Tue, 3 Feb 2004 14:43:20 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 3 Feb 2004 14:43:13 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 3 Feb 2004 14:43:13 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 3 Feb 2004 14:43:12 +0200 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Comments on Pres-Filter-Reqs-03 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017976CB@esebe019.ntc.nokia.com> Thread-Topic: [Simple] Comments on Pres-Filter-Reqs-03 Thread-Index: AcPqUL8d6VOxSGeCRo65uZbAlDBKVQAAcBKg To: , X-OriginalArrivalTime: 03 Feb 2004 12:43:12.0840 (UTC) FILETIME=[493C9C80:01C3EA53] 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, 3 Feb 2004 14:43:12 +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.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 George Foti (QC/EMC) [mailto:george.foti@ericsson.com] > Sent: 03.February.2004 14:24 > To: Khartabil Hisham (Nokia-TP/Helsinki); simple@ietf.org > Subject: RE: [Simple] Comments on Pres-Filter-Reqs-03 >=20 >=20 > I have more questions/comments Hisham, >=20 > 1) I initially understood that these are requirments on the=20 > watcher and not the PS. Now there are clearly a mix of both=20 > which is okay, as long as the scope clearly states that, and=20 > that it is clear from the requirement whether this is a PS or=20 > a watcher requirement. With that in mind, Req C1 needs to be=20 > clarified, as it incorrect the way it is currently stated. These are requirements for the filtering solution. Some things are = required by the client, others by the server >=20 > 2) You did not sepcifically address the behavior of the PS=20 > when it comes to a SUBSCRIBE holding multilple filters. > Is the PS suppose to check that the filters dont contradict=20 > each other, or is this a watcher problem, or even an=20 > implmentation issue > I would like to see the requirement clearer in that regard. You are tapping into the solution space. New versions of the solution = drafts will be available shortly. >=20 > 3) You misunderstood my comment on Req C6, so I will reword -=20 > I wonder the usefulness of the requirement. It seems more=20 > natural for a watcher to state in a filter what he would like=20 > to receieve, rather what he does not want to receieve. A watcher can ask for information to be included in the notification = using a namespace. Allowing the watcher to exclude elements that are in = the namespace that are of no interest to him is what this requirement is = talking about. >=20 > 4) Finally, I would like to add a requirement in which the=20 > watcher indicates his *willingness* to receive binary XML.=20 > This allows PS to conveny presence information in that=20 > format, if it supports that, but does not oblige compliance. Excuse my ignorance, but I don't know what binary XML is. In any case, I = think this is a general issue, not specific for requests carrying = filters. Thanks again for the comments. Hisham >=20 > Thanks. >=20 > /gf >=20 > > -----Original Message----- > > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > > Sent: Tuesday, February 03, 2004 5:03 AM > > To: George Foti (QC/EMC); simple@ietf.org > > Subject: RE: [Simple] Comments on Pres-Filter-Reqs-03 > >=20 > >=20 > > George, > >=20 > > Thanks for the comments. > >=20 > > > -----Original Message----- > > > From: simple-admin@ietf.org=20 > > [mailto:simple-admin@ietf.org]On Behalf Of > > > ext George Foti (QC/EMC) > > > Sent: 02.February.2004 14:30 > > > To: simple@ietf.org > > > Subject: [Simple] Comments on Pres-Filter-Reqs-03 > > >=20 > > >=20 > > > HI, > > >=20 > > > I have few questions/comments on the presence filter=20 > > > requirements 03 draft: > > >=20 > > > Req C1 : It does not seem that this is a requirment on the=20 > > > watcher, rather the presence server. Otherwise, I dont=20 > get that one. > >=20 > > You are correct. > >=20 > > >=20 > > > Req C6: I wonder the usefulness of the requirement. It seems=20 > > > more natural to say what you want rather what you dont=20 > want to see.=20 > >=20 > > The requirement states what you want. > > >=20 > > > Req D1 & Req I4 : I conclude from those 2 requirements that=20 > > > there can be multiple filters within a single SUBSCRIBE. If=20 > > > that is the case, I would like to understand whether the=20 > > > presence server is expected to ensure that the 2 filters dont=20 > > > contradict each other. > >=20 > > Yes it is. > >=20 > > > =20 > > > Req G7: Is this a watcher requirement or a presence server=20 > > > requirement.=20 > >=20 > > Server. > >=20 > > >=20 > > > Req. I1: This is a presence server requirement. Also, I dont=20 > > > understand the reasons for it and what would the PS send the=20 > > > watcher in this case. > >=20 > > Polite blocking. You might not want to tell a watcher that=20 > > he's not allowed to see certain parts of your presence=20 > > information. So you accept the filter, but give false information. > >=20 > > >=20 > > > Req I6: I dont understand that one. May be wording changes=20 > > > can clarify it a bit better, > >=20 > > An RLS fans out subscriptions. If there is a filter for=20 > > someone is domain1.com, the RLS should not forward that=20 > > filter to domian2.com. > >=20 > > /Hisham > >=20 > > >=20 > > > Rgd/gf > > > Ericsson Canada=20 > > >=20 > > >=20 > > > This communication is confidential and intended solely for=20 > > > the addressee(s). Any unauthorized review, use, disclosure or=20 > > > distribution is prohibited. If you believe this message has=20 > > > been sent to you in error, please notify the sender by=20 > > > replying to this transmission and delete the message without=20 > > > disclosing it. Thank you. > > >=20 > > > E-mail including attachments is susceptible to data=20 > > > corruption, interruption, unauthorized amendment, tampering=20 > > > and viruses, and we only send and receive e-mails on the=20 > > > basis that we are not liable for any such corruption,=20 > > > interception, amendment, tampering or viruses or any=20 > > > consequences thereof. > > >=20 > > > _______________________________________________ > > > Simple mailing list > > > Simple@ietf.org > > > https://www1.ietf.org/mailman/listinfo/simple > > >=20 > >=20 >=20 >=20 > This communication is confidential and intended solely for=20 > the addressee(s). Any unauthorized review, use, disclosure or=20 > distribution is prohibited. If you believe this message has=20 > been sent to you in error, please notify the sender by=20 > replying to this transmission and delete the message without=20 > disclosing it. Thank you. >=20 > E-mail including attachments is susceptible to data=20 > corruption, interruption, unauthorized amendment, tampering=20 > and viruses, and we only send and receive e-mails on the=20 > basis that we are not liable for any such corruption,=20 > interception, amendment, tampering or viruses or any=20 > consequences thereof. >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Feb 3 12:24:36 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19872 for ; Tue, 3 Feb 2004 12:24:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao4Hu-0003W8-00 for simple-archive@ietf.org; Tue, 03 Feb 2004 12:24:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao4H0-0003QB-00 for simple-archive@ietf.org; Tue, 03 Feb 2004 12:23:43 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ao4GR-0003Jj-00; Tue, 03 Feb 2004 12:23:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao4GL-0002Fv-7k; Tue, 03 Feb 2004 12:23:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao4G6-0002Eg-6i for simple@optimus.ietf.org; Tue, 03 Feb 2004 12:22:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19800 for ; Tue, 3 Feb 2004 12:22:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao4G4-0003J8-00 for simple@ietf.org; Tue, 03 Feb 2004 12:22:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao4FJ-0003DD-00 for simple@ietf.org; Tue, 03 Feb 2004 12:21:58 -0500 Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx with esmtp (Exim 4.12) id 1Ao4Ef-00030x-00 for simple@ietf.org; Tue, 03 Feb 2004 12:21:17 -0500 Received: from eamrcnt748.exu.ericsson.se (eamrcnt748.exu.ericsson.se [138.85.133.46]) by imr2.ericy.com (8.12.10/8.12.10) with ESMTP id i13HKfFX018174 for ; Tue, 3 Feb 2004 11:20:41 -0600 (CST) Received: from eamrcnt750.exu.ericsson.se ([138.85.133.51]) by eamrcnt748.exu.ericsson.se with Microsoft SMTPSVC(5.0.2195.6713); Tue, 3 Feb 2004 11:16:45 -0600 Received: by eamrcnt750.exu.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Tue, 3 Feb 2004 11:20:35 -0600 Message-ID: <2DBF697D5B36014ABA46E66A96107DA02C94EF@lmc37.lmc.ericsson.se> From: "George Foti (QC/EMC)" To: "'hisham.khartabil@nokia.com'" , simple@ietf.org Subject: RE: [Simple] Comments on Pres-Filter-Reqs-03 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 03 Feb 2004 17:16:45.0281 (UTC) FILETIME=[7FD05D10:01C3EA79] Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.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, 3 Feb 2004 11:19:49 -0600 X-Spam-Checker-Version: SpamAssassin 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 Hisham you wrote : >Excuse my ignorance, but I don't know what binary XML is. In any case, I think this is a general issue, not specific for requests carrying filters. The VBXML is a WAP specification. The link is: http://www.openmobilealliance.org/tech/affiliates/LicenseAgreement.asp?DocName=/wap/wap-192-wbxml-20010725-a.pdf Its applicability is for presence information returned from PS and nothing else as you seem to state. Presence traffic that can be generated can be quite large, and if you include lists, it can cause bottle necks on radio links. This requirment provides an option for devices that can deal with binary XML to indicate that. I dont see what is the problem with including such a requirement. Otherwise, there must be some supportin the draft for requirements to deal with vendor specific options in the filter, that a PS can choose to ignore, it it does not understand. Rgds/gf > -----Original Message----- > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > Sent: Tuesday, February 03, 2004 7:43 AM > To: George Foti (QC/EMC); simple@ietf.org > Subject: RE: [Simple] Comments on Pres-Filter-Reqs-03 > > > > > > -----Original Message----- > > From: ext George Foti (QC/EMC) [mailto:george.foti@ericsson.com] > > Sent: 03.February.2004 14:24 > > To: Khartabil Hisham (Nokia-TP/Helsinki); simple@ietf.org > > Subject: RE: [Simple] Comments on Pres-Filter-Reqs-03 > > > > > > I have more questions/comments Hisham, > > > > 1) I initially understood that these are requirments on the > > watcher and not the PS. Now there are clearly a mix of both > > which is okay, as long as the scope clearly states that, and > > that it is clear from the requirement whether this is a PS or > > a watcher requirement. With that in mind, Req C1 needs to be > > clarified, as it incorrect the way it is currently stated. > > These are requirements for the filtering solution. Some > things are required by the client, others by the server > > > > 2) You did not sepcifically address the behavior of the PS > > when it comes to a SUBSCRIBE holding multilple filters. > > Is the PS suppose to check that the filters dont contradict > > each other, or is this a watcher problem, or even an > > implmentation issue > > I would like to see the requirement clearer in that regard. > > You are tapping into the solution space. New versions of the > solution drafts will be available shortly. > > > > 3) You misunderstood my comment on Req C6, so I will reword - > > I wonder the usefulness of the requirement. It seems more > > natural for a watcher to state in a filter what he would like > > to receieve, rather what he does not want to receieve. > > A watcher can ask for information to be included in the > notification using a namespace. Allowing the watcher to > exclude elements that are in the namespace that are of no > interest to him is what this requirement is talking about. > > > > > 4) Finally, I would like to add a requirement in which the > > watcher indicates his *willingness* to receive binary XML. > > This allows PS to conveny presence information in that > > format, if it supports that, but does not oblige compliance. > > Excuse my ignorance, but I don't know what binary XML is. In > any case, I think this is a general issue, not specific for > requests carrying filters. > > Thanks again for the comments. > Hisham > > > > > Thanks. > > > > /gf > > > > > -----Original Message----- > > > From: hisham.khartabil@nokia.com > [mailto:hisham.khartabil@nokia.com] > > > Sent: Tuesday, February 03, 2004 5:03 AM > > > To: George Foti (QC/EMC); simple@ietf.org > > > Subject: RE: [Simple] Comments on Pres-Filter-Reqs-03 > > > > > > > > > George, > > > > > > Thanks for the comments. > > > > > > > -----Original Message----- > > > > From: simple-admin@ietf.org > > > [mailto:simple-admin@ietf.org]On Behalf Of > > > > ext George Foti (QC/EMC) > > > > Sent: 02.February.2004 14:30 > > > > To: simple@ietf.org > > > > Subject: [Simple] Comments on Pres-Filter-Reqs-03 > > > > > > > > > > > > HI, > > > > > > > > I have few questions/comments on the presence filter > > > > requirements 03 draft: > > > > > > > > Req C1 : It does not seem that this is a requirment on the > > > > watcher, rather the presence server. Otherwise, I dont > > get that one. > > > > > > You are correct. > > > > > > > > > > > Req C6: I wonder the usefulness of the requirement. It seems > > > > more natural to say what you want rather what you dont > > want to see. > > > > > > The requirement states what you want. > > > > > > > > Req D1 & Req I4 : I conclude from those 2 requirements that > > > > there can be multiple filters within a single SUBSCRIBE. If > > > > that is the case, I would like to understand whether the > > > > presence server is expected to ensure that the 2 filters dont > > > > contradict each other. > > > > > > Yes it is. > > > > > > > > > > > Req G7: Is this a watcher requirement or a presence server > > > > requirement. > > > > > > Server. > > > > > > > > > > > Req. I1: This is a presence server requirement. Also, I dont > > > > understand the reasons for it and what would the PS send the > > > > watcher in this case. > > > > > > Polite blocking. You might not want to tell a watcher that > > > he's not allowed to see certain parts of your presence > > > information. So you accept the filter, but give false information. > > > > > > > > > > > Req I6: I dont understand that one. May be wording changes > > > > can clarify it a bit better, > > > > > > An RLS fans out subscriptions. If there is a filter for > > > someone is domain1.com, the RLS should not forward that > > > filter to domian2.com. > > > > > > /Hisham > > > > > > > > > > > Rgd/gf > > > > Ericsson Canada > > > > > > > > > > > > This communication is confidential and intended solely for > > > > the addressee(s). Any unauthorized review, use, disclosure or > > > > distribution is prohibited. If you believe this message has > > > > been sent to you in error, please notify the sender by > > > > replying to this transmission and delete the message without > > > > disclosing it. Thank you. > > > > > > > > E-mail including attachments is susceptible to data > > > > corruption, interruption, unauthorized amendment, tampering > > > > and viruses, and we only send and receive e-mails on the > > > > basis that we are not liable for any such corruption, > > > > interception, amendment, tampering or viruses or any > > > > consequences thereof. > > > > > > > > _______________________________________________ > > > > Simple mailing list > > > > Simple@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/simple > > > > > > > > > > > > > This communication is confidential and intended solely for > > the addressee(s). Any unauthorized review, use, disclosure or > > distribution is prohibited. If you believe this message has > > been sent to you in error, please notify the sender by > > replying to this transmission and delete the message without > > disclosing it. Thank you. > > > > E-mail including attachments is susceptible to data > > corruption, interruption, unauthorized amendment, tampering > > and viruses, and we only send and receive e-mails on the > > basis that we are not liable for any such corruption, > > interception, amendment, tampering or viruses or any > > consequences thereof. > > > This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Feb 3 12:25:08 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 MAA19894 for ; Tue, 3 Feb 2004 12:25:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao4Hx-0002bt-4S for simple-archive@odin.ietf.org; Tue, 03 Feb 2004 12:24:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i13HOfL0010033 for simple-archive@odin.ietf.org; Tue, 3 Feb 2004 12:24:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao4Hw-0002bk-QF for simple-web-archive@optimus.ietf.org; Tue, 03 Feb 2004 12:24:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19890 for ; Tue, 3 Feb 2004 12:24:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao4Hv-0003WF-00 for simple-web-archive@ietf.org; Tue, 03 Feb 2004 12:24:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao4H1-0003QI-00 for simple-web-archive@ietf.org; Tue, 03 Feb 2004 12:23:44 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ao4GR-0003Jj-00; Tue, 03 Feb 2004 12:23:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao4GL-0002Fv-7k; Tue, 03 Feb 2004 12:23:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao4G6-0002Eg-6i for simple@optimus.ietf.org; Tue, 03 Feb 2004 12:22:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19800 for ; Tue, 3 Feb 2004 12:22:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao4G4-0003J8-00 for simple@ietf.org; Tue, 03 Feb 2004 12:22:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao4FJ-0003DD-00 for simple@ietf.org; Tue, 03 Feb 2004 12:21:58 -0500 Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx with esmtp (Exim 4.12) id 1Ao4Ef-00030x-00 for simple@ietf.org; Tue, 03 Feb 2004 12:21:17 -0500 Received: from eamrcnt748.exu.ericsson.se (eamrcnt748.exu.ericsson.se [138.85.133.46]) by imr2.ericy.com (8.12.10/8.12.10) with ESMTP id i13HKfFX018174 for ; Tue, 3 Feb 2004 11:20:41 -0600 (CST) Received: from eamrcnt750.exu.ericsson.se ([138.85.133.51]) by eamrcnt748.exu.ericsson.se with Microsoft SMTPSVC(5.0.2195.6713); Tue, 3 Feb 2004 11:16:45 -0600 Received: by eamrcnt750.exu.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Tue, 3 Feb 2004 11:20:35 -0600 Message-ID: <2DBF697D5B36014ABA46E66A96107DA02C94EF@lmc37.lmc.ericsson.se> From: "George Foti (QC/EMC)" To: "'hisham.khartabil@nokia.com'" , simple@ietf.org Subject: RE: [Simple] Comments on Pres-Filter-Reqs-03 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 03 Feb 2004 17:16:45.0281 (UTC) FILETIME=[7FD05D10:01C3EA79] Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.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, 3 Feb 2004 11:19:49 -0600 X-Spam-Checker-Version: SpamAssassin 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 Hisham you wrote : >Excuse my ignorance, but I don't know what binary XML is. In any case, I think this is a general issue, not specific for requests carrying filters. The VBXML is a WAP specification. The link is: http://www.openmobilealliance.org/tech/affiliates/LicenseAgreement.asp?DocName=/wap/wap-192-wbxml-20010725-a.pdf Its applicability is for presence information returned from PS and nothing else as you seem to state. Presence traffic that can be generated can be quite large, and if you include lists, it can cause bottle necks on radio links. This requirment provides an option for devices that can deal with binary XML to indicate that. I dont see what is the problem with including such a requirement. Otherwise, there must be some supportin the draft for requirements to deal with vendor specific options in the filter, that a PS can choose to ignore, it it does not understand. Rgds/gf > -----Original Message----- > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > Sent: Tuesday, February 03, 2004 7:43 AM > To: George Foti (QC/EMC); simple@ietf.org > Subject: RE: [Simple] Comments on Pres-Filter-Reqs-03 > > > > > > -----Original Message----- > > From: ext George Foti (QC/EMC) [mailto:george.foti@ericsson.com] > > Sent: 03.February.2004 14:24 > > To: Khartabil Hisham (Nokia-TP/Helsinki); simple@ietf.org > > Subject: RE: [Simple] Comments on Pres-Filter-Reqs-03 > > > > > > I have more questions/comments Hisham, > > > > 1) I initially understood that these are requirments on the > > watcher and not the PS. Now there are clearly a mix of both > > which is okay, as long as the scope clearly states that, and > > that it is clear from the requirement whether this is a PS or > > a watcher requirement. With that in mind, Req C1 needs to be > > clarified, as it incorrect the way it is currently stated. > > These are requirements for the filtering solution. Some > things are required by the client, others by the server > > > > 2) You did not sepcifically address the behavior of the PS > > when it comes to a SUBSCRIBE holding multilple filters. > > Is the PS suppose to check that the filters dont contradict > > each other, or is this a watcher problem, or even an > > implmentation issue > > I would like to see the requirement clearer in that regard. > > You are tapping into the solution space. New versions of the > solution drafts will be available shortly. > > > > 3) You misunderstood my comment on Req C6, so I will reword - > > I wonder the usefulness of the requirement. It seems more > > natural for a watcher to state in a filter what he would like > > to receieve, rather what he does not want to receieve. > > A watcher can ask for information to be included in the > notification using a namespace. Allowing the watcher to > exclude elements that are in the namespace that are of no > interest to him is what this requirement is talking about. > > > > > 4) Finally, I would like to add a requirement in which the > > watcher indicates his *willingness* to receive binary XML. > > This allows PS to conveny presence information in that > > format, if it supports that, but does not oblige compliance. > > Excuse my ignorance, but I don't know what binary XML is. In > any case, I think this is a general issue, not specific for > requests carrying filters. > > Thanks again for the comments. > Hisham > > > > > Thanks. > > > > /gf > > > > > -----Original Message----- > > > From: hisham.khartabil@nokia.com > [mailto:hisham.khartabil@nokia.com] > > > Sent: Tuesday, February 03, 2004 5:03 AM > > > To: George Foti (QC/EMC); simple@ietf.org > > > Subject: RE: [Simple] Comments on Pres-Filter-Reqs-03 > > > > > > > > > George, > > > > > > Thanks for the comments. > > > > > > > -----Original Message----- > > > > From: simple-admin@ietf.org > > > [mailto:simple-admin@ietf.org]On Behalf Of > > > > ext George Foti (QC/EMC) > > > > Sent: 02.February.2004 14:30 > > > > To: simple@ietf.org > > > > Subject: [Simple] Comments on Pres-Filter-Reqs-03 > > > > > > > > > > > > HI, > > > > > > > > I have few questions/comments on the presence filter > > > > requirements 03 draft: > > > > > > > > Req C1 : It does not seem that this is a requirment on the > > > > watcher, rather the presence server. Otherwise, I dont > > get that one. > > > > > > You are correct. > > > > > > > > > > > Req C6: I wonder the usefulness of the requirement. It seems > > > > more natural to say what you want rather what you dont > > want to see. > > > > > > The requirement states what you want. > > > > > > > > Req D1 & Req I4 : I conclude from those 2 requirements that > > > > there can be multiple filters within a single SUBSCRIBE. If > > > > that is the case, I would like to understand whether the > > > > presence server is expected to ensure that the 2 filters dont > > > > contradict each other. > > > > > > Yes it is. > > > > > > > > > > > Req G7: Is this a watcher requirement or a presence server > > > > requirement. > > > > > > Server. > > > > > > > > > > > Req. I1: This is a presence server requirement. Also, I dont > > > > understand the reasons for it and what would the PS send the > > > > watcher in this case. > > > > > > Polite blocking. You might not want to tell a watcher that > > > he's not allowed to see certain parts of your presence > > > information. So you accept the filter, but give false information. > > > > > > > > > > > Req I6: I dont understand that one. May be wording changes > > > > can clarify it a bit better, > > > > > > An RLS fans out subscriptions. If there is a filter for > > > someone is domain1.com, the RLS should not forward that > > > filter to domian2.com. > > > > > > /Hisham > > > > > > > > > > > Rgd/gf > > > > Ericsson Canada > > > > > > > > > > > > This communication is confidential and intended solely for > > > > the addressee(s). Any unauthorized review, use, disclosure or > > > > distribution is prohibited. If you believe this message has > > > > been sent to you in error, please notify the sender by > > > > replying to this transmission and delete the message without > > > > disclosing it. Thank you. > > > > > > > > E-mail including attachments is susceptible to data > > > > corruption, interruption, unauthorized amendment, tampering > > > > and viruses, and we only send and receive e-mails on the > > > > basis that we are not liable for any such corruption, > > > > interception, amendment, tampering or viruses or any > > > > consequences thereof. > > > > > > > > _______________________________________________ > > > > Simple mailing list > > > > Simple@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/simple > > > > > > > > > > > > > This communication is confidential and intended solely for > > the addressee(s). Any unauthorized review, use, disclosure or > > distribution is prohibited. If you believe this message has > > been sent to you in error, please notify the sender by > > replying to this transmission and delete the message without > > disclosing it. Thank you. > > > > E-mail including attachments is susceptible to data > > corruption, interruption, unauthorized amendment, tampering > > and viruses, and we only send and receive e-mails on the > > basis that we are not liable for any such corruption, > > interception, amendment, tampering or viruses or any > > consequences thereof. > > > This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Feb 3 15:15:34 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28562 for ; Tue, 3 Feb 2004 15:15:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao6xK-0006U6-00 for simple-archive@ietf.org; Tue, 03 Feb 2004 15:15:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao6wM-0006PC-00 for simple-archive@ietf.org; Tue, 03 Feb 2004 15:14:36 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ao6w1-0006Kf-00; Tue, 03 Feb 2004 15:14:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao6vp-0003bt-5o; Tue, 03 Feb 2004 15:14:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao6vT-0003Px-5b for simple@optimus.ietf.org; Tue, 03 Feb 2004 15:13:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28398 for ; Tue, 3 Feb 2004 15:13:37 -0500 (EST) From: Markus.Isomaki@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao6vR-0006KR-00 for simple@ietf.org; Tue, 03 Feb 2004 15:13:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao6uX-0006Fa-00 for simple@ietf.org; Tue, 03 Feb 2004 15:12:42 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1Ao6uH-0006A8-00 for simple@ietf.org; Tue, 03 Feb 2004 15:12:25 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i13KCFM08844 for ; Tue, 3 Feb 2004 22:12:17 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 3 Feb 2004 22:12:14 +0200 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 3 Feb 2004 22:12:13 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Comments on Pres-Filter-Reqs-03 Message-ID: Thread-Topic: [Simple] Comments on Pres-Filter-Reqs-03 Thread-Index: AcPqem6mrZ44nODNQy6gdtJyG+C3dgAFcUkQ To: , , X-OriginalArrivalTime: 03 Feb 2004 20:12:13.0846 (UTC) FILETIME=[0353E360:01C3EA92] 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, 3 Feb 2004 22:12:13 +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.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Hi George, VBXML support does not need to be part of filtering. You could indicate = support for it in Accept header in SUBSCRIBE. See for instance Chapter = 4.2 in partial presence notifications draft = (http://www.ietf.org/internet-drafts/draft-ietf-simple-partial-notify-01.= txt). I guess for this you would need to define the correct VBXML coded = PIDF content type first, though. Also remember that Signaling Compression can be used to compress = presence information, or other SIP payloads, over radio links, and = indeed the partial notification draft is also available. Lastly, you = could use content indirection to avoid overloading the signaling bearer, = depending on what kind of SIP network you are on. Markus > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > ext George Foti (QC/EMC) > Sent: 03 February, 2004 19:20 > To: Khartabil Hisham (Nokia-TP/Helsinki); simple@ietf.org > Subject: RE: [Simple] Comments on Pres-Filter-Reqs-03 >=20 >=20 > Hisham you wrote : > >Excuse my ignorance, but I don't know what binary XML is. In=20 > any case, I think this is a general issue, not specific for=20 > requests carrying filters. >=20 > The VBXML is a WAP specification. The link is: >=20 > http://www.openmobilealliance.org/tech/affiliates/LicenseAgree > ment.asp?DocName=3D/wap/wap-192-wbxml-20010725-a.pdf >=20 > Its applicability is for presence information returned from=20 > PS and nothing else as you seem to state. Presence traffic=20 > that can be generated can be quite large, and if you include=20 > lists, it can cause bottle necks on radio links. > This requirment provides an option for devices that can deal=20 > with binary XML to indicate that. > I dont see what is the problem with including such a requirement.=20 > Otherwise, there must be some supportin the draft for=20 > requirements to deal with vendor specific options in the=20 > filter, that a PS can choose to ignore, it it does not understand.=20 >=20 > Rgds/gf > =20 >=20 >=20 > > -----Original Message----- > > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > > Sent: Tuesday, February 03, 2004 7:43 AM > > To: George Foti (QC/EMC); simple@ietf.org > > Subject: RE: [Simple] Comments on Pres-Filter-Reqs-03 > >=20 > >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: ext George Foti (QC/EMC) [mailto:george.foti@ericsson.com] > > > Sent: 03.February.2004 14:24 > > > To: Khartabil Hisham (Nokia-TP/Helsinki); simple@ietf.org > > > Subject: RE: [Simple] Comments on Pres-Filter-Reqs-03 > > >=20 > > >=20 > > > I have more questions/comments Hisham, > > >=20 > > > 1) I initially understood that these are requirments on the=20 > > > watcher and not the PS. Now there are clearly a mix of both=20 > > > which is okay, as long as the scope clearly states that, and=20 > > > that it is clear from the requirement whether this is a PS or=20 > > > a watcher requirement. With that in mind, Req C1 needs to be=20 > > > clarified, as it incorrect the way it is currently stated. > >=20 > > These are requirements for the filtering solution. Some=20 > > things are required by the client, others by the server > > >=20 > > > 2) You did not sepcifically address the behavior of the PS=20 > > > when it comes to a SUBSCRIBE holding multilple filters. > > > Is the PS suppose to check that the filters dont contradict=20 > > > each other, or is this a watcher problem, or even an=20 > > > implmentation issue > > > I would like to see the requirement clearer in that regard. > >=20 > > You are tapping into the solution space. New versions of the=20 > > solution drafts will be available shortly. > > >=20 > > > 3) You misunderstood my comment on Req C6, so I will reword -=20 > > > I wonder the usefulness of the requirement. It seems more=20 > > > natural for a watcher to state in a filter what he would like=20 > > > to receieve, rather what he does not want to receieve. > >=20 > > A watcher can ask for information to be included in the=20 > > notification using a namespace. Allowing the watcher to=20 > > exclude elements that are in the namespace that are of no=20 > > interest to him is what this requirement is talking about. > >=20 > > >=20 > > > 4) Finally, I would like to add a requirement in which the=20 > > > watcher indicates his *willingness* to receive binary XML.=20 > > > This allows PS to conveny presence information in that=20 > > > format, if it supports that, but does not oblige compliance. > >=20 > > Excuse my ignorance, but I don't know what binary XML is. In=20 > > any case, I think this is a general issue, not specific for=20 > > requests carrying filters. > >=20 > > Thanks again for the comments. > > Hisham > >=20 > > >=20 > > > Thanks. > > >=20 > > > /gf > > >=20 > > > > -----Original Message----- > > > > From: hisham.khartabil@nokia.com=20 > > [mailto:hisham.khartabil@nokia.com] > > > > Sent: Tuesday, February 03, 2004 5:03 AM > > > > To: George Foti (QC/EMC); simple@ietf.org > > > > Subject: RE: [Simple] Comments on Pres-Filter-Reqs-03 > > > >=20 > > > >=20 > > > > George, > > > >=20 > > > > Thanks for the comments. > > > >=20 > > > > > -----Original Message----- > > > > > From: simple-admin@ietf.org=20 > > > > [mailto:simple-admin@ietf.org]On Behalf Of > > > > > ext George Foti (QC/EMC) > > > > > Sent: 02.February.2004 14:30 > > > > > To: simple@ietf.org > > > > > Subject: [Simple] Comments on Pres-Filter-Reqs-03 > > > > >=20 > > > > >=20 > > > > > HI, > > > > >=20 > > > > > I have few questions/comments on the presence filter=20 > > > > > requirements 03 draft: > > > > >=20 > > > > > Req C1 : It does not seem that this is a requirment on the=20 > > > > > watcher, rather the presence server. Otherwise, I dont=20 > > > get that one. > > > >=20 > > > > You are correct. > > > >=20 > > > > >=20 > > > > > Req C6: I wonder the usefulness of the requirement. It seems=20 > > > > > more natural to say what you want rather what you dont=20 > > > want to see.=20 > > > >=20 > > > > The requirement states what you want. > > > > >=20 > > > > > Req D1 & Req I4 : I conclude from those 2 requirements that=20 > > > > > there can be multiple filters within a single SUBSCRIBE. If=20 > > > > > that is the case, I would like to understand whether the=20 > > > > > presence server is expected to ensure that the 2 filters dont=20 > > > > > contradict each other. > > > >=20 > > > > Yes it is. > > > >=20 > > > > > =20 > > > > > Req G7: Is this a watcher requirement or a presence server=20 > > > > > requirement.=20 > > > >=20 > > > > Server. > > > >=20 > > > > >=20 > > > > > Req. I1: This is a presence server requirement. Also, I dont=20 > > > > > understand the reasons for it and what would the PS send the=20 > > > > > watcher in this case. > > > >=20 > > > > Polite blocking. You might not want to tell a watcher that=20 > > > > he's not allowed to see certain parts of your presence=20 > > > > information. So you accept the filter, but give false=20 > information. > > > >=20 > > > > >=20 > > > > > Req I6: I dont understand that one. May be wording changes=20 > > > > > can clarify it a bit better, > > > >=20 > > > > An RLS fans out subscriptions. If there is a filter for=20 > > > > someone is domain1.com, the RLS should not forward that=20 > > > > filter to domian2.com. > > > >=20 > > > > /Hisham > > > >=20 > > > > >=20 > > > > > Rgd/gf > > > > > Ericsson Canada=20 > > > > >=20 > > > > >=20 > > > > > This communication is confidential and intended solely for=20 > > > > > the addressee(s). Any unauthorized review, use, disclosure or=20 > > > > > distribution is prohibited. If you believe this message has=20 > > > > > been sent to you in error, please notify the sender by=20 > > > > > replying to this transmission and delete the message without=20 > > > > > disclosing it. Thank you. > > > > >=20 > > > > > E-mail including attachments is susceptible to data=20 > > > > > corruption, interruption, unauthorized amendment, tampering=20 > > > > > and viruses, and we only send and receive e-mails on the=20 > > > > > basis that we are not liable for any such corruption,=20 > > > > > interception, amendment, tampering or viruses or any=20 > > > > > consequences thereof. > > > > >=20 > > > > > _______________________________________________ > > > > > Simple mailing list > > > > > Simple@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/simple > > > > >=20 > > > >=20 > > >=20 > > >=20 > > > This communication is confidential and intended solely for=20 > > > the addressee(s). Any unauthorized review, use, disclosure or=20 > > > distribution is prohibited. If you believe this message has=20 > > > been sent to you in error, please notify the sender by=20 > > > replying to this transmission and delete the message without=20 > > > disclosing it. Thank you. > > >=20 > > > E-mail including attachments is susceptible to data=20 > > > corruption, interruption, unauthorized amendment, tampering=20 > > > and viruses, and we only send and receive e-mails on the=20 > > > basis that we are not liable for any such corruption,=20 > > > interception, amendment, tampering or viruses or any=20 > > > consequences thereof. > > >=20 > >=20 >=20 >=20 > This communication is confidential and intended solely for=20 > the addressee(s). Any unauthorized review, use, disclosure or=20 > distribution is prohibited. If you believe this message has=20 > been sent to you in error, please notify the sender by=20 > replying to this transmission and delete the message without=20 > disclosing it. Thank you. >=20 > E-mail including attachments is susceptible to data=20 > corruption, interruption, unauthorized amendment, tampering=20 > and viruses, and we only send and receive e-mails on the=20 > basis that we are not liable for any such corruption,=20 > interception, amendment, tampering or viruses or any=20 > consequences thereof. >=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 Feb 3 15:16:06 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 PAA28626 for ; Tue, 3 Feb 2004 15:16:05 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao6xM-0004HT-SN for simple-archive@odin.ietf.org; Tue, 03 Feb 2004 15:15:37 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i13KFaV5016451 for simple-archive@odin.ietf.org; Tue, 3 Feb 2004 15:15:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao6xM-0004HF-Mv for simple-web-archive@optimus.ietf.org; Tue, 03 Feb 2004 15:15:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28573 for ; Tue, 3 Feb 2004 15:15:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao6xL-0006UD-00 for simple-web-archive@ietf.org; Tue, 03 Feb 2004 15:15:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao6wO-0006PJ-00 for simple-web-archive@ietf.org; Tue, 03 Feb 2004 15:14:37 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ao6w1-0006Kf-00; Tue, 03 Feb 2004 15:14:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao6vp-0003bt-5o; Tue, 03 Feb 2004 15:14:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao6vT-0003Px-5b for simple@optimus.ietf.org; Tue, 03 Feb 2004 15:13:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28398 for ; Tue, 3 Feb 2004 15:13:37 -0500 (EST) From: Markus.Isomaki@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao6vR-0006KR-00 for simple@ietf.org; Tue, 03 Feb 2004 15:13:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao6uX-0006Fa-00 for simple@ietf.org; Tue, 03 Feb 2004 15:12:42 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1Ao6uH-0006A8-00 for simple@ietf.org; Tue, 03 Feb 2004 15:12:25 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i13KCFM08844 for ; Tue, 3 Feb 2004 22:12:17 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 3 Feb 2004 22:12:14 +0200 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 3 Feb 2004 22:12:13 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Comments on Pres-Filter-Reqs-03 Message-ID: Thread-Topic: [Simple] Comments on Pres-Filter-Reqs-03 Thread-Index: AcPqem6mrZ44nODNQy6gdtJyG+C3dgAFcUkQ To: , , X-OriginalArrivalTime: 03 Feb 2004 20:12:13.0846 (UTC) FILETIME=[0353E360:01C3EA92] 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, 3 Feb 2004 22:12:13 +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.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 George, VBXML support does not need to be part of filtering. You could indicate = support for it in Accept header in SUBSCRIBE. See for instance Chapter = 4.2 in partial presence notifications draft = (http://www.ietf.org/internet-drafts/draft-ietf-simple-partial-notify-01.= txt). I guess for this you would need to define the correct VBXML coded = PIDF content type first, though. Also remember that Signaling Compression can be used to compress = presence information, or other SIP payloads, over radio links, and = indeed the partial notification draft is also available. Lastly, you = could use content indirection to avoid overloading the signaling bearer, = depending on what kind of SIP network you are on. Markus > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > ext George Foti (QC/EMC) > Sent: 03 February, 2004 19:20 > To: Khartabil Hisham (Nokia-TP/Helsinki); simple@ietf.org > Subject: RE: [Simple] Comments on Pres-Filter-Reqs-03 >=20 >=20 > Hisham you wrote : > >Excuse my ignorance, but I don't know what binary XML is. In=20 > any case, I think this is a general issue, not specific for=20 > requests carrying filters. >=20 > The VBXML is a WAP specification. The link is: >=20 > http://www.openmobilealliance.org/tech/affiliates/LicenseAgree > ment.asp?DocName=3D/wap/wap-192-wbxml-20010725-a.pdf >=20 > Its applicability is for presence information returned from=20 > PS and nothing else as you seem to state. Presence traffic=20 > that can be generated can be quite large, and if you include=20 > lists, it can cause bottle necks on radio links. > This requirment provides an option for devices that can deal=20 > with binary XML to indicate that. > I dont see what is the problem with including such a requirement.=20 > Otherwise, there must be some supportin the draft for=20 > requirements to deal with vendor specific options in the=20 > filter, that a PS can choose to ignore, it it does not understand.=20 >=20 > Rgds/gf > =20 >=20 >=20 > > -----Original Message----- > > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > > Sent: Tuesday, February 03, 2004 7:43 AM > > To: George Foti (QC/EMC); simple@ietf.org > > Subject: RE: [Simple] Comments on Pres-Filter-Reqs-03 > >=20 > >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: ext George Foti (QC/EMC) [mailto:george.foti@ericsson.com] > > > Sent: 03.February.2004 14:24 > > > To: Khartabil Hisham (Nokia-TP/Helsinki); simple@ietf.org > > > Subject: RE: [Simple] Comments on Pres-Filter-Reqs-03 > > >=20 > > >=20 > > > I have more questions/comments Hisham, > > >=20 > > > 1) I initially understood that these are requirments on the=20 > > > watcher and not the PS. Now there are clearly a mix of both=20 > > > which is okay, as long as the scope clearly states that, and=20 > > > that it is clear from the requirement whether this is a PS or=20 > > > a watcher requirement. With that in mind, Req C1 needs to be=20 > > > clarified, as it incorrect the way it is currently stated. > >=20 > > These are requirements for the filtering solution. Some=20 > > things are required by the client, others by the server > > >=20 > > > 2) You did not sepcifically address the behavior of the PS=20 > > > when it comes to a SUBSCRIBE holding multilple filters. > > > Is the PS suppose to check that the filters dont contradict=20 > > > each other, or is this a watcher problem, or even an=20 > > > implmentation issue > > > I would like to see the requirement clearer in that regard. > >=20 > > You are tapping into the solution space. New versions of the=20 > > solution drafts will be available shortly. > > >=20 > > > 3) You misunderstood my comment on Req C6, so I will reword -=20 > > > I wonder the usefulness of the requirement. It seems more=20 > > > natural for a watcher to state in a filter what he would like=20 > > > to receieve, rather what he does not want to receieve. > >=20 > > A watcher can ask for information to be included in the=20 > > notification using a namespace. Allowing the watcher to=20 > > exclude elements that are in the namespace that are of no=20 > > interest to him is what this requirement is talking about. > >=20 > > >=20 > > > 4) Finally, I would like to add a requirement in which the=20 > > > watcher indicates his *willingness* to receive binary XML.=20 > > > This allows PS to conveny presence information in that=20 > > > format, if it supports that, but does not oblige compliance. > >=20 > > Excuse my ignorance, but I don't know what binary XML is. In=20 > > any case, I think this is a general issue, not specific for=20 > > requests carrying filters. > >=20 > > Thanks again for the comments. > > Hisham > >=20 > > >=20 > > > Thanks. > > >=20 > > > /gf > > >=20 > > > > -----Original Message----- > > > > From: hisham.khartabil@nokia.com=20 > > [mailto:hisham.khartabil@nokia.com] > > > > Sent: Tuesday, February 03, 2004 5:03 AM > > > > To: George Foti (QC/EMC); simple@ietf.org > > > > Subject: RE: [Simple] Comments on Pres-Filter-Reqs-03 > > > >=20 > > > >=20 > > > > George, > > > >=20 > > > > Thanks for the comments. > > > >=20 > > > > > -----Original Message----- > > > > > From: simple-admin@ietf.org=20 > > > > [mailto:simple-admin@ietf.org]On Behalf Of > > > > > ext George Foti (QC/EMC) > > > > > Sent: 02.February.2004 14:30 > > > > > To: simple@ietf.org > > > > > Subject: [Simple] Comments on Pres-Filter-Reqs-03 > > > > >=20 > > > > >=20 > > > > > HI, > > > > >=20 > > > > > I have few questions/comments on the presence filter=20 > > > > > requirements 03 draft: > > > > >=20 > > > > > Req C1 : It does not seem that this is a requirment on the=20 > > > > > watcher, rather the presence server. Otherwise, I dont=20 > > > get that one. > > > >=20 > > > > You are correct. > > > >=20 > > > > >=20 > > > > > Req C6: I wonder the usefulness of the requirement. It seems=20 > > > > > more natural to say what you want rather what you dont=20 > > > want to see.=20 > > > >=20 > > > > The requirement states what you want. > > > > >=20 > > > > > Req D1 & Req I4 : I conclude from those 2 requirements that=20 > > > > > there can be multiple filters within a single SUBSCRIBE. If=20 > > > > > that is the case, I would like to understand whether the=20 > > > > > presence server is expected to ensure that the 2 filters dont=20 > > > > > contradict each other. > > > >=20 > > > > Yes it is. > > > >=20 > > > > > =20 > > > > > Req G7: Is this a watcher requirement or a presence server=20 > > > > > requirement.=20 > > > >=20 > > > > Server. > > > >=20 > > > > >=20 > > > > > Req. I1: This is a presence server requirement. Also, I dont=20 > > > > > understand the reasons for it and what would the PS send the=20 > > > > > watcher in this case. > > > >=20 > > > > Polite blocking. You might not want to tell a watcher that=20 > > > > he's not allowed to see certain parts of your presence=20 > > > > information. So you accept the filter, but give false=20 > information. > > > >=20 > > > > >=20 > > > > > Req I6: I dont understand that one. May be wording changes=20 > > > > > can clarify it a bit better, > > > >=20 > > > > An RLS fans out subscriptions. If there is a filter for=20 > > > > someone is domain1.com, the RLS should not forward that=20 > > > > filter to domian2.com. > > > >=20 > > > > /Hisham > > > >=20 > > > > >=20 > > > > > Rgd/gf > > > > > Ericsson Canada=20 > > > > >=20 > > > > >=20 > > > > > This communication is confidential and intended solely for=20 > > > > > the addressee(s). Any unauthorized review, use, disclosure or=20 > > > > > distribution is prohibited. If you believe this message has=20 > > > > > been sent to you in error, please notify the sender by=20 > > > > > replying to this transmission and delete the message without=20 > > > > > disclosing it. Thank you. > > > > >=20 > > > > > E-mail including attachments is susceptible to data=20 > > > > > corruption, interruption, unauthorized amendment, tampering=20 > > > > > and viruses, and we only send and receive e-mails on the=20 > > > > > basis that we are not liable for any such corruption,=20 > > > > > interception, amendment, tampering or viruses or any=20 > > > > > consequences thereof. > > > > >=20 > > > > > _______________________________________________ > > > > > Simple mailing list > > > > > Simple@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/simple > > > > >=20 > > > >=20 > > >=20 > > >=20 > > > This communication is confidential and intended solely for=20 > > > the addressee(s). Any unauthorized review, use, disclosure or=20 > > > distribution is prohibited. If you believe this message has=20 > > > been sent to you in error, please notify the sender by=20 > > > replying to this transmission and delete the message without=20 > > > disclosing it. Thank you. > > >=20 > > > E-mail including attachments is susceptible to data=20 > > > corruption, interruption, unauthorized amendment, tampering=20 > > > and viruses, and we only send and receive e-mails on the=20 > > > basis that we are not liable for any such corruption,=20 > > > interception, amendment, tampering or viruses or any=20 > > > consequences thereof. > > >=20 > >=20 >=20 >=20 > This communication is confidential and intended solely for=20 > the addressee(s). Any unauthorized review, use, disclosure or=20 > distribution is prohibited. If you believe this message has=20 > been sent to you in error, please notify the sender by=20 > replying to this transmission and delete the message without=20 > disclosing it. Thank you. >=20 > E-mail including attachments is susceptible to data=20 > corruption, interruption, unauthorized amendment, tampering=20 > and viruses, and we only send and receive e-mails on the=20 > basis that we are not liable for any such corruption,=20 > interception, amendment, tampering or viruses or any=20 > consequences thereof. >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Feb 4 07:59:06 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04255 for ; Wed, 4 Feb 2004 07:59:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoMcV-0000hV-00 for simple-archive@ietf.org; Wed, 04 Feb 2004 07:59:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoMbV-0000c4-00 for simple-archive@ietf.org; Wed, 04 Feb 2004 07:58:07 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AoMaW-0000TH-00; Wed, 04 Feb 2004 07:57:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoMaT-0002H8-24; Wed, 04 Feb 2004 07:57:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoMZb-0002Ga-HX for simple@optimus.ietf.org; Wed, 04 Feb 2004 07:56:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04219 for ; Wed, 4 Feb 2004 07:56:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoMZa-0000R8-00 for simple@ietf.org; Wed, 04 Feb 2004 07:56:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoMYe-0000Ml-00 for simple@ietf.org; Wed, 04 Feb 2004 07:55:09 -0500 Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx with esmtp (Exim 4.12) id 1AoMY0-0000E6-00 for simple@ietf.org; Wed, 04 Feb 2004 07:54:29 -0500 Received: from eamrcnt748.exu.ericsson.se (eamrcnt748.exu.ericsson.se [138.85.133.46]) by imr2.ericy.com (8.12.10/8.12.10) with ESMTP id i14CrwFX008121 for ; Wed, 4 Feb 2004 06:53:58 -0600 (CST) Received: from eamrcnt750.exu.ericsson.se ([138.85.133.51]) by eamrcnt748.exu.ericsson.se with Microsoft SMTPSVC(5.0.2195.6713); Wed, 4 Feb 2004 06:50:01 -0600 Received: by eamrcnt750.exu.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Wed, 4 Feb 2004 06:53:52 -0600 Message-ID: <2DBF697D5B36014ABA46E66A96107DA02C94F8@lmc37.lmc.ericsson.se> From: "George Foti (QC/EMC)" To: "'Markus.Isomaki@nokia.com'" , hisham.khartabil@nokia.com, simple@ietf.org Subject: RE: [Simple] Comments on Pres-Filter-Reqs-03 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 04 Feb 2004 12:50:01.0875 (UTC) FILETIME=[67742630:01C3EB1D] Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 4 Feb 2004 06:53:07 -0600 X-Spam-Checker-Version: SpamAssassin 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 Thanks Markus, that addresses my requirement. > -----Original Message----- > From: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com] > Sent: Tuesday, February 03, 2004 3:12 PM > To: George Foti (QC/EMC); hisham.khartabil@nokia.com; simple@ietf.org > Subject: RE: [Simple] Comments on Pres-Filter-Reqs-03 > > > Hi George, > > VBXML support does not need to be part of filtering. You > could indicate support for it in Accept header in SUBSCRIBE. > See for instance Chapter 4.2 in partial presence > notifications draft > (http://www.ietf.org/internet-drafts/draft-ietf-simple-partial > -notify-01.txt). I guess for this you would need to define > the correct VBXML coded PIDF content type first, though. > > Also remember that Signaling Compression can be used to > compress presence information, or other SIP payloads, over > radio links, and indeed the partial notification draft is > also available. Lastly, you could use content indirection to > avoid overloading the signaling bearer, depending on what > kind of SIP network you are on. > > Markus > > > > -----Original Message----- > > From: simple-admin@ietf.org > [mailto:simple-admin@ietf.org]On Behalf Of > > ext George Foti (QC/EMC) > > Sent: 03 February, 2004 19:20 > > To: Khartabil Hisham (Nokia-TP/Helsinki); simple@ietf.org > > Subject: RE: [Simple] Comments on Pres-Filter-Reqs-03 > > > > > > Hisham you wrote : > > >Excuse my ignorance, but I don't know what binary XML is. In > > any case, I think this is a general issue, not specific for > > requests carrying filters. > > > > The VBXML is a WAP specification. The link is: > > > > http://www.openmobilealliance.org/tech/affiliates/LicenseAgree > > ment.asp?DocName=/wap/wap-192-wbxml-20010725-a.pdf > > > > Its applicability is for presence information returned from > > PS and nothing else as you seem to state. Presence traffic > > that can be generated can be quite large, and if you include > > lists, it can cause bottle necks on radio links. > > This requirment provides an option for devices that can deal > > with binary XML to indicate that. > > I dont see what is the problem with including such a requirement. > > Otherwise, there must be some supportin the draft for > > requirements to deal with vendor specific options in the > > filter, that a PS can choose to ignore, it it does not understand. > > > > Rgds/gf > > > > > > > > > -----Original Message----- > > > From: hisham.khartabil@nokia.com > [mailto:hisham.khartabil@nokia.com] > > > Sent: Tuesday, February 03, 2004 7:43 AM > > > To: George Foti (QC/EMC); simple@ietf.org > > > Subject: RE: [Simple] Comments on Pres-Filter-Reqs-03 > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: ext George Foti (QC/EMC) [mailto:george.foti@ericsson.com] > > > > Sent: 03.February.2004 14:24 > > > > To: Khartabil Hisham (Nokia-TP/Helsinki); simple@ietf.org > > > > Subject: RE: [Simple] Comments on Pres-Filter-Reqs-03 > > > > > > > > > > > > I have more questions/comments Hisham, > > > > > > > > 1) I initially understood that these are requirments on the > > > > watcher and not the PS. Now there are clearly a mix of both > > > > which is okay, as long as the scope clearly states that, and > > > > that it is clear from the requirement whether this is a PS or > > > > a watcher requirement. With that in mind, Req C1 needs to be > > > > clarified, as it incorrect the way it is currently stated. > > > > > > These are requirements for the filtering solution. Some > > > things are required by the client, others by the server > > > > > > > > 2) You did not sepcifically address the behavior of the PS > > > > when it comes to a SUBSCRIBE holding multilple filters. > > > > Is the PS suppose to check that the filters dont contradict > > > > each other, or is this a watcher problem, or even an > > > > implmentation issue > > > > I would like to see the requirement clearer in that regard. > > > > > > You are tapping into the solution space. New versions of the > > > solution drafts will be available shortly. > > > > > > > > 3) You misunderstood my comment on Req C6, so I will reword - > > > > I wonder the usefulness of the requirement. It seems more > > > > natural for a watcher to state in a filter what he would like > > > > to receieve, rather what he does not want to receieve. > > > > > > A watcher can ask for information to be included in the > > > notification using a namespace. Allowing the watcher to > > > exclude elements that are in the namespace that are of no > > > interest to him is what this requirement is talking about. > > > > > > > > > > > 4) Finally, I would like to add a requirement in which the > > > > watcher indicates his *willingness* to receive binary XML. > > > > This allows PS to conveny presence information in that > > > > format, if it supports that, but does not oblige compliance. > > > > > > Excuse my ignorance, but I don't know what binary XML is. In > > > any case, I think this is a general issue, not specific for > > > requests carrying filters. > > > > > > Thanks again for the comments. > > > Hisham > > > > > > > > > > > Thanks. > > > > > > > > /gf > > > > > > > > > -----Original Message----- > > > > > From: hisham.khartabil@nokia.com > > > [mailto:hisham.khartabil@nokia.com] > > > > > Sent: Tuesday, February 03, 2004 5:03 AM > > > > > To: George Foti (QC/EMC); simple@ietf.org > > > > > Subject: RE: [Simple] Comments on Pres-Filter-Reqs-03 > > > > > > > > > > > > > > > George, > > > > > > > > > > Thanks for the comments. > > > > > > > > > > > -----Original Message----- > > > > > > From: simple-admin@ietf.org > > > > > [mailto:simple-admin@ietf.org]On Behalf Of > > > > > > ext George Foti (QC/EMC) > > > > > > Sent: 02.February.2004 14:30 > > > > > > To: simple@ietf.org > > > > > > Subject: [Simple] Comments on Pres-Filter-Reqs-03 > > > > > > > > > > > > > > > > > > HI, > > > > > > > > > > > > I have few questions/comments on the presence filter > > > > > > requirements 03 draft: > > > > > > > > > > > > Req C1 : It does not seem that this is a requirment on the > > > > > > watcher, rather the presence server. Otherwise, I dont > > > > get that one. > > > > > > > > > > You are correct. > > > > > > > > > > > > > > > > > Req C6: I wonder the usefulness of the requirement. > It seems > > > > > > more natural to say what you want rather what you dont > > > > want to see. > > > > > > > > > > The requirement states what you want. > > > > > > > > > > > > Req D1 & Req I4 : I conclude from those 2 > requirements that > > > > > > there can be multiple filters within a single SUBSCRIBE. If > > > > > > that is the case, I would like to understand whether the > > > > > > presence server is expected to ensure that the 2 > filters dont > > > > > > contradict each other. > > > > > > > > > > Yes it is. > > > > > > > > > > > > > > > > > Req G7: Is this a watcher requirement or a presence server > > > > > > requirement. > > > > > > > > > > Server. > > > > > > > > > > > > > > > > > Req. I1: This is a presence server requirement. > Also, I dont > > > > > > understand the reasons for it and what would the PS > send the > > > > > > watcher in this case. > > > > > > > > > > Polite blocking. You might not want to tell a watcher that > > > > > he's not allowed to see certain parts of your presence > > > > > information. So you accept the filter, but give false > > information. > > > > > > > > > > > > > > > > > Req I6: I dont understand that one. May be wording changes > > > > > > can clarify it a bit better, > > > > > > > > > > An RLS fans out subscriptions. If there is a filter for > > > > > someone is domain1.com, the RLS should not forward that > > > > > filter to domian2.com. > > > > > > > > > > /Hisham > > > > > > > > > > > > > > > > > Rgd/gf > > > > > > Ericsson Canada > > > > > > > > > > > > > > > > > > This communication is confidential and intended solely for > > > > > > the addressee(s). Any unauthorized review, use, > disclosure or > > > > > > distribution is prohibited. If you believe this message has > > > > > > been sent to you in error, please notify the sender by > > > > > > replying to this transmission and delete the > message without > > > > > > disclosing it. Thank you. > > > > > > > > > > > > E-mail including attachments is susceptible to data > > > > > > corruption, interruption, unauthorized amendment, tampering > > > > > > and viruses, and we only send and receive e-mails on the > > > > > > basis that we are not liable for any such corruption, > > > > > > interception, amendment, tampering or viruses or any > > > > > > consequences thereof. > > > > > > > > > > > > _______________________________________________ > > > > > > Simple mailing list > > > > > > Simple@ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/simple > > > > > > > > > > > > > > > > > > > > > > > This communication is confidential and intended solely for > > > > the addressee(s). Any unauthorized review, use, disclosure or > > > > distribution is prohibited. If you believe this message has > > > > been sent to you in error, please notify the sender by > > > > replying to this transmission and delete the message without > > > > disclosing it. Thank you. > > > > > > > > E-mail including attachments is susceptible to data > > > > corruption, interruption, unauthorized amendment, tampering > > > > and viruses, and we only send and receive e-mails on the > > > > basis that we are not liable for any such corruption, > > > > interception, amendment, tampering or viruses or any > > > > consequences thereof. > > > > > > > > > > > > > This communication is confidential and intended solely for > > the addressee(s). Any unauthorized review, use, disclosure or > > distribution is prohibited. If you believe this message has > > been sent to you in error, please notify the sender by > > replying to this transmission and delete the message without > > disclosing it. Thank you. > > > > E-mail including attachments is susceptible to data > > corruption, interruption, unauthorized amendment, tampering > > and viruses, and we only send and receive e-mails on the > > basis that we are not liable for any such corruption, > > interception, amendment, tampering or viruses or any > > consequences thereof. > > > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > > > This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Feb 4 07:59:38 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 HAA04281 for ; Wed, 4 Feb 2004 07:59:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoMcX-0002Oj-4j for simple-archive@odin.ietf.org; Wed, 04 Feb 2004 07:59:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i14Cx9ML009213 for simple-archive@odin.ietf.org; Wed, 4 Feb 2004 07:59:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoMcX-0002OW-0m for simple-web-archive@optimus.ietf.org; Wed, 04 Feb 2004 07:59:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04275 for ; Wed, 4 Feb 2004 07:59:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoMcW-0000ha-00 for simple-web-archive@ietf.org; Wed, 04 Feb 2004 07:59:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoMbX-0000cB-00 for simple-web-archive@ietf.org; Wed, 04 Feb 2004 07:58:08 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AoMaW-0000TH-00; Wed, 04 Feb 2004 07:57:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoMaT-0002H8-24; Wed, 04 Feb 2004 07:57:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoMZb-0002Ga-HX for simple@optimus.ietf.org; Wed, 04 Feb 2004 07:56:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04219 for ; Wed, 4 Feb 2004 07:56:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoMZa-0000R8-00 for simple@ietf.org; Wed, 04 Feb 2004 07:56:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoMYe-0000Ml-00 for simple@ietf.org; Wed, 04 Feb 2004 07:55:09 -0500 Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx with esmtp (Exim 4.12) id 1AoMY0-0000E6-00 for simple@ietf.org; Wed, 04 Feb 2004 07:54:29 -0500 Received: from eamrcnt748.exu.ericsson.se (eamrcnt748.exu.ericsson.se [138.85.133.46]) by imr2.ericy.com (8.12.10/8.12.10) with ESMTP id i14CrwFX008121 for ; Wed, 4 Feb 2004 06:53:58 -0600 (CST) Received: from eamrcnt750.exu.ericsson.se ([138.85.133.51]) by eamrcnt748.exu.ericsson.se with Microsoft SMTPSVC(5.0.2195.6713); Wed, 4 Feb 2004 06:50:01 -0600 Received: by eamrcnt750.exu.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Wed, 4 Feb 2004 06:53:52 -0600 Message-ID: <2DBF697D5B36014ABA46E66A96107DA02C94F8@lmc37.lmc.ericsson.se> From: "George Foti (QC/EMC)" To: "'Markus.Isomaki@nokia.com'" , hisham.khartabil@nokia.com, simple@ietf.org Subject: RE: [Simple] Comments on Pres-Filter-Reqs-03 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 04 Feb 2004 12:50:01.0875 (UTC) FILETIME=[67742630:01C3EB1D] Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 4 Feb 2004 06:53:07 -0600 X-Spam-Checker-Version: SpamAssassin 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 Thanks Markus, that addresses my requirement. > -----Original Message----- > From: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com] > Sent: Tuesday, February 03, 2004 3:12 PM > To: George Foti (QC/EMC); hisham.khartabil@nokia.com; simple@ietf.org > Subject: RE: [Simple] Comments on Pres-Filter-Reqs-03 > > > Hi George, > > VBXML support does not need to be part of filtering. You > could indicate support for it in Accept header in SUBSCRIBE. > See for instance Chapter 4.2 in partial presence > notifications draft > (http://www.ietf.org/internet-drafts/draft-ietf-simple-partial > -notify-01.txt). I guess for this you would need to define > the correct VBXML coded PIDF content type first, though. > > Also remember that Signaling Compression can be used to > compress presence information, or other SIP payloads, over > radio links, and indeed the partial notification draft is > also available. Lastly, you could use content indirection to > avoid overloading the signaling bearer, depending on what > kind of SIP network you are on. > > Markus > > > > -----Original Message----- > > From: simple-admin@ietf.org > [mailto:simple-admin@ietf.org]On Behalf Of > > ext George Foti (QC/EMC) > > Sent: 03 February, 2004 19:20 > > To: Khartabil Hisham (Nokia-TP/Helsinki); simple@ietf.org > > Subject: RE: [Simple] Comments on Pres-Filter-Reqs-03 > > > > > > Hisham you wrote : > > >Excuse my ignorance, but I don't know what binary XML is. In > > any case, I think this is a general issue, not specific for > > requests carrying filters. > > > > The VBXML is a WAP specification. The link is: > > > > http://www.openmobilealliance.org/tech/affiliates/LicenseAgree > > ment.asp?DocName=/wap/wap-192-wbxml-20010725-a.pdf > > > > Its applicability is for presence information returned from > > PS and nothing else as you seem to state. Presence traffic > > that can be generated can be quite large, and if you include > > lists, it can cause bottle necks on radio links. > > This requirment provides an option for devices that can deal > > with binary XML to indicate that. > > I dont see what is the problem with including such a requirement. > > Otherwise, there must be some supportin the draft for > > requirements to deal with vendor specific options in the > > filter, that a PS can choose to ignore, it it does not understand. > > > > Rgds/gf > > > > > > > > > -----Original Message----- > > > From: hisham.khartabil@nokia.com > [mailto:hisham.khartabil@nokia.com] > > > Sent: Tuesday, February 03, 2004 7:43 AM > > > To: George Foti (QC/EMC); simple@ietf.org > > > Subject: RE: [Simple] Comments on Pres-Filter-Reqs-03 > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: ext George Foti (QC/EMC) [mailto:george.foti@ericsson.com] > > > > Sent: 03.February.2004 14:24 > > > > To: Khartabil Hisham (Nokia-TP/Helsinki); simple@ietf.org > > > > Subject: RE: [Simple] Comments on Pres-Filter-Reqs-03 > > > > > > > > > > > > I have more questions/comments Hisham, > > > > > > > > 1) I initially understood that these are requirments on the > > > > watcher and not the PS. Now there are clearly a mix of both > > > > which is okay, as long as the scope clearly states that, and > > > > that it is clear from the requirement whether this is a PS or > > > > a watcher requirement. With that in mind, Req C1 needs to be > > > > clarified, as it incorrect the way it is currently stated. > > > > > > These are requirements for the filtering solution. Some > > > things are required by the client, others by the server > > > > > > > > 2) You did not sepcifically address the behavior of the PS > > > > when it comes to a SUBSCRIBE holding multilple filters. > > > > Is the PS suppose to check that the filters dont contradict > > > > each other, or is this a watcher problem, or even an > > > > implmentation issue > > > > I would like to see the requirement clearer in that regard. > > > > > > You are tapping into the solution space. New versions of the > > > solution drafts will be available shortly. > > > > > > > > 3) You misunderstood my comment on Req C6, so I will reword - > > > > I wonder the usefulness of the requirement. It seems more > > > > natural for a watcher to state in a filter what he would like > > > > to receieve, rather what he does not want to receieve. > > > > > > A watcher can ask for information to be included in the > > > notification using a namespace. Allowing the watcher to > > > exclude elements that are in the namespace that are of no > > > interest to him is what this requirement is talking about. > > > > > > > > > > > 4) Finally, I would like to add a requirement in which the > > > > watcher indicates his *willingness* to receive binary XML. > > > > This allows PS to conveny presence information in that > > > > format, if it supports that, but does not oblige compliance. > > > > > > Excuse my ignorance, but I don't know what binary XML is. In > > > any case, I think this is a general issue, not specific for > > > requests carrying filters. > > > > > > Thanks again for the comments. > > > Hisham > > > > > > > > > > > Thanks. > > > > > > > > /gf > > > > > > > > > -----Original Message----- > > > > > From: hisham.khartabil@nokia.com > > > [mailto:hisham.khartabil@nokia.com] > > > > > Sent: Tuesday, February 03, 2004 5:03 AM > > > > > To: George Foti (QC/EMC); simple@ietf.org > > > > > Subject: RE: [Simple] Comments on Pres-Filter-Reqs-03 > > > > > > > > > > > > > > > George, > > > > > > > > > > Thanks for the comments. > > > > > > > > > > > -----Original Message----- > > > > > > From: simple-admin@ietf.org > > > > > [mailto:simple-admin@ietf.org]On Behalf Of > > > > > > ext George Foti (QC/EMC) > > > > > > Sent: 02.February.2004 14:30 > > > > > > To: simple@ietf.org > > > > > > Subject: [Simple] Comments on Pres-Filter-Reqs-03 > > > > > > > > > > > > > > > > > > HI, > > > > > > > > > > > > I have few questions/comments on the presence filter > > > > > > requirements 03 draft: > > > > > > > > > > > > Req C1 : It does not seem that this is a requirment on the > > > > > > watcher, rather the presence server. Otherwise, I dont > > > > get that one. > > > > > > > > > > You are correct. > > > > > > > > > > > > > > > > > Req C6: I wonder the usefulness of the requirement. > It seems > > > > > > more natural to say what you want rather what you dont > > > > want to see. > > > > > > > > > > The requirement states what you want. > > > > > > > > > > > > Req D1 & Req I4 : I conclude from those 2 > requirements that > > > > > > there can be multiple filters within a single SUBSCRIBE. If > > > > > > that is the case, I would like to understand whether the > > > > > > presence server is expected to ensure that the 2 > filters dont > > > > > > contradict each other. > > > > > > > > > > Yes it is. > > > > > > > > > > > > > > > > > Req G7: Is this a watcher requirement or a presence server > > > > > > requirement. > > > > > > > > > > Server. > > > > > > > > > > > > > > > > > Req. I1: This is a presence server requirement. > Also, I dont > > > > > > understand the reasons for it and what would the PS > send the > > > > > > watcher in this case. > > > > > > > > > > Polite blocking. You might not want to tell a watcher that > > > > > he's not allowed to see certain parts of your presence > > > > > information. So you accept the filter, but give false > > information. > > > > > > > > > > > > > > > > > Req I6: I dont understand that one. May be wording changes > > > > > > can clarify it a bit better, > > > > > > > > > > An RLS fans out subscriptions. If there is a filter for > > > > > someone is domain1.com, the RLS should not forward that > > > > > filter to domian2.com. > > > > > > > > > > /Hisham > > > > > > > > > > > > > > > > > Rgd/gf > > > > > > Ericsson Canada > > > > > > > > > > > > > > > > > > This communication is confidential and intended solely for > > > > > > the addressee(s). Any unauthorized review, use, > disclosure or > > > > > > distribution is prohibited. If you believe this message has > > > > > > been sent to you in error, please notify the sender by > > > > > > replying to this transmission and delete the > message without > > > > > > disclosing it. Thank you. > > > > > > > > > > > > E-mail including attachments is susceptible to data > > > > > > corruption, interruption, unauthorized amendment, tampering > > > > > > and viruses, and we only send and receive e-mails on the > > > > > > basis that we are not liable for any such corruption, > > > > > > interception, amendment, tampering or viruses or any > > > > > > consequences thereof. > > > > > > > > > > > > _______________________________________________ > > > > > > Simple mailing list > > > > > > Simple@ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/simple > > > > > > > > > > > > > > > > > > > > > > > This communication is confidential and intended solely for > > > > the addressee(s). Any unauthorized review, use, disclosure or > > > > distribution is prohibited. If you believe this message has > > > > been sent to you in error, please notify the sender by > > > > replying to this transmission and delete the message without > > > > disclosing it. Thank you. > > > > > > > > E-mail including attachments is susceptible to data > > > > corruption, interruption, unauthorized amendment, tampering > > > > and viruses, and we only send and receive e-mails on the > > > > basis that we are not liable for any such corruption, > > > > interception, amendment, tampering or viruses or any > > > > consequences thereof. > > > > > > > > > > > > > This communication is confidential and intended solely for > > the addressee(s). Any unauthorized review, use, disclosure or > > distribution is prohibited. If you believe this message has > > been sent to you in error, please notify the sender by > > replying to this transmission and delete the message without > > disclosing it. Thank you. > > > > E-mail including attachments is susceptible to data > > corruption, interruption, unauthorized amendment, tampering > > and viruses, and we only send and receive e-mails on the > > basis that we are not liable for any such corruption, > > interception, amendment, tampering or viruses or any > > consequences thereof. > > > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > > > This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Feb 6 15:47: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 PAA15874 for ; Fri, 6 Feb 2004 15:47:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApCtI-0002mc-00 for simple-archive@ietf.org; Fri, 06 Feb 2004 15:47:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApCsN-0002hF-00 for simple-archive@ietf.org; Fri, 06 Feb 2004 15:46:59 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ApCrX-0002cW-00; Fri, 06 Feb 2004 15:46:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApCrT-0005uY-H3; Fri, 06 Feb 2004 15:46:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApCqd-0005pg-Hn for simple@optimus.ietf.org; Fri, 06 Feb 2004 15:45:11 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15664; Fri, 6 Feb 2004 15:45:08 -0500 (EST) Message-Id: <200402062045.PAA15664@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: simple@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-filter-format-00.txt Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 06 Feb 2004 15:45:08 -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.4 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : An Extensible Markup Language (XML) Based Format for Event Notification Filtering Author(s) : Filename : draft-ietf-simple-filter-format-00.txt Pages : 19 Date : 2004-2-6 The SIP event notification framework describes the usage of the Session Initiation Protocol (SIP) for subscriptions and notifications of changes to a state of a resource. The document does not describe a mechanism of how filtering of event notification information can be achieved. In order to enable this, a format is needed to enable the subscriber to choose when notifications are to be sent to it and what they are to contain. This document presents a solution in the form of an XML document format. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-filter-format-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-filter-format-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-filter-format-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-2-6160328.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-filter-format-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-filter-format-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-6160328.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Feb 6 15:47: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 PAA15897 for ; Fri, 6 Feb 2004 15:47:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApCtK-0002mm-00 for simple-archive@ietf.org; Fri, 06 Feb 2004 15:47:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApCsO-0002hU-00 for simple-archive@ietf.org; Fri, 06 Feb 2004 15:47:01 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ApCrX-0002cX-00; Fri, 06 Feb 2004 15:46:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApCrU-0005ux-3t; Fri, 06 Feb 2004 15:46:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApCqj-0005pm-9x for simple@optimus.ietf.org; Fri, 06 Feb 2004 15:45:17 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15680; Fri, 6 Feb 2004 15:45:14 -0500 (EST) Message-Id: <200402062045.PAA15680@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: simple@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-event-filter-funct-00.txt Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 06 Feb 2004 15:45:14 -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.4 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : Functional Description of Event Notification Filtering Author(s) : H. Khartabil Filename : draft-ietf-simple-event-filter-funct-00.txt Pages : 26 Date : 2004-2-6 The SIP event notification framework describes the usage of the Session Initiation Protocol (SIP) for subscriptions and notifications of changes to a state of a resource. The document does not describe a mechanism of how filtering of event notification information can be achieved. This document describes the operations a subscriber performs in order to define filtering rules, how to handle responses to subscriptions carrying filtering rules, and how to handle notifications with filtering rules applied to them. The document also describes how the notifier behaves when receiving such filtering rules and how a notification is constructed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-event-filter-funct-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-event-filter-funct-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-event-filter-funct-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-2-6160338.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-event-filter-funct-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-event-filter-funct-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-6160338.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Feb 6 15:48:27 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 PAA15950 for ; Fri, 6 Feb 2004 15:48:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApCtL-0006JG-Bi for simple-archive@odin.ietf.org; Fri, 06 Feb 2004 15:47:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i16KlxEW024250 for simple-archive@odin.ietf.org; Fri, 6 Feb 2004 15:47:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApCtL-0006J3-6H for simple-web-archive@optimus.ietf.org; Fri, 06 Feb 2004 15:47:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15888 for ; Fri, 6 Feb 2004 15:47:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApCtJ-0002mh-00 for simple-web-archive@ietf.org; Fri, 06 Feb 2004 15:47:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApCsN-0002hM-00 for simple-web-archive@ietf.org; Fri, 06 Feb 2004 15:47:00 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ApCrX-0002cW-00; Fri, 06 Feb 2004 15:46:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApCrT-0005uY-H3; Fri, 06 Feb 2004 15:46:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApCqd-0005pg-Hn for simple@optimus.ietf.org; Fri, 06 Feb 2004 15:45:11 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15664; Fri, 6 Feb 2004 15:45:08 -0500 (EST) Message-Id: <200402062045.PAA15664@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: simple@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-filter-format-00.txt Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 06 Feb 2004 15:45:08 -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.4 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : An Extensible Markup Language (XML) Based Format for Event Notification Filtering Author(s) : Filename : draft-ietf-simple-filter-format-00.txt Pages : 19 Date : 2004-2-6 The SIP event notification framework describes the usage of the Session Initiation Protocol (SIP) for subscriptions and notifications of changes to a state of a resource. The document does not describe a mechanism of how filtering of event notification information can be achieved. In order to enable this, a format is needed to enable the subscriber to choose when notifications are to be sent to it and what they are to contain. This document presents a solution in the form of an XML document format. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-filter-format-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-filter-format-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-filter-format-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-2-6160328.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-filter-format-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-filter-format-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-6160328.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Feb 6 15:48:28 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 PAA15967 for ; Fri, 6 Feb 2004 15:48:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApCtM-0006Jn-NF for simple-archive@odin.ietf.org; Fri, 06 Feb 2004 15:48:00 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i16Km0bO024281 for simple-archive@odin.ietf.org; Fri, 6 Feb 2004 15:48:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApCtM-0006JY-Ig for simple-web-archive@optimus.ietf.org; Fri, 06 Feb 2004 15:48:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15910 for ; Fri, 6 Feb 2004 15:47:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApCtK-0002mr-00 for simple-web-archive@ietf.org; Fri, 06 Feb 2004 15:47:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApCsP-0002hc-00 for simple-web-archive@ietf.org; Fri, 06 Feb 2004 15:47:02 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ApCrX-0002cX-00; Fri, 06 Feb 2004 15:46:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApCrU-0005ux-3t; Fri, 06 Feb 2004 15:46:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApCqj-0005pm-9x for simple@optimus.ietf.org; Fri, 06 Feb 2004 15:45:17 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15680; Fri, 6 Feb 2004 15:45:14 -0500 (EST) Message-Id: <200402062045.PAA15680@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: simple@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-event-filter-funct-00.txt Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 06 Feb 2004 15:45:14 -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.4 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : Functional Description of Event Notification Filtering Author(s) : H. Khartabil Filename : draft-ietf-simple-event-filter-funct-00.txt Pages : 26 Date : 2004-2-6 The SIP event notification framework describes the usage of the Session Initiation Protocol (SIP) for subscriptions and notifications of changes to a state of a resource. The document does not describe a mechanism of how filtering of event notification information can be achieved. This document describes the operations a subscriber performs in order to define filtering rules, how to handle responses to subscriptions carrying filtering rules, and how to handle notifications with filtering rules applied to them. The document also describes how the notifier behaves when receiving such filtering rules and how a notification is constructed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-event-filter-funct-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-event-filter-funct-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-event-filter-funct-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-2-6160338.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-event-filter-funct-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-event-filter-funct-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-6160338.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Feb 9 07:39:02 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15643 for ; Mon, 9 Feb 2004 07:39:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqAgp-00001l-00 for simple-archive@ietf.org; Mon, 09 Feb 2004 07:39:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqAft-0007iH-00 for simple-archive@ietf.org; Mon, 09 Feb 2004 07:38:06 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqAey-0007bY-00; Mon, 09 Feb 2004 07:37:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqAeq-0003Tb-Ne; Mon, 09 Feb 2004 07:37:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqAdt-0003BB-AC for simple@optimus.ietf.org; Mon, 09 Feb 2004 07:36:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15504 for ; Mon, 9 Feb 2004 07:35:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqAds-0007UB-00 for simple@ietf.org; Mon, 09 Feb 2004 07:36:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqAcx-0007On-00 for simple@ietf.org; Mon, 09 Feb 2004 07:35:04 -0500 Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx with esmtp (Exim 4.12) id 1AqAc1-0007EQ-00 for simple@ietf.org; Mon, 09 Feb 2004 07:34:05 -0500 Received: from eamrcnt748.exu.ericsson.se (eamrcnt748.exu.ericsson.se [138.85.133.46]) by imr1.ericy.com (8.12.10/8.12.10) with ESMTP id i19CXTLc016164 for ; Mon, 9 Feb 2004 06:33:29 -0600 (CST) Received: from eamrcnt750.exu.ericsson.se ([138.85.133.51]) by eamrcnt748.exu.ericsson.se with Microsoft SMTPSVC(5.0.2195.6713); Mon, 9 Feb 2004 06:29:30 -0600 Received: by eamrcnt750.exu.ericsson.se with Internet Mail Service (5.5.2657.72) id <13CKYH37>; Mon, 9 Feb 2004 06:33:31 -0600 Message-ID: <2DBF697D5B36014ABA46E66A96107DA02C9521@lmc37.lmc.ericsson.se> From: "George Foti (QC/EMC)" To: "'simple@ietf.org'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-OriginalArrivalTime: 09 Feb 2004 12:29:30.0968 (UTC) FILETIME=[5DD76580:01C3EF08] Subject: [Simple] Minor Comment on draft-ietf-simple-partial-notify-01 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.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, 9 Feb 2004 06:32:39 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Hi, A minor comment on the partial-Notify-draft-01 draft. The example should be aligned with the text, so the version number in the first returned NOTIFY should be 0, instead of 1. Rgds/gf This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Feb 9 07:39:33 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 HAA15699 for ; Mon, 9 Feb 2004 07:39:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqAgr-0003u9-0t for simple-archive@odin.ietf.org; Mon, 09 Feb 2004 07:39:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i19Cd4od015003 for simple-archive@odin.ietf.org; Mon, 9 Feb 2004 07:39:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqAgq-0003tu-TR for simple-web-archive@optimus.ietf.org; Mon, 09 Feb 2004 07:39:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15660 for ; Mon, 9 Feb 2004 07:39:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqAgq-00001q-00 for simple-web-archive@ietf.org; Mon, 09 Feb 2004 07:39:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqAfu-0007iO-00 for simple-web-archive@ietf.org; Mon, 09 Feb 2004 07:38:07 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqAey-0007bY-00; Mon, 09 Feb 2004 07:37:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqAeq-0003Tb-Ne; Mon, 09 Feb 2004 07:37:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqAdt-0003BB-AC for simple@optimus.ietf.org; Mon, 09 Feb 2004 07:36:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15504 for ; Mon, 9 Feb 2004 07:35:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqAds-0007UB-00 for simple@ietf.org; Mon, 09 Feb 2004 07:36:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqAcx-0007On-00 for simple@ietf.org; Mon, 09 Feb 2004 07:35:04 -0500 Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx with esmtp (Exim 4.12) id 1AqAc1-0007EQ-00 for simple@ietf.org; Mon, 09 Feb 2004 07:34:05 -0500 Received: from eamrcnt748.exu.ericsson.se (eamrcnt748.exu.ericsson.se [138.85.133.46]) by imr1.ericy.com (8.12.10/8.12.10) with ESMTP id i19CXTLc016164 for ; Mon, 9 Feb 2004 06:33:29 -0600 (CST) Received: from eamrcnt750.exu.ericsson.se ([138.85.133.51]) by eamrcnt748.exu.ericsson.se with Microsoft SMTPSVC(5.0.2195.6713); Mon, 9 Feb 2004 06:29:30 -0600 Received: by eamrcnt750.exu.ericsson.se with Internet Mail Service (5.5.2657.72) id <13CKYH37>; Mon, 9 Feb 2004 06:33:31 -0600 Message-ID: <2DBF697D5B36014ABA46E66A96107DA02C9521@lmc37.lmc.ericsson.se> From: "George Foti (QC/EMC)" To: "'simple@ietf.org'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-OriginalArrivalTime: 09 Feb 2004 12:29:30.0968 (UTC) FILETIME=[5DD76580:01C3EF08] Subject: [Simple] Minor Comment on draft-ietf-simple-partial-notify-01 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.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, 9 Feb 2004 06:32:39 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Hi, A minor comment on the partial-Notify-draft-01 draft. The example should be aligned with the text, so the version number in the first returned NOTIFY should be 0, instead of 1. Rgds/gf This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Feb 9 08:13: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 IAA17385 for ; Mon, 9 Feb 2004 08:13:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqBDq-0003uX-00 for simple-archive@ietf.org; Mon, 09 Feb 2004 08:13:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqBCy-0003nY-00 for simple-archive@ietf.org; Mon, 09 Feb 2004 08:12:17 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqBC0-0003fq-00; Mon, 09 Feb 2004 08:11:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqBBm-0005bH-RL; Mon, 09 Feb 2004 08:11:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqBBH-0005ZS-KU for simple@optimus.ietf.org; Mon, 09 Feb 2004 08:10:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17240 for ; Mon, 9 Feb 2004 08:10:29 -0500 (EST) From: mikko.lonnfors@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqBBG-0003XR-00 for simple@ietf.org; Mon, 09 Feb 2004 08:10:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqB9p-0003Gu-00 for simple@ietf.org; Mon, 09 Feb 2004 08:09:02 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AqB86-0002uJ-00 for simple@ietf.org; Mon, 09 Feb 2004 08:07:14 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i19D7Cq17127 for ; Mon, 9 Feb 2004 15:07:12 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 9 Feb 2004 15:06:29 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 9 Feb 2004 15:06:29 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 9 Feb 2004 15:06:28 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Minor Comment on draft-ietf-simple-partial-notify-01 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF01C1DD35@esebe004.ntc.nokia.com> Thread-Topic: [Simple] Minor Comment on draft-ietf-simple-partial-notify-01 Thread-Index: AcPvCXoFhaRPxx2NSDWahOhEOOELgwAA+unQ To: , X-OriginalArrivalTime: 09 Feb 2004 13:06:28.0757 (UTC) FILETIME=[87BF2450:01C3EF0D] 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, 9 Feb 2004 15:06:26 +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.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Hi, Good catch. Will be fixed in next version. Thanks - Mikko > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org] On=20 > Behalf Of ext George Foti (QC/EMC) > Sent: Monday, February 09, 2004 2:33 PM > To: 'simple@ietf.org' > Subject: [Simple] Minor Comment on draft-ietf-simple-partial-notify-01 >=20 >=20 > Hi, > A minor comment on the partial-Notify-draft-01 draft. > The example should be aligned with the text, so the version=20 > number in the first returned NOTIFY should be 0, instead of 1. >=20 > Rgds/gf >=20 >=20 > This communication is confidential and intended solely for=20 > the addressee(s). Any unauthorized review, use, disclosure or=20 > distribution is prohibited. If you believe this message has=20 > been sent to you in error, please notify the sender by=20 > replying to this transmission and delete the message without=20 > disclosing it. Thank you. >=20 > E-mail including attachments is susceptible to data=20 > corruption, interruption, unauthorized amendment, tampering=20 > and viruses, and we only send and receive e-mails on the=20 > basis that we are not liable for any such corruption,=20 > interception, amendment, tampering or viruses or any=20 > consequences thereof. >=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 Feb 9 08:13:41 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 IAA17426 for ; Mon, 9 Feb 2004 08:13:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqBDs-0005pT-O7 for simple-archive@odin.ietf.org; Mon, 09 Feb 2004 08:13:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i19DDCeK022404 for simple-archive@odin.ietf.org; Mon, 9 Feb 2004 08:13:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqBDs-0005pH-Gy for simple-web-archive@optimus.ietf.org; Mon, 09 Feb 2004 08:13:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17402 for ; Mon, 9 Feb 2004 08:13:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqBDr-0003ud-00 for simple-web-archive@ietf.org; Mon, 09 Feb 2004 08:13:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqBCz-0003nf-00 for simple-web-archive@ietf.org; Mon, 09 Feb 2004 08:12:17 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqBC0-0003fq-00; Mon, 09 Feb 2004 08:11:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqBBm-0005bH-RL; Mon, 09 Feb 2004 08:11:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqBBH-0005ZS-KU for simple@optimus.ietf.org; Mon, 09 Feb 2004 08:10:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17240 for ; Mon, 9 Feb 2004 08:10:29 -0500 (EST) From: mikko.lonnfors@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqBBG-0003XR-00 for simple@ietf.org; Mon, 09 Feb 2004 08:10:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqB9p-0003Gu-00 for simple@ietf.org; Mon, 09 Feb 2004 08:09:02 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AqB86-0002uJ-00 for simple@ietf.org; Mon, 09 Feb 2004 08:07:14 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i19D7Cq17127 for ; Mon, 9 Feb 2004 15:07:12 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 9 Feb 2004 15:06:29 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 9 Feb 2004 15:06:29 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 9 Feb 2004 15:06:28 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Minor Comment on draft-ietf-simple-partial-notify-01 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF01C1DD35@esebe004.ntc.nokia.com> Thread-Topic: [Simple] Minor Comment on draft-ietf-simple-partial-notify-01 Thread-Index: AcPvCXoFhaRPxx2NSDWahOhEOOELgwAA+unQ To: , X-OriginalArrivalTime: 09 Feb 2004 13:06:28.0757 (UTC) FILETIME=[87BF2450:01C3EF0D] 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, 9 Feb 2004 15:06:26 +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.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi, Good catch. Will be fixed in next version. Thanks - Mikko > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org] On=20 > Behalf Of ext George Foti (QC/EMC) > Sent: Monday, February 09, 2004 2:33 PM > To: 'simple@ietf.org' > Subject: [Simple] Minor Comment on draft-ietf-simple-partial-notify-01 >=20 >=20 > Hi, > A minor comment on the partial-Notify-draft-01 draft. > The example should be aligned with the text, so the version=20 > number in the first returned NOTIFY should be 0, instead of 1. >=20 > Rgds/gf >=20 >=20 > This communication is confidential and intended solely for=20 > the addressee(s). Any unauthorized review, use, disclosure or=20 > distribution is prohibited. If you believe this message has=20 > been sent to you in error, please notify the sender by=20 > replying to this transmission and delete the message without=20 > disclosing it. Thank you. >=20 > E-mail including attachments is susceptible to data=20 > corruption, interruption, unauthorized amendment, tampering=20 > and viruses, and we only send and receive e-mails on the=20 > basis that we are not liable for any such corruption,=20 > interception, amendment, tampering or viruses or any=20 > consequences thereof. >=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 Feb 9 10:03: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 KAA22119 for ; Mon, 9 Feb 2004 10:03:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqCwC-0006Ck-00 for simple-archive@ietf.org; Mon, 09 Feb 2004 10:03:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqCvH-00068M-00 for simple-archive@ietf.org; Mon, 09 Feb 2004 10:02:08 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqCuJ-00063y-00; Mon, 09 Feb 2004 10:01:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqCuC-0007sA-Qw; Mon, 09 Feb 2004 10:01:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqCtL-0007MM-RW for simple@optimus.ietf.org; Mon, 09 Feb 2004 10:00:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22021 for ; Mon, 9 Feb 2004 10:00:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqCtJ-0005yw-00 for simple@ietf.org; Mon, 09 Feb 2004 10:00:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqCsO-0005uN-00 for simple@ietf.org; Mon, 09 Feb 2004 09:59:08 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1AqCrV-0005q5-00 for simple@ietf.org; Mon, 09 Feb 2004 09:58:13 -0500 Received: from magnum.cs.columbia.edu (IDENT:root@magnum.cs.columbia.edu [128.59.16.117]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i19EvsEp000014 for ; Mon, 9 Feb 2004 09:57:54 -0500 (EST) Received: from cs.columbia.edu (dhcp62.cs.columbia.edu [128.59.17.212]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id i19EvsH22425 for ; Mon, 9 Feb 2004 09:57:54 -0500 Message-ID: <40279FF1.3040603@cs.columbia.edu> From: Henning Schulzrinne 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@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] *PID drafts Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 09 Feb 2004 09:57:53 -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=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit I finally submitted the split RPID set of drafts. Until they appear in the archives, you can find HTML and text copies at http://www.cs.columbia.edu/sip/draft/cipid/draft-ietf-simple-cipid-00.html http://www.cs.columbia.edu/sip/draft/future-status/draft-ietf-simple-future-00.html http://www.cs.columbia.edu/sip/draft/rpid/draft-ietf-simple-rpid-01.html Comments are most welcome. Henning _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Feb 9 10:03:35 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 KAA22171 for ; Mon, 9 Feb 2004 10:03:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqCwF-000198-Oc for simple-archive@odin.ietf.org; Mon, 09 Feb 2004 10:03:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i19F37Kc004397 for simple-archive@odin.ietf.org; Mon, 9 Feb 2004 10:03:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqCwF-00018n-IN for simple-web-archive@optimus.ietf.org; Mon, 09 Feb 2004 10:03:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22131 for ; Mon, 9 Feb 2004 10:03:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqCwD-0006Cp-00 for simple-web-archive@ietf.org; Mon, 09 Feb 2004 10:03:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqCvI-00068T-00 for simple-web-archive@ietf.org; Mon, 09 Feb 2004 10:02:08 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqCuJ-00063y-00; Mon, 09 Feb 2004 10:01:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqCuC-0007sA-Qw; Mon, 09 Feb 2004 10:01:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqCtL-0007MM-RW for simple@optimus.ietf.org; Mon, 09 Feb 2004 10:00:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22021 for ; Mon, 9 Feb 2004 10:00:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqCtJ-0005yw-00 for simple@ietf.org; Mon, 09 Feb 2004 10:00:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqCsO-0005uN-00 for simple@ietf.org; Mon, 09 Feb 2004 09:59:08 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1AqCrV-0005q5-00 for simple@ietf.org; Mon, 09 Feb 2004 09:58:13 -0500 Received: from magnum.cs.columbia.edu (IDENT:root@magnum.cs.columbia.edu [128.59.16.117]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i19EvsEp000014 for ; Mon, 9 Feb 2004 09:57:54 -0500 (EST) Received: from cs.columbia.edu (dhcp62.cs.columbia.edu [128.59.17.212]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id i19EvsH22425 for ; Mon, 9 Feb 2004 09:57:54 -0500 Message-ID: <40279FF1.3040603@cs.columbia.edu> From: Henning Schulzrinne 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@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] *PID drafts Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 09 Feb 2004 09:57:53 -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=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I finally submitted the split RPID set of drafts. Until they appear in the archives, you can find HTML and text copies at http://www.cs.columbia.edu/sip/draft/cipid/draft-ietf-simple-cipid-00.html http://www.cs.columbia.edu/sip/draft/future-status/draft-ietf-simple-future-00.html http://www.cs.columbia.edu/sip/draft/rpid/draft-ietf-simple-rpid-01.html Comments are most welcome. Henning _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Feb 9 10:55: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 KAA24857 for ; Mon, 9 Feb 2004 10:55:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqDkW-0002Qb-00 for simple-archive@ietf.org; Mon, 09 Feb 2004 10:55:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqDjY-0002KB-00 for simple-archive@ietf.org; Mon, 09 Feb 2004 10:54:05 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqDib-0002CU-00; Mon, 09 Feb 2004 10:53:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqDiW-0008Jl-Tx; Mon, 09 Feb 2004 10:53:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqDhi-0008Es-Ti for simple@optimus.ietf.org; Mon, 09 Feb 2004 10:52:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24793 for ; Mon, 9 Feb 2004 10:52:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqDhg-00027s-00 for simple@ietf.org; Mon, 09 Feb 2004 10:52:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqDgp-00023e-00 for simple@ietf.org; Mon, 09 Feb 2004 10:51:16 -0500 Received: from cluster-a.mailcontrol.com ([80.69.8.190] helo=rly06a.srv.mailcontrol.com) by ietf-mx with esmtp (Exim 4.12) id 1AqDgP-0001y7-00 for simple@ietf.org; Mon, 09 Feb 2004 10:50:49 -0500 Received: from gbnewp0186s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92]) by rly06a.srv.mailcontrol.com (MailControl) with SMTP id i19FoFVR007402; Mon, 9 Feb 2004 15:50:16 GMT Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for cluster-a.mailcontrol.com [80.69.8.190]) with SMTP; Mon, 9 Feb 2004 15:50:14 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] *PID drafts Message-ID: <45730E094814E44488F789C1CDED27AE02BDF184@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [Simple] *PID drafts Thread-Index: AcPvHZF4V6YwNryiSne3a2cm+Lg3mAABpfAg From: "Chris Boulton" To: "Henning Schulzrinne" , X-Scanned-By: MailControl A-04-00-00 (www.mailcontrol.com) 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, 9 Feb 2004 15:50:15 -0000 X-Spam-Checker-Version: SpamAssassin 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 Henning - just a small point - shouldn't the element in the rpid doc schema extending 'Tuple' definition be . Chris. >-----Original Message----- >From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >Sent: 09 February 2004 14:58 >To: simple@ietf.org >Subject: [Simple] *PID drafts > >I finally submitted the split RPID set of drafts. Until they appear in >the archives, you can find HTML and text copies at > >http://www.cs.columbia.edu/sip/draft/cipid/draft-ietf-simple-cipid-00.h tml >http://www.cs.columbia.edu/sip/draft/future-status/draft-ietf-simple- >future-00.html >http://www.cs.columbia.edu/sip/draft/rpid/draft-ietf-simple-rpid-01.htm l > >Comments are most welcome. > >Henning > >_______________________________________________ >Simple mailing list >Simple@ietf.org >https://www1.ietf.org/mailman/listinfo/simple This message has been scanned for viruses by MailControl - www.mailcontrol.= com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Feb 9 10:55:35 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 KAA24886 for ; Mon, 9 Feb 2004 10:55:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqDka-0008WB-Hk for simple-archive@odin.ietf.org; Mon, 09 Feb 2004 10:55:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i19Ft8pJ032743 for simple-archive@odin.ietf.org; Mon, 9 Feb 2004 10:55:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqDka-0008W1-CW for simple-web-archive@optimus.ietf.org; Mon, 09 Feb 2004 10:55:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24871 for ; Mon, 9 Feb 2004 10:55:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqDkX-0002Qg-00 for simple-web-archive@ietf.org; Mon, 09 Feb 2004 10:55:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqDjZ-0002KI-00 for simple-web-archive@ietf.org; Mon, 09 Feb 2004 10:54:06 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqDib-0002CU-00; Mon, 09 Feb 2004 10:53:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqDiW-0008Jl-Tx; Mon, 09 Feb 2004 10:53:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqDhi-0008Es-Ti for simple@optimus.ietf.org; Mon, 09 Feb 2004 10:52:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24793 for ; Mon, 9 Feb 2004 10:52:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqDhg-00027s-00 for simple@ietf.org; Mon, 09 Feb 2004 10:52:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqDgp-00023e-00 for simple@ietf.org; Mon, 09 Feb 2004 10:51:16 -0500 Received: from cluster-a.mailcontrol.com ([80.69.8.190] helo=rly06a.srv.mailcontrol.com) by ietf-mx with esmtp (Exim 4.12) id 1AqDgP-0001y7-00 for simple@ietf.org; Mon, 09 Feb 2004 10:50:49 -0500 Received: from gbnewp0186s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92]) by rly06a.srv.mailcontrol.com (MailControl) with SMTP id i19FoFVR007402; Mon, 9 Feb 2004 15:50:16 GMT Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for cluster-a.mailcontrol.com [80.69.8.190]) with SMTP; Mon, 9 Feb 2004 15:50:14 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] *PID drafts Message-ID: <45730E094814E44488F789C1CDED27AE02BDF184@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [Simple] *PID drafts Thread-Index: AcPvHZF4V6YwNryiSne3a2cm+Lg3mAABpfAg From: "Chris Boulton" To: "Henning Schulzrinne" , X-Scanned-By: MailControl A-04-00-00 (www.mailcontrol.com) 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, 9 Feb 2004 15:50:15 -0000 X-Spam-Checker-Version: SpamAssassin 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 Henning - just a small point - shouldn't the element in the rpid doc schema extending 'Tuple' definition be . Chris. >-----Original Message----- >From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >Sent: 09 February 2004 14:58 >To: simple@ietf.org >Subject: [Simple] *PID drafts > >I finally submitted the split RPID set of drafts. Until they appear in >the archives, you can find HTML and text copies at > >http://www.cs.columbia.edu/sip/draft/cipid/draft-ietf-simple-cipid-00.h tml >http://www.cs.columbia.edu/sip/draft/future-status/draft-ietf-simple- >future-00.html >http://www.cs.columbia.edu/sip/draft/rpid/draft-ietf-simple-rpid-01.htm l > >Comments are most welcome. > >Henning > >_______________________________________________ >Simple mailing list >Simple@ietf.org >https://www1.ietf.org/mailman/listinfo/simple This message has been scanned for viruses by MailControl - www.mailcontrol.= com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Feb 9 11:46: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 LAA27775 for ; Mon, 9 Feb 2004 11:46:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqEXz-0000Nf-00 for simple-archive@ietf.org; Mon, 09 Feb 2004 11:46:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqEWy-0000H4-00 for simple-archive@ietf.org; Mon, 09 Feb 2004 11:45:09 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AqEW0-00009V-00; Mon, 09 Feb 2004 11:44:08 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AqEW1-0005oj-Cb; Mon, 09 Feb 2004 11:44:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqEVt-0004iX-LE; Mon, 09 Feb 2004 11:44:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqEVC-0004fv-35 for simple@optimus.ietf.org; Mon, 09 Feb 2004 11:43:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27519 for ; Mon, 9 Feb 2004 11:43:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqEVA-00001V-00 for simple@ietf.org; Mon, 09 Feb 2004 11:43:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqEUC-0007ia-00 for simple@ietf.org; Mon, 09 Feb 2004 11:42:17 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1AqETM-0007d0-00 for simple@ietf.org; Mon, 09 Feb 2004 11:41:24 -0500 Received: from magnum.cs.columbia.edu (IDENT:root@magnum.cs.columbia.edu [128.59.16.117]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i19GfNEp024232; Mon, 9 Feb 2004 11:41:23 -0500 (EST) Received: from cs.columbia.edu (dhcp62.cs.columbia.edu [128.59.17.212]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id i19GdrH10044; Mon, 9 Feb 2004 11:39:53 -0500 Message-ID: <4027B7D8.7070402@cs.columbia.edu> From: Henning Schulzrinne 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: Chris Boulton CC: simple@ietf.org Subject: Re: [Simple] *PID drafts References: <45730E094814E44488F789C1CDED27AE02BDF184@gbnewp0758m.eu.ubiquity.net> In-Reply-To: <45730E094814E44488F789C1CDED27AE02BDF184@gbnewp0758m.eu.ubiquity.net> 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, 09 Feb 2004 11:39:52 -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=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit It should be; thanks. Chris Boulton wrote: > Henning - just a small point - shouldn't the element in the rpid > doc schema extending 'Tuple' definition be . > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Feb 9 11:46:41 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 LAA27824 for ; Mon, 9 Feb 2004 11:46:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqEY2-0004w2-5H for simple-archive@odin.ietf.org; Mon, 09 Feb 2004 11:46:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i19GkEgI018970 for simple-archive@odin.ietf.org; Mon, 9 Feb 2004 11:46:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqEY2-0004vt-0c for simple-web-archive@optimus.ietf.org; Mon, 09 Feb 2004 11:46:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27793 for ; Mon, 9 Feb 2004 11:46:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqEY0-0000Nv-00 for simple-web-archive@ietf.org; Mon, 09 Feb 2004 11:46:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqEWz-0000HC-00 for simple-web-archive@ietf.org; Mon, 09 Feb 2004 11:45:10 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AqEW0-00009V-00; Mon, 09 Feb 2004 11:44:08 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AqEW1-0005oj-Cb; Mon, 09 Feb 2004 11:44:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqEVt-0004iX-LE; Mon, 09 Feb 2004 11:44:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqEVC-0004fv-35 for simple@optimus.ietf.org; Mon, 09 Feb 2004 11:43:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27519 for ; Mon, 9 Feb 2004 11:43:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqEVA-00001V-00 for simple@ietf.org; Mon, 09 Feb 2004 11:43:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqEUC-0007ia-00 for simple@ietf.org; Mon, 09 Feb 2004 11:42:17 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1AqETM-0007d0-00 for simple@ietf.org; Mon, 09 Feb 2004 11:41:24 -0500 Received: from magnum.cs.columbia.edu (IDENT:root@magnum.cs.columbia.edu [128.59.16.117]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i19GfNEp024232; Mon, 9 Feb 2004 11:41:23 -0500 (EST) Received: from cs.columbia.edu (dhcp62.cs.columbia.edu [128.59.17.212]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id i19GdrH10044; Mon, 9 Feb 2004 11:39:53 -0500 Message-ID: <4027B7D8.7070402@cs.columbia.edu> From: Henning Schulzrinne 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: Chris Boulton CC: simple@ietf.org Subject: Re: [Simple] *PID drafts References: <45730E094814E44488F789C1CDED27AE02BDF184@gbnewp0758m.eu.ubiquity.net> In-Reply-To: <45730E094814E44488F789C1CDED27AE02BDF184@gbnewp0758m.eu.ubiquity.net> 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, 09 Feb 2004 11:39:52 -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=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit It should be; thanks. Chris Boulton wrote: > Henning - just a small point - shouldn't the element in the rpid > doc schema extending 'Tuple' definition be . > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Feb 9 14:50:19 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07025 for ; Mon, 9 Feb 2004 14:50:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqHQB-0002rR-00 for simple-archive@ietf.org; Mon, 09 Feb 2004 14:50:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqHPL-0002mc-00 for simple-archive@ietf.org; Mon, 09 Feb 2004 14:49:28 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqHP0-0002h8-00; Mon, 09 Feb 2004 14:49:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqHOv-0003Sn-Ud; Mon, 09 Feb 2004 14:49:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqHOC-0003QL-K0 for simple@optimus.ietf.org; Mon, 09 Feb 2004 14:48:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06883 for ; Mon, 9 Feb 2004 14:48:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqHOA-0002et-00 for simple@ietf.org; Mon, 09 Feb 2004 14:48:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqHND-0002Zf-00 for simple@ietf.org; Mon, 09 Feb 2004 14:47:16 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AqHMK-0002Qo-00 for simple@ietf.org; Mon, 09 Feb 2004 14:46:21 -0500 Received: from dynamicsoft.com ([63.113.46.162]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i19JjrNr001543 for ; Mon, 9 Feb 2004 14:45:53 -0500 (EST) Message-ID: <4027E369.1080001@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] New xcap authorization documents Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.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, 09 Feb 2004 14:45:45 -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.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Folks, We've completed the major first step of integrating the geopriv and simple authorization specifications. -00 drafts have been submitted to both geopriv and simple supporting this unification. In geopriv, the main draft to look at is this one (available in the archives shortly:) http://ecotroph.net/~anewton/resources/geopriv/draft-ietf-geopriv-common-policy-00.txt This is the common policy specification. It outlines the framework for representing policies, and defines some basic elements, such as confirming subscriptions and identifying watchers. At this time, it includes support for the "exception" clause against domains. This specification is extended (and in particular, the abstract condition, action, and transformation elements are made concrete) with presence specific data in: http://www.jdrosen.net/papers/draft-rosenberg-simple-rules-00.txt which should also appear in the archives shortly. This draft will replace draft-ietf-simple-xcap-auth-usage-01.txt once the group is happy with the approach. Another change is the removal of "supported permissions" from xcap-auth-usage. That, like authorization rules, is now broken into a common core document and a presence specific one. http://www.jdrosen.net/papers/draft-rosenberg-simple-common-policy-caps-00.txt specifies the common document, and: http://www.jdrosen.net/papers/draft-rosenberg-simple-pres-policy-caps-00.txt contains the capabilities specific to presence. These are both very simple specifications. I think the resulting document set is much cleaner and easier to understand than before. Put together, beyond a split, here are the major changes: * all conditions are part of a rule-wide selector (the conditions element) rather than specific to permissions. As such, the accept-if condition is gone. * only domain's have except clauses. There is no longer an "any" condition or the ability to reference a list. * The "sphere" element is now present as a condition * There is a "validity" condition which allows you to temproally scope the validity of a document * Removed "can-encrypt" condition - trying to keep things minimal. * You can now explicitly ask for subscription confirmation using the confirmation action from the common document * You can explicitly accept or reject subscriptions with the accept-subscription action in the presence specific document. * You can now explicitly polite block. The behavior of the server when the user requests polite blocking is not defined - its implementation specific. * There is no longer an "encrypt" action for requesting the server to send encrypted notifications. * There is now an "anonymous" condition which allows you to specify policies based on whether the subscription was anonymous * Specific treatment for identity matching is defined for SIP digest authentication, P-asserted-ID and sip-identity * There are three content transformations defined - show-tuple, show-namespace and show-element. Each of these is applied INDEPENDENTLY, so if an item is filtered by any one of these, its filtered out of the document. * show-note and show-contact have been removed to simplify * defaults were established for the above three transformations * The documents are much less xcap-centric. They talk about document formats, and have a small section at the end which defines the usage for xcap. The title and filenames have also changed to reflect this. This clarifies that these documents can be used outside of xcap. Please take a look and send comments. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Feb 9 14:50:50 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 OAA07050 for ; Mon, 9 Feb 2004 14:50:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqHQF-0003aD-K8 for simple-archive@odin.ietf.org; Mon, 09 Feb 2004 14:50:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i19JoN7E013767 for simple-archive@odin.ietf.org; Mon, 9 Feb 2004 14:50:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqHQF-0003Zy-GR for simple-web-archive@optimus.ietf.org; Mon, 09 Feb 2004 14:50:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07043 for ; Mon, 9 Feb 2004 14:50:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqHQC-0002rW-00 for simple-web-archive@ietf.org; Mon, 09 Feb 2004 14:50:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqHPM-0002mj-00 for simple-web-archive@ietf.org; Mon, 09 Feb 2004 14:49:29 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqHP0-0002h8-00; Mon, 09 Feb 2004 14:49:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqHOv-0003Sn-Ud; Mon, 09 Feb 2004 14:49:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqHOC-0003QL-K0 for simple@optimus.ietf.org; Mon, 09 Feb 2004 14:48:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06883 for ; Mon, 9 Feb 2004 14:48:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqHOA-0002et-00 for simple@ietf.org; Mon, 09 Feb 2004 14:48:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqHND-0002Zf-00 for simple@ietf.org; Mon, 09 Feb 2004 14:47:16 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AqHMK-0002Qo-00 for simple@ietf.org; Mon, 09 Feb 2004 14:46:21 -0500 Received: from dynamicsoft.com ([63.113.46.162]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i19JjrNr001543 for ; Mon, 9 Feb 2004 14:45:53 -0500 (EST) Message-ID: <4027E369.1080001@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] New xcap authorization documents Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.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, 09 Feb 2004 14:45:45 -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.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Folks, We've completed the major first step of integrating the geopriv and simple authorization specifications. -00 drafts have been submitted to both geopriv and simple supporting this unification. In geopriv, the main draft to look at is this one (available in the archives shortly:) http://ecotroph.net/~anewton/resources/geopriv/draft-ietf-geopriv-common-policy-00.txt This is the common policy specification. It outlines the framework for representing policies, and defines some basic elements, such as confirming subscriptions and identifying watchers. At this time, it includes support for the "exception" clause against domains. This specification is extended (and in particular, the abstract condition, action, and transformation elements are made concrete) with presence specific data in: http://www.jdrosen.net/papers/draft-rosenberg-simple-rules-00.txt which should also appear in the archives shortly. This draft will replace draft-ietf-simple-xcap-auth-usage-01.txt once the group is happy with the approach. Another change is the removal of "supported permissions" from xcap-auth-usage. That, like authorization rules, is now broken into a common core document and a presence specific one. http://www.jdrosen.net/papers/draft-rosenberg-simple-common-policy-caps-00.txt specifies the common document, and: http://www.jdrosen.net/papers/draft-rosenberg-simple-pres-policy-caps-00.txt contains the capabilities specific to presence. These are both very simple specifications. I think the resulting document set is much cleaner and easier to understand than before. Put together, beyond a split, here are the major changes: * all conditions are part of a rule-wide selector (the conditions element) rather than specific to permissions. As such, the accept-if condition is gone. * only domain's have except clauses. There is no longer an "any" condition or the ability to reference a list. * The "sphere" element is now present as a condition * There is a "validity" condition which allows you to temproally scope the validity of a document * Removed "can-encrypt" condition - trying to keep things minimal. * You can now explicitly ask for subscription confirmation using the confirmation action from the common document * You can explicitly accept or reject subscriptions with the accept-subscription action in the presence specific document. * You can now explicitly polite block. The behavior of the server when the user requests polite blocking is not defined - its implementation specific. * There is no longer an "encrypt" action for requesting the server to send encrypted notifications. * There is now an "anonymous" condition which allows you to specify policies based on whether the subscription was anonymous * Specific treatment for identity matching is defined for SIP digest authentication, P-asserted-ID and sip-identity * There are three content transformations defined - show-tuple, show-namespace and show-element. Each of these is applied INDEPENDENTLY, so if an item is filtered by any one of these, its filtered out of the document. * show-note and show-contact have been removed to simplify * defaults were established for the above three transformations * The documents are much less xcap-centric. They talk about document formats, and have a small section at the end which defines the usage for xcap. The title and filenames have also changed to reflect this. This clarifies that these documents can be used outside of xcap. Please take a look and send comments. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Feb 9 16:27:40 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14836 for ; Mon, 9 Feb 2004 16:27:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqIwP-0004hE-00 for simple-archive@ietf.org; Mon, 09 Feb 2004 16:27:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqIu8-00049i-00 for simple-archive@ietf.org; Mon, 09 Feb 2004 16:25:22 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqIs2-0003gZ-00; Mon, 09 Feb 2004 16:23:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqIrt-00037U-Q2; Mon, 09 Feb 2004 16:23:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqIrC-0002vj-TZ for simple@optimus.ietf.org; Mon, 09 Feb 2004 16:22:18 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13882; Mon, 9 Feb 2004 16:22:15 -0500 (EST) Message-Id: <200402092122.QAA13882@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: simple@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-prescaps-ext-00.txt Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 09 Feb 2004 16:22:15 -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.4 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : User agent capability presence status extension Author(s) : M. Lonnfors, K. Kiss Filename : draft-ietf-simple-prescaps-ext-00.txt Pages : 28 Date : 2004-2-9 Interoperation of Instant Messaging and Presence systems has been defined in IMPP working group. IMPP WG has come up with baseline interoperable operations and formats for presence and instant messaging systems. However, these base formats might need standardized extensions in order to enable building rational applications using presence and instant messaging. This memo proposes an extension to PIDF presence document format to represent A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-prescaps-ext-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-prescaps-ext-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-prescaps-ext-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-2-9162218.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-prescaps-ext-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-prescaps-ext-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-9162218.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Feb 9 16:28:12 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 QAA14936 for ; Mon, 9 Feb 2004 16:28:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqIwS-0003w7-Tp for simple-archive@odin.ietf.org; Mon, 09 Feb 2004 16:27:44 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i19LRisx015130 for simple-archive@odin.ietf.org; Mon, 9 Feb 2004 16:27:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqIwS-0003vx-QD for simple-web-archive@optimus.ietf.org; Mon, 09 Feb 2004 16:27:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14863 for ; Mon, 9 Feb 2004 16:27:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqIwQ-0004hQ-00 for simple-web-archive@ietf.org; Mon, 09 Feb 2004 16:27:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqIuA-0004A8-00 for simple-web-archive@ietf.org; Mon, 09 Feb 2004 16:25:23 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqIs2-0003gZ-00; Mon, 09 Feb 2004 16:23:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqIrt-00037U-Q2; Mon, 09 Feb 2004 16:23:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqIrC-0002vj-TZ for simple@optimus.ietf.org; Mon, 09 Feb 2004 16:22:18 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13882; Mon, 9 Feb 2004 16:22:15 -0500 (EST) Message-Id: <200402092122.QAA13882@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: simple@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-prescaps-ext-00.txt Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 09 Feb 2004 16:22:15 -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.4 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : User agent capability presence status extension Author(s) : M. Lonnfors, K. Kiss Filename : draft-ietf-simple-prescaps-ext-00.txt Pages : 28 Date : 2004-2-9 Interoperation of Instant Messaging and Presence systems has been defined in IMPP working group. IMPP WG has come up with baseline interoperable operations and formats for presence and instant messaging systems. However, these base formats might need standardized extensions in order to enable building rational applications using presence and instant messaging. This memo proposes an extension to PIDF presence document format to represent A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-prescaps-ext-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-prescaps-ext-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-prescaps-ext-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-2-9162218.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-prescaps-ext-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-prescaps-ext-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-9162218.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Feb 10 10:56:00 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24057 for ; Tue, 10 Feb 2004 10:55:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqaEz-0005bX-00 for simple-archive@ietf.org; Tue, 10 Feb 2004 10:56:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqaE2-0005VI-00 for simple-archive@ietf.org; Tue, 10 Feb 2004 10:55:02 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqaDJ-0005PW-00; Tue, 10 Feb 2004 10:54:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqaD2-0000qz-Sd; Tue, 10 Feb 2004 10:54:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqaC7-0000qG-1h for simple@optimus.ietf.org; Tue, 10 Feb 2004 10:53:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23948 for ; Tue, 10 Feb 2004 10:52:59 -0500 (EST) From: Markus.Isomaki@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqaC4-0005GK-00 for simple@ietf.org; Tue, 10 Feb 2004 10:53:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqaB5-0005At-00 for simple@ietf.org; Tue, 10 Feb 2004 10:51:59 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AqaAu-00055v-00 for simple@ietf.org; Tue, 10 Feb 2004 10:51:48 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1AFplv03081 for ; Tue, 10 Feb 2004 17:51:47 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 10 Feb 2004 17:51:47 +0200 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 10 Feb 2004 17:51:48 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: Thread-Topic: [Simple] New xcap authorization documents Thread-Index: AcPvSAnlGDdWtkDYR5GSxd9IBCgMVgAoZA8Q To: X-OriginalArrivalTime: 10 Feb 2004 15:51:48.0512 (UTC) FILETIME=[CACB6200:01C3EFED] Content-Transfer-Encoding: quoted-printable Subject: [Simple] New version of XCAP usage for manipulating presence document contents Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.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, 10 Feb 2004 17:51:46 +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.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Hi, I have submitted a new version on the XCAP application usage for = manipulating the content of PIDF presence document, previously known as = XCAP usage for presence publishing.=20 You can find it at: http://www.ietf.org/internet-drafts/draft-isomaki-simple-xcap-pidf-manipu= lation-usage-00.txt (Note that actually this has been approved as SIMPLE WG item, but due to = my typo, it is still named as an individual draft.) The main idea of the draft is to complement SIP PUBLISH to allow the = presentity to manipulate device independent "hard state" presence = information. This hard state information would be fed to the presence = composition process as one input alongside the PUA views published using = SIP. There are no open issues as such within the draft, the updates compared = to the last version were mainly about better wording. However, there is = one big issue wrt. the latest discussion on SIP PUBLISH. There has been = a proposal (on SIP WG list) to enhance PUBLISH solution so that PUAs = would be able to learn the states set by each other and actually = override such states. If this is brought forward PUBLISH will really = start overlapping with the XCAP usage defined here. I will continue this = discussion on SIP WG mailing list. Regards, Markus =20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Feb 10 10:56:32 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 KAA24097 for ; Tue, 10 Feb 2004 10:56:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqaF3-00017G-IJ for simple-archive@odin.ietf.org; Tue, 10 Feb 2004 10:56:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1AFu5L8004290 for simple-archive@odin.ietf.org; Tue, 10 Feb 2004 10:56:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqaF2-000176-I6 for simple-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 10:56:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24075 for ; Tue, 10 Feb 2004 10:56:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqaEz-0005bd-00 for simple-web-archive@ietf.org; Tue, 10 Feb 2004 10:56:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqaE2-0005VQ-00 for simple-web-archive@ietf.org; Tue, 10 Feb 2004 10:55:03 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqaDJ-0005PW-00; Tue, 10 Feb 2004 10:54:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqaD2-0000qz-Sd; Tue, 10 Feb 2004 10:54:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqaC7-0000qG-1h for simple@optimus.ietf.org; Tue, 10 Feb 2004 10:53:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23948 for ; Tue, 10 Feb 2004 10:52:59 -0500 (EST) From: Markus.Isomaki@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqaC4-0005GK-00 for simple@ietf.org; Tue, 10 Feb 2004 10:53:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqaB5-0005At-00 for simple@ietf.org; Tue, 10 Feb 2004 10:51:59 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AqaAu-00055v-00 for simple@ietf.org; Tue, 10 Feb 2004 10:51:48 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1AFplv03081 for ; Tue, 10 Feb 2004 17:51:47 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 10 Feb 2004 17:51:47 +0200 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 10 Feb 2004 17:51:48 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: Thread-Topic: [Simple] New xcap authorization documents Thread-Index: AcPvSAnlGDdWtkDYR5GSxd9IBCgMVgAoZA8Q To: X-OriginalArrivalTime: 10 Feb 2004 15:51:48.0512 (UTC) FILETIME=[CACB6200:01C3EFED] Content-Transfer-Encoding: quoted-printable Subject: [Simple] New version of XCAP usage for manipulating presence document contents Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.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, 10 Feb 2004 17:51:46 +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.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 have submitted a new version on the XCAP application usage for = manipulating the content of PIDF presence document, previously known as = XCAP usage for presence publishing.=20 You can find it at: http://www.ietf.org/internet-drafts/draft-isomaki-simple-xcap-pidf-manipu= lation-usage-00.txt (Note that actually this has been approved as SIMPLE WG item, but due to = my typo, it is still named as an individual draft.) The main idea of the draft is to complement SIP PUBLISH to allow the = presentity to manipulate device independent "hard state" presence = information. This hard state information would be fed to the presence = composition process as one input alongside the PUA views published using = SIP. There are no open issues as such within the draft, the updates compared = to the last version were mainly about better wording. However, there is = one big issue wrt. the latest discussion on SIP PUBLISH. There has been = a proposal (on SIP WG list) to enhance PUBLISH solution so that PUAs = would be able to learn the states set by each other and actually = override such states. If this is brought forward PUBLISH will really = start overlapping with the XCAP usage defined here. I will continue this = discussion on SIP WG mailing list. Regards, Markus =20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Feb 10 11:08: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 LAA25316 for ; Tue, 10 Feb 2004 11:08:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqaRU-0007iY-00 for simple-archive@ietf.org; Tue, 10 Feb 2004 11:08:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqaQb-0007Za-00 for simple-archive@ietf.org; Tue, 10 Feb 2004 11:08:02 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqaPh-0007Py-00; Tue, 10 Feb 2004 11:07:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqaPf-0002E0-3E; Tue, 10 Feb 2004 11:07:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqaOr-00027Y-FO for simple@optimus.ietf.org; Tue, 10 Feb 2004 11:06:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25080 for ; Tue, 10 Feb 2004 11:06:09 -0500 (EST) From: Markus.Isomaki@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqaOo-0007Gm-00 for simple@ietf.org; Tue, 10 Feb 2004 11:06:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqaNs-00073b-00 for simple@ietf.org; Tue, 10 Feb 2004 11:05:13 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AqaM7-0006i5-00 for simple@ietf.org; Tue, 10 Feb 2004 11:03:23 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1AG3Mv19526 for ; Tue, 10 Feb 2004 18:03:22 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 10 Feb 2004 18:03:20 +0200 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 10 Feb 2004 18:03:20 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] XCAP questions Message-ID: Thread-Topic: [Simple] XCAP questions Thread-Index: AcPngBmIo9JEoIEPSxi0Ed9So8MypwErT+IQ To: , X-OriginalArrivalTime: 10 Feb 2004 16:03:20.0220 (UTC) FILETIME=[6715A5C0:01C3EFEF] 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, 10 Feb 2004 18:03:01 +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.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Hi, For practical use of XCAP I think case 1. below is very important, = without it XCAP falls short from the practical requirements. The = requirement is basically that the user should be able to determine which = XCAP-manipulateable resources he has under which application usage. = Without this, there will be difficulties when the client looses state or = the user switches to some other client device.=20 I think it would be sufficient to be able to do this per application = usage. Is it possible to define a (XML) response payload for HTTP GET = done for the application usage directory URI, which would include the = resources under that directory/usage? Markus > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > ext Jari Urpalainen > Sent: 29 January, 2004 12:22 > To: simple@ietf.org > Subject: [Simple] XCAP questions >=20 >=20 > Hi ! >=20 > I have been developing a reference implementation for XCAP server=20 > (standalone and an Apache module). There are some=20 > open/unclear issues=20 > (to me at least), so here's the list of questions. >=20 > 1. XCAP directory list > In XCAP presence auth draft chapter 4.4, there's a requirement to get=20 > all documents from the server. However, in the base XCAP draft it is=20 > unspecified how the server should send this directory list. While=20 > http-servers can/will provide this information in many ways, IMO the=20 > base XCAP draft should specify this format (xml?).=20 > Furhermore, it would=20 > be nice if ETags were included in the response in order to help to=20 > synchonize documents between the client and the server. >=20 > 2. XCAP ETags > In order to ease the synchronizing within resources between=20 > client and=20 > server the base XCAP draft could specify the secure hash method e.g.=20 > SHA-1 or whatever that is used to calculate the ETag. This is already=20 > proposed in xcap-package but IMHO could be in the base spec. >=20 > 3. XCAP attributes > When updating/querying attributes is it necessary to include=20 > attribute=20 > name in payload as attribute name is already provided in XPATH-query ? >=20 > e.g. you could get /resource-lists/list[@name=3D"friends"]/@uri > so you already know that you receive response for attribute uri. IMHO=20 > when putting/getting attributes, payload could include only=20 > attribute value. >=20 > 4. XCAP namespace declarations > As namespace handling resemble "standard" XML attributes is it also=20 > allowed to change namespace declarations with similar semantics ? >=20 > BR, > Jari Urpalainen >=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 Feb 10 11:09:26 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 LAA25392 for ; Tue, 10 Feb 2004 11:09:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqaRX-0002lg-T8 for simple-archive@odin.ietf.org; Tue, 10 Feb 2004 11:08:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1AG8xQb010634 for simple-archive@odin.ietf.org; Tue, 10 Feb 2004 11:08:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqaRX-0002lR-Pt for simple-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 11:08:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25333 for ; Tue, 10 Feb 2004 11:08:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqaRV-0007id-00 for simple-web-archive@ietf.org; Tue, 10 Feb 2004 11:08:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqaQc-0007Zh-00 for simple-web-archive@ietf.org; Tue, 10 Feb 2004 11:08:03 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqaPh-0007Py-00; Tue, 10 Feb 2004 11:07:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqaPf-0002E0-3E; Tue, 10 Feb 2004 11:07:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqaOr-00027Y-FO for simple@optimus.ietf.org; Tue, 10 Feb 2004 11:06:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25080 for ; Tue, 10 Feb 2004 11:06:09 -0500 (EST) From: Markus.Isomaki@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqaOo-0007Gm-00 for simple@ietf.org; Tue, 10 Feb 2004 11:06:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqaNs-00073b-00 for simple@ietf.org; Tue, 10 Feb 2004 11:05:13 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AqaM7-0006i5-00 for simple@ietf.org; Tue, 10 Feb 2004 11:03:23 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1AG3Mv19526 for ; Tue, 10 Feb 2004 18:03:22 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 10 Feb 2004 18:03:20 +0200 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 10 Feb 2004 18:03:20 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] XCAP questions Message-ID: Thread-Topic: [Simple] XCAP questions Thread-Index: AcPngBmIo9JEoIEPSxi0Ed9So8MypwErT+IQ To: , X-OriginalArrivalTime: 10 Feb 2004 16:03:20.0220 (UTC) FILETIME=[6715A5C0:01C3EFEF] 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, 10 Feb 2004 18:03:01 +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.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, For practical use of XCAP I think case 1. below is very important, = without it XCAP falls short from the practical requirements. The = requirement is basically that the user should be able to determine which = XCAP-manipulateable resources he has under which application usage. = Without this, there will be difficulties when the client looses state or = the user switches to some other client device.=20 I think it would be sufficient to be able to do this per application = usage. Is it possible to define a (XML) response payload for HTTP GET = done for the application usage directory URI, which would include the = resources under that directory/usage? Markus > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > ext Jari Urpalainen > Sent: 29 January, 2004 12:22 > To: simple@ietf.org > Subject: [Simple] XCAP questions >=20 >=20 > Hi ! >=20 > I have been developing a reference implementation for XCAP server=20 > (standalone and an Apache module). There are some=20 > open/unclear issues=20 > (to me at least), so here's the list of questions. >=20 > 1. XCAP directory list > In XCAP presence auth draft chapter 4.4, there's a requirement to get=20 > all documents from the server. However, in the base XCAP draft it is=20 > unspecified how the server should send this directory list. While=20 > http-servers can/will provide this information in many ways, IMO the=20 > base XCAP draft should specify this format (xml?).=20 > Furhermore, it would=20 > be nice if ETags were included in the response in order to help to=20 > synchonize documents between the client and the server. >=20 > 2. XCAP ETags > In order to ease the synchronizing within resources between=20 > client and=20 > server the base XCAP draft could specify the secure hash method e.g.=20 > SHA-1 or whatever that is used to calculate the ETag. This is already=20 > proposed in xcap-package but IMHO could be in the base spec. >=20 > 3. XCAP attributes > When updating/querying attributes is it necessary to include=20 > attribute=20 > name in payload as attribute name is already provided in XPATH-query ? >=20 > e.g. you could get /resource-lists/list[@name=3D"friends"]/@uri > so you already know that you receive response for attribute uri. IMHO=20 > when putting/getting attributes, payload could include only=20 > attribute value. >=20 > 4. XCAP namespace declarations > As namespace handling resemble "standard" XML attributes is it also=20 > allowed to change namespace declarations with similar semantics ? >=20 > BR, > Jari Urpalainen >=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 Feb 10 16:11: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 QAA16255 for ; Tue, 10 Feb 2004 16:11:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqfAJ-000218-00 for simple-archive@ietf.org; Tue, 10 Feb 2004 16:11:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqf8z-0001k6-00 for simple-archive@ietf.org; Tue, 10 Feb 2004 16:10:10 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aqf7z-0001Wu-00; Tue, 10 Feb 2004 16:09:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqf7t-0006Ps-IX; Tue, 10 Feb 2004 16:09:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqf72-0005wv-Ed for simple@optimus.ietf.org; Tue, 10 Feb 2004 16:08:08 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15386; Tue, 10 Feb 2004 16:08:05 -0500 (EST) Message-Id: <200402102108.QAA15386@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: simple@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-future-00.txt Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 10 Feb 2004 16:08:05 -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.4 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : Future Presence: Extensions to the Presence Information Data Format (PIDF) Author(s) : H. Schulzrinne Filename : draft-ietf-simple-future-00.txt Pages : 13 Date : 2004-2-10 The Future Presence extension adds elements to the Presence Information Data Format (PIDF) that allow a presentity to declare their status for a time in the future. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-future-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-future-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-future-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-2-10155432.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-future-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-future-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-10155432.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Feb 10 16:11:35 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16281 for ; Tue, 10 Feb 2004 16:11:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqfAN-00021k-00 for simple-archive@ietf.org; Tue, 10 Feb 2004 16:11:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqf91-0001kR-00 for simple-archive@ietf.org; Tue, 10 Feb 2004 16:10:12 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aqf7z-0001Wv-00; Tue, 10 Feb 2004 16:09:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqf7u-0006QY-LQ; Tue, 10 Feb 2004 16:09:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqf7D-00068Y-E1 for simple@optimus.ietf.org; Tue, 10 Feb 2004 16:08:19 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15431; Tue, 10 Feb 2004 16:08:16 -0500 (EST) Message-Id: <200402102108.QAA15431@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: simple@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-rpid-01.txt Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 10 Feb 2004 16:08:16 -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.4 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : RPID -- Rich Presence Information Data Format Author(s) : H. Schulzrinne Filename : draft-ietf-simple-rpid-01.txt Pages : 24 Date : 2004-2-10 The Rich Presence Information Data Format (RPID) adds elements to the Presence Information Data Format (PIDF) that provide additional information about the presentity and its contacts. This information can be translated into call routing behavior or be delivered to watchers, for example. The information is designed so that much of it can be derived automatically, e.g., from calendar files or user activity. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-rpid-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-rpid-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-rpid-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-2-10155500.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-rpid-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-rpid-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-10155500.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Feb 10 16:11: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 QAA16320 for ; Tue, 10 Feb 2004 16:11:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqfAU-00022x-00 for simple-archive@ietf.org; Tue, 10 Feb 2004 16:11:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqf93-0001kn-00 for simple-archive@ietf.org; Tue, 10 Feb 2004 16:10:13 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aqf7z-0001Wx-00; Tue, 10 Feb 2004 16:09:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqf7v-0006Qv-Ad; Tue, 10 Feb 2004 16:09:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqf7T-0006EU-HE for simple@optimus.ietf.org; Tue, 10 Feb 2004 16:08:35 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15467; Tue, 10 Feb 2004 16:08:32 -0500 (EST) Message-Id: <200402102108.QAA15467@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: simple@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-cipid-00.txt Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 10 Feb 2004 16:08:32 -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.4 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : CIPID: Contact Information in Presence Information Data Format Author(s) : H. Schulzrinne Filename : draft-ietf-simple-cipid-00.txt Pages : 15 Date : 2004-2-10 The Contact Information for Presence Information Data Format (CIPID) adds elements to the Presence Information Data Format (PIDF) that provide additional contact information about a presentity and its contacts, including references to address book entries and icons. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-cipid-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-cipid-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-cipid-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-2-10161459.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-cipid-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-cipid-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-10161459.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Feb 10 16:12: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 QAA16366 for ; Tue, 10 Feb 2004 16:12:02 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqfAM-00078x-N3 for simple-archive@odin.ietf.org; Tue, 10 Feb 2004 16:11:34 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1ALBYIT027453 for simple-archive@odin.ietf.org; Tue, 10 Feb 2004 16:11:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqfAM-00078i-J2 for simple-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 16:11:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16277 for ; Tue, 10 Feb 2004 16:11:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqfAK-00021M-00 for simple-web-archive@ietf.org; Tue, 10 Feb 2004 16:11:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqf90-0001kH-00 for simple-web-archive@ietf.org; Tue, 10 Feb 2004 16:10:11 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aqf7z-0001Wu-00; Tue, 10 Feb 2004 16:09:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqf7t-0006Ps-IX; Tue, 10 Feb 2004 16:09:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqf72-0005wv-Ed for simple@optimus.ietf.org; Tue, 10 Feb 2004 16:08:08 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15386; Tue, 10 Feb 2004 16:08:05 -0500 (EST) Message-Id: <200402102108.QAA15386@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: simple@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-future-00.txt Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 10 Feb 2004 16:08:05 -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.4 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : Future Presence: Extensions to the Presence Information Data Format (PIDF) Author(s) : H. Schulzrinne Filename : draft-ietf-simple-future-00.txt Pages : 13 Date : 2004-2-10 The Future Presence extension adds elements to the Presence Information Data Format (PIDF) that allow a presentity to declare their status for a time in the future. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-future-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-future-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-future-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-2-10155432.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-future-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-future-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-10155432.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Feb 10 16:12:06 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 QAA16383 for ; Tue, 10 Feb 2004 16:12:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqfAQ-00079S-QH for simple-archive@odin.ietf.org; Tue, 10 Feb 2004 16:11:38 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1ALBc0t027484 for simple-archive@odin.ietf.org; Tue, 10 Feb 2004 16:11:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqfAQ-00079D-Mt for simple-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 16:11:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16302 for ; Tue, 10 Feb 2004 16:11:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqfAO-00021y-00 for simple-web-archive@ietf.org; Tue, 10 Feb 2004 16:11:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqf92-0001ka-00 for simple-web-archive@ietf.org; Tue, 10 Feb 2004 16:10:13 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aqf7z-0001Wv-00; Tue, 10 Feb 2004 16:09:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqf7u-0006QY-LQ; Tue, 10 Feb 2004 16:09:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqf7D-00068Y-E1 for simple@optimus.ietf.org; Tue, 10 Feb 2004 16:08:19 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15431; Tue, 10 Feb 2004 16:08:16 -0500 (EST) Message-Id: <200402102108.QAA15431@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: simple@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-rpid-01.txt Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 10 Feb 2004 16:08:16 -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.4 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : RPID -- Rich Presence Information Data Format Author(s) : H. Schulzrinne Filename : draft-ietf-simple-rpid-01.txt Pages : 24 Date : 2004-2-10 The Rich Presence Information Data Format (RPID) adds elements to the Presence Information Data Format (PIDF) that provide additional information about the presentity and its contacts. This information can be translated into call routing behavior or be delivered to watchers, for example. The information is designed so that much of it can be derived automatically, e.g., from calendar files or user activity. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-rpid-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-rpid-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-rpid-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-2-10155500.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-rpid-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-rpid-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-10155500.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Feb 10 16:12:14 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 QAA16426 for ; Tue, 10 Feb 2004 16:12:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqfAY-00079k-F6 for simple-archive@odin.ietf.org; Tue, 10 Feb 2004 16:11:46 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1ALBkBU027502 for simple-archive@odin.ietf.org; Tue, 10 Feb 2004 16:11:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqfAY-00079V-Bm for simple-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 16:11:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16338 for ; Tue, 10 Feb 2004 16:11:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqfAW-00023C-00 for simple-web-archive@ietf.org; Tue, 10 Feb 2004 16:11:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqf94-0001ku-00 for simple-web-archive@ietf.org; Tue, 10 Feb 2004 16:10:14 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aqf7z-0001Wx-00; Tue, 10 Feb 2004 16:09:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqf7v-0006Qv-Ad; Tue, 10 Feb 2004 16:09:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqf7T-0006EU-HE for simple@optimus.ietf.org; Tue, 10 Feb 2004 16:08:35 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15467; Tue, 10 Feb 2004 16:08:32 -0500 (EST) Message-Id: <200402102108.QAA15467@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: simple@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-cipid-00.txt Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 10 Feb 2004 16:08:32 -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.4 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : CIPID: Contact Information in Presence Information Data Format Author(s) : H. Schulzrinne Filename : draft-ietf-simple-cipid-00.txt Pages : 15 Date : 2004-2-10 The Contact Information for Presence Information Data Format (CIPID) adds elements to the Presence Information Data Format (PIDF) that provide additional contact information about a presentity and its contacts, including references to address book entries and icons. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-cipid-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-cipid-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-cipid-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-2-10161459.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-cipid-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-cipid-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-10161459.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Feb 11 15:54:58 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22983 for ; Wed, 11 Feb 2004 15:54:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar1Nr-00045x-00 for simple-archive@ietf.org; Wed, 11 Feb 2004 15:54:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar1N2-0003zH-00 for simple-archive@ietf.org; Wed, 11 Feb 2004 15:54:08 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ar1M8-0003rU-00; Wed, 11 Feb 2004 15:53:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar1Lx-0004N3-C9; Wed, 11 Feb 2004 15:53:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar1L1-00049Q-Fc for simple@optimus.ietf.org; Wed, 11 Feb 2004 15:52:03 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22703; Wed, 11 Feb 2004 15:52:01 -0500 (EST) Message-Id: <200402112052.PAA22703@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: simple@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-cipid-00.txt Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 11 Feb 2004 15:52: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.4 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : CIPID: Contact Information in Presence Information Data Format Author(s) : H. Schulzrinne Filename : draft-ietf-simple-cipid-00.txt Pages : 15 Date : 2004-2-10 The Contact Information for Presence Information Data Format (CIPID) adds elements to the Presence Information Data Format (PIDF) that provide additional contact information about a presentity and its contacts, including references to address book entries and icons. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-cipid-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-cipid-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-cipid-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-2-11160651.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-cipid-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-cipid-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-11160651.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Feb 11 15:55:32 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 PAA23019 for ; Wed, 11 Feb 2004 15:55:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar1Nv-0004ee-Gx for simple-archive@odin.ietf.org; Wed, 11 Feb 2004 15:55:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1BKt3wm017882 for simple-archive@odin.ietf.org; Wed, 11 Feb 2004 15:55:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar1Nt-0004dy-V8 for simple-web-archive@optimus.ietf.org; Wed, 11 Feb 2004 15:55:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23003 for ; Wed, 11 Feb 2004 15:54:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar1Ns-000463-00 for simple-web-archive@ietf.org; Wed, 11 Feb 2004 15:55:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar1N2-0003zO-00 for simple-web-archive@ietf.org; Wed, 11 Feb 2004 15:54:09 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ar1M8-0003rU-00; Wed, 11 Feb 2004 15:53:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar1Lx-0004N3-C9; Wed, 11 Feb 2004 15:53:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar1L1-00049Q-Fc for simple@optimus.ietf.org; Wed, 11 Feb 2004 15:52:03 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22703; Wed, 11 Feb 2004 15:52:01 -0500 (EST) Message-Id: <200402112052.PAA22703@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: simple@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-cipid-00.txt Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 11 Feb 2004 15:52: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.4 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : CIPID: Contact Information in Presence Information Data Format Author(s) : H. Schulzrinne Filename : draft-ietf-simple-cipid-00.txt Pages : 15 Date : 2004-2-10 The Contact Information for Presence Information Data Format (CIPID) adds elements to the Presence Information Data Format (PIDF) that provide additional contact information about a presentity and its contacts, including references to address book entries and icons. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-cipid-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-cipid-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-cipid-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-2-11160651.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-cipid-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-cipid-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-11160651.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Feb 12 11:33: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 LAA01377 for ; Thu, 12 Feb 2004 11:33:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArJmX-0006v1-00 for simple-archive@ietf.org; Thu, 12 Feb 2004 11:33:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArJlc-0006lx-00 for simple-archive@ietf.org; Thu, 12 Feb 2004 11:32:45 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArJkv-0006ci-00; Thu, 12 Feb 2004 11:32:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArJku-0008C2-Vn; Thu, 12 Feb 2004 11:32:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArJkb-00087e-RE for simple@optimus.ietf.org; Thu, 12 Feb 2004 11:31:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01219 for ; Thu, 12 Feb 2004 11:31:39 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArJkY-0006a8-00 for simple@ietf.org; Thu, 12 Feb 2004 11:31:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArJjd-0006OQ-00 for simple@ietf.org; Thu, 12 Feb 2004 11:30:42 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1ArJib-0006DK-00 for simple@ietf.org; Thu, 12 Feb 2004 11:29:37 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1CGTbv14548 for ; Thu, 12 Feb 2004 18:29:37 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 12 Feb 2004 18:29:35 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 12 Feb 2004 18:29:36 +0200 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797748@esebe019.ntc.nokia.com> Thread-Topic: [XCON] "Many users in a single operation" Requirements Thread-Index: AcPvcz3Jb4YIVoLBQDSBV/8FJxrYogAONw5wAHVB4CAAAH6pcA== To: , Cc: X-OriginalArrivalTime: 12 Feb 2004 16:29:36.0850 (UTC) FILETIME=[67A7CB20:01C3F185] Content-Transfer-Encoding: quoted-printable Subject: [Simple] RE: [XCON] "Many users in a single operation" Requirements Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 12 Feb 2004 18:29:36 +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.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable [moved to SIMPLE since this is an XCAP issue] Ok, I see what you mean. XCAP says The content of the request MUST be a single XML element and associated content (including children elements). I don't know why that is. Isn't it enough that the URI points to a = single XML element? Perhaps Jonathan can comment on why the limitation = is in place. Else, the example I gave has to be modified as follows: PUT = http://xcap.example.com/services/conferences/users/Alice/conference.xml?C= onference HTTP/1.1 Content-Type:text/plain sip:bob@example.com sip:alice@example.com sip:bob@domain.com /Hisham > -----Original Message----- > From: ext Orit Levin [mailto:oritl@microsoft.com] > Sent: 12.February.2004 18:12 > To: Khartabil Hisham (Nokia-TP-MSW/Helsinki); xcon@ietf.org > Cc: Jonathan Rosenberg > Subject: RE: [XCON] "Many users in a single operation" Requirements >=20 >=20 > Where is this "XCAP extension" defined in the XCAP documents?! >=20 > Besides, you can't do in the same way REQ-CP-3: It MAY be possible for > the client to batch multiple operations (such as add a user to ACL > blocked list, or remove a user from ACL allowed list) into a single > request that is processed atomically. >=20 > Thanks, > Orit. >=20 > -----Original Message----- > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com]=20 > Sent: Tuesday, February 10, 2004 12:18 AM > To: Orit Levin; xcon@ietf.org > Subject: RE: [XCON] "Many users in a single operation" Requirements >=20 > Here is an example of how to add multiple users to an ACL list in a > single operation: >=20 > PUT > http://xcap.example.com/services/conferences/users/Alice/confe > rence.xml? > Conference/ACL/ACL-target-URI HTTP/1.1 > Content-Type:text/plain >=20 > Access-type=3D"Allowed">sip:bob@example.com > Access-type=3D"Allowed">sip:alice@example.com > Access-type=3D"Allowed">sip:bob@domain.com >=20 >=20 > The rest are done in a similar fashion. >=20 > /Hisham > > -----Original Message----- > > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On=20 > Behalf Of ext > > Orit Levin > > Sent: 10.February.2004 03:15 > > To: xcon@ietf.org > > Subject: [XCON] "Many users in a single operation" Requirements > >=20 > >=20 > > Hi guys! > > =20 > > There are many places throughout the CPCP-req document that identify > > operations on a "subset of list" as MUST be performed in a single > > operation (e.g. G4, G6, H2, and H4). > > How do you plan to meet these requirements with "XCAP CPCP"? > > =20 > > The same question for REQ-CP-3: It MAY be possible for the client to > > batch multiple operations (such as add a user to ACL=20 > blocked list, or > > remove a user from ACL allowed list) into a single request that is > > processed atomically. > > =20 > > Thanks, > > Orit. > >=20 > > _______________________________________________ > > XCON mailing list > > XCON@ietf.org > > https://www1.ietf.org/mailman/listinfo/xcon > >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Feb 12 11:34:13 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 LAA01410 for ; Thu, 12 Feb 2004 11:34:13 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArJmb-0008L8-C7 for simple-archive@odin.ietf.org; Thu, 12 Feb 2004 11:33:45 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1CGXjZb032057 for simple-archive@odin.ietf.org; Thu, 12 Feb 2004 11:33:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArJmb-0008Ky-8r for simple-web-archive@optimus.ietf.org; Thu, 12 Feb 2004 11:33:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01397 for ; Thu, 12 Feb 2004 11:33:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArJmY-0006v6-00 for simple-web-archive@ietf.org; Thu, 12 Feb 2004 11:33:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArJld-0006m4-00 for simple-web-archive@ietf.org; Thu, 12 Feb 2004 11:32:46 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArJkv-0006ci-00; Thu, 12 Feb 2004 11:32:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArJku-0008C2-Vn; Thu, 12 Feb 2004 11:32:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArJkb-00087e-RE for simple@optimus.ietf.org; Thu, 12 Feb 2004 11:31:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01219 for ; Thu, 12 Feb 2004 11:31:39 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArJkY-0006a8-00 for simple@ietf.org; Thu, 12 Feb 2004 11:31:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArJjd-0006OQ-00 for simple@ietf.org; Thu, 12 Feb 2004 11:30:42 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1ArJib-0006DK-00 for simple@ietf.org; Thu, 12 Feb 2004 11:29:37 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1CGTbv14548 for ; Thu, 12 Feb 2004 18:29:37 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 12 Feb 2004 18:29:35 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 12 Feb 2004 18:29:36 +0200 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797748@esebe019.ntc.nokia.com> Thread-Topic: [XCON] "Many users in a single operation" Requirements Thread-Index: AcPvcz3Jb4YIVoLBQDSBV/8FJxrYogAONw5wAHVB4CAAAH6pcA== To: , Cc: X-OriginalArrivalTime: 12 Feb 2004 16:29:36.0850 (UTC) FILETIME=[67A7CB20:01C3F185] Content-Transfer-Encoding: quoted-printable Subject: [Simple] RE: [XCON] "Many users in a single operation" Requirements Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 12 Feb 2004 18:29:36 +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.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable [moved to SIMPLE since this is an XCAP issue] Ok, I see what you mean. XCAP says The content of the request MUST be a single XML element and associated content (including children elements). I don't know why that is. Isn't it enough that the URI points to a = single XML element? Perhaps Jonathan can comment on why the limitation = is in place. Else, the example I gave has to be modified as follows: PUT = http://xcap.example.com/services/conferences/users/Alice/conference.xml?C= onference HTTP/1.1 Content-Type:text/plain sip:bob@example.com sip:alice@example.com sip:bob@domain.com /Hisham > -----Original Message----- > From: ext Orit Levin [mailto:oritl@microsoft.com] > Sent: 12.February.2004 18:12 > To: Khartabil Hisham (Nokia-TP-MSW/Helsinki); xcon@ietf.org > Cc: Jonathan Rosenberg > Subject: RE: [XCON] "Many users in a single operation" Requirements >=20 >=20 > Where is this "XCAP extension" defined in the XCAP documents?! >=20 > Besides, you can't do in the same way REQ-CP-3: It MAY be possible for > the client to batch multiple operations (such as add a user to ACL > blocked list, or remove a user from ACL allowed list) into a single > request that is processed atomically. >=20 > Thanks, > Orit. >=20 > -----Original Message----- > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com]=20 > Sent: Tuesday, February 10, 2004 12:18 AM > To: Orit Levin; xcon@ietf.org > Subject: RE: [XCON] "Many users in a single operation" Requirements >=20 > Here is an example of how to add multiple users to an ACL list in a > single operation: >=20 > PUT > http://xcap.example.com/services/conferences/users/Alice/confe > rence.xml? > Conference/ACL/ACL-target-URI HTTP/1.1 > Content-Type:text/plain >=20 > Access-type=3D"Allowed">sip:bob@example.com > Access-type=3D"Allowed">sip:alice@example.com > Access-type=3D"Allowed">sip:bob@domain.com >=20 >=20 > The rest are done in a similar fashion. >=20 > /Hisham > > -----Original Message----- > > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On=20 > Behalf Of ext > > Orit Levin > > Sent: 10.February.2004 03:15 > > To: xcon@ietf.org > > Subject: [XCON] "Many users in a single operation" Requirements > >=20 > >=20 > > Hi guys! > > =20 > > There are many places throughout the CPCP-req document that identify > > operations on a "subset of list" as MUST be performed in a single > > operation (e.g. G4, G6, H2, and H4). > > How do you plan to meet these requirements with "XCAP CPCP"? > > =20 > > The same question for REQ-CP-3: It MAY be possible for the client to > > batch multiple operations (such as add a user to ACL=20 > blocked list, or > > remove a user from ACL allowed list) into a single request that is > > processed atomically. > > =20 > > Thanks, > > Orit. > >=20 > > _______________________________________________ > > XCON mailing list > > XCON@ietf.org > > https://www1.ietf.org/mailman/listinfo/xcon > >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Feb 12 12:35:20 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03758 for ; Thu, 12 Feb 2004 12:35:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArKkB-0005Vg-00 for simple-archive@ietf.org; Thu, 12 Feb 2004 12:35:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArKjI-0005Qh-00 for simple-archive@ietf.org; Thu, 12 Feb 2004 12:34:25 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArKiz-0005LK-00; Thu, 12 Feb 2004 12:34:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArKiv-0007PN-8t; Thu, 12 Feb 2004 12:34:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArKiN-0007MB-Hz for simple@optimus.ietf.org; Thu, 12 Feb 2004 12:33:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03680 for ; Thu, 12 Feb 2004 12:33:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArKiK-0005KL-00 for simple@ietf.org; Thu, 12 Feb 2004 12:33:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArKhP-0005EY-00 for simple@ietf.org; Thu, 12 Feb 2004 12:32:28 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1ArKgs-00057S-00 for simple@ietf.org; Thu, 12 Feb 2004 12:31:55 -0500 Received: from dynamicsoft.com ([63.113.46.48]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i1CHVVNr003327; Thu, 12 Feb 2004 12:31:32 -0500 (EST) Message-ID: <402BB869.504@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: hisham.khartabil@nokia.com CC: oritl@microsoft.com, simple@ietf.org References: <2038BCC78B1AD641891A0D1AE133DBB701797748@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701797748@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Re: [XCON] "Many users in a single operation" Requirements Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 12 Feb 2004 12:31:21 -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.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sorry for the delay here... Orit is right, and as you point out below, you can in fact only add a single element/subtree at a time. The reason is that, in order to use http out of the box, we need to keep its semantics. That means that things like GET(PUT(URI, body)) == body need to be maintained. If you did a get on the URI below, you would retrieve the first entry. Indeed, if you did the original PUT you suggested: PUT http://xcap.example.com/services/conferences/users/Alice/conference.xml? Conference/ACL/ACL-target-URI HTTP/1.1 Content-Type:text/plain sip:bob@example.com sip:alice@example.com sip:bob@domain.com and there was already an ACL-target-URI in the document, it would be REPLACED by what is provided in the body. Thats normal http - if you PUT to a URI that identifies an existing resource, it gets replaced. more inline. hisham.khartabil@nokia.com wrote: > [moved to SIMPLE since this is an XCAP issue] > > Ok, I see what you mean. XCAP says > > The content of the request MUST be a single XML element and > associated content (including children elements). > > I don't know why that is. Isn't it enough that the URI points to a > single XML element? Perhaps Jonathan can comment on why the > limitation is in place. See above. > > Else, the example I gave has to be modified as follows: > > PUT > http://xcap.example.com/services/conferences/users/Alice/conference.xml?Conference > HTTP/1.1 Content-Type:text/plain > > Access-type="Allowed">sip:bob@example.com > Access-type="Allowed">sip:alice@example.com > Access-type="Allowed">sip:bob@domain.com Yes, this would work. Effectively, since you can only add/replace/delete a single element at a time, you need to introduce hierarchy in the XML *IF* you want this kind of batching operation. I'll note that, once you do the PUT above to add the three entries, you can also do a single DELETE to remove that same three, but if you wanted to delete two of the three, then you would need to do two separate transactions. We had discussed this particular limitation quite a bit during the design of xcap, and it was deemed an acceptable limitation. If it is no longer the case, then we can discuss fixes. Allowing for deletion of multiple entries at a time is relatively easy. Indeed, whether to allow this was an open issue for a time, and we simplified to say no. If we allow fuller xpath expressions in the URI, you can include, in a DELETE, an xpath expression that selects multiple elements. Then, the delete would remove everything that is selected. The penalty for this is we need to support much more of xpath, whereas now the subset is so small, it is fully defined within xcap itself. Adding multiple elements could be done the same kind of way - the HTTP URI expression would need to be something which (1) selects nothing when applied to the current document, (2) selects the contents of the body once the elements are added to the document. You can do that by using id parameters and other tokens that can be placed as attributes of the xml element. There would still be a limitation that you could not add multiple elements at differing points of attachment in the tree; though xpath can define such selectors, the insertion operation for this becomes nearly impossible to perform, I believe. Comments? Thanks, Jonathan R. > > /Hisham > > >> -----Original Message----- From: ext Orit Levin >> [mailto:oritl@microsoft.com] Sent: 12.February.2004 18:12 To: >> Khartabil Hisham (Nokia-TP-MSW/Helsinki); xcon@ietf.org Cc: >> Jonathan Rosenberg Subject: RE: [XCON] "Many users in a single >> operation" Requirements >> >> >> Where is this "XCAP extension" defined in the XCAP documents?! >> >> Besides, you can't do in the same way REQ-CP-3: It MAY be possible >> for the client to batch multiple operations (such as add a user to >> ACL blocked list, or remove a user from ACL allowed list) into a >> single request that is processed atomically. >> >> Thanks, Orit. >> >> -----Original Message----- From: hisham.khartabil@nokia.com >> [mailto:hisham.khartabil@nokia.com] Sent: Tuesday, February 10, >> 2004 12:18 AM To: Orit Levin; xcon@ietf.org Subject: RE: [XCON] >> "Many users in a single operation" Requirements >> >> Here is an example of how to add multiple users to an ACL list in a >> single operation: >> >> PUT http://xcap.example.com/services/conferences/users/Alice/confe >> rence.xml? Conference/ACL/ACL-target-URI HTTP/1.1 >> Content-Type:text/plain >> >> > Access-type="Allowed">sip:bob@example.com >> > Access-type="Allowed">sip:alice@example.com >> > Access-type="Allowed">sip:bob@domain.com >> >> >> The rest are done in a similar fashion. >> >> /Hisham >> >>> -----Original Message----- From: xcon-admin@ietf.org >>> [mailto:xcon-admin@ietf.org]On >> >> Behalf Of ext >> >>> Orit Levin Sent: 10.February.2004 03:15 To: xcon@ietf.org >>> Subject: [XCON] "Many users in a single operation" Requirements >>> >>> >>> Hi guys! >>> >>> There are many places throughout the CPCP-req document that >>> identify operations on a "subset of list" as MUST be performed in >>> a single operation (e.g. G4, G6, H2, and H4). How do you plan to >>> meet these requirements with "XCAP CPCP"? >>> >>> The same question for REQ-CP-3: It MAY be possible for the client >>> to batch multiple operations (such as add a user to ACL >> >> blocked list, or >> >>> remove a user from ACL allowed list) into a single request that >>> is processed atomically. >>> >>> Thanks, Orit. >>> >>> _______________________________________________ XCON mailing list >>> XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon >>> >> > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Feb 12 12:35:52 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 MAA03798 for ; Thu, 12 Feb 2004 12:35:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArKkG-0007Z0-CI for simple-archive@odin.ietf.org; Thu, 12 Feb 2004 12:35:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1CHZOnd029068 for simple-archive@odin.ietf.org; Thu, 12 Feb 2004 12:35:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArKkG-0007Yl-88 for simple-web-archive@optimus.ietf.org; Thu, 12 Feb 2004 12:35:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03776 for ; Thu, 12 Feb 2004 12:35:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArKkC-0005Vl-00 for simple-web-archive@ietf.org; Thu, 12 Feb 2004 12:35:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArKjJ-0005Qo-00 for simple-web-archive@ietf.org; Thu, 12 Feb 2004 12:34:26 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArKiz-0005LK-00; Thu, 12 Feb 2004 12:34:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArKiv-0007PN-8t; Thu, 12 Feb 2004 12:34:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArKiN-0007MB-Hz for simple@optimus.ietf.org; Thu, 12 Feb 2004 12:33:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03680 for ; Thu, 12 Feb 2004 12:33:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArKiK-0005KL-00 for simple@ietf.org; Thu, 12 Feb 2004 12:33:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArKhP-0005EY-00 for simple@ietf.org; Thu, 12 Feb 2004 12:32:28 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1ArKgs-00057S-00 for simple@ietf.org; Thu, 12 Feb 2004 12:31:55 -0500 Received: from dynamicsoft.com ([63.113.46.48]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i1CHVVNr003327; Thu, 12 Feb 2004 12:31:32 -0500 (EST) Message-ID: <402BB869.504@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: hisham.khartabil@nokia.com CC: oritl@microsoft.com, simple@ietf.org References: <2038BCC78B1AD641891A0D1AE133DBB701797748@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701797748@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Re: [XCON] "Many users in a single operation" Requirements Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 12 Feb 2004 12:31:21 -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.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sorry for the delay here... Orit is right, and as you point out below, you can in fact only add a single element/subtree at a time. The reason is that, in order to use http out of the box, we need to keep its semantics. That means that things like GET(PUT(URI, body)) == body need to be maintained. If you did a get on the URI below, you would retrieve the first entry. Indeed, if you did the original PUT you suggested: PUT http://xcap.example.com/services/conferences/users/Alice/conference.xml? Conference/ACL/ACL-target-URI HTTP/1.1 Content-Type:text/plain sip:bob@example.com sip:alice@example.com sip:bob@domain.com and there was already an ACL-target-URI in the document, it would be REPLACED by what is provided in the body. Thats normal http - if you PUT to a URI that identifies an existing resource, it gets replaced. more inline. hisham.khartabil@nokia.com wrote: > [moved to SIMPLE since this is an XCAP issue] > > Ok, I see what you mean. XCAP says > > The content of the request MUST be a single XML element and > associated content (including children elements). > > I don't know why that is. Isn't it enough that the URI points to a > single XML element? Perhaps Jonathan can comment on why the > limitation is in place. See above. > > Else, the example I gave has to be modified as follows: > > PUT > http://xcap.example.com/services/conferences/users/Alice/conference.xml?Conference > HTTP/1.1 Content-Type:text/plain > > Access-type="Allowed">sip:bob@example.com > Access-type="Allowed">sip:alice@example.com > Access-type="Allowed">sip:bob@domain.com Yes, this would work. Effectively, since you can only add/replace/delete a single element at a time, you need to introduce hierarchy in the XML *IF* you want this kind of batching operation. I'll note that, once you do the PUT above to add the three entries, you can also do a single DELETE to remove that same three, but if you wanted to delete two of the three, then you would need to do two separate transactions. We had discussed this particular limitation quite a bit during the design of xcap, and it was deemed an acceptable limitation. If it is no longer the case, then we can discuss fixes. Allowing for deletion of multiple entries at a time is relatively easy. Indeed, whether to allow this was an open issue for a time, and we simplified to say no. If we allow fuller xpath expressions in the URI, you can include, in a DELETE, an xpath expression that selects multiple elements. Then, the delete would remove everything that is selected. The penalty for this is we need to support much more of xpath, whereas now the subset is so small, it is fully defined within xcap itself. Adding multiple elements could be done the same kind of way - the HTTP URI expression would need to be something which (1) selects nothing when applied to the current document, (2) selects the contents of the body once the elements are added to the document. You can do that by using id parameters and other tokens that can be placed as attributes of the xml element. There would still be a limitation that you could not add multiple elements at differing points of attachment in the tree; though xpath can define such selectors, the insertion operation for this becomes nearly impossible to perform, I believe. Comments? Thanks, Jonathan R. > > /Hisham > > >> -----Original Message----- From: ext Orit Levin >> [mailto:oritl@microsoft.com] Sent: 12.February.2004 18:12 To: >> Khartabil Hisham (Nokia-TP-MSW/Helsinki); xcon@ietf.org Cc: >> Jonathan Rosenberg Subject: RE: [XCON] "Many users in a single >> operation" Requirements >> >> >> Where is this "XCAP extension" defined in the XCAP documents?! >> >> Besides, you can't do in the same way REQ-CP-3: It MAY be possible >> for the client to batch multiple operations (such as add a user to >> ACL blocked list, or remove a user from ACL allowed list) into a >> single request that is processed atomically. >> >> Thanks, Orit. >> >> -----Original Message----- From: hisham.khartabil@nokia.com >> [mailto:hisham.khartabil@nokia.com] Sent: Tuesday, February 10, >> 2004 12:18 AM To: Orit Levin; xcon@ietf.org Subject: RE: [XCON] >> "Many users in a single operation" Requirements >> >> Here is an example of how to add multiple users to an ACL list in a >> single operation: >> >> PUT http://xcap.example.com/services/conferences/users/Alice/confe >> rence.xml? Conference/ACL/ACL-target-URI HTTP/1.1 >> Content-Type:text/plain >> >> > Access-type="Allowed">sip:bob@example.com >> > Access-type="Allowed">sip:alice@example.com >> > Access-type="Allowed">sip:bob@domain.com >> >> >> The rest are done in a similar fashion. >> >> /Hisham >> >>> -----Original Message----- From: xcon-admin@ietf.org >>> [mailto:xcon-admin@ietf.org]On >> >> Behalf Of ext >> >>> Orit Levin Sent: 10.February.2004 03:15 To: xcon@ietf.org >>> Subject: [XCON] "Many users in a single operation" Requirements >>> >>> >>> Hi guys! >>> >>> There are many places throughout the CPCP-req document that >>> identify operations on a "subset of list" as MUST be performed in >>> a single operation (e.g. G4, G6, H2, and H4). How do you plan to >>> meet these requirements with "XCAP CPCP"? >>> >>> The same question for REQ-CP-3: It MAY be possible for the client >>> to batch multiple operations (such as add a user to ACL >> >> blocked list, or >> >>> remove a user from ACL allowed list) into a single request that >>> is processed atomically. >>> >>> Thanks, Orit. >>> >>> _______________________________________________ XCON mailing list >>> XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon >>> >> > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Feb 12 16:06:41 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15622 for ; Thu, 12 Feb 2004 16:06:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArO2i-0004Lj-00 for simple-archive@ietf.org; Thu, 12 Feb 2004 16:06:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArO1m-0004Et-00 for simple-archive@ietf.org; Thu, 12 Feb 2004 16:05:43 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArO1D-00047t-00; Thu, 12 Feb 2004 16:05:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArO18-0005Yj-Qu; Thu, 12 Feb 2004 16:05:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArO0g-0005Uw-0J for simple@optimus.ietf.org; Thu, 12 Feb 2004 16:04:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15508 for ; Thu, 12 Feb 2004 16:04:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArO0c-00044b-00 for simple@ietf.org; Thu, 12 Feb 2004 16:04:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArNzh-0003yc-00 for simple@ietf.org; Thu, 12 Feb 2004 16:03:34 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1ArNys-0003mB-00 for simple@ietf.org; Thu, 12 Feb 2004 16:02:42 -0500 Received: from dynamicsoft.com ([63.113.46.48]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i1CL2LNr003425; Thu, 12 Feb 2004 16:02:21 -0500 (EST) Message-ID: <402BE9D3.7090408@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: Jari Urpalainen CC: simple@ietf.org Subject: Re: [Simple] XCAP questions References: <4018DECF.7040108@nokia.com> In-Reply-To: <4018DECF.7040108@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 12 Feb 2004 16:02:11 -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=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sorry for the delay in responding. Thanks so much for your comments and questions. Answers inline. Jari Urpalainen wrote: > Hi ! > > I have been developing a reference implementation for XCAP server > (standalone and an Apache module). There are some open/unclear issues > (to me at least), so here's the list of questions. > > 1. XCAP directory list > In XCAP presence auth draft chapter 4.4, there's a requirement to get > all documents from the server. However, in the base XCAP draft it is > unspecified how the server should send this directory list. While > http-servers can/will provide this information in many ways, IMO the > base XCAP draft should specify this format (xml?). Furhermore, it would > be nice if ETags were included in the response in order to help to > synchonize documents between the client and the server. In the model I had in my head, the presence server itself didnt use xcap to fetch the documents; that interface was something proprietary. However, if xcap is being used there, you are right that there would need to be a standardized way to obtain the list. One way I would suggest for this is to define an application usage which is the "directory" of documents for a specific user. This application usage would specify a single well known place where the document would live. The end user themselves would not need to modify it; the server could set it when the user manages their own documents. This would then be read-only, and visible to either a user or more importantly, to a PE. I think this is more or less what Markus has proposed as well. The question is, where does such a definition occur: 1. base xcap spec 2. as part of each application usage 3. a special "directory" application usage I prefer (3); we could define this once, and the "directory" would contain information on the documents for a user across all application usages. > > 2. XCAP ETags > In order to ease the synchronizing within resources between client and > server the base XCAP draft could specify the secure hash method e.g. > SHA-1 or whatever that is used to calculate the ETag. This is already > proposed in xcap-package but IMHO could be in the base spec. I don't follow. The etag is purely a server computed value. Generally, there is no need to specify how it is computed. Why does it matter how its computed? > > 3. XCAP attributes > When updating/querying attributes is it necessary to include attribute > name in payload as attribute name is already provided in XPATH-query ? > > e.g. you could get /resource-lists/list[@name="friends"]/@uri > so you already know that you receive response for attribute uri. IMHO > when putting/getting attributes, payload could include only attribute > value. That can be true as long as the URI can only identify an attribute by name. I can change this as long as we stick to that constraint. > > 4. XCAP namespace declarations > As namespace handling resemble "standard" XML attributes is it also > allowed to change namespace declarations with similar semantics ? Great question. The answer is no. The reason is say that is that in xpath, namespace declarations are treated differently. If you want to get access to the namespaces of an element, you have to use the explicit namespace axis. I want to make sure that our URI addressing conventions do not violate or contradict xpath, and so I think they need to be consistent. I will clarify in the draft that the selectors do not apply to namespaces, comments or text content. If we want to be able to access and modify those, we need to expand the scope beyond where we are now. I would prefer not to do that. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Feb 12 16:07:13 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 QAA15651 for ; Thu, 12 Feb 2004 16:07:13 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArO2m-0005mW-Hz for simple-archive@odin.ietf.org; Thu, 12 Feb 2004 16:06:44 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1CL6i6M022223 for simple-archive@odin.ietf.org; Thu, 12 Feb 2004 16:06:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArO2m-0005mM-EP for simple-web-archive@optimus.ietf.org; Thu, 12 Feb 2004 16:06:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15639 for ; Thu, 12 Feb 2004 16:06:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArO2i-0004Lo-00 for simple-web-archive@ietf.org; Thu, 12 Feb 2004 16:06:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArO1n-0004F0-00 for simple-web-archive@ietf.org; Thu, 12 Feb 2004 16:05:44 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArO1D-00047t-00; Thu, 12 Feb 2004 16:05:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArO18-0005Yj-Qu; Thu, 12 Feb 2004 16:05:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArO0g-0005Uw-0J for simple@optimus.ietf.org; Thu, 12 Feb 2004 16:04:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15508 for ; Thu, 12 Feb 2004 16:04:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArO0c-00044b-00 for simple@ietf.org; Thu, 12 Feb 2004 16:04:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArNzh-0003yc-00 for simple@ietf.org; Thu, 12 Feb 2004 16:03:34 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1ArNys-0003mB-00 for simple@ietf.org; Thu, 12 Feb 2004 16:02:42 -0500 Received: from dynamicsoft.com ([63.113.46.48]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i1CL2LNr003425; Thu, 12 Feb 2004 16:02:21 -0500 (EST) Message-ID: <402BE9D3.7090408@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: Jari Urpalainen CC: simple@ietf.org Subject: Re: [Simple] XCAP questions References: <4018DECF.7040108@nokia.com> In-Reply-To: <4018DECF.7040108@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 12 Feb 2004 16:02:11 -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=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sorry for the delay in responding. Thanks so much for your comments and questions. Answers inline. Jari Urpalainen wrote: > Hi ! > > I have been developing a reference implementation for XCAP server > (standalone and an Apache module). There are some open/unclear issues > (to me at least), so here's the list of questions. > > 1. XCAP directory list > In XCAP presence auth draft chapter 4.4, there's a requirement to get > all documents from the server. However, in the base XCAP draft it is > unspecified how the server should send this directory list. While > http-servers can/will provide this information in many ways, IMO the > base XCAP draft should specify this format (xml?). Furhermore, it would > be nice if ETags were included in the response in order to help to > synchonize documents between the client and the server. In the model I had in my head, the presence server itself didnt use xcap to fetch the documents; that interface was something proprietary. However, if xcap is being used there, you are right that there would need to be a standardized way to obtain the list. One way I would suggest for this is to define an application usage which is the "directory" of documents for a specific user. This application usage would specify a single well known place where the document would live. The end user themselves would not need to modify it; the server could set it when the user manages their own documents. This would then be read-only, and visible to either a user or more importantly, to a PE. I think this is more or less what Markus has proposed as well. The question is, where does such a definition occur: 1. base xcap spec 2. as part of each application usage 3. a special "directory" application usage I prefer (3); we could define this once, and the "directory" would contain information on the documents for a user across all application usages. > > 2. XCAP ETags > In order to ease the synchronizing within resources between client and > server the base XCAP draft could specify the secure hash method e.g. > SHA-1 or whatever that is used to calculate the ETag. This is already > proposed in xcap-package but IMHO could be in the base spec. I don't follow. The etag is purely a server computed value. Generally, there is no need to specify how it is computed. Why does it matter how its computed? > > 3. XCAP attributes > When updating/querying attributes is it necessary to include attribute > name in payload as attribute name is already provided in XPATH-query ? > > e.g. you could get /resource-lists/list[@name="friends"]/@uri > so you already know that you receive response for attribute uri. IMHO > when putting/getting attributes, payload could include only attribute > value. That can be true as long as the URI can only identify an attribute by name. I can change this as long as we stick to that constraint. > > 4. XCAP namespace declarations > As namespace handling resemble "standard" XML attributes is it also > allowed to change namespace declarations with similar semantics ? Great question. The answer is no. The reason is say that is that in xpath, namespace declarations are treated differently. If you want to get access to the namespaces of an element, you have to use the explicit namespace axis. I want to make sure that our URI addressing conventions do not violate or contradict xpath, and so I think they need to be consistent. I will clarify in the draft that the selectors do not apply to namespaces, comments or text content. If we want to be able to access and modify those, we need to expand the scope beyond where we are now. I would prefer not to do that. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Feb 12 16:45:28 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17845 for ; Thu, 12 Feb 2004 16:45:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArOeE-0000Vx-00 for simple-archive@ietf.org; Thu, 12 Feb 2004 16:45:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArOdQ-0000RT-00 for simple-archive@ietf.org; Thu, 12 Feb 2004 16:44:37 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArOcq-0000Lm-00; Thu, 12 Feb 2004 16:44:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArOcq-0001Ze-Qi; Thu, 12 Feb 2004 16:44:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArOcW-0001Vm-9C for simple@optimus.ietf.org; Thu, 12 Feb 2004 16:43:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17653 for ; Thu, 12 Feb 2004 16:43:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArOcS-0000IZ-00 for simple@ietf.org; Thu, 12 Feb 2004 16:43:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArObX-00008k-00 for simple@ietf.org; Thu, 12 Feb 2004 16:42:40 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1ArOad-0007hV-00 for simple@ietf.org; Thu, 12 Feb 2004 16:41:43 -0500 Received: from dynamicsoft.com ([63.113.46.48]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i1CLfMNr003488; Thu, 12 Feb 2004 16:41:23 -0500 (EST) Message-ID: <402BF2F9.1010904@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: hisham.khartabil@nokia.com CC: simple@ietf.org Subject: Re: [Simple] Comments on xcap-list-usage References: <2038BCC78B1AD641891A0D1AE133DBB701797679@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701797679@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 12 Feb 2004 16:41:13 -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=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit I wish it were true that display names were enough, and that a URI itself was invisible to users, so that its structure was unimportant. But historically, this has not been the case. I beleive there will be a strong desire for vanity URIs, and that we need to be able to support that. I would propose adding the ability of the user to select the URI. If it cannot be assigned, the error response (409) will contain some xml-meta data. We'll define, in base xcap, a meta-data specifically for the case of "URI cannot be assigned", as I expect this to be a very common case for server assigned data. OK? -Jonathan R. hisham.khartabil@nokia.com wrote: > Well, you can always have a display name that the user can set. If the list usage, you have the name attribute. > > In CPCP usage, we defined the Display-name element. I think that should do it. > > /Hisham > > >>-----Original Message----- >>From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] >>Sent: 29.January.2004 00:29 >>To: Khartabil Hisham (Nokia-TP/Helsinki) >>Cc: simple@ietf.org >>Subject: Re: [Simple] Comments on xcap-list-usage >> >> >>Certainly that tactic is simpler. However, it makes it hard to have >>"vanity URIs" for specific lists, for example - >>jonathans-friends@example.com. Do we think that this function >>is needed? >> >>-Jonathan R. >> >>hisham.khartabil@nokia.com wrote: >> >> >>>I would like to follow up on this issue since I faced the >> >>same problem while updating the XCAP usage for CPCP. >> >>> >>>>-----Original Message----- >>>>From: simple-admin@ietf.org >> >>[mailto:simple-admin@ietf.org]On Behalf Of >> >>>>ext Jonathan Rosenberg >>>>Sent: 13.November.2003 11:14 >>>>To: Khartabil Hisham (NMP-MSW/Helsinki) >>>>Cc: simple@ietf.org >>>>Subject: Re: [Simple] Comments on xcap-list-usage >>>> >>>>hisham.khartabil@nokia.com wrote: >>>> >>>> >>>>>- If the "uri" attribute is absent in a document, but the >>>>>"subscribeable" flag is set to true. the XCAP server must allocate >>>>>a URI. But what if the URI is present but conflicts with an already >>>>>existing URI? How does the server react? Does it reject the request >>>>>or does it just rewrite the URI? >>>> >>>>Great question. >>>> >>>>I think it should return an error. The reason is that the document >>>>would be in violation of one of the non-schema data constraints. >>>> >>>>The real question is, how does the client know that it should retry >>>>with a different URI? >>>> >>>>I see no obvious answer. There are a few possibilities: >>>> >>>> * disallow clients from setting the URI >>>> * invent a new error resposne code >>>> * add a body to the 409 that describes the condition >>>> >>> >>> >>>I think the easiest and fastest thing to do is disallow the >> >>client from setting the URI. Any other opinions? >> >>>Regards, >>>Hisham >>> >> >>-- >>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 >> >> > > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Feb 12 16:45:59 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 QAA17870 for ; Thu, 12 Feb 2004 16:45:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArOeJ-0001sN-KL for simple-archive@odin.ietf.org; Thu, 12 Feb 2004 16:45:31 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1CLjVho007207 for simple-archive@odin.ietf.org; Thu, 12 Feb 2004 16:45:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArOeJ-0001sA-G5 for simple-web-archive@optimus.ietf.org; Thu, 12 Feb 2004 16:45:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17863 for ; Thu, 12 Feb 2004 16:45:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArOeF-0000W2-00 for simple-web-archive@ietf.org; Thu, 12 Feb 2004 16:45:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArOdR-0000Ra-00 for simple-web-archive@ietf.org; Thu, 12 Feb 2004 16:44:38 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArOcq-0000Lm-00; Thu, 12 Feb 2004 16:44:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArOcq-0001Ze-Qi; Thu, 12 Feb 2004 16:44:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArOcW-0001Vm-9C for simple@optimus.ietf.org; Thu, 12 Feb 2004 16:43:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17653 for ; Thu, 12 Feb 2004 16:43:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArOcS-0000IZ-00 for simple@ietf.org; Thu, 12 Feb 2004 16:43:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArObX-00008k-00 for simple@ietf.org; Thu, 12 Feb 2004 16:42:40 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1ArOad-0007hV-00 for simple@ietf.org; Thu, 12 Feb 2004 16:41:43 -0500 Received: from dynamicsoft.com ([63.113.46.48]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i1CLfMNr003488; Thu, 12 Feb 2004 16:41:23 -0500 (EST) Message-ID: <402BF2F9.1010904@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: hisham.khartabil@nokia.com CC: simple@ietf.org Subject: Re: [Simple] Comments on xcap-list-usage References: <2038BCC78B1AD641891A0D1AE133DBB701797679@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701797679@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 12 Feb 2004 16:41:13 -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=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I wish it were true that display names were enough, and that a URI itself was invisible to users, so that its structure was unimportant. But historically, this has not been the case. I beleive there will be a strong desire for vanity URIs, and that we need to be able to support that. I would propose adding the ability of the user to select the URI. If it cannot be assigned, the error response (409) will contain some xml-meta data. We'll define, in base xcap, a meta-data specifically for the case of "URI cannot be assigned", as I expect this to be a very common case for server assigned data. OK? -Jonathan R. hisham.khartabil@nokia.com wrote: > Well, you can always have a display name that the user can set. If the list usage, you have the name attribute. > > In CPCP usage, we defined the Display-name element. I think that should do it. > > /Hisham > > >>-----Original Message----- >>From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] >>Sent: 29.January.2004 00:29 >>To: Khartabil Hisham (Nokia-TP/Helsinki) >>Cc: simple@ietf.org >>Subject: Re: [Simple] Comments on xcap-list-usage >> >> >>Certainly that tactic is simpler. However, it makes it hard to have >>"vanity URIs" for specific lists, for example - >>jonathans-friends@example.com. Do we think that this function >>is needed? >> >>-Jonathan R. >> >>hisham.khartabil@nokia.com wrote: >> >> >>>I would like to follow up on this issue since I faced the >> >>same problem while updating the XCAP usage for CPCP. >> >>> >>>>-----Original Message----- >>>>From: simple-admin@ietf.org >> >>[mailto:simple-admin@ietf.org]On Behalf Of >> >>>>ext Jonathan Rosenberg >>>>Sent: 13.November.2003 11:14 >>>>To: Khartabil Hisham (NMP-MSW/Helsinki) >>>>Cc: simple@ietf.org >>>>Subject: Re: [Simple] Comments on xcap-list-usage >>>> >>>>hisham.khartabil@nokia.com wrote: >>>> >>>> >>>>>- If the "uri" attribute is absent in a document, but the >>>>>"subscribeable" flag is set to true. the XCAP server must allocate >>>>>a URI. But what if the URI is present but conflicts with an already >>>>>existing URI? How does the server react? Does it reject the request >>>>>or does it just rewrite the URI? >>>> >>>>Great question. >>>> >>>>I think it should return an error. The reason is that the document >>>>would be in violation of one of the non-schema data constraints. >>>> >>>>The real question is, how does the client know that it should retry >>>>with a different URI? >>>> >>>>I see no obvious answer. There are a few possibilities: >>>> >>>> * disallow clients from setting the URI >>>> * invent a new error resposne code >>>> * add a body to the 409 that describes the condition >>>> >>> >>> >>>I think the easiest and fastest thing to do is disallow the >> >>client from setting the URI. Any other opinions? >> >>>Regards, >>>Hisham >>> >> >>-- >>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 >> >> > > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Feb 13 03:35:56 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28426 for ; Fri, 13 Feb 2004 03:35:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArYni-0007en-00 for simple-archive@ietf.org; Fri, 13 Feb 2004 03:35:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArYmn-0007ZV-00 for simple-archive@ietf.org; Fri, 13 Feb 2004 03:34:58 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArYmI-0007UE-00; Fri, 13 Feb 2004 03:34:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArYlv-0004vk-Mn; Fri, 13 Feb 2004 03:34:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArYlm-0004vN-T7 for simple@optimus.ietf.org; Fri, 13 Feb 2004 03:33:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28328 for ; Fri, 13 Feb 2004 03:33:49 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArYle-0007T4-00 for simple@ietf.org; Fri, 13 Feb 2004 03:33:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArYkj-0007Os-00 for simple@ietf.org; Fri, 13 Feb 2004 03:32:50 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1ArYk5-0007Kb-00 for simple@ietf.org; Fri, 13 Feb 2004 03:32:09 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1D8W4v22175 for ; Fri, 13 Feb 2004 10:32:09 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 13 Feb 2004 10:31:03 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 13 Feb 2004 10:31:05 +0200 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70179774B@esebe019.ntc.nokia.com> Thread-Topic: [XCON] "Many users in a single operation" Requirements Thread-Index: AcPxjlo8gqOFiqTUTOavC5V+B2QiHwAfMcTw To: Cc: , X-OriginalArrivalTime: 13 Feb 2004 08:31:05.0359 (UTC) FILETIME=[B8AFB1F0:01C3F20B] Content-Transfer-Encoding: quoted-printable Subject: [Simple] RE: [XCON] "Many users in a single operation" Requirements Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.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, 13 Feb 2004 10:31:02 +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.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: 12.February.2004 19:31 > To: Khartabil Hisham (Nokia-TP-MSW/Helsinki) > Cc: oritl@microsoft.com; simple@ietf.org > Subject: Re: [XCON] "Many users in a single operation" Requirements >=20 >=20 > Sorry for the delay here... >=20 > Orit is right, and as you point out below, you can in fact only add a > single element/subtree at a time. >=20 > The reason is that, in order to use http out of the box, we=20 > need to keep=20 > its semantics. That means that things like GET(PUT(URI,=20 > body)) =3D=3D body=20 > need to be maintained. If you did a get on the URI below, you would=20 > retrieve the first entry. Indeed, if you did the original PUT=20 > you suggested: >=20 > PUT=20 > http://xcap.example.com/services/conferences/users/Alice/confe > rence.xml? > Conference/ACL/ACL-target-URI HTTP/1.1 > Content-Type:text/plain >=20 > Access-type=3D"Allowed">sip:bob@example.com > Access-type=3D"Allowed">sip:alice@example.com > Access-type=3D"Allowed">sip:bob@domain.com >From why I understand from the current specs, the above example is not = possible since the conent of the PUT contians more than 1 element and = therefore is illegal. >=20 > and there was already an ACL-target-URI in the document, it would be=20 > REPLACED by what is provided in the body. Thats normal http -=20 > if you PUT=20 > to a URI that identifies an existing resource, it gets replaced. >=20 > more inline. >=20 >=20 > hisham.khartabil@nokia.com wrote: >=20 > > [moved to SIMPLE since this is an XCAP issue] > >=20 > > Ok, I see what you mean. XCAP says > >=20 > > The content of the request MUST be a single XML element and > > associated content (including children elements). > >=20 > > I don't know why that is. Isn't it enough that the URI points to a > > single XML element? Perhaps Jonathan can comment on why the > > limitation is in place. >=20 > See above. >=20 > >=20 > > Else, the example I gave has to be modified as follows: > >=20 > > PUT > >=20 > http://xcap.example.com/services/conferences/users/Alice/confe > rence.xml?Conference > > HTTP/1.1 Content-Type:text/plain > >=20 > > > Access-type=3D"Allowed">sip:bob@example.com=20 > > > Access-type=3D"Allowed">sip:alice@example.com=20 > > > Access-type=3D"Allowed">sip:bob@domain.com >=20 > Yes, this would work. Effectively, since you can only=20 > add/replace/delete=20 > a single element at a time, you need to introduce hierarchy=20 > in the XML=20 > *IF* you want this kind of batching operation. I'll note=20 > that, once you=20 > do the PUT above to add the three entries, you can also do a single=20 > DELETE to remove that same three, but if you wanted to delete=20 > two of the=20 > three, then you would need to do two separate transactions. >=20 > We had discussed this particular limitation quite a bit during the=20 > design of xcap, and it was deemed an acceptable limitation.=20 I'm ok with replacing the whole ACL if ACL manipulation is needed. It = satisfies the requirement anyhow that way. > If it is no=20 > longer the case, then we can discuss fixes. [as a chair] I suggest working on those fixes later. /Hisham >=20 > Allowing for deletion of multiple entries at a time is=20 > relatively easy.=20 > Indeed, whether to allow this was an open issue for a time, and we=20 > simplified to say no. If we allow fuller xpath expressions in=20 > the URI,=20 > you can include, in a DELETE, an xpath expression that=20 > selects multiple=20 > elements. Then, the delete would remove everything that is=20 > selected. The=20 > penalty for this is we need to support much more of xpath,=20 > whereas now=20 > the subset is so small, it is fully defined within xcap itself. >=20 > Adding multiple elements could be done the same kind of way -=20 > the HTTP=20 > URI expression would need to be something which (1) selects=20 > nothing when=20 > applied to the current document, (2) selects the contents of the body=20 > once the elements are added to the document. You can do that=20 > by using id=20 > parameters and other tokens that can be placed as attributes=20 > of the xml=20 > element. >=20 > There would still be a limitation that you could not add multiple=20 > elements at differing points of attachment in the tree;=20 > though xpath can=20 > define such selectors, the insertion operation for this=20 > becomes nearly=20 > impossible to perform, I believe. >=20 > Comments? >=20 > Thanks, > Jonathan R. > >=20 > > /Hisham > >=20 > >=20 > >> -----Original Message----- From: ext Orit Levin > >> [mailto:oritl@microsoft.com] Sent: 12.February.2004 18:12 To: > >> Khartabil Hisham (Nokia-TP-MSW/Helsinki); xcon@ietf.org Cc: > >> Jonathan Rosenberg Subject: RE: [XCON] "Many users in a single > >> operation" Requirements > >>=20 > >>=20 > >> Where is this "XCAP extension" defined in the XCAP documents?! > >>=20 > >> Besides, you can't do in the same way REQ-CP-3: It MAY be possible > >> for the client to batch multiple operations (such as add a user to > >> ACL blocked list, or remove a user from ACL allowed list) into a > >> single request that is processed atomically. > >>=20 > >> Thanks, Orit. > >>=20 > >> -----Original Message----- From: hisham.khartabil@nokia.com > >> [mailto:hisham.khartabil@nokia.com] Sent: Tuesday, February 10, > >> 2004 12:18 AM To: Orit Levin; xcon@ietf.org Subject: RE: [XCON] > >> "Many users in a single operation" Requirements > >>=20 > >> Here is an example of how to add multiple users to an ACL list in a > >> single operation: > >>=20 > >> PUT http://xcap.example.com/services/conferences/users/Alice/confe=20 > >> rence.xml? Conference/ACL/ACL-target-URI HTTP/1.1=20 > >> Content-Type:text/plain > >>=20 > >> >> Access-type=3D"Allowed">sip:bob@example.com=20 > >> >> Access-type=3D"Allowed">sip:alice@example.com=20 > >> >> Access-type=3D"Allowed">sip:bob@domain.com > >>=20 > >>=20 > >> The rest are done in a similar fashion. > >>=20 > >> /Hisham > >>=20 > >>> -----Original Message----- From: xcon-admin@ietf.org > >>> [mailto:xcon-admin@ietf.org]On > >>=20 > >> Behalf Of ext > >>=20 > >>> Orit Levin Sent: 10.February.2004 03:15 To: xcon@ietf.org=20 > >>> Subject: [XCON] "Many users in a single operation" Requirements > >>>=20 > >>>=20 > >>> Hi guys! > >>>=20 > >>> There are many places throughout the CPCP-req document that > >>> identify operations on a "subset of list" as MUST be performed in > >>> a single operation (e.g. G4, G6, H2, and H4). How do you plan to > >>> meet these requirements with "XCAP CPCP"? > >>>=20 > >>> The same question for REQ-CP-3: It MAY be possible for the client > >>> to batch multiple operations (such as add a user to ACL > >>=20 > >> blocked list, or > >>=20 > >>> remove a user from ACL allowed list) into a single request that > >>> is processed atomically. > >>>=20 > >>> Thanks, Orit. > >>>=20 > >>> _______________________________________________ XCON mailing list > >>> XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon > >>>=20 > >>=20 > >=20 >=20 > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Feb 13 03:36:29 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 DAA28467 for ; Fri, 13 Feb 2004 03:36:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArYns-0005CG-3K for simple-archive@odin.ietf.org; Fri, 13 Feb 2004 03:36:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1D8a3MX019966 for simple-archive@odin.ietf.org; Fri, 13 Feb 2004 03:36:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArYnr-0005Bs-DG for simple-web-archive@optimus.ietf.org; Fri, 13 Feb 2004 03:36:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28444 for ; Fri, 13 Feb 2004 03:35:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArYnj-0007es-00 for simple-web-archive@ietf.org; Fri, 13 Feb 2004 03:35:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArYmo-0007Zc-00 for simple-web-archive@ietf.org; Fri, 13 Feb 2004 03:35:00 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArYmI-0007UE-00; Fri, 13 Feb 2004 03:34:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArYlv-0004vk-Mn; Fri, 13 Feb 2004 03:34:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArYlm-0004vN-T7 for simple@optimus.ietf.org; Fri, 13 Feb 2004 03:33:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28328 for ; Fri, 13 Feb 2004 03:33:49 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArYle-0007T4-00 for simple@ietf.org; Fri, 13 Feb 2004 03:33:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArYkj-0007Os-00 for simple@ietf.org; Fri, 13 Feb 2004 03:32:50 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1ArYk5-0007Kb-00 for simple@ietf.org; Fri, 13 Feb 2004 03:32:09 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1D8W4v22175 for ; Fri, 13 Feb 2004 10:32:09 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 13 Feb 2004 10:31:03 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 13 Feb 2004 10:31:05 +0200 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70179774B@esebe019.ntc.nokia.com> Thread-Topic: [XCON] "Many users in a single operation" Requirements Thread-Index: AcPxjlo8gqOFiqTUTOavC5V+B2QiHwAfMcTw To: Cc: , X-OriginalArrivalTime: 13 Feb 2004 08:31:05.0359 (UTC) FILETIME=[B8AFB1F0:01C3F20B] Content-Transfer-Encoding: quoted-printable Subject: [Simple] RE: [XCON] "Many users in a single operation" Requirements Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.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, 13 Feb 2004 10:31:02 +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.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 Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: 12.February.2004 19:31 > To: Khartabil Hisham (Nokia-TP-MSW/Helsinki) > Cc: oritl@microsoft.com; simple@ietf.org > Subject: Re: [XCON] "Many users in a single operation" Requirements >=20 >=20 > Sorry for the delay here... >=20 > Orit is right, and as you point out below, you can in fact only add a > single element/subtree at a time. >=20 > The reason is that, in order to use http out of the box, we=20 > need to keep=20 > its semantics. That means that things like GET(PUT(URI,=20 > body)) =3D=3D body=20 > need to be maintained. If you did a get on the URI below, you would=20 > retrieve the first entry. Indeed, if you did the original PUT=20 > you suggested: >=20 > PUT=20 > http://xcap.example.com/services/conferences/users/Alice/confe > rence.xml? > Conference/ACL/ACL-target-URI HTTP/1.1 > Content-Type:text/plain >=20 > Access-type=3D"Allowed">sip:bob@example.com > Access-type=3D"Allowed">sip:alice@example.com > Access-type=3D"Allowed">sip:bob@domain.com >From why I understand from the current specs, the above example is not = possible since the conent of the PUT contians more than 1 element and = therefore is illegal. >=20 > and there was already an ACL-target-URI in the document, it would be=20 > REPLACED by what is provided in the body. Thats normal http -=20 > if you PUT=20 > to a URI that identifies an existing resource, it gets replaced. >=20 > more inline. >=20 >=20 > hisham.khartabil@nokia.com wrote: >=20 > > [moved to SIMPLE since this is an XCAP issue] > >=20 > > Ok, I see what you mean. XCAP says > >=20 > > The content of the request MUST be a single XML element and > > associated content (including children elements). > >=20 > > I don't know why that is. Isn't it enough that the URI points to a > > single XML element? Perhaps Jonathan can comment on why the > > limitation is in place. >=20 > See above. >=20 > >=20 > > Else, the example I gave has to be modified as follows: > >=20 > > PUT > >=20 > http://xcap.example.com/services/conferences/users/Alice/confe > rence.xml?Conference > > HTTP/1.1 Content-Type:text/plain > >=20 > > > Access-type=3D"Allowed">sip:bob@example.com=20 > > > Access-type=3D"Allowed">sip:alice@example.com=20 > > > Access-type=3D"Allowed">sip:bob@domain.com >=20 > Yes, this would work. Effectively, since you can only=20 > add/replace/delete=20 > a single element at a time, you need to introduce hierarchy=20 > in the XML=20 > *IF* you want this kind of batching operation. I'll note=20 > that, once you=20 > do the PUT above to add the three entries, you can also do a single=20 > DELETE to remove that same three, but if you wanted to delete=20 > two of the=20 > three, then you would need to do two separate transactions. >=20 > We had discussed this particular limitation quite a bit during the=20 > design of xcap, and it was deemed an acceptable limitation.=20 I'm ok with replacing the whole ACL if ACL manipulation is needed. It = satisfies the requirement anyhow that way. > If it is no=20 > longer the case, then we can discuss fixes. [as a chair] I suggest working on those fixes later. /Hisham >=20 > Allowing for deletion of multiple entries at a time is=20 > relatively easy.=20 > Indeed, whether to allow this was an open issue for a time, and we=20 > simplified to say no. If we allow fuller xpath expressions in=20 > the URI,=20 > you can include, in a DELETE, an xpath expression that=20 > selects multiple=20 > elements. Then, the delete would remove everything that is=20 > selected. The=20 > penalty for this is we need to support much more of xpath,=20 > whereas now=20 > the subset is so small, it is fully defined within xcap itself. >=20 > Adding multiple elements could be done the same kind of way -=20 > the HTTP=20 > URI expression would need to be something which (1) selects=20 > nothing when=20 > applied to the current document, (2) selects the contents of the body=20 > once the elements are added to the document. You can do that=20 > by using id=20 > parameters and other tokens that can be placed as attributes=20 > of the xml=20 > element. >=20 > There would still be a limitation that you could not add multiple=20 > elements at differing points of attachment in the tree;=20 > though xpath can=20 > define such selectors, the insertion operation for this=20 > becomes nearly=20 > impossible to perform, I believe. >=20 > Comments? >=20 > Thanks, > Jonathan R. > >=20 > > /Hisham > >=20 > >=20 > >> -----Original Message----- From: ext Orit Levin > >> [mailto:oritl@microsoft.com] Sent: 12.February.2004 18:12 To: > >> Khartabil Hisham (Nokia-TP-MSW/Helsinki); xcon@ietf.org Cc: > >> Jonathan Rosenberg Subject: RE: [XCON] "Many users in a single > >> operation" Requirements > >>=20 > >>=20 > >> Where is this "XCAP extension" defined in the XCAP documents?! > >>=20 > >> Besides, you can't do in the same way REQ-CP-3: It MAY be possible > >> for the client to batch multiple operations (such as add a user to > >> ACL blocked list, or remove a user from ACL allowed list) into a > >> single request that is processed atomically. > >>=20 > >> Thanks, Orit. > >>=20 > >> -----Original Message----- From: hisham.khartabil@nokia.com > >> [mailto:hisham.khartabil@nokia.com] Sent: Tuesday, February 10, > >> 2004 12:18 AM To: Orit Levin; xcon@ietf.org Subject: RE: [XCON] > >> "Many users in a single operation" Requirements > >>=20 > >> Here is an example of how to add multiple users to an ACL list in a > >> single operation: > >>=20 > >> PUT http://xcap.example.com/services/conferences/users/Alice/confe=20 > >> rence.xml? Conference/ACL/ACL-target-URI HTTP/1.1=20 > >> Content-Type:text/plain > >>=20 > >> >> Access-type=3D"Allowed">sip:bob@example.com=20 > >> >> Access-type=3D"Allowed">sip:alice@example.com=20 > >> >> Access-type=3D"Allowed">sip:bob@domain.com > >>=20 > >>=20 > >> The rest are done in a similar fashion. > >>=20 > >> /Hisham > >>=20 > >>> -----Original Message----- From: xcon-admin@ietf.org > >>> [mailto:xcon-admin@ietf.org]On > >>=20 > >> Behalf Of ext > >>=20 > >>> Orit Levin Sent: 10.February.2004 03:15 To: xcon@ietf.org=20 > >>> Subject: [XCON] "Many users in a single operation" Requirements > >>>=20 > >>>=20 > >>> Hi guys! > >>>=20 > >>> There are many places throughout the CPCP-req document that > >>> identify operations on a "subset of list" as MUST be performed in > >>> a single operation (e.g. G4, G6, H2, and H4). How do you plan to > >>> meet these requirements with "XCAP CPCP"? > >>>=20 > >>> The same question for REQ-CP-3: It MAY be possible for the client > >>> to batch multiple operations (such as add a user to ACL > >>=20 > >> blocked list, or > >>=20 > >>> remove a user from ACL allowed list) into a single request that > >>> is processed atomically. > >>>=20 > >>> Thanks, Orit. > >>>=20 > >>> _______________________________________________ XCON mailing list > >>> XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon > >>>=20 > >>=20 > >=20 >=20 > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Feb 13 03:52:49 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29046 for ; Fri, 13 Feb 2004 03:52:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArZ43-0001Kl-00 for simple-archive@ietf.org; Fri, 13 Feb 2004 03:52:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArZ3A-0001Fp-00 for simple-archive@ietf.org; Fri, 13 Feb 2004 03:51:53 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArZ2K-0001B5-00; Fri, 13 Feb 2004 03:51:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArZ2N-0006se-2q; Fri, 13 Feb 2004 03:51:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArZ2C-0006rx-Oo for simple@optimus.ietf.org; Fri, 13 Feb 2004 03:50:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28987 for ; Fri, 13 Feb 2004 03:50:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArZ24-00019s-00 for simple@ietf.org; Fri, 13 Feb 2004 03:50:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArZ19-000166-00 for simple@ietf.org; Fri, 13 Feb 2004 03:49:48 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1ArZ0s-00012L-00 for simple@ietf.org; Fri, 13 Feb 2004 03:49:31 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1D8nXv16975 for ; Fri, 13 Feb 2004 10:49:33 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 13 Feb 2004 10:49:28 +0200 Received: from mgw.research.nokia.com ([172.21.33.76]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 13 Feb 2004 10:49:30 +0200 Received: from xitami.research.nokia.com (xitami.research.nokia.com [172.21.40.110]) by mgw.research.nokia.com (8.9.3/8.9.3) with ESMTP id KAA28966; Fri, 13 Feb 2004 10:49:41 +0200 (EET) Subject: Re: [Simple] XCAP questions From: Jari Urpalainen To: ext Jonathan Rosenberg Cc: simple@ietf.org In-Reply-To: <402BE9D3.7090408@dynamicsoft.com> References: <4018DECF.7040108@nokia.com> <402BE9D3.7090408@dynamicsoft.com> Content-Type: text/plain Message-Id: <1076662170.7784.80.camel@xitami.research.nokia.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Feb 2004 08:49:30.0849 (UTC) FILETIME=[4B9C1510:01C3F20E] 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, 13 Feb 2004 10:49:30 +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=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Thanks for your answers, comments inline. On Thu, 2004-02-12 at 23:02, ext Jonathan Rosenberg wrote: > One way I would suggest for this is to define an application usage which > is the "directory" of documents for a specific user. This application > usage would specify a single well known place where the document would > live. The end user themselves would not need to modify it; the server > could set it when the user manages their own documents. This would then > be read-only, and visible to either a user or more importantly, to a PE. > > I think this is more or less what Markus has proposed as well. The > question is, where does such a definition occur: > > 1. base xcap spec > 2. as part of each application usage > 3. a special "directory" application usage > > I prefer (3); we could define this once, and the "directory" would > contain information on the documents for a user across all application > usages. > Option 3 sounds reasonable although it's a bit more complex to implement than a simple directory list. > > > > 2. XCAP ETags > > In order to ease the synchronizing within resources between client and > > server the base XCAP draft could specify the secure hash method e.g. > > SHA-1 or whatever that is used to calculate the ETag. This is already > > proposed in xcap-package but IMHO could be in the base spec. > > I don't follow. The etag is purely a server computed value. Generally, > there is no need to specify how it is computed. Why does it matter how > its computed? > Sorry for not being too clear on this. Actually the problem i see is that e.g. with xcap resource-lists the server should add empty list uris. So what's the most reasonable way for the client to detect that the server has added them ? The first option might be that the client "knows" this resource-list behaviour and it queries after some put operation all the empty uris. This may lead to quite many round-trips and what's more, this is very au related i.e. not very generic. The second option could be that the client subscribes (xcap-package) to this document and gets those add-ons made by server from the notifications. IMHO, this sounds a bit too heavy for this sort of simple operation... The third option could be that when doing put transaction the server would reply within the reply payload all the stuff it has added. The response should have it's own mime-type. I am perfectly aware that it is all but "standard" http put behaviour but it would be efficient. > > > > 3. XCAP attributes > > When updating/querying attributes is it necessary to include attribute > > name in payload as attribute name is already provided in XPATH-query ? > > > > e.g. you could get /resource-lists/list[@name="friends"]/@uri > > so you already know that you receive response for attribute uri. IMHO > > when putting/getting attributes, payload could include only attribute > > value. > > That can be true as long as the URI can only identify an attribute by > name. I can change this as long as we stick to that constraint. > fine. > > > > > 4. XCAP namespace declarations > > As namespace handling resemble "standard" XML attributes is it also > > allowed to change namespace declarations with similar semantics ? > > Great question. The answer is no. The reason is say that is that in > xpath, namespace declarations are treated differently. If you want to > get access to the namespaces of an element, you have to use the explicit > namespace axis. > > I want to make sure that our URI addressing conventions do not violate > or contradict xpath, and so I think they need to be consistent. I will > clarify in the draft that the selectors do not apply to namespaces, > comments or text content. If we want to be able to access and modify > those, we need to expand the scope beyond where we are now. I would > prefer not to do that. > I fully agree that the attribute selectors should exclude namespaces. However, adding comments would be sometimes nice but it can certainly be left for future improvements. BR, Jari _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Feb 13 03:53:22 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 DAA29087 for ; Fri, 13 Feb 2004 03:53:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArZ4D-00070W-Mp for simple-archive@odin.ietf.org; Fri, 13 Feb 2004 03:52:57 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1D8qv1D026929 for simple-archive@odin.ietf.org; Fri, 13 Feb 2004 03:52:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArZ4D-00070G-22 for simple-web-archive@optimus.ietf.org; Fri, 13 Feb 2004 03:52:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29064 for ; Fri, 13 Feb 2004 03:52:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArZ44-0001Ky-00 for simple-web-archive@ietf.org; Fri, 13 Feb 2004 03:52:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArZ3B-0001Fw-00 for simple-web-archive@ietf.org; Fri, 13 Feb 2004 03:51:54 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArZ2K-0001B5-00; Fri, 13 Feb 2004 03:51:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArZ2N-0006se-2q; Fri, 13 Feb 2004 03:51:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArZ2C-0006rx-Oo for simple@optimus.ietf.org; Fri, 13 Feb 2004 03:50:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28987 for ; Fri, 13 Feb 2004 03:50:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArZ24-00019s-00 for simple@ietf.org; Fri, 13 Feb 2004 03:50:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArZ19-000166-00 for simple@ietf.org; Fri, 13 Feb 2004 03:49:48 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1ArZ0s-00012L-00 for simple@ietf.org; Fri, 13 Feb 2004 03:49:31 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1D8nXv16975 for ; Fri, 13 Feb 2004 10:49:33 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 13 Feb 2004 10:49:28 +0200 Received: from mgw.research.nokia.com ([172.21.33.76]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 13 Feb 2004 10:49:30 +0200 Received: from xitami.research.nokia.com (xitami.research.nokia.com [172.21.40.110]) by mgw.research.nokia.com (8.9.3/8.9.3) with ESMTP id KAA28966; Fri, 13 Feb 2004 10:49:41 +0200 (EET) Subject: Re: [Simple] XCAP questions From: Jari Urpalainen To: ext Jonathan Rosenberg Cc: simple@ietf.org In-Reply-To: <402BE9D3.7090408@dynamicsoft.com> References: <4018DECF.7040108@nokia.com> <402BE9D3.7090408@dynamicsoft.com> Content-Type: text/plain Message-Id: <1076662170.7784.80.camel@xitami.research.nokia.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Feb 2004 08:49:30.0849 (UTC) FILETIME=[4B9C1510:01C3F20E] 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, 13 Feb 2004 10:49:30 +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=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Thanks for your answers, comments inline. On Thu, 2004-02-12 at 23:02, ext Jonathan Rosenberg wrote: > One way I would suggest for this is to define an application usage which > is the "directory" of documents for a specific user. This application > usage would specify a single well known place where the document would > live. The end user themselves would not need to modify it; the server > could set it when the user manages their own documents. This would then > be read-only, and visible to either a user or more importantly, to a PE. > > I think this is more or less what Markus has proposed as well. The > question is, where does such a definition occur: > > 1. base xcap spec > 2. as part of each application usage > 3. a special "directory" application usage > > I prefer (3); we could define this once, and the "directory" would > contain information on the documents for a user across all application > usages. > Option 3 sounds reasonable although it's a bit more complex to implement than a simple directory list. > > > > 2. XCAP ETags > > In order to ease the synchronizing within resources between client and > > server the base XCAP draft could specify the secure hash method e.g. > > SHA-1 or whatever that is used to calculate the ETag. This is already > > proposed in xcap-package but IMHO could be in the base spec. > > I don't follow. The etag is purely a server computed value. Generally, > there is no need to specify how it is computed. Why does it matter how > its computed? > Sorry for not being too clear on this. Actually the problem i see is that e.g. with xcap resource-lists the server should add empty list uris. So what's the most reasonable way for the client to detect that the server has added them ? The first option might be that the client "knows" this resource-list behaviour and it queries after some put operation all the empty uris. This may lead to quite many round-trips and what's more, this is very au related i.e. not very generic. The second option could be that the client subscribes (xcap-package) to this document and gets those add-ons made by server from the notifications. IMHO, this sounds a bit too heavy for this sort of simple operation... The third option could be that when doing put transaction the server would reply within the reply payload all the stuff it has added. The response should have it's own mime-type. I am perfectly aware that it is all but "standard" http put behaviour but it would be efficient. > > > > 3. XCAP attributes > > When updating/querying attributes is it necessary to include attribute > > name in payload as attribute name is already provided in XPATH-query ? > > > > e.g. you could get /resource-lists/list[@name="friends"]/@uri > > so you already know that you receive response for attribute uri. IMHO > > when putting/getting attributes, payload could include only attribute > > value. > > That can be true as long as the URI can only identify an attribute by > name. I can change this as long as we stick to that constraint. > fine. > > > > > 4. XCAP namespace declarations > > As namespace handling resemble "standard" XML attributes is it also > > allowed to change namespace declarations with similar semantics ? > > Great question. The answer is no. The reason is say that is that in > xpath, namespace declarations are treated differently. If you want to > get access to the namespaces of an element, you have to use the explicit > namespace axis. > > I want to make sure that our URI addressing conventions do not violate > or contradict xpath, and so I think they need to be consistent. I will > clarify in the draft that the selectors do not apply to namespaces, > comments or text content. If we want to be able to access and modify > those, we need to expand the scope beyond where we are now. I would > prefer not to do that. > I fully agree that the attribute selectors should exclude namespaces. However, adding comments would be sometimes nice but it can certainly be left for future improvements. BR, Jari _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Feb 13 06:45:53 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05726 for ; Fri, 13 Feb 2004 06:45:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArblX-0000R5-00 for simple-archive@ietf.org; Fri, 13 Feb 2004 06:45:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Arbkd-0000Lu-00 for simple-archive@ietf.org; Fri, 13 Feb 2004 06:44:56 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Arbjf-0000G4-00; Fri, 13 Feb 2004 06:43:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arbjl-0003yx-CL; Fri, 13 Feb 2004 06:44:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arbji-0003yk-S1 for simple@optimus.ietf.org; Fri, 13 Feb 2004 06:43:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05623 for ; Fri, 13 Feb 2004 06:43:50 -0500 (EST) From: Markus.Isomaki@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArbjZ-0000F4-00 for simple@ietf.org; Fri, 13 Feb 2004 06:43:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Arbic-00009Z-00 for simple@ietf.org; Fri, 13 Feb 2004 06:42:51 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1Arbhk-00004s-00 for simple@ietf.org; Fri, 13 Feb 2004 06:41:56 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1DBfw317557 for ; Fri, 13 Feb 2004 13:41:58 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 13 Feb 2004 13:37:53 +0200 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 13 Feb 2004 13:37:54 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] XCAP questions Message-ID: Thread-Topic: [Simple] XCAP questions Thread-Index: AcPxq/fDh4b+VrJrTGC9aARe1eLbJQAeIVxQ To: , Cc: X-OriginalArrivalTime: 13 Feb 2004 11:37:54.0845 (UTC) FILETIME=[D20F84D0:01C3F225] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 13 Feb 2004 13:37:53 +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.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Hi, Regarding the XCAP directory application usage: I also like approach 3, as this would make things easiest for the = client. A follow-up issue to this: Would it be possible to include also = the Etags (or similar version identifiers) for each resource listed in = that directory file? In this way the user could only be subscribed to = the changes in the directory file (via XCAP-change event), and still = learn about all the changes that have occured in any of the resources = that he/she owns.=20 If we agree that this is the way, I think specifying this new usage = would be straightforward, and I can volunteer to provide the first = version for it after IETF 59. Markus=20 > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > ext Jonathan Rosenberg > Sent: 12 February, 2004 23:02 > To: Urpalainen Jari (Nokia-NRC/Helsinki) > Cc: simple@ietf.org > Subject: Re: [Simple] XCAP questions >=20 >=20 > Sorry for the delay in responding. Thanks so much for your=20 > comments and=20 > questions. Answers inline. >=20 > Jari Urpalainen wrote: >=20 > > Hi ! > >=20 > > I have been developing a reference implementation for XCAP server=20 > > (standalone and an Apache module). There are some=20 > open/unclear issues=20 > > (to me at least), so here's the list of questions. > >=20 > > 1. XCAP directory list > > In XCAP presence auth draft chapter 4.4, there's a=20 > requirement to get=20 > > all documents from the server. However, in the base XCAP=20 > draft it is=20 > > unspecified how the server should send this directory list. While=20 > > http-servers can/will provide this information in many=20 > ways, IMO the=20 > > base XCAP draft should specify this format (xml?).=20 > Furhermore, it would=20 > > be nice if ETags were included in the response in order to help to=20 > > synchonize documents between the client and the server. >=20 > In the model I had in my head, the presence server itself=20 > didnt use xcap=20 > to fetch the documents; that interface was something proprietary.=20 > However, if xcap is being used there, you are right that there would=20 > need to be a standardized way to obtain the list. >=20 > One way I would suggest for this is to define an application=20 > usage which=20 > is the "directory" of documents for a specific user. This application=20 > usage would specify a single well known place where the=20 > document would=20 > live. The end user themselves would not need to modify it; the server=20 > could set it when the user manages their own documents. This=20 > would then=20 > be read-only, and visible to either a user or more=20 > importantly, to a PE. >=20 > I think this is more or less what Markus has proposed as well. The=20 > question is, where does such a definition occur: >=20 > 1. base xcap spec > 2. as part of each application usage > 3. a special "directory" application usage >=20 > I prefer (3); we could define this once, and the "directory" would=20 > contain information on the documents for a user across all=20 > application=20 > usages. >=20 >=20 >=20 > >=20 > > 2. XCAP ETags > > In order to ease the synchronizing within resources between=20 > client and=20 > > server the base XCAP draft could specify the secure hash=20 > method e.g.=20 > > SHA-1 or whatever that is used to calculate the ETag. This=20 > is already=20 > > proposed in xcap-package but IMHO could be in the base spec. >=20 > I don't follow. The etag is purely a server computed value.=20 > Generally,=20 > there is no need to specify how it is computed. Why does it=20 > matter how=20 > its computed? >=20 > >=20 > > 3. XCAP attributes > > When updating/querying attributes is it necessary to=20 > include attribute=20 > > name in payload as attribute name is already provided in=20 > XPATH-query ? > >=20 > > e.g. you could get /resource-lists/list[@name=3D"friends"]/@uri > > so you already know that you receive response for attribute=20 > uri. IMHO=20 > > when putting/getting attributes, payload could include only=20 > attribute=20 > > value. >=20 > That can be true as long as the URI can only identify an attribute by=20 > name. I can change this as long as we stick to that constraint. >=20 >=20 > >=20 > > 4. XCAP namespace declarations > > As namespace handling resemble "standard" XML attributes is it also=20 > > allowed to change namespace declarations with similar semantics ? >=20 > Great question. The answer is no. The reason is say that is that in=20 > xpath, namespace declarations are treated differently. If you want to=20 > get access to the namespaces of an element, you have to use=20 > the explicit=20 > namespace axis. >=20 > I want to make sure that our URI addressing conventions do=20 > not violate=20 > or contradict xpath, and so I think they need to be=20 > consistent. I will=20 > clarify in the draft that the selectors do not apply to namespaces,=20 > comments or text content. If we want to be able to access and modify=20 > those, we need to expand the scope beyond where we are now. I would=20 > prefer not to do that. >=20 > -Jonathan R. > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Feb 13 06:46:24 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 GAA05772 for ; Fri, 13 Feb 2004 06:46:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arbli-00046n-6K for simple-archive@odin.ietf.org; Fri, 13 Feb 2004 06:46:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DBk2X9015789 for simple-archive@odin.ietf.org; Fri, 13 Feb 2004 06:46:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arbli-00046a-2R for simple-web-archive@optimus.ietf.org; Fri, 13 Feb 2004 06:46:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05741 for ; Fri, 13 Feb 2004 06:45:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArblY-0000R9-00 for simple-web-archive@ietf.org; Fri, 13 Feb 2004 06:45:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Arbke-0000M1-00 for simple-web-archive@ietf.org; Fri, 13 Feb 2004 06:44:58 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Arbjf-0000G4-00; Fri, 13 Feb 2004 06:43:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arbjl-0003yx-CL; Fri, 13 Feb 2004 06:44:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arbji-0003yk-S1 for simple@optimus.ietf.org; Fri, 13 Feb 2004 06:43:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05623 for ; Fri, 13 Feb 2004 06:43:50 -0500 (EST) From: Markus.Isomaki@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArbjZ-0000F4-00 for simple@ietf.org; Fri, 13 Feb 2004 06:43:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Arbic-00009Z-00 for simple@ietf.org; Fri, 13 Feb 2004 06:42:51 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1Arbhk-00004s-00 for simple@ietf.org; Fri, 13 Feb 2004 06:41:56 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1DBfw317557 for ; Fri, 13 Feb 2004 13:41:58 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 13 Feb 2004 13:37:53 +0200 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 13 Feb 2004 13:37:54 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] XCAP questions Message-ID: Thread-Topic: [Simple] XCAP questions Thread-Index: AcPxq/fDh4b+VrJrTGC9aARe1eLbJQAeIVxQ To: , Cc: X-OriginalArrivalTime: 13 Feb 2004 11:37:54.0845 (UTC) FILETIME=[D20F84D0:01C3F225] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 13 Feb 2004 13:37:53 +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.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, Regarding the XCAP directory application usage: I also like approach 3, as this would make things easiest for the = client. A follow-up issue to this: Would it be possible to include also = the Etags (or similar version identifiers) for each resource listed in = that directory file? In this way the user could only be subscribed to = the changes in the directory file (via XCAP-change event), and still = learn about all the changes that have occured in any of the resources = that he/she owns.=20 If we agree that this is the way, I think specifying this new usage = would be straightforward, and I can volunteer to provide the first = version for it after IETF 59. Markus=20 > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > ext Jonathan Rosenberg > Sent: 12 February, 2004 23:02 > To: Urpalainen Jari (Nokia-NRC/Helsinki) > Cc: simple@ietf.org > Subject: Re: [Simple] XCAP questions >=20 >=20 > Sorry for the delay in responding. Thanks so much for your=20 > comments and=20 > questions. Answers inline. >=20 > Jari Urpalainen wrote: >=20 > > Hi ! > >=20 > > I have been developing a reference implementation for XCAP server=20 > > (standalone and an Apache module). There are some=20 > open/unclear issues=20 > > (to me at least), so here's the list of questions. > >=20 > > 1. XCAP directory list > > In XCAP presence auth draft chapter 4.4, there's a=20 > requirement to get=20 > > all documents from the server. However, in the base XCAP=20 > draft it is=20 > > unspecified how the server should send this directory list. While=20 > > http-servers can/will provide this information in many=20 > ways, IMO the=20 > > base XCAP draft should specify this format (xml?).=20 > Furhermore, it would=20 > > be nice if ETags were included in the response in order to help to=20 > > synchonize documents between the client and the server. >=20 > In the model I had in my head, the presence server itself=20 > didnt use xcap=20 > to fetch the documents; that interface was something proprietary.=20 > However, if xcap is being used there, you are right that there would=20 > need to be a standardized way to obtain the list. >=20 > One way I would suggest for this is to define an application=20 > usage which=20 > is the "directory" of documents for a specific user. This application=20 > usage would specify a single well known place where the=20 > document would=20 > live. The end user themselves would not need to modify it; the server=20 > could set it when the user manages their own documents. This=20 > would then=20 > be read-only, and visible to either a user or more=20 > importantly, to a PE. >=20 > I think this is more or less what Markus has proposed as well. The=20 > question is, where does such a definition occur: >=20 > 1. base xcap spec > 2. as part of each application usage > 3. a special "directory" application usage >=20 > I prefer (3); we could define this once, and the "directory" would=20 > contain information on the documents for a user across all=20 > application=20 > usages. >=20 >=20 >=20 > >=20 > > 2. XCAP ETags > > In order to ease the synchronizing within resources between=20 > client and=20 > > server the base XCAP draft could specify the secure hash=20 > method e.g.=20 > > SHA-1 or whatever that is used to calculate the ETag. This=20 > is already=20 > > proposed in xcap-package but IMHO could be in the base spec. >=20 > I don't follow. The etag is purely a server computed value.=20 > Generally,=20 > there is no need to specify how it is computed. Why does it=20 > matter how=20 > its computed? >=20 > >=20 > > 3. XCAP attributes > > When updating/querying attributes is it necessary to=20 > include attribute=20 > > name in payload as attribute name is already provided in=20 > XPATH-query ? > >=20 > > e.g. you could get /resource-lists/list[@name=3D"friends"]/@uri > > so you already know that you receive response for attribute=20 > uri. IMHO=20 > > when putting/getting attributes, payload could include only=20 > attribute=20 > > value. >=20 > That can be true as long as the URI can only identify an attribute by=20 > name. I can change this as long as we stick to that constraint. >=20 >=20 > >=20 > > 4. XCAP namespace declarations > > As namespace handling resemble "standard" XML attributes is it also=20 > > allowed to change namespace declarations with similar semantics ? >=20 > Great question. The answer is no. The reason is say that is that in=20 > xpath, namespace declarations are treated differently. If you want to=20 > get access to the namespaces of an element, you have to use=20 > the explicit=20 > namespace axis. >=20 > I want to make sure that our URI addressing conventions do=20 > not violate=20 > or contradict xpath, and so I think they need to be=20 > consistent. I will=20 > clarify in the draft that the selectors do not apply to namespaces,=20 > comments or text content. If we want to be able to access and modify=20 > those, we need to expand the scope beyond where we are now. I would=20 > prefer not to do that. >=20 > -Jonathan R. > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Feb 13 06:52:53 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06018 for ; Fri, 13 Feb 2004 06:52:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArbsJ-0000yq-00 for simple-archive@ietf.org; Fri, 13 Feb 2004 06:52:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArbrN-0000uR-00 for simple-archive@ietf.org; Fri, 13 Feb 2004 06:51:54 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArbqT-0000q1-00; Fri, 13 Feb 2004 06:50:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArbqY-0004E8-3X; Fri, 13 Feb 2004 06:51:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arbpb-0004Cw-M4 for simple@optimus.ietf.org; Fri, 13 Feb 2004 06:50:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05905 for ; Fri, 13 Feb 2004 06:49:55 -0500 (EST) From: Markus.Isomaki@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArbpR-0000kP-00 for simple@ietf.org; Fri, 13 Feb 2004 06:49:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArboV-0000g9-00 for simple@ietf.org; Fri, 13 Feb 2004 06:48:57 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1Arbo5-0000cA-00 for simple@ietf.org; Fri, 13 Feb 2004 06:48:29 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1DBmW327300 for ; Fri, 13 Feb 2004 13:48:32 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 13 Feb 2004 13:48:31 +0200 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 13 Feb 2004 13:48:24 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Re: [XCON] "Many users in a single operation" Requirements Message-ID: Thread-Topic: [Simple] Re: [XCON] "Many users in a single operation" Requirements Thread-Index: AcPxjxBlcLiUmB9dTYOgJsS6h0U7SgAluQZg To: , Cc: , X-OriginalArrivalTime: 13 Feb 2004 11:48:24.0288 (UTC) FILETIME=[493CE600:01C3F227] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 13 Feb 2004 13:47:33 +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.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Hi, Jonathan Rosenberg wrote: > We had discussed this particular limitation quite a bit during the=20 > design of xcap, and it was deemed an acceptable limitation.=20 > If it is no=20 > longer the case, then we can discuss fixes. I think this all depends on what kind of usages we envision for XCAP. = The requirement for doing multiple operations atomically was also = originally included in the data manipulation reqs that were used as = motivation for XCAP. However, it seemed that doing the actual = applications that were in SIMPLE charter (mainly presence related) did = not really need this capability.=20 My opinion is that it should be added to XCAP if and only if: 1. It is mandatory for conference control (CPCP) according to the = concensus in XCON WG 2. XCON WG chooses XCAP for CPCP's baseline given that XCAP can meet = this requirement 3. XCAP would not be complicated or delayed considerably because of this So far I haven't seen clarification on either 1. or 2. in XCON, but I = think it would be a good target for the Korea meeting. =20 Markus > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > ext Jonathan Rosenberg > Sent: 12 February, 2004 19:31 > To: Khartabil Hisham (Nokia-TP-MSW/Helsinki) > Cc: oritl@microsoft.com; simple@ietf.org > Subject: [Simple] Re: [XCON] "Many users in a single operation" > Requirements >=20 >=20 > Sorry for the delay here... >=20 > Orit is right, and as you point out below, you can in fact only add a > single element/subtree at a time. >=20 > The reason is that, in order to use http out of the box, we=20 > need to keep=20 > its semantics. That means that things like GET(PUT(URI,=20 > body)) =3D=3D body=20 > need to be maintained. If you did a get on the URI below, you would=20 > retrieve the first entry. Indeed, if you did the original PUT=20 > you suggested: >=20 > PUT=20 > http://xcap.example.com/services/conferences/users/Alice/confe > rence.xml? > Conference/ACL/ACL-target-URI HTTP/1.1 > Content-Type:text/plain >=20 > Access-type=3D"Allowed">sip:bob@example.com > Access-type=3D"Allowed">sip:alice@example.com > Access-type=3D"Allowed">sip:bob@domain.com >=20 > and there was already an ACL-target-URI in the document, it would be=20 > REPLACED by what is provided in the body. Thats normal http -=20 > if you PUT=20 > to a URI that identifies an existing resource, it gets replaced. >=20 > more inline. >=20 >=20 > hisham.khartabil@nokia.com wrote: >=20 > > [moved to SIMPLE since this is an XCAP issue] > >=20 > > Ok, I see what you mean. XCAP says > >=20 > > The content of the request MUST be a single XML element and > > associated content (including children elements). > >=20 > > I don't know why that is. Isn't it enough that the URI points to a > > single XML element? Perhaps Jonathan can comment on why the > > limitation is in place. >=20 > See above. >=20 > >=20 > > Else, the example I gave has to be modified as follows: > >=20 > > PUT > >=20 > http://xcap.example.com/services/conferences/users/Alice/confe > rence.xml?Conference > > HTTP/1.1 Content-Type:text/plain > >=20 > > > Access-type=3D"Allowed">sip:bob@example.com=20 > > > Access-type=3D"Allowed">sip:alice@example.com=20 > > > Access-type=3D"Allowed">sip:bob@domain.com >=20 > Yes, this would work. Effectively, since you can only=20 > add/replace/delete=20 > a single element at a time, you need to introduce hierarchy=20 > in the XML=20 > *IF* you want this kind of batching operation. I'll note=20 > that, once you=20 > do the PUT above to add the three entries, you can also do a single=20 > DELETE to remove that same three, but if you wanted to delete=20 > two of the=20 > three, then you would need to do two separate transactions. >=20 > We had discussed this particular limitation quite a bit during the=20 > design of xcap, and it was deemed an acceptable limitation.=20 > If it is no=20 > longer the case, then we can discuss fixes. >=20 > Allowing for deletion of multiple entries at a time is=20 > relatively easy.=20 > Indeed, whether to allow this was an open issue for a time, and we=20 > simplified to say no. If we allow fuller xpath expressions in=20 > the URI,=20 > you can include, in a DELETE, an xpath expression that=20 > selects multiple=20 > elements. Then, the delete would remove everything that is=20 > selected. The=20 > penalty for this is we need to support much more of xpath,=20 > whereas now=20 > the subset is so small, it is fully defined within xcap itself. >=20 > Adding multiple elements could be done the same kind of way -=20 > the HTTP=20 > URI expression would need to be something which (1) selects=20 > nothing when=20 > applied to the current document, (2) selects the contents of the body=20 > once the elements are added to the document. You can do that=20 > by using id=20 > parameters and other tokens that can be placed as attributes=20 > of the xml=20 > element. >=20 > There would still be a limitation that you could not add multiple=20 > elements at differing points of attachment in the tree;=20 > though xpath can=20 > define such selectors, the insertion operation for this=20 > becomes nearly=20 > impossible to perform, I believe. >=20 > Comments? >=20 > Thanks, > Jonathan R. > >=20 > > /Hisham > >=20 > >=20 > >> -----Original Message----- From: ext Orit Levin > >> [mailto:oritl@microsoft.com] Sent: 12.February.2004 18:12 To: > >> Khartabil Hisham (Nokia-TP-MSW/Helsinki); xcon@ietf.org Cc: > >> Jonathan Rosenberg Subject: RE: [XCON] "Many users in a single > >> operation" Requirements > >>=20 > >>=20 > >> Where is this "XCAP extension" defined in the XCAP documents?! > >>=20 > >> Besides, you can't do in the same way REQ-CP-3: It MAY be possible > >> for the client to batch multiple operations (such as add a user to > >> ACL blocked list, or remove a user from ACL allowed list) into a > >> single request that is processed atomically. > >>=20 > >> Thanks, Orit. > >>=20 > >> -----Original Message----- From: hisham.khartabil@nokia.com > >> [mailto:hisham.khartabil@nokia.com] Sent: Tuesday, February 10, > >> 2004 12:18 AM To: Orit Levin; xcon@ietf.org Subject: RE: [XCON] > >> "Many users in a single operation" Requirements > >>=20 > >> Here is an example of how to add multiple users to an ACL list in a > >> single operation: > >>=20 > >> PUT http://xcap.example.com/services/conferences/users/Alice/confe=20 > >> rence.xml? Conference/ACL/ACL-target-URI HTTP/1.1=20 > >> Content-Type:text/plain > >>=20 > >> >> Access-type=3D"Allowed">sip:bob@example.com=20 > >> >> Access-type=3D"Allowed">sip:alice@example.com=20 > >> >> Access-type=3D"Allowed">sip:bob@domain.com > >>=20 > >>=20 > >> The rest are done in a similar fashion. > >>=20 > >> /Hisham > >>=20 > >>> -----Original Message----- From: xcon-admin@ietf.org > >>> [mailto:xcon-admin@ietf.org]On > >>=20 > >> Behalf Of ext > >>=20 > >>> Orit Levin Sent: 10.February.2004 03:15 To: xcon@ietf.org=20 > >>> Subject: [XCON] "Many users in a single operation" Requirements > >>>=20 > >>>=20 > >>> Hi guys! > >>>=20 > >>> There are many places throughout the CPCP-req document that > >>> identify operations on a "subset of list" as MUST be performed in > >>> a single operation (e.g. G4, G6, H2, and H4). How do you plan to > >>> meet these requirements with "XCAP CPCP"? > >>>=20 > >>> The same question for REQ-CP-3: It MAY be possible for the client > >>> to batch multiple operations (such as add a user to ACL > >>=20 > >> blocked list, or > >>=20 > >>> remove a user from ACL allowed list) into a single request that > >>> is processed atomically. > >>>=20 > >>> Thanks, Orit. > >>>=20 > >>> _______________________________________________ XCON mailing list > >>> XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon > >>>=20 > >>=20 > >=20 >=20 > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Feb 13 06:53:25 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 GAA06049 for ; Fri, 13 Feb 2004 06:53:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArbsV-0004Lz-8Q for simple-archive@odin.ietf.org; Fri, 13 Feb 2004 06:53:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DBr3mE016723 for simple-archive@odin.ietf.org; Fri, 13 Feb 2004 06:53:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArbsU-0004LY-RB for simple-web-archive@optimus.ietf.org; Fri, 13 Feb 2004 06:53:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06036 for ; Fri, 13 Feb 2004 06:52:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArbsK-0000yv-00 for simple-web-archive@ietf.org; Fri, 13 Feb 2004 06:52:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArbrO-0000uY-00 for simple-web-archive@ietf.org; Fri, 13 Feb 2004 06:51:55 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArbqT-0000q1-00; Fri, 13 Feb 2004 06:50:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArbqY-0004E8-3X; Fri, 13 Feb 2004 06:51:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arbpb-0004Cw-M4 for simple@optimus.ietf.org; Fri, 13 Feb 2004 06:50:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05905 for ; Fri, 13 Feb 2004 06:49:55 -0500 (EST) From: Markus.Isomaki@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArbpR-0000kP-00 for simple@ietf.org; Fri, 13 Feb 2004 06:49:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArboV-0000g9-00 for simple@ietf.org; Fri, 13 Feb 2004 06:48:57 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1Arbo5-0000cA-00 for simple@ietf.org; Fri, 13 Feb 2004 06:48:29 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1DBmW327300 for ; Fri, 13 Feb 2004 13:48:32 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 13 Feb 2004 13:48:31 +0200 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 13 Feb 2004 13:48:24 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Re: [XCON] "Many users in a single operation" Requirements Message-ID: Thread-Topic: [Simple] Re: [XCON] "Many users in a single operation" Requirements Thread-Index: AcPxjxBlcLiUmB9dTYOgJsS6h0U7SgAluQZg To: , Cc: , X-OriginalArrivalTime: 13 Feb 2004 11:48:24.0288 (UTC) FILETIME=[493CE600:01C3F227] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 13 Feb 2004 13:47:33 +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.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, Jonathan Rosenberg wrote: > We had discussed this particular limitation quite a bit during the=20 > design of xcap, and it was deemed an acceptable limitation.=20 > If it is no=20 > longer the case, then we can discuss fixes. I think this all depends on what kind of usages we envision for XCAP. = The requirement for doing multiple operations atomically was also = originally included in the data manipulation reqs that were used as = motivation for XCAP. However, it seemed that doing the actual = applications that were in SIMPLE charter (mainly presence related) did = not really need this capability.=20 My opinion is that it should be added to XCAP if and only if: 1. It is mandatory for conference control (CPCP) according to the = concensus in XCON WG 2. XCON WG chooses XCAP for CPCP's baseline given that XCAP can meet = this requirement 3. XCAP would not be complicated or delayed considerably because of this So far I haven't seen clarification on either 1. or 2. in XCON, but I = think it would be a good target for the Korea meeting. =20 Markus > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > ext Jonathan Rosenberg > Sent: 12 February, 2004 19:31 > To: Khartabil Hisham (Nokia-TP-MSW/Helsinki) > Cc: oritl@microsoft.com; simple@ietf.org > Subject: [Simple] Re: [XCON] "Many users in a single operation" > Requirements >=20 >=20 > Sorry for the delay here... >=20 > Orit is right, and as you point out below, you can in fact only add a > single element/subtree at a time. >=20 > The reason is that, in order to use http out of the box, we=20 > need to keep=20 > its semantics. That means that things like GET(PUT(URI,=20 > body)) =3D=3D body=20 > need to be maintained. If you did a get on the URI below, you would=20 > retrieve the first entry. Indeed, if you did the original PUT=20 > you suggested: >=20 > PUT=20 > http://xcap.example.com/services/conferences/users/Alice/confe > rence.xml? > Conference/ACL/ACL-target-URI HTTP/1.1 > Content-Type:text/plain >=20 > Access-type=3D"Allowed">sip:bob@example.com > Access-type=3D"Allowed">sip:alice@example.com > Access-type=3D"Allowed">sip:bob@domain.com >=20 > and there was already an ACL-target-URI in the document, it would be=20 > REPLACED by what is provided in the body. Thats normal http -=20 > if you PUT=20 > to a URI that identifies an existing resource, it gets replaced. >=20 > more inline. >=20 >=20 > hisham.khartabil@nokia.com wrote: >=20 > > [moved to SIMPLE since this is an XCAP issue] > >=20 > > Ok, I see what you mean. XCAP says > >=20 > > The content of the request MUST be a single XML element and > > associated content (including children elements). > >=20 > > I don't know why that is. Isn't it enough that the URI points to a > > single XML element? Perhaps Jonathan can comment on why the > > limitation is in place. >=20 > See above. >=20 > >=20 > > Else, the example I gave has to be modified as follows: > >=20 > > PUT > >=20 > http://xcap.example.com/services/conferences/users/Alice/confe > rence.xml?Conference > > HTTP/1.1 Content-Type:text/plain > >=20 > > > Access-type=3D"Allowed">sip:bob@example.com=20 > > > Access-type=3D"Allowed">sip:alice@example.com=20 > > > Access-type=3D"Allowed">sip:bob@domain.com >=20 > Yes, this would work. Effectively, since you can only=20 > add/replace/delete=20 > a single element at a time, you need to introduce hierarchy=20 > in the XML=20 > *IF* you want this kind of batching operation. I'll note=20 > that, once you=20 > do the PUT above to add the three entries, you can also do a single=20 > DELETE to remove that same three, but if you wanted to delete=20 > two of the=20 > three, then you would need to do two separate transactions. >=20 > We had discussed this particular limitation quite a bit during the=20 > design of xcap, and it was deemed an acceptable limitation.=20 > If it is no=20 > longer the case, then we can discuss fixes. >=20 > Allowing for deletion of multiple entries at a time is=20 > relatively easy.=20 > Indeed, whether to allow this was an open issue for a time, and we=20 > simplified to say no. If we allow fuller xpath expressions in=20 > the URI,=20 > you can include, in a DELETE, an xpath expression that=20 > selects multiple=20 > elements. Then, the delete would remove everything that is=20 > selected. The=20 > penalty for this is we need to support much more of xpath,=20 > whereas now=20 > the subset is so small, it is fully defined within xcap itself. >=20 > Adding multiple elements could be done the same kind of way -=20 > the HTTP=20 > URI expression would need to be something which (1) selects=20 > nothing when=20 > applied to the current document, (2) selects the contents of the body=20 > once the elements are added to the document. You can do that=20 > by using id=20 > parameters and other tokens that can be placed as attributes=20 > of the xml=20 > element. >=20 > There would still be a limitation that you could not add multiple=20 > elements at differing points of attachment in the tree;=20 > though xpath can=20 > define such selectors, the insertion operation for this=20 > becomes nearly=20 > impossible to perform, I believe. >=20 > Comments? >=20 > Thanks, > Jonathan R. > >=20 > > /Hisham > >=20 > >=20 > >> -----Original Message----- From: ext Orit Levin > >> [mailto:oritl@microsoft.com] Sent: 12.February.2004 18:12 To: > >> Khartabil Hisham (Nokia-TP-MSW/Helsinki); xcon@ietf.org Cc: > >> Jonathan Rosenberg Subject: RE: [XCON] "Many users in a single > >> operation" Requirements > >>=20 > >>=20 > >> Where is this "XCAP extension" defined in the XCAP documents?! > >>=20 > >> Besides, you can't do in the same way REQ-CP-3: It MAY be possible > >> for the client to batch multiple operations (such as add a user to > >> ACL blocked list, or remove a user from ACL allowed list) into a > >> single request that is processed atomically. > >>=20 > >> Thanks, Orit. > >>=20 > >> -----Original Message----- From: hisham.khartabil@nokia.com > >> [mailto:hisham.khartabil@nokia.com] Sent: Tuesday, February 10, > >> 2004 12:18 AM To: Orit Levin; xcon@ietf.org Subject: RE: [XCON] > >> "Many users in a single operation" Requirements > >>=20 > >> Here is an example of how to add multiple users to an ACL list in a > >> single operation: > >>=20 > >> PUT http://xcap.example.com/services/conferences/users/Alice/confe=20 > >> rence.xml? Conference/ACL/ACL-target-URI HTTP/1.1=20 > >> Content-Type:text/plain > >>=20 > >> >> Access-type=3D"Allowed">sip:bob@example.com=20 > >> >> Access-type=3D"Allowed">sip:alice@example.com=20 > >> >> Access-type=3D"Allowed">sip:bob@domain.com > >>=20 > >>=20 > >> The rest are done in a similar fashion. > >>=20 > >> /Hisham > >>=20 > >>> -----Original Message----- From: xcon-admin@ietf.org > >>> [mailto:xcon-admin@ietf.org]On > >>=20 > >> Behalf Of ext > >>=20 > >>> Orit Levin Sent: 10.February.2004 03:15 To: xcon@ietf.org=20 > >>> Subject: [XCON] "Many users in a single operation" Requirements > >>>=20 > >>>=20 > >>> Hi guys! > >>>=20 > >>> There are many places throughout the CPCP-req document that > >>> identify operations on a "subset of list" as MUST be performed in > >>> a single operation (e.g. G4, G6, H2, and H4). How do you plan to > >>> meet these requirements with "XCAP CPCP"? > >>>=20 > >>> The same question for REQ-CP-3: It MAY be possible for the client > >>> to batch multiple operations (such as add a user to ACL > >>=20 > >> blocked list, or > >>=20 > >>> remove a user from ACL allowed list) into a single request that > >>> is processed atomically. > >>>=20 > >>> Thanks, Orit. > >>>=20 > >>> _______________________________________________ XCON mailing list > >>> XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon > >>>=20 > >>=20 > >=20 >=20 > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Feb 13 11:42: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 LAA18682 for ; Fri, 13 Feb 2004 11:42:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArgOd-0001Sm-00 for simple-archive@ietf.org; Fri, 13 Feb 2004 11:42:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArgN4-00014C-00 for simple-archive@ietf.org; Fri, 13 Feb 2004 11:40:57 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArgKV-0000f4-00; Fri, 13 Feb 2004 11:38:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArgKM-0001vs-FQ; Fri, 13 Feb 2004 11:38:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArgJr-0001nw-Pw for simple@optimus.ietf.org; Fri, 13 Feb 2004 11:37:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18150 for ; Fri, 13 Feb 2004 11:37:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArgJq-0000Yq-00 for simple@ietf.org; Fri, 13 Feb 2004 11:37:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArgIa-0000P0-00 for simple@ietf.org; Fri, 13 Feb 2004 11:36:17 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1ArgHs-0000FB-00 for simple@ietf.org; Fri, 13 Feb 2004 11:35:32 -0500 Received: from dynamicsoft.com ([63.113.46.48]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i1DGYwNr004006; Fri, 13 Feb 2004 11:35:00 -0500 (EST) Message-ID: <402CFCAA.1000200@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: Jari Urpalainen CC: simple@ietf.org Subject: Re: [Simple] XCAP questions References: <4018DECF.7040108@nokia.com> <402BE9D3.7090408@dynamicsoft.com> <1076662170.7784.80.camel@xitami.research.nokia.com> In-Reply-To: <1076662170.7784.80.camel@xitami.research.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 13 Feb 2004 11:34:50 -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=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit inline. Jari Urpalainen wrote: > Thanks for your answers, comments inline. > > On Thu, 2004-02-12 at 23:02, ext Jonathan Rosenberg wrote: > > >>One way I would suggest for this is to define an application usage which >>is the "directory" of documents for a specific user. This application >>usage would specify a single well known place where the document would >>live. The end user themselves would not need to modify it; the server >>could set it when the user manages their own documents. This would then >>be read-only, and visible to either a user or more importantly, to a PE. >> >>I think this is more or less what Markus has proposed as well. The >>question is, where does such a definition occur: >> >>1. base xcap spec >>2. as part of each application usage >>3. a special "directory" application usage >> >>I prefer (3); we could define this once, and the "directory" would >>contain information on the documents for a user across all application >>usages. >> > > Option 3 sounds reasonable although it's a bit more complex to implement > than a simple directory list. You mean, to have a specific document that lists the documents in each directory? You'd still need to do a full tree traversal though in such a case. With one signle document, you would do one xcap fetch for the whole thing. > >>>2. XCAP ETags >>>In order to ease the synchronizing within resources between client and >>>server the base XCAP draft could specify the secure hash method e.g. >>>SHA-1 or whatever that is used to calculate the ETag. This is already >>>proposed in xcap-package but IMHO could be in the base spec. >> >>I don't follow. The etag is purely a server computed value. Generally, >>there is no need to specify how it is computed. Why does it matter how >>its computed? >> > > Sorry for not being too clear on this. Actually the problem i see is > that e.g. with xcap resource-lists the server should add empty list > uris. So what's the most reasonable way for the client to detect that > the server has added them ? > > The first option might be that the client "knows" this resource-list > behaviour and it queries after some put operation all the empty uris. This is what I had in mind. > This may lead to quite many round-trips I admit its a weakness, yes. But I dont expect people to be defining new lists all that often, as opposed to members of specific lists. The xcap-package could also be used to notify the client of the change. > and what's more, this is very au > related i.e. not very generic. > > The second option could be that the client subscribes (xcap-package) to > this document and gets those add-ons made by server from the > notifications. IMHO, this sounds a bit too heavy for this sort of simple > operation... Well, the client may already be doing that anyway. > > The third option could be that when doing put transaction the server > would reply within the reply payload all the stuff it has added. The > response should have it's own mime-type. I am perfectly aware that it is > all but "standard" http put behaviour but it would be efficient. Right. The non-standard part is a serious, serious concern. One of the major reasons that keeping this a pure http usage has been so important, is to reuse http client code on existing handsets. If we do something like this which would change that, then you've defeated much of the purpose in xcap's design. I welcome other ideas... > > >>>3. XCAP attributes >>>When updating/querying attributes is it necessary to include attribute >>>name in payload as attribute name is already provided in XPATH-query ? >>> >>>e.g. you could get /resource-lists/list[@name="friends"]/@uri >>>so you already know that you receive response for attribute uri. IMHO >>>when putting/getting attributes, payload could include only attribute >>>value. >> >>That can be true as long as the URI can only identify an attribute by >>name. I can change this as long as we stick to that constraint. >> > > fine. > >>>4. XCAP namespace declarations >>>As namespace handling resemble "standard" XML attributes is it also >>>allowed to change namespace declarations with similar semantics ? >> >>Great question. The answer is no. The reason is say that is that in >>xpath, namespace declarations are treated differently. If you want to >>get access to the namespaces of an element, you have to use the explicit >>namespace axis. >> >>I want to make sure that our URI addressing conventions do not violate >>or contradict xpath, and so I think they need to be consistent. I will >>clarify in the draft that the selectors do not apply to namespaces, >>comments or text content. If we want to be able to access and modify >>those, we need to expand the scope beyond where we are now. I would >>prefer not to do that. >> > > I fully agree that the attribute selectors should exclude namespaces. > However, adding comments would be sometimes nice but it can certainly be > left for future improvements. You can have them, you just won't be able to directly address them to change them by themselves. You'd have to modify them by sending the full element that surrounds them. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Feb 13 11:43:01 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 LAA18738 for ; Fri, 13 Feb 2004 11:43:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArgOf-0002lZ-Qg for simple-archive@odin.ietf.org; Fri, 13 Feb 2004 11:42:34 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DGgX8s010629 for simple-archive@odin.ietf.org; Fri, 13 Feb 2004 11:42:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArgOf-0002lA-GD for simple-web-archive@optimus.ietf.org; Fri, 13 Feb 2004 11:42:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18702 for ; Fri, 13 Feb 2004 11:42:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArgOe-0001T0-00 for simple-web-archive@ietf.org; Fri, 13 Feb 2004 11:42:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArgN7-00014e-00 for simple-web-archive@ietf.org; Fri, 13 Feb 2004 11:40:59 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArgKV-0000f4-00; Fri, 13 Feb 2004 11:38:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArgKM-0001vs-FQ; Fri, 13 Feb 2004 11:38:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArgJr-0001nw-Pw for simple@optimus.ietf.org; Fri, 13 Feb 2004 11:37:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18150 for ; Fri, 13 Feb 2004 11:37:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArgJq-0000Yq-00 for simple@ietf.org; Fri, 13 Feb 2004 11:37:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArgIa-0000P0-00 for simple@ietf.org; Fri, 13 Feb 2004 11:36:17 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1ArgHs-0000FB-00 for simple@ietf.org; Fri, 13 Feb 2004 11:35:32 -0500 Received: from dynamicsoft.com ([63.113.46.48]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i1DGYwNr004006; Fri, 13 Feb 2004 11:35:00 -0500 (EST) Message-ID: <402CFCAA.1000200@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: Jari Urpalainen CC: simple@ietf.org Subject: Re: [Simple] XCAP questions References: <4018DECF.7040108@nokia.com> <402BE9D3.7090408@dynamicsoft.com> <1076662170.7784.80.camel@xitami.research.nokia.com> In-Reply-To: <1076662170.7784.80.camel@xitami.research.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 13 Feb 2004 11:34:50 -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=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit inline. Jari Urpalainen wrote: > Thanks for your answers, comments inline. > > On Thu, 2004-02-12 at 23:02, ext Jonathan Rosenberg wrote: > > >>One way I would suggest for this is to define an application usage which >>is the "directory" of documents for a specific user. This application >>usage would specify a single well known place where the document would >>live. The end user themselves would not need to modify it; the server >>could set it when the user manages their own documents. This would then >>be read-only, and visible to either a user or more importantly, to a PE. >> >>I think this is more or less what Markus has proposed as well. The >>question is, where does such a definition occur: >> >>1. base xcap spec >>2. as part of each application usage >>3. a special "directory" application usage >> >>I prefer (3); we could define this once, and the "directory" would >>contain information on the documents for a user across all application >>usages. >> > > Option 3 sounds reasonable although it's a bit more complex to implement > than a simple directory list. You mean, to have a specific document that lists the documents in each directory? You'd still need to do a full tree traversal though in such a case. With one signle document, you would do one xcap fetch for the whole thing. > >>>2. XCAP ETags >>>In order to ease the synchronizing within resources between client and >>>server the base XCAP draft could specify the secure hash method e.g. >>>SHA-1 or whatever that is used to calculate the ETag. This is already >>>proposed in xcap-package but IMHO could be in the base spec. >> >>I don't follow. The etag is purely a server computed value. Generally, >>there is no need to specify how it is computed. Why does it matter how >>its computed? >> > > Sorry for not being too clear on this. Actually the problem i see is > that e.g. with xcap resource-lists the server should add empty list > uris. So what's the most reasonable way for the client to detect that > the server has added them ? > > The first option might be that the client "knows" this resource-list > behaviour and it queries after some put operation all the empty uris. This is what I had in mind. > This may lead to quite many round-trips I admit its a weakness, yes. But I dont expect people to be defining new lists all that often, as opposed to members of specific lists. The xcap-package could also be used to notify the client of the change. > and what's more, this is very au > related i.e. not very generic. > > The second option could be that the client subscribes (xcap-package) to > this document and gets those add-ons made by server from the > notifications. IMHO, this sounds a bit too heavy for this sort of simple > operation... Well, the client may already be doing that anyway. > > The third option could be that when doing put transaction the server > would reply within the reply payload all the stuff it has added. The > response should have it's own mime-type. I am perfectly aware that it is > all but "standard" http put behaviour but it would be efficient. Right. The non-standard part is a serious, serious concern. One of the major reasons that keeping this a pure http usage has been so important, is to reuse http client code on existing handsets. If we do something like this which would change that, then you've defeated much of the purpose in xcap's design. I welcome other ideas... > > >>>3. XCAP attributes >>>When updating/querying attributes is it necessary to include attribute >>>name in payload as attribute name is already provided in XPATH-query ? >>> >>>e.g. you could get /resource-lists/list[@name="friends"]/@uri >>>so you already know that you receive response for attribute uri. IMHO >>>when putting/getting attributes, payload could include only attribute >>>value. >> >>That can be true as long as the URI can only identify an attribute by >>name. I can change this as long as we stick to that constraint. >> > > fine. > >>>4. XCAP namespace declarations >>>As namespace handling resemble "standard" XML attributes is it also >>>allowed to change namespace declarations with similar semantics ? >> >>Great question. The answer is no. The reason is say that is that in >>xpath, namespace declarations are treated differently. If you want to >>get access to the namespaces of an element, you have to use the explicit >>namespace axis. >> >>I want to make sure that our URI addressing conventions do not violate >>or contradict xpath, and so I think they need to be consistent. I will >>clarify in the draft that the selectors do not apply to namespaces, >>comments or text content. If we want to be able to access and modify >>those, we need to expand the scope beyond where we are now. I would >>prefer not to do that. >> > > I fully agree that the attribute selectors should exclude namespaces. > However, adding comments would be sometimes nice but it can certainly be > left for future improvements. You can have them, you just won't be able to directly address them to change them by themselves. You'd have to modify them by sending the full element that surrounds them. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Feb 13 11:47: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 LAA19427 for ; Fri, 13 Feb 2004 11:47:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArgTg-0002YK-00 for simple-archive@ietf.org; Fri, 13 Feb 2004 11:47:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArgSu-0002Nc-00 for simple-archive@ietf.org; Fri, 13 Feb 2004 11:46:56 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1ArgRA-00021P-00; Fri, 13 Feb 2004 11:45:08 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1ArgRD-00047y-2K; Fri, 13 Feb 2004 11:45:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArgR5-00030d-52; Fri, 13 Feb 2004 11:45:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArgQm-0002xu-S1 for simple@optimus.ietf.org; Fri, 13 Feb 2004 11:44:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18894 for ; Fri, 13 Feb 2004 11:44:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArgQl-0001v5-00 for simple@ietf.org; Fri, 13 Feb 2004 11:44:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArgOm-0001Ub-00 for simple@ietf.org; Fri, 13 Feb 2004 11:42:41 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1ArgND-00010O-00 for simple@ietf.org; Fri, 13 Feb 2004 11:41:03 -0500 Received: from dynamicsoft.com ([63.113.46.48]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i1DGeeNr004013; Fri, 13 Feb 2004 11:40:40 -0500 (EST) Message-ID: <402CFE00.6010500@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: Markus.Isomaki@nokia.com CC: Jari.Urpalainen@nokia.com, simple@ietf.org Subject: Re: [Simple] XCAP questions References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 13 Feb 2004 11:40:32 -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=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Markus.Isomaki@nokia.com wrote: > Hi, > > Regarding the XCAP directory application usage: > > I also like approach 3, as this would make things easiest for the > client. A follow-up issue to this: Would it be possible to include > also the Etags (or similar version identifiers) for each resource > listed in that directory file? In this way the user could only be > subscribed to the changes in the directory file (via XCAP-change > event), and still learn about all the changes that have occured in > any of the resources that he/she owns. I dont think having the etags in there helps. Changes in the directory file would not contain the changes in the actual documents. As such, the client would know about the change, but knowing the new etag doesnt help - it would still have to do a get of the document to find out what changed. There IS value, however, in including etags in the xcap-event package, so that the client can apply the diff, verify it, know the new etag, and any PUTs it would do would be against that new etag. > > If we agree that this is the way, I think specifying this new usage > would be straightforward, and I can volunteer to provide the first > version for it after IETF 59. Great! -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Feb 13 11:48:17 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 LAA19503 for ; Fri, 13 Feb 2004 11:48:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArgTm-0003VO-8O for simple-archive@odin.ietf.org; Fri, 13 Feb 2004 11:47:50 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DGloWV013468 for simple-archive@odin.ietf.org; Fri, 13 Feb 2004 11:47:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArgTm-0003V9-5A for simple-web-archive@optimus.ietf.org; Fri, 13 Feb 2004 11:47:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19445 for ; Fri, 13 Feb 2004 11:47:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArgTk-0002Yy-00 for simple-web-archive@ietf.org; Fri, 13 Feb 2004 11:47:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArgSv-0002Nr-00 for simple-web-archive@ietf.org; Fri, 13 Feb 2004 11:46:57 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1ArgRA-00021P-00; Fri, 13 Feb 2004 11:45:08 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1ArgRD-00047y-2K; Fri, 13 Feb 2004 11:45:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArgR5-00030d-52; Fri, 13 Feb 2004 11:45:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArgQm-0002xu-S1 for simple@optimus.ietf.org; Fri, 13 Feb 2004 11:44:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18894 for ; Fri, 13 Feb 2004 11:44:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArgQl-0001v5-00 for simple@ietf.org; Fri, 13 Feb 2004 11:44:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArgOm-0001Ub-00 for simple@ietf.org; Fri, 13 Feb 2004 11:42:41 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1ArgND-00010O-00 for simple@ietf.org; Fri, 13 Feb 2004 11:41:03 -0500 Received: from dynamicsoft.com ([63.113.46.48]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i1DGeeNr004013; Fri, 13 Feb 2004 11:40:40 -0500 (EST) Message-ID: <402CFE00.6010500@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: Markus.Isomaki@nokia.com CC: Jari.Urpalainen@nokia.com, simple@ietf.org Subject: Re: [Simple] XCAP questions References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 13 Feb 2004 11:40:32 -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=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Markus.Isomaki@nokia.com wrote: > Hi, > > Regarding the XCAP directory application usage: > > I also like approach 3, as this would make things easiest for the > client. A follow-up issue to this: Would it be possible to include > also the Etags (or similar version identifiers) for each resource > listed in that directory file? In this way the user could only be > subscribed to the changes in the directory file (via XCAP-change > event), and still learn about all the changes that have occured in > any of the resources that he/she owns. I dont think having the etags in there helps. Changes in the directory file would not contain the changes in the actual documents. As such, the client would know about the change, but knowing the new etag doesnt help - it would still have to do a get of the document to find out what changed. There IS value, however, in including etags in the xcap-event package, so that the client can apply the diff, verify it, know the new etag, and any PUTs it would do would be against that new etag. > > If we agree that this is the way, I think specifying this new usage > would be straightforward, and I can volunteer to provide the first > version for it after IETF 59. Great! -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Feb 13 12:19:01 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21096 for ; Fri, 13 Feb 2004 12:19:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Argxy-0005Tz-00 for simple-archive@ietf.org; Fri, 13 Feb 2004 12:19:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Argx1-0005Pe-00 for simple-archive@ietf.org; Fri, 13 Feb 2004 12:18:04 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Argw4-0005LO-00; Fri, 13 Feb 2004 12:17:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Argw0-0006Fy-RD; Fri, 13 Feb 2004 12:17:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArgvI-0006Ee-75 for simple@optimus.ietf.org; Fri, 13 Feb 2004 12:16:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21042 for ; Fri, 13 Feb 2004 12:16:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArgvG-0005H4-00 for simple@ietf.org; Fri, 13 Feb 2004 12:16:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Argug-0005Cw-00 for simple@ietf.org; Fri, 13 Feb 2004 12:15:38 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1Argtp-000564-00 for simple@ietf.org; Fri, 13 Feb 2004 12:14:45 -0500 Received: from dynamicsoft.com ([63.113.46.48]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i1DHELNr004057; Fri, 13 Feb 2004 12:14:21 -0500 (EST) Message-ID: <402D05E4.7030100@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: Markus.Isomaki@nokia.com CC: hisham.khartabil@nokia.com, oritl@microsoft.com, simple@ietf.org Subject: Re: [Simple] Re: [XCON] "Many users in a single operation" Requirements References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 13 Feb 2004 12:14:12 -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=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Markus.Isomaki@nokia.com wrote: > Hi, > > Jonathan Rosenberg wrote: > >> We had discussed this particular limitation quite a bit during the >> design of xcap, and it was deemed an acceptable limitation. If it >> is no longer the case, then we can discuss fixes. > > > I think this all depends on what kind of usages we envision for XCAP. > The requirement for doing multiple operations atomically was also > originally included in the data manipulation reqs that were used as > motivation for XCAP. However, it seemed that doing the actual > applications that were in SIMPLE charter (mainly presence related) > did not really need this capability. Right. Though I fear that, in the future there will be more. > > My opinion is that it should be added to XCAP if and only if: 1. It > is mandatory for conference control (CPCP) according to the concensus > in XCON WG 2. XCON WG chooses XCAP for CPCP's baseline given that > XCAP can meet this requirement 3. XCAP would not be complicated or > delayed considerably because of this > > So far I haven't seen clarification on either 1. or 2. in XCON, but I > think it would be a good target for the Korea meeting. I would propose that I make a first stab at what such a feature might look like in the revision I will submit (probably at 8:58am est Monday...), and then we can discuss it with something concrete in hand. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Feb 13 12:19:32 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 MAA21165 for ; Fri, 13 Feb 2004 12:19:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Argy1-0006N6-9Q for simple-archive@odin.ietf.org; Fri, 13 Feb 2004 12:19:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DHJ5Ko024491 for simple-archive@odin.ietf.org; Fri, 13 Feb 2004 12:19:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Argy1-0006Mw-5g for simple-web-archive@optimus.ietf.org; Fri, 13 Feb 2004 12:19:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21114 for ; Fri, 13 Feb 2004 12:19:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Argxz-0005U4-00 for simple-web-archive@ietf.org; Fri, 13 Feb 2004 12:19:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Argx2-0005Pm-00 for simple-web-archive@ietf.org; Fri, 13 Feb 2004 12:18:05 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Argw4-0005LO-00; Fri, 13 Feb 2004 12:17:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Argw0-0006Fy-RD; Fri, 13 Feb 2004 12:17:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArgvI-0006Ee-75 for simple@optimus.ietf.org; Fri, 13 Feb 2004 12:16:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21042 for ; Fri, 13 Feb 2004 12:16:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArgvG-0005H4-00 for simple@ietf.org; Fri, 13 Feb 2004 12:16:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Argug-0005Cw-00 for simple@ietf.org; Fri, 13 Feb 2004 12:15:38 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1Argtp-000564-00 for simple@ietf.org; Fri, 13 Feb 2004 12:14:45 -0500 Received: from dynamicsoft.com ([63.113.46.48]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i1DHELNr004057; Fri, 13 Feb 2004 12:14:21 -0500 (EST) Message-ID: <402D05E4.7030100@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: Markus.Isomaki@nokia.com CC: hisham.khartabil@nokia.com, oritl@microsoft.com, simple@ietf.org Subject: Re: [Simple] Re: [XCON] "Many users in a single operation" Requirements References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 13 Feb 2004 12:14:12 -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=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Markus.Isomaki@nokia.com wrote: > Hi, > > Jonathan Rosenberg wrote: > >> We had discussed this particular limitation quite a bit during the >> design of xcap, and it was deemed an acceptable limitation. If it >> is no longer the case, then we can discuss fixes. > > > I think this all depends on what kind of usages we envision for XCAP. > The requirement for doing multiple operations atomically was also > originally included in the data manipulation reqs that were used as > motivation for XCAP. However, it seemed that doing the actual > applications that were in SIMPLE charter (mainly presence related) > did not really need this capability. Right. Though I fear that, in the future there will be more. > > My opinion is that it should be added to XCAP if and only if: 1. It > is mandatory for conference control (CPCP) according to the concensus > in XCON WG 2. XCON WG chooses XCAP for CPCP's baseline given that > XCAP can meet this requirement 3. XCAP would not be complicated or > delayed considerably because of this > > So far I haven't seen clarification on either 1. or 2. in XCON, but I > think it would be a good target for the Korea meeting. I would propose that I make a first stab at what such a feature might look like in the revision I will submit (probably at 8:58am est Monday...), and then we can discuss it with something concrete in hand. -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 Sat Feb 14 14:32: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 OAA27789 for ; Sat, 14 Feb 2004 14:32:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1As5X5-0004W1-00 for simple-archive@ietf.org; Sat, 14 Feb 2004 14:32:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1As5W8-0004Su-00 for simple-archive@ietf.org; Sat, 14 Feb 2004 14:31:57 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1As5VK-0004Pr-00; Sat, 14 Feb 2004 14:31:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1As5VG-0004dV-7t; Sat, 14 Feb 2004 14:31:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1As5VD-0004cE-Ak for simple@optimus.ietf.org; Sat, 14 Feb 2004 14:30:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27718 for ; Sat, 14 Feb 2004 14:30:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1As5VA-0004PU-00 for simple@ietf.org; Sat, 14 Feb 2004 14:30:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1As5UT-0004Ms-00 for simple@ietf.org; Sat, 14 Feb 2004 14:30:14 -0500 Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx with esmtp (Exim 4.12) id 1As5Ti-0004Hf-00; Sat, 14 Feb 2004 14:29:26 -0500 Received: from mail5.microsoft.com ([157.54.6.156]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sat, 14 Feb 2004 11:30:10 -0800 Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(6.0.3790.1039); Sat, 14 Feb 2004 11:28:38 -0800 Received: from 157.54.6.197 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Sat, 14 Feb 2004 11:28:38 -0800 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by INET-HUB-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Sat, 14 Feb 2004 11:28:41 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7165.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Re: [XCON] "Many users in a single operation" Requirements Message-ID: Thread-Topic: [Simple] Re: [XCON] "Many users in a single operation" Requirements Thread-Index: AcPyVOSxtK2GWGngQoCejDN7cjsSpwAzRlQg From: "Orit Levin" To: "Jonathan Rosenberg" , , Cc: , X-OriginalArrivalTime: 14 Feb 2004 19:28:41.0536 (UTC) FILETIME=[C0D04400:01C3F330] 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: Sat, 14 Feb 2004 11:29:01 -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.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable XCAP was introduced and designed (as its name says: "XML Configuration Access Protocol") as a LIGHT way CONFIGURATION protocol. As a result, by design it doesn't address close-to-real-time dynamic data manipulations. You can perform any rich atomic operation you need, but in order to do so, you will need to be (preferably) the only owner of the data, to upload the whole data sub-tree, change it locally, and then PUT it back. I think it is a mistake to stretch XCAP functionality beyond this. I think it is a mistake to position XCAP as the (only) protocol for all kinds of dynamic operations neither for presence nor for conferencing. Instead, I liked Jonathan's approach to his "XCAP drafts":=20 "The documents are much less xcap-centric. They talk about document formats, and have a small section at the end which defines the usage for xcap. The title and filenames have also changed to reflect this. This clarifies that these documents can be used outside of xcap." I suggest that XCON group does the same for CPCP. Thanks, Orit. -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]=20 Sent: Friday, February 13, 2004 9:14 AM To: Markus.Isomaki@nokia.com Cc: hisham.khartabil@nokia.com; Orit Levin; simple@ietf.org Subject: Re: [Simple] Re: [XCON] "Many users in a single operation" Requirements Markus.Isomaki@nokia.com wrote: > Hi, >=20 > Jonathan Rosenberg wrote: >=20 >> We had discussed this particular limitation quite a bit during the >> design of xcap, and it was deemed an acceptable limitation. If it >> is no longer the case, then we can discuss fixes. >=20 >=20 > I think this all depends on what kind of usages we envision for XCAP. > The requirement for doing multiple operations atomically was also > originally included in the data manipulation reqs that were used as > motivation for XCAP. However, it seemed that doing the actual > applications that were in SIMPLE charter (mainly presence related) > did not really need this capability. Right. Though I fear that, in the future there will be more. >=20 > My opinion is that it should be added to XCAP if and only if: 1. It > is mandatory for conference control (CPCP) according to the concensus > in XCON WG 2. XCON WG chooses XCAP for CPCP's baseline given that > XCAP can meet this requirement 3. XCAP would not be complicated or > delayed considerably because of this >=20 > So far I haven't seen clarification on either 1. or 2. in XCON, but I > think it would be a good target for the Korea meeting. I would propose that I make a first stab at what such a feature might=20 look like in the revision I will submit (probably at 8:58am est=20 Monday...), and then we can discuss it with something concrete in hand. -Jonathan R. --=20 Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Sat Feb 14 14:33:27 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 OAA27832 for ; Sat, 14 Feb 2004 14:33:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1As5X9-0004kd-CU for simple-archive@odin.ietf.org; Sat, 14 Feb 2004 14:32:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1EJWxZ0018259 for simple-archive@odin.ietf.org; Sat, 14 Feb 2004 14:32:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1As5X9-0004kQ-8w for simple-web-archive@optimus.ietf.org; Sat, 14 Feb 2004 14:32:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27809 for ; Sat, 14 Feb 2004 14:32:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1As5X6-0004W6-00 for simple-web-archive@ietf.org; Sat, 14 Feb 2004 14:32:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1As5W9-0004T1-00 for simple-web-archive@ietf.org; Sat, 14 Feb 2004 14:31:58 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1As5VK-0004Pr-00; Sat, 14 Feb 2004 14:31:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1As5VG-0004dV-7t; Sat, 14 Feb 2004 14:31:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1As5VD-0004cE-Ak for simple@optimus.ietf.org; Sat, 14 Feb 2004 14:30:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27718 for ; Sat, 14 Feb 2004 14:30:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1As5VA-0004PU-00 for simple@ietf.org; Sat, 14 Feb 2004 14:30:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1As5UT-0004Ms-00 for simple@ietf.org; Sat, 14 Feb 2004 14:30:14 -0500 Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx with esmtp (Exim 4.12) id 1As5Ti-0004Hf-00; Sat, 14 Feb 2004 14:29:26 -0500 Received: from mail5.microsoft.com ([157.54.6.156]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sat, 14 Feb 2004 11:30:10 -0800 Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(6.0.3790.1039); Sat, 14 Feb 2004 11:28:38 -0800 Received: from 157.54.6.197 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Sat, 14 Feb 2004 11:28:38 -0800 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by INET-HUB-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Sat, 14 Feb 2004 11:28:41 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7165.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Re: [XCON] "Many users in a single operation" Requirements Message-ID: Thread-Topic: [Simple] Re: [XCON] "Many users in a single operation" Requirements Thread-Index: AcPyVOSxtK2GWGngQoCejDN7cjsSpwAzRlQg From: "Orit Levin" To: "Jonathan Rosenberg" , , Cc: , X-OriginalArrivalTime: 14 Feb 2004 19:28:41.0536 (UTC) FILETIME=[C0D04400:01C3F330] 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: Sat, 14 Feb 2004 11:29:01 -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.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable XCAP was introduced and designed (as its name says: "XML Configuration Access Protocol") as a LIGHT way CONFIGURATION protocol. As a result, by design it doesn't address close-to-real-time dynamic data manipulations. You can perform any rich atomic operation you need, but in order to do so, you will need to be (preferably) the only owner of the data, to upload the whole data sub-tree, change it locally, and then PUT it back. I think it is a mistake to stretch XCAP functionality beyond this. I think it is a mistake to position XCAP as the (only) protocol for all kinds of dynamic operations neither for presence nor for conferencing. Instead, I liked Jonathan's approach to his "XCAP drafts":=20 "The documents are much less xcap-centric. They talk about document formats, and have a small section at the end which defines the usage for xcap. The title and filenames have also changed to reflect this. This clarifies that these documents can be used outside of xcap." I suggest that XCON group does the same for CPCP. Thanks, Orit. -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]=20 Sent: Friday, February 13, 2004 9:14 AM To: Markus.Isomaki@nokia.com Cc: hisham.khartabil@nokia.com; Orit Levin; simple@ietf.org Subject: Re: [Simple] Re: [XCON] "Many users in a single operation" Requirements Markus.Isomaki@nokia.com wrote: > Hi, >=20 > Jonathan Rosenberg wrote: >=20 >> We had discussed this particular limitation quite a bit during the >> design of xcap, and it was deemed an acceptable limitation. If it >> is no longer the case, then we can discuss fixes. >=20 >=20 > I think this all depends on what kind of usages we envision for XCAP. > The requirement for doing multiple operations atomically was also > originally included in the data manipulation reqs that were used as > motivation for XCAP. However, it seemed that doing the actual > applications that were in SIMPLE charter (mainly presence related) > did not really need this capability. Right. Though I fear that, in the future there will be more. >=20 > My opinion is that it should be added to XCAP if and only if: 1. It > is mandatory for conference control (CPCP) according to the concensus > in XCON WG 2. XCON WG chooses XCAP for CPCP's baseline given that > XCAP can meet this requirement 3. XCAP would not be complicated or > delayed considerably because of this >=20 > So far I haven't seen clarification on either 1. or 2. in XCON, but I > think it would be a good target for the Korea meeting. I would propose that I make a first stab at what such a feature might=20 look like in the revision I will submit (probably at 8:58am est=20 Monday...), and then we can discuss it with something concrete in hand. -Jonathan R. --=20 Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Sat Feb 14 18:41:00 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05969 for ; Sat, 14 Feb 2004 18:40:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1As9PB-0003fe-00 for simple-archive@ietf.org; Sat, 14 Feb 2004 18:41:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1As9OB-0003cf-00 for simple-archive@ietf.org; Sat, 14 Feb 2004 18:40:00 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1As9NM-0003aG-00; Sat, 14 Feb 2004 18:39:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1As9NF-0000nf-Q5; Sat, 14 Feb 2004 18:39:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1As9MR-0000m4-30 for simple@optimus.ietf.org; Sat, 14 Feb 2004 18:38:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05947 for ; Sat, 14 Feb 2004 18:38:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1As9MO-0003X8-00 for simple@ietf.org; Sat, 14 Feb 2004 18:38:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1As9LS-0003Tm-00 for simple@ietf.org; Sat, 14 Feb 2004 18:37:11 -0500 Received: from hoemail1.lucent.com ([192.11.226.161] helo=hoemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1As9Kv-0003PD-00 for simple@ietf.org; Sat, 14 Feb 2004 18:36:37 -0500 Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57]) by hoemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1ENZwD00154 for ; Sat, 14 Feb 2004 17:35:59 -0600 (CST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id <17CJ6RN5>; Sat, 14 Feb 2004 23:35:57 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00B1B2152@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: Jonathan Rosenberg Cc: simple@ietf.org Subject: RE: [Simple] Re: [XCON] "Many users in a single operation" Requir ements MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.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, 14 Feb 2004 23:35:55 -0000 X-Spam-Checker-Version: SpamAssassin 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 Can I suggest that such a proposal is not a "revision" but is a separate document identifying what enhancements and changes would be required to the xcap documentation. regards Keith > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: 13 February 2004 17:14 > To: Markus.Isomaki@nokia.com > Cc: hisham.khartabil@nokia.com; oritl@microsoft.com; simple@ietf.org > Subject: Re: [Simple] Re: [XCON] "Many users in a single operation" > Requirements > > > > > Markus.Isomaki@nokia.com wrote: > > > Hi, > > > > Jonathan Rosenberg wrote: > > > >> We had discussed this particular limitation quite a bit during the > >> design of xcap, and it was deemed an acceptable limitation. If it > >> is no longer the case, then we can discuss fixes. > > > > > > I think this all depends on what kind of usages we envision > for XCAP. > > The requirement for doing multiple operations atomically was also > > originally included in the data manipulation reqs that were used as > > motivation for XCAP. However, it seemed that doing the actual > > applications that were in SIMPLE charter (mainly presence related) > > did not really need this capability. > > Right. Though I fear that, in the future there will be more. > > > > > My opinion is that it should be added to XCAP if and only if: 1. It > > is mandatory for conference control (CPCP) according to the > concensus > > in XCON WG 2. XCON WG chooses XCAP for CPCP's baseline given that > > XCAP can meet this requirement 3. XCAP would not be complicated or > > delayed considerably because of this > > > > So far I haven't seen clarification on either 1. or 2. in > XCON, but I > > think it would be a good target for the Korea meeting. > > I would propose that I make a first stab at what such a feature might > look like in the revision I will submit (probably at 8:58am est > Monday...), and then we can discuss it with something > concrete in hand. > > -Jonathan R. > > > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Sat Feb 14 18:41:32 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 SAA06004 for ; Sat, 14 Feb 2004 18:41:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1As9PF-0000y6-MF for simple-archive@odin.ietf.org; Sat, 14 Feb 2004 18:41:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1ENf5Zk003719 for simple-archive@odin.ietf.org; Sat, 14 Feb 2004 18:41:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1As9PF-0000xu-G9 for simple-web-archive@optimus.ietf.org; Sat, 14 Feb 2004 18:41:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05991 for ; Sat, 14 Feb 2004 18:41:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1As9PC-0003fs-00 for simple-web-archive@ietf.org; Sat, 14 Feb 2004 18:41:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1As9OC-0003co-00 for simple-web-archive@ietf.org; Sat, 14 Feb 2004 18:40:01 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1As9NM-0003aG-00; Sat, 14 Feb 2004 18:39:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1As9NF-0000nf-Q5; Sat, 14 Feb 2004 18:39:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1As9MR-0000m4-30 for simple@optimus.ietf.org; Sat, 14 Feb 2004 18:38:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05947 for ; Sat, 14 Feb 2004 18:38:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1As9MO-0003X8-00 for simple@ietf.org; Sat, 14 Feb 2004 18:38:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1As9LS-0003Tm-00 for simple@ietf.org; Sat, 14 Feb 2004 18:37:11 -0500 Received: from hoemail1.lucent.com ([192.11.226.161] helo=hoemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1As9Kv-0003PD-00 for simple@ietf.org; Sat, 14 Feb 2004 18:36:37 -0500 Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57]) by hoemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1ENZwD00154 for ; Sat, 14 Feb 2004 17:35:59 -0600 (CST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id <17CJ6RN5>; Sat, 14 Feb 2004 23:35:57 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00B1B2152@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: Jonathan Rosenberg Cc: simple@ietf.org Subject: RE: [Simple] Re: [XCON] "Many users in a single operation" Requir ements MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.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, 14 Feb 2004 23:35:55 -0000 X-Spam-Checker-Version: SpamAssassin 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 Can I suggest that such a proposal is not a "revision" but is a separate document identifying what enhancements and changes would be required to the xcap documentation. regards Keith > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: 13 February 2004 17:14 > To: Markus.Isomaki@nokia.com > Cc: hisham.khartabil@nokia.com; oritl@microsoft.com; simple@ietf.org > Subject: Re: [Simple] Re: [XCON] "Many users in a single operation" > Requirements > > > > > Markus.Isomaki@nokia.com wrote: > > > Hi, > > > > Jonathan Rosenberg wrote: > > > >> We had discussed this particular limitation quite a bit during the > >> design of xcap, and it was deemed an acceptable limitation. If it > >> is no longer the case, then we can discuss fixes. > > > > > > I think this all depends on what kind of usages we envision > for XCAP. > > The requirement for doing multiple operations atomically was also > > originally included in the data manipulation reqs that were used as > > motivation for XCAP. However, it seemed that doing the actual > > applications that were in SIMPLE charter (mainly presence related) > > did not really need this capability. > > Right. Though I fear that, in the future there will be more. > > > > > My opinion is that it should be added to XCAP if and only if: 1. It > > is mandatory for conference control (CPCP) according to the > concensus > > in XCON WG 2. XCON WG chooses XCAP for CPCP's baseline given that > > XCAP can meet this requirement 3. XCAP would not be complicated or > > delayed considerably because of this > > > > So far I haven't seen clarification on either 1. or 2. in > XCON, but I > > think it would be a good target for the Korea meeting. > > I would propose that I make a first stab at what such a feature might > look like in the revision I will submit (probably at 8:58am est > Monday...), and then we can discuss it with something > concrete in hand. > > -Jonathan R. > > > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Sat Feb 14 20:31: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 UAA08221 for ; Sat, 14 Feb 2004 20:31:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsB7f-0001j8-00 for simple-archive@ietf.org; Sat, 14 Feb 2004 20:31:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsB6f-0001eT-00 for simple-archive@ietf.org; Sat, 14 Feb 2004 20:30:02 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AsB5i-0001a4-00; Sat, 14 Feb 2004 20:29:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsB5g-0006cP-Lz; Sat, 14 Feb 2004 20:29:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsB4n-0006ap-HD for simple@optimus.ietf.org; Sat, 14 Feb 2004 20:28:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08183 for ; Sat, 14 Feb 2004 20:28:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsB4l-0001XU-00 for simple@ietf.org; Sat, 14 Feb 2004 20:28:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsB3o-0001VL-00 for simple@ietf.org; Sat, 14 Feb 2004 20:27:05 -0500 Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx with esmtp (Exim 4.12) id 1AsB2z-0001Qs-00 for simple@ietf.org; Sat, 14 Feb 2004 20:26:13 -0500 Received: from eamrcnt717.exu.ericsson.se (eamrcnt717.exu.ericsson.se [138.85.90.249]) by imr2.ericy.com (8.12.10/8.12.10) with ESMTP id i1F1PhfX023895 for ; Sat, 14 Feb 2004 19:25:43 -0600 (CST) Received: from eamrcnt750.exu.ericsson.se ([138.85.133.51]) by eamrcnt717.exu.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Sat, 14 Feb 2004 19:21:21 -0600 Received: by eamrcnt750.exu.ericsson.se with Internet Mail Service (5.5.2657.72) id <151RZDT2>; Sat, 14 Feb 2004 19:25:36 -0600 Message-ID: <2DBF697D5B36014ABA46E66A96107DA02C9531@lmc37.lmc.ericsson.se> From: "George Foti (QC/EMC)" To: "'simple@ietf.org'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3F362.7D9EBB08" X-OriginalArrivalTime: 15 Feb 2004 01:21:21.0906 (UTC) FILETIME=[05607D20:01C3F362] Subject: [Simple] Comment on MSRP -03 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.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, 14 Feb 2004 19:24:43 -0600 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,HTML_20_30,HTML_MESSAGE autolearn=no version=2.60 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3F362.7D9EBB08 Content-Type: text/plain; charset="iso-8859-1" Quoting the subject draft Section 6.2 entitled "The Direction Attribute" The count is used to determine if a new connection is required in future SDP exchanges for a given stream. For the initial SDP exchange, the count pamameter MUST be set to zero. Endpoints sending a new offer related to an existing stream MUST increment this count from the value in the most recent successful exchange for the stream. The last paragraph needs to be split in 2 parts; one to cover the case, for which the count *MUST* be incremented, when the new offer requires a new TCP connection, the second covers the case where no new connection is required and in that case the count *MUST NOT* be incremented. While the above is stated later in this document (section 6.6), it is not clear from the above the section (section 6.2) and where the count is introduced for the first time in the first draft. Rgds/gf Ericsson Canada This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. ------_=_NextPart_001_01C3F362.7D9EBB08 Content-Type: text/html; charset="iso-8859-1"
Quoting the subject draft Section 6.2 entitled  "The Direction Attribute"
 
 The count is used to determine if a new connection is required in
   future SDP exchanges for a given stream. For the initial SDP
   exchange, the count pamameter MUST be set to zero. Endpoints sending
   a new offer related to an existing stream MUST increment this count
   from the value in the most recent successful exchange for the stream.
 
The last paragraph needs to be split in 2 parts;  one to cover the case, for which the count *MUST* be incremented, when the new offer requires a new TCP connection, the second covers the case where no new connection is required and in that case the count *MUST NOT* be incremented.
 
While the above is stated later in this document (section 6.6), it is not clear from the above the section (section 6.2) and where the count is introduced for the first time in the first draft.
 
Rgds/gf
 
Ericsson Canada
 



This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. ------_=_NextPart_001_01C3F362.7D9EBB08-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Sat Feb 14 20:31:34 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 UAA08264 for ; Sat, 14 Feb 2004 20:31:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsB7i-0006nF-8r for simple-archive@odin.ietf.org; Sat, 14 Feb 2004 20:31:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1F1V6nD026107 for simple-archive@odin.ietf.org; Sat, 14 Feb 2004 20:31:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsB7i-0006n0-2n for simple-web-archive@optimus.ietf.org; Sat, 14 Feb 2004 20:31:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08238 for ; Sat, 14 Feb 2004 20:31:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsB7f-0001jF-00 for simple-web-archive@ietf.org; Sat, 14 Feb 2004 20:31:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsB6g-0001ea-00 for simple-web-archive@ietf.org; Sat, 14 Feb 2004 20:30:03 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AsB5i-0001a4-00; Sat, 14 Feb 2004 20:29:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsB5g-0006cP-Lz; Sat, 14 Feb 2004 20:29:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsB4n-0006ap-HD for simple@optimus.ietf.org; Sat, 14 Feb 2004 20:28:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08183 for ; Sat, 14 Feb 2004 20:28:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsB4l-0001XU-00 for simple@ietf.org; Sat, 14 Feb 2004 20:28:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsB3o-0001VL-00 for simple@ietf.org; Sat, 14 Feb 2004 20:27:05 -0500 Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx with esmtp (Exim 4.12) id 1AsB2z-0001Qs-00 for simple@ietf.org; Sat, 14 Feb 2004 20:26:13 -0500 Received: from eamrcnt717.exu.ericsson.se (eamrcnt717.exu.ericsson.se [138.85.90.249]) by imr2.ericy.com (8.12.10/8.12.10) with ESMTP id i1F1PhfX023895 for ; Sat, 14 Feb 2004 19:25:43 -0600 (CST) Received: from eamrcnt750.exu.ericsson.se ([138.85.133.51]) by eamrcnt717.exu.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Sat, 14 Feb 2004 19:21:21 -0600 Received: by eamrcnt750.exu.ericsson.se with Internet Mail Service (5.5.2657.72) id <151RZDT2>; Sat, 14 Feb 2004 19:25:36 -0600 Message-ID: <2DBF697D5B36014ABA46E66A96107DA02C9531@lmc37.lmc.ericsson.se> From: "George Foti (QC/EMC)" To: "'simple@ietf.org'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3F362.7D9EBB08" X-OriginalArrivalTime: 15 Feb 2004 01:21:21.0906 (UTC) FILETIME=[05607D20:01C3F362] Subject: [Simple] Comment on MSRP -03 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.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, 14 Feb 2004 19:24:43 -0600 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,HTML_20_30,HTML_MESSAGE autolearn=no version=2.60 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3F362.7D9EBB08 Content-Type: text/plain; charset="iso-8859-1" Quoting the subject draft Section 6.2 entitled "The Direction Attribute" The count is used to determine if a new connection is required in future SDP exchanges for a given stream. For the initial SDP exchange, the count pamameter MUST be set to zero. Endpoints sending a new offer related to an existing stream MUST increment this count from the value in the most recent successful exchange for the stream. The last paragraph needs to be split in 2 parts; one to cover the case, for which the count *MUST* be incremented, when the new offer requires a new TCP connection, the second covers the case where no new connection is required and in that case the count *MUST NOT* be incremented. While the above is stated later in this document (section 6.6), it is not clear from the above the section (section 6.2) and where the count is introduced for the first time in the first draft. Rgds/gf Ericsson Canada This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. ------_=_NextPart_001_01C3F362.7D9EBB08 Content-Type: text/html; charset="iso-8859-1"
Quoting the subject draft Section 6.2 entitled  "The Direction Attribute"
 
 The count is used to determine if a new connection is required in
   future SDP exchanges for a given stream. For the initial SDP
   exchange, the count pamameter MUST be set to zero. Endpoints sending
   a new offer related to an existing stream MUST increment this count
   from the value in the most recent successful exchange for the stream.
 
The last paragraph needs to be split in 2 parts;  one to cover the case, for which the count *MUST* be incremented, when the new offer requires a new TCP connection, the second covers the case where no new connection is required and in that case the count *MUST NOT* be incremented.
 
While the above is stated later in this document (section 6.6), it is not clear from the above the section (section 6.2) and where the count is introduced for the first time in the first draft.
 
Rgds/gf
 
Ericsson Canada
 



This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. ------_=_NextPart_001_01C3F362.7D9EBB08-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Sat Feb 14 23:41: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 XAA12629 for ; Sat, 14 Feb 2004 23:41:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsE5c-0005AN-00 for simple-archive@ietf.org; Sat, 14 Feb 2004 23:41:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsE4d-00057X-00 for simple-archive@ietf.org; Sat, 14 Feb 2004 23:40:08 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AsE3h-000555-00; Sat, 14 Feb 2004 23:39:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsE3Y-0008Pa-QX; Sat, 14 Feb 2004 23:39:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsE2k-0008Ng-89 for simple@optimus.ietf.org; Sat, 14 Feb 2004 23:38:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12574 for ; Sat, 14 Feb 2004 23:38:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsE2i-00052H-00 for simple@ietf.org; Sat, 14 Feb 2004 23:38:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsE1n-000502-00 for simple@ietf.org; Sat, 14 Feb 2004 23:37:12 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AsE1F-0004ul-00; Sat, 14 Feb 2004 23:36:37 -0500 Received: from dynamicsoft.com ([63.113.46.68]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i1F4aDNr004552; Sat, 14 Feb 2004 23:36:13 -0500 (EST) Message-ID: <402EF735.9040302@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: Orit Levin CC: Markus.Isomaki@nokia.com, xcon@ietf.org, hisham.khartabil@nokia.com, simple@ietf.org Subject: Re: [Simple] Re: [XCON] "Many users in a single operation" Requirements 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: Sat, 14 Feb 2004 23:36:05 -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=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Orit Levin wrote: > XCAP was introduced and designed (as its name says: "XML Configuration > Access Protocol") as a LIGHT way CONFIGURATION protocol. As a result, by > design it doesn't address close-to-real-time dynamic data manipulations. I'm not sure what you mean by that. If I add a buddy to my buddy list with xcap, that change happens in real time. > You can perform any rich atomic operation you need, but in order to do > so, you will need to be (preferably) the only owner of the data, to > upload the whole data sub-tree, change it locally, and then PUT it back. XCAP most certainly allows multiple users to manipulate the data. It is not optimized for this case, no doubt, as the etag is over the entire document, so that two users manipulating separate parts will require each to syncrhonize on the changes made by the other before making their own change. > > I think it is a mistake to stretch XCAP functionality beyond this. > I think it is a mistake to position XCAP as the (only) protocol for all > kinds of dynamic operations neither for presence nor for conferencing. dynamic operations? Can you clarify what you mean? -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 Sat Feb 14 23:41: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 XAA12702 for ; Sat, 14 Feb 2004 23:41:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsE5f-0000EI-GY for simple-archive@odin.ietf.org; Sat, 14 Feb 2004 23:41:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1F4fBg9000876 for simple-archive@odin.ietf.org; Sat, 14 Feb 2004 23:41:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsE5f-0000E2-Ce for simple-web-archive@optimus.ietf.org; Sat, 14 Feb 2004 23:41:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12647 for ; Sat, 14 Feb 2004 23:41:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsE5d-0005AS-00 for simple-web-archive@ietf.org; Sat, 14 Feb 2004 23:41:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsE4e-00057k-00 for simple-web-archive@ietf.org; Sat, 14 Feb 2004 23:40:09 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AsE3h-000555-00; Sat, 14 Feb 2004 23:39:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsE3Y-0008Pa-QX; Sat, 14 Feb 2004 23:39:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsE2k-0008Ng-89 for simple@optimus.ietf.org; Sat, 14 Feb 2004 23:38:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12574 for ; Sat, 14 Feb 2004 23:38:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsE2i-00052H-00 for simple@ietf.org; Sat, 14 Feb 2004 23:38:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsE1n-000502-00 for simple@ietf.org; Sat, 14 Feb 2004 23:37:12 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AsE1F-0004ul-00; Sat, 14 Feb 2004 23:36:37 -0500 Received: from dynamicsoft.com ([63.113.46.68]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i1F4aDNr004552; Sat, 14 Feb 2004 23:36:13 -0500 (EST) Message-ID: <402EF735.9040302@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: Orit Levin CC: Markus.Isomaki@nokia.com, xcon@ietf.org, hisham.khartabil@nokia.com, simple@ietf.org Subject: Re: [Simple] Re: [XCON] "Many users in a single operation" Requirements 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: Sat, 14 Feb 2004 23:36:05 -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=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Orit Levin wrote: > XCAP was introduced and designed (as its name says: "XML Configuration > Access Protocol") as a LIGHT way CONFIGURATION protocol. As a result, by > design it doesn't address close-to-real-time dynamic data manipulations. I'm not sure what you mean by that. If I add a buddy to my buddy list with xcap, that change happens in real time. > You can perform any rich atomic operation you need, but in order to do > so, you will need to be (preferably) the only owner of the data, to > upload the whole data sub-tree, change it locally, and then PUT it back. XCAP most certainly allows multiple users to manipulate the data. It is not optimized for this case, no doubt, as the etag is over the entire document, so that two users manipulating separate parts will require each to syncrhonize on the changes made by the other before making their own change. > > I think it is a mistake to stretch XCAP functionality beyond this. > I think it is a mistake to position XCAP as the (only) protocol for all > kinds of dynamic operations neither for presence nor for conferencing. dynamic operations? Can you clarify what you mean? -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 Sat Feb 14 23:42: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 XAA12722 for ; Sat, 14 Feb 2004 23:42:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsE6a-0005EC-00 for simple-archive@ietf.org; Sat, 14 Feb 2004 23:42:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsE5d-0005AX-00 for simple-archive@ietf.org; Sat, 14 Feb 2004 23:41:09 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AsE4f-00057t-00; Sat, 14 Feb 2004 23:40:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsE4Z-000077-PF; Sat, 14 Feb 2004 23:40:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsE3k-0008Qt-Jd for simple@optimus.ietf.org; Sat, 14 Feb 2004 23:39:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12589 for ; Sat, 14 Feb 2004 23:39:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsE3i-00055C-00 for simple@ietf.org; Sat, 14 Feb 2004 23:39:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsE2m-000530-00 for simple@ietf.org; Sat, 14 Feb 2004 23:38:12 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AsE2K-00050F-00 for simple@ietf.org; Sat, 14 Feb 2004 23:37:44 -0500 Received: from dynamicsoft.com ([63.113.46.68]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i1F4bMNr004555; Sat, 14 Feb 2004 23:37:22 -0500 (EST) Message-ID: <402EF77A.6020604@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: "Drage, Keith (Keith)" CC: simple@ietf.org Subject: Re: [Simple] Re: [XCON] "Many users in a single operation" Requir ements References: <475FF955A05DD411980D00508B6D5FB00B1B2152@en0033exch001u.uk.lucent.com> In-Reply-To: <475FF955A05DD411980D00508B6D5FB00B1B2152@en0033exch001u.uk.lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 14 Feb 2004 23:37:14 -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=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Drage, Keith (Keith) wrote: > Can I suggest that such a proposal is not a "revision" but is a > separate document identifying what enhancements and changes would be > required to the xcap documentation. OK. In fact, it is looking like I will not have time to make this change in any case before the deadline. So, the draft I will submit will not allow this. I can do a revision after the deadline, which I can make available to the list, which demonstrates what the change would look like. -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 Sat Feb 14 23:42: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 XAA12760 for ; Sat, 14 Feb 2004 23:42:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsE6d-0000FD-Ac for simple-archive@odin.ietf.org; Sat, 14 Feb 2004 23:42:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1F4gBAC000932 for simple-archive@odin.ietf.org; Sat, 14 Feb 2004 23:42:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsE6d-0000Ew-7Q for simple-web-archive@optimus.ietf.org; Sat, 14 Feb 2004 23:42:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12740 for ; Sat, 14 Feb 2004 23:42:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsE6b-0005EH-00 for simple-web-archive@ietf.org; Sat, 14 Feb 2004 23:42:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsE5e-0005Ae-00 for simple-web-archive@ietf.org; Sat, 14 Feb 2004 23:41:10 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AsE4f-00057t-00; Sat, 14 Feb 2004 23:40:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsE4Z-000077-PF; Sat, 14 Feb 2004 23:40:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsE3k-0008Qt-Jd for simple@optimus.ietf.org; Sat, 14 Feb 2004 23:39:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12589 for ; Sat, 14 Feb 2004 23:39:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsE3i-00055C-00 for simple@ietf.org; Sat, 14 Feb 2004 23:39:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsE2m-000530-00 for simple@ietf.org; Sat, 14 Feb 2004 23:38:12 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AsE2K-00050F-00 for simple@ietf.org; Sat, 14 Feb 2004 23:37:44 -0500 Received: from dynamicsoft.com ([63.113.46.68]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i1F4bMNr004555; Sat, 14 Feb 2004 23:37:22 -0500 (EST) Message-ID: <402EF77A.6020604@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: "Drage, Keith (Keith)" CC: simple@ietf.org Subject: Re: [Simple] Re: [XCON] "Many users in a single operation" Requir ements References: <475FF955A05DD411980D00508B6D5FB00B1B2152@en0033exch001u.uk.lucent.com> In-Reply-To: <475FF955A05DD411980D00508B6D5FB00B1B2152@en0033exch001u.uk.lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 14 Feb 2004 23:37:14 -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=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Drage, Keith (Keith) wrote: > Can I suggest that such a proposal is not a "revision" but is a > separate document identifying what enhancements and changes would be > required to the xcap documentation. OK. In fact, it is looking like I will not have time to make this change in any case before the deadline. So, the draft I will submit will not allow this. I can do a revision after the deadline, which I can make available to the list, which demonstrates what the change would look like. -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 Sun Feb 15 02:29:16 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29052 for ; Sun, 15 Feb 2004 02:29:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsGiJ-0006ZX-00 for simple-archive@ietf.org; Sun, 15 Feb 2004 02:29:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsGhL-0006XC-00 for simple-archive@ietf.org; Sun, 15 Feb 2004 02:28:16 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AsGhF-0006Uk-00; Sun, 15 Feb 2004 02:28:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsGh9-0000am-IM; Sun, 15 Feb 2004 02:28:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsGgR-0000Q1-4c for simple@optimus.ietf.org; Sun, 15 Feb 2004 02:27:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28921 for ; Sun, 15 Feb 2004 02:27:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsGgN-0006UI-00 for simple@ietf.org; Sun, 15 Feb 2004 02:27:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsGfP-0006S9-00 for simple@ietf.org; Sun, 15 Feb 2004 02:26:16 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AsGfD-0006Pi-00 for simple@ietf.org; Sun, 15 Feb 2004 02:26:03 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 14 Feb 2004 23:34:32 +0000 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i1F7PWuA001229 for ; Sat, 14 Feb 2004 23:25:33 -0800 (PST) Received: from [10.0.1.3] (rtp-vpn1-45.cisco.com [10.82.224.45]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AMJ52117; Sat, 14 Feb 2004 23:25:31 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.4.030702.0 From: Cullen Jennings To: Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Updated draft on IM addresses in vCards Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.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, 14 Feb 2004 23:25:31 -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.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit I just updated a draft on saving IMPP style addresses in vCards. Until it shows up in the drafts directory, you can find it at: http://www.employees.org/~fluffy/ietf/draft-jennings-impp-vcard-02.html (or .txt) Not directly related to SIMPLE but I thought some of the folks here might be interested. Thanks, Cullen _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Sun Feb 15 02:29:49 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 CAA29106 for ; Sun, 15 Feb 2004 02:29:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsGiP-00014v-9b for simple-archive@odin.ietf.org; Sun, 15 Feb 2004 02:29:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1F7TLIG004117 for simple-archive@odin.ietf.org; Sun, 15 Feb 2004 02:29:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsGiN-00014K-KT for simple-web-archive@optimus.ietf.org; Sun, 15 Feb 2004 02:29:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29067 for ; Sun, 15 Feb 2004 02:29:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsGiJ-0006Zc-00 for simple-web-archive@ietf.org; Sun, 15 Feb 2004 02:29:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsGhM-0006XK-00 for simple-web-archive@ietf.org; Sun, 15 Feb 2004 02:28:17 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AsGhF-0006Uk-00; Sun, 15 Feb 2004 02:28:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsGh9-0000am-IM; Sun, 15 Feb 2004 02:28:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsGgR-0000Q1-4c for simple@optimus.ietf.org; Sun, 15 Feb 2004 02:27:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28921 for ; Sun, 15 Feb 2004 02:27:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsGgN-0006UI-00 for simple@ietf.org; Sun, 15 Feb 2004 02:27:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsGfP-0006S9-00 for simple@ietf.org; Sun, 15 Feb 2004 02:26:16 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AsGfD-0006Pi-00 for simple@ietf.org; Sun, 15 Feb 2004 02:26:03 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 14 Feb 2004 23:34:32 +0000 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i1F7PWuA001229 for ; Sat, 14 Feb 2004 23:25:33 -0800 (PST) Received: from [10.0.1.3] (rtp-vpn1-45.cisco.com [10.82.224.45]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AMJ52117; Sat, 14 Feb 2004 23:25:31 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.4.030702.0 From: Cullen Jennings To: Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Updated draft on IM addresses in vCards Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.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, 14 Feb 2004 23:25:31 -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.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I just updated a draft on saving IMPP style addresses in vCards. Until it shows up in the drafts directory, you can find it at: http://www.employees.org/~fluffy/ietf/draft-jennings-impp-vcard-02.html (or .txt) Not directly related to SIMPLE but I thought some of the folks here might be interested. Thanks, Cullen _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Sun Feb 15 02:50:21 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00454 for ; Sun, 15 Feb 2004 02:50:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsH2i-0000Q1-00 for simple-archive@ietf.org; Sun, 15 Feb 2004 02:50:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsH1U-0000A5-00 for simple-archive@ietf.org; Sun, 15 Feb 2004 02:49:06 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AsGzX-0007dn-00; Sun, 15 Feb 2004 02:47:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsGzV-0003VR-V1; Sun, 15 Feb 2004 02:47:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsGyp-0003SK-Fh for simple@optimus.ietf.org; Sun, 15 Feb 2004 02:46:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29899 for ; Sun, 15 Feb 2004 02:46:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsGyj-0007WL-00 for simple@ietf.org; Sun, 15 Feb 2004 02:46:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsGxl-0007S3-00 for simple@ietf.org; Sun, 15 Feb 2004 02:45:14 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AsGwn-0007O2-00 for simple@ietf.org; Sun, 15 Feb 2004 02:44:13 -0500 Received: from dynamicsoft.com ([63.113.46.68]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i1F7hpNr004602 for ; Sun, 15 Feb 2004 02:43:52 -0500 (EST) Message-ID: <402F232F.3030600@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] Updated XCAP specification Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 15 Feb 2004 02:43:43 -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=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Folks, I've just submitted an update to the main xcap spec. Until it appears in the archives, you can pick up a copy at: http://www.jdrosen.net/papers/draft-ietf-simple-xcap-02.txt Here are the differences from the previous version: * MIME type for element PUTs and GETs is now defined as application/xml-fragment-body. Did not include proposed "root" type - wasnt clear why it was needed. The root is known by the requesting client. * MIME type for attribute PUT and GETs is now defined as application/xml-attribute-value and is just the value, not the attribute name. * combined the create and replace document, element and attribute sections into one section each * when the server gets a PUT request to create a new element, clarified that, if the parent of that element does not exist, the server returns a 409. Similarly for an attribute creation. This case was formerly described as "if the server needs to create additional content in order to perform the insertion, return a 409". This was too vague. * defined the default authorization policy for resources in the global tree - read can be done by all users, write only by priviledged administrators. * clarified that you cannot select comments, processing instructions, text content or namespace attributes with a URI. * clarified that the response to a PUT is a 200 OK with no content. * Etag behavior has completely changed. Now, the server maintains a single etag for the document. Any sub-component will share that etag. * Add text to clarify that, in the case of data dependencies, if the client wants to find out the data computed by the server, it needs to do a subsequent GET, or use the xcap event package. Also clarified that the server is responsible for computing this data after a PUT, and responsible for changing the etag. * In the introduction, clarified that resource lists were useful for list subscriptions as one example use case, and another use case was to allow a user to log in to different clients and still have access to their buddy list. * Clarified that the URI hierarchy defined in the spec is a MUST to implement by servers. I.e., its not a recommended document storage structure. * Defined an XML body that can be included in a 409 that indicates specific details about the reason for the conflict. This body is optional. One of the cases it covers is if the users is trying to create an element or document that requires a URI within the document to be unique (for example, a resource list URI), but the proposed URI exists. The error body indicates the URI(s) which exist, and can also suggest alternates. * The client behavior sections now detail error handling procedures. These are provided only for the 409 case, and in particular, it states that the body of the 409 may be there, providing additional information to assist the client in a retry. * The XCAP URI no longer separates the document URI from the node selector through a query ("?"). Rather, the path of the URI extends naturally from the document down into the content of the document. As per discussion in Minneapolis, this was done since it was anticipated that HTTP server infrastructure would have trouble handling HTTP GET operations for resources containing query strings. * Restructured the section on application usages * Added a discussion of how to extend the schema for an application usage. It is now possible for a server to process a document without understanding all of its namespaces and schemas; it only needs to understand the application usage. The equivalent of the SIP "Require" functionality is now defined through an XML element called "mandatory-ns" that is optionally included in a document. When present, it indicates the namespaces that must be understood by the server in order to process the document. Comments and questions welcome. In particular, I'd like to know whether people are happy with the two most major changes, (1) the usage of the XML document in 409, (2) the ability of the server to process documents without understanding all of its namespaces. There arent any major open issues at this point. The following are the minor open issues I am aware of: * For the XML fragment body and XML attribute value MIME types - do they need to use the +xml convention in RFC 3023? Neither of these are valid XML documents per se. I think the answer is no. Other opinions welcome. * The specification requires that a server uses the same etag across all resources that point to the same document. Whilst this is allowed per se by HTTP 1.1, it feels ugly. Is there anything we can do about it? * Knowing the contents of a directory - how to do it? Separate package? This is being discussed in a separate thread. * Is there a more efficient way to find out server assigned URIs? Right now, its a separate GET after the PUT completes. 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 Sun Feb 15 02:50:54 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 CAA00523 for ; Sun, 15 Feb 2004 02:50:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsH2o-0003ym-53 for simple-archive@odin.ietf.org; Sun, 15 Feb 2004 02:50:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1F7oQWJ015293 for simple-archive@odin.ietf.org; Sun, 15 Feb 2004 02:50:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsH2n-0003yZ-Bc for simple-web-archive@optimus.ietf.org; Sun, 15 Feb 2004 02:50:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00466 for ; Sun, 15 Feb 2004 02:50:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsH2j-0000QK-00 for simple-web-archive@ietf.org; Sun, 15 Feb 2004 02:50:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsH1W-0000AE-00 for simple-web-archive@ietf.org; Sun, 15 Feb 2004 02:49:07 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AsGzX-0007dn-00; Sun, 15 Feb 2004 02:47:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsGzV-0003VR-V1; Sun, 15 Feb 2004 02:47:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsGyp-0003SK-Fh for simple@optimus.ietf.org; Sun, 15 Feb 2004 02:46:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29899 for ; Sun, 15 Feb 2004 02:46:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsGyj-0007WL-00 for simple@ietf.org; Sun, 15 Feb 2004 02:46:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsGxl-0007S3-00 for simple@ietf.org; Sun, 15 Feb 2004 02:45:14 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AsGwn-0007O2-00 for simple@ietf.org; Sun, 15 Feb 2004 02:44:13 -0500 Received: from dynamicsoft.com ([63.113.46.68]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i1F7hpNr004602 for ; Sun, 15 Feb 2004 02:43:52 -0500 (EST) Message-ID: <402F232F.3030600@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] Updated XCAP specification Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 15 Feb 2004 02:43:43 -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=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Folks, I've just submitted an update to the main xcap spec. Until it appears in the archives, you can pick up a copy at: http://www.jdrosen.net/papers/draft-ietf-simple-xcap-02.txt Here are the differences from the previous version: * MIME type for element PUTs and GETs is now defined as application/xml-fragment-body. Did not include proposed "root" type - wasnt clear why it was needed. The root is known by the requesting client. * MIME type for attribute PUT and GETs is now defined as application/xml-attribute-value and is just the value, not the attribute name. * combined the create and replace document, element and attribute sections into one section each * when the server gets a PUT request to create a new element, clarified that, if the parent of that element does not exist, the server returns a 409. Similarly for an attribute creation. This case was formerly described as "if the server needs to create additional content in order to perform the insertion, return a 409". This was too vague. * defined the default authorization policy for resources in the global tree - read can be done by all users, write only by priviledged administrators. * clarified that you cannot select comments, processing instructions, text content or namespace attributes with a URI. * clarified that the response to a PUT is a 200 OK with no content. * Etag behavior has completely changed. Now, the server maintains a single etag for the document. Any sub-component will share that etag. * Add text to clarify that, in the case of data dependencies, if the client wants to find out the data computed by the server, it needs to do a subsequent GET, or use the xcap event package. Also clarified that the server is responsible for computing this data after a PUT, and responsible for changing the etag. * In the introduction, clarified that resource lists were useful for list subscriptions as one example use case, and another use case was to allow a user to log in to different clients and still have access to their buddy list. * Clarified that the URI hierarchy defined in the spec is a MUST to implement by servers. I.e., its not a recommended document storage structure. * Defined an XML body that can be included in a 409 that indicates specific details about the reason for the conflict. This body is optional. One of the cases it covers is if the users is trying to create an element or document that requires a URI within the document to be unique (for example, a resource list URI), but the proposed URI exists. The error body indicates the URI(s) which exist, and can also suggest alternates. * The client behavior sections now detail error handling procedures. These are provided only for the 409 case, and in particular, it states that the body of the 409 may be there, providing additional information to assist the client in a retry. * The XCAP URI no longer separates the document URI from the node selector through a query ("?"). Rather, the path of the URI extends naturally from the document down into the content of the document. As per discussion in Minneapolis, this was done since it was anticipated that HTTP server infrastructure would have trouble handling HTTP GET operations for resources containing query strings. * Restructured the section on application usages * Added a discussion of how to extend the schema for an application usage. It is now possible for a server to process a document without understanding all of its namespaces and schemas; it only needs to understand the application usage. The equivalent of the SIP "Require" functionality is now defined through an XML element called "mandatory-ns" that is optionally included in a document. When present, it indicates the namespaces that must be understood by the server in order to process the document. Comments and questions welcome. In particular, I'd like to know whether people are happy with the two most major changes, (1) the usage of the XML document in 409, (2) the ability of the server to process documents without understanding all of its namespaces. There arent any major open issues at this point. The following are the minor open issues I am aware of: * For the XML fragment body and XML attribute value MIME types - do they need to use the +xml convention in RFC 3023? Neither of these are valid XML documents per se. I think the answer is no. Other opinions welcome. * The specification requires that a server uses the same etag across all resources that point to the same document. Whilst this is allowed per se by HTTP 1.1, it feels ugly. Is there anything we can do about it? * Knowing the contents of a directory - how to do it? Separate package? This is being discussed in a separate thread. * Is there a more efficient way to find out server assigned URIs? Right now, its a separate GET after the PUT completes. 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 Sun Feb 15 04:02:42 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02239 for ; Sun, 15 Feb 2004 04:02:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsIAj-0004dB-00 for simple-archive@ietf.org; Sun, 15 Feb 2004 04:02:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsI9u-0004X2-00 for simple-archive@ietf.org; Sun, 15 Feb 2004 04:01:51 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AsI9A-0004PC-00; Sun, 15 Feb 2004 04:01:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsI98-0000Aa-Li; Sun, 15 Feb 2004 04:01:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsI8e-00008v-PG for simple@optimus.ietf.org; Sun, 15 Feb 2004 04:00:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02119 for ; Sun, 15 Feb 2004 04:00:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsI8c-0004Mc-00 for simple@ietf.org; Sun, 15 Feb 2004 04:00:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsI7i-0004Gm-00 for simple@ietf.org; Sun, 15 Feb 2004 03:59:35 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AsI6s-00045f-00 for simple@ietf.org; Sun, 15 Feb 2004 03:58:42 -0500 Received: from dynamicsoft.com ([63.113.46.68]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i1F8wKNr004665 for ; Sun, 15 Feb 2004 03:58:20 -0500 (EST) Message-ID: <402F34A4.5030606@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] Updated xcap-list draft Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 15 Feb 2004 03:58:12 -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=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Folks, I've submitted an update to the xcap-list draft. Until it appears in the archives, you can pick up a copy at: http://www.jdrosen.net/papers/draft-ietf-simple-xcap-list-usage-02.txt Here are the differences from the previous version: * The draft mentions that no authorization information is provided on who can subscribe to the list. * display name element is now optional * URI attribute of entry now mandatory, and name is optional * restructured document so that its about the document format, and the XCAP usage is defined as a separate section. * added an "entry-ref" element, which can be present in a list. Its a reference to an "entry" element in this document or another. This makes it easy to define a buddy once, and then reference the information for them anytime that buddy appears in a list. There are no open issues that I am aware of. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Sun Feb 15 04:03:18 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 EAA02268 for ; Sun, 15 Feb 2004 04:03:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsIAr-0000JV-1z for simple-archive@odin.ietf.org; Sun, 15 Feb 2004 04:02:49 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1F92mGX001192 for simple-archive@odin.ietf.org; Sun, 15 Feb 2004 04:02:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsIAn-0000Iq-8Q for simple-web-archive@optimus.ietf.org; Sun, 15 Feb 2004 04:02:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02253 for ; Sun, 15 Feb 2004 04:02:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsIAk-0004dI-00 for simple-web-archive@ietf.org; Sun, 15 Feb 2004 04:02:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsI9v-0004X9-00 for simple-web-archive@ietf.org; Sun, 15 Feb 2004 04:01:52 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AsI9A-0004PC-00; Sun, 15 Feb 2004 04:01:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsI98-0000Aa-Li; Sun, 15 Feb 2004 04:01:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsI8e-00008v-PG for simple@optimus.ietf.org; Sun, 15 Feb 2004 04:00:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02119 for ; Sun, 15 Feb 2004 04:00:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsI8c-0004Mc-00 for simple@ietf.org; Sun, 15 Feb 2004 04:00:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsI7i-0004Gm-00 for simple@ietf.org; Sun, 15 Feb 2004 03:59:35 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AsI6s-00045f-00 for simple@ietf.org; Sun, 15 Feb 2004 03:58:42 -0500 Received: from dynamicsoft.com ([63.113.46.68]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i1F8wKNr004665 for ; Sun, 15 Feb 2004 03:58:20 -0500 (EST) Message-ID: <402F34A4.5030606@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] Updated xcap-list draft Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 15 Feb 2004 03:58:12 -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=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Folks, I've submitted an update to the xcap-list draft. Until it appears in the archives, you can pick up a copy at: http://www.jdrosen.net/papers/draft-ietf-simple-xcap-list-usage-02.txt Here are the differences from the previous version: * The draft mentions that no authorization information is provided on who can subscribe to the list. * display name element is now optional * URI attribute of entry now mandatory, and name is optional * restructured document so that its about the document format, and the XCAP usage is defined as a separate section. * added an "entry-ref" element, which can be present in a list. Its a reference to an "entry" element in this document or another. This makes it easy to define a buddy once, and then reference the information for them anytime that buddy appears in a list. There are no open issues that I am aware of. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Feb 16 06:02: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 GAA11115 for ; Mon, 16 Feb 2004 06:02:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsgVv-0003Kd-00 for simple-archive@ietf.org; Mon, 16 Feb 2004 06:02:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsgV2-0003I9-00 for simple-archive@ietf.org; Mon, 16 Feb 2004 06:01:17 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AsgUp-0003FL-00; Mon, 16 Feb 2004 06:01:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsgUm-0004fB-Pr; Mon, 16 Feb 2004 06:01:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsgU0-0004dd-Fv for simple@optimus.ietf.org; Mon, 16 Feb 2004 06:00:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11037 for ; Mon, 16 Feb 2004 06:00:08 -0500 (EST) From: mikko.lonnfors@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsgTw-0003DH-00 for simple@ietf.org; Mon, 16 Feb 2004 06:00:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsgSy-00038B-00 for simple@ietf.org; Mon, 16 Feb 2004 05:59:09 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AsgRz-00034S-00 for simple@ietf.org; Mon, 16 Feb 2004 05:58:07 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1GAw8312071 for ; Mon, 16 Feb 2004 12:58:08 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 16 Feb 2004 12:58:08 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 16 Feb 2004 12:58:06 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 16 Feb 2004 12:58:06 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] I-D ACTION:draft-ietf-simple-prescaps-ext-00.txt Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF01C1DD4A@esebe004.ntc.nokia.com> Thread-Topic: [Simple] I-D ACTION:draft-ietf-simple-prescaps-ext-00.txt Thread-Index: AcPvUwLbh/1FhXbXRM+6a+k4Z3nuXQB7ZOXQ To: X-OriginalArrivalTime: 16 Feb 2004 10:58:06.0958 (UTC) FILETIME=[C20220E0:01C3F47B] 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, 16 Feb 2004 12:58:06 +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.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Hi, Here is the list of changes that have been made to prescaps: - Added negated attribute to all elements where it makes sense. Current version has a bug is sections where it describes how 'negated' attribute is used. So when reading current text:=20 "Value 'true' indicates that device supports audio media type and value 'false' indicates that device does not support audio media type as defined in [6]"=20 please replace 'true' with false and 'false' with true. Example: - elements can now be used inside media feature tags (