From mailman-admin@ietf.org Fri Aug 1 10:10:26 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18927 for ; Fri, 1 Aug 2003 09:38:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iZpM-0006Qj-00 for simple-archive@ietf.org; Fri, 01 Aug 2003 09:20:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19iZmv-0005sW-00 for simple-archive@ietf.org; Fri, 01 Aug 2003 09:17:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iZaE-00066X-U8 for simple-archive@ietf.org; Fri, 01 Aug 2003 09:04:34 -0400 Date: Fri, 01 Aug 2003 09:04:34 -0400 Message-ID: <20030801130434.29120.45154.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 This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, simple-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. *************************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. *************************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. Thanks! Passwords for simple-archive@ietf.org: List Password // URL ---- -------- simple@ietf.org onahda https://www1.ietf.org/mailman/options/simple/simple-archive%40ietf.org From simple-admin@ietf.org Fri Aug 1 11:21:02 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26253; Fri, 1 Aug 2003 11:21:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ibiL-0003JX-00; Fri, 01 Aug 2003 11:21:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ibiK-0003JU-00; Fri, 01 Aug 2003 11:21:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ibiI-0007Lf-Id; Fri, 01 Aug 2003 11:21:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ibhx-0007Kx-MH for simple@optimus.ietf.org; Fri, 01 Aug 2003 11:20:41 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26219; Fri, 1 Aug 2003 11:20:37 -0400 (EDT) Message-Id: <200308011520.LAA26219@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-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, 01 Aug 2003 11:20:37 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : RPID -- Rich Presence Information Data Format Author(s) : H. Schulzrinne Filename : draft-ietf-simple-rpid-00.txt Pages : 19 Date : 2003-7-31 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-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-rpid-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-rpid-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-7-31150622.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-rpid-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-rpid-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-31150622.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 Aug 1 11:21:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26294 for ; Fri, 1 Aug 2003 11:21:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ibiM-0007N6-M3 for simple-archive@odin.ietf.org; Fri, 01 Aug 2003 11:21:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h71FL60o028332 for simple-archive@odin.ietf.org; Fri, 1 Aug 2003 11:21:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ibiM-0007Mt-J9 for simple-web-archive@optimus.ietf.org; Fri, 01 Aug 2003 11:21:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26253; Fri, 1 Aug 2003 11:21:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ibiL-0003JX-00; Fri, 01 Aug 2003 11:21:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ibiK-0003JU-00; Fri, 01 Aug 2003 11:21:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ibiI-0007Lf-Id; Fri, 01 Aug 2003 11:21:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ibhx-0007Kx-MH for simple@optimus.ietf.org; Fri, 01 Aug 2003 11:20:41 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26219; Fri, 1 Aug 2003 11:20:37 -0400 (EDT) Message-Id: <200308011520.LAA26219@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-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, 01 Aug 2003 11:20:37 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : RPID -- Rich Presence Information Data Format Author(s) : H. Schulzrinne Filename : draft-ietf-simple-rpid-00.txt Pages : 19 Date : 2003-7-31 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-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-rpid-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-rpid-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-7-31150622.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-rpid-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-rpid-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-31150622.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 Aug 1 14:03:01 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02644 for ; Fri, 1 Aug 2003 14:03:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ieEe-0005Wz-Lc for simple-archive@odin.ietf.org; Fri, 01 Aug 2003 14:02:36 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h71I2aYM021248 for simple-archive@odin.ietf.org; Fri, 1 Aug 2003 14:02:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iac5-0005Fl-TY for simple-web-archive@optimus.ietf.org; Fri, 01 Aug 2003 10:10:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16913 for ; Fri, 1 Aug 2003 09:35:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iZyf-0000B5-00 for simple-web-archive@ietf.org; Fri, 01 Aug 2003 09:29:49 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19iZmh-0005qi-00 for simple-web-archive@ietf.org; Fri, 01 Aug 2003 09:17:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iZd7-00021i-3Z for simple-web-archive@ietf.org; Fri, 01 Aug 2003 09:07:33 -0400 Date: Fri, 01 Aug 2003 09:07:33 -0400 Message-ID: <20030801130733.29120.20022.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 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 Sun Aug 3 05:08:05 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12987; Sun, 3 Aug 2003 05:08:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jEqV-00008C-00; Sun, 03 Aug 2003 05:08:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19jEqV-000087-00; Sun, 03 Aug 2003 05:08:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jEqP-0008K8-46; Sun, 03 Aug 2003 05:08:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jEpt-0008El-FR for simple@optimus.ietf.org; Sun, 03 Aug 2003 05:07:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12980 for ; Sun, 3 Aug 2003 05:07:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jEpq-000084-00 for simple@ietf.org; Sun, 03 Aug 2003 05:07:26 -0400 Received: from [80.74.106.10] (helo=nt-mail.radvision.com) by ietf-mx with esmtp (Exim 4.12) id 19jEpp-000080-00 for simple@ietf.org; Sun, 03 Aug 2003 05:07:25 -0400 Received: from nt-mail.radvision.com [172.20.2.100] by nt-mail.radvision.com with XWall v3.26 ; Sun, 3 Aug 2003 12:05:41 +0300 Received: by nt-mail.radvision.com with Internet Mail Service (5.5.2653.19) id ; Sun, 3 Aug 2003 12:05:40 +0300 Message-ID: <99FF181D4C99564F8D623069E1DDB25E3B89D2@nt-mail.radvision.com> From: Orly Rosenberg To: "'simple@ietf.org'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="windows-1255" Subject: [Simple] Question about the Waiting state Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.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, 3 Aug 2003 12:05:40 +0300 Hi. According to winfo-package-05: "If, while in the waiting state, the subscription is refreshed through another Subscribe, it moves back into the pending state". Also in the Subscription state-machine as defined in section 4.7.1, there is a transition from state waiting to state pending in case of an incoming Subscribe. My question is: How is it possible to handle a refresh request in the Waiting state, after we already sent a Notify(terminated)? (when the state changed from Pending to Terminated). From what I understand, the Waiting state is an internal state, but the real subscription has terminated. If so, how can we change its state back to pending? Thanks, Orly Rosenberg. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Sun Aug 3 05:08:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13020 for ; Sun, 3 Aug 2003 05:08:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jEqZ-0008Ot-Ke for simple-archive@odin.ietf.org; Sun, 03 Aug 2003 05:08:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7398B0F032285 for simple-archive@odin.ietf.org; Sun, 3 Aug 2003 05:08:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jEqZ-0008Oe-9l for simple-web-archive@optimus.ietf.org; Sun, 03 Aug 2003 05:08:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12987; Sun, 3 Aug 2003 05:08:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jEqV-00008C-00; Sun, 03 Aug 2003 05:08:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19jEqV-000087-00; Sun, 03 Aug 2003 05:08:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jEqP-0008K8-46; Sun, 03 Aug 2003 05:08:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jEpt-0008El-FR for simple@optimus.ietf.org; Sun, 03 Aug 2003 05:07:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12980 for ; Sun, 3 Aug 2003 05:07:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jEpq-000084-00 for simple@ietf.org; Sun, 03 Aug 2003 05:07:26 -0400 Received: from [80.74.106.10] (helo=nt-mail.radvision.com) by ietf-mx with esmtp (Exim 4.12) id 19jEpp-000080-00 for simple@ietf.org; Sun, 03 Aug 2003 05:07:25 -0400 Received: from nt-mail.radvision.com [172.20.2.100] by nt-mail.radvision.com with XWall v3.26 ; Sun, 3 Aug 2003 12:05:41 +0300 Received: by nt-mail.radvision.com with Internet Mail Service (5.5.2653.19) id ; Sun, 3 Aug 2003 12:05:40 +0300 Message-ID: <99FF181D4C99564F8D623069E1DDB25E3B89D2@nt-mail.radvision.com> From: Orly Rosenberg To: "'simple@ietf.org'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="windows-1255" Subject: [Simple] Question about the Waiting state Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.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, 3 Aug 2003 12:05:40 +0300 Hi. According to winfo-package-05: "If, while in the waiting state, the subscription is refreshed through another Subscribe, it moves back into the pending state". Also in the Subscription state-machine as defined in section 4.7.1, there is a transition from state waiting to state pending in case of an incoming Subscribe. My question is: How is it possible to handle a refresh request in the Waiting state, after we already sent a Notify(terminated)? (when the state changed from Pending to Terminated). From what I understand, the Waiting state is an internal state, but the real subscription has terminated. If so, how can we change its state back to pending? Thanks, Orly Rosenberg. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Aug 4 00:35:06 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA04425; Mon, 4 Aug 2003 00:35:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jX3u-0005zI-00; Mon, 04 Aug 2003 00:35:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19jX3t-0005zF-00; Mon, 04 Aug 2003 00:35:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jX3l-0007Ai-D3; Mon, 04 Aug 2003 00:35:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jX3a-0007AI-HJ for simple@optimus.ietf.org; Mon, 04 Aug 2003 00:34:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA04414 for ; Mon, 4 Aug 2003 00:34:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jX3X-0005z0-00 for simple@ietf.org; Mon, 04 Aug 2003 00:34:47 -0400 Received: from [203.110.148.148] (helo=a-start.start.syd) by ietf-mx with esmtp (Exim 4.12) id 19jX3W-0005yq-00 for simple@ietf.org; Mon, 04 Aug 2003 00:34:46 -0400 Subject: RE: [Simple] Question about the Waiting state MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Message-ID: <0EB17E926D035949A09C0F4CD5E9D7732EFFC1@a-start.start.syd> X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message Thread-Topic: [Simple] Question about the Waiting state Thread-Index: AcNZnashRi5qRbnNRQeYkErJ1jNtZwAosx1Q From: "Stephen Gryphon" To: "Orly Rosenberg" , 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, 4 Aug 2003 14:25:55 +1000 Content-Transfer-Encoding: quoted-printable Test message 1 > -----Original Message----- > From: Orly Rosenberg [mailto:Orly@radvision.com] > Sent: Sunday, August 03, 2003 7:06 PM > To: 'simple@ietf.org' > Subject: [Simple] Question about the Waiting state >=20 >=20 > Hi. >=20 > According to winfo-package-05:=20 > "If, while in the waiting state, the subscription is refreshed through > another Subscribe, it moves back into the pending state". >=20 > Also in the Subscription state-machine as defined in section=20 > 4.7.1, there is > a transition from state waiting to state pending in case of=20 > an incoming > Subscribe. >=20 > My question is: > How is it possible to handle a refresh request in the Waiting=20 > state, after > we already sent a Notify(terminated)? (when the state changed=20 > from Pending > to Terminated). > From what I understand, the Waiting state is an internal=20 > state, but the real > subscription has terminated. > If so, how can we change its state back to pending? >=20 > Thanks, > Orly Rosenberg. >=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 Aug 4 00:35:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA04446 for ; Mon, 4 Aug 2003 00:35:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jX3x-0007BQ-GP for simple-archive@odin.ietf.org; Mon, 04 Aug 2003 00:35:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h744ZDB9027611 for simple-archive@odin.ietf.org; Mon, 4 Aug 2003 00:35:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jX3x-0007BG-9p for simple-web-archive@optimus.ietf.org; Mon, 04 Aug 2003 00:35:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA04425; Mon, 4 Aug 2003 00:35:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jX3u-0005zI-00; Mon, 04 Aug 2003 00:35:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19jX3t-0005zF-00; Mon, 04 Aug 2003 00:35:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jX3l-0007Ai-D3; Mon, 04 Aug 2003 00:35:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jX3a-0007AI-HJ for simple@optimus.ietf.org; Mon, 04 Aug 2003 00:34:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA04414 for ; Mon, 4 Aug 2003 00:34:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jX3X-0005z0-00 for simple@ietf.org; Mon, 04 Aug 2003 00:34:47 -0400 Received: from [203.110.148.148] (helo=a-start.start.syd) by ietf-mx with esmtp (Exim 4.12) id 19jX3W-0005yq-00 for simple@ietf.org; Mon, 04 Aug 2003 00:34:46 -0400 Subject: RE: [Simple] Question about the Waiting state MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Message-ID: <0EB17E926D035949A09C0F4CD5E9D7732EFFC1@a-start.start.syd> X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message Thread-Topic: [Simple] Question about the Waiting state Thread-Index: AcNZnashRi5qRbnNRQeYkErJ1jNtZwAosx1Q From: "Stephen Gryphon" To: "Orly Rosenberg" , 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, 4 Aug 2003 14:25:55 +1000 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Test message 1 > -----Original Message----- > From: Orly Rosenberg [mailto:Orly@radvision.com] > Sent: Sunday, August 03, 2003 7:06 PM > To: 'simple@ietf.org' > Subject: [Simple] Question about the Waiting state >=20 >=20 > Hi. >=20 > According to winfo-package-05:=20 > "If, while in the waiting state, the subscription is refreshed through > another Subscribe, it moves back into the pending state". >=20 > Also in the Subscription state-machine as defined in section=20 > 4.7.1, there is > a transition from state waiting to state pending in case of=20 > an incoming > Subscribe. >=20 > My question is: > How is it possible to handle a refresh request in the Waiting=20 > state, after > we already sent a Notify(terminated)? (when the state changed=20 > from Pending > to Terminated). > From what I understand, the Waiting state is an internal=20 > state, but the real > subscription has terminated. > If so, how can we change its state back to pending? >=20 > Thanks, > Orly Rosenberg. >=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 Aug 4 00:43:56 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA04599; Mon, 4 Aug 2003 00:43:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jXCR-00061p-00; Mon, 04 Aug 2003 00:43:59 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19jXCR-00061m-00; Mon, 04 Aug 2003 00:43:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jXCT-0007gl-6D; Mon, 04 Aug 2003 00:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jXBh-0007fa-6a for simple@optimus.ietf.org; Mon, 04 Aug 2003 00:43:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA04592 for ; Mon, 4 Aug 2003 00:43:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jXBe-00061b-00 for simple@ietf.org; Mon, 04 Aug 2003 00:43:10 -0400 Received: from web40902.mail.yahoo.com ([66.218.78.199]) by ietf-mx with smtp (Exim 4.12) id 19jXBe-00061S-00 for simple@ietf.org; Mon, 04 Aug 2003 00:43:10 -0400 Message-ID: <20030804044241.33735.qmail@web40902.mail.yahoo.com> Received: from [203.110.148.145] by web40902.mail.yahoo.com via HTTP; Mon, 04 Aug 2003 14:42:41 EST From: =?iso-8859-1?q?Mr=20Stephen=20Gryphon?= To: simple@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Subject: [Simple] Test 2 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 4 Aug 2003 14:42:41 +1000 (EST) Content-Transfer-Encoding: 8bit test http://personals.yahoo.com.au - Yahoo! Personals - New people, new possibilities! Try Yahoo! Personals, FREE for a limited period! _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Aug 4 00:44:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA04616 for ; Mon, 4 Aug 2003 00:44:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jXCU-0007iW-Q3 for simple-archive@odin.ietf.org; Mon, 04 Aug 2003 00:44:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h744i2J7029658 for simple-archive@odin.ietf.org; Mon, 4 Aug 2003 00:44:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jXCU-0007iH-NE for simple-web-archive@optimus.ietf.org; Mon, 04 Aug 2003 00:44:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA04599; Mon, 4 Aug 2003 00:43:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jXCR-00061p-00; Mon, 04 Aug 2003 00:43:59 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19jXCR-00061m-00; Mon, 04 Aug 2003 00:43:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jXCT-0007gl-6D; Mon, 04 Aug 2003 00:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jXBh-0007fa-6a for simple@optimus.ietf.org; Mon, 04 Aug 2003 00:43:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA04592 for ; Mon, 4 Aug 2003 00:43:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jXBe-00061b-00 for simple@ietf.org; Mon, 04 Aug 2003 00:43:10 -0400 Received: from web40902.mail.yahoo.com ([66.218.78.199]) by ietf-mx with smtp (Exim 4.12) id 19jXBe-00061S-00 for simple@ietf.org; Mon, 04 Aug 2003 00:43:10 -0400 Message-ID: <20030804044241.33735.qmail@web40902.mail.yahoo.com> Received: from [203.110.148.145] by web40902.mail.yahoo.com via HTTP; Mon, 04 Aug 2003 14:42:41 EST From: =?iso-8859-1?q?Mr=20Stephen=20Gryphon?= To: simple@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Subject: [Simple] Test 2 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 4 Aug 2003 14:42:41 +1000 (EST) Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit test http://personals.yahoo.com.au - Yahoo! Personals - New people, new possibilities! Try Yahoo! Personals, FREE for a limited period! _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Aug 4 00:46:00 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA04653; Mon, 4 Aug 2003 00:46:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jXES-00062b-00; Mon, 04 Aug 2003 00:46:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19jXER-00062Y-00; Mon, 04 Aug 2003 00:46:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jXEP-0007mW-TW; Mon, 04 Aug 2003 00:46:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jXDt-0007mD-4n for simple@optimus.ietf.org; Mon, 04 Aug 2003 00:45:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA04650 for ; Mon, 4 Aug 2003 00:45:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jXDq-00062M-00 for simple@ietf.org; Mon, 04 Aug 2003 00:45:26 -0400 Received: from [203.110.148.148] (helo=a-start.start.syd) by ietf-mx with esmtp (Exim 4.12) id 19jXDo-000626-00 for simple@ietf.org; Mon, 04 Aug 2003 00:45:25 -0400 Subject: RE: [Simple] Test 2 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: <0EB17E926D035949A09C0F4CD5E9D7732EFFC2@a-start.start.syd> X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message Thread-Topic: [Simple] Test 2 Thread-Index: AcNaQeLWuZk+mySdQQ+uaXxkptFWJQAAByaA From: "Stephen Gryphon" To: "Mr Stephen Gryphon" , 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, 4 Aug 2003 14:36:39 +1000 Content-Transfer-Encoding: quoted-printable test back > -----Original Message----- > From: Mr Stephen Gryphon [mailto:stephen_gryphon@yahoo.com] > Sent: Monday, August 04, 2003 2:43 PM > To: simple@ietf.org > Subject: [Simple] Test 2 >=20 >=20 > test >=20 > http://personals.yahoo.com.au - Yahoo! Personals > - New people, new possibilities! Try Yahoo! Personals, FREE=20 > for a limited period! >=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 Aug 4 00:46:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA04670 for ; Mon, 4 Aug 2003 00:46:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jXEV-0007q1-Cu for simple-archive@odin.ietf.org; Mon, 04 Aug 2003 00:46:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h744k7Ik030123 for simple-archive@odin.ietf.org; Mon, 4 Aug 2003 00:46:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jXEV-0007pm-8x for simple-web-archive@optimus.ietf.org; Mon, 04 Aug 2003 00:46:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA04653; Mon, 4 Aug 2003 00:46:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jXES-00062b-00; Mon, 04 Aug 2003 00:46:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19jXER-00062Y-00; Mon, 04 Aug 2003 00:46:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jXEP-0007mW-TW; Mon, 04 Aug 2003 00:46:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jXDt-0007mD-4n for simple@optimus.ietf.org; Mon, 04 Aug 2003 00:45:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA04650 for ; Mon, 4 Aug 2003 00:45:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jXDq-00062M-00 for simple@ietf.org; Mon, 04 Aug 2003 00:45:26 -0400 Received: from [203.110.148.148] (helo=a-start.start.syd) by ietf-mx with esmtp (Exim 4.12) id 19jXDo-000626-00 for simple@ietf.org; Mon, 04 Aug 2003 00:45:25 -0400 Subject: RE: [Simple] Test 2 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: <0EB17E926D035949A09C0F4CD5E9D7732EFFC2@a-start.start.syd> X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message Thread-Topic: [Simple] Test 2 Thread-Index: AcNaQeLWuZk+mySdQQ+uaXxkptFWJQAAByaA From: "Stephen Gryphon" To: "Mr Stephen Gryphon" , 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, 4 Aug 2003 14:36:39 +1000 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable test back > -----Original Message----- > From: Mr Stephen Gryphon [mailto:stephen_gryphon@yahoo.com] > Sent: Monday, August 04, 2003 2:43 PM > To: simple@ietf.org > Subject: [Simple] Test 2 >=20 >=20 > test >=20 > http://personals.yahoo.com.au - Yahoo! Personals > - New people, new possibilities! Try Yahoo! Personals, FREE=20 > for a limited period! >=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 Aug 4 16:21:05 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA11082; Mon, 4 Aug 2003 16:21:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jlpL-0005Pk-00; Mon, 04 Aug 2003 16:21:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19jlpL-0005Pf-00; Mon, 04 Aug 2003 16:21:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jlpF-00043e-9w; Mon, 04 Aug 2003 16:21:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jlpC-00043M-98 for simple@optimus.ietf.org; Mon, 04 Aug 2003 16:20:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA11064 for ; Mon, 4 Aug 2003 16:20:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jlpA-0005PX-00 for simple@ietf.org; Mon, 04 Aug 2003 16:20:56 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by ietf-mx with esmtp (Exim 4.12) id 19jlp9-0005PN-00 for simple@ietf.org; Mon, 04 Aug 2003 16:20:56 -0400 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h74KKApp008121; Mon, 4 Aug 2003 13:20:10 -0700 (PDT) Received: from [128.107.170.164] ([128.107.170.164]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGT07015; Mon, 4 Aug 2003 13:20:09 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.1.2418 From: Cullen Jennings To: Robert Sparks , Message-ID: In-Reply-To: <1059580659.940.58.camel@RjS.localdomain> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] simple-message-sessions Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.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, 04 Aug 2003 13:20:08 -0700 Content-Transfer-Encoding: 7bit The notes from the SIMPLE meeting at IETF 57 have ... > Poll: Are we happy enough with the doc that we can finish the nits and > send it to IESG? Answer: Yes. I don't think this document has had the discussion it deserves. For example: the question of why this is better than just running MESSAGE over SIP on TCP has never been answered. Along with other questions - like now that there is no multiplexing, how does this provide any help whatsoever with congestion control of chat IM sessions. Right now, I have a very hard time convincing developers that there is significant value in implementing this. Perhaps I just don't get it - a few phone calls on the subject could go a long ways on at least educating some people on why this is the right thing. I don't want to slow this document down if the WG feels it is ready - it has improved greatly in the last few drafts. Just my 2 cents.... Cullen _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Aug 4 16:21:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA11106 for ; Mon, 4 Aug 2003 16:21:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jlpO-000459-An for simple-archive@odin.ietf.org; Mon, 04 Aug 2003 16:21:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h74KLAm9015687 for simple-archive@odin.ietf.org; Mon, 4 Aug 2003 16:21:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jlpO-00044w-6W for simple-web-archive@optimus.ietf.org; Mon, 04 Aug 2003 16:21:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA11082; Mon, 4 Aug 2003 16:21:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jlpL-0005Pk-00; Mon, 04 Aug 2003 16:21:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19jlpL-0005Pf-00; Mon, 04 Aug 2003 16:21:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jlpF-00043e-9w; Mon, 04 Aug 2003 16:21:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jlpC-00043M-98 for simple@optimus.ietf.org; Mon, 04 Aug 2003 16:20:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA11064 for ; Mon, 4 Aug 2003 16:20:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jlpA-0005PX-00 for simple@ietf.org; Mon, 04 Aug 2003 16:20:56 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by ietf-mx with esmtp (Exim 4.12) id 19jlp9-0005PN-00 for simple@ietf.org; Mon, 04 Aug 2003 16:20:56 -0400 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h74KKApp008121; Mon, 4 Aug 2003 13:20:10 -0700 (PDT) Received: from [128.107.170.164] ([128.107.170.164]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGT07015; Mon, 4 Aug 2003 13:20:09 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.1.2418 From: Cullen Jennings To: Robert Sparks , Message-ID: In-Reply-To: <1059580659.940.58.camel@RjS.localdomain> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] simple-message-sessions Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.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, 04 Aug 2003 13:20:08 -0700 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit The notes from the SIMPLE meeting at IETF 57 have ... > Poll: Are we happy enough with the doc that we can finish the nits and > send it to IESG? Answer: Yes. I don't think this document has had the discussion it deserves. For example: the question of why this is better than just running MESSAGE over SIP on TCP has never been answered. Along with other questions - like now that there is no multiplexing, how does this provide any help whatsoever with congestion control of chat IM sessions. Right now, I have a very hard time convincing developers that there is significant value in implementing this. Perhaps I just don't get it - a few phone calls on the subject could go a long ways on at least educating some people on why this is the right thing. I don't want to slow this document down if the WG feels it is ready - it has improved greatly in the last few drafts. Just my 2 cents.... Cullen _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Aug 4 16:44:58 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA11443; Mon, 4 Aug 2003 16:44:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jmCT-0005U3-00; Mon, 04 Aug 2003 16:45:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19jmCT-0005U0-00; Mon, 04 Aug 2003 16:45:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jmCT-0004ss-4U; Mon, 04 Aug 2003 16:45:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jmCF-0004sV-5Q for simple@optimus.ietf.org; Mon, 04 Aug 2003 16:44:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA11440 for ; Mon, 4 Aug 2003 16:44:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jmCD-0005Tx-00 for simple@ietf.org; Mon, 04 Aug 2003 16:44:45 -0400 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 19jmCC-0005Tr-00 for simple@ietf.org; Mon, 04 Aug 2003 16:44:44 -0400 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h74Ki1Rd007421; Mon, 4 Aug 2003 16:44:01 -0400 (EDT) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 4 Aug 2003 15:44:01 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E8628E@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'Cullen Jennings'" , Robert Sparks , simple@ietf.org Subject: RE: [Simple] simple-message-sessions MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 4 Aug 2003 15:44:00 -0500 Cullen Jennings writes: > I don't think this document has had the discussion > it deserves. For example: the question of why this > is better than just running MESSAGE over SIP on TCP > has never been answered. 1. It's smaller than SIP. I just had a discussion with handset manufacturer in which they expressed concern about the large number of mandatory headers (on the order of 500 - 1000 bytes) just to send a MESSAGE. I assured them that message sessions, with header blocks much closer to 50 bytes, would alleviate many of their concerns. 2. It doesn't traverse the proxy network Just using MESSAGE over TCP requires proxies to stay in the path of the messages. While this can be avoided in theory, such avoidance is exacerbated by the fact that MESSAGE messages don't create sessions. 3. It doesn't allow advanced call control On a related note, the fact that MESSAGEs exist outside of dialogs make them nearly impossible to manage. You can't perform REFER; you don't get to leverage the XCON (and any future conferencing work); all other call control stuff doesn't work. With message sessions, IMs are just another media stream. There are probably other major advantages that I'm missing at the moment, but those are the three that loom largest in my mind. /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Aug 4 16:45:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA11461 for ; Mon, 4 Aug 2003 16:45:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jmCW-0004uV-CO for simple-archive@odin.ietf.org; Mon, 04 Aug 2003 16:45:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h74Kj4KL018869 for simple-archive@odin.ietf.org; Mon, 4 Aug 2003 16:45:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jmCW-0004uG-96 for simple-web-archive@optimus.ietf.org; Mon, 04 Aug 2003 16:45:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA11443; Mon, 4 Aug 2003 16:44:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jmCT-0005U3-00; Mon, 04 Aug 2003 16:45:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19jmCT-0005U0-00; Mon, 04 Aug 2003 16:45:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jmCT-0004ss-4U; Mon, 04 Aug 2003 16:45:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jmCF-0004sV-5Q for simple@optimus.ietf.org; Mon, 04 Aug 2003 16:44:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA11440 for ; Mon, 4 Aug 2003 16:44:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jmCD-0005Tx-00 for simple@ietf.org; Mon, 04 Aug 2003 16:44:45 -0400 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 19jmCC-0005Tr-00 for simple@ietf.org; Mon, 04 Aug 2003 16:44:44 -0400 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h74Ki1Rd007421; Mon, 4 Aug 2003 16:44:01 -0400 (EDT) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 4 Aug 2003 15:44:01 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E8628E@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'Cullen Jennings'" , Robert Sparks , simple@ietf.org Subject: RE: [Simple] simple-message-sessions MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 4 Aug 2003 15:44:00 -0500 Cullen Jennings writes: > I don't think this document has had the discussion > it deserves. For example: the question of why this > is better than just running MESSAGE over SIP on TCP > has never been answered. 1. It's smaller than SIP. I just had a discussion with handset manufacturer in which they expressed concern about the large number of mandatory headers (on the order of 500 - 1000 bytes) just to send a MESSAGE. I assured them that message sessions, with header blocks much closer to 50 bytes, would alleviate many of their concerns. 2. It doesn't traverse the proxy network Just using MESSAGE over TCP requires proxies to stay in the path of the messages. While this can be avoided in theory, such avoidance is exacerbated by the fact that MESSAGE messages don't create sessions. 3. It doesn't allow advanced call control On a related note, the fact that MESSAGEs exist outside of dialogs make them nearly impossible to manage. You can't perform REFER; you don't get to leverage the XCON (and any future conferencing work); all other call control stuff doesn't work. With message sessions, IMs are just another media stream. There are probably other major advantages that I'm missing at the moment, but those are the three that loom largest in my mind. /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Aug 4 18:18:57 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA14448; Mon, 4 Aug 2003 18:18:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jnfQ-00061p-00; Mon, 04 Aug 2003 18:19:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19jnfQ-00061m-00; Mon, 04 Aug 2003 18:19:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jnfQ-0007WE-Jo; Mon, 04 Aug 2003 18:19:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jnem-0007Vh-Ok for simple@optimus.ietf.org; Mon, 04 Aug 2003 18:18:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA14421 for ; Mon, 4 Aug 2003 18:18:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jnej-00061V-00 for simple@ietf.org; Mon, 04 Aug 2003 18:18:18 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19jnej-00061N-00 for simple@ietf.org; Mon, 04 Aug 2003 18:18:17 -0400 Received: from cisco.com (171.68.223.137) by sj-iport-2.cisco.com with ESMTP; 04 Aug 2003 15:22:05 -0700 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h74MHjuG002083; Mon, 4 Aug 2003 15:17:45 -0700 (PDT) Received: from [128.107.170.164] ([128.107.170.164]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGT22014; Mon, 4 Aug 2003 15:17:44 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.1.2418 Subject: Re: [Simple] simple-message-sessions From: Cullen Jennings To: Adam Roach , Robert Sparks , Message-ID: In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3E8628E@dyn-tx-exch-001.dynamicsoft.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 04 Aug 2003 15:17:43 -0700 Content-Transfer-Encoding: 7bit Sorry - I was not clear on something. I was not proposing using page mode. I was comparing to using signaling to set up a session of message that looked a lot like SIP. Adam and I talked about this one the phone. Adam pointed out that 1) It is smaller even with sigcomp because the via tags don't compress. 2) Congestion issues are pretty much the same as they are for things like Yahoo or AOL today. Cullen On 8/4/03 13:44, "Adam Roach" wrote: > Cullen Jennings writes: > >> I don't think this document has had the discussion >> it deserves. For example: the question of why this >> is better than just running MESSAGE over SIP on TCP >> has never been answered. > > 1. It's smaller than SIP. > > I just had a discussion with handset manufacturer in which > they expressed concern about the large number of mandatory > headers (on the order of 500 - 1000 bytes) just to send a > MESSAGE. I assured them that message sessions, with header > blocks much closer to 50 bytes, would alleviate many of > their concerns. > > 2. It doesn't traverse the proxy network > > Just using MESSAGE over TCP requires proxies to stay in > the path of the messages. While this can be avoided in > theory, such avoidance is exacerbated by the fact that > MESSAGE messages don't create sessions. > > 3. It doesn't allow advanced call control > > On a related note, the fact that MESSAGEs exist outside > of dialogs make them nearly impossible to manage. You > can't perform REFER; you don't get to leverage the XCON > (and any future conferencing work); all other call control > stuff doesn't work. With message sessions, IMs are just > another media stream. > > There are probably other major advantages that I'm missing at > the moment, but those are the three that loom largest in > my mind. > > /a > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Aug 4 18:19:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA14472 for ; Mon, 4 Aug 2003 18:19:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jnfU-0007Ww-JE for simple-archive@odin.ietf.org; Mon, 04 Aug 2003 18:19:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h74MJ4he028940 for simple-archive@odin.ietf.org; Mon, 4 Aug 2003 18:19:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jnfU-0007Wh-CQ for simple-web-archive@optimus.ietf.org; Mon, 04 Aug 2003 18:19:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA14448; Mon, 4 Aug 2003 18:18:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jnfQ-00061p-00; Mon, 04 Aug 2003 18:19:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19jnfQ-00061m-00; Mon, 04 Aug 2003 18:19:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jnfQ-0007WE-Jo; Mon, 04 Aug 2003 18:19:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jnem-0007Vh-Ok for simple@optimus.ietf.org; Mon, 04 Aug 2003 18:18:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA14421 for ; Mon, 4 Aug 2003 18:18:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jnej-00061V-00 for simple@ietf.org; Mon, 04 Aug 2003 18:18:18 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19jnej-00061N-00 for simple@ietf.org; Mon, 04 Aug 2003 18:18:17 -0400 Received: from cisco.com (171.68.223.137) by sj-iport-2.cisco.com with ESMTP; 04 Aug 2003 15:22:05 -0700 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h74MHjuG002083; Mon, 4 Aug 2003 15:17:45 -0700 (PDT) Received: from [128.107.170.164] ([128.107.170.164]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGT22014; Mon, 4 Aug 2003 15:17:44 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.1.2418 Subject: Re: [Simple] simple-message-sessions From: Cullen Jennings To: Adam Roach , Robert Sparks , Message-ID: In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3E8628E@dyn-tx-exch-001.dynamicsoft.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 04 Aug 2003 15:17:43 -0700 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sorry - I was not clear on something. I was not proposing using page mode. I was comparing to using signaling to set up a session of message that looked a lot like SIP. Adam and I talked about this one the phone. Adam pointed out that 1) It is smaller even with sigcomp because the via tags don't compress. 2) Congestion issues are pretty much the same as they are for things like Yahoo or AOL today. Cullen On 8/4/03 13:44, "Adam Roach" wrote: > Cullen Jennings writes: > >> I don't think this document has had the discussion >> it deserves. For example: the question of why this >> is better than just running MESSAGE over SIP on TCP >> has never been answered. > > 1. It's smaller than SIP. > > I just had a discussion with handset manufacturer in which > they expressed concern about the large number of mandatory > headers (on the order of 500 - 1000 bytes) just to send a > MESSAGE. I assured them that message sessions, with header > blocks much closer to 50 bytes, would alleviate many of > their concerns. > > 2. It doesn't traverse the proxy network > > Just using MESSAGE over TCP requires proxies to stay in > the path of the messages. While this can be avoided in > theory, such avoidance is exacerbated by the fact that > MESSAGE messages don't create sessions. > > 3. It doesn't allow advanced call control > > On a related note, the fact that MESSAGEs exist outside > of dialogs make them nearly impossible to manage. You > can't perform REFER; you don't get to leverage the XCON > (and any future conferencing work); all other call control > stuff doesn't work. With message sessions, IMs are just > another media stream. > > There are probably other major advantages that I'm missing at > the moment, but those are the three that loom largest in > my mind. > > /a > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Aug 5 09:48:03 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10859; Tue, 5 Aug 2003 09:48:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19k2AY-00022X-00; Tue, 05 Aug 2003 09:48:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19k2AX-00022U-00; Tue, 05 Aug 2003 09:48:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k2AU-0007Jm-NJ; Tue, 05 Aug 2003 09:48:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k2AI-0007Hx-Lg for simple@optimus.ietf.org; Tue, 05 Aug 2003 09:47:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10840 for ; Tue, 5 Aug 2003 09:47:45 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19k2AG-000223-00 for simple@ietf.org; Tue, 05 Aug 2003 09:47:48 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19k2AG-00021z-00 for simple@ietf.org; Tue, 05 Aug 2003 09:47:48 -0400 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h75DljB08943 for ; Tue, 5 Aug 2003 16:47:46 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 5 Aug 2003 16:47:43 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 5 Aug 2003 16:47:44 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 5 Aug 2003 16:47:43 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] xcap and xpath Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701796F4A@esebe019.ntc.nokia.com> Thread-Topic: [Simple] xcap and xpath Thread-Index: AcNPzgjqHgQ2pmCiTVGqkIuujtxcJgLiXYfg To: , X-OriginalArrivalTime: 05 Aug 2003 13:47:43.0503 (UTC) FILETIME=[252669F0:01C35B58] 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, 5 Aug 2003 16:47:43 +0300 Content-Transfer-Encoding: quoted-printable Why not just use XPath? You can define the limited usage of xpath in = your document (as you have written it below) and developers who don't = have the time nor resources to implement a full blown xpath API can = implement the parts of xpath used in the document. Others who already = have an XPath implementation can use that. /Hisham > -----Original Message----- > From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Tuesday, July 22, 2003 12:20 AM > To: Simple WG > Subject: [Simple] xcap and xpath >=20 >=20 > Folks, >=20 > During the meeting, Ted had suggested a potential simplification in=20 > xcap. Namely, don't use xpath at all. If we know ahead of times the=20 > specific "break points" in the schema where we know we will do atomic=20 > operations (I.e., buddies), just define each buddy as a resource, and=20 > define the buddy list as a separate resource, and specify the objects=20 > returned by querying those specific types. >=20 > I thought about this a bit. The problem I ran into is that=20 > one devices=20 > atomic unit is not the same as anothers. >=20 > Consider a PC application which just wants to pull its entire buddy=20 > list in one pass. If information for each buddy is a separate=20 > resource, it has to issue N separate HTTP GETs, one for each of the N=20 > buddies on the list. Worse yet, it would need to first fetch the=20 > "buddy list" resource, which presumably has references to the=20 > resources for each buddy. >=20 > Its more problematic when you want to update something. Lets say you=20 > want to add a buddy. A wireless client would need to PUT the XML=20 > document for this new buddy, and then modify the "buddy list"=20 > document=20 > to add a reference to the new buddy XML document. Thats two=20 > transactions, and one of them requires a GET/modify/PUT of a large=20 > document. >=20 > An optimization is to define a resource that actually returns=20 > the full=20 > buddy list with all of its buddies. If you think about it, this is=20 > exactly the optimiziation that xpath affords us. >=20 > So, I concluded that we want something like xpath, for buddy=20 > lists and=20 > for other usages we are likely to find. >=20 > However, xpath is quite a big spec, and way more than we=20 > need. What we=20 > really need is a way to identify a single XML element. We need to be=20 > able to identify it by its path from the root, where each branch is=20 > defined by element name or by the value of one of its=20 > attributes. That=20 > is a very, very small subset of xpath. >=20 > My recommendation, therefore, is to add a section to the spec=20 > which is=20 > a standalone definition of a string that can point to a single XML=20 > element, using the "/" notation of xpath, and using the=20 > "[@name=3Dvalue]" mechanism in xpath for selecting an element by=20 > attribute name. This section would use Xpath as an informative=20 > reference only. The expressions defined by this section would be=20 > compliant xpath expressions, but we would not be using xpath. That=20 > would leave the door open in the future for full xpath support if we=20 > decide its needed. >=20 > What do people think of this simplification? >=20 > -Jonathan R. > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com >=20 >=20 >=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 Aug 5 09:48:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10944 for ; Tue, 5 Aug 2003 09:48:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k2Aa-0007Mf-St for simple-archive@odin.ietf.org; Tue, 05 Aug 2003 09:48:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h75Dm8pV028303 for simple-archive@odin.ietf.org; Tue, 5 Aug 2003 09:48:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k2Aa-0007MQ-PH for simple-web-archive@optimus.ietf.org; Tue, 05 Aug 2003 09:48:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10859; Tue, 5 Aug 2003 09:48:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19k2AY-00022X-00; Tue, 05 Aug 2003 09:48:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19k2AX-00022U-00; Tue, 05 Aug 2003 09:48:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k2AU-0007Jm-NJ; Tue, 05 Aug 2003 09:48:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k2AI-0007Hx-Lg for simple@optimus.ietf.org; Tue, 05 Aug 2003 09:47:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10840 for ; Tue, 5 Aug 2003 09:47:45 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19k2AG-000223-00 for simple@ietf.org; Tue, 05 Aug 2003 09:47:48 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19k2AG-00021z-00 for simple@ietf.org; Tue, 05 Aug 2003 09:47:48 -0400 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h75DljB08943 for ; Tue, 5 Aug 2003 16:47:46 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 5 Aug 2003 16:47:43 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 5 Aug 2003 16:47:44 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 5 Aug 2003 16:47:43 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] xcap and xpath Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701796F4A@esebe019.ntc.nokia.com> Thread-Topic: [Simple] xcap and xpath Thread-Index: AcNPzgjqHgQ2pmCiTVGqkIuujtxcJgLiXYfg To: , X-OriginalArrivalTime: 05 Aug 2003 13:47:43.0503 (UTC) FILETIME=[252669F0:01C35B58] 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, 5 Aug 2003 16:47:43 +0300 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Why not just use XPath? You can define the limited usage of xpath in = your document (as you have written it below) and developers who don't = have the time nor resources to implement a full blown xpath API can = implement the parts of xpath used in the document. Others who already = have an XPath implementation can use that. /Hisham > -----Original Message----- > From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Tuesday, July 22, 2003 12:20 AM > To: Simple WG > Subject: [Simple] xcap and xpath >=20 >=20 > Folks, >=20 > During the meeting, Ted had suggested a potential simplification in=20 > xcap. Namely, don't use xpath at all. If we know ahead of times the=20 > specific "break points" in the schema where we know we will do atomic=20 > operations (I.e., buddies), just define each buddy as a resource, and=20 > define the buddy list as a separate resource, and specify the objects=20 > returned by querying those specific types. >=20 > I thought about this a bit. The problem I ran into is that=20 > one devices=20 > atomic unit is not the same as anothers. >=20 > Consider a PC application which just wants to pull its entire buddy=20 > list in one pass. If information for each buddy is a separate=20 > resource, it has to issue N separate HTTP GETs, one for each of the N=20 > buddies on the list. Worse yet, it would need to first fetch the=20 > "buddy list" resource, which presumably has references to the=20 > resources for each buddy. >=20 > Its more problematic when you want to update something. Lets say you=20 > want to add a buddy. A wireless client would need to PUT the XML=20 > document for this new buddy, and then modify the "buddy list"=20 > document=20 > to add a reference to the new buddy XML document. Thats two=20 > transactions, and one of them requires a GET/modify/PUT of a large=20 > document. >=20 > An optimization is to define a resource that actually returns=20 > the full=20 > buddy list with all of its buddies. If you think about it, this is=20 > exactly the optimiziation that xpath affords us. >=20 > So, I concluded that we want something like xpath, for buddy=20 > lists and=20 > for other usages we are likely to find. >=20 > However, xpath is quite a big spec, and way more than we=20 > need. What we=20 > really need is a way to identify a single XML element. We need to be=20 > able to identify it by its path from the root, where each branch is=20 > defined by element name or by the value of one of its=20 > attributes. That=20 > is a very, very small subset of xpath. >=20 > My recommendation, therefore, is to add a section to the spec=20 > which is=20 > a standalone definition of a string that can point to a single XML=20 > element, using the "/" notation of xpath, and using the=20 > "[@name=3Dvalue]" mechanism in xpath for selecting an element by=20 > attribute name. This section would use Xpath as an informative=20 > reference only. The expressions defined by this section would be=20 > compliant xpath expressions, but we would not be using xpath. That=20 > would leave the door open in the future for full xpath support if we=20 > decide its needed. >=20 > What do people think of this simplification? >=20 > -Jonathan R. > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com >=20 >=20 >=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 Aug 5 10:08:02 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11976; Tue, 5 Aug 2003 10:08:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19k2Tq-0002FA-00; Tue, 05 Aug 2003 10:08:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19k2Tp-0002F7-00; Tue, 05 Aug 2003 10:08:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k2Tp-0000QI-BS; Tue, 05 Aug 2003 10:08:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k2TA-0000D9-T2 for simple@optimus.ietf.org; Tue, 05 Aug 2003 10:07:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11851 for ; Tue, 5 Aug 2003 10:07:04 -0400 (EDT) From: Dirk.Trossen@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19k2Sx-0002E9-00 for simple@ietf.org; Tue, 05 Aug 2003 10:07:07 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19k2Sw-0002E6-00 for simple@ietf.org; Tue, 05 Aug 2003 10:07:06 -0400 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h75E73B02715 for ; Tue, 5 Aug 2003 17:07:04 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 5 Aug 2003 17:07:03 +0300 Received: from daebh001.NOE.Nokia.com ([172.18.242.231]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 5 Aug 2003 17:07:03 +0300 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 5 Aug 2003 07:07:00 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] xcap and xpath Message-ID: Thread-Topic: [Simple] xcap and xpath Thread-Index: AcNPzgjqHgQ2pmCiTVGqkIuujtxcJgLiXYfgAACFoYA= To: , , X-OriginalArrivalTime: 05 Aug 2003 14:07:00.0653 (UTC) FILETIME=[D6DD7DD0:01C35B5A] 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, 5 Aug 2003 10:06:58 -0400 Content-Transfer-Encoding: quoted-printable Hi Jonathan, So you would define an XPath-like syntax, but wouldn't make the use of = XPath mandatory? Is it realistic (when it comes to deployments) to avoid XPath now but = introduce its usage in the future?=20 I agree with Hisham that I don't see the problem relying on a limited = set of XPath as long as it is carved out properly in the document. With this, we restrict the = options to realize the desired functionality and most likely avoid problems in = implementations?! Dirk >-----Original Message----- >From: ext hisham.khartabil@nokia.com=20 >[mailto:hisham.khartabil@nokia.com] >Sent: Tuesday, August 05, 2003 9:48 AM >To: jdrosen@dynamicsoft.com; simple@ietf.org >Subject: RE: [Simple] xcap and xpath > > >Why not just use XPath? You can define the limited usage of=20 >xpath in your document (as you have written it below) and=20 >developers who don't have the time nor resources to implement=20 >a full blown xpath API can implement the parts of xpath used=20 >in the document. Others who already have an XPath=20 >implementation can use that. > >/Hisham > >> -----Original Message----- >> From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] >> Sent: Tuesday, July 22, 2003 12:20 AM >> To: Simple WG >> Subject: [Simple] xcap and xpath >>=20 >>=20 >> Folks, >>=20 >> During the meeting, Ted had suggested a potential simplification in=20 >> xcap. Namely, don't use xpath at all. If we know ahead of times the=20 >> specific "break points" in the schema where we know we will=20 >do atomic=20 >> operations (I.e., buddies), just define each buddy as a=20 >resource, and=20 >> define the buddy list as a separate resource, and specify=20 >the objects=20 >> returned by querying those specific types. >>=20 >> I thought about this a bit. The problem I ran into is that=20 >> one devices=20 >> atomic unit is not the same as anothers. >>=20 >> Consider a PC application which just wants to pull its entire buddy=20 >> list in one pass. If information for each buddy is a separate=20 >> resource, it has to issue N separate HTTP GETs, one for each=20 >of the N=20 >> buddies on the list. Worse yet, it would need to first fetch the=20 >> "buddy list" resource, which presumably has references to the=20 >> resources for each buddy. >>=20 >> Its more problematic when you want to update something. Lets say you=20 >> want to add a buddy. A wireless client would need to PUT the XML=20 >> document for this new buddy, and then modify the "buddy list"=20 >> document=20 >> to add a reference to the new buddy XML document. Thats two=20 >> transactions, and one of them requires a GET/modify/PUT of a large=20 >> document. >>=20 >> An optimization is to define a resource that actually returns=20 >> the full=20 >> buddy list with all of its buddies. If you think about it, this is=20 >> exactly the optimiziation that xpath affords us. >>=20 >> So, I concluded that we want something like xpath, for buddy=20 >> lists and=20 >> for other usages we are likely to find. >>=20 >> However, xpath is quite a big spec, and way more than we=20 >> need. What we=20 >> really need is a way to identify a single XML element. We need to be=20 >> able to identify it by its path from the root, where each branch is=20 >> defined by element name or by the value of one of its=20 >> attributes. That=20 >> is a very, very small subset of xpath. >>=20 >> My recommendation, therefore, is to add a section to the spec=20 >> which is=20 >> a standalone definition of a string that can point to a single XML=20 >> element, using the "/" notation of xpath, and using the=20 >> "[@name=3Dvalue]" mechanism in xpath for selecting an element by=20 >> attribute name. This section would use Xpath as an informative=20 >> reference only. The expressions defined by this section would be=20 >> compliant xpath expressions, but we would not be using xpath. That=20 >> would leave the door open in the future for full xpath support if we=20 >> decide its needed. >>=20 >> What do people think of this simplification? >>=20 >> -Jonathan R. >> --=20 >> Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >> Chief Technology Officer Parsippany, NJ 07054-2711 >> dynamicsoft >> jdrosen@dynamicsoft.com FAX: (973) 952-5050 >> http://www.jdrosen.net PHONE: (973) 952-5000 >> http://www.dynamicsoft.com >>=20 >>=20 >>=20 >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple >>=20 > >_______________________________________________ >Simple mailing list >Simple@ietf.org >https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Aug 5 10:08:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12057 for ; Tue, 5 Aug 2003 10:08:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k2Tw-0000TW-Cx for simple-archive@odin.ietf.org; Tue, 05 Aug 2003 10:08:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h75E88Ji001820 for simple-archive@odin.ietf.org; Tue, 5 Aug 2003 10:08:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k2Tw-0000TH-9E for simple-web-archive@optimus.ietf.org; Tue, 05 Aug 2003 10:08:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11976; Tue, 5 Aug 2003 10:08:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19k2Tq-0002FA-00; Tue, 05 Aug 2003 10:08:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19k2Tp-0002F7-00; Tue, 05 Aug 2003 10:08:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k2Tp-0000QI-BS; Tue, 05 Aug 2003 10:08:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k2TA-0000D9-T2 for simple@optimus.ietf.org; Tue, 05 Aug 2003 10:07:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11851 for ; Tue, 5 Aug 2003 10:07:04 -0400 (EDT) From: Dirk.Trossen@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19k2Sx-0002E9-00 for simple@ietf.org; Tue, 05 Aug 2003 10:07:07 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19k2Sw-0002E6-00 for simple@ietf.org; Tue, 05 Aug 2003 10:07:06 -0400 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h75E73B02715 for ; Tue, 5 Aug 2003 17:07:04 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 5 Aug 2003 17:07:03 +0300 Received: from daebh001.NOE.Nokia.com ([172.18.242.231]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 5 Aug 2003 17:07:03 +0300 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 5 Aug 2003 07:07:00 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] xcap and xpath Message-ID: Thread-Topic: [Simple] xcap and xpath Thread-Index: AcNPzgjqHgQ2pmCiTVGqkIuujtxcJgLiXYfgAACFoYA= To: , , X-OriginalArrivalTime: 05 Aug 2003 14:07:00.0653 (UTC) FILETIME=[D6DD7DD0:01C35B5A] 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, 5 Aug 2003 10:06:58 -0400 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Jonathan, So you would define an XPath-like syntax, but wouldn't make the use of = XPath mandatory? Is it realistic (when it comes to deployments) to avoid XPath now but = introduce its usage in the future?=20 I agree with Hisham that I don't see the problem relying on a limited = set of XPath as long as it is carved out properly in the document. With this, we restrict the = options to realize the desired functionality and most likely avoid problems in = implementations?! Dirk >-----Original Message----- >From: ext hisham.khartabil@nokia.com=20 >[mailto:hisham.khartabil@nokia.com] >Sent: Tuesday, August 05, 2003 9:48 AM >To: jdrosen@dynamicsoft.com; simple@ietf.org >Subject: RE: [Simple] xcap and xpath > > >Why not just use XPath? You can define the limited usage of=20 >xpath in your document (as you have written it below) and=20 >developers who don't have the time nor resources to implement=20 >a full blown xpath API can implement the parts of xpath used=20 >in the document. Others who already have an XPath=20 >implementation can use that. > >/Hisham > >> -----Original Message----- >> From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] >> Sent: Tuesday, July 22, 2003 12:20 AM >> To: Simple WG >> Subject: [Simple] xcap and xpath >>=20 >>=20 >> Folks, >>=20 >> During the meeting, Ted had suggested a potential simplification in=20 >> xcap. Namely, don't use xpath at all. If we know ahead of times the=20 >> specific "break points" in the schema where we know we will=20 >do atomic=20 >> operations (I.e., buddies), just define each buddy as a=20 >resource, and=20 >> define the buddy list as a separate resource, and specify=20 >the objects=20 >> returned by querying those specific types. >>=20 >> I thought about this a bit. The problem I ran into is that=20 >> one devices=20 >> atomic unit is not the same as anothers. >>=20 >> Consider a PC application which just wants to pull its entire buddy=20 >> list in one pass. If information for each buddy is a separate=20 >> resource, it has to issue N separate HTTP GETs, one for each=20 >of the N=20 >> buddies on the list. Worse yet, it would need to first fetch the=20 >> "buddy list" resource, which presumably has references to the=20 >> resources for each buddy. >>=20 >> Its more problematic when you want to update something. Lets say you=20 >> want to add a buddy. A wireless client would need to PUT the XML=20 >> document for this new buddy, and then modify the "buddy list"=20 >> document=20 >> to add a reference to the new buddy XML document. Thats two=20 >> transactions, and one of them requires a GET/modify/PUT of a large=20 >> document. >>=20 >> An optimization is to define a resource that actually returns=20 >> the full=20 >> buddy list with all of its buddies. If you think about it, this is=20 >> exactly the optimiziation that xpath affords us. >>=20 >> So, I concluded that we want something like xpath, for buddy=20 >> lists and=20 >> for other usages we are likely to find. >>=20 >> However, xpath is quite a big spec, and way more than we=20 >> need. What we=20 >> really need is a way to identify a single XML element. We need to be=20 >> able to identify it by its path from the root, where each branch is=20 >> defined by element name or by the value of one of its=20 >> attributes. That=20 >> is a very, very small subset of xpath. >>=20 >> My recommendation, therefore, is to add a section to the spec=20 >> which is=20 >> a standalone definition of a string that can point to a single XML=20 >> element, using the "/" notation of xpath, and using the=20 >> "[@name=3Dvalue]" mechanism in xpath for selecting an element by=20 >> attribute name. This section would use Xpath as an informative=20 >> reference only. The expressions defined by this section would be=20 >> compliant xpath expressions, but we would not be using xpath. That=20 >> would leave the door open in the future for full xpath support if we=20 >> decide its needed. >>=20 >> What do people think of this simplification? >>=20 >> -Jonathan R. >> --=20 >> Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >> Chief Technology Officer Parsippany, NJ 07054-2711 >> dynamicsoft >> jdrosen@dynamicsoft.com FAX: (973) 952-5050 >> http://www.jdrosen.net PHONE: (973) 952-5000 >> http://www.dynamicsoft.com >>=20 >>=20 >>=20 >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple >>=20 > >_______________________________________________ >Simple mailing list >Simple@ietf.org >https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Aug 5 16:28:02 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27531; Tue, 5 Aug 2003 16:28:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19k8Pd-0005dS-00; Tue, 05 Aug 2003 16:28:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19k8Pc-0005dL-00; Tue, 05 Aug 2003 16:28:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k8PZ-00077i-0b; Tue, 05 Aug 2003 16:28:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k8PS-00077T-5d for simple@optimus.ietf.org; Tue, 05 Aug 2003 16:27:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27523 for ; Tue, 5 Aug 2003 16:27:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19k8PQ-0005dI-00 for simple@ietf.org; Tue, 05 Aug 2003 16:27:52 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19k8PP-0005dE-00 for simple@ietf.org; Tue, 05 Aug 2003 16:27:51 -0400 Received: from dynamicsoft.com (dyn-tx-app-004.dfw.dynamicsoft.com [63.110.3.2]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h75KRC3m000325; Tue, 5 Aug 2003 16:27:13 -0400 (EDT) Message-ID: <3F2FC2F3.7010400@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings CC: Adam Roach , Robert Sparks , simple@ietf.org Subject: Re: [Simple] simple-message-sessions References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 05 Aug 2003 10:45:07 -0400 Content-Transfer-Encoding: 7bit inline. Cullen Jennings wrote: > Sorry - I was not clear on something. I was not proposing using page mode. I > was comparing to using signaling to set up a session of message that looked > a lot like SIP. > > Adam and I talked about this one the phone. Adam pointed out that > > 1) It is smaller even with sigcomp because the via tags don't compress. > > 2) Congestion issues are pretty much the same as they are for things like > Yahoo or AOL today. Well, specifically, it is my understanding that N parallel TCP connections (as opposed to 1) still provides congestion control. There are other side effects, though. In particular, I believe (and someone who knows more than me can confirm) that a single connection would provide overall better throughput, since the window will generally stay open because there is usually traffic. A larger number of connections, each of which gets opened for a new session and sees sporadic traffic, will tend to be in slow start more often and thus reduce the overall throughput. However, I'll also note that, in our ideal case, there would be no intermediaries, and you'd end up with direct tcp connections anyway. That said, I am interested in spec'ing out SCTP for inter-relay usage, as it would address the throughput issue above, and also reduce the number of connections that a relay needs to maintain. In my mind, message sessions is really two protocols that can almost be separated. One of them is the protocol used to obtain bindings and visit remote relays. This protocol is very similar to TURN. The other protocol is a message shim layer that allows us to carry mime content over a tcp connection, established directly or over relays. Cullen, it sounds like your beef is with the shim layer that carries MIME content. Is that right? Is your issue the requirement for another parser? The shim seems simple enough, its not clear to me that this is a real issue. If your beef is with the protocol to establish the relay connections, where the alternative is SIP (REGISTER == BIND), there are real issues there. Using SIP was the essence of the IMTP proposal way back. The problems with that were: 1. you can't just use SIP; you need to remove a bunch of features which really don't work for this application. UDP fallback, forking, redirection. 2. A whole bunch of SIP features are simply unneeded and end up bloating the messages (record-routing, via processing, tags, etc.). 3. Specing a protocol that is a proper subset of SIP, removing the items from 1 and 2 above, is frought with peril. I've been down that road several times now in other protocols. Inevitably, its horribly unclear about exactly what the subset is. Worse, the main protocol evolves, through extensions and revisions - how do those get tracked in the subsetted protocol? In the end, the easiest thing is to define a standalone protocol that represents just what you want. And thats what we've done. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Aug 5 16:28:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27547 for ; Tue, 5 Aug 2003 16:28:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k8Pf-00078N-MH for simple-archive@odin.ietf.org; Tue, 05 Aug 2003 16:28:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h75KS7Bs027419 for simple-archive@odin.ietf.org; Tue, 5 Aug 2003 16:28:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k8Pf-00078A-J5 for simple-web-archive@optimus.ietf.org; Tue, 05 Aug 2003 16:28:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27531; Tue, 5 Aug 2003 16:28:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19k8Pd-0005dS-00; Tue, 05 Aug 2003 16:28:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19k8Pc-0005dL-00; Tue, 05 Aug 2003 16:28:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k8PZ-00077i-0b; Tue, 05 Aug 2003 16:28:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k8PS-00077T-5d for simple@optimus.ietf.org; Tue, 05 Aug 2003 16:27:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27523 for ; Tue, 5 Aug 2003 16:27:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19k8PQ-0005dI-00 for simple@ietf.org; Tue, 05 Aug 2003 16:27:52 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19k8PP-0005dE-00 for simple@ietf.org; Tue, 05 Aug 2003 16:27:51 -0400 Received: from dynamicsoft.com (dyn-tx-app-004.dfw.dynamicsoft.com [63.110.3.2]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h75KRC3m000325; Tue, 5 Aug 2003 16:27:13 -0400 (EDT) Message-ID: <3F2FC2F3.7010400@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings CC: Adam Roach , Robert Sparks , simple@ietf.org Subject: Re: [Simple] simple-message-sessions References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 05 Aug 2003 10:45:07 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit inline. Cullen Jennings wrote: > Sorry - I was not clear on something. I was not proposing using page mode. I > was comparing to using signaling to set up a session of message that looked > a lot like SIP. > > Adam and I talked about this one the phone. Adam pointed out that > > 1) It is smaller even with sigcomp because the via tags don't compress. > > 2) Congestion issues are pretty much the same as they are for things like > Yahoo or AOL today. Well, specifically, it is my understanding that N parallel TCP connections (as opposed to 1) still provides congestion control. There are other side effects, though. In particular, I believe (and someone who knows more than me can confirm) that a single connection would provide overall better throughput, since the window will generally stay open because there is usually traffic. A larger number of connections, each of which gets opened for a new session and sees sporadic traffic, will tend to be in slow start more often and thus reduce the overall throughput. However, I'll also note that, in our ideal case, there would be no intermediaries, and you'd end up with direct tcp connections anyway. That said, I am interested in spec'ing out SCTP for inter-relay usage, as it would address the throughput issue above, and also reduce the number of connections that a relay needs to maintain. In my mind, message sessions is really two protocols that can almost be separated. One of them is the protocol used to obtain bindings and visit remote relays. This protocol is very similar to TURN. The other protocol is a message shim layer that allows us to carry mime content over a tcp connection, established directly or over relays. Cullen, it sounds like your beef is with the shim layer that carries MIME content. Is that right? Is your issue the requirement for another parser? The shim seems simple enough, its not clear to me that this is a real issue. If your beef is with the protocol to establish the relay connections, where the alternative is SIP (REGISTER == BIND), there are real issues there. Using SIP was the essence of the IMTP proposal way back. The problems with that were: 1. you can't just use SIP; you need to remove a bunch of features which really don't work for this application. UDP fallback, forking, redirection. 2. A whole bunch of SIP features are simply unneeded and end up bloating the messages (record-routing, via processing, tags, etc.). 3. Specing a protocol that is a proper subset of SIP, removing the items from 1 and 2 above, is frought with peril. I've been down that road several times now in other protocols. Inevitably, its horribly unclear about exactly what the subset is. Worse, the main protocol evolves, through extensions and revisions - how do those get tracked in the subsetted protocol? In the end, the easiest thing is to define a standalone protocol that represents just what you want. And thats what we've done. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Aug 5 16:29:00 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27566; Tue, 5 Aug 2003 16:29:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19k8QZ-0005dn-00; Tue, 05 Aug 2003 16:29:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19k8QZ-0005dk-00; Tue, 05 Aug 2003 16:29:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k8QX-0007Be-FO; Tue, 05 Aug 2003 16:29:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k8QB-0007BO-4t for simple@optimus.ietf.org; Tue, 05 Aug 2003 16:28:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27563 for ; Tue, 5 Aug 2003 16:28:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19k8Q9-0005de-00 for simple@ietf.org; Tue, 05 Aug 2003 16:28:37 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19k8Q8-0005dY-00 for simple@ietf.org; Tue, 05 Aug 2003 16:28:36 -0400 Received: from dynamicsoft.com (dyn-tx-app-004.dfw.dynamicsoft.com [63.110.3.2]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h75KS63m000343; Tue, 5 Aug 2003 16:28:08 -0400 (EDT) Message-ID: <3F2FCC2B.2040105@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Orly Rosenberg CC: "'simple@ietf.org'" Subject: Re: [Simple] Question about the Waiting state References: <99FF181D4C99564F8D623069E1DDB25E3B89D2@nt-mail.radvision.com> In-Reply-To: <99FF181D4C99564F8D623069E1DDB25E3B89D2@nt-mail.radvision.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 05 Aug 2003 11:24:27 -0400 Content-Transfer-Encoding: 7bit inline. Orly Rosenberg wrote: > Hi. > > According to winfo-package-05: > "If, while in the waiting state, the subscription is refreshed through > another Subscribe, it moves back into the pending state". > > Also in the Subscription state-machine as defined in section 4.7.1, there is > a transition from state waiting to state pending in case of an incoming > Subscribe. > > My question is: > How is it possible to handle a refresh request in the Waiting state, after > we already sent a Notify(terminated)? (when the state changed from Pending > to Terminated). >>From what I understand, the Waiting state is an internal state, but the real > subscription has terminated. > If so, how can we change its state back to pending? You are correct. This is an error. By definition, in waiting state, the subscription has terminated. A new subscription from the watcher would result in a NEW instance of the state machine, which then transitions to pending. In this case, there are now two instances of the state machine - one in waiting, and one in pending. A good implementation would probably transition the machine in the waiting state to terminated, since the information it had captured isn't really needed anymore. The only case that both would be needed is if they contained filters asking for different information. I believe the best way to address this is to add some clarifying/correcting text during authors 48 hours. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Aug 5 16:29:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27589 for ; Tue, 5 Aug 2003 16:29:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k8Qc-0007FI-6H for simple-archive@odin.ietf.org; Tue, 05 Aug 2003 16:29:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h75KT62P027844 for simple-archive@odin.ietf.org; Tue, 5 Aug 2003 16:29:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k8Qc-0007F1-2H for simple-web-archive@optimus.ietf.org; Tue, 05 Aug 2003 16:29:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27566; Tue, 5 Aug 2003 16:29:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19k8QZ-0005dn-00; Tue, 05 Aug 2003 16:29:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19k8QZ-0005dk-00; Tue, 05 Aug 2003 16:29:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k8QX-0007Be-FO; Tue, 05 Aug 2003 16:29:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k8QB-0007BO-4t for simple@optimus.ietf.org; Tue, 05 Aug 2003 16:28:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27563 for ; Tue, 5 Aug 2003 16:28:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19k8Q9-0005de-00 for simple@ietf.org; Tue, 05 Aug 2003 16:28:37 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19k8Q8-0005dY-00 for simple@ietf.org; Tue, 05 Aug 2003 16:28:36 -0400 Received: from dynamicsoft.com (dyn-tx-app-004.dfw.dynamicsoft.com [63.110.3.2]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h75KS63m000343; Tue, 5 Aug 2003 16:28:08 -0400 (EDT) Message-ID: <3F2FCC2B.2040105@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Orly Rosenberg CC: "'simple@ietf.org'" Subject: Re: [Simple] Question about the Waiting state References: <99FF181D4C99564F8D623069E1DDB25E3B89D2@nt-mail.radvision.com> In-Reply-To: <99FF181D4C99564F8D623069E1DDB25E3B89D2@nt-mail.radvision.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 05 Aug 2003 11:24:27 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit inline. Orly Rosenberg wrote: > Hi. > > According to winfo-package-05: > "If, while in the waiting state, the subscription is refreshed through > another Subscribe, it moves back into the pending state". > > Also in the Subscription state-machine as defined in section 4.7.1, there is > a transition from state waiting to state pending in case of an incoming > Subscribe. > > My question is: > How is it possible to handle a refresh request in the Waiting state, after > we already sent a Notify(terminated)? (when the state changed from Pending > to Terminated). >>From what I understand, the Waiting state is an internal state, but the real > subscription has terminated. > If so, how can we change its state back to pending? You are correct. This is an error. By definition, in waiting state, the subscription has terminated. A new subscription from the watcher would result in a NEW instance of the state machine, which then transitions to pending. In this case, there are now two instances of the state machine - one in waiting, and one in pending. A good implementation would probably transition the machine in the waiting state to terminated, since the information it had captured isn't really needed anymore. The only case that both would be needed is if they contained filters asking for different information. I believe the best way to address this is to add some clarifying/correcting text during authors 48 hours. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Aug 5 20:01:04 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03552; Tue, 5 Aug 2003 20:01:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kBjm-0006op-00; Tue, 05 Aug 2003 20:01:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kBjm-0006om-00; Tue, 05 Aug 2003 20:01:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kBji-0005rr-9Q; Tue, 05 Aug 2003 20:01:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kBjA-0005qj-S6 for simple@optimus.ietf.org; Tue, 05 Aug 2003 20:00:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03540 for ; Tue, 5 Aug 2003 20:00:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kBj8-0006oc-00 for simple@ietf.org; Tue, 05 Aug 2003 20:00:27 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19kBj8-0006oR-00 for simple@ietf.org; Tue, 05 Aug 2003 20:00:26 -0400 Received: from dynamicsoft.com (dyn-tx-app-004.dfw.dynamicsoft.com [63.110.3.2]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h75Nxu3m000446; Tue, 5 Aug 2003 19:59:57 -0400 (EDT) Message-ID: <3F3044F6.3060301@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dirk.Trossen@nokia.com CC: hisham.khartabil@nokia.com, simple@ietf.org Subject: Re: [Simple] xcap and xpath References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 05 Aug 2003 19:59:50 -0400 Content-Transfer-Encoding: 7bit The problem is "properly carving out". I had tried this kind of thing in the past, with caller prefs, and previously in this work with acap. Its really easy to use another spec wholesale. Once you try to subset it, the challenge is doing that so that there is a very, very clear definition about what the subset is. As an example, subsettting a grammar is really hard. If we don't use all of xpath, how do we specify the subset of the grammar to be supported? Xpath in particular is full of things we don't need or want, I think - regular expressions, for example. What I am proposing is that the way to subset is to to explicitly specify what we want, rather than to start with xpath and take away until we get to what we want. More inline. Dirk.Trossen@nokia.com wrote: > Hi Jonathan, > > So you would define an XPath-like syntax, but wouldn't make the use of XPath mandatory? > Is it realistic (when it comes to deployments) to avoid XPath now but introduce its usage > in the future? I'm not sure we would find its needed. More likely people would just use xpath libraries on the server side, even though most of it would never get exercised. > > I agree with Hisham that I don't see the problem relying on a limited set of XPath as long > as it is carved out properly in the document. With this, we restrict the options to realize > the desired functionality and most likely avoid problems in implementations?! The devil is in the details here. How would you define the subset grammar? How would you restrict the set of functions that are available? Xpath defines a fairly comprehensive model for an xml document, including nodes for things like namespaces and comments, which we dont need. How would you subset the document model they have proposed? I have no idea. If you don't do a good job at defining the subset, you end up with interop problems between people who concluded on a different subset. Worse, people just assume that servers will use an xpath library anyway, so they write clients which go beyond the subset, and it works anyway. Very dangerous. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Aug 5 20:01:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03576 for ; Tue, 5 Aug 2003 20:01:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kBjp-0005sU-96 for simple-archive@odin.ietf.org; Tue, 05 Aug 2003 20:01:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h760197q022595 for simple-archive@odin.ietf.org; Tue, 5 Aug 2003 20:01:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kBjp-0005sM-5O for simple-web-archive@optimus.ietf.org; Tue, 05 Aug 2003 20:01:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03552; Tue, 5 Aug 2003 20:01:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kBjm-0006op-00; Tue, 05 Aug 2003 20:01:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kBjm-0006om-00; Tue, 05 Aug 2003 20:01:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kBji-0005rr-9Q; Tue, 05 Aug 2003 20:01:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kBjA-0005qj-S6 for simple@optimus.ietf.org; Tue, 05 Aug 2003 20:00:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03540 for ; Tue, 5 Aug 2003 20:00:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kBj8-0006oc-00 for simple@ietf.org; Tue, 05 Aug 2003 20:00:27 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19kBj8-0006oR-00 for simple@ietf.org; Tue, 05 Aug 2003 20:00:26 -0400 Received: from dynamicsoft.com (dyn-tx-app-004.dfw.dynamicsoft.com [63.110.3.2]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h75Nxu3m000446; Tue, 5 Aug 2003 19:59:57 -0400 (EDT) Message-ID: <3F3044F6.3060301@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dirk.Trossen@nokia.com CC: hisham.khartabil@nokia.com, simple@ietf.org Subject: Re: [Simple] xcap and xpath References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 05 Aug 2003 19:59:50 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit The problem is "properly carving out". I had tried this kind of thing in the past, with caller prefs, and previously in this work with acap. Its really easy to use another spec wholesale. Once you try to subset it, the challenge is doing that so that there is a very, very clear definition about what the subset is. As an example, subsettting a grammar is really hard. If we don't use all of xpath, how do we specify the subset of the grammar to be supported? Xpath in particular is full of things we don't need or want, I think - regular expressions, for example. What I am proposing is that the way to subset is to to explicitly specify what we want, rather than to start with xpath and take away until we get to what we want. More inline. Dirk.Trossen@nokia.com wrote: > Hi Jonathan, > > So you would define an XPath-like syntax, but wouldn't make the use of XPath mandatory? > Is it realistic (when it comes to deployments) to avoid XPath now but introduce its usage > in the future? I'm not sure we would find its needed. More likely people would just use xpath libraries on the server side, even though most of it would never get exercised. > > I agree with Hisham that I don't see the problem relying on a limited set of XPath as long > as it is carved out properly in the document. With this, we restrict the options to realize > the desired functionality and most likely avoid problems in implementations?! The devil is in the details here. How would you define the subset grammar? How would you restrict the set of functions that are available? Xpath defines a fairly comprehensive model for an xml document, including nodes for things like namespaces and comments, which we dont need. How would you subset the document model they have proposed? I have no idea. If you don't do a good job at defining the subset, you end up with interop problems between people who concluded on a different subset. Worse, people just assume that servers will use an xpath library anyway, so they write clients which go beyond the subset, and it works anyway. Very dangerous. -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 Aug 8 16:30:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24923; Fri, 8 Aug 2003 16:30:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lDs9-0006Zt-8L; Fri, 08 Aug 2003 16:30:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lDre-0006ZQ-4z for simple@optimus.ietf.org; Fri, 08 Aug 2003 16:29:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24837 for ; Fri, 8 Aug 2003 16:29:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19lDrc-0003rb-00 for simple@ietf.org; Fri, 08 Aug 2003 16:29:28 -0400 Received: from [206.176.144.210] (helo=kevlar.softarmor.com) by ietf-mx with esmtp (Exim 4.12) id 19lDra-0003r1-00 for simple@ietf.org; Fri, 08 Aug 2003 16:29:26 -0400 Received: from kevlar.softarmor.com (kevlar.softarmor.com [127.0.0.1]) by kevlar.softarmor.com (8.12.8/8.12.8) with ESMTP id h78KSZC2002983 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 8 Aug 2003 15:28:35 -0500 Received: (from dwillis@localhost) by kevlar.softarmor.com (8.12.8/8.12.8/Submit) id h78KSYjF002981; Fri, 8 Aug 2003 15:28:34 -0500 X-Authentication-Warning: kevlar.softarmor.com: dwillis set sender to dean.willis@softarmor.com using -f Subject: Re: [Simple] simple-message-sessions From: Dean Willis To: Jonathan Rosenberg Cc: Cullen Jennings , Adam Roach , Robert Sparks , simple@ietf.org In-Reply-To: <3F2FC2F3.7010400@dynamicsoft.com> References: <3F2FC2F3.7010400@dynamicsoft.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1060374514.31640.17.camel@kevlar.softarmor.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.3 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: 08 Aug 2003 15:28:34 -0500 Content-Transfer-Encoding: 7bit > Well, specifically, it is my understanding that N parallel TCP > connections (as opposed to 1) still provides congestion control. There > are other side effects, though. In particular, I believe (and someone > who knows more than me can confirm) that a single connection would > provide overall better throughput, since the window will generally > stay open because there is usually traffic. A larger number of > connections, each of which gets opened for a new session and sees > sporadic traffic, will tend to be in slow start more often and thus > reduce the overall throughput. I tend to think that's exactly backwads. N parallel connections would have much BETTER throughput (at least after slow-start ramps up), but are more competitive for network resources with other TCP connections and therefore more likely to adversely affect congestion. Also, there is no head-of-line blocking between message sessions if each message session is on a seperate socket. A lot does depend on the persistence of the message session, the TCP slow-start options selected, wehether the Nagle algorithm is suppressed, and so on. It seems to me this is something that could benefit from the new fast-adapting TCP stuff that Sally Floyd has been reporting on in TSVWG. > However, I'll also note that, in our ideal case, there would be no > intermediaries, and you'd end up with direct tcp connections anyway. > That said, I am interested in spec'ing out SCTP for inter-relay usage, > as it would address the throughput issue above, and also reduce the > number of connections that a relay needs to maintain. SCTP has huge advantages for inter-relay use. -- Dean _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Aug 8 16:31:04 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24968 for ; Fri, 8 Aug 2003 16:31:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lDsk-0006ek-Nx for simple-archive@odin.ietf.org; Fri, 08 Aug 2003 16:30:38 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h78KUcrm025582 for simple-archive@odin.ietf.org; Fri, 8 Aug 2003 16:30:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lDsk-0006eX-Kp for simple-web-archive@optimus.ietf.org; Fri, 08 Aug 2003 16:30:38 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24923; Fri, 8 Aug 2003 16:30:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lDs9-0006Zt-8L; Fri, 08 Aug 2003 16:30:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lDre-0006ZQ-4z for simple@optimus.ietf.org; Fri, 08 Aug 2003 16:29:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24837 for ; Fri, 8 Aug 2003 16:29:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19lDrc-0003rb-00 for simple@ietf.org; Fri, 08 Aug 2003 16:29:28 -0400 Received: from [206.176.144.210] (helo=kevlar.softarmor.com) by ietf-mx with esmtp (Exim 4.12) id 19lDra-0003r1-00 for simple@ietf.org; Fri, 08 Aug 2003 16:29:26 -0400 Received: from kevlar.softarmor.com (kevlar.softarmor.com [127.0.0.1]) by kevlar.softarmor.com (8.12.8/8.12.8) with ESMTP id h78KSZC2002983 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 8 Aug 2003 15:28:35 -0500 Received: (from dwillis@localhost) by kevlar.softarmor.com (8.12.8/8.12.8/Submit) id h78KSYjF002981; Fri, 8 Aug 2003 15:28:34 -0500 X-Authentication-Warning: kevlar.softarmor.com: dwillis set sender to dean.willis@softarmor.com using -f Subject: Re: [Simple] simple-message-sessions From: Dean Willis To: Jonathan Rosenberg Cc: Cullen Jennings , Adam Roach , Robert Sparks , simple@ietf.org In-Reply-To: <3F2FC2F3.7010400@dynamicsoft.com> References: <3F2FC2F3.7010400@dynamicsoft.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1060374514.31640.17.camel@kevlar.softarmor.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.3 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: 08 Aug 2003 15:28:34 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > Well, specifically, it is my understanding that N parallel TCP > connections (as opposed to 1) still provides congestion control. There > are other side effects, though. In particular, I believe (and someone > who knows more than me can confirm) that a single connection would > provide overall better throughput, since the window will generally > stay open because there is usually traffic. A larger number of > connections, each of which gets opened for a new session and sees > sporadic traffic, will tend to be in slow start more often and thus > reduce the overall throughput. I tend to think that's exactly backwads. N parallel connections would have much BETTER throughput (at least after slow-start ramps up), but are more competitive for network resources with other TCP connections and therefore more likely to adversely affect congestion. Also, there is no head-of-line blocking between message sessions if each message session is on a seperate socket. A lot does depend on the persistence of the message session, the TCP slow-start options selected, wehether the Nagle algorithm is suppressed, and so on. It seems to me this is something that could benefit from the new fast-adapting TCP stuff that Sally Floyd has been reporting on in TSVWG. > However, I'll also note that, in our ideal case, there would be no > intermediaries, and you'd end up with direct tcp connections anyway. > That said, I am interested in spec'ing out SCTP for inter-relay usage, > as it would address the throughput issue above, and also reduce the > number of connections that a relay needs to maintain. SCTP has huge advantages for inter-relay use. -- Dean _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Aug 8 17:54:02 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27532; Fri, 8 Aug 2003 17:54:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19lFBW-0004X4-00; Fri, 08 Aug 2003 17:54:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19lFBW-0004Wz-00; Fri, 08 Aug 2003 17:54:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lFBR-0002ES-0r; Fri, 08 Aug 2003 17:54:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lFAl-0002ED-Nq for simple@optimus.ietf.org; Fri, 08 Aug 2003 17:53:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27508 for ; Fri, 8 Aug 2003 17:53:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19lFAj-0004Wd-00 for simple@ietf.org; Fri, 08 Aug 2003 17:53:17 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19lFAi-0004WP-00 for simple@ietf.org; Fri, 08 Aug 2003 17:53:16 -0400 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h78Lqhtp003540; Fri, 8 Aug 2003 14:52:43 -0700 (PDT) Received: from cisco.com (che-vpn-cluster-2-73.cisco.com [10.86.242.73]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id ABJ89574; Fri, 8 Aug 2003 17:52:41 -0400 (EDT) Message-ID: <3F341BA9.6010108@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dean Willis CC: Jonathan Rosenberg , Cullen Jennings , Adam Roach , Robert Sparks , simple@ietf.org Subject: Re: [Simple] simple-message-sessions References: <3F2FC2F3.7010400@dynamicsoft.com> <1060374514.31640.17.camel@kevlar.softarmor.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, 08 Aug 2003 17:52:41 -0400 Content-Transfer-Encoding: 7bit Dean Willis wrote: > > SCTP has huge advantages for inter-relay use. I think we concluded that SCTP for inter-relay use still has problems with blocking interactions between sessions because it has no way to apply back pressure on a per-stream basis. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Aug 8 17:54:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27548 for ; Fri, 8 Aug 2003 17:54:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lFBZ-0002G8-UC for simple-archive@odin.ietf.org; Fri, 08 Aug 2003 17:54:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h78Ls9UV008649 for simple-archive@odin.ietf.org; Fri, 8 Aug 2003 17:54:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lFBZ-0002Ex-Os for simple-web-archive@optimus.ietf.org; Fri, 08 Aug 2003 17:54:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27532; Fri, 8 Aug 2003 17:54:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19lFBW-0004X4-00; Fri, 08 Aug 2003 17:54:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19lFBW-0004Wz-00; Fri, 08 Aug 2003 17:54:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lFBR-0002ES-0r; Fri, 08 Aug 2003 17:54:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lFAl-0002ED-Nq for simple@optimus.ietf.org; Fri, 08 Aug 2003 17:53:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27508 for ; Fri, 8 Aug 2003 17:53:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19lFAj-0004Wd-00 for simple@ietf.org; Fri, 08 Aug 2003 17:53:17 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19lFAi-0004WP-00 for simple@ietf.org; Fri, 08 Aug 2003 17:53:16 -0400 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h78Lqhtp003540; Fri, 8 Aug 2003 14:52:43 -0700 (PDT) Received: from cisco.com (che-vpn-cluster-2-73.cisco.com [10.86.242.73]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id ABJ89574; Fri, 8 Aug 2003 17:52:41 -0400 (EDT) Message-ID: <3F341BA9.6010108@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dean Willis CC: Jonathan Rosenberg , Cullen Jennings , Adam Roach , Robert Sparks , simple@ietf.org Subject: Re: [Simple] simple-message-sessions References: <3F2FC2F3.7010400@dynamicsoft.com> <1060374514.31640.17.camel@kevlar.softarmor.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, 08 Aug 2003 17:52:41 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Dean Willis wrote: > > SCTP has huge advantages for inter-relay use. I think we concluded that SCTP for inter-relay use still has problems with blocking interactions between sessions because it has no way to apply back pressure on a per-stream basis. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Sun Aug 10 00:23:00 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15373; Sun, 10 Aug 2003 00:23:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19lhjT-0004pV-00; Sun, 10 Aug 2003 00:23:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19lhjT-0004pQ-00; Sun, 10 Aug 2003 00:23:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lhjQ-0003ND-Qy; Sun, 10 Aug 2003 00:23:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lhip-0003Kr-Jk for simple@optimus.ietf.org; Sun, 10 Aug 2003 00:22:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15352 for ; Sun, 10 Aug 2003 00:22:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19lhin-0004pH-00 for simple@ietf.org; Sun, 10 Aug 2003 00:22:21 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19lhim-0004pB-00 for simple@ietf.org; Sun, 10 Aug 2003 00:22:20 -0400 Received: from dynamicsoft.com ([63.113.46.98]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h7A4LX3m002177; Sun, 10 Aug 2003 00:21:33 -0400 (EDT) Message-ID: <3F35C84A.5060606@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: Dean Willis , Cullen Jennings , Adam Roach , Robert Sparks , simple@ietf.org Subject: Re: [Simple] simple-message-sessions References: <3F2FC2F3.7010400@dynamicsoft.com> <1060374514.31640.17.camel@kevlar.softarmor.com> <3F341BA9.6010108@cisco.com> In-Reply-To: <3F341BA9.6010108@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 10 Aug 2003 00:21:30 -0400 Content-Transfer-Encoding: 7bit Paul Kyzivat wrote: > > > Dean Willis wrote: > >> >> SCTP has huge advantages for inter-relay use. > > > I think we concluded that SCTP for inter-relay use still has problems > with blocking interactions between sessions because it has no way to > apply back pressure on a per-stream basis. Sure, but this isn't a symptom of SCTP. We have the same problem with TCP, no? The primary benefit of SCTP would be a reduction in the number of connections between relays. -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 Aug 10 00:23:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15398 for ; Sun, 10 Aug 2003 00:23:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lhjX-0003Ns-12 for simple-archive@odin.ietf.org; Sun, 10 Aug 2003 00:23:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7A4N7vQ013004 for simple-archive@odin.ietf.org; Sun, 10 Aug 2003 00:23:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lhjW-0003Nf-Sm for simple-web-archive@optimus.ietf.org; Sun, 10 Aug 2003 00:23:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15373; Sun, 10 Aug 2003 00:23:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19lhjT-0004pV-00; Sun, 10 Aug 2003 00:23:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19lhjT-0004pQ-00; Sun, 10 Aug 2003 00:23:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lhjQ-0003ND-Qy; Sun, 10 Aug 2003 00:23:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lhip-0003Kr-Jk for simple@optimus.ietf.org; Sun, 10 Aug 2003 00:22:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15352 for ; Sun, 10 Aug 2003 00:22:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19lhin-0004pH-00 for simple@ietf.org; Sun, 10 Aug 2003 00:22:21 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19lhim-0004pB-00 for simple@ietf.org; Sun, 10 Aug 2003 00:22:20 -0400 Received: from dynamicsoft.com ([63.113.46.98]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h7A4LX3m002177; Sun, 10 Aug 2003 00:21:33 -0400 (EDT) Message-ID: <3F35C84A.5060606@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: Dean Willis , Cullen Jennings , Adam Roach , Robert Sparks , simple@ietf.org Subject: Re: [Simple] simple-message-sessions References: <3F2FC2F3.7010400@dynamicsoft.com> <1060374514.31640.17.camel@kevlar.softarmor.com> <3F341BA9.6010108@cisco.com> In-Reply-To: <3F341BA9.6010108@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 10 Aug 2003 00:21:30 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Paul Kyzivat wrote: > > > Dean Willis wrote: > >> >> SCTP has huge advantages for inter-relay use. > > > I think we concluded that SCTP for inter-relay use still has problems > with blocking interactions between sessions because it has no way to > apply back pressure on a per-stream basis. Sure, but this isn't a symptom of SCTP. We have the same problem with TCP, no? The primary benefit of SCTP would be a reduction in the number of connections between relays. -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 Aug 10 14:04:04 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12005; Sun, 10 Aug 2003 14:04:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19luY2-0000iv-00; Sun, 10 Aug 2003 14:04:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19luY1-0000ip-00; Sun, 10 Aug 2003 14:04:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19luY1-0001P8-F0; Sun, 10 Aug 2003 14:04:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19luXO-0001Mi-9i for simple@optimus.ietf.org; Sun, 10 Aug 2003 14:03:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11990 for ; Sun, 10 Aug 2003 14:03:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19luXL-0000iV-00 for simple@ietf.org; Sun, 10 Aug 2003 14:03:23 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by ietf-mx with esmtp (Exim 4.12) id 19luXL-0000hx-00 for simple@ietf.org; Sun, 10 Aug 2003 14:03:23 -0400 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h7AI2ipp027423; Sun, 10 Aug 2003 11:02:44 -0700 (PDT) Received: from [192.168.2.40] (sjc-vpn4-746.cisco.com [10.21.82.234]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGY47212; Sun, 10 Aug 2003 11:02:43 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.1.2418 Subject: Re: [Simple] xcap and xpath From: Cullen Jennings To: Jonathan Rosenberg , Simple WG Message-ID: In-Reply-To: <3F1C58E4.5050608@dynamicsoft.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 09 Aug 2003 12:34:22 -0700 Content-Transfer-Encoding: 7bit This sounds reasonable but I'm not fully seeing why you need it yet. Say the url foo/buddy/a returned 1 and foo/buddy/b returned 2. If I do a get of foo/buddy the server can return anything it wants including a document that contains a composite of 1 and 2 plus some other information that wraps it. If I do a post of foo/buddy/c and c exists it modifies the data. If c does not exist, it creates c, if the posted data is empty, it deletes c. Since this changes the document would return if foo/buddy was request, anyone subscribed to foo/buddy will get notified when this is done. I'm sure I wrong on this and it has all been considered before but I have forgotten what the issues are. Thanks, Cullen On 7/21/03 14:19, "Jonathan Rosenberg" wrote: > Folks, > > During the meeting, Ted had suggested a potential simplification in > xcap. Namely, don't use xpath at all. If we know ahead of times the > specific "break points" in the schema where we know we will do atomic > operations (I.e., buddies), just define each buddy as a resource, and > define the buddy list as a separate resource, and specify the objects > returned by querying those specific types. > > I thought about this a bit. The problem I ran into is that one devices > atomic unit is not the same as anothers. > > Consider a PC application which just wants to pull its entire buddy > list in one pass. If information for each buddy is a separate > resource, it has to issue N separate HTTP GETs, one for each of the N > buddies on the list. Worse yet, it would need to first fetch the > "buddy list" resource, which presumably has references to the > resources for each buddy. > > Its more problematic when you want to update something. Lets say you > want to add a buddy. A wireless client would need to PUT the XML > document for this new buddy, and then modify the "buddy list" document > to add a reference to the new buddy XML document. Thats two > transactions, and one of them requires a GET/modify/PUT of a large > document. > > An optimization is to define a resource that actually returns the full > buddy list with all of its buddies. If you think about it, this is > exactly the optimiziation that xpath affords us. > > So, I concluded that we want something like xpath, for buddy lists and > for other usages we are likely to find. > > However, xpath is quite a big spec, and way more than we need. What we > really need is a way to identify a single XML element. We need to be > able to identify it by its path from the root, where each branch is > defined by element name or by the value of one of its attributes. That > is a very, very small subset of xpath. > > My recommendation, therefore, is to add a section to the spec which is > a standalone definition of a string that can point to a single XML > element, using the "/" notation of xpath, and using the > "[@name=value]" mechanism in xpath for selecting an element by > attribute name. This section would use Xpath as an informative > reference only. The expressions defined by this section would be > compliant xpath expressions, but we would not be using xpath. That > would leave the door open in the future for full xpath support if we > decide its needed. > > What do people think of this simplification? > > -Jonathan R. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Sun Aug 10 14:04:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12061 for ; Sun, 10 Aug 2003 14:04:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19luY5-0001QW-4b for simple-archive@odin.ietf.org; Sun, 10 Aug 2003 14:04:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7AI49RC005477 for simple-archive@odin.ietf.org; Sun, 10 Aug 2003 14:04:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19luY5-0001QG-0p for simple-web-archive@optimus.ietf.org; Sun, 10 Aug 2003 14:04:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12007; Sun, 10 Aug 2003 14:04:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19luY2-0000is-00; Sun, 10 Aug 2003 14:04:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19luY1-0000io-00; Sun, 10 Aug 2003 14:04:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19luY0-0001OR-6l; Sun, 10 Aug 2003 14:04:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19luX9-0001MP-NS for simple@optimus.ietf.org; Sun, 10 Aug 2003 14:03:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11982 for ; Sun, 10 Aug 2003 14:03:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19luX7-0000iG-00 for simple@ietf.org; Sun, 10 Aug 2003 14:03:09 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19luX6-0000ho-00 for simple@ietf.org; Sun, 10 Aug 2003 14:03:08 -0400 Received: from cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 10 Aug 2003 11:02:46 -0700 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h7AI2htp026930; Sun, 10 Aug 2003 11:02:43 -0700 (PDT) Received: from [192.168.2.40] (sjc-vpn4-746.cisco.com [10.21.82.234]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGY47211; Sun, 10 Aug 2003 11:02:42 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.1.2418 Subject: Re: [Simple] A proposal for xcap direction From: Cullen Jennings To: Jonathan Rosenberg CC: Message-ID: In-Reply-To: <3F1C4E62.5060700@dynamicsoft.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 09 Aug 2003 12:02:26 -0700 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I'm supportive of this direction. I think this will also bring xcap server into the scope where it could be implemented inside a typical web server framework. This would be a very *good* thing because the practical issues of deploying secure servers that allow document manipulation from the general internet has turned out to be quite challenging. So, if the proposal turns out that XCAP 1.0 can be done in a typical web server, and XCAP 2.0 can be done in a webdav server - I would see that as nice from a getting it implemented point of view. Cullen On 7/21/03 13:34, "Jonathan Rosenberg" wrote: > It seems that people are supportive of this direction, so I am going > to go ahead and start working on an xcap revision which works along > these lines. I'll send a separate note on how to approach xpath. > > some responses inline: > > hisham.khartabil@nokia.com wrote: > > >>> 2. Every operation is a PUT. No POST. The IETF has established >>> guidelines for usage of HTTP as a substrate for other protocols. >>> One of the tell-tale signs of misuse is that you are using POST >>> as a way to tunnel operations. POST has a well defined semantic - >>> you are sending form data to a process that uses the data as >>> input. In the current xcap draft, the POST operation is used to >>> insert a new element, whereas PUT is used to modify an existing >>> one. We need to only use PUT, since there really is no form >>> processing engine here. However, we still need an insert and a >>> modify operation. How to do that? >>> >>> Well, the proposed direction gives us the answer. How does HTTP >>> support it? Simple. If you PUT a document to a URI that >>> represents a resource that exists, the resource is replaced. If >>> you PUT a document to a URI that doesnt exist, the resource is >>> created (i.e., inserted). Now, our main problem is that there is >>> no way to specify WHERE the new resource gets inserted within the >>> "directory". For regular filesystems, it doesnt matter. For us, >>> it does. So, we will have a constraint that if you do an insert >>> operation on an XML element, you have to do it in a place where >>> either (1) the positioning is implied by the schema, or (2) the >>> positioning isnt important. Again, this just means careful schema >>> design. You will note that in both the authorization usage and >>> buddy list usage, there are many key points in the schema where >>> you can insert things where either the ordering is dictated or >>> not important. >> >> >> I'm confused. Are you talking about PUTting a document or an XML >> element? I thought the XML element is inserted in the location >> pointed to bu the XPATH expression. > > PUT would allow you to put either a document or an XML element. > >> >> >>> 3. We remove the ability to have server computed data (not >>> possible with PUT). That means that creating a buddy list >>> requires the client to either (1) select the URI so its unique, >>> (2) obtain the URI through some other means, (3) put the data >>> without a URI, have the server set the URI, and then have the >>> client fetch the data with the URI filled in. None of them are >>> pretty. Its a limitation with the approach. >> >> >> I thought option 3 was the server computed data. What is different? > > Whats different is that the POST request contained the XML elements > without the server-provided URI, and the POST response contained the > filled-in URI. In the proposed approach, the server is just a > repository. If you PUT the document without the URI, there is no URI. > A separate application (which could be implemented ontop of the xcap > server) would watch for the PUT. When it sees it, it goes and does a > PUT of its own, adding the URI. To find out the assigned uri, the > client needs to either poll or use the xcap package once the change is > made. > > >> >> >> >>> 3. We may be able to keep the ability to have servers enforce >>> data constraints that the schema cannot represent. Not sure its >>> useful. >> >> >> It might be useful. Cases are that you have 2 elements, both are >> optional, but at least one MUST exist. I don't think you can do >> that with schema. > > Yeah, I dont think we can do that with schema. But, I'm not sure we > have that case now. > >> >> >>> 4. We pursue a longer term solution of working with webdav by >>> adding partial patches through some kind of webdav extension. >>> This would be xcap 2.0. >> >> >> >> I fear that this might take longer than 1 year, maily due to the >> fact that we will have version 1.0 that everyone is deploying and >> are not interested in v2.0 for a while to come. > > Well, thats OK then. If the v1.0 solution solves everyones problems > with minimal complexity, that sounds good in my book. > > -Jonathan R. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Sun Aug 10 14:52:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12062 for ; Sun, 10 Aug 2003 14:04:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19luY5-0001Qj-6Z for simple-archive@odin.ietf.org; Sun, 10 Aug 2003 14:04:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7AI49dp005493 for simple-archive@odin.ietf.org; Sun, 10 Aug 2003 14:04:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19luY5-0001QN-34 for simple-web-archive@optimus.ietf.org; Sun, 10 Aug 2003 14:04:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12005; Sun, 10 Aug 2003 14:04:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19luY2-0000iv-00; Sun, 10 Aug 2003 14:04:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19luY1-0000ip-00; Sun, 10 Aug 2003 14:04:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19luY1-0001P8-F0; Sun, 10 Aug 2003 14:04:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19luXO-0001Mi-9i for simple@optimus.ietf.org; Sun, 10 Aug 2003 14:03:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11990 for ; Sun, 10 Aug 2003 14:03:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19luXL-0000iV-00 for simple@ietf.org; Sun, 10 Aug 2003 14:03:23 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by ietf-mx with esmtp (Exim 4.12) id 19luXL-0000hx-00 for simple@ietf.org; Sun, 10 Aug 2003 14:03:23 -0400 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h7AI2ipp027423; Sun, 10 Aug 2003 11:02:44 -0700 (PDT) Received: from [192.168.2.40] (sjc-vpn4-746.cisco.com [10.21.82.234]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGY47212; Sun, 10 Aug 2003 11:02:43 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.1.2418 Subject: Re: [Simple] xcap and xpath From: Cullen Jennings To: Jonathan Rosenberg , Simple WG Message-ID: In-Reply-To: <3F1C58E4.5050608@dynamicsoft.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 09 Aug 2003 12:34:22 -0700 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit This sounds reasonable but I'm not fully seeing why you need it yet. Say the url foo/buddy/a returned 1 and foo/buddy/b returned 2. If I do a get of foo/buddy the server can return anything it wants including a document that contains a composite of 1 and 2 plus some other information that wraps it. If I do a post of foo/buddy/c and c exists it modifies the data. If c does not exist, it creates c, if the posted data is empty, it deletes c. Since this changes the document would return if foo/buddy was request, anyone subscribed to foo/buddy will get notified when this is done. I'm sure I wrong on this and it has all been considered before but I have forgotten what the issues are. Thanks, Cullen On 7/21/03 14:19, "Jonathan Rosenberg" wrote: > Folks, > > During the meeting, Ted had suggested a potential simplification in > xcap. Namely, don't use xpath at all. If we know ahead of times the > specific "break points" in the schema where we know we will do atomic > operations (I.e., buddies), just define each buddy as a resource, and > define the buddy list as a separate resource, and specify the objects > returned by querying those specific types. > > I thought about this a bit. The problem I ran into is that one devices > atomic unit is not the same as anothers. > > Consider a PC application which just wants to pull its entire buddy > list in one pass. If information for each buddy is a separate > resource, it has to issue N separate HTTP GETs, one for each of the N > buddies on the list. Worse yet, it would need to first fetch the > "buddy list" resource, which presumably has references to the > resources for each buddy. > > Its more problematic when you want to update something. Lets say you > want to add a buddy. A wireless client would need to PUT the XML > document for this new buddy, and then modify the "buddy list" document > to add a reference to the new buddy XML document. Thats two > transactions, and one of them requires a GET/modify/PUT of a large > document. > > An optimization is to define a resource that actually returns the full > buddy list with all of its buddies. If you think about it, this is > exactly the optimiziation that xpath affords us. > > So, I concluded that we want something like xpath, for buddy lists and > for other usages we are likely to find. > > However, xpath is quite a big spec, and way more than we need. What we > really need is a way to identify a single XML element. We need to be > able to identify it by its path from the root, where each branch is > defined by element name or by the value of one of its attributes. That > is a very, very small subset of xpath. > > My recommendation, therefore, is to add a section to the spec which is > a standalone definition of a string that can point to a single XML > element, using the "/" notation of xpath, and using the > "[@name=value]" mechanism in xpath for selecting an element by > attribute name. This section would use Xpath as an informative > reference only. The expressions defined by this section would be > compliant xpath expressions, but we would not be using xpath. That > would leave the door open in the future for full xpath support if we > decide its needed. > > What do people think of this simplification? > > -Jonathan R. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Sun Aug 10 14:52:29 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12007; Sun, 10 Aug 2003 14:04:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19luY2-0000is-00; Sun, 10 Aug 2003 14:04:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19luY1-0000io-00; Sun, 10 Aug 2003 14:04:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19luY0-0001OR-6l; Sun, 10 Aug 2003 14:04:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19luX9-0001MP-NS for simple@optimus.ietf.org; Sun, 10 Aug 2003 14:03:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11982 for ; Sun, 10 Aug 2003 14:03:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19luX7-0000iG-00 for simple@ietf.org; Sun, 10 Aug 2003 14:03:09 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19luX6-0000ho-00 for simple@ietf.org; Sun, 10 Aug 2003 14:03:08 -0400 Received: from cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 10 Aug 2003 11:02:46 -0700 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h7AI2htp026930; Sun, 10 Aug 2003 11:02:43 -0700 (PDT) Received: from [192.168.2.40] (sjc-vpn4-746.cisco.com [10.21.82.234]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGY47211; Sun, 10 Aug 2003 11:02:42 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.1.2418 Subject: Re: [Simple] A proposal for xcap direction From: Cullen Jennings To: Jonathan Rosenberg CC: Message-ID: In-Reply-To: <3F1C4E62.5060700@dynamicsoft.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 09 Aug 2003 12:02:26 -0700 Content-Transfer-Encoding: 7bit I'm supportive of this direction. I think this will also bring xcap server into the scope where it could be implemented inside a typical web server framework. This would be a very *good* thing because the practical issues of deploying secure servers that allow document manipulation from the general internet has turned out to be quite challenging. So, if the proposal turns out that XCAP 1.0 can be done in a typical web server, and XCAP 2.0 can be done in a webdav server - I would see that as nice from a getting it implemented point of view. Cullen On 7/21/03 13:34, "Jonathan Rosenberg" wrote: > It seems that people are supportive of this direction, so I am going > to go ahead and start working on an xcap revision which works along > these lines. I'll send a separate note on how to approach xpath. > > some responses inline: > > hisham.khartabil@nokia.com wrote: > > >>> 2. Every operation is a PUT. No POST. The IETF has established >>> guidelines for usage of HTTP as a substrate for other protocols. >>> One of the tell-tale signs of misuse is that you are using POST >>> as a way to tunnel operations. POST has a well defined semantic - >>> you are sending form data to a process that uses the data as >>> input. In the current xcap draft, the POST operation is used to >>> insert a new element, whereas PUT is used to modify an existing >>> one. We need to only use PUT, since there really is no form >>> processing engine here. However, we still need an insert and a >>> modify operation. How to do that? >>> >>> Well, the proposed direction gives us the answer. How does HTTP >>> support it? Simple. If you PUT a document to a URI that >>> represents a resource that exists, the resource is replaced. If >>> you PUT a document to a URI that doesnt exist, the resource is >>> created (i.e., inserted). Now, our main problem is that there is >>> no way to specify WHERE the new resource gets inserted within the >>> "directory". For regular filesystems, it doesnt matter. For us, >>> it does. So, we will have a constraint that if you do an insert >>> operation on an XML element, you have to do it in a place where >>> either (1) the positioning is implied by the schema, or (2) the >>> positioning isnt important. Again, this just means careful schema >>> design. You will note that in both the authorization usage and >>> buddy list usage, there are many key points in the schema where >>> you can insert things where either the ordering is dictated or >>> not important. >> >> >> I'm confused. Are you talking about PUTting a document or an XML >> element? I thought the XML element is inserted in the location >> pointed to bu the XPATH expression. > > PUT would allow you to put either a document or an XML element. > >> >> >>> 3. We remove the ability to have server computed data (not >>> possible with PUT). That means that creating a buddy list >>> requires the client to either (1) select the URI so its unique, >>> (2) obtain the URI through some other means, (3) put the data >>> without a URI, have the server set the URI, and then have the >>> client fetch the data with the URI filled in. None of them are >>> pretty. Its a limitation with the approach. >> >> >> I thought option 3 was the server computed data. What is different? > > Whats different is that the POST request contained the XML elements > without the server-provided URI, and the POST response contained the > filled-in URI. In the proposed approach, the server is just a > repository. If you PUT the document without the URI, there is no URI. > A separate application (which could be implemented ontop of the xcap > server) would watch for the PUT. When it sees it, it goes and does a > PUT of its own, adding the URI. To find out the assigned uri, the > client needs to either poll or use the xcap package once the change is > made. > > >> >> >> >>> 3. We may be able to keep the ability to have servers enforce >>> data constraints that the schema cannot represent. Not sure its >>> useful. >> >> >> It might be useful. Cases are that you have 2 elements, both are >> optional, but at least one MUST exist. I don't think you can do >> that with schema. > > Yeah, I dont think we can do that with schema. But, I'm not sure we > have that case now. > >> >> >>> 4. We pursue a longer term solution of working with webdav by >>> adding partial patches through some kind of webdav extension. >>> This would be xcap 2.0. >> >> >> >> I fear that this might take longer than 1 year, maily due to the >> fact that we will have version 1.0 that everyone is deploying and >> are not interested in v2.0 for a while to come. > > Well, thats OK then. If the v1.0 solution solves everyones problems > with minimal complexity, that sounds good in my book. > > -Jonathan R. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Sun Aug 10 20:48:04 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20669; Sun, 10 Aug 2003 20:48:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19m0qz-00021z-00; Sun, 10 Aug 2003 20:48:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19m0qz-00021w-00; Sun, 10 Aug 2003 20:48:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19m0qu-00044w-S2; Sun, 10 Aug 2003 20:48:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19m0qP-00044c-4c for simple@optimus.ietf.org; Sun, 10 Aug 2003 20:47:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20650 for ; Sun, 10 Aug 2003 20:47:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19m0qM-00021e-00 for simple@ietf.org; Sun, 10 Aug 2003 20:47:26 -0400 Received: from dewberry.cc.columbia.edu ([128.59.59.68] ident=cu41754) by ietf-mx with esmtp (Exim 4.12) id 19m0qM-00021b-00 for simple@ietf.org; Sun, 10 Aug 2003 20:47:26 -0400 Received: from cs.columbia.edu (path.cs.columbia.edu [128.59.19.143]) (user=hgs10 mech=PLAIN bits=0) by dewberry.cc.columbia.edu (8.12.8p1/8.12.8) with ESMTP id h7B0lQxv019686 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Sun, 10 Aug 2003 20:47:26 -0400 (EDT) Message-ID: <3F36E79E.3010909@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Simple WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 Content-Transfer-Encoding: 7bit Subject: [Simple] CIPID: contact information Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.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, 10 Aug 2003 20:47:26 -0400 Content-Transfer-Encoding: 7bit I will be submitting http://www1.cs.columbia.edu/~hgs/sip/draft/cipid/draft-ietf-simple-cipid-00.html shortly, the result of splitting the original RPIDS document. (FWIW, I've since found out that AIM offers something very similar to the functionality.) Any last-minute pre-00 comments are most welcome. Henning _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Sun Aug 10 20:48:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20696 for ; Sun, 10 Aug 2003 20:48:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19m0r2-00045d-Pu for simple-archive@odin.ietf.org; Sun, 10 Aug 2003 20:48:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7B0m8sG015715 for simple-archive@odin.ietf.org; Sun, 10 Aug 2003 20:48:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19m0r2-00045O-Lf for simple-web-archive@optimus.ietf.org; Sun, 10 Aug 2003 20:48:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20669; Sun, 10 Aug 2003 20:48:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19m0qz-00021z-00; Sun, 10 Aug 2003 20:48:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19m0qz-00021w-00; Sun, 10 Aug 2003 20:48:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19m0qu-00044w-S2; Sun, 10 Aug 2003 20:48:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19m0qP-00044c-4c for simple@optimus.ietf.org; Sun, 10 Aug 2003 20:47:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20650 for ; Sun, 10 Aug 2003 20:47:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19m0qM-00021e-00 for simple@ietf.org; Sun, 10 Aug 2003 20:47:26 -0400 Received: from dewberry.cc.columbia.edu ([128.59.59.68] ident=cu41754) by ietf-mx with esmtp (Exim 4.12) id 19m0qM-00021b-00 for simple@ietf.org; Sun, 10 Aug 2003 20:47:26 -0400 Received: from cs.columbia.edu (path.cs.columbia.edu [128.59.19.143]) (user=hgs10 mech=PLAIN bits=0) by dewberry.cc.columbia.edu (8.12.8p1/8.12.8) with ESMTP id h7B0lQxv019686 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Sun, 10 Aug 2003 20:47:26 -0400 (EDT) Message-ID: <3F36E79E.3010909@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Simple WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 Content-Transfer-Encoding: 7bit Subject: [Simple] CIPID: contact information Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.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, 10 Aug 2003 20:47:26 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I will be submitting http://www1.cs.columbia.edu/~hgs/sip/draft/cipid/draft-ietf-simple-cipid-00.html shortly, the result of splitting the original RPIDS document. (FWIW, I've since found out that AIM offers something very similar to the functionality.) Any last-minute pre-00 comments are most welcome. Henning _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Aug 11 01:43:02 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25107; Mon, 11 Aug 2003 01:43:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19m5SS-0003Fl-00; Mon, 11 Aug 2003 01:43:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19m5SR-0003Fg-00; Mon, 11 Aug 2003 01:43:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19m5SO-0002vx-TY; Mon, 11 Aug 2003 01:43:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19m5Rz-0002vU-UC for simple@optimus.ietf.org; Mon, 11 Aug 2003 01:42:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25099 for ; Mon, 11 Aug 2003 01:42:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19m5Rw-0003Fd-00 for simple@ietf.org; Mon, 11 Aug 2003 01:42:32 -0400 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 19m5Rw-0003FZ-00 for simple@ietf.org; Mon, 11 Aug 2003 01:42:32 -0400 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h7B5fxRe004939 for ; Mon, 11 Aug 2003 01:41:59 -0400 (EDT) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 11 Aug 2003 00:41:59 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E862B1@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: simple@ietf.org Subject: RE: [Simple] simple-message-sessions MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 11 Aug 2003 00:41:50 -0500 Dean Willis wrote: > SCTP has huge advantages for inter-relay use. Paul Kyzivat responded: > I think we concluded that SCTP for inter-relay use still > has problems with blocking interactions between sessions > because it has no way to apply back pressure on a per-stream > basis. Jonathan Rosenberg replied: > The primary benefit of SCTP would be a reduction in the > number of connections between relays. No, it won't. That's exactly the point that Paul was trying to make. If you start sharing connections, even over SCTP, you get in a jam once any one of your downstream connections start backing up, since it is impossible to push back on a single SCTP stream. Congestion on one MSRP session causes collateral damage to unrelated MSRP sessions. That isn't acceptable. /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Aug 11 01:43:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25123 for ; Mon, 11 Aug 2003 01:43:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19m5SW-0002wf-4W for simple-archive@odin.ietf.org; Mon, 11 Aug 2003 01:43:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7B5h8CM011315 for simple-archive@odin.ietf.org; Mon, 11 Aug 2003 01:43:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19m5SW-0002wQ-0I for simple-web-archive@optimus.ietf.org; Mon, 11 Aug 2003 01:43:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25107; Mon, 11 Aug 2003 01:43:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19m5SS-0003Fl-00; Mon, 11 Aug 2003 01:43:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19m5SR-0003Fg-00; Mon, 11 Aug 2003 01:43:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19m5SO-0002vx-TY; Mon, 11 Aug 2003 01:43:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19m5Rz-0002vU-UC for simple@optimus.ietf.org; Mon, 11 Aug 2003 01:42:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25099 for ; Mon, 11 Aug 2003 01:42:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19m5Rw-0003Fd-00 for simple@ietf.org; Mon, 11 Aug 2003 01:42:32 -0400 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 19m5Rw-0003FZ-00 for simple@ietf.org; Mon, 11 Aug 2003 01:42:32 -0400 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h7B5fxRe004939 for ; Mon, 11 Aug 2003 01:41:59 -0400 (EDT) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 11 Aug 2003 00:41:59 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E862B1@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: simple@ietf.org Subject: RE: [Simple] simple-message-sessions MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 11 Aug 2003 00:41:50 -0500 Dean Willis wrote: > SCTP has huge advantages for inter-relay use. Paul Kyzivat responded: > I think we concluded that SCTP for inter-relay use still > has problems with blocking interactions between sessions > because it has no way to apply back pressure on a per-stream > basis. Jonathan Rosenberg replied: > The primary benefit of SCTP would be a reduction in the > number of connections between relays. No, it won't. That's exactly the point that Paul was trying to make. If you start sharing connections, even over SCTP, you get in a jam once any one of your downstream connections start backing up, since it is impossible to push back on a single SCTP stream. Congestion on one MSRP session causes collateral damage to unrelated MSRP sessions. That isn't acceptable. /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Aug 11 09:28:02 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15409; Mon, 11 Aug 2003 09:28:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mCiU-0005sc-00; Mon, 11 Aug 2003 09:28:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19mCiU-0005sZ-00; Mon, 11 Aug 2003 09:28:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mCiP-0002tb-Fx; Mon, 11 Aug 2003 09:28:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mCi1-0002tL-Ph for simple@optimus.ietf.org; Mon, 11 Aug 2003 09:27:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15405 for ; Mon, 11 Aug 2003 09:27:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mCi0-0005sW-00 for simple@ietf.org; Mon, 11 Aug 2003 09:27:36 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19mChz-0005sT-00 for simple@ietf.org; Mon, 11 Aug 2003 09:27:35 -0400 Received: from dynamicsoft.com ([63.113.46.98]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h7BDR73m002711; Mon, 11 Aug 2003 09:27:07 -0400 (EDT) Message-ID: <3F3799A8.7000708@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adam Roach CC: simple@ietf.org Subject: Re: [Simple] simple-message-sessions References: <9BF66EBF6BEFD942915B4D4D45C051F3E862B1@dyn-tx-exch-001.dynamicsoft.com> In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3E862B1@dyn-tx-exch-001.dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 11 Aug 2003 09:27:04 -0400 Content-Transfer-Encoding: 7bit Adam Roach wrote: > > Jonathan Rosenberg replied: > > >>The primary benefit of SCTP would be a reduction in the >>number of connections between relays. > > > No, it won't. That's exactly the point that Paul was trying to make. > > If you start sharing connections, even over SCTP, you get in a jam > once any one of your downstream connections start backing up, since > it is impossible to push back on a single SCTP stream. Congestion > on one MSRP session causes collateral damage to unrelated MSRP > sessions. That isn't acceptable. I recall suggesting just discarding messages in the relay at that point. If this proves a serious problem we might even be able to add an application layer flow control message to push back. IMHO, its much more important to have a solution for the connection scalability problem than to do nothing here. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Aug 11 09:28:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15426 for ; Mon, 11 Aug 2003 09:28:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mCiX-0002vC-42 for simple-archive@odin.ietf.org; Mon, 11 Aug 2003 09:28:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7BDS9ug011226 for simple-archive@odin.ietf.org; Mon, 11 Aug 2003 09:28:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mCiX-0002uz-0o for simple-web-archive@optimus.ietf.org; Mon, 11 Aug 2003 09:28:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15409; Mon, 11 Aug 2003 09:28:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mCiU-0005sc-00; Mon, 11 Aug 2003 09:28:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19mCiU-0005sZ-00; Mon, 11 Aug 2003 09:28:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mCiP-0002tb-Fx; Mon, 11 Aug 2003 09:28:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mCi1-0002tL-Ph for simple@optimus.ietf.org; Mon, 11 Aug 2003 09:27:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15405 for ; Mon, 11 Aug 2003 09:27:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mCi0-0005sW-00 for simple@ietf.org; Mon, 11 Aug 2003 09:27:36 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19mChz-0005sT-00 for simple@ietf.org; Mon, 11 Aug 2003 09:27:35 -0400 Received: from dynamicsoft.com ([63.113.46.98]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h7BDR73m002711; Mon, 11 Aug 2003 09:27:07 -0400 (EDT) Message-ID: <3F3799A8.7000708@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adam Roach CC: simple@ietf.org Subject: Re: [Simple] simple-message-sessions References: <9BF66EBF6BEFD942915B4D4D45C051F3E862B1@dyn-tx-exch-001.dynamicsoft.com> In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3E862B1@dyn-tx-exch-001.dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 11 Aug 2003 09:27:04 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Adam Roach wrote: > > Jonathan Rosenberg replied: > > >>The primary benefit of SCTP would be a reduction in the >>number of connections between relays. > > > No, it won't. That's exactly the point that Paul was trying to make. > > If you start sharing connections, even over SCTP, you get in a jam > once any one of your downstream connections start backing up, since > it is impossible to push back on a single SCTP stream. Congestion > on one MSRP session causes collateral damage to unrelated MSRP > sessions. That isn't acceptable. I recall suggesting just discarding messages in the relay at that point. If this proves a serious problem we might even be able to add an application layer flow control message to push back. IMHO, its much more important to have a solution for the connection scalability problem than to do nothing here. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Aug 11 14:28:58 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27380; Mon, 11 Aug 2003 14:28:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mHPh-0000R9-00; Mon, 11 Aug 2003 14:29:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19mHPg-0000R6-00; Mon, 11 Aug 2003 14:29:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mHPg-0007Hx-UP; Mon, 11 Aug 2003 14:29:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mHPK-0007H7-Pm for simple@optimus.ietf.org; Mon, 11 Aug 2003 14:28:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27372 for ; Mon, 11 Aug 2003 14:28:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mHPH-0000Qq-00 for simple@ietf.org; Mon, 11 Aug 2003 14:28:35 -0400 Received: from auds953.usa.alcatel.com ([143.209.238.6]) by ietf-mx with esmtp (Exim 4.12) id 19mHPH-0000QV-00 for simple@ietf.org; Mon, 11 Aug 2003 14:28:35 -0400 Received: from alcatel.com (localhost [127.0.0.1]) by auds953.usa.alcatel.com (8.12.8p1/8.12.8) with ESMTP id h7BIRtLX027626; Mon, 11 Aug 2003 13:27:56 -0500 (CDT) Message-ID: <3F37E02A.F6D048C0@alcatel.com> From: Alex Audu Reply-To: alex.audu@alcatel.com X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Adam Roach CC: simple@ietf.org Subject: Re: [Simple] simple-message-sessions References: <9BF66EBF6BEFD942915B4D4D45C051F3E862B1@dyn-tx-exch-001.dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 11 Aug 2003 13:27:54 -0500 Content-Transfer-Encoding: 7bit Not if the SCTP implementation allocates seperate queues for separate streams. In that case, events in one stream should not impact events on the other stream. At least, that is the way our in-house implementation works. Regards, Alex. Adam Roach wrote: > Dean Willis wrote: > > > SCTP has huge advantages for inter-relay use. > > Paul Kyzivat responded: > > > I think we concluded that SCTP for inter-relay use still > > has problems with blocking interactions between sessions > > because it has no way to apply back pressure on a per-stream > > basis. > > Jonathan Rosenberg replied: > > > The primary benefit of SCTP would be a reduction in the > > number of connections between relays. > > No, it won't. That's exactly the point that Paul was trying to make. > > If you start sharing connections, even over SCTP, you get in a jam > once any one of your downstream connections start backing up, since > it is impossible to push back on a single SCTP stream. Congestion > on one MSRP session causes collateral damage to unrelated MSRP > sessions. That isn't acceptable. > > /a > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Aug 11 14:29:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27400 for ; Mon, 11 Aug 2003 14:29:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mHPm-0007Ic-1D for simple-archive@odin.ietf.org; Mon, 11 Aug 2003 14:29:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7BIT6K3028058 for simple-archive@odin.ietf.org; Mon, 11 Aug 2003 14:29:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mHPl-0007IT-TB for simple-web-archive@optimus.ietf.org; Mon, 11 Aug 2003 14:29:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27380; Mon, 11 Aug 2003 14:28:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mHPh-0000R9-00; Mon, 11 Aug 2003 14:29:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19mHPg-0000R6-00; Mon, 11 Aug 2003 14:29:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mHPg-0007Hx-UP; Mon, 11 Aug 2003 14:29:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mHPK-0007H7-Pm for simple@optimus.ietf.org; Mon, 11 Aug 2003 14:28:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27372 for ; Mon, 11 Aug 2003 14:28:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mHPH-0000Qq-00 for simple@ietf.org; Mon, 11 Aug 2003 14:28:35 -0400 Received: from auds953.usa.alcatel.com ([143.209.238.6]) by ietf-mx with esmtp (Exim 4.12) id 19mHPH-0000QV-00 for simple@ietf.org; Mon, 11 Aug 2003 14:28:35 -0400 Received: from alcatel.com (localhost [127.0.0.1]) by auds953.usa.alcatel.com (8.12.8p1/8.12.8) with ESMTP id h7BIRtLX027626; Mon, 11 Aug 2003 13:27:56 -0500 (CDT) Message-ID: <3F37E02A.F6D048C0@alcatel.com> From: Alex Audu Reply-To: alex.audu@alcatel.com X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Adam Roach CC: simple@ietf.org Subject: Re: [Simple] simple-message-sessions References: <9BF66EBF6BEFD942915B4D4D45C051F3E862B1@dyn-tx-exch-001.dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 11 Aug 2003 13:27:54 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Not if the SCTP implementation allocates seperate queues for separate streams. In that case, events in one stream should not impact events on the other stream. At least, that is the way our in-house implementation works. Regards, Alex. Adam Roach wrote: > Dean Willis wrote: > > > SCTP has huge advantages for inter-relay use. > > Paul Kyzivat responded: > > > I think we concluded that SCTP for inter-relay use still > > has problems with blocking interactions between sessions > > because it has no way to apply back pressure on a per-stream > > basis. > > Jonathan Rosenberg replied: > > > The primary benefit of SCTP would be a reduction in the > > number of connections between relays. > > No, it won't. That's exactly the point that Paul was trying to make. > > If you start sharing connections, even over SCTP, you get in a jam > once any one of your downstream connections start backing up, since > it is impossible to push back on a single SCTP stream. Congestion > on one MSRP session causes collateral damage to unrelated MSRP > sessions. That isn't acceptable. > > /a > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Aug 11 15:03:58 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28521; Mon, 11 Aug 2003 15:03:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mHxa-0000gK-00; Mon, 11 Aug 2003 15:04:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19mHxZ-0000gH-00; Mon, 11 Aug 2003 15:04:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mHxZ-0008FM-IZ; Mon, 11 Aug 2003 15:04:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mHwu-0008Es-NK for simple@optimus.ietf.org; Mon, 11 Aug 2003 15:03:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28455 for ; Mon, 11 Aug 2003 15:03:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mHwr-0000fe-00 for simple@ietf.org; Mon, 11 Aug 2003 15:03:17 -0400 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 19mHwr-0000ei-00 for simple@ietf.org; Mon, 11 Aug 2003 15:03:17 -0400 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h7BJ2ZRe006426; Mon, 11 Aug 2003 15:02:35 -0400 (EDT) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 11 Aug 2003 14:02:35 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E862B6@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'alex.audu@alcatel.com'" , Adam Roach Cc: simple@ietf.org Subject: RE: [Simple] simple-message-sessions MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 11 Aug 2003 14:02:34 -0500 The issue isn't head-of-line blocking. The issue is that the SCTP congestion control is specified in such a way that it is determined on a per-association basis, not a per-stream basis. There is no implementation end-around this fact; it's just the way that SCTP has been designed (q.v. RFC 2960, section 7). In any case, we've already reached consensus that this problem is too large to solve at present, and that we're going with MSRP without connection sharing. I have no doubt that adding some mechanism -- perhaps using SCTP, perhaps not -- to allow connection sharing between relays is something that we can add in the future. Given the apparent complexity of the issue, it's probably more of a research problem than a design problem. For the time being, though, it's just wasted effort churning through the same set of arguments all over again. /a > -----Original Message----- > From: Alex Audu [mailto:alex.audu@alcatel.com] > Sent: Monday, August 11, 2003 13:28 > To: Adam Roach > Cc: simple@ietf.org > Subject: Re: [Simple] simple-message-sessions > > > Not if the SCTP implementation allocates seperate queues for separate > streams. > In that case, events in one stream should not impact events > on the other > stream. > At least, that is the way our in-house implementation works. > > Regards, > Alex. > > Adam Roach wrote: > > > Dean Willis wrote: > > > > > SCTP has huge advantages for inter-relay use. > > > > Paul Kyzivat responded: > > > > > I think we concluded that SCTP for inter-relay use still > > > has problems with blocking interactions between sessions > > > because it has no way to apply back pressure on a per-stream > > > basis. > > > > Jonathan Rosenberg replied: > > > > > The primary benefit of SCTP would be a reduction in the > > > number of connections between relays. > > > > No, it won't. That's exactly the point that Paul was trying to make. > > > > If you start sharing connections, even over SCTP, you get in a jam > > once any one of your downstream connections start backing up, since > > it is impossible to push back on a single SCTP stream. Congestion > > on one MSRP session causes collateral damage to unrelated MSRP > > sessions. That isn't acceptable. > > > > /a > > > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Aug 11 15:04:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28591 for ; Mon, 11 Aug 2003 15:04:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mHxe-0008G8-6V for simple-archive@odin.ietf.org; Mon, 11 Aug 2003 15:04:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7BJ46el031743 for simple-archive@odin.ietf.org; Mon, 11 Aug 2003 15:04:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mHxe-0008Fu-3Q for simple-web-archive@optimus.ietf.org; Mon, 11 Aug 2003 15:04:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28521; Mon, 11 Aug 2003 15:03:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mHxa-0000gK-00; Mon, 11 Aug 2003 15:04:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19mHxZ-0000gH-00; Mon, 11 Aug 2003 15:04:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mHxZ-0008FM-IZ; Mon, 11 Aug 2003 15:04:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mHwu-0008Es-NK for simple@optimus.ietf.org; Mon, 11 Aug 2003 15:03:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28455 for ; Mon, 11 Aug 2003 15:03:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mHwr-0000fe-00 for simple@ietf.org; Mon, 11 Aug 2003 15:03:17 -0400 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 19mHwr-0000ei-00 for simple@ietf.org; Mon, 11 Aug 2003 15:03:17 -0400 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h7BJ2ZRe006426; Mon, 11 Aug 2003 15:02:35 -0400 (EDT) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 11 Aug 2003 14:02:35 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E862B6@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'alex.audu@alcatel.com'" , Adam Roach Cc: simple@ietf.org Subject: RE: [Simple] simple-message-sessions MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 11 Aug 2003 14:02:34 -0500 The issue isn't head-of-line blocking. The issue is that the SCTP congestion control is specified in such a way that it is determined on a per-association basis, not a per-stream basis. There is no implementation end-around this fact; it's just the way that SCTP has been designed (q.v. RFC 2960, section 7). In any case, we've already reached consensus that this problem is too large to solve at present, and that we're going with MSRP without connection sharing. I have no doubt that adding some mechanism -- perhaps using SCTP, perhaps not -- to allow connection sharing between relays is something that we can add in the future. Given the apparent complexity of the issue, it's probably more of a research problem than a design problem. For the time being, though, it's just wasted effort churning through the same set of arguments all over again. /a > -----Original Message----- > From: Alex Audu [mailto:alex.audu@alcatel.com] > Sent: Monday, August 11, 2003 13:28 > To: Adam Roach > Cc: simple@ietf.org > Subject: Re: [Simple] simple-message-sessions > > > Not if the SCTP implementation allocates seperate queues for separate > streams. > In that case, events in one stream should not impact events > on the other > stream. > At least, that is the way our in-house implementation works. > > Regards, > Alex. > > Adam Roach wrote: > > > Dean Willis wrote: > > > > > SCTP has huge advantages for inter-relay use. > > > > Paul Kyzivat responded: > > > > > I think we concluded that SCTP for inter-relay use still > > > has problems with blocking interactions between sessions > > > because it has no way to apply back pressure on a per-stream > > > basis. > > > > Jonathan Rosenberg replied: > > > > > The primary benefit of SCTP would be a reduction in the > > > number of connections between relays. > > > > No, it won't. That's exactly the point that Paul was trying to make. > > > > If you start sharing connections, even over SCTP, you get in a jam > > once any one of your downstream connections start backing up, since > > it is impossible to push back on a single SCTP stream. Congestion > > on one MSRP session causes collateral damage to unrelated MSRP > > sessions. That isn't acceptable. > > > > /a > > > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Aug 11 23:44:00 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15471; Mon, 11 Aug 2003 23:44:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mQ4q-0004Dj-00; Mon, 11 Aug 2003 23:44:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19mQ4p-0004Dg-00; Mon, 11 Aug 2003 23:44:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mQ4n-00087l-3H; Mon, 11 Aug 2003 23:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mQ4i-00087X-4S for simple@optimus.ietf.org; Mon, 11 Aug 2003 23:43:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15466 for ; Mon, 11 Aug 2003 23:43:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mQ4g-0004Db-00 for simple@ietf.org; Mon, 11 Aug 2003 23:43:54 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19mQ4f-0004DN-00 for simple@ietf.org; Mon, 11 Aug 2003 23:43:53 -0400 Received: from dynamicsoft.com ([63.113.46.49]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h7C3hH3m003014; Mon, 11 Aug 2003 23:43:17 -0400 (EDT) Message-ID: <3F386250.8070702@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings CC: Simple WG Subject: Re: [Simple] xcap and xpath References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 11 Aug 2003 23:43:12 -0400 Content-Transfer-Encoding: 7bit Cullen Jennings wrote: > This sounds reasonable but I'm not fully seeing why you need it yet. Sorry - by "this" you mean my proposal on the xpath subset? > > Say the url foo/buddy/a returned 1 and foo/buddy/b returned 2. If I do a get > of foo/buddy the server can return anything it wants including a document > that contains a composite of 1 and 2 plus some other information that wraps > it. No, the server would return the XML element addressed by foo/buddy. This would obviously contain elements a and b, but possibly others too. > > If I do a post of foo/buddy/c and c exists it modifies the data. If c does > not exist, it creates c, if the posted data is empty, it deletes c. Since > this changes the document would return if foo/buddy was request, anyone > subscribed to foo/buddy will get notified when this is done. Correct. That is my proposal on how to support both insert and modify. > > I'm sure I wrong on this and it has all been considered before but I have > forgotten what the issues are. THe issue I am talking about below is that xpath has reams of other stuff in it - regular expressions, for example, and the ability to select multiple elements across a tree, none of which we need. So, the idea was to specify a mini xpath as part of xcap. -Jonathan R. > > On 7/21/03 14:19, "Jonathan Rosenberg" wrote: > > >>Folks, >> >>During the meeting, Ted had suggested a potential simplification in >>xcap. Namely, don't use xpath at all. If we know ahead of times the >>specific "break points" in the schema where we know we will do atomic >>operations (I.e., buddies), just define each buddy as a resource, and >>define the buddy list as a separate resource, and specify the objects >>returned by querying those specific types. >> >>I thought about this a bit. The problem I ran into is that one devices >>atomic unit is not the same as anothers. >> >>Consider a PC application which just wants to pull its entire buddy >>list in one pass. If information for each buddy is a separate >>resource, it has to issue N separate HTTP GETs, one for each of the N >>buddies on the list. Worse yet, it would need to first fetch the >>"buddy list" resource, which presumably has references to the >>resources for each buddy. >> >>Its more problematic when you want to update something. Lets say you >>want to add a buddy. A wireless client would need to PUT the XML >>document for this new buddy, and then modify the "buddy list" document >>to add a reference to the new buddy XML document. Thats two >>transactions, and one of them requires a GET/modify/PUT of a large >>document. >> >>An optimization is to define a resource that actually returns the full >>buddy list with all of its buddies. If you think about it, this is >>exactly the optimiziation that xpath affords us. >> >>So, I concluded that we want something like xpath, for buddy lists and >>for other usages we are likely to find. >> >>However, xpath is quite a big spec, and way more than we need. What we >>really need is a way to identify a single XML element. We need to be >>able to identify it by its path from the root, where each branch is >>defined by element name or by the value of one of its attributes. That >>is a very, very small subset of xpath. >> >>My recommendation, therefore, is to add a section to the spec which is >>a standalone definition of a string that can point to a single XML >>element, using the "/" notation of xpath, and using the >>"[@name=value]" mechanism in xpath for selecting an element by >>attribute name. This section would use Xpath as an informative >>reference only. The expressions defined by this section would be >>compliant xpath expressions, but we would not be using xpath. That >>would leave the door open in the future for full xpath support if we >>decide its needed. >> >>What do people think of this simplification? >> >>-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 Aug 11 23:44:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15487 for ; Mon, 11 Aug 2003 23:44:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mQ4s-00089K-UL for simple-archive@odin.ietf.org; Mon, 11 Aug 2003 23:44:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7C3i67s031325 for simple-archive@odin.ietf.org; Mon, 11 Aug 2003 23:44:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mQ4s-00089A-R1 for simple-web-archive@optimus.ietf.org; Mon, 11 Aug 2003 23:44:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15471; Mon, 11 Aug 2003 23:44:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mQ4q-0004Dj-00; Mon, 11 Aug 2003 23:44:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19mQ4p-0004Dg-00; Mon, 11 Aug 2003 23:44:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mQ4n-00087l-3H; Mon, 11 Aug 2003 23:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mQ4i-00087X-4S for simple@optimus.ietf.org; Mon, 11 Aug 2003 23:43:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15466 for ; Mon, 11 Aug 2003 23:43:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mQ4g-0004Db-00 for simple@ietf.org; Mon, 11 Aug 2003 23:43:54 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19mQ4f-0004DN-00 for simple@ietf.org; Mon, 11 Aug 2003 23:43:53 -0400 Received: from dynamicsoft.com ([63.113.46.49]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h7C3hH3m003014; Mon, 11 Aug 2003 23:43:17 -0400 (EDT) Message-ID: <3F386250.8070702@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings CC: Simple WG Subject: Re: [Simple] xcap and xpath References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 11 Aug 2003 23:43:12 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cullen Jennings wrote: > This sounds reasonable but I'm not fully seeing why you need it yet. Sorry - by "this" you mean my proposal on the xpath subset? > > Say the url foo/buddy/a returned 1 and foo/buddy/b returned 2. If I do a get > of foo/buddy the server can return anything it wants including a document > that contains a composite of 1 and 2 plus some other information that wraps > it. No, the server would return the XML element addressed by foo/buddy. This would obviously contain elements a and b, but possibly others too. > > If I do a post of foo/buddy/c and c exists it modifies the data. If c does > not exist, it creates c, if the posted data is empty, it deletes c. Since > this changes the document would return if foo/buddy was request, anyone > subscribed to foo/buddy will get notified when this is done. Correct. That is my proposal on how to support both insert and modify. > > I'm sure I wrong on this and it has all been considered before but I have > forgotten what the issues are. THe issue I am talking about below is that xpath has reams of other stuff in it - regular expressions, for example, and the ability to select multiple elements across a tree, none of which we need. So, the idea was to specify a mini xpath as part of xcap. -Jonathan R. > > On 7/21/03 14:19, "Jonathan Rosenberg" wrote: > > >>Folks, >> >>During the meeting, Ted had suggested a potential simplification in >>xcap. Namely, don't use xpath at all. If we know ahead of times the >>specific "break points" in the schema where we know we will do atomic >>operations (I.e., buddies), just define each buddy as a resource, and >>define the buddy list as a separate resource, and specify the objects >>returned by querying those specific types. >> >>I thought about this a bit. The problem I ran into is that one devices >>atomic unit is not the same as anothers. >> >>Consider a PC application which just wants to pull its entire buddy >>list in one pass. If information for each buddy is a separate >>resource, it has to issue N separate HTTP GETs, one for each of the N >>buddies on the list. Worse yet, it would need to first fetch the >>"buddy list" resource, which presumably has references to the >>resources for each buddy. >> >>Its more problematic when you want to update something. Lets say you >>want to add a buddy. A wireless client would need to PUT the XML >>document for this new buddy, and then modify the "buddy list" document >>to add a reference to the new buddy XML document. Thats two >>transactions, and one of them requires a GET/modify/PUT of a large >>document. >> >>An optimization is to define a resource that actually returns the full >>buddy list with all of its buddies. If you think about it, this is >>exactly the optimiziation that xpath affords us. >> >>So, I concluded that we want something like xpath, for buddy lists and >>for other usages we are likely to find. >> >>However, xpath is quite a big spec, and way more than we need. What we >>really need is a way to identify a single XML element. We need to be >>able to identify it by its path from the root, where each branch is >>defined by element name or by the value of one of its attributes. That >>is a very, very small subset of xpath. >> >>My recommendation, therefore, is to add a section to the spec which is >>a standalone definition of a string that can point to a single XML >>element, using the "/" notation of xpath, and using the >>"[@name=value]" mechanism in xpath for selecting an element by >>attribute name. This section would use Xpath as an informative >>reference only. The expressions defined by this section would be >>compliant xpath expressions, but we would not be using xpath. That >>would leave the door open in the future for full xpath support if we >>decide its needed. >> >>What do people think of this simplification? >> >>-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 Aug 11 23:47:03 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15560; Mon, 11 Aug 2003 23:47:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mQ7n-0004E3-00; Mon, 11 Aug 2003 23:47:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19mQ7m-0004E0-00; Mon, 11 Aug 2003 23:47:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mQ7h-0008ER-Al; Mon, 11 Aug 2003 23:47:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mQ7V-0008E9-UN for simple@optimus.ietf.org; Mon, 11 Aug 2003 23:46:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15557 for ; Mon, 11 Aug 2003 23:46:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mQ7T-0004Dv-00 for simple@ietf.org; Mon, 11 Aug 2003 23:46:47 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19mQ7S-0004Dr-00 for simple@ietf.org; Mon, 11 Aug 2003 23:46:47 -0400 Received: from dynamicsoft.com ([63.113.46.49]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h7C3kB3m003017; Mon, 11 Aug 2003 23:46:11 -0400 (EDT) Message-ID: <3F3862FE.3040609@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings CC: simple@ietf.org Subject: Re: [Simple] A proposal for xcap direction References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 11 Aug 2003 23:46:06 -0400 Content-Transfer-Encoding: 7bit Cullen Jennings wrote: > I'm supportive of this direction. Thanks. > > I think this will also bring xcap server into the scope where it could be > implemented inside a typical web server framework. This would be a very > *good* thing because the practical issues of deploying secure servers that > allow document manipulation from the general internet has turned out to be > quite challenging. Agreed. That was the idea all along - its just a servlet or something within any web server, with some xpath code along with it. Thanks, Jonathan R. > > > On 7/21/03 13:34, "Jonathan Rosenberg" wrote: > > >>It seems that people are supportive of this direction, so I am going >>to go ahead and start working on an xcap revision which works along >>these lines. I'll send a separate note on how to approach xpath. >> >>some responses inline: >> >>hisham.khartabil@nokia.com wrote: >> >> >> >>>>2. Every operation is a PUT. No POST. The IETF has established >>>>guidelines for usage of HTTP as a substrate for other protocols. >>>>One of the tell-tale signs of misuse is that you are using POST >>>>as a way to tunnel operations. POST has a well defined semantic - >>>>you are sending form data to a process that uses the data as >>>>input. In the current xcap draft, the POST operation is used to >>>>insert a new element, whereas PUT is used to modify an existing >>>>one. We need to only use PUT, since there really is no form >>>>processing engine here. However, we still need an insert and a >>>>modify operation. How to do that? >>>> >>>>Well, the proposed direction gives us the answer. How does HTTP >>>>support it? Simple. If you PUT a document to a URI that >>>>represents a resource that exists, the resource is replaced. If >>>>you PUT a document to a URI that doesnt exist, the resource is >>>>created (i.e., inserted). Now, our main problem is that there is >>>>no way to specify WHERE the new resource gets inserted within the >>>>"directory". For regular filesystems, it doesnt matter. For us, >>>>it does. So, we will have a constraint that if you do an insert >>>>operation on an XML element, you have to do it in a place where >>>>either (1) the positioning is implied by the schema, or (2) the >>>>positioning isnt important. Again, this just means careful schema >>>>design. You will note that in both the authorization usage and >>>>buddy list usage, there are many key points in the schema where >>>>you can insert things where either the ordering is dictated or >>>>not important. >>> >>> >>>I'm confused. Are you talking about PUTting a document or an XML >>>element? I thought the XML element is inserted in the location >>>pointed to bu the XPATH expression. >> >>PUT would allow you to put either a document or an XML element. >> >> >>> >>>>3. We remove the ability to have server computed data (not >>>>possible with PUT). That means that creating a buddy list >>>>requires the client to either (1) select the URI so its unique, >>>>(2) obtain the URI through some other means, (3) put the data >>>>without a URI, have the server set the URI, and then have the >>>>client fetch the data with the URI filled in. None of them are >>>>pretty. Its a limitation with the approach. >>> >>> >>>I thought option 3 was the server computed data. What is different? >> >>Whats different is that the POST request contained the XML elements >>without the server-provided URI, and the POST response contained the >>filled-in URI. In the proposed approach, the server is just a >>repository. If you PUT the document without the URI, there is no URI. >>A separate application (which could be implemented ontop of the xcap >>server) would watch for the PUT. When it sees it, it goes and does a >>PUT of its own, adding the URI. To find out the assigned uri, the >>client needs to either poll or use the xcap package once the change is >>made. >> >> >> >>> >>> >>>>3. We may be able to keep the ability to have servers enforce >>>>data constraints that the schema cannot represent. Not sure its >>>>useful. >>> >>> >>>It might be useful. Cases are that you have 2 elements, both are >>>optional, but at least one MUST exist. I don't think you can do >>>that with schema. >> >>Yeah, I dont think we can do that with schema. But, I'm not sure we >>have that case now. >> >> >>> >>>>4. We pursue a longer term solution of working with webdav by >>>>adding partial patches through some kind of webdav extension. >>>>This would be xcap 2.0. >>> >>> >>> >>>I fear that this might take longer than 1 year, maily due to the >>>fact that we will have version 1.0 that everyone is deploying and >>>are not interested in v2.0 for a while to come. >> >>Well, thats OK then. If the v1.0 solution solves everyones problems >>with minimal complexity, that sounds good in my book. >> >>-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 Aug 11 23:47:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15576 for ; Mon, 11 Aug 2003 23:47:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mQ7q-0008Hz-0X for simple-archive@odin.ietf.org; Mon, 11 Aug 2003 23:47:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7C3l9Ji031857 for simple-archive@odin.ietf.org; Mon, 11 Aug 2003 23:47:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mQ7p-0008Hk-TD for simple-web-archive@optimus.ietf.org; Mon, 11 Aug 2003 23:47:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15560; Mon, 11 Aug 2003 23:47:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mQ7n-0004E3-00; Mon, 11 Aug 2003 23:47:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19mQ7m-0004E0-00; Mon, 11 Aug 2003 23:47:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mQ7h-0008ER-Al; Mon, 11 Aug 2003 23:47:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mQ7V-0008E9-UN for simple@optimus.ietf.org; Mon, 11 Aug 2003 23:46:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15557 for ; Mon, 11 Aug 2003 23:46:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mQ7T-0004Dv-00 for simple@ietf.org; Mon, 11 Aug 2003 23:46:47 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19mQ7S-0004Dr-00 for simple@ietf.org; Mon, 11 Aug 2003 23:46:47 -0400 Received: from dynamicsoft.com ([63.113.46.49]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h7C3kB3m003017; Mon, 11 Aug 2003 23:46:11 -0400 (EDT) Message-ID: <3F3862FE.3040609@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings CC: simple@ietf.org Subject: Re: [Simple] A proposal for xcap direction References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 11 Aug 2003 23:46:06 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cullen Jennings wrote: > I'm supportive of this direction. Thanks. > > I think this will also bring xcap server into the scope where it could be > implemented inside a typical web server framework. This would be a very > *good* thing because the practical issues of deploying secure servers that > allow document manipulation from the general internet has turned out to be > quite challenging. Agreed. That was the idea all along - its just a servlet or something within any web server, with some xpath code along with it. Thanks, Jonathan R. > > > On 7/21/03 13:34, "Jonathan Rosenberg" wrote: > > >>It seems that people are supportive of this direction, so I am going >>to go ahead and start working on an xcap revision which works along >>these lines. I'll send a separate note on how to approach xpath. >> >>some responses inline: >> >>hisham.khartabil@nokia.com wrote: >> >> >> >>>>2. Every operation is a PUT. No POST. The IETF has established >>>>guidelines for usage of HTTP as a substrate for other protocols. >>>>One of the tell-tale signs of misuse is that you are using POST >>>>as a way to tunnel operations. POST has a well defined semantic - >>>>you are sending form data to a process that uses the data as >>>>input. In the current xcap draft, the POST operation is used to >>>>insert a new element, whereas PUT is used to modify an existing >>>>one. We need to only use PUT, since there really is no form >>>>processing engine here. However, we still need an insert and a >>>>modify operation. How to do that? >>>> >>>>Well, the proposed direction gives us the answer. How does HTTP >>>>support it? Simple. If you PUT a document to a URI that >>>>represents a resource that exists, the resource is replaced. If >>>>you PUT a document to a URI that doesnt exist, the resource is >>>>created (i.e., inserted). Now, our main problem is that there is >>>>no way to specify WHERE the new resource gets inserted within the >>>>"directory". For regular filesystems, it doesnt matter. For us, >>>>it does. So, we will have a constraint that if you do an insert >>>>operation on an XML element, you have to do it in a place where >>>>either (1) the positioning is implied by the schema, or (2) the >>>>positioning isnt important. Again, this just means careful schema >>>>design. You will note that in both the authorization usage and >>>>buddy list usage, there are many key points in the schema where >>>>you can insert things where either the ordering is dictated or >>>>not important. >>> >>> >>>I'm confused. Are you talking about PUTting a document or an XML >>>element? I thought the XML element is inserted in the location >>>pointed to bu the XPATH expression. >> >>PUT would allow you to put either a document or an XML element. >> >> >>> >>>>3. We remove the ability to have server computed data (not >>>>possible with PUT). That means that creating a buddy list >>>>requires the client to either (1) select the URI so its unique, >>>>(2) obtain the URI through some other means, (3) put the data >>>>without a URI, have the server set the URI, and then have the >>>>client fetch the data with the URI filled in. None of them are >>>>pretty. Its a limitation with the approach. >>> >>> >>>I thought option 3 was the server computed data. What is different? >> >>Whats different is that the POST request contained the XML elements >>without the server-provided URI, and the POST response contained the >>filled-in URI. In the proposed approach, the server is just a >>repository. If you PUT the document without the URI, there is no URI. >>A separate application (which could be implemented ontop of the xcap >>server) would watch for the PUT. When it sees it, it goes and does a >>PUT of its own, adding the URI. To find out the assigned uri, the >>client needs to either poll or use the xcap package once the change is >>made. >> >> >> >>> >>> >>>>3. We may be able to keep the ability to have servers enforce >>>>data constraints that the schema cannot represent. Not sure its >>>>useful. >>> >>> >>>It might be useful. Cases are that you have 2 elements, both are >>>optional, but at least one MUST exist. I don't think you can do >>>that with schema. >> >>Yeah, I dont think we can do that with schema. But, I'm not sure we >>have that case now. >> >> >>> >>>>4. We pursue a longer term solution of working with webdav by >>>>adding partial patches through some kind of webdav extension. >>>>This would be xcap 2.0. >>> >>> >>> >>>I fear that this might take longer than 1 year, maily due to the >>>fact that we will have version 1.0 that everyone is deploying and >>>are not interested in v2.0 for a while to come. >> >>Well, thats OK then. If the v1.0 solution solves everyones problems >>with minimal complexity, that sounds good in my book. >> >>-Jonathan R. > > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Aug 12 12:43:00 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21047; Tue, 12 Aug 2003 12:43:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mcEj-00029H-00; Tue, 12 Aug 2003 12:43:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19mcEi-00029C-00; Tue, 12 Aug 2003 12:43:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mcEf-00028n-BV; Tue, 12 Aug 2003 12:43:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mcEP-00028a-Gg for simple@optimus.ietf.org; Tue, 12 Aug 2003 12:42:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21023 for ; Tue, 12 Aug 2003 12:42:37 -0400 (EDT) From: hardie@qualcomm.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mcEM-000299-00 for simple@ietf.org; Tue, 12 Aug 2003 12:42:42 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx with esmtp (Exim 4.12) id 19mcEL-000290-00 for simple@ietf.org; Tue, 12 Aug 2003 12:42:41 -0400 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h7CGgOVp006429 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 12 Aug 2003 09:42:24 -0700 (PDT) Received: from [129.46.227.161] (carbuncle.qualcomm.com [129.46.227.161]) by magus.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h7CGgLsh006301; Tue, 12 Aug 2003 09:42:22 -0700 (PDT) Mime-Version: 1.0 X-Sender: hardie@mage.qualcomm.com Message-Id: In-Reply-To: <3F386250.8070702@dynamicsoft.com> References: <3F386250.8070702@dynamicsoft.com> To: Jonathan Rosenberg , Cullen Jennings Subject: Re: [Simple] xcap and xpath Cc: Simple WG Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.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, 12 Aug 2003 09:42:21 -0700 At 11:43 PM -0400 8/11/03, Jonathan Rosenberg wrote: >> >>If I do a post of foo/buddy/c and c exists it modifies the data. If c does >>not exist, it creates c, if the posted data is empty, it deletes c. Since >>this changes the document would return if foo/buddy was request, anyone >>subscribed to foo/buddy will get notified when this is done. > >Correct. That is my proposal on how to support both insert and modify. Just as a clarification, do you mean POST or PUT? PUT can obviously be used for create and modify; it is less clear that PUTting an empty document does exactly what you want. Note, however, that DELETE is a valid method in HTTP 1.x, and the combination of PUT (to create or modify) and DELETE (to, well, delete) probably covers the ground. regards, Ted Hardie _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Aug 12 12:43:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21071 for ; Tue, 12 Aug 2003 12:43:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mcEl-00029T-UJ for simple-archive@odin.ietf.org; Tue, 12 Aug 2003 12:43:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7CGh7sc008265 for simple-archive@odin.ietf.org; Tue, 12 Aug 2003 12:43:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mcEl-00029E-Br for simple-web-archive@optimus.ietf.org; Tue, 12 Aug 2003 12:43:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21047; Tue, 12 Aug 2003 12:43:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mcEj-00029H-00; Tue, 12 Aug 2003 12:43:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19mcEi-00029C-00; Tue, 12 Aug 2003 12:43:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mcEf-00028n-BV; Tue, 12 Aug 2003 12:43:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mcEP-00028a-Gg for simple@optimus.ietf.org; Tue, 12 Aug 2003 12:42:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21023 for ; Tue, 12 Aug 2003 12:42:37 -0400 (EDT) From: hardie@qualcomm.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mcEM-000299-00 for simple@ietf.org; Tue, 12 Aug 2003 12:42:42 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx with esmtp (Exim 4.12) id 19mcEL-000290-00 for simple@ietf.org; Tue, 12 Aug 2003 12:42:41 -0400 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h7CGgOVp006429 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 12 Aug 2003 09:42:24 -0700 (PDT) Received: from [129.46.227.161] (carbuncle.qualcomm.com [129.46.227.161]) by magus.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h7CGgLsh006301; Tue, 12 Aug 2003 09:42:22 -0700 (PDT) Mime-Version: 1.0 X-Sender: hardie@mage.qualcomm.com Message-Id: In-Reply-To: <3F386250.8070702@dynamicsoft.com> References: <3F386250.8070702@dynamicsoft.com> To: Jonathan Rosenberg , Cullen Jennings Subject: Re: [Simple] xcap and xpath Cc: Simple WG Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.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, 12 Aug 2003 09:42:21 -0700 At 11:43 PM -0400 8/11/03, Jonathan Rosenberg wrote: >> >>If I do a post of foo/buddy/c and c exists it modifies the data. If c does >>not exist, it creates c, if the posted data is empty, it deletes c. Since >>this changes the document would return if foo/buddy was request, anyone >>subscribed to foo/buddy will get notified when this is done. > >Correct. That is my proposal on how to support both insert and modify. Just as a clarification, do you mean POST or PUT? PUT can obviously be used for create and modify; it is less clear that PUTting an empty document does exactly what you want. Note, however, that DELETE is a valid method in HTTP 1.x, and the combination of PUT (to create or modify) and DELETE (to, well, delete) probably covers the ground. regards, Ted Hardie _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Aug 12 13:02:59 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21622; Tue, 12 Aug 2003 13:02:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mcY3-0002Gt-00; Tue, 12 Aug 2003 13:03:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19mcY3-0002Gq-00; Tue, 12 Aug 2003 13:03:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mcY0-0002sk-8W; Tue, 12 Aug 2003 13:03:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mcX5-0002rE-FX for simple@optimus.ietf.org; Tue, 12 Aug 2003 13:02:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21592 for ; Tue, 12 Aug 2003 13:01:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mcX3-0002GK-00 for simple@ietf.org; Tue, 12 Aug 2003 13:02:01 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19mcX2-0002FU-00 for simple@ietf.org; Tue, 12 Aug 2003 13:02:00 -0400 Received: from dynamicsoft.com ([63.113.47.242]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h7CH153m003302; Tue, 12 Aug 2003 13:01:09 -0400 (EDT) Message-ID: <3F391D4E.4030804@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hardie@qualcomm.com CC: Cullen Jennings , Simple WG Subject: Re: [Simple] xcap and xpath References: <3F386250.8070702@dynamicsoft.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 12 Aug 2003 13:01:02 -0400 Content-Transfer-Encoding: 7bit inline. hardie@qualcomm.com wrote: > At 11:43 PM -0400 8/11/03, Jonathan Rosenberg wrote: > >>> >>> If I do a post of foo/buddy/c and c exists it modifies the data. If c >>> does >>> not exist, it creates c, if the posted data is empty, it deletes c. >>> Since >>> this changes the document would return if foo/buddy was request, anyone >>> subscribed to foo/buddy will get notified when this is done. >> >> >> Correct. That is my proposal on how to support both insert and modify. > > > Just as a clarification, do you mean POST or PUT? PUT. The plan is to not make use of POST at all. > PUT can obviously > be used for create and modify; it is less clear that PUTting an empty > document does exactly what you want. My original intent, and the way the current xcap doc is written, is with DELETE in fact. I hadnt considered PUT of an empty doc, but after Cullen mention it, it seemed reasonable to me. The desire is that it should work as it does for any other kind of resource. So, the real question is - what IS the HTTP semantic for PUT of an empty document? Does the spec say? > Note, however, that DELETE > is a valid method in HTTP 1.x, and the combination of PUT (to create > or modify) and DELETE (to, well, delete) probably covers the ground. Right. Per above that was the original intent, though we should say something about PUT of empty documents I suspect, whether to forbid it, or to say its allowed, really only clarifying for us what the http intent is. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Aug 12 13:03:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21645 for ; Tue, 12 Aug 2003 13:03:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mcY6-0002uU-BS for simple-archive@odin.ietf.org; Tue, 12 Aug 2003 13:03:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7CH36dG011180 for simple-archive@odin.ietf.org; Tue, 12 Aug 2003 13:03:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mcY6-0002uF-8H for simple-web-archive@optimus.ietf.org; Tue, 12 Aug 2003 13:03:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21622; Tue, 12 Aug 2003 13:02:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mcY3-0002Gt-00; Tue, 12 Aug 2003 13:03:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19mcY3-0002Gq-00; Tue, 12 Aug 2003 13:03:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mcY0-0002sk-8W; Tue, 12 Aug 2003 13:03:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mcX5-0002rE-FX for simple@optimus.ietf.org; Tue, 12 Aug 2003 13:02:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21592 for ; Tue, 12 Aug 2003 13:01:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mcX3-0002GK-00 for simple@ietf.org; Tue, 12 Aug 2003 13:02:01 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19mcX2-0002FU-00 for simple@ietf.org; Tue, 12 Aug 2003 13:02:00 -0400 Received: from dynamicsoft.com ([63.113.47.242]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h7CH153m003302; Tue, 12 Aug 2003 13:01:09 -0400 (EDT) Message-ID: <3F391D4E.4030804@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hardie@qualcomm.com CC: Cullen Jennings , Simple WG Subject: Re: [Simple] xcap and xpath References: <3F386250.8070702@dynamicsoft.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 12 Aug 2003 13:01:02 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit inline. hardie@qualcomm.com wrote: > At 11:43 PM -0400 8/11/03, Jonathan Rosenberg wrote: > >>> >>> If I do a post of foo/buddy/c and c exists it modifies the data. If c >>> does >>> not exist, it creates c, if the posted data is empty, it deletes c. >>> Since >>> this changes the document would return if foo/buddy was request, anyone >>> subscribed to foo/buddy will get notified when this is done. >> >> >> Correct. That is my proposal on how to support both insert and modify. > > > Just as a clarification, do you mean POST or PUT? PUT. The plan is to not make use of POST at all. > PUT can obviously > be used for create and modify; it is less clear that PUTting an empty > document does exactly what you want. My original intent, and the way the current xcap doc is written, is with DELETE in fact. I hadnt considered PUT of an empty doc, but after Cullen mention it, it seemed reasonable to me. The desire is that it should work as it does for any other kind of resource. So, the real question is - what IS the HTTP semantic for PUT of an empty document? Does the spec say? > Note, however, that DELETE > is a valid method in HTTP 1.x, and the combination of PUT (to create > or modify) and DELETE (to, well, delete) probably covers the ground. Right. Per above that was the original intent, though we should say something about PUT of empty documents I suspect, whether to forbid it, or to say its allowed, really only clarifying for us what the http intent is. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Aug 12 13:47:00 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22595; Tue, 12 Aug 2003 13:46:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mdEe-0002ch-00; Tue, 12 Aug 2003 13:47:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19mdEe-0002ce-00; Tue, 12 Aug 2003 13:47:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mdEb-0004MF-Mv; Tue, 12 Aug 2003 13:47:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mdEJ-0004M1-OD for simple@optimus.ietf.org; Tue, 12 Aug 2003 13:46:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22582 for ; Tue, 12 Aug 2003 13:46:36 -0400 (EDT) From: hardie@qualcomm.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mdEH-0002cJ-00 for simple@ietf.org; Tue, 12 Aug 2003 13:46:41 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx with esmtp (Exim 4.12) id 19mdEG-0002cG-00 for simple@ietf.org; Tue, 12 Aug 2003 13:46:40 -0400 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h7CHkOVp010488 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 12 Aug 2003 10:46:24 -0700 (PDT) Received: from [129.46.227.161] (carbuncle.qualcomm.com [129.46.227.161]) by magus.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h7CHkMsh016378; Tue, 12 Aug 2003 10:46:22 -0700 (PDT) Mime-Version: 1.0 X-Sender: hardie@mage.qualcomm.com Message-Id: In-Reply-To: <3F391D4E.4030804@dynamicsoft.com> References: <3F386250.8070702@dynamicsoft.com> <3F391D4E.4030804@dynamicsoft.com> To: Jonathan Rosenberg Subject: Re: [Simple] xcap and xpath Cc: Cullen Jennings , Simple WG Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.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, 12 Aug 2003 10:46:20 -0700 >My original intent, and the way the current xcap doc is written, is >with DELETE in fact. I hadnt considered PUT of an empty doc, but >after Cullen mention it, it seemed reasonable to me. The desire is >that it should work as it does for any other kind of resource. So, >the real question is - what IS the HTTP semantic for PUT of an empty >document? Does the spec say? My reading is that an empty document is updated content and creates a modified version under the rules set out in Section 9.6. Here's the text: > The PUT method requests that the enclosed entity be stored under the > supplied Request-URI. If the Request-URI refers to an already > existing resource, the enclosed entity SHOULD be considered as a > modified version of the one residing on the origin server. If the > Request-URI does not point to an existing resource, and that URI is > capable of being defined as a new resource by the requesting user > agent, the origin server can create the resource with that URI. If a > new resource is created, the origin server MUST inform the user agent > via the 201 (Created) response. If an existing resource is modified, > either the 200 (OK) or 204 (No Content) response codes SHOULD be sent > to indicate successful completion of the request. If the resource > could not be created or modified with the Request-URI, an appropriate > error response SHOULD be given that reflects the nature of the > problem. The recipient of the entity MUST NOT ignore any Content-* > (e.g. Content-Range) headers that it does not understand or implement > and MUST return a 501 (Not Implemented) response in such cases. Note that the "No Content" response does not mean that the resource has been specified to contain no content, it means that the server does not need to return an entity-body, but MAY return updated metainformation (a new e-tag, for example). > If the request passes through a cache and the Request-URI identifies > one or more currently cached entities, those entries SHOULD be > treated as stale. Responses to this method are not cacheable. > > The fundamental difference between the POST and PUT requests is > reflected in the different meaning of the Request-URI. The URI in a > POST request identifies the resource that will handle the enclosed > entity. That resource might be a data-accepting process, a gateway to > some other protocol, or a separate entity that accepts annotations. > In contrast, the URI in a PUT request identifies the entity enclosed > with the request -- the user agent knows what URI is intended and the > server MUST NOT attempt to apply the request to some other resource. > If the server desires that the request be applied to a different URI, > it MUST send a 301 (Moved Permanently) response; the user agent MAY > then make its own decision regarding whether or not to redirect the > request. > > A single resource MAY be identified by many different URIs. For > example, an article might have a URI for identifying "the current > version" which is separate from the URI identifying each particular > version. In this case, a PUT request on a general URI might result in > several other URIs being defined by the origin server. > > HTTP/1.1 does not define how a PUT method affects the state of an > origin server. > > PUT requests MUST obey the message transmission requirements set out > in section 8.2. > > Unless otherwise specified for a particular entity-header, the > entity-headers in the PUT request SHOULD be applied to the resource > created or modified by the PUT. > >> Note, however, that DELETE >>is a valid method in HTTP 1.x, and the combination of PUT (to create >>or modify) and DELETE (to, well, delete) probably covers the ground. > >Right. Per above that was the original intent, though we should say >something about PUT of empty documents I suspect, whether to forbid >it, or to say its allowed, really only clarifying for us what the >http intent is. If you want the resource to continue to exist but to have zero-length content, updating it with a PUT of an empty resource would be the right choice; if you want the resource to cease to exist, using DELETE would be the right choice. regards, Ted Hardie _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Aug 12 13:47:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22632 for ; Tue, 12 Aug 2003 13:47:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mdEh-0004Mu-RK for simple-archive@odin.ietf.org; Tue, 12 Aug 2003 13:47:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7CHl7Pd016791 for simple-archive@odin.ietf.org; Tue, 12 Aug 2003 13:47:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mdEh-0004Mk-AM for simple-web-archive@optimus.ietf.org; Tue, 12 Aug 2003 13:47:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22595; Tue, 12 Aug 2003 13:46:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mdEe-0002ch-00; Tue, 12 Aug 2003 13:47:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19mdEe-0002ce-00; Tue, 12 Aug 2003 13:47:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mdEb-0004MF-Mv; Tue, 12 Aug 2003 13:47:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mdEJ-0004M1-OD for simple@optimus.ietf.org; Tue, 12 Aug 2003 13:46:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22582 for ; Tue, 12 Aug 2003 13:46:36 -0400 (EDT) From: hardie@qualcomm.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mdEH-0002cJ-00 for simple@ietf.org; Tue, 12 Aug 2003 13:46:41 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx with esmtp (Exim 4.12) id 19mdEG-0002cG-00 for simple@ietf.org; Tue, 12 Aug 2003 13:46:40 -0400 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h7CHkOVp010488 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 12 Aug 2003 10:46:24 -0700 (PDT) Received: from [129.46.227.161] (carbuncle.qualcomm.com [129.46.227.161]) by magus.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h7CHkMsh016378; Tue, 12 Aug 2003 10:46:22 -0700 (PDT) Mime-Version: 1.0 X-Sender: hardie@mage.qualcomm.com Message-Id: In-Reply-To: <3F391D4E.4030804@dynamicsoft.com> References: <3F386250.8070702@dynamicsoft.com> <3F391D4E.4030804@dynamicsoft.com> To: Jonathan Rosenberg Subject: Re: [Simple] xcap and xpath Cc: Cullen Jennings , Simple WG Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.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, 12 Aug 2003 10:46:20 -0700 >My original intent, and the way the current xcap doc is written, is >with DELETE in fact. I hadnt considered PUT of an empty doc, but >after Cullen mention it, it seemed reasonable to me. The desire is >that it should work as it does for any other kind of resource. So, >the real question is - what IS the HTTP semantic for PUT of an empty >document? Does the spec say? My reading is that an empty document is updated content and creates a modified version under the rules set out in Section 9.6. Here's the text: > The PUT method requests that the enclosed entity be stored under the > supplied Request-URI. If the Request-URI refers to an already > existing resource, the enclosed entity SHOULD be considered as a > modified version of the one residing on the origin server. If the > Request-URI does not point to an existing resource, and that URI is > capable of being defined as a new resource by the requesting user > agent, the origin server can create the resource with that URI. If a > new resource is created, the origin server MUST inform the user agent > via the 201 (Created) response. If an existing resource is modified, > either the 200 (OK) or 204 (No Content) response codes SHOULD be sent > to indicate successful completion of the request. If the resource > could not be created or modified with the Request-URI, an appropriate > error response SHOULD be given that reflects the nature of the > problem. The recipient of the entity MUST NOT ignore any Content-* > (e.g. Content-Range) headers that it does not understand or implement > and MUST return a 501 (Not Implemented) response in such cases. Note that the "No Content" response does not mean that the resource has been specified to contain no content, it means that the server does not need to return an entity-body, but MAY return updated metainformation (a new e-tag, for example). > If the request passes through a cache and the Request-URI identifies > one or more currently cached entities, those entries SHOULD be > treated as stale. Responses to this method are not cacheable. > > The fundamental difference between the POST and PUT requests is > reflected in the different meaning of the Request-URI. The URI in a > POST request identifies the resource that will handle the enclosed > entity. That resource might be a data-accepting process, a gateway to > some other protocol, or a separate entity that accepts annotations. > In contrast, the URI in a PUT request identifies the entity enclosed > with the request -- the user agent knows what URI is intended and the > server MUST NOT attempt to apply the request to some other resource. > If the server desires that the request be applied to a different URI, > it MUST send a 301 (Moved Permanently) response; the user agent MAY > then make its own decision regarding whether or not to redirect the > request. > > A single resource MAY be identified by many different URIs. For > example, an article might have a URI for identifying "the current > version" which is separate from the URI identifying each particular > version. In this case, a PUT request on a general URI might result in > several other URIs being defined by the origin server. > > HTTP/1.1 does not define how a PUT method affects the state of an > origin server. > > PUT requests MUST obey the message transmission requirements set out > in section 8.2. > > Unless otherwise specified for a particular entity-header, the > entity-headers in the PUT request SHOULD be applied to the resource > created or modified by the PUT. > >> Note, however, that DELETE >>is a valid method in HTTP 1.x, and the combination of PUT (to create >>or modify) and DELETE (to, well, delete) probably covers the ground. > >Right. Per above that was the original intent, though we should say >something about PUT of empty documents I suspect, whether to forbid >it, or to say its allowed, really only clarifying for us what the >http intent is. If you want the resource to continue to exist but to have zero-length content, updating it with a PUT of an empty resource would be the right choice; if you want the resource to cease to exist, using DELETE would be the right choice. regards, Ted Hardie _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Aug 12 14:11:59 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23128; Tue, 12 Aug 2003 14:11:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mdco-0002oW-00; Tue, 12 Aug 2003 14:12:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19mdco-0002oT-00; Tue, 12 Aug 2003 14:12:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mdcn-00051c-Nb; Tue, 12 Aug 2003 14:12:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mdcR-000516-VL for simple@optimus.ietf.org; Tue, 12 Aug 2003 14:11:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23118 for ; Tue, 12 Aug 2003 14:11:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mdcP-0002o3-00 for simple@ietf.org; Tue, 12 Aug 2003 14:11:37 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19mdcO-0002nu-00 for simple@ietf.org; Tue, 12 Aug 2003 14:11:36 -0400 Received: from cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 12 Aug 2003 11:11:07 -0700 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h7CIB47F000312; Tue, 12 Aug 2003 11:11:04 -0700 (PDT) Received: from [128.107.170.103] ([128.107.170.103]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHA16729; Tue, 12 Aug 2003 11:11:03 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.1.2418 Subject: Re: [Simple] xcap and xpath From: Cullen Jennings To: Jonathan Rosenberg CC: Simple WG Message-ID: In-Reply-To: <3F391D4E.4030804@dynamicsoft.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 12 Aug 2003 11:11:02 -0700 Content-Transfer-Encoding: 7bit At the bottom ... On 8/12/03 10:01 AM, "Jonathan Rosenberg" wrote: > inline. > > hardie@qualcomm.com wrote: > >> At 11:43 PM -0400 8/11/03, Jonathan Rosenberg wrote: >> >>>> >>>> If I do a post of foo/buddy/c and c exists it modifies the data. If c >>>> does >>>> not exist, it creates c, if the posted data is empty, it deletes c. >>>> Since >>>> this changes the document would return if foo/buddy was request, anyone >>>> subscribed to foo/buddy will get notified when this is done. >>> >>> >>> Correct. That is my proposal on how to support both insert and modify. >> >> >> Just as a clarification, do you mean POST or PUT? > > PUT. The plan is to not make use of POST at all. > >> PUT can obviously >> be used for create and modify; it is less clear that PUTting an empty >> document does exactly what you want. > > My original intent, and the way the current xcap doc is written, is > with DELETE in fact. I hadnt considered PUT of an empty doc, but after > Cullen mention it, it seemed reasonable to me. The desire is that it > should work as it does for any other kind of resource. So, the real > question is - what IS the HTTP semantic for PUT of an empty document? > Does the spec say? > > >> Note, however, that DELETE >> is a valid method in HTTP 1.x, and the combination of PUT (to create >> or modify) and DELETE (to, well, delete) probably covers the ground. > > Right. Per above that was the original intent, though we should say > something about PUT of empty documents I suspect, whether to forbid > it, or to say its allowed, really only clarifying for us what the http > intent is. > > Thanks, > Jonathan R. I did not have any reason for preferring the empty document vs. DELETE. I think either would work for me. Cullen _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Aug 12 14:12:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23150 for ; Tue, 12 Aug 2003 14:12:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mdcr-00052K-Ox for simple-archive@odin.ietf.org; Tue, 12 Aug 2003 14:12:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7CIC5Kj019358 for simple-archive@odin.ietf.org; Tue, 12 Aug 2003 14:12:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mdcr-000529-J9 for simple-web-archive@optimus.ietf.org; Tue, 12 Aug 2003 14:12:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23128; Tue, 12 Aug 2003 14:11:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mdco-0002oW-00; Tue, 12 Aug 2003 14:12:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19mdco-0002oT-00; Tue, 12 Aug 2003 14:12:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mdcn-00051c-Nb; Tue, 12 Aug 2003 14:12:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mdcR-000516-VL for simple@optimus.ietf.org; Tue, 12 Aug 2003 14:11:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23118 for ; Tue, 12 Aug 2003 14:11:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mdcP-0002o3-00 for simple@ietf.org; Tue, 12 Aug 2003 14:11:37 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19mdcO-0002nu-00 for simple@ietf.org; Tue, 12 Aug 2003 14:11:36 -0400 Received: from cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 12 Aug 2003 11:11:07 -0700 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h7CIB47F000312; Tue, 12 Aug 2003 11:11:04 -0700 (PDT) Received: from [128.107.170.103] ([128.107.170.103]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHA16729; Tue, 12 Aug 2003 11:11:03 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.1.2418 Subject: Re: [Simple] xcap and xpath From: Cullen Jennings To: Jonathan Rosenberg CC: Simple WG Message-ID: In-Reply-To: <3F391D4E.4030804@dynamicsoft.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 12 Aug 2003 11:11:02 -0700 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit At the bottom ... On 8/12/03 10:01 AM, "Jonathan Rosenberg" wrote: > inline. > > hardie@qualcomm.com wrote: > >> At 11:43 PM -0400 8/11/03, Jonathan Rosenberg wrote: >> >>>> >>>> If I do a post of foo/buddy/c and c exists it modifies the data. If c >>>> does >>>> not exist, it creates c, if the posted data is empty, it deletes c. >>>> Since >>>> this changes the document would return if foo/buddy was request, anyone >>>> subscribed to foo/buddy will get notified when this is done. >>> >>> >>> Correct. That is my proposal on how to support both insert and modify. >> >> >> Just as a clarification, do you mean POST or PUT? > > PUT. The plan is to not make use of POST at all. > >> PUT can obviously >> be used for create and modify; it is less clear that PUTting an empty >> document does exactly what you want. > > My original intent, and the way the current xcap doc is written, is > with DELETE in fact. I hadnt considered PUT of an empty doc, but after > Cullen mention it, it seemed reasonable to me. The desire is that it > should work as it does for any other kind of resource. So, the real > question is - what IS the HTTP semantic for PUT of an empty document? > Does the spec say? > > >> Note, however, that DELETE >> is a valid method in HTTP 1.x, and the combination of PUT (to create >> or modify) and DELETE (to, well, delete) probably covers the ground. > > Right. Per above that was the original intent, though we should say > something about PUT of empty documents I suspect, whether to forbid > it, or to say its allowed, really only clarifying for us what the http > intent is. > > Thanks, > Jonathan R. I did not have any reason for preferring the empty document vs. DELETE. I think either would work for me. Cullen _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Aug 12 14:38:58 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23874; Tue, 12 Aug 2003 14:38:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19me2v-00031L-00; Tue, 12 Aug 2003 14:39:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19me2u-00031I-00; Tue, 12 Aug 2003 14:39:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19me2u-0005se-E1; Tue, 12 Aug 2003 14:39:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19me2t-0005sT-EO for simple@optimus.ietf.org; Tue, 12 Aug 2003 14:38:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23871 for ; Tue, 12 Aug 2003 14:38:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19me2q-00031D-00 for simple@ietf.org; Tue, 12 Aug 2003 14:38:56 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19me2p-00030v-00 for simple@ietf.org; Tue, 12 Aug 2003 14:38:55 -0400 Received: from dynamicsoft.com ([63.113.47.242]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h7CIcE3m003329; Tue, 12 Aug 2003 14:38:16 -0400 (EDT) Message-ID: <3F393412.30608@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hardie@qualcomm.com CC: Cullen Jennings , Simple WG Subject: Re: [Simple] xcap and xpath References: <3F386250.8070702@dynamicsoft.com> <3F391D4E.4030804@dynamicsoft.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 12 Aug 2003 14:38:10 -0400 Content-Transfer-Encoding: 7bit hardie@qualcomm.com wrote: >> Right. Per above that was the original intent, though we should say >> something about PUT of empty documents I suspect, whether to forbid >> it, or to say its allowed, really only clarifying for us what the http >> intent is. > > > If you want the resource to continue to exist but to have zero-length > content, > updating it with a PUT of an empty resource would be the right choice; > if you want > the resource to cease to exist, using DELETE would be the right choice. OK. DELETE is definitely what we want. I'll be sure to clarify that. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Aug 12 14:39:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23920 for ; Tue, 12 Aug 2003 14:39:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19me2y-0005tK-B2 for simple-archive@odin.ietf.org; Tue, 12 Aug 2003 14:39:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7CId4YS022640 for simple-archive@odin.ietf.org; Tue, 12 Aug 2003 14:39:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19me2y-0005t5-5p for simple-web-archive@optimus.ietf.org; Tue, 12 Aug 2003 14:39:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23874; Tue, 12 Aug 2003 14:38:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19me2v-00031L-00; Tue, 12 Aug 2003 14:39:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19me2u-00031I-00; Tue, 12 Aug 2003 14:39:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19me2u-0005se-E1; Tue, 12 Aug 2003 14:39:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19me2t-0005sT-EO for simple@optimus.ietf.org; Tue, 12 Aug 2003 14:38:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23871 for ; Tue, 12 Aug 2003 14:38:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19me2q-00031D-00 for simple@ietf.org; Tue, 12 Aug 2003 14:38:56 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19me2p-00030v-00 for simple@ietf.org; Tue, 12 Aug 2003 14:38:55 -0400 Received: from dynamicsoft.com ([63.113.47.242]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h7CIcE3m003329; Tue, 12 Aug 2003 14:38:16 -0400 (EDT) Message-ID: <3F393412.30608@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hardie@qualcomm.com CC: Cullen Jennings , Simple WG Subject: Re: [Simple] xcap and xpath References: <3F386250.8070702@dynamicsoft.com> <3F391D4E.4030804@dynamicsoft.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 12 Aug 2003 14:38:10 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit hardie@qualcomm.com wrote: >> Right. Per above that was the original intent, though we should say >> something about PUT of empty documents I suspect, whether to forbid >> it, or to say its allowed, really only clarifying for us what the http >> intent is. > > > If you want the resource to continue to exist but to have zero-length > content, > updating it with a PUT of an empty resource would be the right choice; > if you want > the resource to cease to exist, using DELETE would be the right choice. OK. DELETE is definitely what we want. I'll be sure to clarify that. 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 Wed Aug 13 10:28:00 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21857; Wed, 13 Aug 2003 10:28:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mwbc-00021s-00; Wed, 13 Aug 2003 10:28:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19mwbb-00021p-00; Wed, 13 Aug 2003 10:28:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mwba-00011v-1M; Wed, 13 Aug 2003 10:28:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mwbI-00011Y-EC for simple@optimus.ietf.org; Wed, 13 Aug 2003 10:27:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21843 for ; Wed, 13 Aug 2003 10:27:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mwbG-00021e-00 for simple@ietf.org; Wed, 13 Aug 2003 10:27:42 -0400 Received: from hoemail2.lucent.com ([192.11.226.163] helo=hoemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 19mwbF-00021b-00 for simple@ietf.org; Wed, 13 Aug 2003 10:27:41 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by hoemail2.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h7DER7A23816; Wed, 13 Aug 2003 09:27:07 -0500 (CDT) Received: from lucent.com (il0015vkg1.ih.lucent.com [135.185.173.147]) by ihmail.ih.lucent.com (8.11.6+Sun/EMS-1.5 sol2) id h7DER6826500; Wed, 13 Aug 2003 09:27:06 -0500 (CDT) Message-ID: <3F3A4AA6.1090907@lucent.com> From: "Vijay K. Gurbani" Organization: Wireless Netwoks Group User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne CC: Simple WG Subject: Re: [Simple] CIPID: contact information References: <3F36E79E.3010909@cs.columbia.edu> In-Reply-To: <3F36E79E.3010909@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 13 Aug 2003 09:26:46 -0500 Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > I will be submitting > > http://www1.cs.columbia.edu/~hgs/sip/draft/cipid/draft-ietf-simple-cipid-00.html > > > shortly, the result of splitting the original RPIDS document. > Any last-minute pre-00 comments are most welcome. Prof. Schulzrinne: Sorry for the delay -- one comment: 1/ The I-D is fairly sparse, and it may have been your intent to keep it so. But, would it benefit provide a tie in with RPIDS up front. Something to this effect as a second paragraph in Introduction: "The elements described in this draft can be interspersed with RPIDS [2] elements in a presence document. While RPIDS contains a rich vocabulary which includes describing location and activity information about a presentity, the elements in this draft are most concerned with quantifying the presentity itself." Then comes the existing second paragraph, "We describe ..." Regards, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Wireless Networks Group/Internet Software and Services Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Aug 13 10:28:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21873 for ; Wed, 13 Aug 2003 10:28:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mwbg-00013Y-5g for simple-archive@odin.ietf.org; Wed, 13 Aug 2003 10:28:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7DES81H004060 for simple-archive@odin.ietf.org; Wed, 13 Aug 2003 10:28:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mwbf-00013P-Kx for simple-web-archive@optimus.ietf.org; Wed, 13 Aug 2003 10:28:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21857; Wed, 13 Aug 2003 10:28:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mwbc-00021s-00; Wed, 13 Aug 2003 10:28:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19mwbb-00021p-00; Wed, 13 Aug 2003 10:28:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mwba-00011v-1M; Wed, 13 Aug 2003 10:28:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mwbI-00011Y-EC for simple@optimus.ietf.org; Wed, 13 Aug 2003 10:27:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21843 for ; Wed, 13 Aug 2003 10:27:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mwbG-00021e-00 for simple@ietf.org; Wed, 13 Aug 2003 10:27:42 -0400 Received: from hoemail2.lucent.com ([192.11.226.163] helo=hoemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 19mwbF-00021b-00 for simple@ietf.org; Wed, 13 Aug 2003 10:27:41 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by hoemail2.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h7DER7A23816; Wed, 13 Aug 2003 09:27:07 -0500 (CDT) Received: from lucent.com (il0015vkg1.ih.lucent.com [135.185.173.147]) by ihmail.ih.lucent.com (8.11.6+Sun/EMS-1.5 sol2) id h7DER6826500; Wed, 13 Aug 2003 09:27:06 -0500 (CDT) Message-ID: <3F3A4AA6.1090907@lucent.com> From: "Vijay K. Gurbani" Organization: Wireless Netwoks Group User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne CC: Simple WG Subject: Re: [Simple] CIPID: contact information References: <3F36E79E.3010909@cs.columbia.edu> In-Reply-To: <3F36E79E.3010909@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 13 Aug 2003 09:26:46 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > I will be submitting > > http://www1.cs.columbia.edu/~hgs/sip/draft/cipid/draft-ietf-simple-cipid-00.html > > > shortly, the result of splitting the original RPIDS document. > Any last-minute pre-00 comments are most welcome. Prof. Schulzrinne: Sorry for the delay -- one comment: 1/ The I-D is fairly sparse, and it may have been your intent to keep it so. But, would it benefit provide a tie in with RPIDS up front. Something to this effect as a second paragraph in Introduction: "The elements described in this draft can be interspersed with RPIDS [2] elements in a presence document. While RPIDS contains a rich vocabulary which includes describing location and activity information about a presentity, the elements in this draft are most concerned with quantifying the presentity itself." Then comes the existing second paragraph, "We describe ..." Regards, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Wireless Networks Group/Internet Software and Services Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Aug 14 10:28:02 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12047; Thu, 14 Aug 2003 10:28:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nJ5B-0002e7-00; Thu, 14 Aug 2003 10:28:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19nJ5B-0002e2-00; Thu, 14 Aug 2003 10:28:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nJ57-0004xW-4L; Thu, 14 Aug 2003 10:28:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nJ4i-0004ww-PQ for simple@optimus.ietf.org; Thu, 14 Aug 2003 10:27:36 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11963; Thu, 14 Aug 2003 10:27:31 -0400 (EDT) Message-Id: <200308141427.KAA11963@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-pres-filter-reqs-02.txt Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 14 Aug 2003 10:27:30 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : Requirements for Presence Specific Event Notification Filtering Author(s) : H. Khartabil, E. Leppanen, T. Moran Filename : draft-ietf-simple-pres-filter-reqs-02.txt Pages : 12 Date : 2003-8-14 This document defines a set of structured requirements whereby a presence information subscriber may select specific information to be received in the presence infomation notification sent by the notifier. The purpose is to limit the content and frequency of notifications so that only essential information on a need basis is delivered by the server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-pres-filter-reqs-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-pres-filter-reqs-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-pres-filter-reqs-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-8-14091802.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-pres-filter-reqs-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-pres-filter-reqs-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-14091802.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Aug 14 10:28:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12074 for ; Thu, 14 Aug 2003 10:28:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nJ5E-0004yg-Ob for simple-archive@odin.ietf.org; Thu, 14 Aug 2003 10:28:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7EES8ir019132 for simple-archive@odin.ietf.org; Thu, 14 Aug 2003 10:28:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nJ5E-0004yV-L4 for simple-web-archive@optimus.ietf.org; Thu, 14 Aug 2003 10:28:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12047; Thu, 14 Aug 2003 10:28:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nJ5B-0002e7-00; Thu, 14 Aug 2003 10:28:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19nJ5B-0002e2-00; Thu, 14 Aug 2003 10:28:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nJ57-0004xW-4L; Thu, 14 Aug 2003 10:28:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nJ4i-0004ww-PQ for simple@optimus.ietf.org; Thu, 14 Aug 2003 10:27:36 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11963; Thu, 14 Aug 2003 10:27:31 -0400 (EDT) Message-Id: <200308141427.KAA11963@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-pres-filter-reqs-02.txt Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 14 Aug 2003 10:27:30 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : Requirements for Presence Specific Event Notification Filtering Author(s) : H. Khartabil, E. Leppanen, T. Moran Filename : draft-ietf-simple-pres-filter-reqs-02.txt Pages : 12 Date : 2003-8-14 This document defines a set of structured requirements whereby a presence information subscriber may select specific information to be received in the presence infomation notification sent by the notifier. The purpose is to limit the content and frequency of notifications so that only essential information on a need basis is delivered by the server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-pres-filter-reqs-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-pres-filter-reqs-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-pres-filter-reqs-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-8-14091802.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-pres-filter-reqs-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-pres-filter-reqs-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-14091802.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 Aug 19 06:47:01 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04222; Tue, 19 Aug 2003 06:47:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19p412-0006Tj-00; Tue, 19 Aug 2003 06:47:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19p411-0006Te-00; Tue, 19 Aug 2003 06:47:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19p40z-0007r3-63; Tue, 19 Aug 2003 06:47:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19p40e-0007qn-Qx for simple@optimus.ietf.org; Tue, 19 Aug 2003 06:46:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04207 for ; Tue, 19 Aug 2003 06:46:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19p40a-0006TK-00 for simple@ietf.org; Tue, 19 Aug 2003 06:46:36 -0400 Received: from david.siemens.de ([192.35.17.14]) by ietf-mx with esmtp (Exim 4.12) id 19p40a-0006TH-00 for simple@ietf.org; Tue, 19 Aug 2003 06:46:36 -0400 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by david.siemens.de (8.11.7/8.11.7) with ESMTP id h7JAkax20449 for ; Tue, 19 Aug 2003 12:46:36 +0200 (MEST) Received: from mchh9ega.mchh.siemens.de (mchh9ega.mchh.siemens.de [139.21.194.56]) by mail2.siemens.de (8.11.7/8.11.7) with ESMTP id h7JAkZG18127 for ; Tue, 19 Aug 2003 12:46:35 +0200 (MEST) Received: by mchh9ega.mchh.siemens.de with Internet Mail Service (5.5.2653.19) id ; Tue, 19 Aug 2003 12:46:35 +0200 Message-ID: From: Werkstudent8 SAL To: "'simple@ietf.org'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Simple] draft-ietf-simple-xcap-00.txt - Examples Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.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, 19 Aug 2003 12:46:34 +0200 From: "Stefan Mecke" Hi all, I just read through the examples in draft-ietf-simple-xcap-00.txt and I'm a bit confused about the first example: First, a user Bill creates a new presence-list, initially with no users in it: .... Next, Bill adds an entry to the list: PUT http://xcap.example.com/services/presence-lists/users/bill/fr.xml? presence-lists/list[@name="friends"] HTTP/1.1 Content-Type:text/plain Bill Doe It is Bill's presences list and he adds Bill to his "friends"-list? So he adds himself or is it another Bill? Or do you always have to be on your own presence-lists? If this is not the case, then chosing a different name might be better. Thanks, S. Mecke _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Aug 19 06:47:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04238 for ; Tue, 19 Aug 2003 06:47:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19p416-0007rp-Sb for simple-archive@odin.ietf.org; Tue, 19 Aug 2003 06:47:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7JAl8KR030237 for simple-archive@odin.ietf.org; Tue, 19 Aug 2003 06:47:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19p416-0007rc-M1 for simple-web-archive@optimus.ietf.org; Tue, 19 Aug 2003 06:47:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04222; Tue, 19 Aug 2003 06:47:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19p412-0006Tj-00; Tue, 19 Aug 2003 06:47:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19p411-0006Te-00; Tue, 19 Aug 2003 06:47:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19p40z-0007r3-63; Tue, 19 Aug 2003 06:47:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19p40e-0007qn-Qx for simple@optimus.ietf.org; Tue, 19 Aug 2003 06:46:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04207 for ; Tue, 19 Aug 2003 06:46:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19p40a-0006TK-00 for simple@ietf.org; Tue, 19 Aug 2003 06:46:36 -0400 Received: from david.siemens.de ([192.35.17.14]) by ietf-mx with esmtp (Exim 4.12) id 19p40a-0006TH-00 for simple@ietf.org; Tue, 19 Aug 2003 06:46:36 -0400 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by david.siemens.de (8.11.7/8.11.7) with ESMTP id h7JAkax20449 for ; Tue, 19 Aug 2003 12:46:36 +0200 (MEST) Received: from mchh9ega.mchh.siemens.de (mchh9ega.mchh.siemens.de [139.21.194.56]) by mail2.siemens.de (8.11.7/8.11.7) with ESMTP id h7JAkZG18127 for ; Tue, 19 Aug 2003 12:46:35 +0200 (MEST) Received: by mchh9ega.mchh.siemens.de with Internet Mail Service (5.5.2653.19) id ; Tue, 19 Aug 2003 12:46:35 +0200 Message-ID: From: Werkstudent8 SAL To: "'simple@ietf.org'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Simple] draft-ietf-simple-xcap-00.txt - Examples Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.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, 19 Aug 2003 12:46:34 +0200 From: "Stefan Mecke" Hi all, I just read through the examples in draft-ietf-simple-xcap-00.txt and I'm a bit confused about the first example: First, a user Bill creates a new presence-list, initially with no users in it: .... Next, Bill adds an entry to the list: PUT http://xcap.example.com/services/presence-lists/users/bill/fr.xml? presence-lists/list[@name="friends"] HTTP/1.1 Content-Type:text/plain Bill Doe It is Bill's presences list and he adds Bill to his "friends"-list? So he adds himself or is it another Bill? Or do you always have to be on your own presence-lists? If this is not the case, then chosing a different name might be better. Thanks, S. Mecke _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Aug 22 02:28:03 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06497; Fri, 22 Aug 2003 02:28:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19q5P2-0007LQ-00; Fri, 22 Aug 2003 02:28:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19q5P2-0007LL-00; Fri, 22 Aug 2003 02:28:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19q5Oz-0000OV-UJ; Fri, 22 Aug 2003 02:28:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19q5Ov-0000O2-2r for simple@optimus.ietf.org; Fri, 22 Aug 2003 02:27:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06483 for ; Fri, 22 Aug 2003 02:27:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19q5Or-0007L5-00 for simple@ietf.org; Fri, 22 Aug 2003 02:27:53 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19q5Oq-0007Kz-00 for simple@ietf.org; Fri, 22 Aug 2003 02:27:52 -0400 Received: from dynamicsoft.com ([63.113.46.16]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h7M6RNUg003790; Fri, 22 Aug 2003 02:27:24 -0400 (EDT) Message-ID: <3F45B7C7.1050100@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Werkstudent8 SAL CC: "'simple@ietf.org'" Subject: Re: [Simple] draft-ietf-simple-xcap-00.txt - Examples 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, 22 Aug 2003 02:27:19 -0400 Content-Transfer-Encoding: 7bit Oops, this is a mistake. Bill would not normally add himself to his buddy list. I will correct in the next revision. Thanks, Jonathan R. Werkstudent8 SAL wrote: > From: "Stefan Mecke" > > Hi all, > > I just read through the examples in draft-ietf-simple-xcap-00.txt and I'm a > bit confused about the first example: > > First, a user Bill creates a new presence-list, initially with no > users in it: > .... > Next, Bill adds an entry to the list: > > PUT > http://xcap.example.com/services/presence-lists/users/bill/fr.xml? > presence-lists/list[@name="friends"] HTTP/1.1 > Content-Type:text/plain > > > Bill Doe > > > It is Bill's presences list and he adds Bill to his "friends"-list? So he > adds himself or is it another Bill? Or do you always have to be on your own > presence-lists? > If this is not the case, then chosing a different name might be better. > > Thanks, > S. Mecke > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Aug 22 02:28:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06545 for ; Fri, 22 Aug 2003 02:28:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19q5P7-0000Pc-R7 for simple-archive@odin.ietf.org; Fri, 22 Aug 2003 02:28:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7M6S95N001585 for simple-archive@odin.ietf.org; Fri, 22 Aug 2003 02:28:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19q5P7-0000PU-5w for simple-web-archive@optimus.ietf.org; Fri, 22 Aug 2003 02:28:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06497; Fri, 22 Aug 2003 02:28:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19q5P2-0007LQ-00; Fri, 22 Aug 2003 02:28:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19q5P2-0007LL-00; Fri, 22 Aug 2003 02:28:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19q5Oz-0000OV-UJ; Fri, 22 Aug 2003 02:28:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19q5Ov-0000O2-2r for simple@optimus.ietf.org; Fri, 22 Aug 2003 02:27:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06483 for ; Fri, 22 Aug 2003 02:27:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19q5Or-0007L5-00 for simple@ietf.org; Fri, 22 Aug 2003 02:27:53 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19q5Oq-0007Kz-00 for simple@ietf.org; Fri, 22 Aug 2003 02:27:52 -0400 Received: from dynamicsoft.com ([63.113.46.16]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h7M6RNUg003790; Fri, 22 Aug 2003 02:27:24 -0400 (EDT) Message-ID: <3F45B7C7.1050100@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Werkstudent8 SAL CC: "'simple@ietf.org'" Subject: Re: [Simple] draft-ietf-simple-xcap-00.txt - Examples 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, 22 Aug 2003 02:27:19 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Oops, this is a mistake. Bill would not normally add himself to his buddy list. I will correct in the next revision. Thanks, Jonathan R. Werkstudent8 SAL wrote: > From: "Stefan Mecke" > > Hi all, > > I just read through the examples in draft-ietf-simple-xcap-00.txt and I'm a > bit confused about the first example: > > First, a user Bill creates a new presence-list, initially with no > users in it: > .... > Next, Bill adds an entry to the list: > > PUT > http://xcap.example.com/services/presence-lists/users/bill/fr.xml? > presence-lists/list[@name="friends"] HTTP/1.1 > Content-Type:text/plain > > > Bill Doe > > > It is Bill's presences list and he adds Bill to his "friends"-list? So he > adds himself or is it another Bill? Or do you always have to be on your own > presence-lists? > If this is not the case, then chosing a different name might be better. > > Thanks, > S. Mecke > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Aug 29 12:01:12 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07040; Fri, 29 Aug 2003 12:01:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sl7w-0005tV-9p; Fri, 29 Aug 2003 11:25:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19skMr-0003A1-El for simple@optimus.ietf.org; Fri, 29 Aug 2003 10:36:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29212 for ; Fri, 29 Aug 2003 10:36:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19skMp-0004ol-00 for simple@ietf.org; Fri, 29 Aug 2003 10:36:47 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19skMn-0004oF-00 for simple@ietf.org; Fri, 29 Aug 2003 10:36:45 -0400 Received: from dynamicsoft.com ([63.113.47.242]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h7TEaBUg007077; Fri, 29 Aug 2003 10:36:13 -0400 (EDT) Message-ID: <3F4F64D5.7020508@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Simple WG , gk@ninebynine.org Content-Type: multipart/mixed; boundary="------------080301020009010705030906" Subject: [Simple] [Fwd: Re: NETCONF WG meeting minutes for IETF #57] Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.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, 29 Aug 2003 10:36:05 -0400 This is a multi-part message in MIME format. --------------080301020009010705030906 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Graham Klyne posted this note on netconf that has some insights which I think can benefit us. Pay attention to this statement: Graham writes: > I would be very wary about using XPath as the basis for selective > access to XMLConf data. XPath, by design, provides selection on > the syntactic structure of XML: it has been suggested elsewhere > (e.g. in the netconf protocol document, IIRC) that the data model > is separate from the protocol framework (which I think is a good > approach). But the query/selection syntax should be related to the > data model, not to the carrier syntax. I have seen difficulties > arise with different XML-based applications where people tried to > use XPath selection for an XML format used to carry a data model > that was somewhat different from the XML carrier syntax. If the > data model does not map directly onto the XML syntax, then XPath > selection may well prove inadequate to make appropriate selection > in the configuration data. I think this summarizes nicely the concerns I have had about using xpath for filtering. I am also going to be removing it from element identification in the next xcap-auth rev. -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 --------------080301020009010705030906 Content-Type: message/rfc822; name="Re: NETCONF WG meeting minutes for IETF #57" Content-Disposition: inline; filename="Re: NETCONF WG meeting minutes for IETF #57" Received: from mail2.dynamicsoft.com (192.168.4.31 [192.168.4.31]) by DYN-EXCH-01.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id RQ9AMWDW; Fri, 29 Aug 2003 03:02:46 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by mail2.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h7T703hp000182; Fri, 29 Aug 2003 03:00:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19sdCT-0001KU-K7 for netconf-data@psg.com; Fri, 29 Aug 2003 06:57:37 +0000 Received: from [208.184.79.253] (helo=jay.songbird.com) by psg.com with esmtp (Exim 4.22) id 19sQov-000Mys-KL for netconf@ops.ietf.org; Thu, 28 Aug 2003 17:44:29 +0000 Received: from Rincewind.ninebynine.org (jay.songbird.com [208.184.79.253]) by jay.songbird.com (8.11.6/8.11.3) with ESMTP id h7SHiE023575 for ; Thu, 28 Aug 2003 10:44:15 -0700 Message-Id: <5.1.0.14.2.20030827080833.023f2a08@127.0.0.1> X-Sender: gk@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 27 Aug 2003 09:44:12 +0100 To: netconf@ops.ietf.org From: Graham Klyne Subject: Re: NETCONF WG meeting minutes for IETF #57 In-Reply-To: <4.3.2.7.2.20030812194018.0249bfb0@fedex.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed X-Spam-Status: No, hits=-0.9 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable At 19:41 12/08/03 -0700, Andy Bierman wrote: >Hi, > >Here are the minutes for the NETCONF WG meeting held in Vienna. Here are some thoughts about some of the design directions being = suggested... >1) The major issues facing the working group were listed >without much discussion: > > Transport mappings > BEEP, HTTPS, SSH? I don't think that BEEP and SOAP should be viewed as mutually=20 exclusive. There is a proposal (somewhere) for SOAP over BEEP. If = this=20 means SOAP-over-HTTP, then I think it would help to avoid possible=20 confusion to say this explicitly. If you mean the pre-standard version = of=20 SOAP that is specifically HTTP-based, then that should be stated = clearly. > RPC Layer > SOAP encoding, xmlconf RPC, or simple request/response This is the *real* possible role for SOAP: SOAP, as currently = specified=20 [1], defines SOAP message structures separately from transport = bindings. [1] W3C Weekly News - 27 June 2003: [[ SOAP Version 1.2 Is a W3C Recommendation The World Wide Web Consortium released SOAP Version 1.2 as a W3C Recommendation. The Recommendation is four documents: the "SOAP Version 1.2 Primer," "SOAP Version 1.2 Messaging Framework," "SOAP Version 1.2 Adjuncts," and the "SOAP Version 1.2 Assertions and Test Collection." Developed by the W3C XML Protocol Working Group, SOAP Version 1.2 is a lightweight protocol for exchanging structured information in a decentralized, distributed environment such as the Web. Read the press release, the testimonials, the changes and benefits and the FAQ. Visit the Web services home page. http://www.w3.org/2003/06/soap12-pressrelease http://www.w3.org/2003/06/soap12-testimonial http://www.w3.org/2003/06/soap11-soap12.html http://www.w3.org/2003/06/soap12faq.html http://www.w3.org/2002/ws/ ]] > Advanced XML features > WSDL templates, XPath filtering, more? Can WSDL be applied to non-SOAP message structures? (I don't know, but = I=20 had the impression that SOAP - in some version - was a prerequisite for = using WSDL.) > Protocol Operations > Add, Modify, Delete Variants > Advanced operations: mandatory or optional > Multi-device operation support > Error Handling > Notifications > Security > Authorization model, user identity [...] >There was agreement that XPath support would be a good idea, >but that it should be optional, and a special capability flag >for XPath support is needed. I would be very wary about using XPath as the basis for selective = access to=20 XMLConf data. XPath, by design, provides selection on the syntactic=20 structure of XML: it has been suggested elsewhere (e.g. in the netconf = protocol document, IIRC) that the data model is separate from the = protocol=20 framework (which I think is a good approach). But the query/selection=20 syntax should be related to the data model, not to the carrier syntax. = I=20 have seen difficulties arise with different XML-based applications = where=20 people tried to use XPath selection for an XML format used to carry a = data=20 model that was somewhat different from the XML carrier syntax. If the = data=20 model does not map directly onto the XML syntax, then XPath selection = may=20 well prove inadequate to make appropriate selection in the = configuration data. (See also my thoughts about a data model, below.) >2.3) Transport > >WSDL over SOAP should be used as the transport binding. Eh? I thought WSDL is a service *description* language, not a = transport=20 binding. The closest I can make sense of this is that WSDL is used to=20 *describe* a transport binding for XMLConf. >New mappings for SOAP over SSH may be defined, and used >in addition to the SOAP over HTTP and SOAP over BEEP >bindings already defined. Ah, good, these are stated more explicitly. >There were some strong comments from the group on this issue. >There seems to be some significant support for using SOAP >for the transport. NETCONF over BEEP is wrong because this >will cause the WEB Services model to be reinvented. I'd be interested in a reference that describes *the* web services=20 model. I could maybe accept the above comment about reinventing the = web=20 services model if I knew what it meant. [...] >5.2) Configuration templates > >A request was made for configuration template support. >This is an open issue. It is not clear if this would >be part of the protocol operations, part of the data models, >or both. Perhaps XPath can be used to supply some of this >functionality. Ouch! That seems like the tail wagging the dog, or a hammer-and-nails=20 position (as in when you have a hammer ...). See above comments about=20 XPath. Perhaps there is a role for XPath eventually, but absent=20 understanding of the requirement I wouldn't want to think about that. [...] >5.4) 'Get' protocol operation > >The XMLCONF draft includes two 'Get' operations, one for >configuration data and one for everything else. A request >was made to change this scheme. It should be possible to >retrieve all types of data with a single request. It >was agreed that a 'get all' type of operation is needed. IIRC, configuration vs everything else is an issue of static=20 (configuration) data vs dynamic (status) data. Or do I miss something? = I=20 do find myself wondering if it is truly possible to draw such a=20 hard-and-fast distinction, and if one has appropriate selection model = then=20 the distinction may be redundant. (e.g. if a device IP address is a = static=20 assignment obtained by DHCP, which is it?) [...] Some thoughts about a data model -------------------------------- These comments are not presented here as an idea for active = consideration=20 by this group, but reflect some private work I have been doing, = off-and-on,=20 over the past few months. I raise them here to underscore my concerns=20 about the possible problems of locking the data selection model too = closely=20 to the the XML syntactic model in general, and XPath in particular. I have done a small amount of work to use RDF [2] to represent = information=20 about network device configuration and access policies [3]. While my = early=20 experiments raised a number of problems using current RDF tools for = this=20 purpose, they did also suggest some promising advantages. RDF is a general purpose language for representing information in the = web,=20 which grew out of the PICS (web site metadta) effort, and is now being = used=20 in a number of diverse applications, including online resource = cataloguing,=20 software agents, message routing, schedule descriptions, etc. It's key = features are use of URIs as identifiers, a data model based on a = directed,=20 labelled graph, and an XML-based transfer syntax. The design of RDF = makes=20 it easy to combine information from various sources into a single=20 expression. It also has a formal semantic structure which provides an=20 initial basis for generic processing of application data. (Roughly, = RDF=20 does for application data semantics what XML does for application data=20 syntax: it provides a framework for building upon.) So why apply the RDF model to network configuration data? My thoughts = include: (a) a ready path to include existing SNMP MIB structures (b) fairly direct encoding of entity-relation data models defined = using,=20 say, UML (c) easy integration of common standard configuration data with=20 vendor-specific extensions (d) availability of toolkits for processing information (semantic=20 processing as well as syntax handling) e.g. [4] (e) possibilities for using generic tools for direct generation of=20 configuration data from access policy descriptions (this is an area in=20 which I am doing some development work to investigate using Haskell [5] = as=20 a "scripting language" for dealing with application data semantics, in=20 particular network configuration and monitoring activities in relation = to=20 the user-defined policies for network use). The above claims beg some justification, which I don't attempt to do = here. My point is to illustrate, in a fairly concrete fashion, the = possibility of=20 a data model that is carried in XML syntax, but which does not itself=20 directly reflect the underlying XML data model. XML is (roughly) a=20 labelled-and-annotated tree structure, where RDF uses a labelled = directed=20 graph structure. Query/selection that works for a tree structufre = doesn't=20 necessarily work for other data models. In the case of RDF, there is a = whole raft of experimental work to create a simple query framework, = which=20 seems to be rapidly converging on some common core ideas (which happen = to=20 considerably simpler than XPath-style selectors) [6]. #g -- [2] http://www.ninebynine.org/Links.html#RDF [3] http://www.ninebynine.org/SWAD-E/Intro.html#HomeNetAccessDemo [4] http://www.ninebynine.org/Links.html#RDF-Tools [5] http://www.haskell.org/ [6] RDF query work: http://www.w3.org/2001/11/13-RDF-Query-Rules/ http://www.w3.org/TandS/QL/QL98/pp/rdfquery.html http://ilrt.org/discovery/2002/04/query/ = http://www-uk.hpl.hp.com/people/afs/Abstracts/ISWC2002-SquishQL-Abstract= .html = http://www-uk.hpl.hp.com/people/afs/Papers/ISWC%202002%20-%20SquishQL.pd= f etc. ------------ Graham Klyne _________ GK@ninebynine.org ___|_o_o_o_|_=AC \____________/ (nb Helva) ~~~~~~~~~~~~~~~~~~ @Reading, River Thames http://www.ninebynine.org/Travels/2003Aug-Thames/Intro.html -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: --------------080301020009010705030906-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Aug 29 14:18:09 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20316 for ; Fri, 29 Aug 2003 14:18:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sm6E-0000BN-Fq for simple-archive@odin.ietf.org; Fri, 29 Aug 2003 12:27:48 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7TGRjE4000694 for simple-archive@odin.ietf.org; Fri, 29 Aug 2003 12:27:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19slge-0007Zt-GL for simple-web-archive@optimus.ietf.org; Fri, 29 Aug 2003 12:01:20 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07040; Fri, 29 Aug 2003 12:01:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sl7w-0005tV-9p; Fri, 29 Aug 2003 11:25:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19skMr-0003A1-El for simple@optimus.ietf.org; Fri, 29 Aug 2003 10:36:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29212 for ; Fri, 29 Aug 2003 10:36:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19skMp-0004ol-00 for simple@ietf.org; Fri, 29 Aug 2003 10:36:47 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19skMn-0004oF-00 for simple@ietf.org; Fri, 29 Aug 2003 10:36:45 -0400 Received: from dynamicsoft.com ([63.113.47.242]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h7TEaBUg007077; Fri, 29 Aug 2003 10:36:13 -0400 (EDT) Message-ID: <3F4F64D5.7020508@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Simple WG , gk@ninebynine.org Content-Type: multipart/mixed; boundary="------------080301020009010705030906" Subject: [Simple] [Fwd: Re: NETCONF WG meeting minutes for IETF #57] Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.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, 29 Aug 2003 10:36:05 -0400 This is a multi-part message in MIME format. --------------080301020009010705030906 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Graham Klyne posted this note on netconf that has some insights which I think can benefit us. Pay attention to this statement: Graham writes: > I would be very wary about using XPath as the basis for selective > access to XMLConf data. XPath, by design, provides selection on > the syntactic structure of XML: it has been suggested elsewhere > (e.g. in the netconf protocol document, IIRC) that the data model > is separate from the protocol framework (which I think is a good > approach). But the query/selection syntax should be related to the > data model, not to the carrier syntax. I have seen difficulties > arise with different XML-based applications where people tried to > use XPath selection for an XML format used to carry a data model > that was somewhat different from the XML carrier syntax. If the > data model does not map directly onto the XML syntax, then XPath > selection may well prove inadequate to make appropriate selection > in the configuration data. I think this summarizes nicely the concerns I have had about using xpath for filtering. I am also going to be removing it from element identification in the next xcap-auth rev. -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 --------------080301020009010705030906 Content-Type: message/rfc822; name="Re: NETCONF WG meeting minutes for IETF #57" Content-Disposition: inline; filename="Re: NETCONF WG meeting minutes for IETF #57" Received: from mail2.dynamicsoft.com (192.168.4.31 [192.168.4.31]) by DYN-EXCH-01.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id RQ9AMWDW; Fri, 29 Aug 2003 03:02:46 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by mail2.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h7T703hp000182; Fri, 29 Aug 2003 03:00:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19sdCT-0001KU-K7 for netconf-data@psg.com; Fri, 29 Aug 2003 06:57:37 +0000 Received: from [208.184.79.253] (helo=jay.songbird.com) by psg.com with esmtp (Exim 4.22) id 19sQov-000Mys-KL for netconf@ops.ietf.org; Thu, 28 Aug 2003 17:44:29 +0000 Received: from Rincewind.ninebynine.org (jay.songbird.com [208.184.79.253]) by jay.songbird.com (8.11.6/8.11.3) with ESMTP id h7SHiE023575 for ; Thu, 28 Aug 2003 10:44:15 -0700 Message-Id: <5.1.0.14.2.20030827080833.023f2a08@127.0.0.1> X-Sender: gk@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 27 Aug 2003 09:44:12 +0100 To: netconf@ops.ietf.org From: Graham Klyne Subject: Re: NETCONF WG meeting minutes for IETF #57 In-Reply-To: <4.3.2.7.2.20030812194018.0249bfb0@fedex.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed X-Spam-Status: No, hits=-0.9 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable At 19:41 12/08/03 -0700, Andy Bierman wrote: >Hi, > >Here are the minutes for the NETCONF WG meeting held in Vienna. Here are some thoughts about some of the design directions being = suggested... >1) The major issues facing the working group were listed >without much discussion: > > Transport mappings > BEEP, HTTPS, SSH? I don't think that BEEP and SOAP should be viewed as mutually=20 exclusive. There is a proposal (somewhere) for SOAP over BEEP. If = this=20 means SOAP-over-HTTP, then I think it would help to avoid possible=20 confusion to say this explicitly. If you mean the pre-standard version = of=20 SOAP that is specifically HTTP-based, then that should be stated = clearly. > RPC Layer > SOAP encoding, xmlconf RPC, or simple request/response This is the *real* possible role for SOAP: SOAP, as currently = specified=20 [1], defines SOAP message structures separately from transport = bindings. [1] W3C Weekly News - 27 June 2003: [[ SOAP Version 1.2 Is a W3C Recommendation The World Wide Web Consortium released SOAP Version 1.2 as a W3C Recommendation. The Recommendation is four documents: the "SOAP Version 1.2 Primer," "SOAP Version 1.2 Messaging Framework," "SOAP Version 1.2 Adjuncts," and the "SOAP Version 1.2 Assertions and Test Collection." Developed by the W3C XML Protocol Working Group, SOAP Version 1.2 is a lightweight protocol for exchanging structured information in a decentralized, distributed environment such as the Web. Read the press release, the testimonials, the changes and benefits and the FAQ. Visit the Web services home page. http://www.w3.org/2003/06/soap12-pressrelease http://www.w3.org/2003/06/soap12-testimonial http://www.w3.org/2003/06/soap11-soap12.html http://www.w3.org/2003/06/soap12faq.html http://www.w3.org/2002/ws/ ]] > Advanced XML features > WSDL templates, XPath filtering, more? Can WSDL be applied to non-SOAP message structures? (I don't know, but = I=20 had the impression that SOAP - in some version - was a prerequisite for = using WSDL.) > Protocol Operations > Add, Modify, Delete Variants > Advanced operations: mandatory or optional > Multi-device operation support > Error Handling > Notifications > Security > Authorization model, user identity [...] >There was agreement that XPath support would be a good idea, >but that it should be optional, and a special capability flag >for XPath support is needed. I would be very wary about using XPath as the basis for selective = access to=20 XMLConf data. XPath, by design, provides selection on the syntactic=20 structure of XML: it has been suggested elsewhere (e.g. in the netconf = protocol document, IIRC) that the data model is separate from the = protocol=20 framework (which I think is a good approach). But the query/selection=20 syntax should be related to the data model, not to the carrier syntax. = I=20 have seen difficulties arise with different XML-based applications = where=20 people tried to use XPath selection for an XML format used to carry a = data=20 model that was somewhat different from the XML carrier syntax. If the = data=20 model does not map directly onto the XML syntax, then XPath selection = may=20 well prove inadequate to make appropriate selection in the = configuration data. (See also my thoughts about a data model, below.) >2.3) Transport > >WSDL over SOAP should be used as the transport binding. Eh? I thought WSDL is a service *description* language, not a = transport=20 binding. The closest I can make sense of this is that WSDL is used to=20 *describe* a transport binding for XMLConf. >New mappings for SOAP over SSH may be defined, and used >in addition to the SOAP over HTTP and SOAP over BEEP >bindings already defined. Ah, good, these are stated more explicitly. >There were some strong comments from the group on this issue. >There seems to be some significant support for using SOAP >for the transport. NETCONF over BEEP is wrong because this >will cause the WEB Services model to be reinvented. I'd be interested in a reference that describes *the* web services=20 model. I could maybe accept the above comment about reinventing the = web=20 services model if I knew what it meant. [...] >5.2) Configuration templates > >A request was made for configuration template support. >This is an open issue. It is not clear if this would >be part of the protocol operations, part of the data models, >or both. Perhaps XPath can be used to supply some of this >functionality. Ouch! That seems like the tail wagging the dog, or a hammer-and-nails=20 position (as in when you have a hammer ...). See above comments about=20 XPath. Perhaps there is a role for XPath eventually, but absent=20 understanding of the requirement I wouldn't want to think about that. [...] >5.4) 'Get' protocol operation > >The XMLCONF draft includes two 'Get' operations, one for >configuration data and one for everything else. A request >was made to change this scheme. It should be possible to >retrieve all types of data with a single request. It >was agreed that a 'get all' type of operation is needed. IIRC, configuration vs everything else is an issue of static=20 (configuration) data vs dynamic (status) data. Or do I miss something? = I=20 do find myself wondering if it is truly possible to draw such a=20 hard-and-fast distinction, and if one has appropriate selection model = then=20 the distinction may be redundant. (e.g. if a device IP address is a = static=20 assignment obtained by DHCP, which is it?) [...] Some thoughts about a data model -------------------------------- These comments are not presented here as an idea for active = consideration=20 by this group, but reflect some private work I have been doing, = off-and-on,=20 over the past few months. I raise them here to underscore my concerns=20 about the possible problems of locking the data selection model too = closely=20 to the the XML syntactic model in general, and XPath in particular. I have done a small amount of work to use RDF [2] to represent = information=20 about network device configuration and access policies [3]. While my = early=20 experiments raised a number of problems using current RDF tools for = this=20 purpose, they did also suggest some promising advantages. RDF is a general purpose language for representing information in the = web,=20 which grew out of the PICS (web site metadta) effort, and is now being = used=20 in a number of diverse applications, including online resource = cataloguing,=20 software agents, message routing, schedule descriptions, etc. It's key = features are use of URIs as identifiers, a data model based on a = directed,=20 labelled graph, and an XML-based transfer syntax. The design of RDF = makes=20 it easy to combine information from various sources into a single=20 expression. It also has a formal semantic structure which provides an=20 initial basis for generic processing of application data. (Roughly, = RDF=20 does for application data semantics what XML does for application data=20 syntax: it provides a framework for building upon.) So why apply the RDF model to network configuration data? My thoughts = include: (a) a ready path to include existing SNMP MIB structures (b) fairly direct encoding of entity-relation data models defined = using,=20 say, UML (c) easy integration of common standard configuration data with=20 vendor-specific extensions (d) availability of toolkits for processing information (semantic=20 processing as well as syntax handling) e.g. [4] (e) possibilities for using generic tools for direct generation of=20 configuration data from access policy descriptions (this is an area in=20 which I am doing some development work to investigate using Haskell [5] = as=20 a "scripting language" for dealing with application data semantics, in=20 particular network configuration and monitoring activities in relation = to=20 the user-defined policies for network use). The above claims beg some justification, which I don't attempt to do = here. My point is to illustrate, in a fairly concrete fashion, the = possibility of=20 a data model that is carried in XML syntax, but which does not itself=20 directly reflect the underlying XML data model. XML is (roughly) a=20 labelled-and-annotated tree structure, where RDF uses a labelled = directed=20 graph structure. Query/selection that works for a tree structufre = doesn't=20 necessarily work for other data models. In the case of RDF, there is a = whole raft of experimental work to create a simple query framework, = which=20 seems to be rapidly converging on some common core ideas (which happen = to=20 considerably simpler than XPath-style selectors) [6]. #g -- [2] http://www.ninebynine.org/Links.html#RDF [3] http://www.ninebynine.org/SWAD-E/Intro.html#HomeNetAccessDemo [4] http://www.ninebynine.org/Links.html#RDF-Tools [5] http://www.haskell.org/ [6] RDF query work: http://www.w3.org/2001/11/13-RDF-Query-Rules/ http://www.w3.org/TandS/QL/QL98/pp/rdfquery.html http://ilrt.org/discovery/2002/04/query/ = http://www-uk.hpl.hp.com/people/afs/Abstracts/ISWC2002-SquishQL-Abstract= .html = http://www-uk.hpl.hp.com/people/afs/Papers/ISWC%202002%20-%20SquishQL.pd= f etc. ------------ Graham Klyne _________ GK@ninebynine.org ___|_o_o_o_|_=AC \____________/ (nb Helva) ~~~~~~~~~~~~~~~~~~ @Reading, River Thames http://www.ninebynine.org/Travels/2003Aug-Thames/Intro.html -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: --------------080301020009010705030906-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Aug 29 15:41:12 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28497; Fri, 29 Aug 2003 15:41:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sp7V-000554-00; Fri, 29 Aug 2003 15:41:17 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19sp7U-00054z-00; Fri, 29 Aug 2003 15:41:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19snxY-0005h8-Aq; Fri, 29 Aug 2003 14:26:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19smBq-0000Lh-To for simple@optimus.ietf.org; Fri, 29 Aug 2003 12:33:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10838 for ; Fri, 29 Aug 2003 12:33:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19slzq-00071E-00 for simple@ietf.org; Fri, 29 Aug 2003 12:21:10 -0400 Received: from ns.execdsl.net ([208.184.15.238] helo=EXECDSL.COM) by ietf-mx with esmtp (Exim 4.12) id 19slzo-00070x-00 for simple@ietf.org; Fri, 29 Aug 2003 12:21:08 -0400 Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 5324078; Fri, 29 Aug 2003 12:21:01 -0400 Message-Id: <5.1.0.14.0.20030829121757.02167de0@mail.stevecrocker.com> X-Sender: joel@stevecrocker.com@mail.stevecrocker.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 To: Simple WG From: "Joel M. Halpern" Subject: Re: [Simple] [Fwd: Re: NETCONF WG meeting minutes for IETF #57] Cc: gk@ninebynine.org In-Reply-To: <3F4F64D5.7020508@dynamicsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 29 Aug 2003 12:20:56 -0400 Content-Transfer-Encoding: quoted-printable It appears that the premise for the concern is the situation where "the=20 data model does not map directly onto the XML syntax." Now, sometimes that is unavoidable. But, in this environment where we are defining the information to be=20 represented and defining the XML Schema at the same time, one would expect= =20 them to map well. In fact, if the syntactic structure of our XML does not= =20 match the semantic structure of the information we are carrying, we are=20 going to seriously confuse our users. Why would we want to do that? Yours, Joel M. Halpern PS: In the netconf environment, the underlying data model is so messy as to= =20 almost mandate a mismatch. I do not believe that is the case for the work= =20 we are doing here. At 10:36 AM 8/29/2003 -0400, Jonathan Rosenberg wrote: >Graham Klyne posted this note on netconf that has some insights which >I think can benefit us. Pay attention to this statement: > >Graham writes: >>I would be very wary about using XPath as the basis for selective >>access to XMLConf data. XPath, by design, provides selection on >>the syntactic structure of XML: it has been suggested elsewhere >>(e.g. in the netconf protocol document, IIRC) that the data model >>is separate from the protocol framework (which I think is a good >>approach). But the query/selection syntax should be related to the >>data model, not to the carrier syntax. I have seen difficulties >>arise with different XML-based applications where people tried to >>use XPath selection for an XML format used to carry a data model >>that was somewhat different from the XML carrier syntax. If the >>data model does not map directly onto the XML syntax, then XPath >>selection may well prove inadequate to make appropriate selection >>in the configuration data. > >I think this summarizes nicely the concerns I have had about using xpath=20 >for filtering. I am also going to be removing it from element=20 >identification in the next xcap-auth rev. > >-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 > > >Received: from mail2.dynamicsoft.com (192.168.4.31 [192.168.4.31]) by=20 >DYN-EXCH-01.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail=20 >Service Version 5.5.2653.13) > id RQ9AMWDW; Fri, 29 Aug 2003 03:02:46 -0400 >Received: from psg.com (mailnull@psg.com [147.28.0.62]) > by mail2.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id=20 > h7T703hp000182; > Fri, 29 Aug 2003 03:00:04 -0400 (EDT) >Received: from lserv by psg.com with local (Exim 4.22) > id 19sdCT-0001KU-K7 > for netconf-data@psg.com; Fri, 29 Aug 2003 06:57:37 +0000 >Received: from [208.184.79.253] (helo=3Djay.songbird.com) > by psg.com with esmtp (Exim 4.22) > id 19sQov-000Mys-KL > for netconf@ops.ietf.org; Thu, 28 Aug 2003 17:44:29 +0000 >Received: from Rincewind.ninebynine.org (jay.songbird.com [208.184.79.253]) > by jay.songbird.com (8.11.6/8.11.3) with ESMTP id h7SHiE023575 > for ; Thu, 28 Aug 2003 10:44:15 -0700 >Message-Id: <5.1.0.14.2.20030827080833.023f2a08@127.0.0.1> >X-Sender: gk@127.0.0.1 >X-Mailer: QUALCOMM Windows Eudora Version 5.1 >Date: Wed, 27 Aug 2003 09:44:12 +0100 >To: netconf@ops.ietf.org >From: Graham Klyne >Subject: Re: NETCONF WG meeting minutes for IETF #57 >In-Reply-To: <4.3.2.7.2.20030812194018.0249bfb0@fedex.cisco.com> >Mime-Version: 1.0 >Content-Type: text/plain; charset=3D"iso-8859-1"; format=3Dflowed >X-Spam-Status: No, hits=3D-0.9 required=3D5.0 > tests=3DEMAIL_ATTRIBUTION,IN_REP_TO > version=3D2.55 >X-Spam-Level: >X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) >Sender: owner-netconf@ops.ietf.org >Precedence: bulk > >At 19:41 12/08/03 -0700, Andy Bierman wrote: >>Hi, >> >>Here are the minutes for the NETCONF WG meeting held in Vienna. > >Here are some thoughts about some of the design directions being= suggested... > >>1) The major issues facing the working group were listed >>without much discussion: >> >> Transport mappings >> BEEP, HTTPS, SSH? > >I don't think that BEEP and SOAP should be viewed as mutually=20 >exclusive. There is a proposal (somewhere) for SOAP over BEEP. If this=20 >means SOAP-over-HTTP, then I think it would help to avoid possible=20 >confusion to say this explicitly. If you mean the pre-standard version of= =20 >SOAP that is specifically HTTP-based, then that should be stated clearly. > >> RPC Layer >> SOAP encoding, xmlconf RPC, or simple request/response > >This is the *real* possible role for SOAP: SOAP, as currently specified=20 >[1], defines SOAP message structures separately from transport bindings. > >[1] W3C Weekly News - 27 June 2003: >[[ > SOAP Version 1.2 Is a W3C Recommendation > > The World Wide Web Consortium released SOAP Version 1.2 as a W3C > Recommendation. The Recommendation is four documents: the "SOAP > Version 1.2 Primer," "SOAP Version 1.2 Messaging Framework," "SOAP > Version 1.2 Adjuncts," and the "SOAP Version 1.2 Assertions and Test > Collection." Developed by the W3C XML Protocol Working Group, SOAP > Version 1.2 is a lightweight protocol for exchanging structured > information in a decentralized, distributed environment such as the > Web. Read the press release, the testimonials, the changes and > benefits and the FAQ. Visit the Web services home page. > > http://www.w3.org/2003/06/soap12-pressrelease > http://www.w3.org/2003/06/soap12-testimonial > http://www.w3.org/2003/06/soap11-soap12.html > http://www.w3.org/2003/06/soap12faq.html > http://www.w3.org/2002/ws/ >]] > >> Advanced XML features >> WSDL templates, XPath filtering, more? > >Can WSDL be applied to non-SOAP message structures? (I don't know, but I= =20 >had the impression that SOAP - in some version - was a prerequisite for=20 >using WSDL.) > >> Protocol Operations >> Add, Modify, Delete Variants >> Advanced operations: mandatory or optional >> Multi-device operation support >> Error Handling >> Notifications >> Security >> Authorization model, user identity > >[...] > >>There was agreement that XPath support would be a good idea, >>but that it should be optional, and a special capability flag >>for XPath support is needed. > >I would be very wary about using XPath as the basis for selective access=20 >to XMLConf data. XPath, by design, provides selection on the syntactic=20 >structure of XML: it has been suggested elsewhere (e.g. in the netconf=20 >protocol document, IIRC) that the data model is separate from the protocol= =20 >framework (which I think is a good approach). But the query/selection=20 >syntax should be related to the data model, not to the carrier syntax. I= =20 >have seen difficulties arise with different XML-based applications where=20 >people tried to use XPath selection for an XML format used to carry a data= =20 >model that was somewhat different from the XML carrier syntax. If the=20 >data model does not map directly onto the XML syntax, then XPath selection= =20 >may well prove inadequate to make appropriate selection in the=20 >configuration data. > >(See also my thoughts about a data model, below.) > > >>2.3) Transport >> >>WSDL over SOAP should be used as the transport binding. > >Eh? I thought WSDL is a service *description* language, not a transport=20 >binding. The closest I can make sense of this is that WSDL is used to=20 >*describe* a transport binding for XMLConf. > >>New mappings for SOAP over SSH may be defined, and used >>in addition to the SOAP over HTTP and SOAP over BEEP >>bindings already defined. > >Ah, good, these are stated more explicitly. > >>There were some strong comments from the group on this issue. >>There seems to be some significant support for using SOAP >>for the transport. NETCONF over BEEP is wrong because this >>will cause the WEB Services model to be reinvented. > >I'd be interested in a reference that describes *the* web services=20 >model. I could maybe accept the above comment about reinventing the web=20 >services model if I knew what it meant. > >[...] > > >>5.2) Configuration templates >> >>A request was made for configuration template support. >>This is an open issue. It is not clear if this would >>be part of the protocol operations, part of the data models, >>or both. Perhaps XPath can be used to supply some of this >>functionality. > >Ouch! That seems like the tail wagging the dog, or a hammer-and-nails=20 >position (as in when you have a hammer ...). See above comments about=20 >XPath. Perhaps there is a role for XPath eventually, but absent=20 >understanding of the requirement I wouldn't want to think about that. > >[...] > > >>5.4) 'Get' protocol operation >> >>The XMLCONF draft includes two 'Get' operations, one for >>configuration data and one for everything else. A request >>was made to change this scheme. It should be possible to >>retrieve all types of data with a single request. It >>was agreed that a 'get all' type of operation is needed. > >IIRC, configuration vs everything else is an issue of static=20 >(configuration) data vs dynamic (status) data. Or do I miss something? I= =20 >do find myself wondering if it is truly possible to draw such a=20 >hard-and-fast distinction, and if one has appropriate selection model then= =20 >the distinction may be redundant. (e.g. if a device IP address is a=20 >static assignment obtained by DHCP, which is it?) > >[...] > > >Some thoughts about a data model >-------------------------------- > >These comments are not presented here as an idea for active consideration= =20 >by this group, but reflect some private work I have been doing,=20 >off-and-on, over the past few months. I raise them here to underscore my= =20 >concerns about the possible problems of locking the data selection model=20 >too closely to the the XML syntactic model in general, and XPath in= particular. > >I have done a small amount of work to use RDF [2] to represent information= =20 >about network device configuration and access policies [3]. While my=20 >early experiments raised a number of problems using current RDF tools for= =20 >this purpose, they did also suggest some promising advantages. > >RDF is a general purpose language for representing information in the web,= =20 >which grew out of the PICS (web site metadta) effort, and is now being=20 >used in a number of diverse applications, including online resource=20 >cataloguing, software agents, message routing, schedule descriptions,=20 >etc. It's key features are use of URIs as identifiers, a data model based= =20 >on a directed, labelled graph, and an XML-based transfer syntax. The=20 >design of RDF makes it easy to combine information from various sources=20 >into a single expression. It also has a formal semantic structure which=20 >provides an initial basis for generic processing of application=20 >data. (Roughly, RDF does for application data semantics what XML does for= =20 >application data syntax: it provides a framework for building upon.) > >So why apply the RDF model to network configuration data? My thoughts=20 >include: >(a) a ready path to include existing SNMP MIB structures >(b) fairly direct encoding of entity-relation data models defined using,=20 >say, UML >(c) easy integration of common standard configuration data with=20 >vendor-specific extensions >(d) availability of toolkits for processing information (semantic=20 >processing as well as syntax handling) e.g. [4] >(e) possibilities for using generic tools for direct generation of=20 >configuration data from access policy descriptions (this is an area in=20 >which I am doing some development work to investigate using Haskell [5] as= =20 >a "scripting language" for dealing with application data semantics, in=20 >particular network configuration and monitoring activities in relation to= =20 >the user-defined policies for network use). > >The above claims beg some justification, which I don't attempt to do here. > >My point is to illustrate, in a fairly concrete fashion, the possibility=20 >of a data model that is carried in XML syntax, but which does not itself=20 >directly reflect the underlying XML data model. XML is (roughly) a=20 >labelled-and-annotated tree structure, where RDF uses a labelled directed= =20 >graph structure. Query/selection that works for a tree structufre doesn't= =20 >necessarily work for other data models. In the case of RDF, there is a=20 >whole raft of experimental work to create a simple query framework, which= =20 >seems to be rapidly converging on some common core ideas (which happen to= =20 >considerably simpler than XPath-style selectors) [6]. > >#g >-- > >[2] http://www.ninebynine.org/Links.html#RDF > >[3] http://www.ninebynine.org/SWAD-E/Intro.html#HomeNetAccessDemo > >[4] http://www.ninebynine.org/Links.html#RDF-Tools > >[5] http://www.haskell.org/ > >[6] RDF query work: > http://www.w3.org/2001/11/13-RDF-Query-Rules/ > http://www.w3.org/TandS/QL/QL98/pp/rdfquery.html > http://ilrt.org/discovery/2002/04/query/ >=20 >http://www-uk.hpl.hp.com/people/afs/Abstracts/ISWC2002-SquishQL-Abstract.ht= ml >=20 >http://www-uk.hpl.hp.com/people/afs/Papers/ISWC%202002%20-%20SquishQL.pdf > etc. > > >------------ >Graham Klyne _________ >GK@ninebynine.org ___|_o_o_o_|_=AC > \____________/ >(nb Helva) ~~~~~~~~~~~~~~~~~~ @Reading, River Thames >http://www.ninebynine.org/Travels/2003Aug-Thames/Intro.html > > > > >-- >to unsubscribe send a message to netconf-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Aug 29 19:34:50 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18316 for ; Fri, 29 Aug 2003 19:34:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19srma-0007XS-Hj for simple-archive@odin.ietf.org; Fri, 29 Aug 2003 18:31:53 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7TMVpON028968 for simple-archive@odin.ietf.org; Fri, 29 Aug 2003 18:31:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sp7Y-0000by-4r for simple-web-archive@optimus.ietf.org; Fri, 29 Aug 2003 15:41:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28497; Fri, 29 Aug 2003 15:41:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sp7V-000554-00; Fri, 29 Aug 2003 15:41:17 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19sp7U-00054z-00; Fri, 29 Aug 2003 15:41:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19snxY-0005h8-Aq; Fri, 29 Aug 2003 14:26:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19smBq-0000Lh-To for simple@optimus.ietf.org; Fri, 29 Aug 2003 12:33:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10838 for ; Fri, 29 Aug 2003 12:33:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19slzq-00071E-00 for simple@ietf.org; Fri, 29 Aug 2003 12:21:10 -0400 Received: from ns.execdsl.net ([208.184.15.238] helo=EXECDSL.COM) by ietf-mx with esmtp (Exim 4.12) id 19slzo-00070x-00 for simple@ietf.org; Fri, 29 Aug 2003 12:21:08 -0400 Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 5324078; Fri, 29 Aug 2003 12:21:01 -0400 Message-Id: <5.1.0.14.0.20030829121757.02167de0@mail.stevecrocker.com> X-Sender: joel@stevecrocker.com@mail.stevecrocker.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 To: Simple WG From: "Joel M. Halpern" Subject: Re: [Simple] [Fwd: Re: NETCONF WG meeting minutes for IETF #57] Cc: gk@ninebynine.org In-Reply-To: <3F4F64D5.7020508@dynamicsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 29 Aug 2003 12:20:56 -0400 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable It appears that the premise for the concern is the situation where "the=20 data model does not map directly onto the XML syntax." Now, sometimes that is unavoidable. But, in this environment where we are defining the information to be=20 represented and defining the XML Schema at the same time, one would expect= =20 them to map well. In fact, if the syntactic structure of our XML does not= =20 match the semantic structure of the information we are carrying, we are=20 going to seriously confuse our users. Why would we want to do that? Yours, Joel M. Halpern PS: In the netconf environment, the underlying data model is so messy as to= =20 almost mandate a mismatch. I do not believe that is the case for the work= =20 we are doing here. At 10:36 AM 8/29/2003 -0400, Jonathan Rosenberg wrote: >Graham Klyne posted this note on netconf that has some insights which >I think can benefit us. Pay attention to this statement: > >Graham writes: >>I would be very wary about using XPath as the basis for selective >>access to XMLConf data. XPath, by design, provides selection on >>the syntactic structure of XML: it has been suggested elsewhere >>(e.g. in the netconf protocol document, IIRC) that the data model >>is separate from the protocol framework (which I think is a good >>approach). But the query/selection syntax should be related to the >>data model, not to the carrier syntax. I have seen difficulties >>arise with different XML-based applications where people tried to >>use XPath selection for an XML format used to carry a data model >>that was somewhat different from the XML carrier syntax. If the >>data model does not map directly onto the XML syntax, then XPath >>selection may well prove inadequate to make appropriate selection >>in the configuration data. > >I think this summarizes nicely the concerns I have had about using xpath=20 >for filtering. I am also going to be removing it from element=20 >identification in the next xcap-auth rev. > >-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 > > >Received: from mail2.dynamicsoft.com (192.168.4.31 [192.168.4.31]) by=20 >DYN-EXCH-01.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail=20 >Service Version 5.5.2653.13) > id RQ9AMWDW; Fri, 29 Aug 2003 03:02:46 -0400 >Received: from psg.com (mailnull@psg.com [147.28.0.62]) > by mail2.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id=20 > h7T703hp000182; > Fri, 29 Aug 2003 03:00:04 -0400 (EDT) >Received: from lserv by psg.com with local (Exim 4.22) > id 19sdCT-0001KU-K7 > for netconf-data@psg.com; Fri, 29 Aug 2003 06:57:37 +0000 >Received: from [208.184.79.253] (helo=3Djay.songbird.com) > by psg.com with esmtp (Exim 4.22) > id 19sQov-000Mys-KL > for netconf@ops.ietf.org; Thu, 28 Aug 2003 17:44:29 +0000 >Received: from Rincewind.ninebynine.org (jay.songbird.com [208.184.79.253]) > by jay.songbird.com (8.11.6/8.11.3) with ESMTP id h7SHiE023575 > for ; Thu, 28 Aug 2003 10:44:15 -0700 >Message-Id: <5.1.0.14.2.20030827080833.023f2a08@127.0.0.1> >X-Sender: gk@127.0.0.1 >X-Mailer: QUALCOMM Windows Eudora Version 5.1 >Date: Wed, 27 Aug 2003 09:44:12 +0100 >To: netconf@ops.ietf.org >From: Graham Klyne >Subject: Re: NETCONF WG meeting minutes for IETF #57 >In-Reply-To: <4.3.2.7.2.20030812194018.0249bfb0@fedex.cisco.com> >Mime-Version: 1.0 >Content-Type: text/plain; charset=3D"iso-8859-1"; format=3Dflowed >X-Spam-Status: No, hits=3D-0.9 required=3D5.0 > tests=3DEMAIL_ATTRIBUTION,IN_REP_TO > version=3D2.55 >X-Spam-Level: >X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) >Sender: owner-netconf@ops.ietf.org >Precedence: bulk > >At 19:41 12/08/03 -0700, Andy Bierman wrote: >>Hi, >> >>Here are the minutes for the NETCONF WG meeting held in Vienna. > >Here are some thoughts about some of the design directions being= suggested... > >>1) The major issues facing the working group were listed >>without much discussion: >> >> Transport mappings >> BEEP, HTTPS, SSH? > >I don't think that BEEP and SOAP should be viewed as mutually=20 >exclusive. There is a proposal (somewhere) for SOAP over BEEP. If this=20 >means SOAP-over-HTTP, then I think it would help to avoid possible=20 >confusion to say this explicitly. If you mean the pre-standard version of= =20 >SOAP that is specifically HTTP-based, then that should be stated clearly. > >> RPC Layer >> SOAP encoding, xmlconf RPC, or simple request/response > >This is the *real* possible role for SOAP: SOAP, as currently specified=20 >[1], defines SOAP message structures separately from transport bindings. > >[1] W3C Weekly News - 27 June 2003: >[[ > SOAP Version 1.2 Is a W3C Recommendation > > The World Wide Web Consortium released SOAP Version 1.2 as a W3C > Recommendation. The Recommendation is four documents: the "SOAP > Version 1.2 Primer," "SOAP Version 1.2 Messaging Framework," "SOAP > Version 1.2 Adjuncts," and the "SOAP Version 1.2 Assertions and Test > Collection." Developed by the W3C XML Protocol Working Group, SOAP > Version 1.2 is a lightweight protocol for exchanging structured > information in a decentralized, distributed environment such as the > Web. Read the press release, the testimonials, the changes and > benefits and the FAQ. Visit the Web services home page. > > http://www.w3.org/2003/06/soap12-pressrelease > http://www.w3.org/2003/06/soap12-testimonial > http://www.w3.org/2003/06/soap11-soap12.html > http://www.w3.org/2003/06/soap12faq.html > http://www.w3.org/2002/ws/ >]] > >> Advanced XML features >> WSDL templates, XPath filtering, more? > >Can WSDL be applied to non-SOAP message structures? (I don't know, but I= =20 >had the impression that SOAP - in some version - was a prerequisite for=20 >using WSDL.) > >> Protocol Operations >> Add, Modify, Delete Variants >> Advanced operations: mandatory or optional >> Multi-device operation support >> Error Handling >> Notifications >> Security >> Authorization model, user identity > >[...] > >>There was agreement that XPath support would be a good idea, >>but that it should be optional, and a special capability flag >>for XPath support is needed. > >I would be very wary about using XPath as the basis for selective access=20 >to XMLConf data. XPath, by design, provides selection on the syntactic=20 >structure of XML: it has been suggested elsewhere (e.g. in the netconf=20 >protocol document, IIRC) that the data model is separate from the protocol= =20 >framework (which I think is a good approach). But the query/selection=20 >syntax should be related to the data model, not to the carrier syntax. I= =20 >have seen difficulties arise with different XML-based applications where=20 >people tried to use XPath selection for an XML format used to carry a data= =20 >model that was somewhat different from the XML carrier syntax. If the=20 >data model does not map directly onto the XML syntax, then XPath selection= =20 >may well prove inadequate to make appropriate selection in the=20 >configuration data. > >(See also my thoughts about a data model, below.) > > >>2.3) Transport >> >>WSDL over SOAP should be used as the transport binding. > >Eh? I thought WSDL is a service *description* language, not a transport=20 >binding. The closest I can make sense of this is that WSDL is used to=20 >*describe* a transport binding for XMLConf. > >>New mappings for SOAP over SSH may be defined, and used >>in addition to the SOAP over HTTP and SOAP over BEEP >>bindings already defined. > >Ah, good, these are stated more explicitly. > >>There were some strong comments from the group on this issue. >>There seems to be some significant support for using SOAP >>for the transport. NETCONF over BEEP is wrong because this >>will cause the WEB Services model to be reinvented. > >I'd be interested in a reference that describes *the* web services=20 >model. I could maybe accept the above comment about reinventing the web=20 >services model if I knew what it meant. > >[...] > > >>5.2) Configuration templates >> >>A request was made for configuration template support. >>This is an open issue. It is not clear if this would >>be part of the protocol operations, part of the data models, >>or both. Perhaps XPath can be used to supply some of this >>functionality. > >Ouch! That seems like the tail wagging the dog, or a hammer-and-nails=20 >position (as in when you have a hammer ...). See above comments about=20 >XPath. Perhaps there is a role for XPath eventually, but absent=20 >understanding of the requirement I wouldn't want to think about that. > >[...] > > >>5.4) 'Get' protocol operation >> >>The XMLCONF draft includes two 'Get' operations, one for >>configuration data and one for everything else. A request >>was made to change this scheme. It should be possible to >>retrieve all types of data with a single request. It >>was agreed that a 'get all' type of operation is needed. > >IIRC, configuration vs everything else is an issue of static=20 >(configuration) data vs dynamic (status) data. Or do I miss something? I= =20 >do find myself wondering if it is truly possible to draw such a=20 >hard-and-fast distinction, and if one has appropriate selection model then= =20 >the distinction may be redundant. (e.g. if a device IP address is a=20 >static assignment obtained by DHCP, which is it?) > >[...] > > >Some thoughts about a data model >-------------------------------- > >These comments are not presented here as an idea for active consideration= =20 >by this group, but reflect some private work I have been doing,=20 >off-and-on, over the past few months. I raise them here to underscore my= =20 >concerns about the possible problems of locking the data selection model=20 >too closely to the the XML syntactic model in general, and XPath in= particular. > >I have done a small amount of work to use RDF [2] to represent information= =20 >about network device configuration and access policies [3]. While my=20 >early experiments raised a number of problems using current RDF tools for= =20 >this purpose, they did also suggest some promising advantages. > >RDF is a general purpose language for representing information in the web,= =20 >which grew out of the PICS (web site metadta) effort, and is now being=20 >used in a number of diverse applications, including online resource=20 >cataloguing, software agents, message routing, schedule descriptions,=20 >etc. It's key features are use of URIs as identifiers, a data model based= =20 >on a directed, labelled graph, and an XML-based transfer syntax. The=20 >design of RDF makes it easy to combine information from various sources=20 >into a single expression. It also has a formal semantic structure which=20 >provides an initial basis for generic processing of application=20 >data. (Roughly, RDF does for application data semantics what XML does for= =20 >application data syntax: it provides a framework for building upon.) > >So why apply the RDF model to network configuration data? My thoughts=20 >include: >(a) a ready path to include existing SNMP MIB structures >(b) fairly direct encoding of entity-relation data models defined using,=20 >say, UML >(c) easy integration of common standard configuration data with=20 >vendor-specific extensions >(d) availability of toolkits for processing information (semantic=20 >processing as well as syntax handling) e.g. [4] >(e) possibilities for using generic tools for direct generation of=20 >configuration data from access policy descriptions (this is an area in=20 >which I am doing some development work to investigate using Haskell [5] as= =20 >a "scripting language" for dealing with application data semantics, in=20 >particular network configuration and monitoring activities in relation to= =20 >the user-defined policies for network use). > >The above claims beg some justification, which I don't attempt to do here. > >My point is to illustrate, in a fairly concrete fashion, the possibility=20 >of a data model that is carried in XML syntax, but which does not itself=20 >directly reflect the underlying XML data model. XML is (roughly) a=20 >labelled-and-annotated tree structure, where RDF uses a labelled directed= =20 >graph structure. Query/selection that works for a tree structufre doesn't= =20 >necessarily work for other data models. In the case of RDF, there is a=20 >whole raft of experimental work to create a simple query framework, which= =20 >seems to be rapidly converging on some common core ideas (which happen to= =20 >considerably simpler than XPath-style selectors) [6]. > >#g >-- > >[2] http://www.ninebynine.org/Links.html#RDF > >[3] http://www.ninebynine.org/SWAD-E/Intro.html#HomeNetAccessDemo > >[4] http://www.ninebynine.org/Links.html#RDF-Tools > >[5] http://www.haskell.org/ > >[6] RDF query work: > http://www.w3.org/2001/11/13-RDF-Query-Rules/ > http://www.w3.org/TandS/QL/QL98/pp/rdfquery.html > http://ilrt.org/discovery/2002/04/query/ >=20 >http://www-uk.hpl.hp.com/people/afs/Abstracts/ISWC2002-SquishQL-Abstract.ht= ml >=20 >http://www-uk.hpl.hp.com/people/afs/Papers/ISWC%202002%20-%20SquishQL.pdf > etc. > > >------------ >Graham Klyne _________ >GK@ninebynine.org ___|_o_o_o_|_=AC > \____________/ >(nb Helva) ~~~~~~~~~~~~~~~~~~ @Reading, River Thames >http://www.ninebynine.org/Travels/2003Aug-Thames/Intro.html > > > > >-- >to unsubscribe send a message to netconf-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Aug 29 22:14:36 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28980; Fri, 29 Aug 2003 22:14:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19svGD-0000sE-00; Fri, 29 Aug 2003 22:14:41 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19svGC-0000s9-00; Fri, 29 Aug 2003 22:14:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19stkx-0004Kr-Nk; Fri, 29 Aug 2003 20:38:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sohP-0007tl-6y for simple@optimus.ietf.org; Fri, 29 Aug 2003 15:14:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25495 for ; Fri, 29 Aug 2003 15:14:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sohN-0004DI-00 for simple@ietf.org; Fri, 29 Aug 2003 15:14:17 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 19sohM-0004DB-00 for simple@ietf.org; Fri, 29 Aug 2003 15:14:16 -0400 Received: from magnum.cs.columbia.edu (IDENT:root@magnum.cs.columbia.edu [128.59.16.117]) by cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h7TJEFcm029269; Fri, 29 Aug 2003 15:14:15 -0400 (EDT) Received: from cs.columbia.edu (path.cs.columbia.edu [128.59.19.143]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h7TJEEG24712; Fri, 29 Aug 2003 15:14:14 -0400 Message-ID: <3F4FA606.3020207@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030827 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg , simple@ietf.org Subject: Re: [Simple] [Fwd: Re: NETCONF WG meeting minutes for IETF #57] References: <3F4F64D5.7020508@dynamicsoft.com> In-Reply-To: <3F4F64D5.7020508@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 29 Aug 2003 15:14:14 -0400 Content-Transfer-Encoding: 7bit This makes sense to me, but what is the alternative? It would be nice if there was one way of identifying logical components of XML, rather than each spec or even each WG making up their own. Does the DOM model offer an alternative? Jonathan Rosenberg wrote: > Graham Klyne posted this note on netconf that has some insights which > I think can benefit us. Pay attention to this statement: > > Graham writes: > >> I would be very wary about using XPath as the basis for selective >> access to XMLConf data. XPath, by design, provides selection on >> the syntactic structure of XML: it has been suggested elsewhere >> (e.g. in the netconf protocol document, IIRC) that the data model >> is separate from the protocol framework (which I think is a good >> approach). But the query/selection syntax should be related to the >> data model, not to the carrier syntax. I have seen difficulties >> arise with different XML-based applications where people tried to >> use XPath selection for an XML format used to carry a data model >> that was somewhat different from the XML carrier syntax. If the >> data model does not map directly onto the XML syntax, then XPath >> selection may well prove inadequate to make appropriate selection >> in the configuration data. > > > I think this summarizes nicely the concerns I have had about using xpath > for filtering. I am also going to be removing it from element > identification in the next xcap-auth rev. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Aug 29 23:54:54 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06749; Fri, 29 Aug 2003 23:54:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19swpH-0005Ak-00; Fri, 29 Aug 2003 23:54:59 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19swpG-0005Af-00; Fri, 29 Aug 2003 23:54:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19svBL-0000d6-Dp; Fri, 29 Aug 2003 22:09:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sqnk-0005L3-B9 for simple@optimus.ietf.org; Fri, 29 Aug 2003 17:29:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06881 for ; Fri, 29 Aug 2003 17:28:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sqnh-00009r-00 for simple@ietf.org; Fri, 29 Aug 2003 17:28:57 -0400 Received: from web41506.mail.yahoo.com ([66.218.93.89]) by ietf-mx with smtp (Exim 4.12) id 19sqng-000093-00 for simple@ietf.org; Fri, 29 Aug 2003 17:28:57 -0400 Message-ID: <20030829212826.95093.qmail@web41506.mail.yahoo.com> Received: from [131.107.3.70] by web41506.mail.yahoo.com via HTTP; Fri, 29 Aug 2003 14:28:26 PDT From: Sean Olson Subject: Re: [Simple] [Fwd: Re: NETCONF WG meeting minutes for IETF #57] To: "Joel M. Halpern" , Simple WG Cc: gk@ninebynine.org In-Reply-To: <5.1.0.14.0.20030829121757.02167de0@mail.stevecrocker.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 29 Aug 2003 14:28:26 -0700 (PDT) I agree. I would expect a strong correlation between the XML schema and the underlying data model. If they did not match, why would you invest the effort in the XML schema in the first place? If the choice is XML, use XML wisely and to full advantage. XPath is a natural extension of this design path. Cheers, Sean --- "Joel M. Halpern" wrote: > It appears that the premise for the concern is the > situation where "the > data model does not map directly onto the XML > syntax." > Now, sometimes that is unavoidable. > But, in this environment where we are defining the > information to be > represented and defining the XML Schema at the same > time, one would expect > them to map well. In fact, if the syntactic > structure of our XML does not > match the semantic structure of the information we > are carrying, we are > going to seriously confuse our users. Why would we > want to do that? > > Yours, > Joel M. Halpern > > PS: In the netconf environment, the underlying data > model is so messy as to > almost mandate a mismatch. I do not believe that is > the case for the work > we are doing here. > > At 10:36 AM 8/29/2003 -0400, Jonathan Rosenberg > wrote: > >Graham Klyne posted this note on netconf that has > some insights which > >I think can benefit us. Pay attention to this > statement: > > > >Graham writes: > >>I would be very wary about using XPath as the > basis for selective > >>access to XMLConf data. XPath, by design, > provides selection on > >>the syntactic structure of XML: it has been > suggested elsewhere > >>(e.g. in the netconf protocol document, IIRC) that > the data model > >>is separate from the protocol framework (which I > think is a good > >>approach). But the query/selection syntax should > be related to the > >>data model, not to the carrier syntax. I have > seen difficulties > >>arise with different XML-based applications where > people tried to > >>use XPath selection for an XML format used to > carry a data model > >>that was somewhat different from the XML carrier > syntax. If the > >>data model does not map directly onto the XML > syntax, then XPath > >>selection may well prove inadequate to make > appropriate selection > >>in the configuration data. > > > >I think this summarizes nicely the concerns I have > had about using xpath > >for filtering. I am also going to be removing it > from element > >identification in the next xcap-auth rev. > > > >-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 > > > > > >Received: from mail2.dynamicsoft.com (192.168.4.31 > [192.168.4.31]) by > >DYN-EXCH-01.dynamicsoft.com with SMTP (Microsoft > Exchange Internet Mail > >Service Version 5.5.2653.13) > > id RQ9AMWDW; Fri, 29 Aug 2003 03:02:46 > -0400 > >Received: from psg.com (mailnull@psg.com > [147.28.0.62]) > > by mail2.dynamicsoft.com (8.12.8/8.12.8) > with ESMTP id > > h7T703hp000182; > > Fri, 29 Aug 2003 03:00:04 -0400 (EDT) > >Received: from lserv by psg.com with local (Exim > 4.22) > > id 19sdCT-0001KU-K7 > > for netconf-data@psg.com; Fri, 29 Aug 2003 > 06:57:37 +0000 > >Received: from [208.184.79.253] > (helo=jay.songbird.com) > > by psg.com with esmtp (Exim 4.22) > > id 19sQov-000Mys-KL > > for netconf@ops.ietf.org; Thu, 28 Aug 2003 > 17:44:29 +0000 > >Received: from Rincewind.ninebynine.org > (jay.songbird.com [208.184.79.253]) > > by jay.songbird.com (8.11.6/8.11.3) with > ESMTP id h7SHiE023575 > > for ; Thu, 28 Aug > 2003 10:44:15 -0700 > >Message-Id: > <5.1.0.14.2.20030827080833.023f2a08@127.0.0.1> > >X-Sender: gk@127.0.0.1 > >X-Mailer: QUALCOMM Windows Eudora Version 5.1 > >Date: Wed, 27 Aug 2003 09:44:12 +0100 > >To: netconf@ops.ietf.org > >From: Graham Klyne > >Subject: Re: NETCONF WG meeting minutes for IETF > #57 > >In-Reply-To: > <4.3.2.7.2.20030812194018.0249bfb0@fedex.cisco.com> > >Mime-Version: 1.0 > >Content-Type: text/plain; charset="iso-8859-1"; > format=flowed > >X-Spam-Status: No, hits=-0.9 required=5.0 > > tests=EMAIL_ATTRIBUTION,IN_REP_TO > > version=2.55 > >X-Spam-Level: > >X-Spam-Checker-Version: SpamAssassin 2.55 > (1.174.2.19-2003-05-19-exp) > >Sender: owner-netconf@ops.ietf.org > >Precedence: bulk > > > >At 19:41 12/08/03 -0700, Andy Bierman wrote: > >>Hi, > >> > >>Here are the minutes for the NETCONF WG meeting > held in Vienna. > > > >Here are some thoughts about some of the design > directions being suggested... > > > >>1) The major issues facing the working group were > listed > >>without much discussion: > >> > >> Transport mappings > >> BEEP, HTTPS, SSH? > > > >I don't think that BEEP and SOAP should be viewed > as mutually > >exclusive. There is a proposal (somewhere) for > SOAP over BEEP. If this > >means SOAP-over-HTTP, then I think it would help to > avoid possible > >confusion to say this explicitly. If you mean the > pre-standard version of > >SOAP that is specifically HTTP-based, then that > should be stated clearly. > > > >> RPC Layer > >> SOAP encoding, xmlconf RPC, or simple > request/response > > > >This is the *real* possible role for SOAP: SOAP, > as currently specified > >[1], defines SOAP message structures separately > from transport bindings. > > > >[1] W3C Weekly News - 27 June 2003: > >[[ > > SOAP Version 1.2 Is a W3C Recommendation > > > > The World Wide Web Consortium released SOAP > Version 1.2 as a W3C > > Recommendation. The Recommendation is four > documents: the "SOAP > > Version 1.2 Primer," "SOAP Version 1.2 Messaging > Framework," "SOAP > > Version 1.2 Adjuncts," and the "SOAP Version 1.2 > Assertions and Test > > Collection." Developed by the W3C XML Protocol > Working Group, SOAP > > Version 1.2 is a lightweight protocol for > exchanging structured > > information in a decentralized, distributed > environment such as the > > Web. Read the press release, the testimonials, > the changes and > > benefits and the FAQ. Visit the Web services > home page. > > > > http://www.w3.org/2003/06/soap12-pressrelease > > http://www.w3.org/2003/06/soap12-testimonial > > http://www.w3.org/2003/06/soap11-soap12.html > > http://www.w3.org/2003/06/soap12faq.html > > http://www.w3.org/2002/ws/ > >]] > > > >> Advanced XML features > >> WSDL templates, XPath filtering, more? > === message truncated === __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Sat Aug 30 03:24:10 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28131 for ; Sat, 30 Aug 2003 03:24:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19syBK-0001Ys-TE for simple-archive@odin.ietf.org; Sat, 30 Aug 2003 01:21:51 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7U5LonL005998 for simple-archive@odin.ietf.org; Sat, 30 Aug 2003 01:21:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19svGG-0000z7-UW for simple-web-archive@optimus.ietf.org; Fri, 29 Aug 2003 22:14:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28980; Fri, 29 Aug 2003 22:14:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19svGD-0000sE-00; Fri, 29 Aug 2003 22:14:41 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19svGC-0000s9-00; Fri, 29 Aug 2003 22:14:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19stkx-0004Kr-Nk; Fri, 29 Aug 2003 20:38:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sohP-0007tl-6y for simple@optimus.ietf.org; Fri, 29 Aug 2003 15:14:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25495 for ; Fri, 29 Aug 2003 15:14:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sohN-0004DI-00 for simple@ietf.org; Fri, 29 Aug 2003 15:14:17 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 19sohM-0004DB-00 for simple@ietf.org; Fri, 29 Aug 2003 15:14:16 -0400 Received: from magnum.cs.columbia.edu (IDENT:root@magnum.cs.columbia.edu [128.59.16.117]) by cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h7TJEFcm029269; Fri, 29 Aug 2003 15:14:15 -0400 (EDT) Received: from cs.columbia.edu (path.cs.columbia.edu [128.59.19.143]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h7TJEEG24712; Fri, 29 Aug 2003 15:14:14 -0400 Message-ID: <3F4FA606.3020207@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030827 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg , simple@ietf.org Subject: Re: [Simple] [Fwd: Re: NETCONF WG meeting minutes for IETF #57] References: <3F4F64D5.7020508@dynamicsoft.com> In-Reply-To: <3F4F64D5.7020508@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 29 Aug 2003 15:14:14 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit This makes sense to me, but what is the alternative? It would be nice if there was one way of identifying logical components of XML, rather than each spec or even each WG making up their own. Does the DOM model offer an alternative? Jonathan Rosenberg wrote: > Graham Klyne posted this note on netconf that has some insights which > I think can benefit us. Pay attention to this statement: > > Graham writes: > >> I would be very wary about using XPath as the basis for selective >> access to XMLConf data. XPath, by design, provides selection on >> the syntactic structure of XML: it has been suggested elsewhere >> (e.g. in the netconf protocol document, IIRC) that the data model >> is separate from the protocol framework (which I think is a good >> approach). But the query/selection syntax should be related to the >> data model, not to the carrier syntax. I have seen difficulties >> arise with different XML-based applications where people tried to >> use XPath selection for an XML format used to carry a data model >> that was somewhat different from the XML carrier syntax. If the >> data model does not map directly onto the XML syntax, then XPath >> selection may well prove inadequate to make appropriate selection >> in the configuration data. > > > I think this summarizes nicely the concerns I have had about using xpath > for filtering. I am also going to be removing it from element > identification in the next xcap-auth rev. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Sat Aug 30 04:20:14 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00997 for ; Sat, 30 Aug 2003 04:20:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19szYx-0006m0-6Z for simple-archive@odin.ietf.org; Sat, 30 Aug 2003 02:50:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7U6oIi6026026 for simple-archive@odin.ietf.org; Sat, 30 Aug 2003 02:50:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19swpL-0005SK-0P for simple-web-archive@optimus.ietf.org; Fri, 29 Aug 2003 23:55:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06749; Fri, 29 Aug 2003 23:54:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19swpH-0005Ak-00; Fri, 29 Aug 2003 23:54:59 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19swpG-0005Af-00; Fri, 29 Aug 2003 23:54:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19svBL-0000d6-Dp; Fri, 29 Aug 2003 22:09:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sqnk-0005L3-B9 for simple@optimus.ietf.org; Fri, 29 Aug 2003 17:29:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06881 for ; Fri, 29 Aug 2003 17:28:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sqnh-00009r-00 for simple@ietf.org; Fri, 29 Aug 2003 17:28:57 -0400 Received: from web41506.mail.yahoo.com ([66.218.93.89]) by ietf-mx with smtp (Exim 4.12) id 19sqng-000093-00 for simple@ietf.org; Fri, 29 Aug 2003 17:28:57 -0400 Message-ID: <20030829212826.95093.qmail@web41506.mail.yahoo.com> Received: from [131.107.3.70] by web41506.mail.yahoo.com via HTTP; Fri, 29 Aug 2003 14:28:26 PDT From: Sean Olson Subject: Re: [Simple] [Fwd: Re: NETCONF WG meeting minutes for IETF #57] To: "Joel M. Halpern" , Simple WG Cc: gk@ninebynine.org In-Reply-To: <5.1.0.14.0.20030829121757.02167de0@mail.stevecrocker.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 29 Aug 2003 14:28:26 -0700 (PDT) I agree. I would expect a strong correlation between the XML schema and the underlying data model. If they did not match, why would you invest the effort in the XML schema in the first place? If the choice is XML, use XML wisely and to full advantage. XPath is a natural extension of this design path. Cheers, Sean --- "Joel M. Halpern" wrote: > It appears that the premise for the concern is the > situation where "the > data model does not map directly onto the XML > syntax." > Now, sometimes that is unavoidable. > But, in this environment where we are defining the > information to be > represented and defining the XML Schema at the same > time, one would expect > them to map well. In fact, if the syntactic > structure of our XML does not > match the semantic structure of the information we > are carrying, we are > going to seriously confuse our users. Why would we > want to do that? > > Yours, > Joel M. Halpern > > PS: In the netconf environment, the underlying data > model is so messy as to > almost mandate a mismatch. I do not believe that is > the case for the work > we are doing here. > > At 10:36 AM 8/29/2003 -0400, Jonathan Rosenberg > wrote: > >Graham Klyne posted this note on netconf that has > some insights which > >I think can benefit us. Pay attention to this > statement: > > > >Graham writes: > >>I would be very wary about using XPath as the > basis for selective > >>access to XMLConf data. XPath, by design, > provides selection on > >>the syntactic structure of XML: it has been > suggested elsewhere > >>(e.g. in the netconf protocol document, IIRC) that > the data model > >>is separate from the protocol framework (which I > think is a good > >>approach). But the query/selection syntax should > be related to the > >>data model, not to the carrier syntax. I have > seen difficulties > >>arise with different XML-based applications where > people tried to > >>use XPath selection for an XML format used to > carry a data model > >>that was somewhat different from the XML carrier > syntax. If the > >>data model does not map directly onto the XML > syntax, then XPath > >>selection may well prove inadequate to make > appropriate selection > >>in the configuration data. > > > >I think this summarizes nicely the concerns I have > had about using xpath > >for filtering. I am also going to be removing it > from element > >identification in the next xcap-auth rev. > > > >-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 > > > > > >Received: from mail2.dynamicsoft.com (192.168.4.31 > [192.168.4.31]) by > >DYN-EXCH-01.dynamicsoft.com with SMTP (Microsoft > Exchange Internet Mail > >Service Version 5.5.2653.13) > > id RQ9AMWDW; Fri, 29 Aug 2003 03:02:46 > -0400 > >Received: from psg.com (mailnull@psg.com > [147.28.0.62]) > > by mail2.dynamicsoft.com (8.12.8/8.12.8) > with ESMTP id > > h7T703hp000182; > > Fri, 29 Aug 2003 03:00:04 -0400 (EDT) > >Received: from lserv by psg.com with local (Exim > 4.22) > > id 19sdCT-0001KU-K7 > > for netconf-data@psg.com; Fri, 29 Aug 2003 > 06:57:37 +0000 > >Received: from [208.184.79.253] > (helo=jay.songbird.com) > > by psg.com with esmtp (Exim 4.22) > > id 19sQov-000Mys-KL > > for netconf@ops.ietf.org; Thu, 28 Aug 2003 > 17:44:29 +0000 > >Received: from Rincewind.ninebynine.org > (jay.songbird.com [208.184.79.253]) > > by jay.songbird.com (8.11.6/8.11.3) with > ESMTP id h7SHiE023575 > > for ; Thu, 28 Aug > 2003 10:44:15 -0700 > >Message-Id: > <5.1.0.14.2.20030827080833.023f2a08@127.0.0.1> > >X-Sender: gk@127.0.0.1 > >X-Mailer: QUALCOMM Windows Eudora Version 5.1 > >Date: Wed, 27 Aug 2003 09:44:12 +0100 > >To: netconf@ops.ietf.org > >From: Graham Klyne > >Subject: Re: NETCONF WG meeting minutes for IETF > #57 > >In-Reply-To: > <4.3.2.7.2.20030812194018.0249bfb0@fedex.cisco.com> > >Mime-Version: 1.0 > >Content-Type: text/plain; charset="iso-8859-1"; > format=flowed > >X-Spam-Status: No, hits=-0.9 required=5.0 > > tests=EMAIL_ATTRIBUTION,IN_REP_TO > > version=2.55 > >X-Spam-Level: > >X-Spam-Checker-Version: SpamAssassin 2.55 > (1.174.2.19-2003-05-19-exp) > >Sender: owner-netconf@ops.ietf.org > >Precedence: bulk > > > >At 19:41 12/08/03 -0700, Andy Bierman wrote: > >>Hi, > >> > >>Here are the minutes for the NETCONF WG meeting > held in Vienna. > > > >Here are some thoughts about some of the design > directions being suggested... > > > >>1) The major issues facing the working group were > listed > >>without much discussion: > >> > >> Transport mappings > >> BEEP, HTTPS, SSH? > > > >I don't think that BEEP and SOAP should be viewed > as mutually > >exclusive. There is a proposal (somewhere) for > SOAP over BEEP. If this > >means SOAP-over-HTTP, then I think it would help to > avoid possible > >confusion to say this explicitly. If you mean the > pre-standard version of > >SOAP that is specifically HTTP-based, then that > should be stated clearly. > > > >> RPC Layer > >> SOAP encoding, xmlconf RPC, or simple > request/response > > > >This is the *real* possible role for SOAP: SOAP, > as currently specified > >[1], defines SOAP message structures separately > from transport bindings. > > > >[1] W3C Weekly News - 27 June 2003: > >[[ > > SOAP Version 1.2 Is a W3C Recommendation > > > > The World Wide Web Consortium released SOAP > Version 1.2 as a W3C > > Recommendation. The Recommendation is four > documents: the "SOAP > > Version 1.2 Primer," "SOAP Version 1.2 Messaging > Framework," "SOAP > > Version 1.2 Adjuncts," and the "SOAP Version 1.2 > Assertions and Test > > Collection." Developed by the W3C XML Protocol > Working Group, SOAP > > Version 1.2 is a lightweight protocol for > exchanging structured > > information in a decentralized, distributed > environment such as the > > Web. Read the press release, the testimonials, > the changes and > > benefits and the FAQ. Visit the Web services > home page. > > > > http://www.w3.org/2003/06/soap12-pressrelease > > http://www.w3.org/2003/06/soap12-testimonial > > http://www.w3.org/2003/06/soap11-soap12.html > > http://www.w3.org/2003/06/soap12faq.html > > http://www.w3.org/2002/ws/ > >]] > > > >> Advanced XML features > >> WSDL templates, XPath filtering, more? > === message truncated === __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple