From mailman-admin@ietf.org Sun Jun 1 11:06: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 LAA14993 for ; Sun, 1 Jun 2003 11:06:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19MUNd-0000Is-00 for simple-archive@ietf.org; Sun, 01 Jun 2003 11:04:17 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19MUNd-0000Io-00 for simple-archive@ietf.org; Sun, 01 Jun 2003 11:04:17 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h51F66B19891 for ; Sun, 1 Jun 2003 11:06:06 -0400 Date: Sun, 01 Jun 2003 11:06:06 -0400 Message-ID: <20030601150606.11734.11613.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 Sun Jun 1 12:08:39 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 MAA18824; Sun, 1 Jun 2003 12:08:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19MVMG-0001UF-00; Sun, 01 Jun 2003 12:06:56 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19MVMG-0001UB-00; Sun, 01 Jun 2003 12:06:56 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h51G3NB06479; Sun, 1 Jun 2003 12:03:23 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h51G1ZB06246 for ; Sun, 1 Jun 2003 12:01: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 MAA18659 for ; Sun, 1 Jun 2003 12:01:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19MVFN-0001QD-00 for simple@ietf.org; Sun, 01 Jun 2003 11:59:49 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by ietf-mx with esmtp (Exim 4.12) id 19MVFM-0001QA-00 for simple@ietf.org; Sun, 01 Jun 2003 11:59:48 -0400 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 h51G0lFW025366; Sun, 1 Jun 2003 09:00:47 -0700 (PDT) Received: from [10.61.34.188] (sjc-vpn1-562.cisco.com [10.21.98.50]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AEQ86520; Sun, 1 Jun 2003 09:00:45 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.1.2418 From: Cullen Jennings To: Robert Sparks , Ben Campbell CC: Simple , Jonathan Rosenberg , Paul Kyzivat , Adam Roach Message-ID: In-Reply-To: <1054072815.12206.157.camel@RjS.localdomain> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Re: Comments on draft-ietf-simple-message-sesisons-00 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, 01 Jun 2003 09:00:45 -0700 Content-Transfer-Encoding: 7bit On 5/27/03 3:00 PM, "Robert Sparks" wrote: >>> LISTEN would be a better name. > > I would like to leave it as is. > > RjS > > OK - as long as some thought went into it I'm fine with leaving it as it is. I will never bring it up again :-) Cullen _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Sun Jun 1 12:09:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18920 for ; Sun, 1 Jun 2003 12:09:10 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h51G8hY08142 for simple-archive@odin.ietf.org; Sun, 1 Jun 2003 12:08:43 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h51G8hB08139 for ; Sun, 1 Jun 2003 12:08: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 MAA18824; Sun, 1 Jun 2003 12:08:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19MVMG-0001UF-00; Sun, 01 Jun 2003 12:06:56 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19MVMG-0001UB-00; Sun, 01 Jun 2003 12:06:56 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h51G3NB06479; Sun, 1 Jun 2003 12:03:23 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h51G1ZB06246 for ; Sun, 1 Jun 2003 12:01: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 MAA18659 for ; Sun, 1 Jun 2003 12:01:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19MVFN-0001QD-00 for simple@ietf.org; Sun, 01 Jun 2003 11:59:49 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by ietf-mx with esmtp (Exim 4.12) id 19MVFM-0001QA-00 for simple@ietf.org; Sun, 01 Jun 2003 11:59:48 -0400 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 h51G0lFW025366; Sun, 1 Jun 2003 09:00:47 -0700 (PDT) Received: from [10.61.34.188] (sjc-vpn1-562.cisco.com [10.21.98.50]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AEQ86520; Sun, 1 Jun 2003 09:00:45 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.1.2418 From: Cullen Jennings To: Robert Sparks , Ben Campbell CC: Simple , Jonathan Rosenberg , Paul Kyzivat , Adam Roach Message-ID: In-Reply-To: <1054072815.12206.157.camel@RjS.localdomain> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Re: Comments on draft-ietf-simple-message-sesisons-00 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, 01 Jun 2003 09:00:45 -0700 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On 5/27/03 3:00 PM, "Robert Sparks" wrote: >>> LISTEN would be a better name. > > I would like to leave it as is. > > RjS > > OK - as long as some thought went into it I'm fine with leaving it as it is. I will never bring it up again :-) Cullen _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Sun Jun 1 13:03:20 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 NAA21814; Sun, 1 Jun 2003 13:03:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19MWDC-0002NX-00; Sun, 01 Jun 2003 13:01:38 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19MWDB-0002NU-00; Sun, 01 Jun 2003 13:01:37 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h51Gw6B22110; Sun, 1 Jun 2003 12:58:06 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h51Gn9B18904 for ; Sun, 1 Jun 2003 12:49: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 MAA20995 for ; Sun, 1 Jun 2003 12:49:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19MVzO-00027l-00 for simple@ietf.org; Sun, 01 Jun 2003 12:47:22 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19MVzN-00027C-00 for simple@ietf.org; Sun, 01 Jun 2003 12:47:21 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h51GmV606807 for ; Sun, 1 Jun 2003 11:48:31 -0500 From: Robert Sparks To: simple@ietf.org Content-Type: text/plain Message-Id: <1054486110.1147.6.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Raw notes/slides from interim meeting 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: 01 Jun 2003 11:48:30 -0500 Content-Transfer-Encoding: 7bit Raw notes from the interim meeting (and the slides used during the discussions) are available at http://www.softarmor.com/simple/meets/interim2003/ RjS _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Sun Jun 1 13:03:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21835 for ; Sun, 1 Jun 2003 13:03:51 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h51H3PR22664 for simple-archive@odin.ietf.org; Sun, 1 Jun 2003 13:03:25 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h51H3PB22661 for ; Sun, 1 Jun 2003 13:03:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21814; Sun, 1 Jun 2003 13:03:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19MWDC-0002NX-00; Sun, 01 Jun 2003 13:01:38 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19MWDB-0002NU-00; Sun, 01 Jun 2003 13:01:37 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h51Gw6B22110; Sun, 1 Jun 2003 12:58:06 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h51Gn9B18904 for ; Sun, 1 Jun 2003 12:49: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 MAA20995 for ; Sun, 1 Jun 2003 12:49:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19MVzO-00027l-00 for simple@ietf.org; Sun, 01 Jun 2003 12:47:22 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19MVzN-00027C-00 for simple@ietf.org; Sun, 01 Jun 2003 12:47:21 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h51GmV606807 for ; Sun, 1 Jun 2003 11:48:31 -0500 From: Robert Sparks To: simple@ietf.org Content-Type: text/plain Message-Id: <1054486110.1147.6.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Raw notes/slides from interim meeting 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: 01 Jun 2003 11:48:30 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Raw notes from the interim meeting (and the slides used during the discussions) are available at http://www.softarmor.com/simple/meets/interim2003/ RjS _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Sun Jun 1 22:52:25 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 WAA10111; Sun, 1 Jun 2003 22:52:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19MfPF-0006vQ-00; Sun, 01 Jun 2003 22:50:41 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19MfPF-0006vN-00; Sun, 01 Jun 2003 22:50:41 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h522lAB19129; Sun, 1 Jun 2003 22:47:10 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h522kuB19108 for ; Sun, 1 Jun 2003 22:46: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 WAA10014 for ; Sun, 1 Jun 2003 22:46:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19MfJq-0006uD-00 for simple@ietf.org; Sun, 01 Jun 2003 22:45:06 -0400 Received: from bdsl.66.12.12.130.gte.net ([66.12.12.130] helo=bdsl.greycouncil.com) by ietf-mx with esmtp (Exim 4.12) id 19MfJp-0006u9-00 for simple@ietf.org; Sun, 01 Jun 2003 22:45:05 -0400 Received: from txdwillis (12-239-241-155.client.attbi.com [12.239.241.155]) (authenticated bits=0) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h522kG6n027451 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Sun, 1 Jun 2003 21:46:18 -0500 From: "Dean Willis" To: , , Subject: RE: [Simple] Congestion Control Message-ID: <000901c328b1$1f017ee0$b37ba8c0@txdwillis> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD901945294@esebe013.ntc.nokia.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h522kvB19110 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, 1 Jun 2003 21:46:05 -0500 Content-Transfer-Encoding: 8bit Aki asked: > So what if we drop the safety portion of congestion safe, and > focus on ensuring congestion-controlled transport gets used > at each hop instead? That's probably a reasonable compromise. All the complexity jumps up when we try to show a "safe" way to use UDP. The proposed mechanism could easily be used to simply assure that UDP isn't being used at all. I could probably fix the draft up by just deleting a few passages. The result would be quite useful for MESSAGE, as well as big invitations, etc. It does raise questions for high-fan-in servers and potentially for mobile applications, although I'm inclined to think that these questions do not have as severe a downside as some people seem to think. I suppose this should properly be discussed on the SIP list. . . -- Dean _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Sun Jun 1 22:52:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10128 for ; Sun, 1 Jun 2003 22:52:56 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h522qWN19302 for simple-archive@odin.ietf.org; Sun, 1 Jun 2003 22:52:32 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h522qWB19299 for ; Sun, 1 Jun 2003 22:52:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10111; Sun, 1 Jun 2003 22:52:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19MfPF-0006vQ-00; Sun, 01 Jun 2003 22:50:41 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19MfPF-0006vN-00; Sun, 01 Jun 2003 22:50:41 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h522lAB19129; Sun, 1 Jun 2003 22:47:10 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h522kuB19108 for ; Sun, 1 Jun 2003 22:46: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 WAA10014 for ; Sun, 1 Jun 2003 22:46:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19MfJq-0006uD-00 for simple@ietf.org; Sun, 01 Jun 2003 22:45:06 -0400 Received: from bdsl.66.12.12.130.gte.net ([66.12.12.130] helo=bdsl.greycouncil.com) by ietf-mx with esmtp (Exim 4.12) id 19MfJp-0006u9-00 for simple@ietf.org; Sun, 01 Jun 2003 22:45:05 -0400 Received: from txdwillis (12-239-241-155.client.attbi.com [12.239.241.155]) (authenticated bits=0) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h522kG6n027451 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Sun, 1 Jun 2003 21:46:18 -0500 From: "Dean Willis" To: , , Subject: RE: [Simple] Congestion Control Message-ID: <000901c328b1$1f017ee0$b37ba8c0@txdwillis> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD901945294@esebe013.ntc.nokia.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h522kvB19110 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, 1 Jun 2003 21:46:05 -0500 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Aki asked: > So what if we drop the safety portion of congestion safe, and > focus on ensuring congestion-controlled transport gets used > at each hop instead? That's probably a reasonable compromise. All the complexity jumps up when we try to show a "safe" way to use UDP. The proposed mechanism could easily be used to simply assure that UDP isn't being used at all. I could probably fix the draft up by just deleting a few passages. The result would be quite useful for MESSAGE, as well as big invitations, etc. It does raise questions for high-fan-in servers and potentially for mobile applications, although I'm inclined to think that these questions do not have as severe a downside as some people seem to think. I suppose this should properly be discussed on the SIP list. . . -- Dean _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Jun 2 11:56:07 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 LAA13114; Mon, 2 Jun 2003 11:56:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Mrde-0004HL-00; Mon, 02 Jun 2003 11:54:22 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Mrdd-0004HH-00; Mon, 02 Jun 2003 11:54:21 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52FokB26657; Mon, 2 Jun 2003 11:50:46 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52FkdB26456 for ; Mon, 2 Jun 2003 11:46: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 LAA12657 for ; Mon, 2 Jun 2003 11:46:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19MrUR-0004AZ-00 for simple@ietf.org; Mon, 02 Jun 2003 11:44:51 -0400 Received: from dewberry.cc.columbia.edu ([128.59.59.68] ident=cu41754) by ietf-mx with esmtp (Exim 4.12) id 19MrUR-0004AW-00 for simple@ietf.org; Mon, 02 Jun 2003 11:44:51 -0400 Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (user=hgs10 mech=PLAIN bits=0) by dewberry.cc.columbia.edu (8.12.8p1/8.12.8) with ESMTP id h52FkZRZ007575 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 2 Jun 2003 11:46:35 -0400 (EDT) Message-ID: <3EDB7093.3080408@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030529 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Sparks CC: simple@ietf.org Subject: Re: [Simple] Slides for this afternoon's discussions on publish References: <1054302295.935.55.camel@RjS.localdomain> In-Reply-To: <1054302295.935.55.camel@RjS.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.32 (www . roaringpenguin . com / mimedefang) 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, 02 Jun 2003 11:43:15 -0400 Content-Transfer-Encoding: 7bit I didn't participate in the discussion on PUBLISH, but some questions on possibly related HTTP mechanisms: - In the interest of having methods that mean what they say, why not follow the HTTP/1.1 lead and use DELETE to remove a publication? - Entity-Tags (RFC 2616, Section 14.19) provide content identification. Since PUBLISH is a kin of WebDAV and the HTTP content model, might as well at least consider the existing solutions... Robert Sparks wrote: > http://www.nostrum.com/~rjsparks/simple-interim-may03-publish.ppt > http://www.nostrum.com/~rjsparks/simple-interim-may03-xcap.ppt > > _______________________________________________ > Simple mailing 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 mailnull@www1.ietf.org Mon Jun 2 11:56:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13141 for ; Mon, 2 Jun 2003 11:56:38 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h52FuB827073 for simple-archive@odin.ietf.org; Mon, 2 Jun 2003 11:56:11 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52FuAB27070 for ; Mon, 2 Jun 2003 11:56:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13114; Mon, 2 Jun 2003 11:56:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Mrde-0004HL-00; Mon, 02 Jun 2003 11:54:22 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Mrdd-0004HH-00; Mon, 02 Jun 2003 11:54:21 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52FokB26657; Mon, 2 Jun 2003 11:50:46 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52FkdB26456 for ; Mon, 2 Jun 2003 11:46: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 LAA12657 for ; Mon, 2 Jun 2003 11:46:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19MrUR-0004AZ-00 for simple@ietf.org; Mon, 02 Jun 2003 11:44:51 -0400 Received: from dewberry.cc.columbia.edu ([128.59.59.68] ident=cu41754) by ietf-mx with esmtp (Exim 4.12) id 19MrUR-0004AW-00 for simple@ietf.org; Mon, 02 Jun 2003 11:44:51 -0400 Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (user=hgs10 mech=PLAIN bits=0) by dewberry.cc.columbia.edu (8.12.8p1/8.12.8) with ESMTP id h52FkZRZ007575 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 2 Jun 2003 11:46:35 -0400 (EDT) Message-ID: <3EDB7093.3080408@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030529 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Sparks CC: simple@ietf.org Subject: Re: [Simple] Slides for this afternoon's discussions on publish References: <1054302295.935.55.camel@RjS.localdomain> In-Reply-To: <1054302295.935.55.camel@RjS.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.32 (www . roaringpenguin . com / mimedefang) 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, 02 Jun 2003 11:43:15 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I didn't participate in the discussion on PUBLISH, but some questions on possibly related HTTP mechanisms: - In the interest of having methods that mean what they say, why not follow the HTTP/1.1 lead and use DELETE to remove a publication? - Entity-Tags (RFC 2616, Section 14.19) provide content identification. Since PUBLISH is a kin of WebDAV and the HTTP content model, might as well at least consider the existing solutions... Robert Sparks wrote: > http://www.nostrum.com/~rjsparks/simple-interim-may03-publish.ppt > http://www.nostrum.com/~rjsparks/simple-interim-may03-xcap.ppt > > _______________________________________________ > Simple mailing 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 Jun 2 12:50:28 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 MAA14848; Mon, 2 Jun 2003 12:50:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19MsUF-0004gD-00; Mon, 02 Jun 2003 12:48:43 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19MsUF-0004g9-00; Mon, 02 Jun 2003 12:48:43 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52GipB31982; Mon, 2 Jun 2003 12:44:51 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52GhDB31925 for ; Mon, 2 Jun 2003 12: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 ESMTP id MAA14665 for ; Mon, 2 Jun 2003 12:43:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19MsNA-0004dK-00 for simple@ietf.org; Mon, 02 Jun 2003 12:41:24 -0400 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 19MsN9-0004cu-00 for simple@ietf.org; Mon, 02 Jun 2003 12:41:23 -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 h52GgaMV007035; Mon, 2 Jun 2003 12:42:36 -0400 (EDT) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 2 Jun 2003 11:42:36 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A647F9@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'hisham.khartabil@nokia.com'" , Andrew Allen , simple@ietf.org MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="utf-8" X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h52GhEB31926 Subject: [Simple] RE: Use of 202 response for subscription with filter (was :RE: [S imple] RE: Comments on draft-khartabil-simple-filter-funct-00) Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 2 Jun 2003 11:42:33 -0500 X-MIME-Autoconverted: from 8bit to quoted-printable by www1.ietf.org id h52GipB31982 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA14848 Sorry for taking so long to respond. I was trying to find the rest of this thread, which I seem to have missed. I'll answer with the context I can figure out from the messages I've seen. > -----Original Message----- > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > > > -----Original Message----- > > From: ext AndrewAllen007@aol.com [mailto:AndrewAllen007@aol.com] > > > > > > Next comment relates to clause 3.3.4 Subscriber Interpreting > > > SIP responses, clause 5.2 Notifier Processing SUBSCRIBE > > > Requests, and clause 5.4 Handling Abnormal Cases: > > > > > > The meaning of 200 and 202 responses to Subscribe requests is > > > already defined in RFC 3265 and they relate to the state of > > > the subscription I don’t think we should further extend their > > > meaning to also include a meaning to the state of the filter > > > criteria. It seems the server has four basic options: > > > > > > 1) It can accept the subscription and also accept the filter > > > criteria. – 200 OK > > > 2) It can accept the subscription but ignore all the filter > > > criteria - 200 OK > > > 3) It can reject the subscription (which also rejects the > > > filter criteria) - 4xxx > > > 4) It can indicate that the subscription has been > > > understood, and that authorization may or may not have been > > > granted. - 202 > > > > I think the text as it is now is ok. Some implementations of > > the server might want to examine the filter after responding > > to the SUBSCRIBE. A 202 in this case is needed. > > > > [AA] My concern is with extending the meaning of 200 OK and > > 202 from that stated in RFC 3265. The text of concern is in > > clause 5.2 “A "200" response indicates that the subscription > > has been accepted, the user is authorized and the filter is > > accepted.” AND “A "202" response also indicates that the > > filter criteria have not been accepted yet.” > > > > [AA] IMO even if we go with the approach of rejecting the > > subscription if the filter criteria is rejected we do not > > need this text since the RFC 3265 wording still applies – the > > subscription is either rejected or authorized or pending. If > > the implementation wants to examine the filter criteria > > before authorizing the subscription then a 202 is appropriate > > and I think this is covered in 3265 as well. If we choose to > > always reject the subscription if the filter criteria is not > > acceptable then all we need to state in the draft is that > > rejection of the filter criteria means that the subscription > > must also be rejected as you propose below. > > > > I still think we need to spell it out in the filtering draft. > What do you think Adam? I'm all for being explicit. However, I see Andrew's concern that the current wording appears to change what 202 means in response to a SUBSCRIBE. So, I would probably change the wording to more closely reflect how Andrew describes it above: 202 still means that authorization is pending, and that such an authorization decision may be predicated on the contents of the filter. On a different topic, I don't see having a notifier accept a subscription but reject the filter as being a viable option. I agree with Jonathan that these operations need to be atomic. From a practical perspective, any device that puts a filter in place certainly has a good reason for doing so, and having the notifier ignore such a filter seems to border on malicious. /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon Jun 2 12:50:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14866 for ; Mon, 2 Jun 2003 12:50:59 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h52GoX332192 for simple-archive@odin.ietf.org; Mon, 2 Jun 2003 12:50:33 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52GoXB32189 for ; Mon, 2 Jun 2003 12:50: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 MAA14848; Mon, 2 Jun 2003 12:50:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19MsUF-0004gD-00; Mon, 02 Jun 2003 12:48:43 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19MsUF-0004g9-00; Mon, 02 Jun 2003 12:48:43 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52GipB31982; Mon, 2 Jun 2003 12:44:51 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52GhDB31925 for ; Mon, 2 Jun 2003 12: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 ESMTP id MAA14665 for ; Mon, 2 Jun 2003 12:43:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19MsNA-0004dK-00 for simple@ietf.org; Mon, 02 Jun 2003 12:41:24 -0400 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 19MsN9-0004cu-00 for simple@ietf.org; Mon, 02 Jun 2003 12:41:23 -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 h52GgaMV007035; Mon, 2 Jun 2003 12:42:36 -0400 (EDT) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 2 Jun 2003 11:42:36 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A647F9@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'hisham.khartabil@nokia.com'" , Andrew Allen , simple@ietf.org MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="utf-8" X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h52GhEB31926 Subject: [Simple] RE: Use of 202 response for subscription with filter (was :RE: [S imple] RE: Comments on draft-khartabil-simple-filter-funct-00) Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 2 Jun 2003 11:42:33 -0500 X-MIME-Autoconverted: from 8bit to quoted-printable by www1.ietf.org id h52GipB31982 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h52GoXB32189 Content-Transfer-Encoding: 8bit Sorry for taking so long to respond. I was trying to find the rest of this thread, which I seem to have missed. I'll answer with the context I can figure out from the messages I've seen. > -----Original Message----- > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > > > -----Original Message----- > > From: ext AndrewAllen007@aol.com [mailto:AndrewAllen007@aol.com] > > > > > > Next comment relates to clause 3.3.4 Subscriber Interpreting > > > SIP responses, clause 5.2 Notifier Processing SUBSCRIBE > > > Requests, and clause 5.4 Handling Abnormal Cases: > > > > > > The meaning of 200 and 202 responses to Subscribe requests is > > > already defined in RFC 3265 and they relate to the state of > > > the subscription I don’t think we should further extend their > > > meaning to also include a meaning to the state of the filter > > > criteria. It seems the server has four basic options: > > > > > > 1) It can accept the subscription and also accept the filter > > > criteria. – 200 OK > > > 2) It can accept the subscription but ignore all the filter > > > criteria - 200 OK > > > 3) It can reject the subscription (which also rejects the > > > filter criteria) - 4xxx > > > 4) It can indicate that the subscription has been > > > understood, and that authorization may or may not have been > > > granted. - 202 > > > > I think the text as it is now is ok. Some implementations of > > the server might want to examine the filter after responding > > to the SUBSCRIBE. A 202 in this case is needed. > > > > [AA] My concern is with extending the meaning of 200 OK and > > 202 from that stated in RFC 3265. The text of concern is in > > clause 5.2 “A "200" response indicates that the subscription > > has been accepted, the user is authorized and the filter is > > accepted.” AND “A "202" response also indicates that the > > filter criteria have not been accepted yet.” > > > > [AA] IMO even if we go with the approach of rejecting the > > subscription if the filter criteria is rejected we do not > > need this text since the RFC 3265 wording still applies – the > > subscription is either rejected or authorized or pending. If > > the implementation wants to examine the filter criteria > > before authorizing the subscription then a 202 is appropriate > > and I think this is covered in 3265 as well. If we choose to > > always reject the subscription if the filter criteria is not > > acceptable then all we need to state in the draft is that > > rejection of the filter criteria means that the subscription > > must also be rejected as you propose below. > > > > I still think we need to spell it out in the filtering draft. > What do you think Adam? I'm all for being explicit. However, I see Andrew's concern that the current wording appears to change what 202 means in response to a SUBSCRIBE. So, I would probably change the wording to more closely reflect how Andrew describes it above: 202 still means that authorization is pending, and that such an authorization decision may be predicated on the contents of the filter. On a different topic, I don't see having a notifier accept a subscription but reject the filter as being a viable option. I agree with Jonathan that these operations need to be atomic. From a practical perspective, any device that puts a filter in place certainly has a good reason for doing so, and having the notifier ignore such a filter seems to border on malicious. /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Jun 2 13:29:32 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 NAA15842; Mon, 2 Jun 2003 13:29:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Mt64-0004rJ-00; Mon, 02 Jun 2003 13:27:48 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Mt63-0004rG-00; Mon, 02 Jun 2003 13:27:47 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52HONB02341; Mon, 2 Jun 2003 13:24:23 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52HKpB02157 for ; Mon, 2 Jun 2003 13:20:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15606 for ; Mon, 2 Jun 2003 13:20:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19MsxZ-0004oh-00 for simple@ietf.org; Mon, 02 Jun 2003 13:19:02 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19MsxY-0004oZ-00 for simple@ietf.org; Mon, 02 Jun 2003 13:19:00 -0400 Received: from dynamicsoft.com ([63.113.47.242]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h52HKBZE006296; Mon, 2 Jun 2003 13:20:11 -0400 (EDT) Message-ID: <3EDB8747.6060603@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne CC: Robert Sparks , simple@ietf.org Subject: Re: [Simple] Slides for this afternoon's discussions on publish References: <1054302295.935.55.camel@RjS.localdomain> <3EDB7093.3080408@cs.columbia.edu> In-Reply-To: <3EDB7093.3080408@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 02 Jun 2003 13:20:07 -0400 Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > I didn't participate in the discussion on PUBLISH, but some questions on > possibly related HTTP mechanisms: > > - In the interest of having methods that mean what they say, why not > follow the HTTP/1.1 lead and use DELETE to remove a publication? Published state is soft-state. So far, everywhere else in SIP (registrations, subscriptions), we have used Expires:0 to delete soft-state. Seems better to be consistent with that. > > - Entity-Tags (RFC 2616, Section 14.19) provide content identification. > > Since PUBLISH is a kin of WebDAV and the HTTP content model, might as > well at least consider the existing solutions... The proposal I had made in the slides was to use the If-Unmodified-Since header from here; not clear to me how etags is better or worse. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Scientist 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 mailnull@www1.ietf.org Mon Jun 2 13:30:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15879 for ; Mon, 2 Jun 2003 13:30:03 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h52HTc702550 for simple-archive@odin.ietf.org; Mon, 2 Jun 2003 13:29:38 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52HTcB02547 for ; Mon, 2 Jun 2003 13:29: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 NAA15842; Mon, 2 Jun 2003 13:29:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Mt64-0004rJ-00; Mon, 02 Jun 2003 13:27:48 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Mt63-0004rG-00; Mon, 02 Jun 2003 13:27:47 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52HONB02341; Mon, 2 Jun 2003 13:24:23 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52HKpB02157 for ; Mon, 2 Jun 2003 13:20:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15606 for ; Mon, 2 Jun 2003 13:20:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19MsxZ-0004oh-00 for simple@ietf.org; Mon, 02 Jun 2003 13:19:02 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19MsxY-0004oZ-00 for simple@ietf.org; Mon, 02 Jun 2003 13:19:00 -0400 Received: from dynamicsoft.com ([63.113.47.242]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h52HKBZE006296; Mon, 2 Jun 2003 13:20:11 -0400 (EDT) Message-ID: <3EDB8747.6060603@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne CC: Robert Sparks , simple@ietf.org Subject: Re: [Simple] Slides for this afternoon's discussions on publish References: <1054302295.935.55.camel@RjS.localdomain> <3EDB7093.3080408@cs.columbia.edu> In-Reply-To: <3EDB7093.3080408@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 02 Jun 2003 13:20:07 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > I didn't participate in the discussion on PUBLISH, but some questions on > possibly related HTTP mechanisms: > > - In the interest of having methods that mean what they say, why not > follow the HTTP/1.1 lead and use DELETE to remove a publication? Published state is soft-state. So far, everywhere else in SIP (registrations, subscriptions), we have used Expires:0 to delete soft-state. Seems better to be consistent with that. > > - Entity-Tags (RFC 2616, Section 14.19) provide content identification. > > Since PUBLISH is a kin of WebDAV and the HTTP content model, might as > well at least consider the existing solutions... The proposal I had made in the slides was to use the If-Unmodified-Since header from here; not clear to me how etags is better or worse. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Scientist 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 Jun 2 13:49:07 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 NAA16775; Mon, 2 Jun 2003 13:49:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19MtOz-00053t-00; Mon, 02 Jun 2003 13:47:21 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19MtOz-00053q-00; Mon, 02 Jun 2003 13:47:21 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52Hi7B04478; Mon, 2 Jun 2003 13:44:08 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52HhrB04444 for ; Mon, 2 Jun 2003 13:43:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16503 for ; Mon, 2 Jun 2003 13:43:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19MtJr-00051C-00 for simple@ietf.org; Mon, 02 Jun 2003 13:42:03 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 19MtJq-000519-00 for simple@ietf.org; Mon, 02 Jun 2003 13:42:02 -0400 Received: from localhost (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id h52Hhg5k053951 for ; Mon, 2 Jun 2003 12:43:43 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) From: Ben Campbell To: Simple WG Content-Type: text/plain Message-Id: <1054575797.1975.49.camel@verite.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] MSRP: Connection Issue and proposal 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: 02 Jun 2003 12:43:17 -0500 Content-Transfer-Encoding: 7bit The last issue we discussed on MSRP in Ottowa concerned the connection setup mechanism. The background is, when an MSRP endpoint receives an offer containing "both", it does not immediately try to both host and visit, like comedia endpoints do. Rather, it first attempts to act as a visitor, then if that fails, it SHOULD attempt to host. This means that an SDP _answer_ will _never_ contain a direction attribute of "both". It was mentioned in the meeting that it can take some time for the connection attempt to timeout. In the situation where the answerer cannot open a connection to the host, it could conceivably take a small number of minutes before it falls back to act as a host. This would not be a very good user experience. A second issue that Jonathan brought up is forking. If an INVITE forks, you could end up with multiple visitors legitimately trying to connect to the host. The current draft only allows one connection for any given session. The first visit will always win, and any others will be rejected. We could allow multiple connections to be associated with the session, but that would add a great deal of complexity and additional security concerns. One idea (hereby designated as option 1) that was mentioned to me is that we could solve both of these issues by simply changing the process so that the visitor always hosts. However, this greatly reduces the flexibility dealing with firewall issues, and would probably greatly reduce the chance for any two endpoints to be able to talk. Another option (hereby designated option 2) is twofold: a) Follow the existing process for the answerer when it receives an offer containg "both", with an additional statement that the answerer SHOULD time-out the connection attempt after some fairly small value--say 10 seconds. b) Keep the current behavior when a fork occurs. The first connection wins. Any subsequent connections will get an error response as documented in the draft. Answerers that receive that response MUST fail the offer. Adam pointed out that doing anything else is not particularly useful, because any proxy that forks the request will probably CANCEL any outstanding transactions after receiving the first 200 response, so there is no way to reliably use the forking mechanism to set up multiple session connections anyway. I propose we go with option 2, as it gives us the most flexibility without adding a great deal of complexity. Thoughts? _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon Jun 2 13:49:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16808 for ; Mon, 2 Jun 2003 13:49:38 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h52HnCM04874 for simple-archive@odin.ietf.org; Mon, 2 Jun 2003 13:49:12 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52HnCB04871 for ; Mon, 2 Jun 2003 13:49:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16775; Mon, 2 Jun 2003 13:49:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19MtOz-00053t-00; Mon, 02 Jun 2003 13:47:21 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19MtOz-00053q-00; Mon, 02 Jun 2003 13:47:21 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52Hi7B04478; Mon, 2 Jun 2003 13:44:08 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52HhrB04444 for ; Mon, 2 Jun 2003 13:43:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16503 for ; Mon, 2 Jun 2003 13:43:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19MtJr-00051C-00 for simple@ietf.org; Mon, 02 Jun 2003 13:42:03 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 19MtJq-000519-00 for simple@ietf.org; Mon, 02 Jun 2003 13:42:02 -0400 Received: from localhost (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id h52Hhg5k053951 for ; Mon, 2 Jun 2003 12:43:43 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) From: Ben Campbell To: Simple WG Content-Type: text/plain Message-Id: <1054575797.1975.49.camel@verite.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] MSRP: Connection Issue and proposal 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: 02 Jun 2003 12:43:17 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit The last issue we discussed on MSRP in Ottowa concerned the connection setup mechanism. The background is, when an MSRP endpoint receives an offer containing "both", it does not immediately try to both host and visit, like comedia endpoints do. Rather, it first attempts to act as a visitor, then if that fails, it SHOULD attempt to host. This means that an SDP _answer_ will _never_ contain a direction attribute of "both". It was mentioned in the meeting that it can take some time for the connection attempt to timeout. In the situation where the answerer cannot open a connection to the host, it could conceivably take a small number of minutes before it falls back to act as a host. This would not be a very good user experience. A second issue that Jonathan brought up is forking. If an INVITE forks, you could end up with multiple visitors legitimately trying to connect to the host. The current draft only allows one connection for any given session. The first visit will always win, and any others will be rejected. We could allow multiple connections to be associated with the session, but that would add a great deal of complexity and additional security concerns. One idea (hereby designated as option 1) that was mentioned to me is that we could solve both of these issues by simply changing the process so that the visitor always hosts. However, this greatly reduces the flexibility dealing with firewall issues, and would probably greatly reduce the chance for any two endpoints to be able to talk. Another option (hereby designated option 2) is twofold: a) Follow the existing process for the answerer when it receives an offer containg "both", with an additional statement that the answerer SHOULD time-out the connection attempt after some fairly small value--say 10 seconds. b) Keep the current behavior when a fork occurs. The first connection wins. Any subsequent connections will get an error response as documented in the draft. Answerers that receive that response MUST fail the offer. Adam pointed out that doing anything else is not particularly useful, because any proxy that forks the request will probably CANCEL any outstanding transactions after receiving the first 200 response, so there is no way to reliably use the forking mechanism to set up multiple session connections anyway. I propose we go with option 2, as it gives us the most flexibility without adding a great deal of complexity. Thoughts? _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Jun 3 01:08:44 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 BAA07966; Tue, 3 Jun 2003 01:08:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19N40e-0001rW-00; Tue, 03 Jun 2003 01:06:56 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19N40e-0001rT-00; Tue, 03 Jun 2003 01:06:56 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5353QB25447; Tue, 3 Jun 2003 01:03:26 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5352RB25381 for ; Tue, 3 Jun 2003 01:02:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07699 for ; Tue, 3 Jun 2003 01:02:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19N3uW-0001lO-00 for simple@ietf.org; Tue, 03 Jun 2003 01:00:36 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19N3uE-0001jM-00 for simple@ietf.org; Tue, 03 Jun 2003 01:00:19 -0400 Received: from dynamicsoft.com ([63.113.46.71]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h5351cZE006932 for ; Tue, 3 Jun 2003 01:01:39 -0400 (EDT) Message-ID: <3EDC2BAE.2060608@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, en MIME-Version: 1.0 To: simple@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] XCAP issue: batching 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, 03 Jun 2003 01:01:34 -0400 Content-Transfer-Encoding: 7bit Folks, The main open issue in xcap at this time is batching. We discussed it during the interim, and I have done some additional investigating since then. The issue is this. In many cases, a client will want to modify a document from X to Y. This modification may require a series of changes to the document. However, the intermediate versions of the document which result from those changes do not represent a state that the client finds acceptable. This could be because they are not compliant to the schema, or because they are wrong or inappropriate. An example is moving a buddy from a white list to a black list. That would require two xcap operations - one to remove from the white list, one to add to the black list. After completing the first step, the buddy is on NEITHER list, and if a subscription should arrive at exactly that moment, the wrong thing would happen. This is basically the consistency property of ACID. There are several ways this feature can be provided: Soln 1: Least Common Parent The "least common parent" is the XML element whose descendants include all of the nodes to be modified in the transaction, and for whom no descendant also has this property. So, to provide the transaction, the client would read the value of the least common parent, modify all of the elements as needed, and write it back to the server. The main drawback of this approach is overhead. The client may be forced to read and write a lot of extra elements which are not actually modified, but are within the subtree of the least common parent. For buddy lists, this might mean reading the entire list, modifying some of the entries, and writing it back. Not pretty. This approach works with xcap as written now. Approach II: Body Commands In this approach, we introduce a new operation that can be done on a document. The body of the request (POST) would contain XML that contains the sequence of operations to perform. So: POST http://xcap.example.com/services/presence-lists/users/joe/list1.xml?batch /presence-lists/list[@name=friends]/entry[@name=bill] ; Tue, 3 Jun 2003 01:09:15 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5358mm26732 for simple-archive@odin.ietf.org; Tue, 3 Jun 2003 01:08:48 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5358lB26729 for ; Tue, 3 Jun 2003 01:08:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07966; Tue, 3 Jun 2003 01:08:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19N40e-0001rW-00; Tue, 03 Jun 2003 01:06:56 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19N40e-0001rT-00; Tue, 03 Jun 2003 01:06:56 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5353QB25447; Tue, 3 Jun 2003 01:03:26 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5352RB25381 for ; Tue, 3 Jun 2003 01:02:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07699 for ; Tue, 3 Jun 2003 01:02:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19N3uW-0001lO-00 for simple@ietf.org; Tue, 03 Jun 2003 01:00:36 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19N3uE-0001jM-00 for simple@ietf.org; Tue, 03 Jun 2003 01:00:19 -0400 Received: from dynamicsoft.com ([63.113.46.71]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h5351cZE006932 for ; Tue, 3 Jun 2003 01:01:39 -0400 (EDT) Message-ID: <3EDC2BAE.2060608@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, en MIME-Version: 1.0 To: simple@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] XCAP issue: batching 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, 03 Jun 2003 01:01:34 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Folks, The main open issue in xcap at this time is batching. We discussed it during the interim, and I have done some additional investigating since then. The issue is this. In many cases, a client will want to modify a document from X to Y. This modification may require a series of changes to the document. However, the intermediate versions of the document which result from those changes do not represent a state that the client finds acceptable. This could be because they are not compliant to the schema, or because they are wrong or inappropriate. An example is moving a buddy from a white list to a black list. That would require two xcap operations - one to remove from the white list, one to add to the black list. After completing the first step, the buddy is on NEITHER list, and if a subscription should arrive at exactly that moment, the wrong thing would happen. This is basically the consistency property of ACID. There are several ways this feature can be provided: Soln 1: Least Common Parent The "least common parent" is the XML element whose descendants include all of the nodes to be modified in the transaction, and for whom no descendant also has this property. So, to provide the transaction, the client would read the value of the least common parent, modify all of the elements as needed, and write it back to the server. The main drawback of this approach is overhead. The client may be forced to read and write a lot of extra elements which are not actually modified, but are within the subtree of the least common parent. For buddy lists, this might mean reading the entire list, modifying some of the entries, and writing it back. Not pretty. This approach works with xcap as written now. Approach II: Body Commands In this approach, we introduce a new operation that can be done on a document. The body of the request (POST) would contain XML that contains the sequence of operations to perform. So: POST http://xcap.example.com/services/presence-lists/users/joe/list1.xml?batch /presence-lists/list[@name=friends]/entry[@name=bill] ; Tue, 3 Jun 2003 10:14:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06461 for ; Tue, 3 Jun 2003 10:14:52 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NCXB-0006PM-00 for simple@ietf.org; Tue, 03 Jun 2003 10:13:05 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19NCXA-0006PJ-00 for simple@ietf.org; Tue, 03 Jun 2003 10:13:04 -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 h53EEqW05891 for ; Tue, 3 Jun 2003 17:14:52 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 3 Jun 2003 17:14:52 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 3 Jun 2003 17:14:52 +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" Subject: RE: [Simple] XCAP issue: batching Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701796D02@esebe019.ntc.nokia.com> Thread-Topic: [Simple] XCAP issue: batching Thread-Index: AcMpjavjawe3E0GfTAigiBKq/a5ilAAS/bpA To: , X-OriginalArrivalTime: 03 Jun 2003 14:14:52.0022 (UTC) FILETIME=[7FCC7160:01C329DA] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h53EEwB18197 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 3 Jun 2003 17:14:51 +0300 Content-Transfer-Encoding: 8bit I don't yet have a preference, I have to think about the options a little more. I do have a question about option II though: Does going with option II potentially mean eliminating the need of the DELETE method usage? and perhaps PUT as well? So we only have POST and GET. Regards, Hisham > -----Original Message----- > From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Tuesday, June 03, 2003 8:02 AM > To: simple@ietf.org > Subject: [Simple] XCAP issue: batching > > > Folks, > > The main open issue in xcap at this time is batching. We discussed it > during the interim, and I have done some additional investigating > since then. > > The issue is this. In many cases, a client will want to modify a > document from X to Y. This modification may require a series of > changes to the document. However, the intermediate versions of the > document which result from those changes do not represent a > state that > the client finds acceptable. This could be because they are not > compliant to the schema, or because they are wrong or inappropriate. > An example is moving a buddy from a white list to a black list. That > would require two xcap operations - one to remove from the > white list, > one to add to the black list. After completing the first step, the > buddy is on NEITHER list, and if a subscription should arrive at > exactly that moment, the wrong thing would happen. This is basically > the consistency property of ACID. > > There are several ways this feature can be provided: > > Soln 1: Least Common Parent > > The "least common parent" is the XML element whose > descendants include > all of the nodes to be modified in the transaction, and for whom no > descendant also has this property. So, to provide the > transaction, the > client would read the value of the least common parent, modify all of > the elements as needed, and write it back to the server. > > The main drawback of this approach is overhead. The client may be > forced to read and write a lot of extra elements which are not > actually modified, but are within the subtree of the least common > parent. For buddy lists, this might mean reading the entire list, > modifying some of the entries, and writing it back. Not pretty. > > This approach works with xcap as written now. > > Approach II: Body Commands > > In this approach, we introduce a new operation that can be done on a > document. The body of the request (POST) would contain XML that > contains the sequence of operations to perform. So: > > POST > http://xcap.example.com/services/presence-lists/users/joe/list > 1.xml?batch > > > > /presence-lists/list[@name=friends]/entry[@name=bill] > > read directly by anyone but the document owner. To make a bunch of > changes, the client would COPY (using webdav copy) the document into > the area, using a random filename as the target. It then makes the > changes using a series of PUT/POST/DELETE, with pipelining. > When done, > it performs a Webdav MOVE to place it back into the right place. We > can specify some rules for the server on only allowing a move of a > dcument back to the place where it was copied from. > > I *think* we can support MOVE and COPY (and the additional webdav > headers) without all of the rest of webdav, but I would need to > confirm that. I didnt find any words that said MOVE or COPY can be > applied to a non-webdav resource. > > If any intermediate operation should fail, the client just > DELETEs the > document from the scratch area, and the original remains as > it was. We > would also probably want to have documents in the scratch area expire > automatically after some time, so as to cleanup from incomplete > transactions. > > > > > Assuming it is possible to MOVE or COPY non-webdav resources, my > current preference is for option IV. > > Comments, questions, or other proposals? > > Thanks, > Jonathan R. > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Scientist Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Tue Jun 3 10:20:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06757 for ; Tue, 3 Jun 2003 10:20:50 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h53EKQf18595 for simple-archive@odin.ietf.org; Tue, 3 Jun 2003 10:20:26 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53EKPB18592 for ; Tue, 3 Jun 2003 10:20:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06739; Tue, 3 Jun 2003 10:20:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NCcS-0006SL-00; Tue, 03 Jun 2003 10:18:32 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19NCcR-0006SI-00; Tue, 03 Jun 2003 10:18:31 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53EFDB18250; Tue, 3 Jun 2003 10:15:13 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53EEwB18196 for ; Tue, 3 Jun 2003 10:14:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06461 for ; Tue, 3 Jun 2003 10:14:52 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NCXB-0006PM-00 for simple@ietf.org; Tue, 03 Jun 2003 10:13:05 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19NCXA-0006PJ-00 for simple@ietf.org; Tue, 03 Jun 2003 10:13:04 -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 h53EEqW05891 for ; Tue, 3 Jun 2003 17:14:52 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 3 Jun 2003 17:14:52 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 3 Jun 2003 17:14:52 +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" Subject: RE: [Simple] XCAP issue: batching Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701796D02@esebe019.ntc.nokia.com> Thread-Topic: [Simple] XCAP issue: batching Thread-Index: AcMpjavjawe3E0GfTAigiBKq/a5ilAAS/bpA To: , X-OriginalArrivalTime: 03 Jun 2003 14:14:52.0022 (UTC) FILETIME=[7FCC7160:01C329DA] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h53EEwB18197 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 3 Jun 2003 17:14:51 +0300 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit I don't yet have a preference, I have to think about the options a little more. I do have a question about option II though: Does going with option II potentially mean eliminating the need of the DELETE method usage? and perhaps PUT as well? So we only have POST and GET. Regards, Hisham > -----Original Message----- > From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Tuesday, June 03, 2003 8:02 AM > To: simple@ietf.org > Subject: [Simple] XCAP issue: batching > > > Folks, > > The main open issue in xcap at this time is batching. We discussed it > during the interim, and I have done some additional investigating > since then. > > The issue is this. In many cases, a client will want to modify a > document from X to Y. This modification may require a series of > changes to the document. However, the intermediate versions of the > document which result from those changes do not represent a > state that > the client finds acceptable. This could be because they are not > compliant to the schema, or because they are wrong or inappropriate. > An example is moving a buddy from a white list to a black list. That > would require two xcap operations - one to remove from the > white list, > one to add to the black list. After completing the first step, the > buddy is on NEITHER list, and if a subscription should arrive at > exactly that moment, the wrong thing would happen. This is basically > the consistency property of ACID. > > There are several ways this feature can be provided: > > Soln 1: Least Common Parent > > The "least common parent" is the XML element whose > descendants include > all of the nodes to be modified in the transaction, and for whom no > descendant also has this property. So, to provide the > transaction, the > client would read the value of the least common parent, modify all of > the elements as needed, and write it back to the server. > > The main drawback of this approach is overhead. The client may be > forced to read and write a lot of extra elements which are not > actually modified, but are within the subtree of the least common > parent. For buddy lists, this might mean reading the entire list, > modifying some of the entries, and writing it back. Not pretty. > > This approach works with xcap as written now. > > Approach II: Body Commands > > In this approach, we introduce a new operation that can be done on a > document. The body of the request (POST) would contain XML that > contains the sequence of operations to perform. So: > > POST > http://xcap.example.com/services/presence-lists/users/joe/list > 1.xml?batch > > > > /presence-lists/list[@name=friends]/entry[@name=bill] > > read directly by anyone but the document owner. To make a bunch of > changes, the client would COPY (using webdav copy) the document into > the area, using a random filename as the target. It then makes the > changes using a series of PUT/POST/DELETE, with pipelining. > When done, > it performs a Webdav MOVE to place it back into the right place. We > can specify some rules for the server on only allowing a move of a > dcument back to the place where it was copied from. > > I *think* we can support MOVE and COPY (and the additional webdav > headers) without all of the rest of webdav, but I would need to > confirm that. I didnt find any words that said MOVE or COPY can be > applied to a non-webdav resource. > > If any intermediate operation should fail, the client just > DELETEs the > document from the scratch area, and the original remains as > it was. We > would also probably want to have documents in the scratch area expire > automatically after some time, so as to cleanup from incomplete > transactions. > > > > > Assuming it is possible to MOVE or COPY non-webdav resources, my > current preference is for option IV. > > Comments, questions, or other proposals? > > Thanks, > Jonathan R. > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Scientist Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Jun 3 10:41:09 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 KAA07383; Tue, 3 Jun 2003 10:41:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NCwc-0006bs-00; Tue, 03 Jun 2003 10:39:22 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19NCwb-0006bp-00; Tue, 03 Jun 2003 10:39:21 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53Ea7B19533; Tue, 3 Jun 2003 10:36:07 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53EZbB19513 for ; Tue, 3 Jun 2003 10:35: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 KAA07183 for ; Tue, 3 Jun 2003 10:35:30 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NCrA-0006YX-00 for simple@ietf.org; Tue, 03 Jun 2003 10:33:44 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19NCr9-0006YU-00 for simple@ietf.org; Tue, 03 Jun 2003 10:33:43 -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 h53EZUW21988 for ; Tue, 3 Jun 2003 17:35:30 +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, 3 Jun 2003 17:35:30 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 3 Jun 2003 17:35:30 +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" Subject: RE: placing filters in refreshes, was: Re: [Simple] RE: Comments on draft-khartabil-simple-filter-funct-00 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701796D03@esebe019.ntc.nokia.com> Thread-Topic: placing filters in refreshes, was: Re: [Simple] RE: Comments on draft-khartabil-simple-filter-funct-00 Thread-Index: AcMnL2xMrpg3416OTxq6NcrbjWHsQQCq91Ow To: Cc: , X-OriginalArrivalTime: 03 Jun 2003 14:35:30.0373 (UTC) FILETIME=[61E9CF50:01C329DD] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h53EZbB19514 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 3 Jun 2003 17:35:29 +0300 Content-Transfer-Encoding: 8bit The body of a SUBSCRIBE may have many filters: eg: SUBSCRIBE ... content-type: application/simple-filter+xml filter id=1 filter id=2 filter id=3 Now, I want to remove filter 2. The way it is proposed now is to send a new SUBSCRIBE with filters 1 and 3. This is not efficient. What I was proposing was sending filter 2 id indicating that it is deleted. Filters 1 and 3 are not sent and therefore remain on the server. You propose hashing the whole body. How do I remove filter 2 in this case? Can you explain your proposal in more detail? If the SUBSCRIBE includes multiple hashes, one for each filter, then it might work. Something like this (for removing filter 2): SUBSCRIBE ... content-type: application/simple-filter+xml #(filter) id=1 #(filter) id=3 This is hardly an improvement. Regards, Hisham > -----Original Message----- > From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Saturday, May 31, 2003 2:33 AM > To: Khartabil Hisham (NMP/Helsinki) > Cc: AndrewAllen007@aol.com; simple@ietf.org > Subject: Re: placing filters in refreshes, was: Re: [Simple] RE: > Comments on draft-khartabil-simple-filter-funct-00 > > > It becomes really helpful if you ever run into a case where you want > to go back and forth between filters within the context of a > subscription. > > -Jonathan R. > > hisham.khartabil@nokia.com wrote: > > Sounds like a reasonable idea. But the question is if its > more complicated that adding an element or attribute that > indicates removal of a filter using the filter id. > > > > Regards, > > Hisham > > > > > >>-----Original Message----- > >>From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > >>Sent: Thursday, May 29, 2003 8:08 PM > >>To: Khartabil Hisham (NMP/Helsinki) > >>Cc: AndrewAllen007@aol.com; simple@ietf.org > >>Subject: placing filters in refreshes, was: Re: [Simple] RE: > >>Comments on > >>draft-khartabil-simple-filter-funct-00 > >> > >> > >> > >> > >>hisham.khartabil@nokia.com wrote: > >> > >>>>As I stated in my earlier email regarding the requirement draft I > >>>>have a concern with the replace semantics of the filter criteria > >>>>in the Subscribe. I am concerned that the filter criteria could > >>>>become quite large especially if the watcher has different filter > >>>>criteria for different presentities within presence lists. Do we > >>>>need to have every refresh subscriptions include all the filter > >>>>criteria for every presentity being watching everytime as our > >>>>goal is bandwidth efficiency between the watcher and the network? > >>>>I think that filter criteria will be modified by watchers a lot > >>>>less regularly than the period of refresh subscriptions and so it > >>>>is better to have some very small extra overhead when creating, > >>>>modifying or deleting the filter than having to include the > >>>>filter criteria in every refresh. I think some similar > >>>>functionality to the partial drafts may be the way forward here. > >>> > >>> > >>>As I commented earlier, I share your concern and will look into it > >>>before the next version of the I-D is released. > >> > >>I have an idea here. > >> > >>THe idea is that, instead of sending the filter, the > >>SUBSCRIBE refresh > >>includes a hash of the filter as the body of the request (with a > >>content-type along the lines of filter-hash or something). > The server > >>checks the hash to see if it maps against any existing filter > >>that has > >>been used in this dialog (and indeed, part of different > dialogs too - > >>would allow for sharing of filters). If so, the server acts > >>as if that > >>filter was in the body of the SUBSCRIBE. If not, it rejects teh > >>request and the client can re-try with the full filter. > >> > >>Basically, this is caching of filter documents, using a hash of the > >>document as a reference to a cache entry. > >> > >>-Jonathan R. > >> > >>-- > >>Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > >>Chief Scientist Parsippany, NJ > 07054-2711 > >>dynamicsoft > >>jdrosen@dynamicsoft.com FAX: (973) 952-5050 > >>http://www.jdrosen.net PHONE: (973) 952-5000 > >>http://www.dynamicsoft.com > >> > >> > > > > > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Scientist 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 mailnull@www1.ietf.org Tue Jun 3 10:41:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07410 for ; Tue, 3 Jun 2003 10:41:40 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h53EfGB20678 for simple-archive@odin.ietf.org; Tue, 3 Jun 2003 10:41:16 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53EfGB20675 for ; Tue, 3 Jun 2003 10:41:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07383; Tue, 3 Jun 2003 10:41:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NCwc-0006bs-00; Tue, 03 Jun 2003 10:39:22 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19NCwb-0006bp-00; Tue, 03 Jun 2003 10:39:21 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53Ea7B19533; Tue, 3 Jun 2003 10:36:07 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53EZbB19513 for ; Tue, 3 Jun 2003 10:35: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 KAA07183 for ; Tue, 3 Jun 2003 10:35:30 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NCrA-0006YX-00 for simple@ietf.org; Tue, 03 Jun 2003 10:33:44 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19NCr9-0006YU-00 for simple@ietf.org; Tue, 03 Jun 2003 10:33:43 -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 h53EZUW21988 for ; Tue, 3 Jun 2003 17:35:30 +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, 3 Jun 2003 17:35:30 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 3 Jun 2003 17:35:30 +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" Subject: RE: placing filters in refreshes, was: Re: [Simple] RE: Comments on draft-khartabil-simple-filter-funct-00 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701796D03@esebe019.ntc.nokia.com> Thread-Topic: placing filters in refreshes, was: Re: [Simple] RE: Comments on draft-khartabil-simple-filter-funct-00 Thread-Index: AcMnL2xMrpg3416OTxq6NcrbjWHsQQCq91Ow To: Cc: , X-OriginalArrivalTime: 03 Jun 2003 14:35:30.0373 (UTC) FILETIME=[61E9CF50:01C329DD] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h53EZbB19514 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 3 Jun 2003 17:35:29 +0300 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit The body of a SUBSCRIBE may have many filters: eg: SUBSCRIBE ... content-type: application/simple-filter+xml filter id=1 filter id=2 filter id=3 Now, I want to remove filter 2. The way it is proposed now is to send a new SUBSCRIBE with filters 1 and 3. This is not efficient. What I was proposing was sending filter 2 id indicating that it is deleted. Filters 1 and 3 are not sent and therefore remain on the server. You propose hashing the whole body. How do I remove filter 2 in this case? Can you explain your proposal in more detail? If the SUBSCRIBE includes multiple hashes, one for each filter, then it might work. Something like this (for removing filter 2): SUBSCRIBE ... content-type: application/simple-filter+xml #(filter) id=1 #(filter) id=3 This is hardly an improvement. Regards, Hisham > -----Original Message----- > From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Saturday, May 31, 2003 2:33 AM > To: Khartabil Hisham (NMP/Helsinki) > Cc: AndrewAllen007@aol.com; simple@ietf.org > Subject: Re: placing filters in refreshes, was: Re: [Simple] RE: > Comments on draft-khartabil-simple-filter-funct-00 > > > It becomes really helpful if you ever run into a case where you want > to go back and forth between filters within the context of a > subscription. > > -Jonathan R. > > hisham.khartabil@nokia.com wrote: > > Sounds like a reasonable idea. But the question is if its > more complicated that adding an element or attribute that > indicates removal of a filter using the filter id. > > > > Regards, > > Hisham > > > > > >>-----Original Message----- > >>From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > >>Sent: Thursday, May 29, 2003 8:08 PM > >>To: Khartabil Hisham (NMP/Helsinki) > >>Cc: AndrewAllen007@aol.com; simple@ietf.org > >>Subject: placing filters in refreshes, was: Re: [Simple] RE: > >>Comments on > >>draft-khartabil-simple-filter-funct-00 > >> > >> > >> > >> > >>hisham.khartabil@nokia.com wrote: > >> > >>>>As I stated in my earlier email regarding the requirement draft I > >>>>have a concern with the replace semantics of the filter criteria > >>>>in the Subscribe. I am concerned that the filter criteria could > >>>>become quite large especially if the watcher has different filter > >>>>criteria for different presentities within presence lists. Do we > >>>>need to have every refresh subscriptions include all the filter > >>>>criteria for every presentity being watching everytime as our > >>>>goal is bandwidth efficiency between the watcher and the network? > >>>>I think that filter criteria will be modified by watchers a lot > >>>>less regularly than the period of refresh subscriptions and so it > >>>>is better to have some very small extra overhead when creating, > >>>>modifying or deleting the filter than having to include the > >>>>filter criteria in every refresh. I think some similar > >>>>functionality to the partial drafts may be the way forward here. > >>> > >>> > >>>As I commented earlier, I share your concern and will look into it > >>>before the next version of the I-D is released. > >> > >>I have an idea here. > >> > >>THe idea is that, instead of sending the filter, the > >>SUBSCRIBE refresh > >>includes a hash of the filter as the body of the request (with a > >>content-type along the lines of filter-hash or something). > The server > >>checks the hash to see if it maps against any existing filter > >>that has > >>been used in this dialog (and indeed, part of different > dialogs too - > >>would allow for sharing of filters). If so, the server acts > >>as if that > >>filter was in the body of the SUBSCRIBE. If not, it rejects teh > >>request and the client can re-try with the full filter. > >> > >>Basically, this is caching of filter documents, using a hash of the > >>document as a reference to a cache entry. > >> > >>-Jonathan R. > >> > >>-- > >>Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > >>Chief Scientist Parsippany, NJ > 07054-2711 > >>dynamicsoft > >>jdrosen@dynamicsoft.com FAX: (973) 952-5050 > >>http://www.jdrosen.net PHONE: (973) 952-5000 > >>http://www.dynamicsoft.com > >> > >> > > > > > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Scientist 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 Jun 3 11:19:09 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 LAA09028; Tue, 3 Jun 2003 11:19:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NDXO-00070H-00; Tue, 03 Jun 2003 11:17:22 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19NDXN-00070E-00; Tue, 03 Jun 2003 11:17:21 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53FDpB23658; Tue, 3 Jun 2003 11:13:51 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53FCRB23535 for ; Tue, 3 Jun 2003 11:12:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08552 for ; Tue, 3 Jun 2003 11:12:25 -0400 (EDT) From: AndrewAllen007@aol.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NDQs-0006tI-00 for simple@ietf.org; Tue, 03 Jun 2003 11:10:38 -0400 Received: from imo-m04.mx.aol.com ([64.12.136.7]) by ietf-mx with esmtp (Exim 4.12) id 19NDQr-0006sj-00 for simple@ietf.org; Tue, 03 Jun 2003 11:10:37 -0400 Received: from AndrewAllen007@aol.com by imo-m04.mx.aol.com (mail_out_v36.3.) id l.65.1259f848 (16111) for ; Tue, 3 Jun 2003 11:11:51 -0400 (EDT) Received: from aol.com (mow-d14.webmail.aol.com [205.188.139.130]) by air-id12.mx.aol.com (v93.12) with ESMTP id MAILINID123-3eef3edcbab71; Tue, 03 Jun 2003 11:11:51 -0400 To: simple@ietf.org Subject: Re: placing filters in refreshes, was: Re: [Simple] RE: Comments on draft-khartabil-simple-filter-funct-00 MIME-Version: 1.0 Message-ID: <0915A663.6C36A748.2E6F5200@aol.com> X-Mailer: Atlas Mailer 2.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit 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, 03 Jun 2003 11:11:51 -0400 Content-Transfer-Encoding: 8bit Hisham, My responses below proceeded by [AA] Regards Andrew Sounds like a reasonable idea. But the question is if its more complicated that adding an element or attribute that indicates removal of a filter using the filter id. [AA] I think we also need to be able to add and modify filters without sending the entire filter document again so we need the filter id for that as well. The hash may help us with the out of synch detection and recovery problem. We will need a 4xx response code for when the hash is not found. Regards, Hisham _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Tue Jun 3 11:19:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09149 for ; Tue, 3 Jun 2003 11:19:40 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h53FJC024089 for simple-archive@odin.ietf.org; Tue, 3 Jun 2003 11:19:12 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53FJCB24086 for ; Tue, 3 Jun 2003 11:19:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09028; Tue, 3 Jun 2003 11:19:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NDXO-00070H-00; Tue, 03 Jun 2003 11:17:22 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19NDXN-00070E-00; Tue, 03 Jun 2003 11:17:21 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53FDpB23658; Tue, 3 Jun 2003 11:13:51 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53FCRB23535 for ; Tue, 3 Jun 2003 11:12:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08552 for ; Tue, 3 Jun 2003 11:12:25 -0400 (EDT) From: AndrewAllen007@aol.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NDQs-0006tI-00 for simple@ietf.org; Tue, 03 Jun 2003 11:10:38 -0400 Received: from imo-m04.mx.aol.com ([64.12.136.7]) by ietf-mx with esmtp (Exim 4.12) id 19NDQr-0006sj-00 for simple@ietf.org; Tue, 03 Jun 2003 11:10:37 -0400 Received: from AndrewAllen007@aol.com by imo-m04.mx.aol.com (mail_out_v36.3.) id l.65.1259f848 (16111) for ; Tue, 3 Jun 2003 11:11:51 -0400 (EDT) Received: from aol.com (mow-d14.webmail.aol.com [205.188.139.130]) by air-id12.mx.aol.com (v93.12) with ESMTP id MAILINID123-3eef3edcbab71; Tue, 03 Jun 2003 11:11:51 -0400 To: simple@ietf.org Subject: Re: placing filters in refreshes, was: Re: [Simple] RE: Comments on draft-khartabil-simple-filter-funct-00 MIME-Version: 1.0 Message-ID: <0915A663.6C36A748.2E6F5200@aol.com> X-Mailer: Atlas Mailer 2.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit 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, 03 Jun 2003 11:11:51 -0400 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hisham, My responses below proceeded by [AA] Regards Andrew Sounds like a reasonable idea. But the question is if its more complicated that adding an element or attribute that indicates removal of a filter using the filter id. [AA] I think we also need to be able to add and modify filters without sending the entire filter document again so we need the filter id for that as well. The hash may help us with the out of synch detection and recovery problem. We will need a 4xx response code for when the hash is not found. Regards, Hisham _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Jun 3 11:23:43 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 LAA09394; Tue, 3 Jun 2003 11:23:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NDbo-00075C-00; Tue, 03 Jun 2003 11:21:56 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19NDbn-000759-00; Tue, 03 Jun 2003 11:21:55 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53FIcB24053; Tue, 3 Jun 2003 11:18:38 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53FDXB23609 for ; Tue, 3 Jun 2003 11:13: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 LAA08594 for ; Tue, 3 Jun 2003 11:13:30 -0400 (EDT) From: AndrewAllen007@aol.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NDRv-0006u5-00 for simple@ietf.org; Tue, 03 Jun 2003 11:11:43 -0400 Received: from imo-r07.mx.aol.com ([152.163.225.103]) by ietf-mx with esmtp (Exim 4.12) id 19NDRv-0006tl-00 for simple@ietf.org; Tue, 03 Jun 2003 11:11:43 -0400 Received: from AndrewAllen007@aol.com by imo-r07.mx.aol.com (mail_out_v36.3.) id l.6d.125e6e77 (16086) for ; Tue, 3 Jun 2003 11:12:54 -0400 (EDT) Received: from aol.com (mow-d18.webmail.aol.com [205.188.139.134]) by air-id10.mx.aol.com (v93.12) with ESMTP id MAILINID103-3ed63edcbaf6338; Tue, 03 Jun 2003 11:12:54 -0400 To: simple@ietf.org Subject: Re: Use of require header in SUBSCRIBE with a filter (was: RE: [Simple] RE: Comments on draft-khartabil-simple-filter-funct-00) MIME-Version: 1.0 Message-ID: <773C00CD.1E07EF33.2E6F5200@aol.com> X-Mailer: Atlas Mailer 2.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit 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, 03 Jun 2003 11:12:54 -0400 Content-Transfer-Encoding: 8bit Hisham, My responses below proceeded by [AA] Regards Andrew > -----Original Message----- > From: ext AndrewAllen007@aol.com [mailto:AndrewAllen007@aol.com] > Sent: Thursday, May 29, 2003 6:32 PM > To: Khartabil Hisham (NMP/Helsinki); simple@ietf.org > Cc: AndrewAllen007@aol.com > Subject: Re: [Simple] RE: Comments on > draft-khartabil-simple-filter-funct-00 > > > > > > I think we need a separate mechanism to indicate the > > difference between options 2 and 3. Also the UAC should be > > able to indicate whether option 2 is acceptable since option > > 2 could result in a large presence document being sent in a > > Notify, which may not be acceptable to the UAC. > > I will remove references to the word "ignore" in the next > version. If a server does not like a filter, it rejects it. > When it comes to authorisation, the server can examine the > filter after its has applied the authorisation policy. I'll > clarify that also. > > [AA] This is certainly one approach we could take however > this means that if I would like to use filtering but I am > willing to accept the subscription without filtering then I > may have to make two subscription attempts one with and one > without filtering. It seems to me that it would be more > efficient to use the SIP extension use negotiation > capabilities (Supported and Require) for a more efficient and > flexible mechanism. This is also along the lines of what is > currently proposed in draft-lonnfors-simple-partial-notify > where the option is there to indicate whether the use of the > extension is required or not. IMO it would make sense to be > consistent with subscription state handling for both partial > notifications and filtering. > Firstly, I was just agreed in the interim meeting that this require-header in partial notification is not necessary and will be removed. It is widely accepted that it is a server choice to honour filters. Do we need to change that? I need input from others on the list. [AA] I think that the server should always have a choice whether to honour filters however the client needs to also be able to decide if it wants to subscribe without filters. I think that consistent behaviour of subscriptions with partial notification makes a lot of sense so lets just get rid of the possibility of the Server accepting the subscription while ignoring the filter as you proposed in your earlier email. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Tue Jun 3 11:24:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09422 for ; Tue, 3 Jun 2003 11:24:14 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h53FNkp24458 for simple-archive@odin.ietf.org; Tue, 3 Jun 2003 11:23:46 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53FNkB24455 for ; Tue, 3 Jun 2003 11:23:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09394; Tue, 3 Jun 2003 11:23:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NDbo-00075C-00; Tue, 03 Jun 2003 11:21:56 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19NDbn-000759-00; Tue, 03 Jun 2003 11:21:55 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53FIcB24053; Tue, 3 Jun 2003 11:18:38 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53FDXB23609 for ; Tue, 3 Jun 2003 11:13: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 LAA08594 for ; Tue, 3 Jun 2003 11:13:30 -0400 (EDT) From: AndrewAllen007@aol.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NDRv-0006u5-00 for simple@ietf.org; Tue, 03 Jun 2003 11:11:43 -0400 Received: from imo-r07.mx.aol.com ([152.163.225.103]) by ietf-mx with esmtp (Exim 4.12) id 19NDRv-0006tl-00 for simple@ietf.org; Tue, 03 Jun 2003 11:11:43 -0400 Received: from AndrewAllen007@aol.com by imo-r07.mx.aol.com (mail_out_v36.3.) id l.6d.125e6e77 (16086) for ; Tue, 3 Jun 2003 11:12:54 -0400 (EDT) Received: from aol.com (mow-d18.webmail.aol.com [205.188.139.134]) by air-id10.mx.aol.com (v93.12) with ESMTP id MAILINID103-3ed63edcbaf6338; Tue, 03 Jun 2003 11:12:54 -0400 To: simple@ietf.org Subject: Re: Use of require header in SUBSCRIBE with a filter (was: RE: [Simple] RE: Comments on draft-khartabil-simple-filter-funct-00) MIME-Version: 1.0 Message-ID: <773C00CD.1E07EF33.2E6F5200@aol.com> X-Mailer: Atlas Mailer 2.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit 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, 03 Jun 2003 11:12:54 -0400 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hisham, My responses below proceeded by [AA] Regards Andrew > -----Original Message----- > From: ext AndrewAllen007@aol.com [mailto:AndrewAllen007@aol.com] > Sent: Thursday, May 29, 2003 6:32 PM > To: Khartabil Hisham (NMP/Helsinki); simple@ietf.org > Cc: AndrewAllen007@aol.com > Subject: Re: [Simple] RE: Comments on > draft-khartabil-simple-filter-funct-00 > > > > > > I think we need a separate mechanism to indicate the > > difference between options 2 and 3. Also the UAC should be > > able to indicate whether option 2 is acceptable since option > > 2 could result in a large presence document being sent in a > > Notify, which may not be acceptable to the UAC. > > I will remove references to the word "ignore" in the next > version. If a server does not like a filter, it rejects it. > When it comes to authorisation, the server can examine the > filter after its has applied the authorisation policy. I'll > clarify that also. > > [AA] This is certainly one approach we could take however > this means that if I would like to use filtering but I am > willing to accept the subscription without filtering then I > may have to make two subscription attempts one with and one > without filtering. It seems to me that it would be more > efficient to use the SIP extension use negotiation > capabilities (Supported and Require) for a more efficient and > flexible mechanism. This is also along the lines of what is > currently proposed in draft-lonnfors-simple-partial-notify > where the option is there to indicate whether the use of the > extension is required or not. IMO it would make sense to be > consistent with subscription state handling for both partial > notifications and filtering. > Firstly, I was just agreed in the interim meeting that this require-header in partial notification is not necessary and will be removed. It is widely accepted that it is a server choice to honour filters. Do we need to change that? I need input from others on the list. [AA] I think that the server should always have a choice whether to honour filters however the client needs to also be able to decide if it wants to subscribe without filters. I think that consistent behaviour of subscriptions with partial notification makes a lot of sense so lets just get rid of the possibility of the Server accepting the subscription while ignoring the filter as you proposed in your earlier email. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Jun 3 11:25: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 LAA09447; Tue, 3 Jun 2003 11:25:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NDdW-00075o-00; Tue, 03 Jun 2003 11:23:42 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19NDdW-00075l-00; Tue, 03 Jun 2003 11:23:42 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53FKRB24228; Tue, 3 Jun 2003 11:20:27 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53FErB23709 for ; Tue, 3 Jun 2003 11:14:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08636 for ; Tue, 3 Jun 2003 11:14:50 -0400 (EDT) From: AndrewAllen007@aol.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NDTE-0006v4-00 for simple@ietf.org; Tue, 03 Jun 2003 11:13:04 -0400 Received: from imo-r07.mx.aol.com ([152.163.225.103]) by ietf-mx with esmtp (Exim 4.12) id 19NDTD-0006uj-00 for simple@ietf.org; Tue, 03 Jun 2003 11:13:03 -0400 Received: from AndrewAllen007@aol.com by imo-r07.mx.aol.com (mail_out_v36.3.) id l.164.2134b283 (15887) for ; Tue, 3 Jun 2003 11:14:13 -0400 (EDT) Received: from aol.com (mow-d19.webmail.aol.com [205.188.139.135]) by air-id08.mx.aol.com (v93.12) with ESMTP id MAILINID82-3e0f3edcbb45b4; Tue, 03 Jun 2003 11:14:13 -0400 To: simple@ietf.org Subject: Re: Scope of filter addressing (was: RE: [Simple] RE: Comments on draft-khartabil-simple-filter-funct-00) MIME-Version: 1.0 Message-ID: <5CC98E9E.72D98A67.2E6F5200@aol.com> X-Mailer: Atlas Mailer 2.0 Content-Type: text/plain; charset=utf-8 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, 03 Jun 2003 11:14:13 -0400 X-MIME-Autoconverted: from 8bit to quoted-printable by www1.ietf.org id h53FKRB24228 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA09447 Hisham, My responses below proceeded by [AA] Regards Andrew -----Original Message----- > From: ext AndrewAllen007@aol.com [mailto:AndrewAllen007@aol.com] > Sent: Thursday, May 29, 2003 6:32 PM > To: Khartabil Hisham (NMP/Helsinki); simple@ietf.org > Cc: AndrewAllen007@aol.com > Subject: Re: [Simple] RE: Comments on > draft-khartabil-simple-filter-funct-00 > [AA] The text at issue here is in clause 4.1 “If the URI > indicated by the filter criteria is for one resource who's > URI is NOT one of the URIs that result from a lookup, by the > RLS, on the Request-URI, the filter criteria are propagated > to all the fanned out subscriptions. This is to accommodate > the scenario where the > subscriber knows that there are sub-lists in the list that > the original subscription was sent to, and the subscriber > wishes to set a filter criteria for a resource in that sub-list.” > > [AA] The issue that I am identifying is when the filter > criteria corresponds to a resource that is a child of a sub > list of the list. For instance 3 lists A, B, and C, each in > different domains where A is a child of B and B is a child of > C: CàBàA > > [AA] Now in the subscription to C I want to be able to > include filter criteria that is targeted at a particular > member of list A (Amember1). In order to target the URI > member of A in the subscription to list C we need to specify > the path of the URI: C->B->A->Amember1. Maybe Xpath can also > be used for this purpose? For the reasons stated I think > simply propagating the filter criteria corresponding to a > resource unknown to the RLS to every descendent, (as I > understand from this text is proposed), is a bad idea. > Instead the filter criteria should only be propagated down > the specific branch that contains the target. In addition to > the issues raised earlier, I think also there may be privacy > concerns with broadcasting the filter criteria to other > branches of the tree that are possibly in different domains > from the target (i.e Do you want your company to know who all > your personal contacts are?) As was discussed in the interim meeting, this URI approach might not be good enough to describe wild cards (this filter applies to all people in nokia.com, people is a georgraphic location (this filter applies to people in helsinki), etc. This is certainly expanding the scope of this work and the question is do we need such scope. [AA] Unfortunately I was not at the interim meeting and so I do not fully understand this comment, (I will read Robert’s report for details when it comes out). I assume what is meant is that there is maybe some cases when you want a filter to be propagated down multiple branches because the filter criteria have global applicability. I think that there are also cases when you don’t (as I have shown in some of my examples). My understanding was that if the URI was the URI of the list then the filter criteria applies to all the members of the list and is propagated down all the branches. I think we also need the ability to target filters at individual members as well though. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Tue Jun 3 11:26:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09473 for ; Tue, 3 Jun 2003 11:26:00 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h53FPWX24547 for simple-archive@odin.ietf.org; Tue, 3 Jun 2003 11:25:32 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53FPWB24544 for ; Tue, 3 Jun 2003 11:25:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09447; Tue, 3 Jun 2003 11:25:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NDdW-00075o-00; Tue, 03 Jun 2003 11:23:42 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19NDdW-00075l-00; Tue, 03 Jun 2003 11:23:42 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53FKRB24228; Tue, 3 Jun 2003 11:20:27 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53FErB23709 for ; Tue, 3 Jun 2003 11:14:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08636 for ; Tue, 3 Jun 2003 11:14:50 -0400 (EDT) From: AndrewAllen007@aol.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NDTE-0006v4-00 for simple@ietf.org; Tue, 03 Jun 2003 11:13:04 -0400 Received: from imo-r07.mx.aol.com ([152.163.225.103]) by ietf-mx with esmtp (Exim 4.12) id 19NDTD-0006uj-00 for simple@ietf.org; Tue, 03 Jun 2003 11:13:03 -0400 Received: from AndrewAllen007@aol.com by imo-r07.mx.aol.com (mail_out_v36.3.) id l.164.2134b283 (15887) for ; Tue, 3 Jun 2003 11:14:13 -0400 (EDT) Received: from aol.com (mow-d19.webmail.aol.com [205.188.139.135]) by air-id08.mx.aol.com (v93.12) with ESMTP id MAILINID82-3e0f3edcbb45b4; Tue, 03 Jun 2003 11:14:13 -0400 To: simple@ietf.org Subject: Re: Scope of filter addressing (was: RE: [Simple] RE: Comments on draft-khartabil-simple-filter-funct-00) MIME-Version: 1.0 Message-ID: <5CC98E9E.72D98A67.2E6F5200@aol.com> X-Mailer: Atlas Mailer 2.0 Content-Type: text/plain; charset=utf-8 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, 03 Jun 2003 11:14:13 -0400 X-MIME-Autoconverted: from 8bit to quoted-printable by www1.ietf.org id h53FKRB24228 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h53FPWB24544 Content-Transfer-Encoding: 8bit Hisham, My responses below proceeded by [AA] Regards Andrew -----Original Message----- > From: ext AndrewAllen007@aol.com [mailto:AndrewAllen007@aol.com] > Sent: Thursday, May 29, 2003 6:32 PM > To: Khartabil Hisham (NMP/Helsinki); simple@ietf.org > Cc: AndrewAllen007@aol.com > Subject: Re: [Simple] RE: Comments on > draft-khartabil-simple-filter-funct-00 > [AA] The text at issue here is in clause 4.1 “If the URI > indicated by the filter criteria is for one resource who's > URI is NOT one of the URIs that result from a lookup, by the > RLS, on the Request-URI, the filter criteria are propagated > to all the fanned out subscriptions. This is to accommodate > the scenario where the > subscriber knows that there are sub-lists in the list that > the original subscription was sent to, and the subscriber > wishes to set a filter criteria for a resource in that sub-list.” > > [AA] The issue that I am identifying is when the filter > criteria corresponds to a resource that is a child of a sub > list of the list. For instance 3 lists A, B, and C, each in > different domains where A is a child of B and B is a child of > C: CàBàA > > [AA] Now in the subscription to C I want to be able to > include filter criteria that is targeted at a particular > member of list A (Amember1). In order to target the URI > member of A in the subscription to list C we need to specify > the path of the URI: C->B->A->Amember1. Maybe Xpath can also > be used for this purpose? For the reasons stated I think > simply propagating the filter criteria corresponding to a > resource unknown to the RLS to every descendent, (as I > understand from this text is proposed), is a bad idea. > Instead the filter criteria should only be propagated down > the specific branch that contains the target. In addition to > the issues raised earlier, I think also there may be privacy > concerns with broadcasting the filter criteria to other > branches of the tree that are possibly in different domains > from the target (i.e Do you want your company to know who all > your personal contacts are?) As was discussed in the interim meeting, this URI approach might not be good enough to describe wild cards (this filter applies to all people in nokia.com, people is a georgraphic location (this filter applies to people in helsinki), etc. This is certainly expanding the scope of this work and the question is do we need such scope. [AA] Unfortunately I was not at the interim meeting and so I do not fully understand this comment, (I will read Robert’s report for details when it comes out). I assume what is meant is that there is maybe some cases when you want a filter to be propagated down multiple branches because the filter criteria have global applicability. I think that there are also cases when you don’t (as I have shown in some of my examples). My understanding was that if the URI was the URI of the list then the filter criteria applies to all the members of the list and is propagated down all the branches. I think we also need the ability to target filters at individual members as well though. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Jun 3 11:53:30 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 LAA11399; Tue, 3 Jun 2003 11:53:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NE4e-0007YX-00; Tue, 03 Jun 2003 11:51:44 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19NE4d-0007YU-00; Tue, 03 Jun 2003 11:51:43 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53FmDB27133; Tue, 3 Jun 2003 11:48:13 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53FltB27086 for ; Tue, 3 Jun 2003 11:47:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11061 for ; Tue, 3 Jun 2003 11:47:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NDzB-0007Tr-00 for simple@ietf.org; Tue, 03 Jun 2003 11:46:05 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19NDzA-0007TX-00 for simple@ietf.org; Tue, 03 Jun 2003 11:46:04 -0400 Received: from dynamicsoft.com ([63.113.46.71]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h53FlPZE007290; Tue, 3 Jun 2003 11:47:25 -0400 (EDT) Message-ID: <3EDCC309.50209@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: simple@ietf.org Subject: Re: [Simple] XCAP issue: batching References: <2038BCC78B1AD641891A0D1AE133DBB701796D02@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701796D02@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 03 Jun 2003 11:47:21 -0400 Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > I don't yet have a preference, I have to think about the options a > little more. I do have a question about option II though: > > Does going with option II potentially mean eliminating the need of > the DELETE method usage? and perhaps PUT as well? So we only have > POST and GET. I suppose so, but at the cost of a lot of overhead. Basically, in the case of buddy lists, to delete a buddy, you'd have to re-POST the entire list, just without that buddy. Not what we want to do, I think. Also, that would not work for deleting documents, where an explicit DELETE is still needed. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Scientist 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 mailnull@www1.ietf.org Tue Jun 3 11:54:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11430 for ; Tue, 3 Jun 2003 11:54:01 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h53FrYq27501 for simple-archive@odin.ietf.org; Tue, 3 Jun 2003 11:53:34 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53FrYB27498 for ; Tue, 3 Jun 2003 11:53:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11399; Tue, 3 Jun 2003 11:53:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NE4e-0007YX-00; Tue, 03 Jun 2003 11:51:44 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19NE4d-0007YU-00; Tue, 03 Jun 2003 11:51:43 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53FmDB27133; Tue, 3 Jun 2003 11:48:13 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53FltB27086 for ; Tue, 3 Jun 2003 11:47:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11061 for ; Tue, 3 Jun 2003 11:47:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NDzB-0007Tr-00 for simple@ietf.org; Tue, 03 Jun 2003 11:46:05 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19NDzA-0007TX-00 for simple@ietf.org; Tue, 03 Jun 2003 11:46:04 -0400 Received: from dynamicsoft.com ([63.113.46.71]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h53FlPZE007290; Tue, 3 Jun 2003 11:47:25 -0400 (EDT) Message-ID: <3EDCC309.50209@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: simple@ietf.org Subject: Re: [Simple] XCAP issue: batching References: <2038BCC78B1AD641891A0D1AE133DBB701796D02@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701796D02@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 03 Jun 2003 11:47:21 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > I don't yet have a preference, I have to think about the options a > little more. I do have a question about option II though: > > Does going with option II potentially mean eliminating the need of > the DELETE method usage? and perhaps PUT as well? So we only have > POST and GET. I suppose so, but at the cost of a lot of overhead. Basically, in the case of buddy lists, to delete a buddy, you'd have to re-POST the entire list, just without that buddy. Not what we want to do, I think. Also, that would not work for deleting documents, where an explicit DELETE is still needed. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Scientist 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 Jun 3 12:00:57 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 MAA11875; Tue, 3 Jun 2003 12:00:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NEBq-0007hj-00; Tue, 03 Jun 2003 11:59:11 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19NEBq-0007hf-00; Tue, 03 Jun 2003 11:59:10 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53Ft5B27667; Tue, 3 Jun 2003 11:55:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53FsbB27601 for ; Tue, 3 Jun 2003 11:54: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 LAA11462 for ; Tue, 3 Jun 2003 11:54:34 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NE5f-0007ZC-00 for simple@ietf.org; Tue, 03 Jun 2003 11:52:48 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19NE5f-0007Z9-00 for simple@ietf.org; Tue, 03 Jun 2003 11:52:47 -0400 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h53FsYD20399 for ; Tue, 3 Jun 2003 18:54:34 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 3 Jun 2003 18:54:33 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 3 Jun 2003 18:54:34 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 3 Jun 2003 18:54:33 +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" Subject: RE: [Simple] XCAP issue: batching Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701796D06@esebe019.ntc.nokia.com> Thread-Topic: [Simple] XCAP issue: batching Thread-Index: AcMp54VjdTZtusScQ2Wy1v0Sk/rE5gAALn6w To: Cc: X-OriginalArrivalTime: 03 Jun 2003 15:54:33.0807 (UTC) FILETIME=[6D3865F0:01C329E8] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h53FscB27602 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 3 Jun 2003 18:54:33 +0300 Content-Transfer-Encoding: 8bit I meant something like this: POST http://xcap.example.com/services/presence-lists/users/joe/list 1.xml /presence-lists/list[@name=friends]/entry[@name=bill] /Hisham > -----Original Message----- > From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Tuesday, June 03, 2003 6:47 PM > To: Khartabil Hisham (NMP/Helsinki) > Cc: simple@ietf.org > Subject: Re: [Simple] XCAP issue: batching > > > > > hisham.khartabil@nokia.com wrote: > > I don't yet have a preference, I have to think about the options a > > little more. I do have a question about option II though: > > > > Does going with option II potentially mean eliminating the need of > > the DELETE method usage? and perhaps PUT as well? So we only have > > POST and GET. > > I suppose so, but at the cost of a lot of overhead. Basically, in the > case of buddy lists, to delete a buddy, you'd have to re-POST the > entire list, just without that buddy. Not what we want to do, I think. > > Also, that would not work for deleting documents, where an explicit > DELETE is still needed. > > -Jonathan R. > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Scientist 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 mailnull@www1.ietf.org Tue Jun 3 12:01:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11932 for ; Tue, 3 Jun 2003 12:01:28 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h53G11o28192 for simple-archive@odin.ietf.org; Tue, 3 Jun 2003 12:01:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53G11B28189 for ; Tue, 3 Jun 2003 12:01:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11875; Tue, 3 Jun 2003 12:00:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NEBq-0007hj-00; Tue, 03 Jun 2003 11:59:11 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19NEBq-0007hf-00; Tue, 03 Jun 2003 11:59:10 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53Ft5B27667; Tue, 3 Jun 2003 11:55:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53FsbB27601 for ; Tue, 3 Jun 2003 11:54: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 LAA11462 for ; Tue, 3 Jun 2003 11:54:34 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NE5f-0007ZC-00 for simple@ietf.org; Tue, 03 Jun 2003 11:52:48 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19NE5f-0007Z9-00 for simple@ietf.org; Tue, 03 Jun 2003 11:52:47 -0400 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h53FsYD20399 for ; Tue, 3 Jun 2003 18:54:34 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 3 Jun 2003 18:54:33 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 3 Jun 2003 18:54:34 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 3 Jun 2003 18:54:33 +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" Subject: RE: [Simple] XCAP issue: batching Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701796D06@esebe019.ntc.nokia.com> Thread-Topic: [Simple] XCAP issue: batching Thread-Index: AcMp54VjdTZtusScQ2Wy1v0Sk/rE5gAALn6w To: Cc: X-OriginalArrivalTime: 03 Jun 2003 15:54:33.0807 (UTC) FILETIME=[6D3865F0:01C329E8] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h53FscB27602 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 3 Jun 2003 18:54:33 +0300 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit I meant something like this: POST http://xcap.example.com/services/presence-lists/users/joe/list 1.xml /presence-lists/list[@name=friends]/entry[@name=bill] /Hisham > -----Original Message----- > From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Tuesday, June 03, 2003 6:47 PM > To: Khartabil Hisham (NMP/Helsinki) > Cc: simple@ietf.org > Subject: Re: [Simple] XCAP issue: batching > > > > > hisham.khartabil@nokia.com wrote: > > I don't yet have a preference, I have to think about the options a > > little more. I do have a question about option II though: > > > > Does going with option II potentially mean eliminating the need of > > the DELETE method usage? and perhaps PUT as well? So we only have > > POST and GET. > > I suppose so, but at the cost of a lot of overhead. Basically, in the > case of buddy lists, to delete a buddy, you'd have to re-POST the > entire list, just without that buddy. Not what we want to do, I think. > > Also, that would not work for deleting documents, where an explicit > DELETE is still needed. > > -Jonathan R. > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Scientist 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 Jun 3 12: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 MAA12407; Tue, 3 Jun 2003 12:10:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NEL2-00001M-00; Tue, 03 Jun 2003 12:08:40 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19NEL1-00001J-00; Tue, 03 Jun 2003 12:08:39 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53G59B28901; Tue, 3 Jun 2003 12:05:09 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53G3CB28508 for ; Tue, 3 Jun 2003 12:03:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12065 for ; Tue, 3 Jun 2003 12:03:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NEDx-0007ja-00 for simple@ietf.org; Tue, 03 Jun 2003 12:01:21 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19NEDx-0007j0-00 for simple@ietf.org; Tue, 03 Jun 2003 12:01:21 -0400 Received: from dynamicsoft.com ([63.113.46.71]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h53G2hZE007384; Tue, 3 Jun 2003 12:02:43 -0400 (EDT) Message-ID: <3EDCC69E.2030308@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: simple@ietf.org Subject: Re: [Simple] XCAP issue: batching References: <2038BCC78B1AD641891A0D1AE133DBB701796D06@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701796D06@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 03 Jun 2003 12:02:38 -0400 Content-Transfer-Encoding: 7bit I see. Yes, you could do that. I personally don't like it too much, since it devolves into using HTTP as a tunelling protocol for something that is more or less HTTP, but in XML format. I like the idea of preserving the HTTP semantics. -Jonathan R. hisham.khartabil@nokia.com wrote: > I meant something like this: > > POST http://xcap.example.com/services/presence-lists/users/joe/list 1.xml > > /presence-lists/list[@name=friends]/entry[@name=bill] > > /Hisham > > >>-----Original Message----- >>From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] >>Sent: Tuesday, June 03, 2003 6:47 PM >>To: Khartabil Hisham (NMP/Helsinki) >>Cc: simple@ietf.org >>Subject: Re: [Simple] XCAP issue: batching >> >> >> >> >>hisham.khartabil@nokia.com wrote: >> >>>I don't yet have a preference, I have to think about the options a >>>little more. I do have a question about option II though: >>> >>>Does going with option II potentially mean eliminating the need of >>>the DELETE method usage? and perhaps PUT as well? So we only have >>>POST and GET. >> >>I suppose so, but at the cost of a lot of overhead. Basically, in the >>case of buddy lists, to delete a buddy, you'd have to re-POST the >>entire list, just without that buddy. Not what we want to do, I think. >> >>Also, that would not work for deleting documents, where an explicit >>DELETE is still needed. >> >>-Jonathan R. >> >>-- >>Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >>Chief Scientist Parsippany, NJ 07054-2711 >>dynamicsoft >>jdrosen@dynamicsoft.com FAX: (973) 952-5050 >>http://www.jdrosen.net PHONE: (973) 952-5000 >>http://www.dynamicsoft.com >> >> > > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Scientist 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 mailnull@www1.ietf.org Tue Jun 3 12:10:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12432 for ; Tue, 3 Jun 2003 12:10:57 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h53GAVm30238 for simple-archive@odin.ietf.org; Tue, 3 Jun 2003 12:10:31 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53GAVB30235 for ; Tue, 3 Jun 2003 12:10:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12407; Tue, 3 Jun 2003 12:10:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NEL2-00001M-00; Tue, 03 Jun 2003 12:08:40 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19NEL1-00001J-00; Tue, 03 Jun 2003 12:08:39 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53G59B28901; Tue, 3 Jun 2003 12:05:09 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53G3CB28508 for ; Tue, 3 Jun 2003 12:03:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12065 for ; Tue, 3 Jun 2003 12:03:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NEDx-0007ja-00 for simple@ietf.org; Tue, 03 Jun 2003 12:01:21 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19NEDx-0007j0-00 for simple@ietf.org; Tue, 03 Jun 2003 12:01:21 -0400 Received: from dynamicsoft.com ([63.113.46.71]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h53G2hZE007384; Tue, 3 Jun 2003 12:02:43 -0400 (EDT) Message-ID: <3EDCC69E.2030308@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: simple@ietf.org Subject: Re: [Simple] XCAP issue: batching References: <2038BCC78B1AD641891A0D1AE133DBB701796D06@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701796D06@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 03 Jun 2003 12:02:38 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I see. Yes, you could do that. I personally don't like it too much, since it devolves into using HTTP as a tunelling protocol for something that is more or less HTTP, but in XML format. I like the idea of preserving the HTTP semantics. -Jonathan R. hisham.khartabil@nokia.com wrote: > I meant something like this: > > POST http://xcap.example.com/services/presence-lists/users/joe/list 1.xml > > /presence-lists/list[@name=friends]/entry[@name=bill] > > /Hisham > > >>-----Original Message----- >>From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] >>Sent: Tuesday, June 03, 2003 6:47 PM >>To: Khartabil Hisham (NMP/Helsinki) >>Cc: simple@ietf.org >>Subject: Re: [Simple] XCAP issue: batching >> >> >> >> >>hisham.khartabil@nokia.com wrote: >> >>>I don't yet have a preference, I have to think about the options a >>>little more. I do have a question about option II though: >>> >>>Does going with option II potentially mean eliminating the need of >>>the DELETE method usage? and perhaps PUT as well? So we only have >>>POST and GET. >> >>I suppose so, but at the cost of a lot of overhead. Basically, in the >>case of buddy lists, to delete a buddy, you'd have to re-POST the >>entire list, just without that buddy. Not what we want to do, I think. >> >>Also, that would not work for deleting documents, where an explicit >>DELETE is still needed. >> >>-Jonathan R. >> >>-- >>Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >>Chief Scientist Parsippany, NJ 07054-2711 >>dynamicsoft >>jdrosen@dynamicsoft.com FAX: (973) 952-5050 >>http://www.jdrosen.net PHONE: (973) 952-5000 >>http://www.dynamicsoft.com >> >> > > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Scientist 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 Jun 3 14:44:46 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 OAA19081; Tue, 3 Jun 2003 14:44:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NGkM-0001ha-00; Tue, 03 Jun 2003 14:42:58 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19NGkL-0001hW-00; Tue, 03 Jun 2003 14:42:57 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53IdTB15374; Tue, 3 Jun 2003 14:39:29 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53IcsB15329 for ; Tue, 3 Jun 2003 14:38: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 OAA18935 for ; Tue, 3 Jun 2003 14:38:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NGeb-0001ej-00 for simple@ietf.org; Tue, 03 Jun 2003 14:37:01 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19NGea-0001eI-00 for simple@ietf.org; Tue, 03 Jun 2003 14:37:00 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h53IcC630680; Tue, 3 Jun 2003 13:38:12 -0500 Subject: Re: [Simple] "What is a tuple" design team From: Robert Sparks To: "Vijay K. Gurbani" Cc: simple@ietf.org In-Reply-To: <3ED7D2E5.1000108@lucent.com> References: <1054325208.935.449.camel@RjS.localdomain> <3ED7D2E5.1000108@lucent.com> Content-Type: text/plain Message-Id: <1054665489.941.57.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 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: 03 Jun 2003 13:38:10 -0500 Content-Transfer-Encoding: 7bit Did you want to be on this team? Do you have the time? I can't tell from the below note if you are wanting to participate or just track. RjS On Fri, 2003-05-30 at 16:53, Vijay K. Gurbani wrote: > Robert Sparks wrote: > > We will be forming a design team that will propose a > > conclusion to the "what is a tuple" conversation. This > > team will meet next week and will be operating under > > an aggressive deadline (3 or fewer weeks). > > Robert: > > Could you please post a summary/notes of the "what is a > tuple" conversation to the WG list? Much as I would > have liked to make it to the interim meeting, I could > not and would like to see what transpired at that > particular session, at the very least. > > Thanks, > > - vijay _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Tue Jun 3 14:45:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19112 for ; Tue, 3 Jun 2003 14:45:16 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h53Iiqa15914 for simple-archive@odin.ietf.org; Tue, 3 Jun 2003 14:44:52 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53IiqB15911 for ; Tue, 3 Jun 2003 14:44:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19081; Tue, 3 Jun 2003 14:44:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NGkM-0001ha-00; Tue, 03 Jun 2003 14:42:58 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19NGkL-0001hW-00; Tue, 03 Jun 2003 14:42:57 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53IdTB15374; Tue, 3 Jun 2003 14:39:29 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53IcsB15329 for ; Tue, 3 Jun 2003 14:38: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 OAA18935 for ; Tue, 3 Jun 2003 14:38:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NGeb-0001ej-00 for simple@ietf.org; Tue, 03 Jun 2003 14:37:01 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19NGea-0001eI-00 for simple@ietf.org; Tue, 03 Jun 2003 14:37:00 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h53IcC630680; Tue, 3 Jun 2003 13:38:12 -0500 Subject: Re: [Simple] "What is a tuple" design team From: Robert Sparks To: "Vijay K. Gurbani" Cc: simple@ietf.org In-Reply-To: <3ED7D2E5.1000108@lucent.com> References: <1054325208.935.449.camel@RjS.localdomain> <3ED7D2E5.1000108@lucent.com> Content-Type: text/plain Message-Id: <1054665489.941.57.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 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: 03 Jun 2003 13:38:10 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Did you want to be on this team? Do you have the time? I can't tell from the below note if you are wanting to participate or just track. RjS On Fri, 2003-05-30 at 16:53, Vijay K. Gurbani wrote: > Robert Sparks wrote: > > We will be forming a design team that will propose a > > conclusion to the "what is a tuple" conversation. This > > team will meet next week and will be operating under > > an aggressive deadline (3 or fewer weeks). > > Robert: > > Could you please post a summary/notes of the "what is a > tuple" conversation to the WG list? Much as I would > have liked to make it to the interim meeting, I could > not and would like to see what transpired at that > particular session, at the very least. > > Thanks, > > - vijay _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Jun 3 14:52: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 OAA19361; Tue, 3 Jun 2003 14:52:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NGrO-0001la-00; Tue, 03 Jun 2003 14:50:14 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19NGrO-0001lX-00; Tue, 03 Jun 2003 14:50:14 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53Il2B16112; Tue, 3 Jun 2003 14:47:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53IkcB16067 for ; Tue, 3 Jun 2003 14:46: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 OAA19165 for ; Tue, 3 Jun 2003 14:46:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NGm4-0001iH-00 for simple@ietf.org; Tue, 03 Jun 2003 14:44:44 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19NGm3-0001i4-00 for simple@ietf.org; Tue, 03 Jun 2003 14:44:43 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h53Ijv630761; Tue, 3 Jun 2003 13:45:57 -0500 Subject: Re: [Simple] "What is a tuple" design team From: Robert Sparks To: "Vijay K. Gurbani" Cc: simple@ietf.org In-Reply-To: <1054665489.941.57.camel@RjS.localdomain> References: <1054325208.935.449.camel@RjS.localdomain> <3ED7D2E5.1000108@lucent.com> <1054665489.941.57.camel@RjS.localdomain> Content-Type: text/plain Message-Id: <1054665955.1068.68.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 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: 03 Jun 2003 13:45:55 -0500 Content-Transfer-Encoding: 7bit D'OH - Sorry - I meant that to be a personal reply, not on-list. Apologies to all. RjS On Tue, 2003-06-03 at 13:38, Robert Sparks wrote: > Did you want to be on this team? Do you have the time? > I can't tell from the below note if you are wanting to > participate or just track. > > RjS > > On Fri, 2003-05-30 at 16:53, Vijay K. Gurbani wrote: > > Robert Sparks wrote: > > > We will be forming a design team that will propose a > > > conclusion to the "what is a tuple" conversation. This > > > team will meet next week and will be operating under > > > an aggressive deadline (3 or fewer weeks). > > > > Robert: > > > > Could you please post a summary/notes of the "what is a > > tuple" conversation to the WG list? Much as I would > > have liked to make it to the interim meeting, I could > > not and would like to see what transpired at that > > particular session, at the very least. > > > > Thanks, > > > > - vijay > > _______________________________________________ > Simple mailing 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 mailnull@www1.ietf.org Tue Jun 3 14:52:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19420 for ; Tue, 3 Jun 2003 14:52:33 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h53Iq8916632 for simple-archive@odin.ietf.org; Tue, 3 Jun 2003 14:52:08 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53Iq8B16629 for ; Tue, 3 Jun 2003 14:52: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 OAA19361; Tue, 3 Jun 2003 14:52:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NGrO-0001la-00; Tue, 03 Jun 2003 14:50:14 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19NGrO-0001lX-00; Tue, 03 Jun 2003 14:50:14 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53Il2B16112; Tue, 3 Jun 2003 14:47:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53IkcB16067 for ; Tue, 3 Jun 2003 14:46: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 OAA19165 for ; Tue, 3 Jun 2003 14:46:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NGm4-0001iH-00 for simple@ietf.org; Tue, 03 Jun 2003 14:44:44 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19NGm3-0001i4-00 for simple@ietf.org; Tue, 03 Jun 2003 14:44:43 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h53Ijv630761; Tue, 3 Jun 2003 13:45:57 -0500 Subject: Re: [Simple] "What is a tuple" design team From: Robert Sparks To: "Vijay K. Gurbani" Cc: simple@ietf.org In-Reply-To: <1054665489.941.57.camel@RjS.localdomain> References: <1054325208.935.449.camel@RjS.localdomain> <3ED7D2E5.1000108@lucent.com> <1054665489.941.57.camel@RjS.localdomain> Content-Type: text/plain Message-Id: <1054665955.1068.68.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 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: 03 Jun 2003 13:45:55 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit D'OH - Sorry - I meant that to be a personal reply, not on-list. Apologies to all. RjS On Tue, 2003-06-03 at 13:38, Robert Sparks wrote: > Did you want to be on this team? Do you have the time? > I can't tell from the below note if you are wanting to > participate or just track. > > RjS > > On Fri, 2003-05-30 at 16:53, Vijay K. Gurbani wrote: > > Robert Sparks wrote: > > > We will be forming a design team that will propose a > > > conclusion to the "what is a tuple" conversation. This > > > team will meet next week and will be operating under > > > an aggressive deadline (3 or fewer weeks). > > > > Robert: > > > > Could you please post a summary/notes of the "what is a > > tuple" conversation to the WG list? Much as I would > > have liked to make it to the interim meeting, I could > > not and would like to see what transpired at that > > particular session, at the very least. > > > > Thanks, > > > > - vijay > > _______________________________________________ > Simple mailing 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 Jun 3 16:02:51 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 QAA22829; Tue, 3 Jun 2003 16:02:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NHxw-0002MJ-00; Tue, 03 Jun 2003 16:01:04 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19NHxv-0002MG-00; Tue, 03 Jun 2003 16:01:03 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53JvHB23258; Tue, 3 Jun 2003 15:57:18 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53Ju3B23196 for ; Tue, 3 Jun 2003 15:56: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 PAA22637 for ; Tue, 3 Jun 2003 15:56:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NHrJ-0002Jc-00 for simple@ietf.org; Tue, 03 Jun 2003 15:54:13 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19NHrI-0002JO-00 for simple@ietf.org; Tue, 03 Jun 2003 15:54:12 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h53JtS631392 for ; Tue, 3 Jun 2003 14:55:28 -0500 Subject: Re: [Simple] "What is a tuple" design team From: Robert Sparks To: simple@ietf.org In-Reply-To: <1054325208.935.449.camel@RjS.localdomain> References: <1054325208.935.449.camel@RjS.localdomain> Content-Type: text/plain Message-Id: <1054670125.1068.154.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 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: 03 Jun 2003 14:55:25 -0500 Content-Transfer-Encoding: 7bit This team will initially consist of Keith Drage Ben Campbell Brian Rosen Henning Schulzrinne Aziz Mohammed Aki Niemi Adam Roach Thanos Diacakis Jonathan Rosenberg Robert Sparks Jon Peterson The team will begin meeting this week and will operate on the schedule discussed below. RjS On Fri, 2003-05-30 at 15:06, Robert Sparks wrote: > We will be forming a design team that will propose a > conclusion to the "what is a tuple" conversation. This > team will meet next week and will be operating under > an aggressive deadline (3 or fewer weeks). > > If you wish to participate and can spend significant > time on this effort (expect one or more 4 hour meetings > per week), send mail to me with your availability next > week. I will announce the design team membership next > Tuesday. > > RjS > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Tue Jun 3 16:03:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22874 for ; Tue, 3 Jun 2003 16:03:22 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h53K2ta23515 for simple-archive@odin.ietf.org; Tue, 3 Jun 2003 16:02:55 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53K2tB23512 for ; Tue, 3 Jun 2003 16:02:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22829; Tue, 3 Jun 2003 16:02:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NHxw-0002MJ-00; Tue, 03 Jun 2003 16:01:04 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19NHxv-0002MG-00; Tue, 03 Jun 2003 16:01:03 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53JvHB23258; Tue, 3 Jun 2003 15:57:18 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53Ju3B23196 for ; Tue, 3 Jun 2003 15:56: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 PAA22637 for ; Tue, 3 Jun 2003 15:56:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NHrJ-0002Jc-00 for simple@ietf.org; Tue, 03 Jun 2003 15:54:13 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19NHrI-0002JO-00 for simple@ietf.org; Tue, 03 Jun 2003 15:54:12 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h53JtS631392 for ; Tue, 3 Jun 2003 14:55:28 -0500 Subject: Re: [Simple] "What is a tuple" design team From: Robert Sparks To: simple@ietf.org In-Reply-To: <1054325208.935.449.camel@RjS.localdomain> References: <1054325208.935.449.camel@RjS.localdomain> Content-Type: text/plain Message-Id: <1054670125.1068.154.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 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: 03 Jun 2003 14:55:25 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit This team will initially consist of Keith Drage Ben Campbell Brian Rosen Henning Schulzrinne Aziz Mohammed Aki Niemi Adam Roach Thanos Diacakis Jonathan Rosenberg Robert Sparks Jon Peterson The team will begin meeting this week and will operate on the schedule discussed below. RjS On Fri, 2003-05-30 at 15:06, Robert Sparks wrote: > We will be forming a design team that will propose a > conclusion to the "what is a tuple" conversation. This > team will meet next week and will be operating under > an aggressive deadline (3 or fewer weeks). > > If you wish to participate and can spend significant > time on this effort (expect one or more 4 hour meetings > per week), send mail to me with your availability next > week. I will announce the design team membership next > Tuesday. > > RjS > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Jun 3 17:40:34 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 RAA25527; Tue, 3 Jun 2003 17:40:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NJUV-00034V-00; Tue, 03 Jun 2003 17:38:47 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19NJUU-00034S-00; Tue, 03 Jun 2003 17:38:46 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53LZGB31384; Tue, 3 Jun 2003 17:35:16 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53LYtB31349 for ; Tue, 3 Jun 2003 17:34:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25360 for ; Tue, 3 Jun 2003 17:34:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NJOx-00031f-00 for simple@ietf.org; Tue, 03 Jun 2003 17:33:03 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19NJOv-00031M-00 for simple@ietf.org; Tue, 03 Jun 2003 17:33:01 -0400 Received: from dynamicsoft.com ([63.113.46.71]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h53LXdZE007940; Tue, 3 Jun 2003 17:33:41 -0400 (EDT) Message-ID: <3EDD142C.9030306@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: AndrewAllen007@aol.com, simple@ietf.org Subject: Re: placing filters in refreshes, was: Re: [Simple] RE: Comments on draft-khartabil-simple-filter-funct-00 References: <2038BCC78B1AD641891A0D1AE133DBB701796D03@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701796D03@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 03 Jun 2003 17:33:32 -0400 Content-Transfer-Encoding: 7bit inline. hisham.khartabil@nokia.com wrote: > The body of a SUBSCRIBE may have many filters: > > eg: > > SUBSCRIBE ... content-type: application/simple-filter+xml > > filter id=1 > > filter id=2 > > filter id=3 > > Now, I want to remove filter 2. The way it is proposed now is to > send a new SUBSCRIBE with filters 1 and 3. This is not efficient. Ah, I had a different model in mind. What I had in mind was that there is one filter installed per subscription at a time. THis filter may itself have multiple rules, but the granularity of operations are on the level of filter. You are assuming rather that multiple filters are installed at once. What does that mean? How do you reconcile them in case they conflict? > > What I was proposing was sending filter 2 id indicating that it is > deleted. Filters 1 and 3 are not sent and therefore remain on the > server. > > You propose hashing the whole body. How do I remove filter 2 in > this case? Can you explain your proposal in more detail? In the one-filter model, you would remove a filter simply by sending a re-SUBSCRIBE with no body. Thus, there is no hash needed to remove. You would use a hash to (re-)enable a filter. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Scientist 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 mailnull@www1.ietf.org Tue Jun 3 17:41:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25551 for ; Tue, 3 Jun 2003 17:41:05 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h53LeeX32505 for simple-archive@odin.ietf.org; Tue, 3 Jun 2003 17:40:40 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53LeeB32502 for ; Tue, 3 Jun 2003 17:40:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25527; Tue, 3 Jun 2003 17:40:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NJUV-00034V-00; Tue, 03 Jun 2003 17:38:47 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19NJUU-00034S-00; Tue, 03 Jun 2003 17:38:46 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53LZGB31384; Tue, 3 Jun 2003 17:35:16 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53LYtB31349 for ; Tue, 3 Jun 2003 17:34:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25360 for ; Tue, 3 Jun 2003 17:34:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NJOx-00031f-00 for simple@ietf.org; Tue, 03 Jun 2003 17:33:03 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19NJOv-00031M-00 for simple@ietf.org; Tue, 03 Jun 2003 17:33:01 -0400 Received: from dynamicsoft.com ([63.113.46.71]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h53LXdZE007940; Tue, 3 Jun 2003 17:33:41 -0400 (EDT) Message-ID: <3EDD142C.9030306@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: AndrewAllen007@aol.com, simple@ietf.org Subject: Re: placing filters in refreshes, was: Re: [Simple] RE: Comments on draft-khartabil-simple-filter-funct-00 References: <2038BCC78B1AD641891A0D1AE133DBB701796D03@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701796D03@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 03 Jun 2003 17:33:32 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit inline. hisham.khartabil@nokia.com wrote: > The body of a SUBSCRIBE may have many filters: > > eg: > > SUBSCRIBE ... content-type: application/simple-filter+xml > > filter id=1 > > filter id=2 > > filter id=3 > > Now, I want to remove filter 2. The way it is proposed now is to > send a new SUBSCRIBE with filters 1 and 3. This is not efficient. Ah, I had a different model in mind. What I had in mind was that there is one filter installed per subscription at a time. THis filter may itself have multiple rules, but the granularity of operations are on the level of filter. You are assuming rather that multiple filters are installed at once. What does that mean? How do you reconcile them in case they conflict? > > What I was proposing was sending filter 2 id indicating that it is > deleted. Filters 1 and 3 are not sent and therefore remain on the > server. > > You propose hashing the whole body. How do I remove filter 2 in > this case? Can you explain your proposal in more detail? In the one-filter model, you would remove a filter simply by sending a re-SUBSCRIBE with no body. Thus, there is no hash needed to remove. You would use a hash to (re-)enable a filter. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Scientist 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 Jun 3 18:51:27 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 SAA28770; Tue, 3 Jun 2003 18:51:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NKb7-0003cn-00; Tue, 03 Jun 2003 18:49:41 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19NKb6-0003ck-00; Tue, 03 Jun 2003 18:49:40 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53MkDB04374; Tue, 3 Jun 2003 18:46:13 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53MjdB04359 for ; Tue, 3 Jun 2003 18:45:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28628 for ; Tue, 3 Jun 2003 18:45:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NKVN-0003bc-00 for simple@ietf.org; Tue, 03 Jun 2003 18:43:46 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by ietf-mx with esmtp (Exim 4.12) id 19NKVN-0003bZ-00 for simple@ietf.org; Tue, 03 Jun 2003 18:43:45 -0400 Received: from cannon.cisco.com (IDENT:mirapoint@cannon.cisco.com [161.44.118.24]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h53Mhf51011297; Tue, 3 Jun 2003 18:43:41 -0400 (EDT) Received: from cisco.com ([161.44.79.220]) by cannon.cisco.com (Mirapoint) with ESMTP id ABK26750; Tue, 3 Jun 2003 18:52:35 -0400 (EDT) Message-ID: <3EDD249C.2070509@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Campbell CC: Simple WG Subject: Re: [Simple] MSRP: Connection Issue and proposal References: <1054575797.1975.49.camel@verite.localdomain> 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, 03 Jun 2003 18:43:40 -0400 Content-Transfer-Encoding: 7bit I think option 2 sounds pretty reasonable with some provisos: - 10 seconds can be an eternity in some call flows, especially if you are sending a reinvite that attempts to add IM as a new media stream to an existing call. Often call flows must assume reinvites will complete immediately. - maybe there is a way to control the timeout. Perhaps the Expires header on the INVITE might set an upper limit on the time to wait. Paul Ben Campbell wrote: > The last issue we discussed on MSRP in Ottowa concerned the connection > setup mechanism. The background is, when an MSRP endpoint receives an > offer containing "both", it does not immediately try to both host and > visit, like comedia endpoints do. Rather, it first attempts to act as a > visitor, then if that fails, it SHOULD attempt to host. This means that > an SDP _answer_ will _never_ contain a direction attribute of "both". > > It was mentioned in the meeting that it can take some time for the > connection attempt to timeout. In the situation where the answerer > cannot open a connection to the host, it could conceivably take a small > number of minutes before it falls back to act as a host. This would not > be a very good user experience. > > A second issue that Jonathan brought up is forking. If an INVITE forks, > you could end up with multiple visitors legitimately trying to connect > to the host. The current draft only allows one connection for any given > session. The first visit will always win, and any others will be > rejected. We could allow multiple connections to be associated with the > session, but that would add a great deal of complexity and additional > security concerns. > > One idea (hereby designated as option 1) that was mentioned to me is > that we could solve both of these issues by simply changing the process > so that the visitor always hosts. However, this greatly reduces the > flexibility dealing with firewall issues, and would probably greatly > reduce the chance for any two endpoints to be able to talk. > > Another option (hereby designated option 2) is twofold: > > a) Follow the existing process for the answerer when it receives an > offer containg "both", with an additional statement that the answerer > SHOULD time-out the connection attempt after some fairly small > value--say 10 seconds. > > b) Keep the current behavior when a fork occurs. The first connection > wins. Any subsequent connections will get an error response as > documented in the draft. Answerers that receive that response MUST fail > the offer. Adam pointed out that doing anything else is not particularly > useful, because any proxy that forks the request will probably CANCEL > any outstanding transactions after receiving the first 200 response, so > there is no way to reliably use the forking mechanism to set up multiple > session connections anyway. > > I propose we go with option 2, as it gives us the most flexibility > without adding a great deal of complexity. > > Thoughts? > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Tue Jun 3 18:51:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28810 for ; Tue, 3 Jun 2003 18:51:58 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h53MpZj04532 for simple-archive@odin.ietf.org; Tue, 3 Jun 2003 18:51:35 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53MpZB04529 for ; Tue, 3 Jun 2003 18:51:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28770; Tue, 3 Jun 2003 18:51:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NKb7-0003cn-00; Tue, 03 Jun 2003 18:49:41 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19NKb6-0003ck-00; Tue, 03 Jun 2003 18:49:40 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53MkDB04374; Tue, 3 Jun 2003 18:46:13 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53MjdB04359 for ; Tue, 3 Jun 2003 18:45:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28628 for ; Tue, 3 Jun 2003 18:45:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NKVN-0003bc-00 for simple@ietf.org; Tue, 03 Jun 2003 18:43:46 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by ietf-mx with esmtp (Exim 4.12) id 19NKVN-0003bZ-00 for simple@ietf.org; Tue, 03 Jun 2003 18:43:45 -0400 Received: from cannon.cisco.com (IDENT:mirapoint@cannon.cisco.com [161.44.118.24]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h53Mhf51011297; Tue, 3 Jun 2003 18:43:41 -0400 (EDT) Received: from cisco.com ([161.44.79.220]) by cannon.cisco.com (Mirapoint) with ESMTP id ABK26750; Tue, 3 Jun 2003 18:52:35 -0400 (EDT) Message-ID: <3EDD249C.2070509@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Campbell CC: Simple WG Subject: Re: [Simple] MSRP: Connection Issue and proposal References: <1054575797.1975.49.camel@verite.localdomain> 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, 03 Jun 2003 18:43:40 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I think option 2 sounds pretty reasonable with some provisos: - 10 seconds can be an eternity in some call flows, especially if you are sending a reinvite that attempts to add IM as a new media stream to an existing call. Often call flows must assume reinvites will complete immediately. - maybe there is a way to control the timeout. Perhaps the Expires header on the INVITE might set an upper limit on the time to wait. Paul Ben Campbell wrote: > The last issue we discussed on MSRP in Ottowa concerned the connection > setup mechanism. The background is, when an MSRP endpoint receives an > offer containing "both", it does not immediately try to both host and > visit, like comedia endpoints do. Rather, it first attempts to act as a > visitor, then if that fails, it SHOULD attempt to host. This means that > an SDP _answer_ will _never_ contain a direction attribute of "both". > > It was mentioned in the meeting that it can take some time for the > connection attempt to timeout. In the situation where the answerer > cannot open a connection to the host, it could conceivably take a small > number of minutes before it falls back to act as a host. This would not > be a very good user experience. > > A second issue that Jonathan brought up is forking. If an INVITE forks, > you could end up with multiple visitors legitimately trying to connect > to the host. The current draft only allows one connection for any given > session. The first visit will always win, and any others will be > rejected. We could allow multiple connections to be associated with the > session, but that would add a great deal of complexity and additional > security concerns. > > One idea (hereby designated as option 1) that was mentioned to me is > that we could solve both of these issues by simply changing the process > so that the visitor always hosts. However, this greatly reduces the > flexibility dealing with firewall issues, and would probably greatly > reduce the chance for any two endpoints to be able to talk. > > Another option (hereby designated option 2) is twofold: > > a) Follow the existing process for the answerer when it receives an > offer containg "both", with an additional statement that the answerer > SHOULD time-out the connection attempt after some fairly small > value--say 10 seconds. > > b) Keep the current behavior when a fork occurs. The first connection > wins. Any subsequent connections will get an error response as > documented in the draft. Answerers that receive that response MUST fail > the offer. Adam pointed out that doing anything else is not particularly > useful, because any proxy that forks the request will probably CANCEL > any outstanding transactions after receiving the first 200 response, so > there is no way to reliably use the forking mechanism to set up multiple > session connections anyway. > > I propose we go with option 2, as it gives us the most flexibility > without adding a great deal of complexity. > > Thoughts? > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Jun 4 00:21:19 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 AAA06243; Wed, 4 Jun 2003 00:21:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NPkK-0005mE-00; Wed, 04 Jun 2003 00:19:32 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19NPkJ-0005mB-00; Wed, 04 Jun 2003 00:19:31 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h544GHB27561; Wed, 4 Jun 2003 00:16:17 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h544FfB27522 for ; Wed, 4 Jun 2003 00:15:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06203 for ; Wed, 4 Jun 2003 00:15:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NPeo-0005lN-00 for simple@ietf.org; Wed, 04 Jun 2003 00:13:50 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 19NPel-0005lK-00 for simple@ietf.org; Wed, 04 Jun 2003 00:13:47 -0400 Received: from localhost (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id h544FP5k005076; Tue, 3 Jun 2003 23:15:27 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) Subject: Re: [Simple] MSRP: Connection Issue and proposal From: Ben Campbell To: Paul Kyzivat Cc: Simple WG In-Reply-To: <3EDD249C.2070509@cisco.com> References: <1054575797.1975.49.camel@verite.localdomain> <3EDD249C.2070509@cisco.com> Content-Type: text/plain Message-Id: <1054699943.2475.4.camel@verite.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.3.92 (Preview Release) 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: 03 Jun 2003 23:12:23 -0500 Content-Transfer-Encoding: 7bit On Tue, 2003-06-03 at 17:43, Paul Kyzivat wrote: > I think option 2 sounds pretty reasonable with some provisos: > > - 10 seconds can be an eternity in some call flows, especially if you > are sending a reinvite that attempts to add IM as a new media stream to > an existing call. Often call flows must assume reinvites will complete > immediately. I did not necessarily mean for 10 seconds to be the final answer--I just tossed out a number. But keep in mind, we are talking about primarily text messaging here. 10 seconds is well withing normal conversational latency when people are typing. > > - maybe there is a way to control the timeout. Perhaps the Expires > header on the INVITE might set an upper limit on the time to wait. Interesting idea. That would not fit with the normal usage of Expires on invite, but it might make sense to add something to the sdp for this. Perhaps an additional parameter on the direction attribute? > > Paul > > Ben Campbell wrote: > > The last issue we discussed on MSRP in Ottowa concerned the connection > > setup mechanism. The background is, when an MSRP endpoint receives an > > offer containing "both", it does not immediately try to both host and > > visit, like comedia endpoints do. Rather, it first attempts to act as a > > visitor, then if that fails, it SHOULD attempt to host. This means that > > an SDP _answer_ will _never_ contain a direction attribute of "both". > > > > It was mentioned in the meeting that it can take some time for the > > connection attempt to timeout. In the situation where the answerer > > cannot open a connection to the host, it could conceivably take a small > > number of minutes before it falls back to act as a host. This would not > > be a very good user experience. > > > > A second issue that Jonathan brought up is forking. If an INVITE forks, > > you could end up with multiple visitors legitimately trying to connect > > to the host. The current draft only allows one connection for any given > > session. The first visit will always win, and any others will be > > rejected. We could allow multiple connections to be associated with the > > session, but that would add a great deal of complexity and additional > > security concerns. > > > > One idea (hereby designated as option 1) that was mentioned to me is > > that we could solve both of these issues by simply changing the process > > so that the visitor always hosts. However, this greatly reduces the > > flexibility dealing with firewall issues, and would probably greatly > > reduce the chance for any two endpoints to be able to talk. > > > > Another option (hereby designated option 2) is twofold: > > > > a) Follow the existing process for the answerer when it receives an > > offer containg "both", with an additional statement that the answerer > > SHOULD time-out the connection attempt after some fairly small > > value--say 10 seconds. > > > > b) Keep the current behavior when a fork occurs. The first connection > > wins. Any subsequent connections will get an error response as > > documented in the draft. Answerers that receive that response MUST fail > > the offer. Adam pointed out that doing anything else is not particularly > > useful, because any proxy that forks the request will probably CANCEL > > any outstanding transactions after receiving the first 200 response, so > > there is no way to reliably use the forking mechanism to set up multiple > > session connections anyway. > > > > I propose we go with option 2, as it gives us the most flexibility > > without adding a great deal of complexity. > > > > Thoughts? > > > > > > > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Wed Jun 4 00:21:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06281 for ; Wed, 4 Jun 2003 00:21:50 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h544LOW27715 for simple-archive@odin.ietf.org; Wed, 4 Jun 2003 00:21:24 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h544LOB27712 for ; Wed, 4 Jun 2003 00:21:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06243; Wed, 4 Jun 2003 00:21:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NPkK-0005mE-00; Wed, 04 Jun 2003 00:19:32 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19NPkJ-0005mB-00; Wed, 04 Jun 2003 00:19:31 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h544GHB27561; Wed, 4 Jun 2003 00:16:17 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h544FfB27522 for ; Wed, 4 Jun 2003 00:15:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06203 for ; Wed, 4 Jun 2003 00:15:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NPeo-0005lN-00 for simple@ietf.org; Wed, 04 Jun 2003 00:13:50 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 19NPel-0005lK-00 for simple@ietf.org; Wed, 04 Jun 2003 00:13:47 -0400 Received: from localhost (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id h544FP5k005076; Tue, 3 Jun 2003 23:15:27 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) Subject: Re: [Simple] MSRP: Connection Issue and proposal From: Ben Campbell To: Paul Kyzivat Cc: Simple WG In-Reply-To: <3EDD249C.2070509@cisco.com> References: <1054575797.1975.49.camel@verite.localdomain> <3EDD249C.2070509@cisco.com> Content-Type: text/plain Message-Id: <1054699943.2475.4.camel@verite.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.3.92 (Preview Release) 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: 03 Jun 2003 23:12:23 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Tue, 2003-06-03 at 17:43, Paul Kyzivat wrote: > I think option 2 sounds pretty reasonable with some provisos: > > - 10 seconds can be an eternity in some call flows, especially if you > are sending a reinvite that attempts to add IM as a new media stream to > an existing call. Often call flows must assume reinvites will complete > immediately. I did not necessarily mean for 10 seconds to be the final answer--I just tossed out a number. But keep in mind, we are talking about primarily text messaging here. 10 seconds is well withing normal conversational latency when people are typing. > > - maybe there is a way to control the timeout. Perhaps the Expires > header on the INVITE might set an upper limit on the time to wait. Interesting idea. That would not fit with the normal usage of Expires on invite, but it might make sense to add something to the sdp for this. Perhaps an additional parameter on the direction attribute? > > Paul > > Ben Campbell wrote: > > The last issue we discussed on MSRP in Ottowa concerned the connection > > setup mechanism. The background is, when an MSRP endpoint receives an > > offer containing "both", it does not immediately try to both host and > > visit, like comedia endpoints do. Rather, it first attempts to act as a > > visitor, then if that fails, it SHOULD attempt to host. This means that > > an SDP _answer_ will _never_ contain a direction attribute of "both". > > > > It was mentioned in the meeting that it can take some time for the > > connection attempt to timeout. In the situation where the answerer > > cannot open a connection to the host, it could conceivably take a small > > number of minutes before it falls back to act as a host. This would not > > be a very good user experience. > > > > A second issue that Jonathan brought up is forking. If an INVITE forks, > > you could end up with multiple visitors legitimately trying to connect > > to the host. The current draft only allows one connection for any given > > session. The first visit will always win, and any others will be > > rejected. We could allow multiple connections to be associated with the > > session, but that would add a great deal of complexity and additional > > security concerns. > > > > One idea (hereby designated as option 1) that was mentioned to me is > > that we could solve both of these issues by simply changing the process > > so that the visitor always hosts. However, this greatly reduces the > > flexibility dealing with firewall issues, and would probably greatly > > reduce the chance for any two endpoints to be able to talk. > > > > Another option (hereby designated option 2) is twofold: > > > > a) Follow the existing process for the answerer when it receives an > > offer containg "both", with an additional statement that the answerer > > SHOULD time-out the connection attempt after some fairly small > > value--say 10 seconds. > > > > b) Keep the current behavior when a fork occurs. The first connection > > wins. Any subsequent connections will get an error response as > > documented in the draft. Answerers that receive that response MUST fail > > the offer. Adam pointed out that doing anything else is not particularly > > useful, because any proxy that forks the request will probably CANCEL > > any outstanding transactions after receiving the first 200 response, so > > there is no way to reliably use the forking mechanism to set up multiple > > session connections anyway. > > > > I propose we go with option 2, as it gives us the most flexibility > > without adding a great deal of complexity. > > > > Thoughts? > > > > > > > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Jun 4 04:37:35 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 EAA07948; Wed, 4 Jun 2003 04:37:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NTkJ-0007ZP-00; Wed, 04 Jun 2003 04:35:47 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19NTkI-0007ZM-00; Wed, 04 Jun 2003 04:35:46 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h548WJB24819; Wed, 4 Jun 2003 04:32:19 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h548VKB24773 for ; Wed, 4 Jun 2003 04:31: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 EAA07860 for ; Wed, 4 Jun 2003 04:31:16 -0400 (EDT) From: AndrewAllen007@aol.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NTeC-0007XL-00 for simple@ietf.org; Wed, 04 Jun 2003 04:29:28 -0400 Received: from imo-m02.mx.aol.com ([64.12.136.5]) by ietf-mx with esmtp (Exim 4.12) id 19NTeB-0007XI-00 for simple@ietf.org; Wed, 04 Jun 2003 04:29:27 -0400 Received: from AndrewAllen007@aol.com by imo-m02.mx.aol.com (mail_out_v36.3.) id r.ba.3ff38dd5 (15874); Wed, 4 Jun 2003 04:29:36 -0400 (EDT) Received: from aol.com (mow-m14.webmail.aol.com [64.12.180.130]) by air-id07.mx.aol.com (v93.12) with ESMTP id MAILINID71-3e023eddadef97; Wed, 04 Jun 2003 04:29:36 -0400 To: jdrosen@dynamicsoft.com, hisham.khartabil@nokia.com, simple@ietf.org Cc: AndrewAllen007@aol.com Subject: Re: placing filters in refreshes, was: Re: [Simple] RE: Comments on draft-khartabil-simple-filter-funct-00 MIME-Version: 1.0 Message-ID: <5A5B95CF.3BA8A044.2E6F5200@aol.com> X-Mailer: Atlas Mailer 2.0 Content-Type: text/plain; charset=utf-8 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, 04 Jun 2003 04:29:35 -0400 X-MIME-Autoconverted: from 8bit to quoted-printable by www1.ietf.org id h548WJB24819 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA07948 Hisham, Jonathan, My assumption was the same as that of Hisham. My thoughts were that there would not be a conflict problem as the result of multiple filters on the same document would effectively be combined together to form the output document. We just need to be careful that we don't produce duplicate tuples in the output. In order to reliably modify, add and delete filters we need to ensure that we can detect and recover from situations when the client and the server get out of sync with what is the current version of the filter document. We either can use some document version numbering scheme or we can use the Hash scheme as Jonathan suggested for this. One advantage as I see of the hash is that it might be easier to use this to efficiently enable the client to select from a set of different baseline filter documents, (e.g the “at work” filters, the “at home” filters, etc) by using hashes of different versions that are stored on the server. I suggest that we use an empty ev-filter element for deletion. If the ev-filter element contains a valid id attribute already present in the filter document referenced by the hash and does not contain a What or Trigger element then this filter is removed from the filter document. If the ev-filter with a valid id attribute contains what and/or trigger elements then this indicates that the filter is to be modified to these new settings. If the ev-filter id attribute is new then this filter is added to the filter document. TO DELETE: TO ADD OR MODIFY: //*[rpids:label="im" or rpids:label="sms" or rpids:label="mms"]/descendant-or-self::* | //*[rpids:label="im" or rpids:label="sms" or rpids:label="mms"]/ancestor::* A new hash would be calculated for the current state of the filter document. Andrew _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Wed Jun 4 04:38:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07987 for ; Wed, 4 Jun 2003 04:38:06 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h548be125853 for simple-archive@odin.ietf.org; Wed, 4 Jun 2003 04:37:40 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h548beB25850 for ; Wed, 4 Jun 2003 04:37:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07948; Wed, 4 Jun 2003 04:37:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NTkJ-0007ZP-00; Wed, 04 Jun 2003 04:35:47 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19NTkI-0007ZM-00; Wed, 04 Jun 2003 04:35:46 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h548WJB24819; Wed, 4 Jun 2003 04:32:19 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h548VKB24773 for ; Wed, 4 Jun 2003 04:31: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 EAA07860 for ; Wed, 4 Jun 2003 04:31:16 -0400 (EDT) From: AndrewAllen007@aol.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NTeC-0007XL-00 for simple@ietf.org; Wed, 04 Jun 2003 04:29:28 -0400 Received: from imo-m02.mx.aol.com ([64.12.136.5]) by ietf-mx with esmtp (Exim 4.12) id 19NTeB-0007XI-00 for simple@ietf.org; Wed, 04 Jun 2003 04:29:27 -0400 Received: from AndrewAllen007@aol.com by imo-m02.mx.aol.com (mail_out_v36.3.) id r.ba.3ff38dd5 (15874); Wed, 4 Jun 2003 04:29:36 -0400 (EDT) Received: from aol.com (mow-m14.webmail.aol.com [64.12.180.130]) by air-id07.mx.aol.com (v93.12) with ESMTP id MAILINID71-3e023eddadef97; Wed, 04 Jun 2003 04:29:36 -0400 To: jdrosen@dynamicsoft.com, hisham.khartabil@nokia.com, simple@ietf.org Cc: AndrewAllen007@aol.com Subject: Re: placing filters in refreshes, was: Re: [Simple] RE: Comments on draft-khartabil-simple-filter-funct-00 MIME-Version: 1.0 Message-ID: <5A5B95CF.3BA8A044.2E6F5200@aol.com> X-Mailer: Atlas Mailer 2.0 Content-Type: text/plain; charset=utf-8 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, 04 Jun 2003 04:29:35 -0400 X-MIME-Autoconverted: from 8bit to quoted-printable by www1.ietf.org id h548WJB24819 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h548beB25850 Content-Transfer-Encoding: 8bit Hisham, Jonathan, My assumption was the same as that of Hisham. My thoughts were that there would not be a conflict problem as the result of multiple filters on the same document would effectively be combined together to form the output document. We just need to be careful that we don't produce duplicate tuples in the output. In order to reliably modify, add and delete filters we need to ensure that we can detect and recover from situations when the client and the server get out of sync with what is the current version of the filter document. We either can use some document version numbering scheme or we can use the Hash scheme as Jonathan suggested for this. One advantage as I see of the hash is that it might be easier to use this to efficiently enable the client to select from a set of different baseline filter documents, (e.g the “at work” filters, the “at home” filters, etc) by using hashes of different versions that are stored on the server. I suggest that we use an empty ev-filter element for deletion. If the ev-filter element contains a valid id attribute already present in the filter document referenced by the hash and does not contain a What or Trigger element then this filter is removed from the filter document. If the ev-filter with a valid id attribute contains what and/or trigger elements then this indicates that the filter is to be modified to these new settings. If the ev-filter id attribute is new then this filter is added to the filter document. TO DELETE: TO ADD OR MODIFY: //*[rpids:label="im" or rpids:label="sms" or rpids:label="mms"]/descendant-or-self::* | //*[rpids:label="im" or rpids:label="sms" or rpids:label="mms"]/ancestor::* A new hash would be calculated for the current state of the filter document. Andrew _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Jun 4 09:35:37 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 JAA18786; Wed, 4 Jun 2003 09:35:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NYOj-0002h2-00; Wed, 04 Jun 2003 09:33:49 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19NYOi-0002gz-00; Wed, 04 Jun 2003 09:33:48 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h54DUNB15180; Wed, 4 Jun 2003 09:30:23 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h54DT7B15124 for ; Wed, 4 Jun 2003 09:29: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 JAA18529 for ; Wed, 4 Jun 2003 09:29:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NYIL-0002en-00 for simple@ietf.org; Wed, 04 Jun 2003 09:27:13 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by ietf-mx with esmtp (Exim 4.12) id 19NYIK-0002dq-00 for simple@ietf.org; Wed, 04 Jun 2003 09:27:12 -0400 Received: from cannon.cisco.com (IDENT:mirapoint@cannon.cisco.com [161.44.118.24]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h54DSN53024382; Wed, 4 Jun 2003 09:28:25 -0400 (EDT) Received: from cisco.com ([161.44.79.220]) by cannon.cisco.com (Mirapoint) with ESMTP id ABK29314; Wed, 4 Jun 2003 09:37:18 -0400 (EDT) Message-ID: <3EDDF3F6.8060504@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Campbell CC: Simple WG Subject: Re: [Simple] MSRP: Connection Issue and proposal References: <1054575797.1975.49.camel@verite.localdomain> <3EDD249C.2070509@cisco.com> <1054699943.2475.4.camel@verite.localdomain> 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, 04 Jun 2003 09:28:22 -0400 Content-Transfer-Encoding: 7bit Ben Campbell wrote: > On Tue, 2003-06-03 at 17:43, Paul Kyzivat wrote: > >>I think option 2 sounds pretty reasonable with some provisos: >> >>- 10 seconds can be an eternity in some call flows, especially if you >>are sending a reinvite that attempts to add IM as a new media stream to >>an existing call. Often call flows must assume reinvites will complete >>immediately. > > > I did not necessarily mean for 10 seconds to be the final answer--I just > tossed out a number. But keep in mind, we are talking about primarily > text messaging here. 10 seconds is well withing normal conversational > latency when people are typing. I realize that. But that assumes this time is masked by conversational latency, and that it is a human that is waiting. I have in mind a case where a reinvite is sent, adding IM to a preexisting call. The question is whether it is acceptable to have a reinvite take a long time. I know there have been discussions about this, with the conclusion that reinvite should never take long human-interaction scale times. This was primarily because there are call flows using reinvite in a 3pcc environment that won't work under those circumstances - e.g. because they are spliced between a 200 OK and an ACK of another call. This is a borderline case if we are talking about 10 seconds. And in any case it may be that there should be exceptions to the rule that reinvites must be fast. I don't think this was ever formalized anywhere. >>- maybe there is a way to control the timeout. Perhaps the Expires >>header on the INVITE might set an upper limit on the time to wait. > > > Interesting idea. That would not fit with the normal usage of Expires on > invite, but it might make sense to add something to the sdp for this. > Perhaps an additional parameter on the direction attribute? Why doesn't it fit with the normal use of Expires on INVITE? Doesn't it normally mean to give up if you can't complete the call in that amount of time? Here, if you were to wait longer you would be expected to fail the call. So instead you let the call proceed by letting the other end attempt a connection. But I suppose you would have to do this a bit before the expiration time in order to give the call time to succeed the other way. Perhaps *half* the expiration time should be an upper limit on how long to wait. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Wed Jun 4 09:36:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18820 for ; Wed, 4 Jun 2003 09:36:08 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h54DZhh15366 for simple-archive@odin.ietf.org; Wed, 4 Jun 2003 09:35:43 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h54DZhB15363 for ; Wed, 4 Jun 2003 09:35: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 JAA18786; Wed, 4 Jun 2003 09:35:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NYOj-0002h2-00; Wed, 04 Jun 2003 09:33:49 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19NYOi-0002gz-00; Wed, 04 Jun 2003 09:33:48 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h54DUNB15180; Wed, 4 Jun 2003 09:30:23 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h54DT7B15124 for ; Wed, 4 Jun 2003 09:29: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 JAA18529 for ; Wed, 4 Jun 2003 09:29:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NYIL-0002en-00 for simple@ietf.org; Wed, 04 Jun 2003 09:27:13 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by ietf-mx with esmtp (Exim 4.12) id 19NYIK-0002dq-00 for simple@ietf.org; Wed, 04 Jun 2003 09:27:12 -0400 Received: from cannon.cisco.com (IDENT:mirapoint@cannon.cisco.com [161.44.118.24]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h54DSN53024382; Wed, 4 Jun 2003 09:28:25 -0400 (EDT) Received: from cisco.com ([161.44.79.220]) by cannon.cisco.com (Mirapoint) with ESMTP id ABK29314; Wed, 4 Jun 2003 09:37:18 -0400 (EDT) Message-ID: <3EDDF3F6.8060504@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Campbell CC: Simple WG Subject: Re: [Simple] MSRP: Connection Issue and proposal References: <1054575797.1975.49.camel@verite.localdomain> <3EDD249C.2070509@cisco.com> <1054699943.2475.4.camel@verite.localdomain> 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, 04 Jun 2003 09:28:22 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Ben Campbell wrote: > On Tue, 2003-06-03 at 17:43, Paul Kyzivat wrote: > >>I think option 2 sounds pretty reasonable with some provisos: >> >>- 10 seconds can be an eternity in some call flows, especially if you >>are sending a reinvite that attempts to add IM as a new media stream to >>an existing call. Often call flows must assume reinvites will complete >>immediately. > > > I did not necessarily mean for 10 seconds to be the final answer--I just > tossed out a number. But keep in mind, we are talking about primarily > text messaging here. 10 seconds is well withing normal conversational > latency when people are typing. I realize that. But that assumes this time is masked by conversational latency, and that it is a human that is waiting. I have in mind a case where a reinvite is sent, adding IM to a preexisting call. The question is whether it is acceptable to have a reinvite take a long time. I know there have been discussions about this, with the conclusion that reinvite should never take long human-interaction scale times. This was primarily because there are call flows using reinvite in a 3pcc environment that won't work under those circumstances - e.g. because they are spliced between a 200 OK and an ACK of another call. This is a borderline case if we are talking about 10 seconds. And in any case it may be that there should be exceptions to the rule that reinvites must be fast. I don't think this was ever formalized anywhere. >>- maybe there is a way to control the timeout. Perhaps the Expires >>header on the INVITE might set an upper limit on the time to wait. > > > Interesting idea. That would not fit with the normal usage of Expires on > invite, but it might make sense to add something to the sdp for this. > Perhaps an additional parameter on the direction attribute? Why doesn't it fit with the normal use of Expires on INVITE? Doesn't it normally mean to give up if you can't complete the call in that amount of time? Here, if you were to wait longer you would be expected to fail the call. So instead you let the call proceed by letting the other end attempt a connection. But I suppose you would have to do this a bit before the expiration time in order to give the call time to succeed the other way. Perhaps *half* the expiration time should be an upper limit on how long to wait. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Jun 4 09:46:17 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 JAA19161; Wed, 4 Jun 2003 09:46:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NYZ2-0002mr-00; Wed, 04 Jun 2003 09:44:28 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19NYZ2-0002mo-00; Wed, 04 Jun 2003 09:44:28 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h54Df4B16566; Wed, 4 Jun 2003 09:41:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h54DeWB16545 for ; Wed, 4 Jun 2003 09:40:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18994 for ; Wed, 4 Jun 2003 09:40:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NYTP-0002ji-00 for simple@ietf.org; Wed, 04 Jun 2003 09:38:39 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19NYTO-0002j1-00 for simple@ietf.org; Wed, 04 Jun 2003 09:38:38 -0400 Received: from dynamicsoft.com ([63.113.46.71]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h54DdvZE008214; Wed, 4 Jun 2003 09:39:58 -0400 (EDT) Message-ID: <3EDDF6A9.4000207@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, en MIME-Version: 1.0 To: AndrewAllen007@aol.com CC: hisham.khartabil@nokia.com, simple@ietf.org Subject: Re: placing filters in refreshes, was: Re: [Simple] RE: Comments on draft-khartabil-simple-filter-funct-00 References: <5A5B95CF.3BA8A044.2E6F5200@aol.com> In-Reply-To: <5A5B95CF.3BA8A044.2E6F5200@aol.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: Wed, 04 Jun 2003 09:39:53 -0400 Content-Transfer-Encoding: 7bit AndrewAllen007@aol.com wrote: > > Hisham, Jonathan, > > My assumption was the same as that of Hisham. My thoughts were that > there would not be a conflict problem as the result of multiple > filters on the same document would effectively be combined together > to form the output document. We just need to be careful that we > don't produce duplicate tuples in the output. I really dont understand the motivation behind this requirements for multiple installed filters in parallel. Why can't you view the whole combination as one big filter, and treat that as the thing which is managed (i.e., installed, refreshed, deleted)? Just trying to simplify. If you make that assumption, the whole problem becomes a lot easier. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Scientist 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 mailnull@www1.ietf.org Wed Jun 4 09:46:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19200 for ; Wed, 4 Jun 2003 09:46:48 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h54DkNp16898 for simple-archive@odin.ietf.org; Wed, 4 Jun 2003 09:46:23 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h54DkNB16895 for ; Wed, 4 Jun 2003 09:46: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 JAA19161; Wed, 4 Jun 2003 09:46:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NYZ2-0002mr-00; Wed, 04 Jun 2003 09:44:28 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19NYZ2-0002mo-00; Wed, 04 Jun 2003 09:44:28 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h54Df4B16566; Wed, 4 Jun 2003 09:41:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h54DeWB16545 for ; Wed, 4 Jun 2003 09:40:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18994 for ; Wed, 4 Jun 2003 09:40:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NYTP-0002ji-00 for simple@ietf.org; Wed, 04 Jun 2003 09:38:39 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19NYTO-0002j1-00 for simple@ietf.org; Wed, 04 Jun 2003 09:38:38 -0400 Received: from dynamicsoft.com ([63.113.46.71]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h54DdvZE008214; Wed, 4 Jun 2003 09:39:58 -0400 (EDT) Message-ID: <3EDDF6A9.4000207@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, en MIME-Version: 1.0 To: AndrewAllen007@aol.com CC: hisham.khartabil@nokia.com, simple@ietf.org Subject: Re: placing filters in refreshes, was: Re: [Simple] RE: Comments on draft-khartabil-simple-filter-funct-00 References: <5A5B95CF.3BA8A044.2E6F5200@aol.com> In-Reply-To: <5A5B95CF.3BA8A044.2E6F5200@aol.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: Wed, 04 Jun 2003 09:39:53 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit AndrewAllen007@aol.com wrote: > > Hisham, Jonathan, > > My assumption was the same as that of Hisham. My thoughts were that > there would not be a conflict problem as the result of multiple > filters on the same document would effectively be combined together > to form the output document. We just need to be careful that we > don't produce duplicate tuples in the output. I really dont understand the motivation behind this requirements for multiple installed filters in parallel. Why can't you view the whole combination as one big filter, and treat that as the thing which is managed (i.e., installed, refreshed, deleted)? Just trying to simplify. If you make that assumption, the whole problem becomes a lot easier. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Scientist 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 Jun 4 10:14:46 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 KAA21796; Wed, 4 Jun 2003 10:14:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NZ0b-0003Bf-00; Wed, 04 Jun 2003 10:12:57 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19NZ0a-0003Bc-00; Wed, 04 Jun 2003 10:12:56 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h54E9WB18914; Wed, 4 Jun 2003 10:09:32 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h54E8TB18843 for ; Wed, 4 Jun 2003 10:08: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 KAA21062 for ; Wed, 4 Jun 2003 10:08:23 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NYuQ-00037Z-00 for simple@ietf.org; Wed, 04 Jun 2003 10:06:34 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19NYuP-00037W-00 for simple@ietf.org; Wed, 04 Jun 2003 10:06:33 -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 h54E8MW17355 for ; Wed, 4 Jun 2003 17:08:22 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 4 Jun 2003 17:08:22 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 4 Jun 2003 17:08:22 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 4 Jun 2003 17:08:22 +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" Subject: RE: placing filters in refreshes, was: Re: [Simple] RE: Comments on draft-khartabil-simple-filter-funct-00 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701796D2B@esebe019.ntc.nokia.com> Thread-Topic: placing filters in refreshes, was: Re: [Simple] RE: Comments on draft-khartabil-simple-filter-funct-00 Thread-Index: AcMqnuVUG+2MIY/kRaSnmSBF1JpclwAAouFg To: , Cc: X-OriginalArrivalTime: 04 Jun 2003 14:08:22.0241 (UTC) FILETIME=[C1E25510:01C32AA2] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h54E8TB18844 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 4 Jun 2003 17:08:21 +0300 Content-Transfer-Encoding: 8bit If you send a subscription to a presence list and you want to have a separate filter for each member on that list, then you need separate filters (unless you count them as one filter with multiple rules). Even if they are multiple rules within a filter, why shouldn't it be possible to manipulate one of those rules. To answer your earlier question about reconciling them in case of conflict; I would say they don't conflict since they are destined for different resources. Regards, Hisham > -----Original Message----- > From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Wednesday, June 04, 2003 4:40 PM > To: AndrewAllen007@aol.com > Cc: Khartabil Hisham (NMP/Helsinki); simple@ietf.org > Subject: Re: placing filters in refreshes, was: Re: [Simple] RE: > Comments on draft-khartabil-simple-filter-funct-00 > > > > > AndrewAllen007@aol.com wrote: > > > > Hisham, Jonathan, > > > > My assumption was the same as that of Hisham. My thoughts were that > > there would not be a conflict problem as the result of multiple > > filters on the same document would effectively be combined together > > to form the output document. We just need to be careful that we > > don't produce duplicate tuples in the output. > > I really dont understand the motivation behind this requirements for > multiple installed filters in parallel. Why can't you view the whole > combination as one big filter, and treat that as the thing which is > managed (i.e., installed, refreshed, deleted)? Just trying to > simplify. If you make that assumption, the whole problem > becomes a lot > easier. > > -Jonathan R. > > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Scientist 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 mailnull@www1.ietf.org Wed Jun 4 10:15:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21896 for ; Wed, 4 Jun 2003 10:15:17 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h54EErL19259 for simple-archive@odin.ietf.org; Wed, 4 Jun 2003 10:14:53 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h54EEqB19256 for ; Wed, 4 Jun 2003 10:14:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21796; Wed, 4 Jun 2003 10:14:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NZ0b-0003Bf-00; Wed, 04 Jun 2003 10:12:57 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19NZ0a-0003Bc-00; Wed, 04 Jun 2003 10:12:56 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h54E9WB18914; Wed, 4 Jun 2003 10:09:32 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h54E8TB18843 for ; Wed, 4 Jun 2003 10:08: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 KAA21062 for ; Wed, 4 Jun 2003 10:08:23 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NYuQ-00037Z-00 for simple@ietf.org; Wed, 04 Jun 2003 10:06:34 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19NYuP-00037W-00 for simple@ietf.org; Wed, 04 Jun 2003 10:06:33 -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 h54E8MW17355 for ; Wed, 4 Jun 2003 17:08:22 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 4 Jun 2003 17:08:22 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 4 Jun 2003 17:08:22 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 4 Jun 2003 17:08:22 +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" Subject: RE: placing filters in refreshes, was: Re: [Simple] RE: Comments on draft-khartabil-simple-filter-funct-00 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701796D2B@esebe019.ntc.nokia.com> Thread-Topic: placing filters in refreshes, was: Re: [Simple] RE: Comments on draft-khartabil-simple-filter-funct-00 Thread-Index: AcMqnuVUG+2MIY/kRaSnmSBF1JpclwAAouFg To: , Cc: X-OriginalArrivalTime: 04 Jun 2003 14:08:22.0241 (UTC) FILETIME=[C1E25510:01C32AA2] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h54E8TB18844 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 4 Jun 2003 17:08:21 +0300 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit If you send a subscription to a presence list and you want to have a separate filter for each member on that list, then you need separate filters (unless you count them as one filter with multiple rules). Even if they are multiple rules within a filter, why shouldn't it be possible to manipulate one of those rules. To answer your earlier question about reconciling them in case of conflict; I would say they don't conflict since they are destined for different resources. Regards, Hisham > -----Original Message----- > From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Wednesday, June 04, 2003 4:40 PM > To: AndrewAllen007@aol.com > Cc: Khartabil Hisham (NMP/Helsinki); simple@ietf.org > Subject: Re: placing filters in refreshes, was: Re: [Simple] RE: > Comments on draft-khartabil-simple-filter-funct-00 > > > > > AndrewAllen007@aol.com wrote: > > > > Hisham, Jonathan, > > > > My assumption was the same as that of Hisham. My thoughts were that > > there would not be a conflict problem as the result of multiple > > filters on the same document would effectively be combined together > > to form the output document. We just need to be careful that we > > don't produce duplicate tuples in the output. > > I really dont understand the motivation behind this requirements for > multiple installed filters in parallel. Why can't you view the whole > combination as one big filter, and treat that as the thing which is > managed (i.e., installed, refreshed, deleted)? Just trying to > simplify. If you make that assumption, the whole problem > becomes a lot > easier. > > -Jonathan R. > > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Scientist 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 Jun 4 10:17:17 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 KAA22058; Wed, 4 Jun 2003 10:17:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NZ32-0003CR-00; Wed, 04 Jun 2003 10:15:28 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19NZ32-0003CO-00; Wed, 04 Jun 2003 10:15:28 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h54EC4B19126; Wed, 4 Jun 2003 10:12:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h54EADB18950 for ; Wed, 4 Jun 2003 10:10:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21232 for ; Wed, 4 Jun 2003 10:10:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NYw7-00038T-00 for simple@ietf.org; Wed, 04 Jun 2003 10:08:19 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 19NYw4-00038L-00 for simple@ietf.org; Wed, 04 Jun 2003 10:08:17 -0400 Received: from localhost (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id h54E8w5k043656; Wed, 4 Jun 2003 09:08:58 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) Subject: Re: [Simple] MSRP: Connection Issue and proposal From: Ben Campbell To: Paul Kyzivat Cc: Simple WG In-Reply-To: <3EDDF3F6.8060504@cisco.com> References: <1054575797.1975.49.camel@verite.localdomain> <3EDD249C.2070509@cisco.com> <1054699943.2475.4.camel@verite.localdomain> <3EDDF3F6.8060504@cisco.com> Content-Type: text/plain Message-Id: <1054735701.3201.4.camel@verite.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.3.92 (Preview Release) 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: 04 Jun 2003 09:08:21 -0500 Content-Transfer-Encoding: 7bit On Wed, 2003-06-04 at 08:28, Paul Kyzivat wrote: > Ben Campbell wrote: > > On Tue, 2003-06-03 at 17:43, Paul Kyzivat wrote: > > > >>I think option 2 sounds pretty reasonable with some provisos: > >> > >>- 10 seconds can be an eternity in some call flows, especially if you > >>are sending a reinvite that attempts to add IM as a new media stream to > >>an existing call. Often call flows must assume reinvites will complete > >>immediately. > > > > > > I did not necessarily mean for 10 seconds to be the final answer--I just > > tossed out a number. But keep in mind, we are talking about primarily > > text messaging here. 10 seconds is well withing normal conversational > > latency when people are typing. > > I realize that. But that assumes this time is masked by conversational > latency, and that it is a human that is waiting. I have in mind a case > where a reinvite is sent, adding IM to a preexisting call. The question > is whether it is acceptable to have a reinvite take a long time. I know > there have been discussions about this, with the conclusion that > reinvite should never take long human-interaction scale times. > > This was primarily because there are call flows using reinvite in a 3pcc > environment that won't work under those circumstances - e.g. because > they are spliced between a 200 OK and an ACK of another call. This is a > borderline case if we are talking about 10 seconds. And in any case it > may be that there should be exceptions to the rule that reinvites must > be fast. I don't think this was ever formalized anywhere. > > >>- maybe there is a way to control the timeout. Perhaps the Expires > >>header on the INVITE might set an upper limit on the time to wait. > > > > > > Interesting idea. That would not fit with the normal usage of Expires on > > invite, but it might make sense to add something to the sdp for this. > > Perhaps an additional parameter on the direction attribute? > > Why doesn't it fit with the normal use of Expires on INVITE? Doesn't it > normally mean to give up if you can't complete the call in that amount > of time? Yes, but we are not talking about giving up on the invite. We are talking about changing the mode of the call. > Here, if you were to wait longer you would be expected to fail > the call. So instead you let the call proceed by letting the other end > attempt a connection. But I suppose you would have to do this a bit > before the expiration time in order to give the call time to succeed the > other way. Perhaps *half* the expiration time should be an upper limit > on how long to wait. The other issue is, so far, the draft only depends normatively on SDP, not SIP. > > Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Wed Jun 4 10:17:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22090 for ; Wed, 4 Jun 2003 10:17:48 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h54EHOR19358 for simple-archive@odin.ietf.org; Wed, 4 Jun 2003 10:17:24 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h54EHOB19355 for ; Wed, 4 Jun 2003 10:17:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22058; Wed, 4 Jun 2003 10:17:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NZ32-0003CR-00; Wed, 04 Jun 2003 10:15:28 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19NZ32-0003CO-00; Wed, 04 Jun 2003 10:15:28 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h54EC4B19126; Wed, 4 Jun 2003 10:12:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h54EADB18950 for ; Wed, 4 Jun 2003 10:10:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21232 for ; Wed, 4 Jun 2003 10:10:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NYw7-00038T-00 for simple@ietf.org; Wed, 04 Jun 2003 10:08:19 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 19NYw4-00038L-00 for simple@ietf.org; Wed, 04 Jun 2003 10:08:17 -0400 Received: from localhost (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id h54E8w5k043656; Wed, 4 Jun 2003 09:08:58 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) Subject: Re: [Simple] MSRP: Connection Issue and proposal From: Ben Campbell To: Paul Kyzivat Cc: Simple WG In-Reply-To: <3EDDF3F6.8060504@cisco.com> References: <1054575797.1975.49.camel@verite.localdomain> <3EDD249C.2070509@cisco.com> <1054699943.2475.4.camel@verite.localdomain> <3EDDF3F6.8060504@cisco.com> Content-Type: text/plain Message-Id: <1054735701.3201.4.camel@verite.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.3.92 (Preview Release) 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: 04 Jun 2003 09:08:21 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Wed, 2003-06-04 at 08:28, Paul Kyzivat wrote: > Ben Campbell wrote: > > On Tue, 2003-06-03 at 17:43, Paul Kyzivat wrote: > > > >>I think option 2 sounds pretty reasonable with some provisos: > >> > >>- 10 seconds can be an eternity in some call flows, especially if you > >>are sending a reinvite that attempts to add IM as a new media stream to > >>an existing call. Often call flows must assume reinvites will complete > >>immediately. > > > > > > I did not necessarily mean for 10 seconds to be the final answer--I just > > tossed out a number. But keep in mind, we are talking about primarily > > text messaging here. 10 seconds is well withing normal conversational > > latency when people are typing. > > I realize that. But that assumes this time is masked by conversational > latency, and that it is a human that is waiting. I have in mind a case > where a reinvite is sent, adding IM to a preexisting call. The question > is whether it is acceptable to have a reinvite take a long time. I know > there have been discussions about this, with the conclusion that > reinvite should never take long human-interaction scale times. > > This was primarily because there are call flows using reinvite in a 3pcc > environment that won't work under those circumstances - e.g. because > they are spliced between a 200 OK and an ACK of another call. This is a > borderline case if we are talking about 10 seconds. And in any case it > may be that there should be exceptions to the rule that reinvites must > be fast. I don't think this was ever formalized anywhere. > > >>- maybe there is a way to control the timeout. Perhaps the Expires > >>header on the INVITE might set an upper limit on the time to wait. > > > > > > Interesting idea. That would not fit with the normal usage of Expires on > > invite, but it might make sense to add something to the sdp for this. > > Perhaps an additional parameter on the direction attribute? > > Why doesn't it fit with the normal use of Expires on INVITE? Doesn't it > normally mean to give up if you can't complete the call in that amount > of time? Yes, but we are not talking about giving up on the invite. We are talking about changing the mode of the call. > Here, if you were to wait longer you would be expected to fail > the call. So instead you let the call proceed by letting the other end > attempt a connection. But I suppose you would have to do this a bit > before the expiration time in order to give the call time to succeed the > other way. Perhaps *half* the expiration time should be an upper limit > on how long to wait. The other issue is, so far, the draft only depends normatively on SDP, not SIP. > > Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Jun 4 18:14:33 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 SAA15749; Wed, 4 Jun 2003 18:14:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NgUu-0000tv-00; Wed, 04 Jun 2003 18:12:45 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19NgUu-0000tq-00; Wed, 04 Jun 2003 18:12:44 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h54M9QB25655; Wed, 4 Jun 2003 18:09:26 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h54M8oB25637 for ; Wed, 4 Jun 2003 18:08:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15232 for ; Wed, 4 Jun 2003 18:08:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NgPH-0000sO-00 for simple@ietf.org; Wed, 04 Jun 2003 18:06:55 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by ietf-mx with esmtp (Exim 4.12) id 19NgPG-0000rx-00 for simple@ietf.org; Wed, 04 Jun 2003 18:06:54 -0400 Received: from cannon.cisco.com (IDENT:mirapoint@cannon.cisco.com [161.44.118.24]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h54M6q51003254; Wed, 4 Jun 2003 18:06:53 -0400 (EDT) Received: from cisco.com ([161.44.79.220]) by cannon.cisco.com (Mirapoint) with ESMTP id ABK34871; Wed, 4 Jun 2003 18:15:47 -0400 (EDT) Message-ID: <3EDE6D7C.7020607@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Campbell CC: Simple WG Subject: Re: [Simple] MSRP: Connection Issue and proposal References: <1054575797.1975.49.camel@verite.localdomain> <3EDD249C.2070509@cisco.com> <1054699943.2475.4.camel@verite.localdomain> <3EDDF3F6.8060504@cisco.com> <1054735701.3201.4.camel@verite.localdomain> 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, 04 Jun 2003 18:06:52 -0400 Content-Transfer-Encoding: 7bit Ben Campbell wrote: > >>>Interesting idea. That would not fit with the normal usage of Expires on >>>invite, but it might make sense to add something to the sdp for this. >>>Perhaps an additional parameter on the direction attribute? >> >>Why doesn't it fit with the normal use of Expires on INVITE? Doesn't it >>normally mean to give up if you can't complete the call in that amount >>of time? > > > Yes, but we are not talking about giving up on the invite. We are > talking about changing the mode of the call. If you wait longer than the expiration time on the invite, then the invite will fail. So it makes sense to stop waiting before then if there is then a way that the call can succeed. There are actually two ways the call can succeed: - simply give up on this medium - refuse the m-line but accept the invite. - return an answer with direction:both and let the other side try to connect. >>Here, if you were to wait longer you would be expected to fail >>the call. So instead you let the call proceed by letting the other end >>attempt a connection. But I suppose you would have to do this a bit >>before the expiration time in order to give the call time to succeed the >>other way. Perhaps *half* the expiration time should be an upper limit >>on how long to wait. > > > The other issue is, so far, the draft only depends normatively on SDP, > not SIP. Isn't it also dependent on 3264 (offer/answer)? In any case, this more or less convinces me. Your suggestion of an SDP parameter is attractive here. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Wed Jun 4 18:15:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15815 for ; Wed, 4 Jun 2003 18:15:04 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h54MEfn25805 for simple-archive@odin.ietf.org; Wed, 4 Jun 2003 18:14:41 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h54MEeB25802 for ; Wed, 4 Jun 2003 18:14: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 SAA15749; Wed, 4 Jun 2003 18:14:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NgUu-0000tv-00; Wed, 04 Jun 2003 18:12:45 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19NgUu-0000tq-00; Wed, 04 Jun 2003 18:12:44 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h54M9QB25655; Wed, 4 Jun 2003 18:09:26 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h54M8oB25637 for ; Wed, 4 Jun 2003 18:08:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15232 for ; Wed, 4 Jun 2003 18:08:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NgPH-0000sO-00 for simple@ietf.org; Wed, 04 Jun 2003 18:06:55 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by ietf-mx with esmtp (Exim 4.12) id 19NgPG-0000rx-00 for simple@ietf.org; Wed, 04 Jun 2003 18:06:54 -0400 Received: from cannon.cisco.com (IDENT:mirapoint@cannon.cisco.com [161.44.118.24]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h54M6q51003254; Wed, 4 Jun 2003 18:06:53 -0400 (EDT) Received: from cisco.com ([161.44.79.220]) by cannon.cisco.com (Mirapoint) with ESMTP id ABK34871; Wed, 4 Jun 2003 18:15:47 -0400 (EDT) Message-ID: <3EDE6D7C.7020607@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Campbell CC: Simple WG Subject: Re: [Simple] MSRP: Connection Issue and proposal References: <1054575797.1975.49.camel@verite.localdomain> <3EDD249C.2070509@cisco.com> <1054699943.2475.4.camel@verite.localdomain> <3EDDF3F6.8060504@cisco.com> <1054735701.3201.4.camel@verite.localdomain> 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, 04 Jun 2003 18:06:52 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Ben Campbell wrote: > >>>Interesting idea. That would not fit with the normal usage of Expires on >>>invite, but it might make sense to add something to the sdp for this. >>>Perhaps an additional parameter on the direction attribute? >> >>Why doesn't it fit with the normal use of Expires on INVITE? Doesn't it >>normally mean to give up if you can't complete the call in that amount >>of time? > > > Yes, but we are not talking about giving up on the invite. We are > talking about changing the mode of the call. If you wait longer than the expiration time on the invite, then the invite will fail. So it makes sense to stop waiting before then if there is then a way that the call can succeed. There are actually two ways the call can succeed: - simply give up on this medium - refuse the m-line but accept the invite. - return an answer with direction:both and let the other side try to connect. >>Here, if you were to wait longer you would be expected to fail >>the call. So instead you let the call proceed by letting the other end >>attempt a connection. But I suppose you would have to do this a bit >>before the expiration time in order to give the call time to succeed the >>other way. Perhaps *half* the expiration time should be an upper limit >>on how long to wait. > > > The other issue is, so far, the draft only depends normatively on SDP, > not SIP. Isn't it also dependent on 3264 (offer/answer)? In any case, this more or less convinces me. Your suggestion of an SDP parameter is attractive here. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Jun 5 06:27:31 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 GAA14042; Thu, 5 Jun 2003 06:27:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NrwD-0004mS-00; Thu, 05 Jun 2003 06:25:41 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19NrwC-0004mP-00; Thu, 05 Jun 2003 06:25:40 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55AMHB20954; Thu, 5 Jun 2003 06:22:17 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55ALuB20925 for ; Thu, 5 Jun 2003 06:21: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 GAA13880 for ; Thu, 5 Jun 2003 06:21:50 -0400 (EDT) From: AndrewAllen007@aol.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Nrqi-0004kS-00 for simple@ietf.org; Thu, 05 Jun 2003 06:20:00 -0400 Received: from imo-m08.mx.aol.com ([64.12.136.163]) by ietf-mx with esmtp (Exim 4.12) id 19Nrqh-0004kO-00 for simple@ietf.org; Thu, 05 Jun 2003 06:19:59 -0400 Received: from AndrewAllen007@aol.com by imo-m08.mx.aol.com (mail_out_v36.3.) id p.1ec.a318fb9 (15898); Thu, 5 Jun 2003 06:21:00 -0400 (EDT) Received: from aol.com (mow-d14.webmail.aol.com [205.188.139.130]) by air-id09.mx.aol.com (v93.12) with ESMTP id MAILINID91-3e1a3edf198cdd; Thu, 05 Jun 2003 06:21:00 -0400 To: hisham.khartabil@nokia.com, jdrosen@dynamicsoft.com, simple@ietf.org Cc: AndrewAllen007@aol.com Subject: Re: placing filters in refreshes, was: Re: [Simple] RE: Comments on draft-khartabil-simple-filter-funct-00 MIME-Version: 1.0 Message-ID: <2B5E85BC.227D42F6.2E6F5200@aol.com> X-Mailer: Atlas Mailer 2.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit 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, 05 Jun 2003 06:21:00 -0400 Content-Transfer-Encoding: 8bit Hisham, Jonathan, In addition I am thinking that multiple applications may share the presence subscription and filters. For instance a messenger app and a chess game app. It seems simpler for the presence app in the client to simply combine seperate filters as seperate XML elements into one filter document than to try to produce a single XPATH filter expression from multiple input sources. Andrew _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu Jun 5 06:28:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14062 for ; Thu, 5 Jun 2003 06:28:02 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h55ARcD21169 for simple-archive@odin.ietf.org; Thu, 5 Jun 2003 06:27:38 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55ARcB21166 for ; Thu, 5 Jun 2003 06:27: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 GAA14042; Thu, 5 Jun 2003 06:27:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NrwD-0004mS-00; Thu, 05 Jun 2003 06:25:41 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19NrwC-0004mP-00; Thu, 05 Jun 2003 06:25:40 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55AMHB20954; Thu, 5 Jun 2003 06:22:17 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55ALuB20925 for ; Thu, 5 Jun 2003 06:21: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 GAA13880 for ; Thu, 5 Jun 2003 06:21:50 -0400 (EDT) From: AndrewAllen007@aol.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Nrqi-0004kS-00 for simple@ietf.org; Thu, 05 Jun 2003 06:20:00 -0400 Received: from imo-m08.mx.aol.com ([64.12.136.163]) by ietf-mx with esmtp (Exim 4.12) id 19Nrqh-0004kO-00 for simple@ietf.org; Thu, 05 Jun 2003 06:19:59 -0400 Received: from AndrewAllen007@aol.com by imo-m08.mx.aol.com (mail_out_v36.3.) id p.1ec.a318fb9 (15898); Thu, 5 Jun 2003 06:21:00 -0400 (EDT) Received: from aol.com (mow-d14.webmail.aol.com [205.188.139.130]) by air-id09.mx.aol.com (v93.12) with ESMTP id MAILINID91-3e1a3edf198cdd; Thu, 05 Jun 2003 06:21:00 -0400 To: hisham.khartabil@nokia.com, jdrosen@dynamicsoft.com, simple@ietf.org Cc: AndrewAllen007@aol.com Subject: Re: placing filters in refreshes, was: Re: [Simple] RE: Comments on draft-khartabil-simple-filter-funct-00 MIME-Version: 1.0 Message-ID: <2B5E85BC.227D42F6.2E6F5200@aol.com> X-Mailer: Atlas Mailer 2.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit 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, 05 Jun 2003 06:21:00 -0400 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hisham, Jonathan, In addition I am thinking that multiple applications may share the presence subscription and filters. For instance a messenger app and a chess game app. It seems simpler for the presence app in the client to simply combine seperate filters as seperate XML elements into one filter document than to try to produce a single XPATH filter expression from multiple input sources. Andrew _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Jun 5 11:18:31 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 LAA01483; Thu, 5 Jun 2003 11:18:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NwTn-0000Bv-00; Thu, 05 Jun 2003 11:16:39 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19NwTn-0000Bq-00; Thu, 05 Jun 2003 11:16:39 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55FF8B13144; Thu, 5 Jun 2003 11:15:08 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55FEZB13085 for ; Thu, 5 Jun 2003 11:14: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 LAA00934 for ; Thu, 5 Jun 2003 11:14:34 -0400 (EDT) From: aki.niemi@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NwPy-00006K-00 for simple@ietf.org; Thu, 05 Jun 2003 11:12:42 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19NwPy-000060-00 for simple@ietf.org; Thu, 05 Jun 2003 11:12:42 -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 h55FDZW16645 for ; Thu, 5 Jun 2003 18:13:35 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 5 Jun 2003 18:13:34 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 5 Jun 2003 18:13:34 +0300 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 5 Jun 2003 18:13:34 +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" Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9019452AF@esebe013.ntc.nokia.com> Thread-Topic: PUBLISH: versioning of published information Thread-Index: AcMrdQdXvcgYHMI8R++RNkVGkcpO8g== To: X-OriginalArrivalTime: 05 Jun 2003 15:13:34.0061 (UTC) FILETIME=[07EC71D0:01C32B75] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h55FEZB13086 Subject: [Simple] PUBLISH: versioning of published 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: Thu, 5 Jun 2003 18:13:33 +0300 Content-Transfer-Encoding: 8bit Hi All, In the SIMPLE interim we discussed the issue of versioning of published information (among other things - other issues will be posted on separate emails). There were proposals at the meeting, and we've also had a suggestion on the list since then. I'll try to summarize the issue and the proposals made this far. The current PUBLISH draft uses information contained in the body of a publication, namely timestamps in individual tuples to version the published tuples. This doesn't work without global clock sync between the EPAs, and so we need something else. Proposal 1: Have the server return a timestamp in the response of a PUBLISH, and have the client use that timestamp with the HTTP/1.1 style preconditions "If-Unmodified-Since" to detect if someone else has modified the published tuple(s). Attempt to PUBLISH a "stale" tuple would result in a 412 Preconditions Failed error response. An automata refreshing a publication would never override in such a case, but some type of human intervention would be required to do a fresh PUBLISH, i.e., a publication without the preconditions. Proposal 2: Since there is theoretically a 1 second time window for two publications to collide due to the resolution of the Date header time, it was suggested that we should instead use a counter. Each fresh publication of the tuple would return an incremented value, which the client would use in each refresh publication. Proposal 3: Basically identical to the previous proposal except that instead of a counter value, the server would return an opaque token, much like the Set-Cookie, Cookie headers in HTTP. Proposal 4: It was suggested that HTTP/1.1 style entity-tags would be used to identify a specific instance or version of a tuple. The value received from a server in an "ETag" header would be used by the client with an HTTP/1.1 style request precondition of "If-Match". Failure to match the entity tag would fail the request with a 412 response like in Proposal 1. Personally, I like Proposal 4, because it accomplishes exactly what we want without the (theoretical) problem with the 1 second resolution in Date values. Comments? Cheers, Aki _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu Jun 5 11:19:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01777 for ; Thu, 5 Jun 2003 11:19:03 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h55FIYH13306 for simple-archive@odin.ietf.org; Thu, 5 Jun 2003 11:18:34 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55FIYB13302 for ; Thu, 5 Jun 2003 11:18:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01483; Thu, 5 Jun 2003 11:18:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NwTn-0000Bv-00; Thu, 05 Jun 2003 11:16:39 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19NwTn-0000Bq-00; Thu, 05 Jun 2003 11:16:39 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55FF8B13144; Thu, 5 Jun 2003 11:15:08 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55FEZB13085 for ; Thu, 5 Jun 2003 11:14: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 LAA00934 for ; Thu, 5 Jun 2003 11:14:34 -0400 (EDT) From: aki.niemi@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NwPy-00006K-00 for simple@ietf.org; Thu, 05 Jun 2003 11:12:42 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19NwPy-000060-00 for simple@ietf.org; Thu, 05 Jun 2003 11:12:42 -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 h55FDZW16645 for ; Thu, 5 Jun 2003 18:13:35 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 5 Jun 2003 18:13:34 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 5 Jun 2003 18:13:34 +0300 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 5 Jun 2003 18:13:34 +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" Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9019452AF@esebe013.ntc.nokia.com> Thread-Topic: PUBLISH: versioning of published information Thread-Index: AcMrdQdXvcgYHMI8R++RNkVGkcpO8g== To: X-OriginalArrivalTime: 05 Jun 2003 15:13:34.0061 (UTC) FILETIME=[07EC71D0:01C32B75] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h55FEZB13086 Subject: [Simple] PUBLISH: versioning of published 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: Thu, 5 Jun 2003 18:13:33 +0300 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi All, In the SIMPLE interim we discussed the issue of versioning of published information (among other things - other issues will be posted on separate emails). There were proposals at the meeting, and we've also had a suggestion on the list since then. I'll try to summarize the issue and the proposals made this far. The current PUBLISH draft uses information contained in the body of a publication, namely timestamps in individual tuples to version the published tuples. This doesn't work without global clock sync between the EPAs, and so we need something else. Proposal 1: Have the server return a timestamp in the response of a PUBLISH, and have the client use that timestamp with the HTTP/1.1 style preconditions "If-Unmodified-Since" to detect if someone else has modified the published tuple(s). Attempt to PUBLISH a "stale" tuple would result in a 412 Preconditions Failed error response. An automata refreshing a publication would never override in such a case, but some type of human intervention would be required to do a fresh PUBLISH, i.e., a publication without the preconditions. Proposal 2: Since there is theoretically a 1 second time window for two publications to collide due to the resolution of the Date header time, it was suggested that we should instead use a counter. Each fresh publication of the tuple would return an incremented value, which the client would use in each refresh publication. Proposal 3: Basically identical to the previous proposal except that instead of a counter value, the server would return an opaque token, much like the Set-Cookie, Cookie headers in HTTP. Proposal 4: It was suggested that HTTP/1.1 style entity-tags would be used to identify a specific instance or version of a tuple. The value received from a server in an "ETag" header would be used by the client with an HTTP/1.1 style request precondition of "If-Match". Failure to match the entity tag would fail the request with a 412 response like in Proposal 1. Personally, I like Proposal 4, because it accomplishes exactly what we want without the (theoretical) problem with the 1 second resolution in Date values. Comments? Cheers, Aki _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Jun 5 11:29:27 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 LAA02748; Thu, 5 Jun 2003 11:29:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NweO-0000Ov-00; Thu, 05 Jun 2003 11:27:36 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19NweN-0000Os-00; Thu, 05 Jun 2003 11:27:35 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55FQ7B13887; Thu, 5 Jun 2003 11:26:07 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55FPFB13824 for ; Thu, 5 Jun 2003 11:25:15 -0400 Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02649 for ; Thu, 5 Jun 2003 11:25:12 -0400 (EDT) From: aki.niemi@nokia.com 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 h55FPCW25064 for ; Thu, 5 Jun 2003 18:25:12 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 5 Jun 2003 18:25:12 +0300 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 5 Jun 2003 18:25:12 +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" Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9019452B0@esebe013.ntc.nokia.com> Thread-Topic: PUBLISH: identification of presence segments Thread-Index: AcMrdqe3fTZTitqNRcO56t+UPArpjw== To: X-OriginalArrivalTime: 05 Jun 2003 15:25:12.0425 (UTC) FILETIME=[A82E5590:01C32B76] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h55FPFB13825 Subject: [Simple] PUBLISH: identification of presence segments 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, 5 Jun 2003 18:25:11 +0300 Content-Transfer-Encoding: 8bit Hi All, One of the open issues in the PUBLISH work is how to identify specific segments of state. Each event is supposed to define a way to identify a specific segment. So far, we've decided that in presence publication, a tuple corresponds to such a segment. I think the conclusion we arrived at in the interim meeting was that tuple IDs would be used to identiy a specific presence tuple instead of the RPIDS label-element. Just making sure this was the consensus. Anyone against? Cheers, Aki _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu Jun 5 11:29:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02790 for ; Thu, 5 Jun 2003 11:29:58 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h55FTUI14103 for simple-archive@odin.ietf.org; Thu, 5 Jun 2003 11:29:30 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55FTUB14100 for ; Thu, 5 Jun 2003 11: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 LAA02748; Thu, 5 Jun 2003 11:29:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NweO-0000Ov-00; Thu, 05 Jun 2003 11:27:36 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19NweN-0000Os-00; Thu, 05 Jun 2003 11:27:35 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55FQ7B13887; Thu, 5 Jun 2003 11:26:07 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55FPFB13824 for ; Thu, 5 Jun 2003 11:25:15 -0400 Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02649 for ; Thu, 5 Jun 2003 11:25:12 -0400 (EDT) From: aki.niemi@nokia.com 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 h55FPCW25064 for ; Thu, 5 Jun 2003 18:25:12 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 5 Jun 2003 18:25:12 +0300 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 5 Jun 2003 18:25:12 +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" Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9019452B0@esebe013.ntc.nokia.com> Thread-Topic: PUBLISH: identification of presence segments Thread-Index: AcMrdqe3fTZTitqNRcO56t+UPArpjw== To: X-OriginalArrivalTime: 05 Jun 2003 15:25:12.0425 (UTC) FILETIME=[A82E5590:01C32B76] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h55FPFB13825 Subject: [Simple] PUBLISH: identification of presence segments 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, 5 Jun 2003 18:25:11 +0300 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi All, One of the open issues in the PUBLISH work is how to identify specific segments of state. Each event is supposed to define a way to identify a specific segment. So far, we've decided that in presence publication, a tuple corresponds to such a segment. I think the conclusion we arrived at in the interim meeting was that tuple IDs would be used to identiy a specific presence tuple instead of the RPIDS label-element. Just making sure this was the consensus. Anyone against? Cheers, Aki _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Jun 5 12:59: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 MAA06308; Thu, 5 Jun 2003 12:59:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Ny3U-00016S-00; Thu, 05 Jun 2003 12:57:36 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Ny3T-00016P-00; Thu, 05 Jun 2003 12:57:35 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55GuAB21305; Thu, 5 Jun 2003 12:56:10 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55GtvB21281 for ; Thu, 5 Jun 2003 12:55: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 MAA06191 for ; Thu, 5 Jun 2003 12:55:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Ny02-000140-00 for simple@ietf.org; Thu, 05 Jun 2003 12:54:02 -0400 Received: from web41511.mail.yahoo.com ([66.218.93.94]) by ietf-mx with smtp (Exim 4.12) id 19Ny01-00013j-00 for simple@ietf.org; Thu, 05 Jun 2003 12:54:01 -0400 Message-ID: <20030605165523.61767.qmail@web41511.mail.yahoo.com> Received: from [131.107.3.71] by web41511.mail.yahoo.com via HTTP; Thu, 05 Jun 2003 09:55:23 PDT From: Sean Olson Subject: Re: [Simple] PUBLISH: versioning of published information To: aki.niemi@nokia.com, simple@ietf.org In-Reply-To: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9019452AF@esebe013.ntc.nokia.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: Thu, 5 Jun 2003 09:55:23 -0700 (PDT) The rationale behind using the timestamp element was that is was pre-existing and more importantly, it was in the body itself. The goal was to make the actual PUBLISH request headers as simple as possible without introducing new headers if at all possible. I like option 4, but it still has a sync. issue between EPAs. Namely, how does an EPA who is watching the published state detect collisions? I would like to see some feedback mechanism in the published state itself. Can we include the ETag as an optional component of the published tuple? --- aki.niemi@nokia.com wrote: > Hi All, > > In the SIMPLE interim we discussed the issue of > versioning of published information (among other > things - other issues will be posted on separate > emails). There were proposals at the meeting, and > we've also had a suggestion on the list since then. > I'll try to summarize the issue and the proposals > made this far. > > The current PUBLISH draft uses information contained > in the body of a publication, namely timestamps in > individual tuples to version the published tuples. > This doesn't work without global clock sync between > the EPAs, and so we need something else. > > Proposal 1: > Have the server return a timestamp in the response > of a PUBLISH, and have the client use that timestamp > with the HTTP/1.1 style preconditions > "If-Unmodified-Since" to detect if someone else has > modified the published tuple(s). Attempt to PUBLISH > a "stale" tuple would result in a 412 Preconditions > Failed error response. An automata refreshing a > publication would never override in such a case, but > some type of human intervention would be required to > do a fresh PUBLISH, i.e., a publication without the > preconditions. > > Proposal 2: > Since there is theoretically a 1 second time window > for two publications to collide due to the > resolution of the Date header time, it was suggested > that we should instead use a counter. Each fresh > publication of the tuple would return an incremented > value, which the client would use in each refresh > publication. > > Proposal 3: > Basically identical to the previous proposal except > that instead of a counter value, the server would > return an opaque token, much like the Set-Cookie, > Cookie headers in HTTP. > > Proposal 4: > It was suggested that HTTP/1.1 style entity-tags > would be used to identify a specific instance or > version of a tuple. The value received from a server > in an "ETag" header would be used by the client with > an HTTP/1.1 style request precondition of > "If-Match". Failure to match the entity tag would > fail the request with a 412 response like in > Proposal 1. > > Personally, I like Proposal 4, because it > accomplishes exactly what we want without the > (theoretical) problem with the 1 second resolution > in Date values. > > Comments? > > Cheers, > Aki > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple __________________________________ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu Jun 5 12:59:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06330 for ; Thu, 5 Jun 2003 12:59:57 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h55GxVS21556 for simple-archive@odin.ietf.org; Thu, 5 Jun 2003 12:59:31 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55GxVB21553 for ; Thu, 5 Jun 2003 12:59:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06308; Thu, 5 Jun 2003 12:59:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Ny3U-00016S-00; Thu, 05 Jun 2003 12:57:36 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Ny3T-00016P-00; Thu, 05 Jun 2003 12:57:35 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55GuAB21305; Thu, 5 Jun 2003 12:56:10 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55GtvB21281 for ; Thu, 5 Jun 2003 12:55: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 MAA06191 for ; Thu, 5 Jun 2003 12:55:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Ny02-000140-00 for simple@ietf.org; Thu, 05 Jun 2003 12:54:02 -0400 Received: from web41511.mail.yahoo.com ([66.218.93.94]) by ietf-mx with smtp (Exim 4.12) id 19Ny01-00013j-00 for simple@ietf.org; Thu, 05 Jun 2003 12:54:01 -0400 Message-ID: <20030605165523.61767.qmail@web41511.mail.yahoo.com> Received: from [131.107.3.71] by web41511.mail.yahoo.com via HTTP; Thu, 05 Jun 2003 09:55:23 PDT From: Sean Olson Subject: Re: [Simple] PUBLISH: versioning of published information To: aki.niemi@nokia.com, simple@ietf.org In-Reply-To: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9019452AF@esebe013.ntc.nokia.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: Thu, 5 Jun 2003 09:55:23 -0700 (PDT) The rationale behind using the timestamp element was that is was pre-existing and more importantly, it was in the body itself. The goal was to make the actual PUBLISH request headers as simple as possible without introducing new headers if at all possible. I like option 4, but it still has a sync. issue between EPAs. Namely, how does an EPA who is watching the published state detect collisions? I would like to see some feedback mechanism in the published state itself. Can we include the ETag as an optional component of the published tuple? --- aki.niemi@nokia.com wrote: > Hi All, > > In the SIMPLE interim we discussed the issue of > versioning of published information (among other > things - other issues will be posted on separate > emails). There were proposals at the meeting, and > we've also had a suggestion on the list since then. > I'll try to summarize the issue and the proposals > made this far. > > The current PUBLISH draft uses information contained > in the body of a publication, namely timestamps in > individual tuples to version the published tuples. > This doesn't work without global clock sync between > the EPAs, and so we need something else. > > Proposal 1: > Have the server return a timestamp in the response > of a PUBLISH, and have the client use that timestamp > with the HTTP/1.1 style preconditions > "If-Unmodified-Since" to detect if someone else has > modified the published tuple(s). Attempt to PUBLISH > a "stale" tuple would result in a 412 Preconditions > Failed error response. An automata refreshing a > publication would never override in such a case, but > some type of human intervention would be required to > do a fresh PUBLISH, i.e., a publication without the > preconditions. > > Proposal 2: > Since there is theoretically a 1 second time window > for two publications to collide due to the > resolution of the Date header time, it was suggested > that we should instead use a counter. Each fresh > publication of the tuple would return an incremented > value, which the client would use in each refresh > publication. > > Proposal 3: > Basically identical to the previous proposal except > that instead of a counter value, the server would > return an opaque token, much like the Set-Cookie, > Cookie headers in HTTP. > > Proposal 4: > It was suggested that HTTP/1.1 style entity-tags > would be used to identify a specific instance or > version of a tuple. The value received from a server > in an "ETag" header would be used by the client with > an HTTP/1.1 style request precondition of > "If-Match". Failure to match the entity tag would > fail the request with a 412 response like in > Proposal 1. > > Personally, I like Proposal 4, because it > accomplishes exactly what we want without the > (theoretical) problem with the 1 second resolution > in Date values. > > Comments? > > Cheers, > Aki > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple __________________________________ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Jun 5 13:00:16 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 NAA06362; Thu, 5 Jun 2003 13:00:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Ny4H-00016e-00; Thu, 05 Jun 2003 12:58:25 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Ny4H-00016b-00; Thu, 05 Jun 2003 12:58:25 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55Gv1B21373; Thu, 5 Jun 2003 12:57:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55GumB21326 for ; Thu, 5 Jun 2003 12:56:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06209 for ; Thu, 5 Jun 2003 12:56:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Ny0r-00014Q-00 for simple@ietf.org; Thu, 05 Jun 2003 12:54:53 -0400 Received: from oe-im1pub.managedmail.com ([206.46.164.52] helo=oe-im1.bizmailsrvcs.net) by ietf-mx with esmtp (Exim 4.12) id 19Ny0q-00014L-00 for simple@ietf.org; Thu, 05 Jun 2003 12:54:52 -0400 Received: from oe-ismta1.bizmailsrvcs.net ([206.46.164.26]) by oe-im1.bizmailsrvcs.net (InterMail vM.5.01.05.27 201-253-122-126-127-20021220) with ESMTP id <20030605165614.NSCH2597.oe-im1.bizmailsrvcs.net@oe-ismta1.bizmailsrvcs.net>; Thu, 5 Jun 2003 11:56:14 -0500 Received: from tdiacakis ([63.67.207.249]) by oe-ismta1.bizmailsrvcs.net (InterMail vM.5.01.05.27 201-253-122-126-127-20021220) with SMTP id <20030605165613.QLNM6261.oe-ismta1.bizmailsrvcs.net@tdiacakis>; Thu, 5 Jun 2003 11:56:13 -0500 Message-ID: <010f01c32b83$5fad5110$05071e0a@myopwv.com> From: "Thanos Diacakis" To: , References: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9019452B0@esebe013.ntc.nokia.com> Subject: Re: [Simple] PUBLISH: identification of presence segments MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 5 Jun 2003 10:56:09 -0600 Content-Transfer-Encoding: 7bit Hi Aki, (I'm assuming you're referring to the presence aggregation problem) I think I remember the consensus being along those lines, but I'm not sure this will work. Here's why... Recap: If two entities (say P1 and P2) are publishing presence for a particular presentity, that include two semantically identical tuples, it is hard for them to co-ordinate the tuple-ids. By "semantically identical" I mean they contain information about the same segment of state. The assumption I think that we were working on is that P1 will first publish a tuple T1 with tuple ID, say X1. P2 will be a subscriber to this information, and will have a way to figure out that the tuple T1 with ID X1 is "semantically identically" to the tuple it wants to publish (ignoring that this is not trivial), and thus P2 will publish a tuple T2 with ID X1. The aggregator at the Presence Service will then replace T2 with T1 (subject to the other mechanism we're discussing). Now the first problem is that if P1 and P2 simultaneously decide to publish T1 and T2 respectively, they will each assign unique ids to two tuples that are semantically the same. To solve this we need to have a central entity that can identify tuples that are "semantically identical" , and there are some ways of doing so. The second problem is that this mechanism relies on the tuples being published having the same ID as the tuples in notifications. This is possible in some simple cases, but won't work when the presence information being notified is based upon (but not verbatim copies) of the presence being published. For example, if a particular presence implementation takes tuples A and B, does some complex calculation and publishes tuple C, then we have a problem as there is no direct way to map tuple IDs between the publish and notify operations. (This also affects the versioning mechanism, as you may no longer assume that P1 and P2 can see all aspects of what each other is doing) Thanos --- Thanos Diacakis Openwave Systems thanos.diacakis@openwave.com +1-303 385 6705 ----- Original Message ----- From: To: Sent: Thursday, June 05, 2003 9:25 AM Subject: [Simple] PUBLISH: identification of presence segments > Hi All, > > One of the open issues in the PUBLISH work is how to identify specific segments of state. Each event is supposed to define a way to identify a specific segment. So far, we've decided that in presence publication, a tuple corresponds to such a segment. > > I think the conclusion we arrived at in the interim meeting was that tuple IDs would be used to identiy a specific presence tuple instead of the RPIDS label-element. > > Just making sure this was the consensus. Anyone against? > > Cheers, > Aki > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu Jun 5 13:00:47 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06400 for ; Thu, 5 Jun 2003 13:00:47 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h55H0LK21619 for simple-archive@odin.ietf.org; Thu, 5 Jun 2003 13:00:21 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55H0LB21616 for ; Thu, 5 Jun 2003 13:00:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06362; Thu, 5 Jun 2003 13:00:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Ny4H-00016e-00; Thu, 05 Jun 2003 12:58:25 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Ny4H-00016b-00; Thu, 05 Jun 2003 12:58:25 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55Gv1B21373; Thu, 5 Jun 2003 12:57:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55GumB21326 for ; Thu, 5 Jun 2003 12:56:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06209 for ; Thu, 5 Jun 2003 12:56:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Ny0r-00014Q-00 for simple@ietf.org; Thu, 05 Jun 2003 12:54:53 -0400 Received: from oe-im1pub.managedmail.com ([206.46.164.52] helo=oe-im1.bizmailsrvcs.net) by ietf-mx with esmtp (Exim 4.12) id 19Ny0q-00014L-00 for simple@ietf.org; Thu, 05 Jun 2003 12:54:52 -0400 Received: from oe-ismta1.bizmailsrvcs.net ([206.46.164.26]) by oe-im1.bizmailsrvcs.net (InterMail vM.5.01.05.27 201-253-122-126-127-20021220) with ESMTP id <20030605165614.NSCH2597.oe-im1.bizmailsrvcs.net@oe-ismta1.bizmailsrvcs.net>; Thu, 5 Jun 2003 11:56:14 -0500 Received: from tdiacakis ([63.67.207.249]) by oe-ismta1.bizmailsrvcs.net (InterMail vM.5.01.05.27 201-253-122-126-127-20021220) with SMTP id <20030605165613.QLNM6261.oe-ismta1.bizmailsrvcs.net@tdiacakis>; Thu, 5 Jun 2003 11:56:13 -0500 Message-ID: <010f01c32b83$5fad5110$05071e0a@myopwv.com> From: "Thanos Diacakis" To: , References: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9019452B0@esebe013.ntc.nokia.com> Subject: Re: [Simple] PUBLISH: identification of presence segments MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 5 Jun 2003 10:56:09 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Aki, (I'm assuming you're referring to the presence aggregation problem) I think I remember the consensus being along those lines, but I'm not sure this will work. Here's why... Recap: If two entities (say P1 and P2) are publishing presence for a particular presentity, that include two semantically identical tuples, it is hard for them to co-ordinate the tuple-ids. By "semantically identical" I mean they contain information about the same segment of state. The assumption I think that we were working on is that P1 will first publish a tuple T1 with tuple ID, say X1. P2 will be a subscriber to this information, and will have a way to figure out that the tuple T1 with ID X1 is "semantically identically" to the tuple it wants to publish (ignoring that this is not trivial), and thus P2 will publish a tuple T2 with ID X1. The aggregator at the Presence Service will then replace T2 with T1 (subject to the other mechanism we're discussing). Now the first problem is that if P1 and P2 simultaneously decide to publish T1 and T2 respectively, they will each assign unique ids to two tuples that are semantically the same. To solve this we need to have a central entity that can identify tuples that are "semantically identical" , and there are some ways of doing so. The second problem is that this mechanism relies on the tuples being published having the same ID as the tuples in notifications. This is possible in some simple cases, but won't work when the presence information being notified is based upon (but not verbatim copies) of the presence being published. For example, if a particular presence implementation takes tuples A and B, does some complex calculation and publishes tuple C, then we have a problem as there is no direct way to map tuple IDs between the publish and notify operations. (This also affects the versioning mechanism, as you may no longer assume that P1 and P2 can see all aspects of what each other is doing) Thanos --- Thanos Diacakis Openwave Systems thanos.diacakis@openwave.com +1-303 385 6705 ----- Original Message ----- From: To: Sent: Thursday, June 05, 2003 9:25 AM Subject: [Simple] PUBLISH: identification of presence segments > Hi All, > > One of the open issues in the PUBLISH work is how to identify specific segments of state. Each event is supposed to define a way to identify a specific segment. So far, we've decided that in presence publication, a tuple corresponds to such a segment. > > I think the conclusion we arrived at in the interim meeting was that tuple IDs would be used to identiy a specific presence tuple instead of the RPIDS label-element. > > Just making sure this was the consensus. Anyone against? > > Cheers, > Aki > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Jun 5 13:01:17 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 NAA06441; Thu, 5 Jun 2003 13:01:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Ny5G-00017g-00; Thu, 05 Jun 2003 12:59:26 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Ny5G-00017d-00; Thu, 05 Jun 2003 12:59:26 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55Gw3B21481; Thu, 5 Jun 2003 12:58:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55Gv9B21422 for ; Thu, 5 Jun 2003 12:57: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 MAA06240 for ; Thu, 5 Jun 2003 12:57:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Ny1C-00015M-00 for simple@ietf.org; Thu, 05 Jun 2003 12:55:14 -0400 Received: from web41505.mail.yahoo.com ([66.218.93.88]) by ietf-mx with smtp (Exim 4.12) id 19Ny1B-00014M-00 for simple@ietf.org; Thu, 05 Jun 2003 12:55:13 -0400 Message-ID: <20030605165634.50252.qmail@web41505.mail.yahoo.com> Received: from [131.107.3.78] by web41505.mail.yahoo.com via HTTP; Thu, 05 Jun 2003 09:56:34 PDT From: Sean Olson Subject: Re: [Simple] PUBLISH: identification of presence segments To: aki.niemi@nokia.com, simple@ietf.org In-Reply-To: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9019452B0@esebe013.ntc.nokia.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: Thu, 5 Jun 2003 09:56:34 -0700 (PDT) Agreed. The tuple ID is the only really guaranteed unique value on which to base this. --- aki.niemi@nokia.com wrote: > Hi All, > > One of the open issues in the PUBLISH work is how to > identify specific segments of state. Each event is > supposed to define a way to identify a specific > segment. So far, we've decided that in presence > publication, a tuple corresponds to such a segment. > > I think the conclusion we arrived at in the interim > meeting was that tuple IDs would be used to identiy > a specific presence tuple instead of the RPIDS > label-element. > > Just making sure this was the consensus. Anyone > against? > > Cheers, > Aki > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple __________________________________ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu Jun 5 13:01:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06466 for ; Thu, 5 Jun 2003 13:01:48 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h55H1M821704 for simple-archive@odin.ietf.org; Thu, 5 Jun 2003 13:01:22 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55H1MB21701 for ; Thu, 5 Jun 2003 13:01:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06441; Thu, 5 Jun 2003 13:01:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Ny5G-00017g-00; Thu, 05 Jun 2003 12:59:26 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Ny5G-00017d-00; Thu, 05 Jun 2003 12:59:26 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55Gw3B21481; Thu, 5 Jun 2003 12:58:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55Gv9B21422 for ; Thu, 5 Jun 2003 12:57: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 MAA06240 for ; Thu, 5 Jun 2003 12:57:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Ny1C-00015M-00 for simple@ietf.org; Thu, 05 Jun 2003 12:55:14 -0400 Received: from web41505.mail.yahoo.com ([66.218.93.88]) by ietf-mx with smtp (Exim 4.12) id 19Ny1B-00014M-00 for simple@ietf.org; Thu, 05 Jun 2003 12:55:13 -0400 Message-ID: <20030605165634.50252.qmail@web41505.mail.yahoo.com> Received: from [131.107.3.78] by web41505.mail.yahoo.com via HTTP; Thu, 05 Jun 2003 09:56:34 PDT From: Sean Olson Subject: Re: [Simple] PUBLISH: identification of presence segments To: aki.niemi@nokia.com, simple@ietf.org In-Reply-To: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9019452B0@esebe013.ntc.nokia.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: Thu, 5 Jun 2003 09:56:34 -0700 (PDT) Agreed. The tuple ID is the only really guaranteed unique value on which to base this. --- aki.niemi@nokia.com wrote: > Hi All, > > One of the open issues in the PUBLISH work is how to > identify specific segments of state. Each event is > supposed to define a way to identify a specific > segment. So far, we've decided that in presence > publication, a tuple corresponds to such a segment. > > I think the conclusion we arrived at in the interim > meeting was that tuple IDs would be used to identiy > a specific presence tuple instead of the RPIDS > label-element. > > Just making sure this was the consensus. Anyone > against? > > Cheers, > Aki > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple __________________________________ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Jun 5 15:23:31 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 PAA13208; Thu, 5 Jun 2003 15:23:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19O0It-0002XV-00; Thu, 05 Jun 2003 15:21:39 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19O0Is-0002XS-00; Thu, 05 Jun 2003 15:21:38 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55JKDB01400; Thu, 5 Jun 2003 15:20:13 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55JJGB01325 for ; Thu, 5 Jun 2003 15:19:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13008; Thu, 5 Jun 2003 15:19:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19O0Ek-0002UX-00; Thu, 05 Jun 2003 15:17:22 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19O0Ej-0002UO-00; Thu, 05 Jun 2003 15:17:21 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h55JIh623909; Thu, 5 Jun 2003 14:18:43 -0500 From: Robert Sparks To: simple@ietf.org, minutes@ietf.org Content-Type: text/plain Message-Id: <1054840721.927.29.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Minutes: SIMPLE Interim, May 29-30, 2003 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: 05 Jun 2003 14:18:42 -0500 Content-Transfer-Encoding: 7bit The minutes from last week's SIMPLE interim meeting are available at http://www.softarmor.com/simple/meets/interim2003/notes/minutes.txt RjS _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu Jun 5 15:24:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13242 for ; Thu, 5 Jun 2003 15:24:04 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h55JNZZ01583 for simple-archive@odin.ietf.org; Thu, 5 Jun 2003 15:23:35 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55JNYB01580 for ; Thu, 5 Jun 2003 15:23:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13208; Thu, 5 Jun 2003 15:23:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19O0It-0002XV-00; Thu, 05 Jun 2003 15:21:39 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19O0Is-0002XS-00; Thu, 05 Jun 2003 15:21:38 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55JKDB01400; Thu, 5 Jun 2003 15:20:13 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55JJGB01325 for ; Thu, 5 Jun 2003 15:19:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13008; Thu, 5 Jun 2003 15:19:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19O0Ek-0002UX-00; Thu, 05 Jun 2003 15:17:22 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19O0Ej-0002UO-00; Thu, 05 Jun 2003 15:17:21 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h55JIh623909; Thu, 5 Jun 2003 14:18:43 -0500 From: Robert Sparks To: simple@ietf.org, minutes@ietf.org Content-Type: text/plain Message-Id: <1054840721.927.29.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Minutes: SIMPLE Interim, May 29-30, 2003 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: 05 Jun 2003 14:18:42 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit The minutes from last week's SIMPLE interim meeting are available at http://www.softarmor.com/simple/meets/interim2003/notes/minutes.txt RjS _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Jun 6 02:44:35 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 CAA12110; Fri, 6 Jun 2003 02:44:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OAvy-0006tl-00; Fri, 06 Jun 2003 02:42:43 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19OAvy-0006tg-00; Fri, 06 Jun 2003 02:42:42 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h566fIB27607; Fri, 6 Jun 2003 02:41:18 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h566eLB27565 for ; Fri, 6 Jun 2003 02:40:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12079 for ; Fri, 6 Jun 2003 02:40:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OArm-0006sV-00 for simple@ietf.org; Fri, 06 Jun 2003 02:38:23 -0400 Received: from mgw2.noc.ntt.com ([210.163.32.69]) by ietf-mx with esmtp (Exim 4.12) id 19OArl-0006sS-00 for simple@ietf.org; Fri, 06 Jun 2003 02:38:22 -0400 Received: from mop2.noc.ntt.com by mgw2.noc.ntt.com (NTT-Com MailSV) with ESMTP id h566dh0c012382 for ; Fri, 6 Jun 2003 15:39:43 +0900 (JST) Received: from mip1.noc.ntt.com (mvi3.noc.ntt.com) by mop2.noc.ntt.com (NTT-Com MailSV) with ESMTP id <0HG1006OXRU79J@ntt.com> for simple@ietf.org; Fri, 06 Jun 2003 15:39:43 +0900 (JST) Received: from nttu26skyyrabi by mip1.noc.ntt.com (NTT-Com MailSV) with SMTP id <0HG100J8GRU7KU@ntt.com> for simple@ietf.org; Fri, 06 Jun 2003 15:39:43 +0900 (JST) Content-return: prohibited From: "Ashir Ahmed" To: simple@ietf.org Message-id: <008c01c32bf5$b4b46910$cd44320a@nttu26skyyrabi> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-type: multipart/alternative; boundary="----=_NextPart_000_0088_01C32C41.248E5570" X-Priority: 3 X-MSMail-priority: Normal Subject: [Simple] requirements of a presence server Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 06 Jun 2003 15:34:39 +0900 This is a multi-part message in MIME format. ------=_NextPart_000_0088_01C32C41.248E5570 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Is there any drafts/RFC that contains the requirements/features of a presence server? Thanks for your help. Ashir ------=_NextPart_000_0088_01C32C41.248E5570 Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable
Is there any drafts/RFC that = contains the=20 requirements/features of a presence server?
 
Thanks for your = help.
 
Ashir
------=_NextPart_000_0088_01C32C41.248E5570-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Fri Jun 6 02:45:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12142 for ; Fri, 6 Jun 2003 02:45:07 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h566igf27723 for simple-archive@odin.ietf.org; Fri, 6 Jun 2003 02:44:42 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h566ifB27720 for ; Fri, 6 Jun 2003 02:44:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12110; Fri, 6 Jun 2003 02:44:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OAvy-0006tl-00; Fri, 06 Jun 2003 02:42:43 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19OAvy-0006tg-00; Fri, 06 Jun 2003 02:42:42 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h566fIB27607; Fri, 6 Jun 2003 02:41:18 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h566eLB27565 for ; Fri, 6 Jun 2003 02:40:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12079 for ; Fri, 6 Jun 2003 02:40:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OArm-0006sV-00 for simple@ietf.org; Fri, 06 Jun 2003 02:38:23 -0400 Received: from mgw2.noc.ntt.com ([210.163.32.69]) by ietf-mx with esmtp (Exim 4.12) id 19OArl-0006sS-00 for simple@ietf.org; Fri, 06 Jun 2003 02:38:22 -0400 Received: from mop2.noc.ntt.com by mgw2.noc.ntt.com (NTT-Com MailSV) with ESMTP id h566dh0c012382 for ; Fri, 6 Jun 2003 15:39:43 +0900 (JST) Received: from mip1.noc.ntt.com (mvi3.noc.ntt.com) by mop2.noc.ntt.com (NTT-Com MailSV) with ESMTP id <0HG1006OXRU79J@ntt.com> for simple@ietf.org; Fri, 06 Jun 2003 15:39:43 +0900 (JST) Received: from nttu26skyyrabi by mip1.noc.ntt.com (NTT-Com MailSV) with SMTP id <0HG100J8GRU7KU@ntt.com> for simple@ietf.org; Fri, 06 Jun 2003 15:39:43 +0900 (JST) Content-return: prohibited From: "Ashir Ahmed" To: simple@ietf.org Message-id: <008c01c32bf5$b4b46910$cd44320a@nttu26skyyrabi> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-type: multipart/alternative; boundary="----=_NextPart_000_0088_01C32C41.248E5570" X-Priority: 3 X-MSMail-priority: Normal Subject: [Simple] requirements of a presence server Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 06 Jun 2003 15:34:39 +0900 This is a multi-part message in MIME format. ------=_NextPart_000_0088_01C32C41.248E5570 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Is there any drafts/RFC that contains the requirements/features of a presence server? Thanks for your help. Ashir ------=_NextPart_000_0088_01C32C41.248E5570 Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable
Is there any drafts/RFC that = contains the=20 requirements/features of a presence server?
 
Thanks for your = help.
 
Ashir
------=_NextPart_000_0088_01C32C41.248E5570-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Jun 6 03:22: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 DAA12790; Fri, 6 Jun 2003 03:22:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OBWf-00074J-00; Fri, 06 Jun 2003 03:20:37 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19OBWe-00074G-00; Fri, 06 Jun 2003 03:20:36 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h567JBB29821; Fri, 6 Jun 2003 03:19:11 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h567IZB29790 for ; Fri, 6 Jun 2003 03:18: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 DAA12705 for ; Fri, 6 Jun 2003 03:18:33 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OBSq-00072u-00 for simple@ietf.org; Fri, 06 Jun 2003 03:16:40 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19OBSp-00072r-00 for simple@ietf.org; Fri, 06 Jun 2003 03:16:40 -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 h567IWW23210 for ; Fri, 6 Jun 2003 10:18:32 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 6 Jun 2003 10:18:32 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 6 Jun 2003 10:18:32 +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" Subject: RE: [Simple] PUBLISH: versioning of published information Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701796D3E@esebe019.ntc.nokia.com> Thread-Topic: [Simple] PUBLISH: versioning of published information Thread-Index: AcMrg3GzyMFitiOFQ9mh811ikPA6iAAdcsYg To: , , X-OriginalArrivalTime: 06 Jun 2003 07:18:32.0129 (UTC) FILETIME=[D5DC8310:01C32BFB] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h567IZB29791 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, 6 Jun 2003 10:18:28 +0300 Content-Transfer-Encoding: 8bit I share some of Sean's concern, mainly for the reason I mentioned in the interim that we can't assume that all presentities will publish using PUBLISH. Putting something like this in the body will increase the chances of it being used. Regards, Hisham > -----Original Message----- > From: ext Sean Olson [mailto:seancolson@yahoo.com] > Sent: Thursday, June 05, 2003 7:55 PM > To: Niemi Aki (NMP/Helsinki); simple@ietf.org > Subject: Re: [Simple] PUBLISH: versioning of published information > > > The rationale behind using the timestamp element was > that is was pre-existing and more importantly, it was > in the body itself. The goal was to make the actual > PUBLISH request headers as simple as possible without > introducing new headers if at all possible. > > I like option 4, but it still has a sync. issue > between EPAs. Namely, how does an EPA who is watching > the published state detect collisions? I would like to > see some feedback mechanism in the published state > itself. Can we include the ETag as an optional > component of the published tuple? > > > --- aki.niemi@nokia.com wrote: > > Hi All, > > > > In the SIMPLE interim we discussed the issue of > > versioning of published information (among other > > things - other issues will be posted on separate > > emails). There were proposals at the meeting, and > > we've also had a suggestion on the list since then. > > I'll try to summarize the issue and the proposals > > made this far. > > > > The current PUBLISH draft uses information contained > > in the body of a publication, namely timestamps in > > individual tuples to version the published tuples. > > This doesn't work without global clock sync between > > the EPAs, and so we need something else. > > > > Proposal 1: > > Have the server return a timestamp in the response > > of a PUBLISH, and have the client use that timestamp > > with the HTTP/1.1 style preconditions > > "If-Unmodified-Since" to detect if someone else has > > modified the published tuple(s). Attempt to PUBLISH > > a "stale" tuple would result in a 412 Preconditions > > Failed error response. An automata refreshing a > > publication would never override in such a case, but > > some type of human intervention would be required to > > do a fresh PUBLISH, i.e., a publication without the > > preconditions. > > > > Proposal 2: > > Since there is theoretically a 1 second time window > > for two publications to collide due to the > > resolution of the Date header time, it was suggested > > that we should instead use a counter. Each fresh > > publication of the tuple would return an incremented > > value, which the client would use in each refresh > > publication. > > > > Proposal 3: > > Basically identical to the previous proposal except > > that instead of a counter value, the server would > > return an opaque token, much like the Set-Cookie, > > Cookie headers in HTTP. > > > > Proposal 4: > > It was suggested that HTTP/1.1 style entity-tags > > would be used to identify a specific instance or > > version of a tuple. The value received from a server > > in an "ETag" header would be used by the client with > > an HTTP/1.1 style request precondition of > > "If-Match". Failure to match the entity tag would > > fail the request with a 412 response like in > > Proposal 1. > > > > Personally, I like Proposal 4, because it > > accomplishes exactly what we want without the > > (theoretical) problem with the 1 second resolution > > in Date values. > > > > Comments? > > > > Cheers, > > Aki > > > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > > > __________________________________ > Do you Yahoo!? > Yahoo! Calendar - Free online calendar with sync to Outlook(TM). > http://calendar.yahoo.com > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Fri Jun 6 03:23:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12806 for ; Fri, 6 Jun 2003 03:23:00 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h567MW529955 for simple-archive@odin.ietf.org; Fri, 6 Jun 2003 03:22:32 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h567MWB29952 for ; Fri, 6 Jun 2003 03:22:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12790; Fri, 6 Jun 2003 03:22:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OBWf-00074J-00; Fri, 06 Jun 2003 03:20:37 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19OBWe-00074G-00; Fri, 06 Jun 2003 03:20:36 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h567JBB29821; Fri, 6 Jun 2003 03:19:11 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h567IZB29790 for ; Fri, 6 Jun 2003 03:18: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 DAA12705 for ; Fri, 6 Jun 2003 03:18:33 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OBSq-00072u-00 for simple@ietf.org; Fri, 06 Jun 2003 03:16:40 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19OBSp-00072r-00 for simple@ietf.org; Fri, 06 Jun 2003 03:16:40 -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 h567IWW23210 for ; Fri, 6 Jun 2003 10:18:32 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 6 Jun 2003 10:18:32 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 6 Jun 2003 10:18:32 +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" Subject: RE: [Simple] PUBLISH: versioning of published information Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701796D3E@esebe019.ntc.nokia.com> Thread-Topic: [Simple] PUBLISH: versioning of published information Thread-Index: AcMrg3GzyMFitiOFQ9mh811ikPA6iAAdcsYg To: , , X-OriginalArrivalTime: 06 Jun 2003 07:18:32.0129 (UTC) FILETIME=[D5DC8310:01C32BFB] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h567IZB29791 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, 6 Jun 2003 10:18:28 +0300 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit I share some of Sean's concern, mainly for the reason I mentioned in the interim that we can't assume that all presentities will publish using PUBLISH. Putting something like this in the body will increase the chances of it being used. Regards, Hisham > -----Original Message----- > From: ext Sean Olson [mailto:seancolson@yahoo.com] > Sent: Thursday, June 05, 2003 7:55 PM > To: Niemi Aki (NMP/Helsinki); simple@ietf.org > Subject: Re: [Simple] PUBLISH: versioning of published information > > > The rationale behind using the timestamp element was > that is was pre-existing and more importantly, it was > in the body itself. The goal was to make the actual > PUBLISH request headers as simple as possible without > introducing new headers if at all possible. > > I like option 4, but it still has a sync. issue > between EPAs. Namely, how does an EPA who is watching > the published state detect collisions? I would like to > see some feedback mechanism in the published state > itself. Can we include the ETag as an optional > component of the published tuple? > > > --- aki.niemi@nokia.com wrote: > > Hi All, > > > > In the SIMPLE interim we discussed the issue of > > versioning of published information (among other > > things - other issues will be posted on separate > > emails). There were proposals at the meeting, and > > we've also had a suggestion on the list since then. > > I'll try to summarize the issue and the proposals > > made this far. > > > > The current PUBLISH draft uses information contained > > in the body of a publication, namely timestamps in > > individual tuples to version the published tuples. > > This doesn't work without global clock sync between > > the EPAs, and so we need something else. > > > > Proposal 1: > > Have the server return a timestamp in the response > > of a PUBLISH, and have the client use that timestamp > > with the HTTP/1.1 style preconditions > > "If-Unmodified-Since" to detect if someone else has > > modified the published tuple(s). Attempt to PUBLISH > > a "stale" tuple would result in a 412 Preconditions > > Failed error response. An automata refreshing a > > publication would never override in such a case, but > > some type of human intervention would be required to > > do a fresh PUBLISH, i.e., a publication without the > > preconditions. > > > > Proposal 2: > > Since there is theoretically a 1 second time window > > for two publications to collide due to the > > resolution of the Date header time, it was suggested > > that we should instead use a counter. Each fresh > > publication of the tuple would return an incremented > > value, which the client would use in each refresh > > publication. > > > > Proposal 3: > > Basically identical to the previous proposal except > > that instead of a counter value, the server would > > return an opaque token, much like the Set-Cookie, > > Cookie headers in HTTP. > > > > Proposal 4: > > It was suggested that HTTP/1.1 style entity-tags > > would be used to identify a specific instance or > > version of a tuple. The value received from a server > > in an "ETag" header would be used by the client with > > an HTTP/1.1 style request precondition of > > "If-Match". Failure to match the entity tag would > > fail the request with a 412 response like in > > Proposal 1. > > > > Personally, I like Proposal 4, because it > > accomplishes exactly what we want without the > > (theoretical) problem with the 1 second resolution > > in Date values. > > > > Comments? > > > > Cheers, > > Aki > > > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > > > __________________________________ > Do you Yahoo!? > Yahoo! Calendar - Free online calendar with sync to Outlook(TM). > http://calendar.yahoo.com > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Jun 6 06:00:32 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 GAA15866; Fri, 6 Jun 2003 06:00:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ODzc-00007D-00; Fri, 06 Jun 2003 05:58:40 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ODzb-00007A-00; Fri, 06 Jun 2003 05:58:39 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h569vHB08404; Fri, 6 Jun 2003 05:57:17 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h569ugB08373 for ; Fri, 6 Jun 2003 05:56:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15807 for ; Fri, 6 Jun 2003 05:56:37 -0400 (EDT) From: aki.niemi@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ODvp-00006Q-00 for simple@ietf.org; Fri, 06 Jun 2003 05:54:45 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19ODvo-00006M-00 for simple@ietf.org; Fri, 06 Jun 2003 05:54:44 -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 h569uWW01464 for ; Fri, 6 Jun 2003 12:56:32 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 6 Jun 2003 12:56:31 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 6 Jun 2003 12:56:31 +0300 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 6 Jun 2003 12:56:31 +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" Subject: RE: [Simple] PUBLISH: versioning of published information Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD901ADD714@esebe013.ntc.nokia.com> Thread-Topic: [Simple] PUBLISH: versioning of published information Thread-Index: AcMrg0XEa7Z1PViKQJ2A74b5D1c5SAABSazw To: , X-OriginalArrivalTime: 06 Jun 2003 09:56:31.0455 (UTC) FILETIME=[E7FADEF0:01C32C11] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h569ugB08374 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, 6 Jun 2003 12:56:30 +0300 Content-Transfer-Encoding: 8bit > -----Original Message----- > From: ext Sean Olson [mailto:seancolson@yahoo.com] > Sent: 05 June, 2003 19:55 > To: Niemi Aki (NMP/Helsinki); simple@ietf.org > Subject: Re: [Simple] PUBLISH: versioning of published information > > > The rationale behind using the timestamp element was > that is was pre-existing and more importantly, it was > in the body itself. The goal was to make the actual > PUBLISH request headers as simple as possible without > introducing new headers if at all possible. > > I like option 4, but it still has a sync. issue > between EPAs. Namely, how does an EPA who is watching > the published state detect collisions? I would like to > see some feedback mechanism in the published state > itself. Can we include the ETag as an optional > component of the published tuple? An EPA would detect a collision once it tried to refresh its state, and got a 412 response. Between the refreshes, doesn't the tuple ID basically enable this? If a watcher detects presence notification that matches its own, but has different state then it can figure out that a collision occurred? Cheers, Aki > > --- aki.niemi@nokia.com wrote: > > Hi All, > > > > In the SIMPLE interim we discussed the issue of > > versioning of published information (among other > > things - other issues will be posted on separate > > emails). There were proposals at the meeting, and > > we've also had a suggestion on the list since then. > > I'll try to summarize the issue and the proposals > > made this far. > > > > The current PUBLISH draft uses information contained > > in the body of a publication, namely timestamps in > > individual tuples to version the published tuples. > > This doesn't work without global clock sync between > > the EPAs, and so we need something else. > > > > Proposal 1: > > Have the server return a timestamp in the response > > of a PUBLISH, and have the client use that timestamp > > with the HTTP/1.1 style preconditions > > "If-Unmodified-Since" to detect if someone else has > > modified the published tuple(s). Attempt to PUBLISH > > a "stale" tuple would result in a 412 Preconditions > > Failed error response. An automata refreshing a > > publication would never override in such a case, but > > some type of human intervention would be required to > > do a fresh PUBLISH, i.e., a publication without the > > preconditions. > > > > Proposal 2: > > Since there is theoretically a 1 second time window > > for two publications to collide due to the > > resolution of the Date header time, it was suggested > > that we should instead use a counter. Each fresh > > publication of the tuple would return an incremented > > value, which the client would use in each refresh > > publication. > > > > Proposal 3: > > Basically identical to the previous proposal except > > that instead of a counter value, the server would > > return an opaque token, much like the Set-Cookie, > > Cookie headers in HTTP. > > > > Proposal 4: > > It was suggested that HTTP/1.1 style entity-tags > > would be used to identify a specific instance or > > version of a tuple. The value received from a server > > in an "ETag" header would be used by the client with > > an HTTP/1.1 style request precondition of > > "If-Match". Failure to match the entity tag would > > fail the request with a 412 response like in > > Proposal 1. > > > > Personally, I like Proposal 4, because it > > accomplishes exactly what we want without the > > (theoretical) problem with the 1 second resolution > > in Date values. > > > > Comments? > > > > Cheers, > > Aki > > > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > > > __________________________________ > Do you Yahoo!? > Yahoo! Calendar - Free online calendar with sync to Outlook(TM). > http://calendar.yahoo.com > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Fri Jun 6 06:01:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15899 for ; Fri, 6 Jun 2003 06:01:03 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h56A0dv08538 for simple-archive@odin.ietf.org; Fri, 6 Jun 2003 06:00:39 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56A0cB08535 for ; Fri, 6 Jun 2003 06:00:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15866; Fri, 6 Jun 2003 06:00:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ODzc-00007D-00; Fri, 06 Jun 2003 05:58:40 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ODzb-00007A-00; Fri, 06 Jun 2003 05:58:39 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h569vHB08404; Fri, 6 Jun 2003 05:57:17 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h569ugB08373 for ; Fri, 6 Jun 2003 05:56:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15807 for ; Fri, 6 Jun 2003 05:56:37 -0400 (EDT) From: aki.niemi@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ODvp-00006Q-00 for simple@ietf.org; Fri, 06 Jun 2003 05:54:45 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19ODvo-00006M-00 for simple@ietf.org; Fri, 06 Jun 2003 05:54:44 -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 h569uWW01464 for ; Fri, 6 Jun 2003 12:56:32 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 6 Jun 2003 12:56:31 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 6 Jun 2003 12:56:31 +0300 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 6 Jun 2003 12:56:31 +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" Subject: RE: [Simple] PUBLISH: versioning of published information Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD901ADD714@esebe013.ntc.nokia.com> Thread-Topic: [Simple] PUBLISH: versioning of published information Thread-Index: AcMrg0XEa7Z1PViKQJ2A74b5D1c5SAABSazw To: , X-OriginalArrivalTime: 06 Jun 2003 09:56:31.0455 (UTC) FILETIME=[E7FADEF0:01C32C11] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h569ugB08374 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, 6 Jun 2003 12:56:30 +0300 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit > -----Original Message----- > From: ext Sean Olson [mailto:seancolson@yahoo.com] > Sent: 05 June, 2003 19:55 > To: Niemi Aki (NMP/Helsinki); simple@ietf.org > Subject: Re: [Simple] PUBLISH: versioning of published information > > > The rationale behind using the timestamp element was > that is was pre-existing and more importantly, it was > in the body itself. The goal was to make the actual > PUBLISH request headers as simple as possible without > introducing new headers if at all possible. > > I like option 4, but it still has a sync. issue > between EPAs. Namely, how does an EPA who is watching > the published state detect collisions? I would like to > see some feedback mechanism in the published state > itself. Can we include the ETag as an optional > component of the published tuple? An EPA would detect a collision once it tried to refresh its state, and got a 412 response. Between the refreshes, doesn't the tuple ID basically enable this? If a watcher detects presence notification that matches its own, but has different state then it can figure out that a collision occurred? Cheers, Aki > > --- aki.niemi@nokia.com wrote: > > Hi All, > > > > In the SIMPLE interim we discussed the issue of > > versioning of published information (among other > > things - other issues will be posted on separate > > emails). There were proposals at the meeting, and > > we've also had a suggestion on the list since then. > > I'll try to summarize the issue and the proposals > > made this far. > > > > The current PUBLISH draft uses information contained > > in the body of a publication, namely timestamps in > > individual tuples to version the published tuples. > > This doesn't work without global clock sync between > > the EPAs, and so we need something else. > > > > Proposal 1: > > Have the server return a timestamp in the response > > of a PUBLISH, and have the client use that timestamp > > with the HTTP/1.1 style preconditions > > "If-Unmodified-Since" to detect if someone else has > > modified the published tuple(s). Attempt to PUBLISH > > a "stale" tuple would result in a 412 Preconditions > > Failed error response. An automata refreshing a > > publication would never override in such a case, but > > some type of human intervention would be required to > > do a fresh PUBLISH, i.e., a publication without the > > preconditions. > > > > Proposal 2: > > Since there is theoretically a 1 second time window > > for two publications to collide due to the > > resolution of the Date header time, it was suggested > > that we should instead use a counter. Each fresh > > publication of the tuple would return an incremented > > value, which the client would use in each refresh > > publication. > > > > Proposal 3: > > Basically identical to the previous proposal except > > that instead of a counter value, the server would > > return an opaque token, much like the Set-Cookie, > > Cookie headers in HTTP. > > > > Proposal 4: > > It was suggested that HTTP/1.1 style entity-tags > > would be used to identify a specific instance or > > version of a tuple. The value received from a server > > in an "ETag" header would be used by the client with > > an HTTP/1.1 style request precondition of > > "If-Match". Failure to match the entity tag would > > fail the request with a 412 response like in > > Proposal 1. > > > > Personally, I like Proposal 4, because it > > accomplishes exactly what we want without the > > (theoretical) problem with the 1 second resolution > > in Date values. > > > > Comments? > > > > Cheers, > > Aki > > > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > > > __________________________________ > Do you Yahoo!? > Yahoo! Calendar - Free online calendar with sync to Outlook(TM). > http://calendar.yahoo.com > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Jun 6 06:14:21 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 GAA16051; Fri, 6 Jun 2003 06:14:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OECz-0000C7-00; Fri, 06 Jun 2003 06:12:29 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19OECy-0000C4-00; Fri, 06 Jun 2003 06:12:28 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56AB6B09826; Fri, 6 Jun 2003 06:11:06 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56AAXB09795 for ; Fri, 6 Jun 2003 06: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 GAA15989 for ; Fri, 6 Jun 2003 06:10:27 -0400 (EDT) From: aki.niemi@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OE9D-0000A0-00 for simple@ietf.org; Fri, 06 Jun 2003 06:08:35 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19OE9C-00009x-00 for simple@ietf.org; Fri, 06 Jun 2003 06:08:34 -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 h56AARW16486 for ; Fri, 6 Jun 2003 13:10:27 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 6 Jun 2003 13:10:25 +0300 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 6 Jun 2003 13:10:25 +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" Subject: RE: [Simple] PUBLISH: versioning of published information Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9019452B5@esebe013.ntc.nokia.com> Thread-Topic: [Simple] PUBLISH: versioning of published information Thread-Index: AcMrg3GzyMFitiOFQ9mh811ikPA6iAAdcsYgAAYr4bA= To: , , X-OriginalArrivalTime: 06 Jun 2003 10:10:25.0054 (UTC) FILETIME=[D8D7FBE0:01C32C13] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h56AAXB09796 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, 6 Jun 2003 13:10:24 +0300 Content-Transfer-Encoding: 8bit Having versioning in the body would be the optimal solution, but I think we quite clearly demonstrated that it won't work without clock (or counter, etc.) sync between the publishers. I think this problem maps quite nicely to the model used in HTTP where a resource (data object or service) has many representations, defined as entities - an entity tag uniquely identifying each one of them. We can think of an event segment being the resource, and each publication of that event segment carrying a representation of that resource. There needs to be a central body assigning entity tags for those representations (the server) - otherwise we end up with the sync problem. I don't think it matters whether a more recent publication for the same event segment arrived via PUBLISH or some other mechanism. I think it's up to the other mechaisms to define their own way of detecting collisions. We only need to define that for PUBLISH. Cheers, Aki > -----Original Message----- > From: ext hisham.khartabil@nokia.com > [mailto:hisham.khartabil@nokia.com] > Sent: 06 June, 2003 10:18 > To: seancolson@yahoo.com; Niemi Aki (NMP/Helsinki); simple@ietf.org > Subject: RE: [Simple] PUBLISH: versioning of published information > > > I share some of Sean's concern, mainly for the reason I > mentioned in the interim that we can't assume that all > presentities will publish using PUBLISH. Putting something > like this in the body will increase the chances of it being used. > > Regards, > Hisham > > > -----Original Message----- > > From: ext Sean Olson [mailto:seancolson@yahoo.com] > > Sent: Thursday, June 05, 2003 7:55 PM > > To: Niemi Aki (NMP/Helsinki); simple@ietf.org > > Subject: Re: [Simple] PUBLISH: versioning of published information > > > > > > The rationale behind using the timestamp element was > > that is was pre-existing and more importantly, it was > > in the body itself. The goal was to make the actual > > PUBLISH request headers as simple as possible without > > introducing new headers if at all possible. > > > > I like option 4, but it still has a sync. issue > > between EPAs. Namely, how does an EPA who is watching > > the published state detect collisions? I would like to > > see some feedback mechanism in the published state > > itself. Can we include the ETag as an optional > > component of the published tuple? > > > > > > --- aki.niemi@nokia.com wrote: > > > Hi All, > > > > > > In the SIMPLE interim we discussed the issue of > > > versioning of published information (among other > > > things - other issues will be posted on separate > > > emails). There were proposals at the meeting, and > > > we've also had a suggestion on the list since then. > > > I'll try to summarize the issue and the proposals > > > made this far. > > > > > > The current PUBLISH draft uses information contained > > > in the body of a publication, namely timestamps in > > > individual tuples to version the published tuples. > > > This doesn't work without global clock sync between > > > the EPAs, and so we need something else. > > > > > > Proposal 1: > > > Have the server return a timestamp in the response > > > of a PUBLISH, and have the client use that timestamp > > > with the HTTP/1.1 style preconditions > > > "If-Unmodified-Since" to detect if someone else has > > > modified the published tuple(s). Attempt to PUBLISH > > > a "stale" tuple would result in a 412 Preconditions > > > Failed error response. An automata refreshing a > > > publication would never override in such a case, but > > > some type of human intervention would be required to > > > do a fresh PUBLISH, i.e., a publication without the > > > preconditions. > > > > > > Proposal 2: > > > Since there is theoretically a 1 second time window > > > for two publications to collide due to the > > > resolution of the Date header time, it was suggested > > > that we should instead use a counter. Each fresh > > > publication of the tuple would return an incremented > > > value, which the client would use in each refresh > > > publication. > > > > > > Proposal 3: > > > Basically identical to the previous proposal except > > > that instead of a counter value, the server would > > > return an opaque token, much like the Set-Cookie, > > > Cookie headers in HTTP. > > > > > > Proposal 4: > > > It was suggested that HTTP/1.1 style entity-tags > > > would be used to identify a specific instance or > > > version of a tuple. The value received from a server > > > in an "ETag" header would be used by the client with > > > an HTTP/1.1 style request precondition of > > > "If-Match". Failure to match the entity tag would > > > fail the request with a 412 response like in > > > Proposal 1. > > > > > > Personally, I like Proposal 4, because it > > > accomplishes exactly what we want without the > > > (theoretical) problem with the 1 second resolution > > > in Date values. > > > > > > Comments? > > > > > > Cheers, > > > Aki > > > > > > _______________________________________________ > > > Simple mailing list > > > Simple@ietf.org > > > https://www1.ietf.org/mailman/listinfo/simple > > > > > > __________________________________ > > Do you Yahoo!? > > Yahoo! Calendar - Free online calendar with sync to Outlook(TM). > > http://calendar.yahoo.com > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Fri Jun 6 06:14:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16067 for ; Fri, 6 Jun 2003 06:14:52 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h56AESG09944 for simple-archive@odin.ietf.org; Fri, 6 Jun 2003 06:14:28 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56AERB09941 for ; Fri, 6 Jun 2003 06:14:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16051; Fri, 6 Jun 2003 06:14:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OECz-0000C7-00; Fri, 06 Jun 2003 06:12:29 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19OECy-0000C4-00; Fri, 06 Jun 2003 06:12:28 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56AB6B09826; Fri, 6 Jun 2003 06:11:06 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56AAXB09795 for ; Fri, 6 Jun 2003 06: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 GAA15989 for ; Fri, 6 Jun 2003 06:10:27 -0400 (EDT) From: aki.niemi@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OE9D-0000A0-00 for simple@ietf.org; Fri, 06 Jun 2003 06:08:35 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19OE9C-00009x-00 for simple@ietf.org; Fri, 06 Jun 2003 06:08:34 -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 h56AARW16486 for ; Fri, 6 Jun 2003 13:10:27 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 6 Jun 2003 13:10:25 +0300 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 6 Jun 2003 13:10:25 +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" Subject: RE: [Simple] PUBLISH: versioning of published information Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9019452B5@esebe013.ntc.nokia.com> Thread-Topic: [Simple] PUBLISH: versioning of published information Thread-Index: AcMrg3GzyMFitiOFQ9mh811ikPA6iAAdcsYgAAYr4bA= To: , , X-OriginalArrivalTime: 06 Jun 2003 10:10:25.0054 (UTC) FILETIME=[D8D7FBE0:01C32C13] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h56AAXB09796 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, 6 Jun 2003 13:10:24 +0300 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Having versioning in the body would be the optimal solution, but I think we quite clearly demonstrated that it won't work without clock (or counter, etc.) sync between the publishers. I think this problem maps quite nicely to the model used in HTTP where a resource (data object or service) has many representations, defined as entities - an entity tag uniquely identifying each one of them. We can think of an event segment being the resource, and each publication of that event segment carrying a representation of that resource. There needs to be a central body assigning entity tags for those representations (the server) - otherwise we end up with the sync problem. I don't think it matters whether a more recent publication for the same event segment arrived via PUBLISH or some other mechanism. I think it's up to the other mechaisms to define their own way of detecting collisions. We only need to define that for PUBLISH. Cheers, Aki > -----Original Message----- > From: ext hisham.khartabil@nokia.com > [mailto:hisham.khartabil@nokia.com] > Sent: 06 June, 2003 10:18 > To: seancolson@yahoo.com; Niemi Aki (NMP/Helsinki); simple@ietf.org > Subject: RE: [Simple] PUBLISH: versioning of published information > > > I share some of Sean's concern, mainly for the reason I > mentioned in the interim that we can't assume that all > presentities will publish using PUBLISH. Putting something > like this in the body will increase the chances of it being used. > > Regards, > Hisham > > > -----Original Message----- > > From: ext Sean Olson [mailto:seancolson@yahoo.com] > > Sent: Thursday, June 05, 2003 7:55 PM > > To: Niemi Aki (NMP/Helsinki); simple@ietf.org > > Subject: Re: [Simple] PUBLISH: versioning of published information > > > > > > The rationale behind using the timestamp element was > > that is was pre-existing and more importantly, it was > > in the body itself. The goal was to make the actual > > PUBLISH request headers as simple as possible without > > introducing new headers if at all possible. > > > > I like option 4, but it still has a sync. issue > > between EPAs. Namely, how does an EPA who is watching > > the published state detect collisions? I would like to > > see some feedback mechanism in the published state > > itself. Can we include the ETag as an optional > > component of the published tuple? > > > > > > --- aki.niemi@nokia.com wrote: > > > Hi All, > > > > > > In the SIMPLE interim we discussed the issue of > > > versioning of published information (among other > > > things - other issues will be posted on separate > > > emails). There were proposals at the meeting, and > > > we've also had a suggestion on the list since then. > > > I'll try to summarize the issue and the proposals > > > made this far. > > > > > > The current PUBLISH draft uses information contained > > > in the body of a publication, namely timestamps in > > > individual tuples to version the published tuples. > > > This doesn't work without global clock sync between > > > the EPAs, and so we need something else. > > > > > > Proposal 1: > > > Have the server return a timestamp in the response > > > of a PUBLISH, and have the client use that timestamp > > > with the HTTP/1.1 style preconditions > > > "If-Unmodified-Since" to detect if someone else has > > > modified the published tuple(s). Attempt to PUBLISH > > > a "stale" tuple would result in a 412 Preconditions > > > Failed error response. An automata refreshing a > > > publication would never override in such a case, but > > > some type of human intervention would be required to > > > do a fresh PUBLISH, i.e., a publication without the > > > preconditions. > > > > > > Proposal 2: > > > Since there is theoretically a 1 second time window > > > for two publications to collide due to the > > > resolution of the Date header time, it was suggested > > > that we should instead use a counter. Each fresh > > > publication of the tuple would return an incremented > > > value, which the client would use in each refresh > > > publication. > > > > > > Proposal 3: > > > Basically identical to the previous proposal except > > > that instead of a counter value, the server would > > > return an opaque token, much like the Set-Cookie, > > > Cookie headers in HTTP. > > > > > > Proposal 4: > > > It was suggested that HTTP/1.1 style entity-tags > > > would be used to identify a specific instance or > > > version of a tuple. The value received from a server > > > in an "ETag" header would be used by the client with > > > an HTTP/1.1 style request precondition of > > > "If-Match". Failure to match the entity tag would > > > fail the request with a 412 response like in > > > Proposal 1. > > > > > > Personally, I like Proposal 4, because it > > > accomplishes exactly what we want without the > > > (theoretical) problem with the 1 second resolution > > > in Date values. > > > > > > Comments? > > > > > > Cheers, > > > Aki > > > > > > _______________________________________________ > > > Simple mailing list > > > Simple@ietf.org > > > https://www1.ietf.org/mailman/listinfo/simple > > > > > > __________________________________ > > Do you Yahoo!? > > Yahoo! Calendar - Free online calendar with sync to Outlook(TM). > > http://calendar.yahoo.com > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Jun 6 09:00:41 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 JAA21935; Fri, 6 Jun 2003 09:00:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OGnw-0001n7-00; Fri, 06 Jun 2003 08:58:48 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19OGnv-0001n4-00; Fri, 06 Jun 2003 08:58:47 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56CvMB20904; Fri, 6 Jun 2003 08:57:22 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56CuWB20866 for ; Fri, 6 Jun 2003 08:56:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21843 for ; Fri, 6 Jun 2003 08:56:28 -0400 (EDT) From: aki.niemi@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OGjr-0001lS-00 for simple@ietf.org; Fri, 06 Jun 2003 08:54:35 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19OGjq-0001lP-00 for simple@ietf.org; Fri, 06 Jun 2003 08:54:34 -0400 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h56CuRD10727 for ; Fri, 6 Jun 2003 15:56:27 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 6 Jun 2003 15:56:27 +0300 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 6 Jun 2003 15:56:27 +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" Subject: RE: [Simple] PUBLISH: identification of presence segments Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9019452B6@esebe013.ntc.nokia.com> Thread-Topic: [Simple] PUBLISH: identification of presence segments Thread-Index: AcMrg2qSkM3Av3+6SlahjiuITK+g+QAkHEQg To: , X-OriginalArrivalTime: 06 Jun 2003 12:56:27.0153 (UTC) FILETIME=[0AB7A810:01C32C2B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h56CuWB20867 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, 6 Jun 2003 15:56:26 +0300 Content-Transfer-Encoding: 8bit Hi Thanos, I think you are right in that using the tuple ID makes the assumption that the composer never merges or modifies the individual tuples, so that the ID is carried over to the watchers intact. You also touch on a very interesting related topic of how to identify two "semantically identical" presence segments. Since the tuple IDs are generated at the source of presence information, it could be so that two sources publish the same presence segment using a different ID. In this case, the composer would need to know that the segments are in fact two representations of the same presence segment, and instead of composing them both in the presence document it should only use the most recent one of the two (and indicate a collision to the publisher of the stale one). I think the only use case we considered in the interim was one where a user goes home, sees that her work PC is still publishing OPEN IM status, and needs to "steal" that particular publication away from the work PC. In this scenario, merely knowing the tuple ID would suffice. So we have two issues to resolve: (1) Can we restrict the composer so that published tuples are never merged or modified? (2) Can we define a way for the composer (and EPAs as well) to identify "semantically identical" tuples when they have different IDs? I think (1) has a more wider scope that deals with the models we have envisioned for presence composition. As was also stated in the interim, there may be security implications related to a composer modifying tuples, and this also relates to another discussion on as to how for example geoloc information is applied to a presence document. Is it a separate tuple or part of other tuples. Even when answering "yes" to (1), (2) would most probably still be needed because of the reasons you point out. I could imagine that for some other event segments, such a definition of "semantically identical" could be relatively straight forward. However, with presence it may not be so simple. Any thoughts on this? Cheers, Aki > -----Original Message----- > From: ext Thanos Diacakis [mailto:thanos.diacakis@openwave.com] > Sent: 05 June, 2003 19:56 > To: Niemi Aki (NMP/Helsinki); simple@ietf.org > Subject: Re: [Simple] PUBLISH: identification of presence segments > > > Hi Aki, > > (I'm assuming you're referring to the presence aggregation problem) > > I think I remember the consensus being along those lines, > but I'm not sure > this will work. Here's why... > > Recap: If two entities (say P1 and P2) are publishing presence for a > particular presentity, that include two semantically > identical tuples, it is > hard for them to co-ordinate the tuple-ids. By > "semantically identical" I > mean they contain information about the same segment of state. > > The assumption I think that we were working on is that P1 > will first publish > a tuple T1 with tuple ID, say X1. P2 will be a subscriber to this > information, and will have a way to figure out that the > tuple T1 with ID X1 > is "semantically identically" to the tuple it wants to > publish (ignoring > that this is not trivial), and thus P2 will publish a tuple > T2 with ID X1. > The aggregator at the Presence Service will then replace T2 > with T1 (subject > to the other mechanism we're discussing). > > Now the first problem is that if P1 and P2 simultaneously > decide to publish > T1 and T2 respectively, they will each assign unique ids to > two tuples that > are semantically the same. To solve this we need to have a > central entity > that can identify tuples that are "semantically identical" , > and there are > some ways of doing so. > > The second problem is that this mechanism relies on the tuples being > published having the same ID as the tuples in notifications. This is > possible in some simple cases, but won't work when the > presence information > being notified is based upon (but not verbatim copies) of > the presence being > published. For example, if a particular presence > implementation takes > tuples A and B, does some complex calculation and publishes > tuple C, then we > have a problem as there is no direct way to map tuple IDs between the > publish and notify operations. (This also affects the > versioning mechanism, > as you may no longer assume that P1 and P2 can see all > aspects of what each > other is doing) > > Thanos > --- > Thanos Diacakis > Openwave Systems > thanos.diacakis@openwave.com > +1-303 385 6705 > > ----- Original Message ----- > From: > To: > Sent: Thursday, June 05, 2003 9:25 AM > Subject: [Simple] PUBLISH: identification of presence segments > > > > Hi All, > > > > One of the open issues in the PUBLISH work is how to > identify specific > segments of state. Each event is supposed to define a way to > identify a > specific segment. So far, we've decided that in presence > publication, a > tuple corresponds to such a segment. > > > > I think the conclusion we arrived at in the interim > meeting was that tuple > IDs would be used to identiy a specific presence tuple > instead of the RPIDS > label-element. > > > > Just making sure this was the consensus. Anyone against? > > > > Cheers, > > Aki > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > > > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Fri Jun 6 09:01:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21968 for ; Fri, 6 Jun 2003 09:01:12 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h56D0jt21033 for simple-archive@odin.ietf.org; Fri, 6 Jun 2003 09:00:45 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56D0jB21030 for ; Fri, 6 Jun 2003 09:00: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 JAA21935; Fri, 6 Jun 2003 09:00:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OGnw-0001n7-00; Fri, 06 Jun 2003 08:58:48 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19OGnv-0001n4-00; Fri, 06 Jun 2003 08:58:47 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56CvMB20904; Fri, 6 Jun 2003 08:57:22 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56CuWB20866 for ; Fri, 6 Jun 2003 08:56:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21843 for ; Fri, 6 Jun 2003 08:56:28 -0400 (EDT) From: aki.niemi@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OGjr-0001lS-00 for simple@ietf.org; Fri, 06 Jun 2003 08:54:35 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19OGjq-0001lP-00 for simple@ietf.org; Fri, 06 Jun 2003 08:54:34 -0400 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h56CuRD10727 for ; Fri, 6 Jun 2003 15:56:27 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 6 Jun 2003 15:56:27 +0300 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 6 Jun 2003 15:56:27 +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" Subject: RE: [Simple] PUBLISH: identification of presence segments Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9019452B6@esebe013.ntc.nokia.com> Thread-Topic: [Simple] PUBLISH: identification of presence segments Thread-Index: AcMrg2qSkM3Av3+6SlahjiuITK+g+QAkHEQg To: , X-OriginalArrivalTime: 06 Jun 2003 12:56:27.0153 (UTC) FILETIME=[0AB7A810:01C32C2B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h56CuWB20867 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, 6 Jun 2003 15:56:26 +0300 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi Thanos, I think you are right in that using the tuple ID makes the assumption that the composer never merges or modifies the individual tuples, so that the ID is carried over to the watchers intact. You also touch on a very interesting related topic of how to identify two "semantically identical" presence segments. Since the tuple IDs are generated at the source of presence information, it could be so that two sources publish the same presence segment using a different ID. In this case, the composer would need to know that the segments are in fact two representations of the same presence segment, and instead of composing them both in the presence document it should only use the most recent one of the two (and indicate a collision to the publisher of the stale one). I think the only use case we considered in the interim was one where a user goes home, sees that her work PC is still publishing OPEN IM status, and needs to "steal" that particular publication away from the work PC. In this scenario, merely knowing the tuple ID would suffice. So we have two issues to resolve: (1) Can we restrict the composer so that published tuples are never merged or modified? (2) Can we define a way for the composer (and EPAs as well) to identify "semantically identical" tuples when they have different IDs? I think (1) has a more wider scope that deals with the models we have envisioned for presence composition. As was also stated in the interim, there may be security implications related to a composer modifying tuples, and this also relates to another discussion on as to how for example geoloc information is applied to a presence document. Is it a separate tuple or part of other tuples. Even when answering "yes" to (1), (2) would most probably still be needed because of the reasons you point out. I could imagine that for some other event segments, such a definition of "semantically identical" could be relatively straight forward. However, with presence it may not be so simple. Any thoughts on this? Cheers, Aki > -----Original Message----- > From: ext Thanos Diacakis [mailto:thanos.diacakis@openwave.com] > Sent: 05 June, 2003 19:56 > To: Niemi Aki (NMP/Helsinki); simple@ietf.org > Subject: Re: [Simple] PUBLISH: identification of presence segments > > > Hi Aki, > > (I'm assuming you're referring to the presence aggregation problem) > > I think I remember the consensus being along those lines, > but I'm not sure > this will work. Here's why... > > Recap: If two entities (say P1 and P2) are publishing presence for a > particular presentity, that include two semantically > identical tuples, it is > hard for them to co-ordinate the tuple-ids. By > "semantically identical" I > mean they contain information about the same segment of state. > > The assumption I think that we were working on is that P1 > will first publish > a tuple T1 with tuple ID, say X1. P2 will be a subscriber to this > information, and will have a way to figure out that the > tuple T1 with ID X1 > is "semantically identically" to the tuple it wants to > publish (ignoring > that this is not trivial), and thus P2 will publish a tuple > T2 with ID X1. > The aggregator at the Presence Service will then replace T2 > with T1 (subject > to the other mechanism we're discussing). > > Now the first problem is that if P1 and P2 simultaneously > decide to publish > T1 and T2 respectively, they will each assign unique ids to > two tuples that > are semantically the same. To solve this we need to have a > central entity > that can identify tuples that are "semantically identical" , > and there are > some ways of doing so. > > The second problem is that this mechanism relies on the tuples being > published having the same ID as the tuples in notifications. This is > possible in some simple cases, but won't work when the > presence information > being notified is based upon (but not verbatim copies) of > the presence being > published. For example, if a particular presence > implementation takes > tuples A and B, does some complex calculation and publishes > tuple C, then we > have a problem as there is no direct way to map tuple IDs between the > publish and notify operations. (This also affects the > versioning mechanism, > as you may no longer assume that P1 and P2 can see all > aspects of what each > other is doing) > > Thanos > --- > Thanos Diacakis > Openwave Systems > thanos.diacakis@openwave.com > +1-303 385 6705 > > ----- Original Message ----- > From: > To: > Sent: Thursday, June 05, 2003 9:25 AM > Subject: [Simple] PUBLISH: identification of presence segments > > > > Hi All, > > > > One of the open issues in the PUBLISH work is how to > identify specific > segments of state. Each event is supposed to define a way to > identify a > specific segment. So far, we've decided that in presence > publication, a > tuple corresponds to such a segment. > > > > I think the conclusion we arrived at in the interim > meeting was that tuple > IDs would be used to identiy a specific presence tuple > instead of the RPIDS > label-element. > > > > Just making sure this was the consensus. Anyone against? > > > > Cheers, > > Aki > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > > > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Jun 6 10:10:32 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 KAA24855; Fri, 6 Jun 2003 10:10:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OHtX-0002Ox-00; Fri, 06 Jun 2003 10:08:39 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19OHtX-0002Ou-00; Fri, 06 Jun 2003 10:08:39 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56E7CB26029; Fri, 6 Jun 2003 10:07:12 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56E61B25778 for ; Fri, 6 Jun 2003 10:06:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24355 for ; Fri, 6 Jun 2003 10:05:55 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OHp4-0002Ml-00 for simple@ietf.org; Fri, 06 Jun 2003 10:04:02 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19OHp4-0002Mi-00 for simple@ietf.org; Fri, 06 Jun 2003 10:04:02 -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 h56E5tW19417 for ; Fri, 6 Jun 2003 17:05:55 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 6 Jun 2003 17:05:54 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 6 Jun 2003 17:05:54 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 6 Jun 2003 17:05:54 +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" Subject: RE: [Simple] PUBLISH: identification of presence segments Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701796D4D@esebe019.ntc.nokia.com> Thread-Topic: [Simple] PUBLISH: identification of presence segments Thread-Index: AcMrg2qSkM3Av3+6SlahjiuITK+g+QAkHEQgAAePb6A= To: , , X-OriginalArrivalTime: 06 Jun 2003 14:05:54.0376 (UTC) FILETIME=[BE936C80:01C32C34] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h56E61B25779 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, 6 Jun 2003 17:05:53 +0300 Content-Transfer-Encoding: 8bit We need something to identify not just the tuple in which the user wants to override from a terminal that doesn't own that tuple, but aspects within the tuple. Imagine I have a device D1 (office PC) that publishes one device tuple T1 that describes all the services available in that device (IM, voice, video). Now I go home and only want to override the part of the device tuple T1 describing the IM, using my home device D2. I therefore have to publish a new tuple T2 from D2 that is just related to the part of the old tuple T1. The compositor has to relate the 2 tuples somehow. A solution for this is to mandate that no matter what part of the tuple a second device wants to modify from a second terminal, that second device MUST publish the whole tuple again. This makes it easier for the compositor in that it just replaces the original tuple instead of trying to compose T2 into parts of T1. Having said that, the problem stays: How do you relate those 2 tuples, especially since the compositor can create tuple-ids on its own when composing separate tuples into one. Can a human be involved in this? The human sets ids or keywords for services, devices or whatever s/he is publishing presence for. Taking the example above: When I publish from work, I give unique Ids to IM, voice, and video (office-pc-im, office-pc-voice, office-pc-video, respectively) that I know about and remember. Regardless of how the implementation in the terminal interprets those and puts them in a tuples (one tuple or 3), I have now uniquely identified things for myself. When I go home and want to override my IM that I published from work, I input the id office-pc-im before I publish. I haven't thought about the proposal too much, just thinking aloud, so don't hose me :) Regards, Hisham > -----Original Message----- > From: ext aki.niemi@nokia.com [mailto:aki.niemi@nokia.com] > Sent: Friday, June 06, 2003 3:56 PM > To: thanos.diacakis@openwave.com; simple@ietf.org > Subject: RE: [Simple] PUBLISH: identification of presence segments > > > Hi Thanos, > > I think you are right in that using the tuple ID makes the > assumption that the composer never merges or modifies the > individual tuples, so that the ID is carried over to the > watchers intact. > > You also touch on a very interesting related topic of how to > identify two "semantically identical" presence segments. > Since the tuple IDs are generated at the source of presence > information, it could be so that two sources publish the same > presence segment using a different ID. > > In this case, the composer would need to know that the > segments are in fact two representations of the same presence > segment, and instead of composing them both in the presence > document it should only use the most recent one of the two > (and indicate a collision to the publisher of the stale one). > > I think the only use case we considered in the interim was > one where a user goes home, sees that her work PC is still > publishing OPEN IM status, and needs to "steal" that > particular publication away from the work PC. In this > scenario, merely knowing the tuple ID would suffice. > > So we have two issues to resolve: > (1) Can we restrict the composer so that published tuples are > never merged > or modified? > > (2) Can we define a way for the composer (and EPAs as well) > to identify > "semantically identical" tuples when they have different IDs? > > I think (1) has a more wider scope that deals with the models > we have envisioned for presence composition. As was also > stated in the interim, there may be security implications > related to a composer modifying tuples, and this also relates > to another discussion on as to how for example geoloc > information is applied to a presence document. Is it a > separate tuple or part of other tuples. > > Even when answering "yes" to (1), (2) would most probably > still be needed because of the reasons you point out. I could > imagine that for some other event segments, such a definition > of "semantically identical" could be relatively straight > forward. However, with presence it may not be so simple. > > Any thoughts on this? > > Cheers, > Aki > > > -----Original Message----- > > From: ext Thanos Diacakis [mailto:thanos.diacakis@openwave.com] > > Sent: 05 June, 2003 19:56 > > To: Niemi Aki (NMP/Helsinki); simple@ietf.org > > Subject: Re: [Simple] PUBLISH: identification of presence segments > > > > > > Hi Aki, > > > > (I'm assuming you're referring to the presence aggregation problem) > > > > I think I remember the consensus being along those lines, > > but I'm not sure > > this will work. Here's why... > > > > Recap: If two entities (say P1 and P2) are publishing > presence for a > > particular presentity, that include two semantically > > identical tuples, it is > > hard for them to co-ordinate the tuple-ids. By > > "semantically identical" I > > mean they contain information about the same segment of state. > > > > The assumption I think that we were working on is that P1 > > will first publish > > a tuple T1 with tuple ID, say X1. P2 will be a subscriber to this > > information, and will have a way to figure out that the > > tuple T1 with ID X1 > > is "semantically identically" to the tuple it wants to > > publish (ignoring > > that this is not trivial), and thus P2 will publish a tuple > > T2 with ID X1. > > The aggregator at the Presence Service will then replace T2 > > with T1 (subject > > to the other mechanism we're discussing). > > > > Now the first problem is that if P1 and P2 simultaneously > > decide to publish > > T1 and T2 respectively, they will each assign unique ids to > > two tuples that > > are semantically the same. To solve this we need to have a > > central entity > > that can identify tuples that are "semantically identical" , > > and there are > > some ways of doing so. > > > > The second problem is that this mechanism relies on the > tuples being > > published having the same ID as the tuples in > notifications. This is > > possible in some simple cases, but won't work when the > > presence information > > being notified is based upon (but not verbatim copies) of > > the presence being > > published. For example, if a particular presence > > implementation takes > > tuples A and B, does some complex calculation and publishes > > tuple C, then we > > have a problem as there is no direct way to map tuple IDs > between the > > publish and notify operations. (This also affects the > > versioning mechanism, > > as you may no longer assume that P1 and P2 can see all > > aspects of what each > > other is doing) > > > > Thanos > > --- > > Thanos Diacakis > > Openwave Systems > > thanos.diacakis@openwave.com > > +1-303 385 6705 > > > > ----- Original Message ----- > > From: > > To: > > Sent: Thursday, June 05, 2003 9:25 AM > > Subject: [Simple] PUBLISH: identification of presence segments > > > > > > > Hi All, > > > > > > One of the open issues in the PUBLISH work is how to > > identify specific > > segments of state. Each event is supposed to define a way to > > identify a > > specific segment. So far, we've decided that in presence > > publication, a > > tuple corresponds to such a segment. > > > > > > I think the conclusion we arrived at in the interim > > meeting was that tuple > > IDs would be used to identiy a specific presence tuple > > instead of the RPIDS > > label-element. > > > > > > Just making sure this was the consensus. Anyone against? > > > > > > Cheers, > > > Aki > > > _______________________________________________ > > > Simple mailing list > > > Simple@ietf.org > > > https://www1.ietf.org/mailman/listinfo/simple > > > > > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Fri Jun 6 10:11:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24927 for ; Fri, 6 Jun 2003 10:11:03 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h56EAcF26914 for simple-archive@odin.ietf.org; Fri, 6 Jun 2003 10:10:38 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56EAcB26911 for ; Fri, 6 Jun 2003 10:10: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 KAA24855; Fri, 6 Jun 2003 10:10:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OHtX-0002Ox-00; Fri, 06 Jun 2003 10:08:39 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19OHtX-0002Ou-00; Fri, 06 Jun 2003 10:08:39 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56E7CB26029; Fri, 6 Jun 2003 10:07:12 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56E61B25778 for ; Fri, 6 Jun 2003 10:06:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24355 for ; Fri, 6 Jun 2003 10:05:55 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OHp4-0002Ml-00 for simple@ietf.org; Fri, 06 Jun 2003 10:04:02 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19OHp4-0002Mi-00 for simple@ietf.org; Fri, 06 Jun 2003 10:04:02 -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 h56E5tW19417 for ; Fri, 6 Jun 2003 17:05:55 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 6 Jun 2003 17:05:54 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 6 Jun 2003 17:05:54 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 6 Jun 2003 17:05:54 +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" Subject: RE: [Simple] PUBLISH: identification of presence segments Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701796D4D@esebe019.ntc.nokia.com> Thread-Topic: [Simple] PUBLISH: identification of presence segments Thread-Index: AcMrg2qSkM3Av3+6SlahjiuITK+g+QAkHEQgAAePb6A= To: , , X-OriginalArrivalTime: 06 Jun 2003 14:05:54.0376 (UTC) FILETIME=[BE936C80:01C32C34] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h56E61B25779 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, 6 Jun 2003 17:05:53 +0300 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit We need something to identify not just the tuple in which the user wants to override from a terminal that doesn't own that tuple, but aspects within the tuple. Imagine I have a device D1 (office PC) that publishes one device tuple T1 that describes all the services available in that device (IM, voice, video). Now I go home and only want to override the part of the device tuple T1 describing the IM, using my home device D2. I therefore have to publish a new tuple T2 from D2 that is just related to the part of the old tuple T1. The compositor has to relate the 2 tuples somehow. A solution for this is to mandate that no matter what part of the tuple a second device wants to modify from a second terminal, that second device MUST publish the whole tuple again. This makes it easier for the compositor in that it just replaces the original tuple instead of trying to compose T2 into parts of T1. Having said that, the problem stays: How do you relate those 2 tuples, especially since the compositor can create tuple-ids on its own when composing separate tuples into one. Can a human be involved in this? The human sets ids or keywords for services, devices or whatever s/he is publishing presence for. Taking the example above: When I publish from work, I give unique Ids to IM, voice, and video (office-pc-im, office-pc-voice, office-pc-video, respectively) that I know about and remember. Regardless of how the implementation in the terminal interprets those and puts them in a tuples (one tuple or 3), I have now uniquely identified things for myself. When I go home and want to override my IM that I published from work, I input the id office-pc-im before I publish. I haven't thought about the proposal too much, just thinking aloud, so don't hose me :) Regards, Hisham > -----Original Message----- > From: ext aki.niemi@nokia.com [mailto:aki.niemi@nokia.com] > Sent: Friday, June 06, 2003 3:56 PM > To: thanos.diacakis@openwave.com; simple@ietf.org > Subject: RE: [Simple] PUBLISH: identification of presence segments > > > Hi Thanos, > > I think you are right in that using the tuple ID makes the > assumption that the composer never merges or modifies the > individual tuples, so that the ID is carried over to the > watchers intact. > > You also touch on a very interesting related topic of how to > identify two "semantically identical" presence segments. > Since the tuple IDs are generated at the source of presence > information, it could be so that two sources publish the same > presence segment using a different ID. > > In this case, the composer would need to know that the > segments are in fact two representations of the same presence > segment, and instead of composing them both in the presence > document it should only use the most recent one of the two > (and indicate a collision to the publisher of the stale one). > > I think the only use case we considered in the interim was > one where a user goes home, sees that her work PC is still > publishing OPEN IM status, and needs to "steal" that > particular publication away from the work PC. In this > scenario, merely knowing the tuple ID would suffice. > > So we have two issues to resolve: > (1) Can we restrict the composer so that published tuples are > never merged > or modified? > > (2) Can we define a way for the composer (and EPAs as well) > to identify > "semantically identical" tuples when they have different IDs? > > I think (1) has a more wider scope that deals with the models > we have envisioned for presence composition. As was also > stated in the interim, there may be security implications > related to a composer modifying tuples, and this also relates > to another discussion on as to how for example geoloc > information is applied to a presence document. Is it a > separate tuple or part of other tuples. > > Even when answering "yes" to (1), (2) would most probably > still be needed because of the reasons you point out. I could > imagine that for some other event segments, such a definition > of "semantically identical" could be relatively straight > forward. However, with presence it may not be so simple. > > Any thoughts on this? > > Cheers, > Aki > > > -----Original Message----- > > From: ext Thanos Diacakis [mailto:thanos.diacakis@openwave.com] > > Sent: 05 June, 2003 19:56 > > To: Niemi Aki (NMP/Helsinki); simple@ietf.org > > Subject: Re: [Simple] PUBLISH: identification of presence segments > > > > > > Hi Aki, > > > > (I'm assuming you're referring to the presence aggregation problem) > > > > I think I remember the consensus being along those lines, > > but I'm not sure > > this will work. Here's why... > > > > Recap: If two entities (say P1 and P2) are publishing > presence for a > > particular presentity, that include two semantically > > identical tuples, it is > > hard for them to co-ordinate the tuple-ids. By > > "semantically identical" I > > mean they contain information about the same segment of state. > > > > The assumption I think that we were working on is that P1 > > will first publish > > a tuple T1 with tuple ID, say X1. P2 will be a subscriber to this > > information, and will have a way to figure out that the > > tuple T1 with ID X1 > > is "semantically identically" to the tuple it wants to > > publish (ignoring > > that this is not trivial), and thus P2 will publish a tuple > > T2 with ID X1. > > The aggregator at the Presence Service will then replace T2 > > with T1 (subject > > to the other mechanism we're discussing). > > > > Now the first problem is that if P1 and P2 simultaneously > > decide to publish > > T1 and T2 respectively, they will each assign unique ids to > > two tuples that > > are semantically the same. To solve this we need to have a > > central entity > > that can identify tuples that are "semantically identical" , > > and there are > > some ways of doing so. > > > > The second problem is that this mechanism relies on the > tuples being > > published having the same ID as the tuples in > notifications. This is > > possible in some simple cases, but won't work when the > > presence information > > being notified is based upon (but not verbatim copies) of > > the presence being > > published. For example, if a particular presence > > implementation takes > > tuples A and B, does some complex calculation and publishes > > tuple C, then we > > have a problem as there is no direct way to map tuple IDs > between the > > publish and notify operations. (This also affects the > > versioning mechanism, > > as you may no longer assume that P1 and P2 can see all > > aspects of what each > > other is doing) > > > > Thanos > > --- > > Thanos Diacakis > > Openwave Systems > > thanos.diacakis@openwave.com > > +1-303 385 6705 > > > > ----- Original Message ----- > > From: > > To: > > Sent: Thursday, June 05, 2003 9:25 AM > > Subject: [Simple] PUBLISH: identification of presence segments > > > > > > > Hi All, > > > > > > One of the open issues in the PUBLISH work is how to > > identify specific > > segments of state. Each event is supposed to define a way to > > identify a > > specific segment. So far, we've decided that in presence > > publication, a > > tuple corresponds to such a segment. > > > > > > I think the conclusion we arrived at in the interim > > meeting was that tuple > > IDs would be used to identiy a specific presence tuple > > instead of the RPIDS > > label-element. > > > > > > Just making sure this was the consensus. Anyone against? > > > > > > Cheers, > > > Aki > > > _______________________________________________ > > > Simple mailing list > > > Simple@ietf.org > > > https://www1.ietf.org/mailman/listinfo/simple > > > > > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Jun 6 12:03:48 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 MAA00017; Fri, 6 Jun 2003 12:03:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OJfA-0003VT-00; Fri, 06 Jun 2003 12:01:56 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19OJf9-0003VQ-00; Fri, 06 Jun 2003 12:01:55 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56G0NB03837; Fri, 6 Jun 2003 12:00:23 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56Fx8B03718 for ; Fri, 6 Jun 2003 11:59: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 LAA29740 for ; Fri, 6 Jun 2003 11:59:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OJaa-0003R5-00 for simple@ietf.org; Fri, 06 Jun 2003 11:57:12 -0400 Received: from oe-im1pub.managedmail.com ([206.46.164.52] helo=oe-im1.bizmailsrvcs.net) by ietf-mx with esmtp (Exim 4.12) id 19OJaa-0003QU-00 for simple@ietf.org; Fri, 06 Jun 2003 11:57:12 -0400 Received: from oe-ismta1.bizmailsrvcs.net ([206.46.164.26]) by oe-im1.bizmailsrvcs.net (InterMail vM.5.01.05.27 201-253-122-126-127-20021220) with ESMTP id <20030606155835.TODH2597.oe-im1.bizmailsrvcs.net@oe-ismta1.bizmailsrvcs.net>; Fri, 6 Jun 2003 10:58:35 -0500 Received: from tdiacakis ([63.67.207.249]) by oe-ismta1.bizmailsrvcs.net (InterMail vM.5.01.05.27 201-253-122-126-127-20021220) with SMTP id <20030606155830.VWLF6261.oe-ismta1.bizmailsrvcs.net@tdiacakis>; Fri, 6 Jun 2003 10:58:30 -0500 Message-ID: <06a501c32c44$79624ef0$05071e0a@myopwv.com> From: "Thanos Diacakis" To: , References: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9019452B6@esebe013.ntc.nokia.com> Subject: Re: [Simple] PUBLISH: identification of presence segments MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 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, 6 Jun 2003 09:58:04 -0600 Content-Transfer-Encoding: 7bit Hi Aki, On your two issues: (1) I don't think we can assume that tuples are never to be merged or modified (or split out for that matter). The easiest use case for this is when one wants to lie, which means that the tuples contents need to be changed for some subscriber or group of subscribers. A different use case could be something along the lines of a "rule" in the presence server saying "if my IM at work is open, publish my work phone # tuple". In this case, one tuple triggers the publication of another tuple, but the first tuple never gets out. My broader point is that by allowing the transformation of tuples you enable a rich set of presence functionality, whereas if you mandate that tuples need to go through the presence service intact, then you've dumbed down the service to an unacceptable level, where no cool features can be added. (2) I totally agree here and this is related to the "what is a tuple" discussion, so we should take this into consideration when having the "what is a tuple" discussion. Thanos --- Thanos Diacakis Openwave Systems thanos.diacakis@openwave.com +1-303 385 6705 ----- Original Message ----- From: To: ; Sent: Friday, June 06, 2003 6:56 AM Subject: RE: [Simple] PUBLISH: identification of presence segments > Hi Thanos, > > I think you are right in that using the tuple ID makes the assumption that the composer never merges or modifies the individual tuples, so that the ID is carried over to the watchers intact. > > You also touch on a very interesting related topic of how to identify two "semantically identical" presence segments. Since the tuple IDs are generated at the source of presence information, it could be so that two sources publish the same presence segment using a different ID. > > In this case, the composer would need to know that the segments are in fact two representations of the same presence segment, and instead of composing them both in the presence document it should only use the most recent one of the two (and indicate a collision to the publisher of the stale one). > > I think the only use case we considered in the interim was one where a user goes home, sees that her work PC is still publishing OPEN IM status, and needs to "steal" that particular publication away from the work PC. In this scenario, merely knowing the tuple ID would suffice. > > So we have two issues to resolve: > (1) Can we restrict the composer so that published tuples are never merged > or modified? > > (2) Can we define a way for the composer (and EPAs as well) to identify > "semantically identical" tuples when they have different IDs? > > I think (1) has a more wider scope that deals with the models we have envisioned for presence composition. As was also stated in the interim, there may be security implications related to a composer modifying tuples, and this also relates to another discussion on as to how for example geoloc information is applied to a presence document. Is it a separate tuple or part of other tuples. > > Even when answering "yes" to (1), (2) would most probably still be needed because of the reasons you point out. I could imagine that for some other event segments, such a definition of "semantically identical" could be relatively straight forward. However, with presence it may not be so simple. > > Any thoughts on this? > > Cheers, > Aki > > > -----Original Message----- > > From: ext Thanos Diacakis [mailto:thanos.diacakis@openwave.com] > > Sent: 05 June, 2003 19:56 > > To: Niemi Aki (NMP/Helsinki); simple@ietf.org > > Subject: Re: [Simple] PUBLISH: identification of presence segments > > > > > > Hi Aki, > > > > (I'm assuming you're referring to the presence aggregation problem) > > > > I think I remember the consensus being along those lines, > > but I'm not sure > > this will work. Here's why... > > > > Recap: If two entities (say P1 and P2) are publishing presence for a > > particular presentity, that include two semantically > > identical tuples, it is > > hard for them to co-ordinate the tuple-ids. By > > "semantically identical" I > > mean they contain information about the same segment of state. > > > > The assumption I think that we were working on is that P1 > > will first publish > > a tuple T1 with tuple ID, say X1. P2 will be a subscriber to this > > information, and will have a way to figure out that the > > tuple T1 with ID X1 > > is "semantically identically" to the tuple it wants to > > publish (ignoring > > that this is not trivial), and thus P2 will publish a tuple > > T2 with ID X1. > > The aggregator at the Presence Service will then replace T2 > > with T1 (subject > > to the other mechanism we're discussing). > > > > Now the first problem is that if P1 and P2 simultaneously > > decide to publish > > T1 and T2 respectively, they will each assign unique ids to > > two tuples that > > are semantically the same. To solve this we need to have a > > central entity > > that can identify tuples that are "semantically identical" , > > and there are > > some ways of doing so. > > > > The second problem is that this mechanism relies on the tuples being > > published having the same ID as the tuples in notifications. This is > > possible in some simple cases, but won't work when the > > presence information > > being notified is based upon (but not verbatim copies) of > > the presence being > > published. For example, if a particular presence > > implementation takes > > tuples A and B, does some complex calculation and publishes > > tuple C, then we > > have a problem as there is no direct way to map tuple IDs between the > > publish and notify operations. (This also affects the > > versioning mechanism, > > as you may no longer assume that P1 and P2 can see all > > aspects of what each > > other is doing) > > > > Thanos > > --- > > Thanos Diacakis > > Openwave Systems > > thanos.diacakis@openwave.com > > +1-303 385 6705 > > > > ----- Original Message ----- > > From: > > To: > > Sent: Thursday, June 05, 2003 9:25 AM > > Subject: [Simple] PUBLISH: identification of presence segments > > > > > > > Hi All, > > > > > > One of the open issues in the PUBLISH work is how to > > identify specific > > segments of state. Each event is supposed to define a way to > > identify a > > specific segment. So far, we've decided that in presence > > publication, a > > tuple corresponds to such a segment. > > > > > > I think the conclusion we arrived at in the interim > > meeting was that tuple > > IDs would be used to identiy a specific presence tuple > > instead of the RPIDS > > label-element. > > > > > > Just making sure this was the consensus. Anyone against? > > > > > > Cheers, > > > Aki > > > _______________________________________________ > > > Simple mailing list > > > Simple@ietf.org > > > https://www1.ietf.org/mailman/listinfo/simple > > > > > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Fri Jun 6 12:04:19 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00064 for ; Fri, 6 Jun 2003 12:04:19 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h56G3rA04134 for simple-archive@odin.ietf.org; Fri, 6 Jun 2003 12:03:53 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56G3rB04131 for ; Fri, 6 Jun 2003 12:03:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00017; Fri, 6 Jun 2003 12:03:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OJfA-0003VT-00; Fri, 06 Jun 2003 12:01:56 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19OJf9-0003VQ-00; Fri, 06 Jun 2003 12:01:55 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56G0NB03837; Fri, 6 Jun 2003 12:00:23 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56Fx8B03718 for ; Fri, 6 Jun 2003 11:59: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 LAA29740 for ; Fri, 6 Jun 2003 11:59:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OJaa-0003R5-00 for simple@ietf.org; Fri, 06 Jun 2003 11:57:12 -0400 Received: from oe-im1pub.managedmail.com ([206.46.164.52] helo=oe-im1.bizmailsrvcs.net) by ietf-mx with esmtp (Exim 4.12) id 19OJaa-0003QU-00 for simple@ietf.org; Fri, 06 Jun 2003 11:57:12 -0400 Received: from oe-ismta1.bizmailsrvcs.net ([206.46.164.26]) by oe-im1.bizmailsrvcs.net (InterMail vM.5.01.05.27 201-253-122-126-127-20021220) with ESMTP id <20030606155835.TODH2597.oe-im1.bizmailsrvcs.net@oe-ismta1.bizmailsrvcs.net>; Fri, 6 Jun 2003 10:58:35 -0500 Received: from tdiacakis ([63.67.207.249]) by oe-ismta1.bizmailsrvcs.net (InterMail vM.5.01.05.27 201-253-122-126-127-20021220) with SMTP id <20030606155830.VWLF6261.oe-ismta1.bizmailsrvcs.net@tdiacakis>; Fri, 6 Jun 2003 10:58:30 -0500 Message-ID: <06a501c32c44$79624ef0$05071e0a@myopwv.com> From: "Thanos Diacakis" To: , References: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9019452B6@esebe013.ntc.nokia.com> Subject: Re: [Simple] PUBLISH: identification of presence segments MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 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, 6 Jun 2003 09:58:04 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Aki, On your two issues: (1) I don't think we can assume that tuples are never to be merged or modified (or split out for that matter). The easiest use case for this is when one wants to lie, which means that the tuples contents need to be changed for some subscriber or group of subscribers. A different use case could be something along the lines of a "rule" in the presence server saying "if my IM at work is open, publish my work phone # tuple". In this case, one tuple triggers the publication of another tuple, but the first tuple never gets out. My broader point is that by allowing the transformation of tuples you enable a rich set of presence functionality, whereas if you mandate that tuples need to go through the presence service intact, then you've dumbed down the service to an unacceptable level, where no cool features can be added. (2) I totally agree here and this is related to the "what is a tuple" discussion, so we should take this into consideration when having the "what is a tuple" discussion. Thanos --- Thanos Diacakis Openwave Systems thanos.diacakis@openwave.com +1-303 385 6705 ----- Original Message ----- From: To: ; Sent: Friday, June 06, 2003 6:56 AM Subject: RE: [Simple] PUBLISH: identification of presence segments > Hi Thanos, > > I think you are right in that using the tuple ID makes the assumption that the composer never merges or modifies the individual tuples, so that the ID is carried over to the watchers intact. > > You also touch on a very interesting related topic of how to identify two "semantically identical" presence segments. Since the tuple IDs are generated at the source of presence information, it could be so that two sources publish the same presence segment using a different ID. > > In this case, the composer would need to know that the segments are in fact two representations of the same presence segment, and instead of composing them both in the presence document it should only use the most recent one of the two (and indicate a collision to the publisher of the stale one). > > I think the only use case we considered in the interim was one where a user goes home, sees that her work PC is still publishing OPEN IM status, and needs to "steal" that particular publication away from the work PC. In this scenario, merely knowing the tuple ID would suffice. > > So we have two issues to resolve: > (1) Can we restrict the composer so that published tuples are never merged > or modified? > > (2) Can we define a way for the composer (and EPAs as well) to identify > "semantically identical" tuples when they have different IDs? > > I think (1) has a more wider scope that deals with the models we have envisioned for presence composition. As was also stated in the interim, there may be security implications related to a composer modifying tuples, and this also relates to another discussion on as to how for example geoloc information is applied to a presence document. Is it a separate tuple or part of other tuples. > > Even when answering "yes" to (1), (2) would most probably still be needed because of the reasons you point out. I could imagine that for some other event segments, such a definition of "semantically identical" could be relatively straight forward. However, with presence it may not be so simple. > > Any thoughts on this? > > Cheers, > Aki > > > -----Original Message----- > > From: ext Thanos Diacakis [mailto:thanos.diacakis@openwave.com] > > Sent: 05 June, 2003 19:56 > > To: Niemi Aki (NMP/Helsinki); simple@ietf.org > > Subject: Re: [Simple] PUBLISH: identification of presence segments > > > > > > Hi Aki, > > > > (I'm assuming you're referring to the presence aggregation problem) > > > > I think I remember the consensus being along those lines, > > but I'm not sure > > this will work. Here's why... > > > > Recap: If two entities (say P1 and P2) are publishing presence for a > > particular presentity, that include two semantically > > identical tuples, it is > > hard for them to co-ordinate the tuple-ids. By > > "semantically identical" I > > mean they contain information about the same segment of state. > > > > The assumption I think that we were working on is that P1 > > will first publish > > a tuple T1 with tuple ID, say X1. P2 will be a subscriber to this > > information, and will have a way to figure out that the > > tuple T1 with ID X1 > > is "semantically identically" to the tuple it wants to > > publish (ignoring > > that this is not trivial), and thus P2 will publish a tuple > > T2 with ID X1. > > The aggregator at the Presence Service will then replace T2 > > with T1 (subject > > to the other mechanism we're discussing). > > > > Now the first problem is that if P1 and P2 simultaneously > > decide to publish > > T1 and T2 respectively, they will each assign unique ids to > > two tuples that > > are semantically the same. To solve this we need to have a > > central entity > > that can identify tuples that are "semantically identical" , > > and there are > > some ways of doing so. > > > > The second problem is that this mechanism relies on the tuples being > > published having the same ID as the tuples in notifications. This is > > possible in some simple cases, but won't work when the > > presence information > > being notified is based upon (but not verbatim copies) of > > the presence being > > published. For example, if a particular presence > > implementation takes > > tuples A and B, does some complex calculation and publishes > > tuple C, then we > > have a problem as there is no direct way to map tuple IDs between the > > publish and notify operations. (This also affects the > > versioning mechanism, > > as you may no longer assume that P1 and P2 can see all > > aspects of what each > > other is doing) > > > > Thanos > > --- > > Thanos Diacakis > > Openwave Systems > > thanos.diacakis@openwave.com > > +1-303 385 6705 > > > > ----- Original Message ----- > > From: > > To: > > Sent: Thursday, June 05, 2003 9:25 AM > > Subject: [Simple] PUBLISH: identification of presence segments > > > > > > > Hi All, > > > > > > One of the open issues in the PUBLISH work is how to > > identify specific > > segments of state. Each event is supposed to define a way to > > identify a > > specific segment. So far, we've decided that in presence > > publication, a > > tuple corresponds to such a segment. > > > > > > I think the conclusion we arrived at in the interim > > meeting was that tuple > > IDs would be used to identiy a specific presence tuple > > instead of the RPIDS > > label-element. > > > > > > Just making sure this was the consensus. Anyone against? > > > > > > Cheers, > > > Aki > > > _______________________________________________ > > > Simple mailing list > > > Simple@ietf.org > > > https://www1.ietf.org/mailman/listinfo/simple > > > > > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Jun 6 12:16:28 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 MAA00840; Fri, 6 Jun 2003 12:16:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OJrQ-0003iJ-00; Fri, 06 Jun 2003 12:14:36 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19OJrP-0003iG-00; Fri, 06 Jun 2003 12:14:35 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56GDAB06180; Fri, 6 Jun 2003 12:13:10 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56G6BB04288 for ; Fri, 6 Jun 2003 12:06: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 MAA00181 for ; Fri, 6 Jun 2003 12:06:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OJhP-0003WJ-00 for simple@ietf.org; Fri, 06 Jun 2003 12:04:15 -0400 Received: from oe-im1pub.managedmail.com ([206.46.164.52] helo=oe-im1.bizmailsrvcs.net) by ietf-mx with esmtp (Exim 4.12) id 19OJhO-0003W4-00 for simple@ietf.org; Fri, 06 Jun 2003 12:04:14 -0400 Received: from oe-ismta1.bizmailsrvcs.net ([206.46.164.26]) by oe-im1.bizmailsrvcs.net (InterMail vM.5.01.05.27 201-253-122-126-127-20021220) with ESMTP id <20030606160538.TPMD2597.oe-im1.bizmailsrvcs.net@oe-ismta1.bizmailsrvcs.net>; Fri, 6 Jun 2003 11:05:38 -0500 Received: from tdiacakis ([63.67.207.249]) by oe-ismta1.bizmailsrvcs.net (InterMail vM.5.01.05.27 201-253-122-126-127-20021220) with SMTP id <20030606160538.VXTA6261.oe-ismta1.bizmailsrvcs.net@tdiacakis>; Fri, 6 Jun 2003 11:05:38 -0500 Message-ID: <06b201c32c45$78620080$05071e0a@myopwv.com> From: "Thanos Diacakis" To: , , References: <2038BCC78B1AD641891A0D1AE133DBB701796D4D@esebe019.ntc.nokia.com> Subject: Re: [Simple] PUBLISH: identification of presence segments MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 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, 6 Jun 2003 10:05:32 -0600 Content-Transfer-Encoding: 7bit Hi Hisham, some comments inline. Thanos --- Thanos Diacakis Openwave Systems thanos.diacakis@openwave.com +1-303 385 6705 ----- Original Message ----- From: To: ; ; Sent: Friday, June 06, 2003 8:05 AM Subject: RE: [Simple] PUBLISH: identification of presence segments > We need something to identify not just the tuple in which the user wants to override from a terminal that doesn't own that tuple, but aspects within the tuple. > > Imagine I have a device D1 (office PC) that publishes one device tuple T1 that describes all the services available in that device (IM, voice, video). Now I go home and only want to override the part of the device tuple T1 describing the IM, using my home device D2. I therefore have to publish a new tuple T2 from D2 that is just related to the part of the old tuple T1. The compositor has to relate the 2 tuples somehow. A solution for this is to mandate that no matter what part of the tuple a second device wants to modify from a second terminal, that second device MUST publish the whole tuple again. This makes it easier for the compositor in that it just replaces the original tuple instead of trying to compose T2 into parts of T1. > Well, if you want the compositor to merge your presence information, you must structure it in the units that it can deal with, and I think what we're discussing here is that the compositor will be able to deal with tuple-sized units. If you don't want the compositor to do it, then you would need to publish the whole thing again. > Having said that, the problem stays: How do you relate those 2 tuples, especially since the compositor can create tuple-ids on its own when composing separate tuples into one. Agreed. > > Can a human be involved in this? The human sets ids or keywords for services, devices or whatever s/he is publishing presence for. Taking the example above: > > When I publish from work, I give unique Ids to IM, voice, and video (office-pc-im, office-pc-voice, office-pc-video, respectively) that I know about and remember. Regardless of how the implementation in the terminal interprets those and puts them in a tuples (one tuple or 3), I have now uniquely identified things for myself. When I go home and want to override my IM that I published from work, I input the id office-pc-im before I publish. > > I haven't thought about the proposal too much, just thinking aloud, so don't hose me :) This could work, but I think the use cases it would support would be very limited, given the manual input nature of the solution. We need to come up with a programatic solution that uniquely identifies two tuples as being "semantically identical" while at the same time being careful not to kill the presence format extensibility. > > Regards, > Hisham > > > -----Original Message----- > > From: ext aki.niemi@nokia.com [mailto:aki.niemi@nokia.com] > > Sent: Friday, June 06, 2003 3:56 PM > > To: thanos.diacakis@openwave.com; simple@ietf.org > > Subject: RE: [Simple] PUBLISH: identification of presence segments > > > > > > Hi Thanos, > > > > I think you are right in that using the tuple ID makes the > > assumption that the composer never merges or modifies the > > individual tuples, so that the ID is carried over to the > > watchers intact. > > > > You also touch on a very interesting related topic of how to > > identify two "semantically identical" presence segments. > > Since the tuple IDs are generated at the source of presence > > information, it could be so that two sources publish the same > > presence segment using a different ID. > > > > In this case, the composer would need to know that the > > segments are in fact two representations of the same presence > > segment, and instead of composing them both in the presence > > document it should only use the most recent one of the two > > (and indicate a collision to the publisher of the stale one). > > > > I think the only use case we considered in the interim was > > one where a user goes home, sees that her work PC is still > > publishing OPEN IM status, and needs to "steal" that > > particular publication away from the work PC. In this > > scenario, merely knowing the tuple ID would suffice. > > > > So we have two issues to resolve: > > (1) Can we restrict the composer so that published tuples are > > never merged > > or modified? > > > > (2) Can we define a way for the composer (and EPAs as well) > > to identify > > "semantically identical" tuples when they have different IDs? > > > > I think (1) has a more wider scope that deals with the models > > we have envisioned for presence composition. As was also > > stated in the interim, there may be security implications > > related to a composer modifying tuples, and this also relates > > to another discussion on as to how for example geoloc > > information is applied to a presence document. Is it a > > separate tuple or part of other tuples. > > > > Even when answering "yes" to (1), (2) would most probably > > still be needed because of the reasons you point out. I could > > imagine that for some other event segments, such a definition > > of "semantically identical" could be relatively straight > > forward. However, with presence it may not be so simple. > > > > Any thoughts on this? > > > > Cheers, > > Aki > > > > > -----Original Message----- > > > From: ext Thanos Diacakis [mailto:thanos.diacakis@openwave.com] > > > Sent: 05 June, 2003 19:56 > > > To: Niemi Aki (NMP/Helsinki); simple@ietf.org > > > Subject: Re: [Simple] PUBLISH: identification of presence segments > > > > > > > > > Hi Aki, > > > > > > (I'm assuming you're referring to the presence aggregation problem) > > > > > > I think I remember the consensus being along those lines, > > > but I'm not sure > > > this will work. Here's why... > > > > > > Recap: If two entities (say P1 and P2) are publishing > > presence for a > > > particular presentity, that include two semantically > > > identical tuples, it is > > > hard for them to co-ordinate the tuple-ids. By > > > "semantically identical" I > > > mean they contain information about the same segment of state. > > > > > > The assumption I think that we were working on is that P1 > > > will first publish > > > a tuple T1 with tuple ID, say X1. P2 will be a subscriber to this > > > information, and will have a way to figure out that the > > > tuple T1 with ID X1 > > > is "semantically identically" to the tuple it wants to > > > publish (ignoring > > > that this is not trivial), and thus P2 will publish a tuple > > > T2 with ID X1. > > > The aggregator at the Presence Service will then replace T2 > > > with T1 (subject > > > to the other mechanism we're discussing). > > > > > > Now the first problem is that if P1 and P2 simultaneously > > > decide to publish > > > T1 and T2 respectively, they will each assign unique ids to > > > two tuples that > > > are semantically the same. To solve this we need to have a > > > central entity > > > that can identify tuples that are "semantically identical" , > > > and there are > > > some ways of doing so. > > > > > > The second problem is that this mechanism relies on the > > tuples being > > > published having the same ID as the tuples in > > notifications. This is > > > possible in some simple cases, but won't work when the > > > presence information > > > being notified is based upon (but not verbatim copies) of > > > the presence being > > > published. For example, if a particular presence > > > implementation takes > > > tuples A and B, does some complex calculation and publishes > > > tuple C, then we > > > have a problem as there is no direct way to map tuple IDs > > between the > > > publish and notify operations. (This also affects the > > > versioning mechanism, > > > as you may no longer assume that P1 and P2 can see all > > > aspects of what each > > > other is doing) > > > > > > Thanos > > > --- > > > Thanos Diacakis > > > Openwave Systems > > > thanos.diacakis@openwave.com > > > +1-303 385 6705 > > > > > > ----- Original Message ----- > > > From: > > > To: > > > Sent: Thursday, June 05, 2003 9:25 AM > > > Subject: [Simple] PUBLISH: identification of presence segments > > > > > > > > > > Hi All, > > > > > > > > One of the open issues in the PUBLISH work is how to > > > identify specific > > > segments of state. Each event is supposed to define a way to > > > identify a > > > specific segment. So far, we've decided that in presence > > > publication, a > > > tuple corresponds to such a segment. > > > > > > > > I think the conclusion we arrived at in the interim > > > meeting was that tuple > > > IDs would be used to identiy a specific presence tuple > > > instead of the RPIDS > > > label-element. > > > > > > > > Just making sure this was the consensus. Anyone against? > > > > > > > > Cheers, > > > > Aki > > > > _______________________________________________ > > > > Simple mailing list > > > > Simple@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/simple > > > > > > > > > > > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > > > _______________________________________________ > Simple mailing 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 mailnull@www1.ietf.org Fri Jun 6 12:16:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00891 for ; Fri, 6 Jun 2003 12:16:59 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h56GGXd06449 for simple-archive@odin.ietf.org; Fri, 6 Jun 2003 12:16:33 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56GGXB06446 for ; Fri, 6 Jun 2003 12:16:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00840; Fri, 6 Jun 2003 12:16:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OJrQ-0003iJ-00; Fri, 06 Jun 2003 12:14:36 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19OJrP-0003iG-00; Fri, 06 Jun 2003 12:14:35 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56GDAB06180; Fri, 6 Jun 2003 12:13:10 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56G6BB04288 for ; Fri, 6 Jun 2003 12:06: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 MAA00181 for ; Fri, 6 Jun 2003 12:06:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OJhP-0003WJ-00 for simple@ietf.org; Fri, 06 Jun 2003 12:04:15 -0400 Received: from oe-im1pub.managedmail.com ([206.46.164.52] helo=oe-im1.bizmailsrvcs.net) by ietf-mx with esmtp (Exim 4.12) id 19OJhO-0003W4-00 for simple@ietf.org; Fri, 06 Jun 2003 12:04:14 -0400 Received: from oe-ismta1.bizmailsrvcs.net ([206.46.164.26]) by oe-im1.bizmailsrvcs.net (InterMail vM.5.01.05.27 201-253-122-126-127-20021220) with ESMTP id <20030606160538.TPMD2597.oe-im1.bizmailsrvcs.net@oe-ismta1.bizmailsrvcs.net>; Fri, 6 Jun 2003 11:05:38 -0500 Received: from tdiacakis ([63.67.207.249]) by oe-ismta1.bizmailsrvcs.net (InterMail vM.5.01.05.27 201-253-122-126-127-20021220) with SMTP id <20030606160538.VXTA6261.oe-ismta1.bizmailsrvcs.net@tdiacakis>; Fri, 6 Jun 2003 11:05:38 -0500 Message-ID: <06b201c32c45$78620080$05071e0a@myopwv.com> From: "Thanos Diacakis" To: , , References: <2038BCC78B1AD641891A0D1AE133DBB701796D4D@esebe019.ntc.nokia.com> Subject: Re: [Simple] PUBLISH: identification of presence segments MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 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, 6 Jun 2003 10:05:32 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Hisham, some comments inline. Thanos --- Thanos Diacakis Openwave Systems thanos.diacakis@openwave.com +1-303 385 6705 ----- Original Message ----- From: To: ; ; Sent: Friday, June 06, 2003 8:05 AM Subject: RE: [Simple] PUBLISH: identification of presence segments > We need something to identify not just the tuple in which the user wants to override from a terminal that doesn't own that tuple, but aspects within the tuple. > > Imagine I have a device D1 (office PC) that publishes one device tuple T1 that describes all the services available in that device (IM, voice, video). Now I go home and only want to override the part of the device tuple T1 describing the IM, using my home device D2. I therefore have to publish a new tuple T2 from D2 that is just related to the part of the old tuple T1. The compositor has to relate the 2 tuples somehow. A solution for this is to mandate that no matter what part of the tuple a second device wants to modify from a second terminal, that second device MUST publish the whole tuple again. This makes it easier for the compositor in that it just replaces the original tuple instead of trying to compose T2 into parts of T1. > Well, if you want the compositor to merge your presence information, you must structure it in the units that it can deal with, and I think what we're discussing here is that the compositor will be able to deal with tuple-sized units. If you don't want the compositor to do it, then you would need to publish the whole thing again. > Having said that, the problem stays: How do you relate those 2 tuples, especially since the compositor can create tuple-ids on its own when composing separate tuples into one. Agreed. > > Can a human be involved in this? The human sets ids or keywords for services, devices or whatever s/he is publishing presence for. Taking the example above: > > When I publish from work, I give unique Ids to IM, voice, and video (office-pc-im, office-pc-voice, office-pc-video, respectively) that I know about and remember. Regardless of how the implementation in the terminal interprets those and puts them in a tuples (one tuple or 3), I have now uniquely identified things for myself. When I go home and want to override my IM that I published from work, I input the id office-pc-im before I publish. > > I haven't thought about the proposal too much, just thinking aloud, so don't hose me :) This could work, but I think the use cases it would support would be very limited, given the manual input nature of the solution. We need to come up with a programatic solution that uniquely identifies two tuples as being "semantically identical" while at the same time being careful not to kill the presence format extensibility. > > Regards, > Hisham > > > -----Original Message----- > > From: ext aki.niemi@nokia.com [mailto:aki.niemi@nokia.com] > > Sent: Friday, June 06, 2003 3:56 PM > > To: thanos.diacakis@openwave.com; simple@ietf.org > > Subject: RE: [Simple] PUBLISH: identification of presence segments > > > > > > Hi Thanos, > > > > I think you are right in that using the tuple ID makes the > > assumption that the composer never merges or modifies the > > individual tuples, so that the ID is carried over to the > > watchers intact. > > > > You also touch on a very interesting related topic of how to > > identify two "semantically identical" presence segments. > > Since the tuple IDs are generated at the source of presence > > information, it could be so that two sources publish the same > > presence segment using a different ID. > > > > In this case, the composer would need to know that the > > segments are in fact two representations of the same presence > > segment, and instead of composing them both in the presence > > document it should only use the most recent one of the two > > (and indicate a collision to the publisher of the stale one). > > > > I think the only use case we considered in the interim was > > one where a user goes home, sees that her work PC is still > > publishing OPEN IM status, and needs to "steal" that > > particular publication away from the work PC. In this > > scenario, merely knowing the tuple ID would suffice. > > > > So we have two issues to resolve: > > (1) Can we restrict the composer so that published tuples are > > never merged > > or modified? > > > > (2) Can we define a way for the composer (and EPAs as well) > > to identify > > "semantically identical" tuples when they have different IDs? > > > > I think (1) has a more wider scope that deals with the models > > we have envisioned for presence composition. As was also > > stated in the interim, there may be security implications > > related to a composer modifying tuples, and this also relates > > to another discussion on as to how for example geoloc > > information is applied to a presence document. Is it a > > separate tuple or part of other tuples. > > > > Even when answering "yes" to (1), (2) would most probably > > still be needed because of the reasons you point out. I could > > imagine that for some other event segments, such a definition > > of "semantically identical" could be relatively straight > > forward. However, with presence it may not be so simple. > > > > Any thoughts on this? > > > > Cheers, > > Aki > > > > > -----Original Message----- > > > From: ext Thanos Diacakis [mailto:thanos.diacakis@openwave.com] > > > Sent: 05 June, 2003 19:56 > > > To: Niemi Aki (NMP/Helsinki); simple@ietf.org > > > Subject: Re: [Simple] PUBLISH: identification of presence segments > > > > > > > > > Hi Aki, > > > > > > (I'm assuming you're referring to the presence aggregation problem) > > > > > > I think I remember the consensus being along those lines, > > > but I'm not sure > > > this will work. Here's why... > > > > > > Recap: If two entities (say P1 and P2) are publishing > > presence for a > > > particular presentity, that include two semantically > > > identical tuples, it is > > > hard for them to co-ordinate the tuple-ids. By > > > "semantically identical" I > > > mean they contain information about the same segment of state. > > > > > > The assumption I think that we were working on is that P1 > > > will first publish > > > a tuple T1 with tuple ID, say X1. P2 will be a subscriber to this > > > information, and will have a way to figure out that the > > > tuple T1 with ID X1 > > > is "semantically identically" to the tuple it wants to > > > publish (ignoring > > > that this is not trivial), and thus P2 will publish a tuple > > > T2 with ID X1. > > > The aggregator at the Presence Service will then replace T2 > > > with T1 (subject > > > to the other mechanism we're discussing). > > > > > > Now the first problem is that if P1 and P2 simultaneously > > > decide to publish > > > T1 and T2 respectively, they will each assign unique ids to > > > two tuples that > > > are semantically the same. To solve this we need to have a > > > central entity > > > that can identify tuples that are "semantically identical" , > > > and there are > > > some ways of doing so. > > > > > > The second problem is that this mechanism relies on the > > tuples being > > > published having the same ID as the tuples in > > notifications. This is > > > possible in some simple cases, but won't work when the > > > presence information > > > being notified is based upon (but not verbatim copies) of > > > the presence being > > > published. For example, if a particular presence > > > implementation takes > > > tuples A and B, does some complex calculation and publishes > > > tuple C, then we > > > have a problem as there is no direct way to map tuple IDs > > between the > > > publish and notify operations. (This also affects the > > > versioning mechanism, > > > as you may no longer assume that P1 and P2 can see all > > > aspects of what each > > > other is doing) > > > > > > Thanos > > > --- > > > Thanos Diacakis > > > Openwave Systems > > > thanos.diacakis@openwave.com > > > +1-303 385 6705 > > > > > > ----- Original Message ----- > > > From: > > > To: > > > Sent: Thursday, June 05, 2003 9:25 AM > > > Subject: [Simple] PUBLISH: identification of presence segments > > > > > > > > > > Hi All, > > > > > > > > One of the open issues in the PUBLISH work is how to > > > identify specific > > > segments of state. Each event is supposed to define a way to > > > identify a > > > specific segment. So far, we've decided that in presence > > > publication, a > > > tuple corresponds to such a segment. > > > > > > > > I think the conclusion we arrived at in the interim > > > meeting was that tuple > > > IDs would be used to identiy a specific presence tuple > > > instead of the RPIDS > > > label-element. > > > > > > > > Just making sure this was the consensus. Anyone against? > > > > > > > > Cheers, > > > > Aki > > > > _______________________________________________ > > > > Simple mailing list > > > > Simple@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/simple > > > > > > > > > > > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > > > _______________________________________________ > Simple mailing 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 Fri Jun 6 13:12:30 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 NAA02718; Fri, 6 Jun 2003 13:12:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OKjd-0004Fe-00; Fri, 06 Jun 2003 13:10:38 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19OKjd-0004Fb-00; Fri, 06 Jun 2003 13:10:37 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56H8iB10954; Fri, 6 Jun 2003 13:08:44 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56H53B09886 for ; Fri, 6 Jun 2003 13:05: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 NAA02516 for ; Fri, 6 Jun 2003 13:04:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OKcL-0004CH-00 for simple@ietf.org; Fri, 06 Jun 2003 13:03:05 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19OKcK-0004Bd-00 for simple@ietf.org; Fri, 06 Jun 2003 13:03:04 -0400 Received: from dynamicsoft.com ([63.113.46.85]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h56H4OZE009553; Fri, 6 Jun 2003 13:04:26 -0400 (EDT) Message-ID: <3EE0C993.9090902@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ashir Ahmed CC: simple@ietf.org Subject: Re: [Simple] requirements of a presence server References: <008c01c32bf5$b4b46910$cd44320a@nttu26skyyrabi> In-Reply-To: <008c01c32bf5$b4b46910$cd44320a@nttu26skyyrabi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 06 Jun 2003 13:04:19 -0400 Content-Transfer-Encoding: 7bit The IETF does not specify features beyond those which are aspects of the protocols (such as sip for presence) used by the servers. -Jonathan R. Ashir Ahmed wrote: > Is there any drafts/RFC that contains the requirements/features of a > presence server? > > Thanks for your help. > > Ashir -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Scientist 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 mailnull@www1.ietf.org Fri Jun 6 13:13:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02741 for ; Fri, 6 Jun 2003 13:13:00 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h56HCac11157 for simple-archive@odin.ietf.org; Fri, 6 Jun 2003 13:12:36 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56HCZB11154 for ; Fri, 6 Jun 2003 13:12: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 NAA02718; Fri, 6 Jun 2003 13:12:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OKjd-0004Fe-00; Fri, 06 Jun 2003 13:10:38 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19OKjd-0004Fb-00; Fri, 06 Jun 2003 13:10:37 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56H8iB10954; Fri, 6 Jun 2003 13:08:44 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56H53B09886 for ; Fri, 6 Jun 2003 13:05: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 NAA02516 for ; Fri, 6 Jun 2003 13:04:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OKcL-0004CH-00 for simple@ietf.org; Fri, 06 Jun 2003 13:03:05 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19OKcK-0004Bd-00 for simple@ietf.org; Fri, 06 Jun 2003 13:03:04 -0400 Received: from dynamicsoft.com ([63.113.46.85]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h56H4OZE009553; Fri, 6 Jun 2003 13:04:26 -0400 (EDT) Message-ID: <3EE0C993.9090902@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ashir Ahmed CC: simple@ietf.org Subject: Re: [Simple] requirements of a presence server References: <008c01c32bf5$b4b46910$cd44320a@nttu26skyyrabi> In-Reply-To: <008c01c32bf5$b4b46910$cd44320a@nttu26skyyrabi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 06 Jun 2003 13:04:19 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit The IETF does not specify features beyond those which are aspects of the protocols (such as sip for presence) used by the servers. -Jonathan R. Ashir Ahmed wrote: > Is there any drafts/RFC that contains the requirements/features of a > presence server? > > Thanks for your help. > > Ashir -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Scientist 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 Jun 8 12:59: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 MAA25247; Sun, 8 Jun 2003 12:59:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19P3U1-0004Gw-00; Sun, 08 Jun 2003 12:57:29 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19P3U0-0004Gr-00; Sun, 08 Jun 2003 12:57:28 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h58GseB10410; Sun, 8 Jun 2003 12:54:40 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h58GrSB10381 for ; Sun, 8 Jun 2003 12:53: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 MAA25170 for ; Sun, 8 Jun 2003 12:53:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19P3Nv-0004FC-00 for simple@ietf.org; Sun, 08 Jun 2003 12:51:11 -0400 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 19P3Nu-0004F8-00 for simple@ietf.org; Sun, 08 Jun 2003 12:51:11 -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 h58GqaDc004314; Sun, 8 Jun 2003 12:52:36 -0400 (EDT) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Sun, 8 Jun 2003 11:52:36 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A6482A@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'hisham.khartabil@nokia.com'" , seancolson@yahoo.com, aki.niemi@nokia.com, simple@ietf.org Subject: RE: [Simple] PUBLISH: versioning of published information 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: Sun, 8 Jun 2003 11:52:35 -0500 > -----Original Message----- > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > > I share some of Sean's concern, mainly for the reason I > mentioned in the interim that we can't assume that all > presentities will publish using PUBLISH. Putting something > like this in the body will increase the chances of it being used. Keep in mind that, long term, we want PUBLISH to work for events in general, not just presence. The bodies for other event packages have demonstrated a tendency to be radically different than those of presence. /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Sun Jun 8 13:00:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25281 for ; Sun, 8 Jun 2003 13:00:35 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h58H04W10552 for simple-archive@odin.ietf.org; Sun, 8 Jun 2003 13:00:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h58H03B10549 for ; Sun, 8 Jun 2003 13:00:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25247; Sun, 8 Jun 2003 12:59:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19P3U1-0004Gw-00; Sun, 08 Jun 2003 12:57:29 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19P3U0-0004Gr-00; Sun, 08 Jun 2003 12:57:28 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h58GseB10410; Sun, 8 Jun 2003 12:54:40 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h58GrSB10381 for ; Sun, 8 Jun 2003 12:53: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 MAA25170 for ; Sun, 8 Jun 2003 12:53:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19P3Nv-0004FC-00 for simple@ietf.org; Sun, 08 Jun 2003 12:51:11 -0400 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 19P3Nu-0004F8-00 for simple@ietf.org; Sun, 08 Jun 2003 12:51:11 -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 h58GqaDc004314; Sun, 8 Jun 2003 12:52:36 -0400 (EDT) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Sun, 8 Jun 2003 11:52:36 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A6482A@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'hisham.khartabil@nokia.com'" , seancolson@yahoo.com, aki.niemi@nokia.com, simple@ietf.org Subject: RE: [Simple] PUBLISH: versioning of published information 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: Sun, 8 Jun 2003 11:52:35 -0500 > -----Original Message----- > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > > I share some of Sean's concern, mainly for the reason I > mentioned in the interim that we can't assume that all > presentities will publish using PUBLISH. Putting something > like this in the body will increase the chances of it being used. Keep in mind that, long term, we want PUBLISH to work for events in general, not just presence. The bodies for other event packages have demonstrated a tendency to be radically different than those of presence. /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Sun Jun 8 13:14:53 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 NAA25506; Sun, 8 Jun 2003 13:14:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19P3iy-0004Kd-00; Sun, 08 Jun 2003 13:12:56 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19P3ix-0004Ka-00; Sun, 08 Jun 2003 13:12:55 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h58HA9B11651; Sun, 8 Jun 2003 13:10:09 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h58H9LB11625 for ; Sun, 8 Jun 2003 13:09:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25378 for ; Sun, 8 Jun 2003 13:09:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19P3dM-0004Il-00 for simple@ietf.org; Sun, 08 Jun 2003 13:07:08 -0400 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 19P3dL-0004Ih-00 for simple@ietf.org; Sun, 08 Jun 2003 13:07:07 -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 h58H8XDc004347; Sun, 8 Jun 2003 13:08:37 -0400 (EDT) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Sun, 8 Jun 2003 12:08:33 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A6482C@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'Thanos Diacakis'" , aki.niemi@nokia.com, simple@ietf.org Subject: RE: [Simple] PUBLISH: identification of presence segments 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: Sun, 8 Jun 2003 12:08:32 -0500 Thanos Diacakis [mailto:thanos.diacakis@openwave.com] writes: >...[T]his is related to the "what is a tuple" > discussion, so we should take this into consideration when > having the "what is a tuple" discussion. Actually, I would argue that the answer to this is not just related to the "what is a tuple" discussion; based on the arguments I've seen in this thread, it is *predicated* on it. Almost every argument so far has made implicit or explicit assumptions about tuples that may or may not end up being true, pending the output of the "what is a tuple?" team. I would suggest that we table trying to solve the identification problem until we actually have a shared view of what it is we're trying to identify. /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Sun Jun 8 13:15:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25585 for ; Sun, 8 Jun 2003 13:15:54 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h58HFTF11787 for simple-archive@odin.ietf.org; Sun, 8 Jun 2003 13:15:29 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h58HFTB11784 for ; Sun, 8 Jun 2003 13:15: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 NAA25506; Sun, 8 Jun 2003 13:14:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19P3iy-0004Kd-00; Sun, 08 Jun 2003 13:12:56 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19P3ix-0004Ka-00; Sun, 08 Jun 2003 13:12:55 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h58HA9B11651; Sun, 8 Jun 2003 13:10:09 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h58H9LB11625 for ; Sun, 8 Jun 2003 13:09:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25378 for ; Sun, 8 Jun 2003 13:09:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19P3dM-0004Il-00 for simple@ietf.org; Sun, 08 Jun 2003 13:07:08 -0400 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 19P3dL-0004Ih-00 for simple@ietf.org; Sun, 08 Jun 2003 13:07:07 -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 h58H8XDc004347; Sun, 8 Jun 2003 13:08:37 -0400 (EDT) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Sun, 8 Jun 2003 12:08:33 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A6482C@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'Thanos Diacakis'" , aki.niemi@nokia.com, simple@ietf.org Subject: RE: [Simple] PUBLISH: identification of presence segments 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: Sun, 8 Jun 2003 12:08:32 -0500 Thanos Diacakis [mailto:thanos.diacakis@openwave.com] writes: >...[T]his is related to the "what is a tuple" > discussion, so we should take this into consideration when > having the "what is a tuple" discussion. Actually, I would argue that the answer to this is not just related to the "what is a tuple" discussion; based on the arguments I've seen in this thread, it is *predicated* on it. Almost every argument so far has made implicit or explicit assumptions about tuples that may or may not end up being true, pending the output of the "what is a tuple?" team. I would suggest that we table trying to solve the identification problem until we actually have a shared view of what it is we're trying to identify. /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Sun Jun 8 16:42:44 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 QAA29937; Sun, 8 Jun 2003 16:42:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19P6y6-0005CG-00; Sun, 08 Jun 2003 16:40:46 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19P6y5-0005CD-00; Sun, 08 Jun 2003 16:40:45 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h58KbQB22749; Sun, 8 Jun 2003 16:37:26 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h58KarB22022 for ; Sun, 8 Jun 2003 16:36:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29860 for ; Sun, 8 Jun 2003 16:36:40 -0400 (EDT) From: Markus.Isomaki@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19P6sE-0005Aq-00 for simple@ietf.org; Sun, 08 Jun 2003 16:34:42 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19P6sD-0005An-00 for simple@ietf.org; Sun, 08 Jun 2003 16:34:41 -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 h58KadW27208 for ; Sun, 8 Jun 2003 23:36:39 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Sun, 8 Jun 2003 23:36:39 +0300 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Sun, 8 Jun 2003 23:36:39 +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" Subject: RE: [Simple] XCAP issue: batching Message-ID: Thread-Topic: [Simple] XCAP issue: batching Thread-Index: AcMpja7MF8PCaQH5Tf2XZIslYABAoQEbq9Xg To: , X-OriginalArrivalTime: 08 Jun 2003 20:36:39.0650 (UTC) FILETIME=[A9DFD420:01C32DFD] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h58KawB22029 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, 8 Jun 2003 23:36:39 +0300 Content-Transfer-Encoding: 8bit Hi, My prefence would be to go for option II, if we could do also conference control by making XCAP a bit more general. That would still be much lighter to implement than SOAP. The problem with option IV is that it seems to require extensions on HTTP level. That might make it difficult to implement on top of a common HTTP stack, which is an issue in certain environments. Otherwise option IV would be the best one. Have to see how big job incorporating the new methods/headers actually is. Markus > -----Original Message----- > From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: 03 June, 2003 08:02 > To: simple@ietf.org > Subject: [Simple] XCAP issue: batching > > > Folks, > > The main open issue in xcap at this time is batching. We discussed it > during the interim, and I have done some additional investigating > since then. > > The issue is this. In many cases, a client will want to modify a > document from X to Y. This modification may require a series of > changes to the document. However, the intermediate versions of the > document which result from those changes do not represent a > state that > the client finds acceptable. This could be because they are not > compliant to the schema, or because they are wrong or inappropriate. > An example is moving a buddy from a white list to a black list. That > would require two xcap operations - one to remove from the > white list, > one to add to the black list. After completing the first step, the > buddy is on NEITHER list, and if a subscription should arrive at > exactly that moment, the wrong thing would happen. This is basically > the consistency property of ACID. > > There are several ways this feature can be provided: > > Soln 1: Least Common Parent > > The "least common parent" is the XML element whose > descendants include > all of the nodes to be modified in the transaction, and for whom no > descendant also has this property. So, to provide the > transaction, the > client would read the value of the least common parent, modify all of > the elements as needed, and write it back to the server. > > The main drawback of this approach is overhead. The client may be > forced to read and write a lot of extra elements which are not > actually modified, but are within the subtree of the least common > parent. For buddy lists, this might mean reading the entire list, > modifying some of the entries, and writing it back. Not pretty. > > This approach works with xcap as written now. > > Approach II: Body Commands > > In this approach, we introduce a new operation that can be done on a > document. The body of the request (POST) would contain XML that > contains the sequence of operations to perform. So: > > POST > http://xcap.example.com/services/presence-lists/users/joe/list > 1.xml?batch > > > > /presence-lists/list[@name=friends]/entry[@name=bill] > > read directly by anyone but the document owner. To make a bunch of > changes, the client would COPY (using webdav copy) the document into > the area, using a random filename as the target. It then makes the > changes using a series of PUT/POST/DELETE, with pipelining. > When done, > it performs a Webdav MOVE to place it back into the right place. We > can specify some rules for the server on only allowing a move of a > dcument back to the place where it was copied from. > > I *think* we can support MOVE and COPY (and the additional webdav > headers) without all of the rest of webdav, but I would need to > confirm that. I didnt find any words that said MOVE or COPY can be > applied to a non-webdav resource. > > If any intermediate operation should fail, the client just > DELETEs the > document from the scratch area, and the original remains as > it was. We > would also probably want to have documents in the scratch area expire > automatically after some time, so as to cleanup from incomplete > transactions. > > > > > Assuming it is possible to MOVE or COPY non-webdav resources, my > current preference is for option IV. > > Comments, questions, or other proposals? > > Thanks, > Jonathan R. > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Scientist Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Sun Jun 8 16:43:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29965 for ; Sun, 8 Jun 2003 16:43:40 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h58KhDe23083 for simple-archive@odin.ietf.org; Sun, 8 Jun 2003 16:43:13 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h58KhDB23080 for ; Sun, 8 Jun 2003 16: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 ESMTP id QAA29937; Sun, 8 Jun 2003 16:42:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19P6y6-0005CG-00; Sun, 08 Jun 2003 16:40:46 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19P6y5-0005CD-00; Sun, 08 Jun 2003 16:40:45 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h58KbQB22749; Sun, 8 Jun 2003 16:37:26 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h58KarB22022 for ; Sun, 8 Jun 2003 16:36:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29860 for ; Sun, 8 Jun 2003 16:36:40 -0400 (EDT) From: Markus.Isomaki@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19P6sE-0005Aq-00 for simple@ietf.org; Sun, 08 Jun 2003 16:34:42 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19P6sD-0005An-00 for simple@ietf.org; Sun, 08 Jun 2003 16:34:41 -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 h58KadW27208 for ; Sun, 8 Jun 2003 23:36:39 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Sun, 8 Jun 2003 23:36:39 +0300 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Sun, 8 Jun 2003 23:36:39 +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" Subject: RE: [Simple] XCAP issue: batching Message-ID: Thread-Topic: [Simple] XCAP issue: batching Thread-Index: AcMpja7MF8PCaQH5Tf2XZIslYABAoQEbq9Xg To: , X-OriginalArrivalTime: 08 Jun 2003 20:36:39.0650 (UTC) FILETIME=[A9DFD420:01C32DFD] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h58KawB22029 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, 8 Jun 2003 23:36:39 +0300 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi, My prefence would be to go for option II, if we could do also conference control by making XCAP a bit more general. That would still be much lighter to implement than SOAP. The problem with option IV is that it seems to require extensions on HTTP level. That might make it difficult to implement on top of a common HTTP stack, which is an issue in certain environments. Otherwise option IV would be the best one. Have to see how big job incorporating the new methods/headers actually is. Markus > -----Original Message----- > From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: 03 June, 2003 08:02 > To: simple@ietf.org > Subject: [Simple] XCAP issue: batching > > > Folks, > > The main open issue in xcap at this time is batching. We discussed it > during the interim, and I have done some additional investigating > since then. > > The issue is this. In many cases, a client will want to modify a > document from X to Y. This modification may require a series of > changes to the document. However, the intermediate versions of the > document which result from those changes do not represent a > state that > the client finds acceptable. This could be because they are not > compliant to the schema, or because they are wrong or inappropriate. > An example is moving a buddy from a white list to a black list. That > would require two xcap operations - one to remove from the > white list, > one to add to the black list. After completing the first step, the > buddy is on NEITHER list, and if a subscription should arrive at > exactly that moment, the wrong thing would happen. This is basically > the consistency property of ACID. > > There are several ways this feature can be provided: > > Soln 1: Least Common Parent > > The "least common parent" is the XML element whose > descendants include > all of the nodes to be modified in the transaction, and for whom no > descendant also has this property. So, to provide the > transaction, the > client would read the value of the least common parent, modify all of > the elements as needed, and write it back to the server. > > The main drawback of this approach is overhead. The client may be > forced to read and write a lot of extra elements which are not > actually modified, but are within the subtree of the least common > parent. For buddy lists, this might mean reading the entire list, > modifying some of the entries, and writing it back. Not pretty. > > This approach works with xcap as written now. > > Approach II: Body Commands > > In this approach, we introduce a new operation that can be done on a > document. The body of the request (POST) would contain XML that > contains the sequence of operations to perform. So: > > POST > http://xcap.example.com/services/presence-lists/users/joe/list > 1.xml?batch > > > > /presence-lists/list[@name=friends]/entry[@name=bill] > > read directly by anyone but the document owner. To make a bunch of > changes, the client would COPY (using webdav copy) the document into > the area, using a random filename as the target. It then makes the > changes using a series of PUT/POST/DELETE, with pipelining. > When done, > it performs a Webdav MOVE to place it back into the right place. We > can specify some rules for the server on only allowing a move of a > dcument back to the place where it was copied from. > > I *think* we can support MOVE and COPY (and the additional webdav > headers) without all of the rest of webdav, but I would need to > confirm that. I didnt find any words that said MOVE or COPY can be > applied to a non-webdav resource. > > If any intermediate operation should fail, the client just > DELETEs the > document from the scratch area, and the original remains as > it was. We > would also probably want to have documents in the scratch area expire > automatically after some time, so as to cleanup from incomplete > transactions. > > > > > Assuming it is possible to MOVE or COPY non-webdav resources, my > current preference is for option IV. > > Comments, questions, or other proposals? > > Thanks, > Jonathan R. > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Scientist Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Jun 9 08:03: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 IAA29316; Mon, 9 Jun 2003 08:03:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PLKg-00025U-00; Mon, 09 Jun 2003 08:01:02 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19PLKf-00025R-00; Mon, 09 Jun 2003 08:01:01 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59BvfB26874; Mon, 9 Jun 2003 07:57:41 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59BkCB26316 for ; Mon, 9 Jun 2003 07:46:12 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28773; Mon, 9 Jun 2003 07:46:09 -0400 (EDT) Message-Id: <200306091146.HAA28773@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-00.txt Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 09 Jun 2003 07:46:09 -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) : T. Moran et al. Filename : draft-ietf-simple-pres-filter-reqs-00.txt Pages : 10 Date : 2003-6-6 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-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-pres-filter-reqs-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-pres-filter-reqs-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-6-6144227.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-pres-filter-reqs-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-pres-filter-reqs-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-6144227.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon Jun 9 08:03:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29369 for ; Mon, 9 Jun 2003 08:03:33 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h59C35w27378 for simple-archive@odin.ietf.org; Mon, 9 Jun 2003 08:03:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59C35B27375 for ; Mon, 9 Jun 2003 08:03: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 IAA29316; Mon, 9 Jun 2003 08:03:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PLKg-00025U-00; Mon, 09 Jun 2003 08:01:02 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19PLKf-00025R-00; Mon, 09 Jun 2003 08:01:01 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59BvfB26874; Mon, 9 Jun 2003 07:57:41 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59BkCB26316 for ; Mon, 9 Jun 2003 07:46:12 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28773; Mon, 9 Jun 2003 07:46:09 -0400 (EDT) Message-Id: <200306091146.HAA28773@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-00.txt Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 09 Jun 2003 07:46:09 -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) : T. Moran et al. Filename : draft-ietf-simple-pres-filter-reqs-00.txt Pages : 10 Date : 2003-6-6 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-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-pres-filter-reqs-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-pres-filter-reqs-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-6-6144227.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-pres-filter-reqs-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-pres-filter-reqs-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-6144227.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Jun 9 09:12:39 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 JAA03307; Mon, 9 Jun 2003 09:12:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PMQ3-0003IR-00; Mon, 09 Jun 2003 09:10:39 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19PMQ3-0003IO-00; Mon, 09 Jun 2003 09:10:39 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59D7MB00664; Mon, 9 Jun 2003 09:07:22 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59D69B32523 for ; Mon, 9 Jun 2003 09:06: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 JAA03203 for ; Mon, 9 Jun 2003 09:06:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PMJh-0003HD-00 for simple@ietf.org; Mon, 09 Jun 2003 09:04:05 -0400 Received: from oe-im1pub.managedmail.com ([206.46.164.52] helo=oe-im1.bizmailsrvcs.net) by ietf-mx with esmtp (Exim 4.12) id 19PMJg-0003HA-00 for simple@ietf.org; Mon, 09 Jun 2003 09:04:04 -0400 Received: from oe-ismta1.bizmailsrvcs.net ([206.46.164.26]) by oe-im1.bizmailsrvcs.net (InterMail vM.5.01.05.27 201-253-122-126-127-20021220) with ESMTP id <20030609130535.ENLN2597.oe-im1.bizmailsrvcs.net@oe-ismta1.bizmailsrvcs.net>; Mon, 9 Jun 2003 08:05:35 -0500 Received: from tdiacakis ([206.35.147.89]) by oe-ismta1.bizmailsrvcs.net (InterMail vM.5.01.05.27 201-253-122-126-127-20021220) with SMTP id <20030609130535.FQBV6261.oe-ismta1.bizmailsrvcs.net@tdiacakis>; Mon, 9 Jun 2003 08:05:35 -0500 Message-ID: <000b01c32e87$ce8a0400$ca000a0a@myopwv.com> From: "Thanos Diacakis" To: "Adam Roach" , , References: <9BF66EBF6BEFD942915B4D4D45C051F3A6482C@dyn-tx-exch-001.dynamicsoft.com> Subject: Re: [Simple] PUBLISH: identification of presence segments MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 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, 9 Jun 2003 07:05:25 -0600 Content-Transfer-Encoding: 7bit Well, yes and no. Although that appears as a valid way to go about this, as you pointed out in your previous email, PUBLISH might be used for other things, so defining what a tuple means for *presence* won't really help us. We'd need to define what a tuple is in general. This gives the problem a very broad scope, where a tuple is just a container. Then one of the very few things we might be able to define is how to identify a tuple... Thanos --- Thanos Diacakis Openwave Systems thanos.diacakis@openwave.com +1-303 385 6705 ----- Original Message ----- From: "Adam Roach" To: "'Thanos Diacakis'" ; ; Sent: Sunday, June 08, 2003 11:08 AM Subject: RE: [Simple] PUBLISH: identification of presence segments > Thanos Diacakis [mailto:thanos.diacakis@openwave.com] writes: > > >...[T]his is related to the "what is a tuple" > > discussion, so we should take this into consideration when > > having the "what is a tuple" discussion. > > Actually, I would argue that the answer to this is not just > related to the "what is a tuple" discussion; based on the > arguments I've seen in this thread, it is *predicated* on > it. Almost every argument so far has made implicit or > explicit assumptions about tuples that may or may not end > up being true, pending the output of the "what is a tuple?" > team. > > I would suggest that we table trying to solve the > identification problem until we actually have a > shared view of what it is we're trying to identify. > > /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon Jun 9 09:13:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03333 for ; Mon, 9 Jun 2003 09:13:10 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h59DCim01133 for simple-archive@odin.ietf.org; Mon, 9 Jun 2003 09:12:44 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59DCiB01130 for ; Mon, 9 Jun 2003 09:12: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 JAA03307; Mon, 9 Jun 2003 09:12:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PMQ3-0003IR-00; Mon, 09 Jun 2003 09:10:39 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19PMQ3-0003IO-00; Mon, 09 Jun 2003 09:10:39 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59D7MB00664; Mon, 9 Jun 2003 09:07:22 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59D69B32523 for ; Mon, 9 Jun 2003 09:06: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 JAA03203 for ; Mon, 9 Jun 2003 09:06:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PMJh-0003HD-00 for simple@ietf.org; Mon, 09 Jun 2003 09:04:05 -0400 Received: from oe-im1pub.managedmail.com ([206.46.164.52] helo=oe-im1.bizmailsrvcs.net) by ietf-mx with esmtp (Exim 4.12) id 19PMJg-0003HA-00 for simple@ietf.org; Mon, 09 Jun 2003 09:04:04 -0400 Received: from oe-ismta1.bizmailsrvcs.net ([206.46.164.26]) by oe-im1.bizmailsrvcs.net (InterMail vM.5.01.05.27 201-253-122-126-127-20021220) with ESMTP id <20030609130535.ENLN2597.oe-im1.bizmailsrvcs.net@oe-ismta1.bizmailsrvcs.net>; Mon, 9 Jun 2003 08:05:35 -0500 Received: from tdiacakis ([206.35.147.89]) by oe-ismta1.bizmailsrvcs.net (InterMail vM.5.01.05.27 201-253-122-126-127-20021220) with SMTP id <20030609130535.FQBV6261.oe-ismta1.bizmailsrvcs.net@tdiacakis>; Mon, 9 Jun 2003 08:05:35 -0500 Message-ID: <000b01c32e87$ce8a0400$ca000a0a@myopwv.com> From: "Thanos Diacakis" To: "Adam Roach" , , References: <9BF66EBF6BEFD942915B4D4D45C051F3A6482C@dyn-tx-exch-001.dynamicsoft.com> Subject: Re: [Simple] PUBLISH: identification of presence segments MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 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, 9 Jun 2003 07:05:25 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Well, yes and no. Although that appears as a valid way to go about this, as you pointed out in your previous email, PUBLISH might be used for other things, so defining what a tuple means for *presence* won't really help us. We'd need to define what a tuple is in general. This gives the problem a very broad scope, where a tuple is just a container. Then one of the very few things we might be able to define is how to identify a tuple... Thanos --- Thanos Diacakis Openwave Systems thanos.diacakis@openwave.com +1-303 385 6705 ----- Original Message ----- From: "Adam Roach" To: "'Thanos Diacakis'" ; ; Sent: Sunday, June 08, 2003 11:08 AM Subject: RE: [Simple] PUBLISH: identification of presence segments > Thanos Diacakis [mailto:thanos.diacakis@openwave.com] writes: > > >...[T]his is related to the "what is a tuple" > > discussion, so we should take this into consideration when > > having the "what is a tuple" discussion. > > Actually, I would argue that the answer to this is not just > related to the "what is a tuple" discussion; based on the > arguments I've seen in this thread, it is *predicated* on > it. Almost every argument so far has made implicit or > explicit assumptions about tuples that may or may not end > up being true, pending the output of the "what is a tuple?" > team. > > I would suggest that we table trying to solve the > identification problem until we actually have a > shared view of what it is we're trying to identify. > > /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Jun 9 11:14:45 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 LAA08344; Mon, 9 Jun 2003 11:14:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19POKE-0004EB-00; Mon, 09 Jun 2003 11:12:46 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19POKD-0004E8-00; Mon, 09 Jun 2003 11:12:45 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59F9IB09149; Mon, 9 Jun 2003 11:09:18 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59F8TB09087 for ; Mon, 9 Jun 2003 11:08: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 LAA08059 for ; Mon, 9 Jun 2003 11:08:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19POE2-00048d-00 for simple@ietf.org; Mon, 09 Jun 2003 11:06:22 -0400 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 19POE1-00048L-00 for simple@ietf.org; Mon, 09 Jun 2003 11:06:21 -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 h59F7dDc006672; Mon, 9 Jun 2003 11:07:39 -0400 (EDT) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 9 Jun 2003 10:07:39 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A6482D@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'Thanos Diacakis'" , Adam Roach , aki.niemi@nokia.com, simple@ietf.org Subject: RE: [Simple] PUBLISH: identification of presence segments 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, 9 Jun 2003 10:07:34 -0500 The consensus that was reached among the participants at the interim meeting, by my recollection, is that identification of subdocuments for publication was an issue that would be decided on a package-by-package basis. Given the wide variation in the body types that have and will be developed for these event packages, I contend that this is the only tractable way to approach the problem, so revisiting this decision seems pointless. As far as I can tell, the ongoing conversation is trying to solve the problem of how to perform this identification for presence; i.e., how to identify PIDF tuples. I think it's pretty self- explanatory that trying to identify something before we're even sure what that thing is won't yield much progress. To put it another way: I have a hunch that once we come to consensus on what a tuple is, the issue of how to identify one will become obvious. /a > -----Original Message----- > From: Thanos Diacakis [mailto:thanos.diacakis@openwave.com] > Sent: Monday, June 09, 2003 8:05 > To: Adam Roach; aki.niemi@nokia.com; simple@ietf.org > Subject: Re: [Simple] PUBLISH: identification of presence segments > > > Well, yes and no. Although that appears as a valid way to go > about this, as > you pointed out in your previous email, PUBLISH might be used > for other > things, so defining what a tuple means for *presence* won't > really help us. > We'd need to define what a tuple is in general. This gives > the problem a > very broad scope, where a tuple is just a container. Then > one of the very > few things we might be able to define is how to identify a tuple... > > Thanos > --- > Thanos Diacakis > Openwave Systems > thanos.diacakis@openwave.com > +1-303 385 6705 > > ----- Original Message ----- > From: "Adam Roach" > To: "'Thanos Diacakis'" ; > ; > Sent: Sunday, June 08, 2003 11:08 AM > Subject: RE: [Simple] PUBLISH: identification of presence segments > > > > Thanos Diacakis [mailto:thanos.diacakis@openwave.com] writes: > > > > >...[T]his is related to the "what is a tuple" > > > discussion, so we should take this into consideration when > > > having the "what is a tuple" discussion. > > > > Actually, I would argue that the answer to this is not just > > related to the "what is a tuple" discussion; based on the > > arguments I've seen in this thread, it is *predicated* on > > it. Almost every argument so far has made implicit or > > explicit assumptions about tuples that may or may not end > > up being true, pending the output of the "what is a tuple?" > > team. > > > > I would suggest that we table trying to solve the > > identification problem until we actually have a > > shared view of what it is we're trying to identify. > > > > /a > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon Jun 9 11:15:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08373 for ; Mon, 9 Jun 2003 11:15:16 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h59FEnI09511 for simple-archive@odin.ietf.org; Mon, 9 Jun 2003 11:14:49 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59FEmB09508 for ; Mon, 9 Jun 2003 11:14:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08344; Mon, 9 Jun 2003 11:14:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19POKE-0004EB-00; Mon, 09 Jun 2003 11:12:46 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19POKD-0004E8-00; Mon, 09 Jun 2003 11:12:45 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59F9IB09149; Mon, 9 Jun 2003 11:09:18 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59F8TB09087 for ; Mon, 9 Jun 2003 11:08: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 LAA08059 for ; Mon, 9 Jun 2003 11:08:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19POE2-00048d-00 for simple@ietf.org; Mon, 09 Jun 2003 11:06:22 -0400 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 19POE1-00048L-00 for simple@ietf.org; Mon, 09 Jun 2003 11:06:21 -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 h59F7dDc006672; Mon, 9 Jun 2003 11:07:39 -0400 (EDT) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 9 Jun 2003 10:07:39 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A6482D@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'Thanos Diacakis'" , Adam Roach , aki.niemi@nokia.com, simple@ietf.org Subject: RE: [Simple] PUBLISH: identification of presence segments 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, 9 Jun 2003 10:07:34 -0500 The consensus that was reached among the participants at the interim meeting, by my recollection, is that identification of subdocuments for publication was an issue that would be decided on a package-by-package basis. Given the wide variation in the body types that have and will be developed for these event packages, I contend that this is the only tractable way to approach the problem, so revisiting this decision seems pointless. As far as I can tell, the ongoing conversation is trying to solve the problem of how to perform this identification for presence; i.e., how to identify PIDF tuples. I think it's pretty self- explanatory that trying to identify something before we're even sure what that thing is won't yield much progress. To put it another way: I have a hunch that once we come to consensus on what a tuple is, the issue of how to identify one will become obvious. /a > -----Original Message----- > From: Thanos Diacakis [mailto:thanos.diacakis@openwave.com] > Sent: Monday, June 09, 2003 8:05 > To: Adam Roach; aki.niemi@nokia.com; simple@ietf.org > Subject: Re: [Simple] PUBLISH: identification of presence segments > > > Well, yes and no. Although that appears as a valid way to go > about this, as > you pointed out in your previous email, PUBLISH might be used > for other > things, so defining what a tuple means for *presence* won't > really help us. > We'd need to define what a tuple is in general. This gives > the problem a > very broad scope, where a tuple is just a container. Then > one of the very > few things we might be able to define is how to identify a tuple... > > Thanos > --- > Thanos Diacakis > Openwave Systems > thanos.diacakis@openwave.com > +1-303 385 6705 > > ----- Original Message ----- > From: "Adam Roach" > To: "'Thanos Diacakis'" ; > ; > Sent: Sunday, June 08, 2003 11:08 AM > Subject: RE: [Simple] PUBLISH: identification of presence segments > > > > Thanos Diacakis [mailto:thanos.diacakis@openwave.com] writes: > > > > >...[T]his is related to the "what is a tuple" > > > discussion, so we should take this into consideration when > > > having the "what is a tuple" discussion. > > > > Actually, I would argue that the answer to this is not just > > related to the "what is a tuple" discussion; based on the > > arguments I've seen in this thread, it is *predicated* on > > it. Almost every argument so far has made implicit or > > explicit assumptions about tuples that may or may not end > > up being true, pending the output of the "what is a tuple?" > > team. > > > > I would suggest that we table trying to solve the > > identification problem until we actually have a > > shared view of what it is we're trying to identify. > > > > /a > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Jun 9 12:33:33 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 MAA10898; Mon, 9 Jun 2003 12:33:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PPYU-0004rC-00; Mon, 09 Jun 2003 12:31:34 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19PPYT-0004r9-00; Mon, 09 Jun 2003 12:31:33 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59GSCB14808; Mon, 9 Jun 2003 12:28:12 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59GREB14752 for ; Mon, 9 Jun 2003 12:27:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10544 for ; Mon, 9 Jun 2003 12:27:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PPSJ-0004nv-00 for simple@ietf.org; Mon, 09 Jun 2003 12:25:11 -0400 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 19PPSI-0004nr-00 for simple@ietf.org; Mon, 09 Jun 2003 12:25:10 -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 h59GQZDc006865 for ; Mon, 9 Jun 2003 12:26:35 -0400 (EDT) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 9 Jun 2003 11:26:34 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A64831@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: Jonathan Rosenberg , simple@ietf.org Subject: RE: [Simple] XCAP issue: batching 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, 9 Jun 2003 11:26:28 -0500 Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] writes: > During the interim, we talked about using webdav. The idea there was > to first have the client LOCK the document, then perform a series of > changes (PUT, POST, DELETE), and then UNLOCK. AFter the LOCK, all of > the modification requests could be pipelined. The overhead here is > probably pretty small, since HTTP has few mandatory headers. > > I looked into webdav, and ran into the following issues: [...] What I liked most about this proposal wasn't that it was based on WEBDAV (although that was a nice bonus) as much as the model of locking the record, performing operations on it as appropriate (with connection-reuse and pipelining if desired), and then committing the record. The strongest appeal lies in the fact that the operations for adding a record to a document are identical for locked and non-locked writes. Since we're already having to define a mechanism for different operations associated with a POST, I would contend that the same effect could be achieved rather trivially by adding operations "lock", "commit", and "rollback". For example, an atomic add/delete/replace would be the following operations (with the middle three being pipelined): POST http://xcap.example.com/services/presence-lists/users/joe/list1.xml?lock=/pr esence-lists/list[@name=friends] POST http://xcap.example.com/services/presence-lists/users/joe/list1.xml?append=/ presence-lists/list[@name=friends]/entry[@name=bob] DELETE http://xcap.example.com/services/presence-lists/users/joe/list1.xml?/presenc e-lists/list[@name=friends]/entry[@name=dave] POST http://xcap.example.com/services/presence-lists/users/joe/list1.xml?replace= /presence-lists/list[@name=friends]/entry[@name=bill] POST http://xcap.example.com/services/presence-lists/users/joe/list1.xml?commit=/ presence-lists/list[@name=friends] (Or, if something goes wrong) POST http://xcap.example.com/services/presence-lists/users/joe/list1.xml?rollback =/presence-lists/list[@name=friends]/ And, of course, clients wouldn't be *required* to use the lock mechanism at all; it's only necessary when multiple updates need to be atomic. You raise the issue of read-locking; just to be sure I understand: do you see the need to lock a record, perform multiple reading operations on it that must yield a consistent view of the data, and then unlock it? I'm having a hard time constructing use cases for this ability. If we need it, though, we could define additional operations of "rlock" and "runlock" (and possibly "upgrade" and "downgrade"). /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon Jun 9 12:34:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10933 for ; Mon, 9 Jun 2003 12:34:03 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h59GXcC15175 for simple-archive@odin.ietf.org; Mon, 9 Jun 2003 12:33:38 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59GXcB15172 for ; Mon, 9 Jun 2003 12:33: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 MAA10898; Mon, 9 Jun 2003 12:33:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PPYU-0004rC-00; Mon, 09 Jun 2003 12:31:34 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19PPYT-0004r9-00; Mon, 09 Jun 2003 12:31:33 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59GSCB14808; Mon, 9 Jun 2003 12:28:12 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59GREB14752 for ; Mon, 9 Jun 2003 12:27:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10544 for ; Mon, 9 Jun 2003 12:27:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PPSJ-0004nv-00 for simple@ietf.org; Mon, 09 Jun 2003 12:25:11 -0400 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 19PPSI-0004nr-00 for simple@ietf.org; Mon, 09 Jun 2003 12:25:10 -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 h59GQZDc006865 for ; Mon, 9 Jun 2003 12:26:35 -0400 (EDT) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 9 Jun 2003 11:26:34 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A64831@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: Jonathan Rosenberg , simple@ietf.org Subject: RE: [Simple] XCAP issue: batching 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, 9 Jun 2003 11:26:28 -0500 Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] writes: > During the interim, we talked about using webdav. The idea there was > to first have the client LOCK the document, then perform a series of > changes (PUT, POST, DELETE), and then UNLOCK. AFter the LOCK, all of > the modification requests could be pipelined. The overhead here is > probably pretty small, since HTTP has few mandatory headers. > > I looked into webdav, and ran into the following issues: [...] What I liked most about this proposal wasn't that it was based on WEBDAV (although that was a nice bonus) as much as the model of locking the record, performing operations on it as appropriate (with connection-reuse and pipelining if desired), and then committing the record. The strongest appeal lies in the fact that the operations for adding a record to a document are identical for locked and non-locked writes. Since we're already having to define a mechanism for different operations associated with a POST, I would contend that the same effect could be achieved rather trivially by adding operations "lock", "commit", and "rollback". For example, an atomic add/delete/replace would be the following operations (with the middle three being pipelined): POST http://xcap.example.com/services/presence-lists/users/joe/list1.xml?lock=/pr esence-lists/list[@name=friends] POST http://xcap.example.com/services/presence-lists/users/joe/list1.xml?append=/ presence-lists/list[@name=friends]/entry[@name=bob] DELETE http://xcap.example.com/services/presence-lists/users/joe/list1.xml?/presenc e-lists/list[@name=friends]/entry[@name=dave] POST http://xcap.example.com/services/presence-lists/users/joe/list1.xml?replace= /presence-lists/list[@name=friends]/entry[@name=bill] POST http://xcap.example.com/services/presence-lists/users/joe/list1.xml?commit=/ presence-lists/list[@name=friends] (Or, if something goes wrong) POST http://xcap.example.com/services/presence-lists/users/joe/list1.xml?rollback =/presence-lists/list[@name=friends]/ And, of course, clients wouldn't be *required* to use the lock mechanism at all; it's only necessary when multiple updates need to be atomic. You raise the issue of read-locking; just to be sure I understand: do you see the need to lock a record, perform multiple reading operations on it that must yield a consistent view of the data, and then unlock it? I'm having a hard time constructing use cases for this ability. If we need it, though, we could define additional operations of "rlock" and "runlock" (and possibly "upgrade" and "downgrade"). /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Jun 9 21:32:44 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 VAA27754; Mon, 9 Jun 2003 21:32:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PXyF-0000ft-00; Mon, 09 Jun 2003 21:30:43 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19PXyF-0000fo-00; Mon, 09 Jun 2003 21:30:43 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5A1TQB21763; Mon, 9 Jun 2003 21:29:26 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5A1SMB21720 for ; Mon, 9 Jun 2003 21:28:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27685 for ; Mon, 9 Jun 2003 21:28:18 -0400 (EDT) From: aki.niemi@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PXtx-0000ea-00 for simple@ietf.org; Mon, 09 Jun 2003 21:26:17 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19PXtw-0000eX-00 for simple@ietf.org; Mon, 09 Jun 2003 21:26:16 -0400 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h5A1SG922583 for ; Tue, 10 Jun 2003 04:28:16 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 10 Jun 2003 04:28:16 +0300 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 10 Jun 2003 04:28:15 +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" Subject: RE: [Simple] PUBLISH: identification of presence segments Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9019452C3@esebe013.ntc.nokia.com> Thread-Topic: [Simple] PUBLISH: identification of presence segments Thread-Index: AcMumPrQK1eAUMDqQMqu6kC68tXmNQAVWkoA To: , , X-OriginalArrivalTime: 10 Jun 2003 01:28:15.0318 (UTC) FILETIME=[9084A760:01C32EEF] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5A1SNB21721 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 10 Jun 2003 04:28:14 +0300 Content-Transfer-Encoding: 8bit I agree. As you suggest, I think at this point it is probably best to table the identification issue, pending the "what is a tuple" results. Especially since I think this issue can be treated independently from the versioning issue, as well as independent from any text we may need to add explaining the generic property of "semantically identical" event segments. Thanks, Aki > -----Original Message----- > From: ext Adam Roach [mailto:adam@dynamicsoft.com] > Sent: 09 June, 2003 18:08 > To: 'Thanos Diacakis'; Adam Roach; Niemi Aki (NMP/Helsinki); > simple@ietf.org > Subject: RE: [Simple] PUBLISH: identification of presence segments > > > The consensus that was reached among the participants at > the interim meeting, by my recollection, is that > identification of subdocuments for publication was an > issue that would be decided on a package-by-package > basis. Given the wide variation in the body types that > have and will be developed for these event packages, > I contend that this is the only tractable way to > approach the problem, so revisiting this decision > seems pointless. > > As far as I can tell, the ongoing conversation is > trying to solve the problem of how to perform > this identification for presence; i.e., how to > identify PIDF tuples. I think it's pretty self- > explanatory that trying to identify something > before we're even sure what that thing is won't > yield much progress. > > To put it another way: I have a hunch that once > we come to consensus on what a tuple is, the > issue of how to identify one will become obvious. > > /a > > > -----Original Message----- > > From: Thanos Diacakis [mailto:thanos.diacakis@openwave.com] > > Sent: Monday, June 09, 2003 8:05 > > To: Adam Roach; aki.niemi@nokia.com; simple@ietf.org > > Subject: Re: [Simple] PUBLISH: identification of presence segments > > > > > > Well, yes and no. Although that appears as a valid way to go > > about this, as > > you pointed out in your previous email, PUBLISH might be used > > for other > > things, so defining what a tuple means for *presence* won't > > really help us. > > We'd need to define what a tuple is in general. This gives > > the problem a > > very broad scope, where a tuple is just a container. Then > > one of the very > > few things we might be able to define is how to identify a tuple... > > > > Thanos > > --- > > Thanos Diacakis > > Openwave Systems > > thanos.diacakis@openwave.com > > +1-303 385 6705 > > > > ----- Original Message ----- > > From: "Adam Roach" > > To: "'Thanos Diacakis'" ; > > ; > > Sent: Sunday, June 08, 2003 11:08 AM > > Subject: RE: [Simple] PUBLISH: identification of presence segments > > > > > > > Thanos Diacakis [mailto:thanos.diacakis@openwave.com] writes: > > > > > > >...[T]his is related to the "what is a tuple" > > > > discussion, so we should take this into consideration when > > > > having the "what is a tuple" discussion. > > > > > > Actually, I would argue that the answer to this is not just > > > related to the "what is a tuple" discussion; based on the > > > arguments I've seen in this thread, it is *predicated* on > > > it. Almost every argument so far has made implicit or > > > explicit assumptions about tuples that may or may not end > > > up being true, pending the output of the "what is a tuple?" > > > team. > > > > > > I would suggest that we table trying to solve the > > > identification problem until we actually have a > > > shared view of what it is we're trying to identify. > > > > > > /a > > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon Jun 9 21:33:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27793 for ; Mon, 9 Jun 2003 21:33:15 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5A1Wne21918 for simple-archive@odin.ietf.org; Mon, 9 Jun 2003 21:32:49 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5A1WnB21914 for ; Mon, 9 Jun 2003 21:32: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 VAA27754; Mon, 9 Jun 2003 21:32:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PXyF-0000ft-00; Mon, 09 Jun 2003 21:30:43 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19PXyF-0000fo-00; Mon, 09 Jun 2003 21:30:43 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5A1TQB21763; Mon, 9 Jun 2003 21:29:26 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5A1SMB21720 for ; Mon, 9 Jun 2003 21:28:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27685 for ; Mon, 9 Jun 2003 21:28:18 -0400 (EDT) From: aki.niemi@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PXtx-0000ea-00 for simple@ietf.org; Mon, 09 Jun 2003 21:26:17 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19PXtw-0000eX-00 for simple@ietf.org; Mon, 09 Jun 2003 21:26:16 -0400 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h5A1SG922583 for ; Tue, 10 Jun 2003 04:28:16 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 10 Jun 2003 04:28:16 +0300 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 10 Jun 2003 04:28:15 +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" Subject: RE: [Simple] PUBLISH: identification of presence segments Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9019452C3@esebe013.ntc.nokia.com> Thread-Topic: [Simple] PUBLISH: identification of presence segments Thread-Index: AcMumPrQK1eAUMDqQMqu6kC68tXmNQAVWkoA To: , , X-OriginalArrivalTime: 10 Jun 2003 01:28:15.0318 (UTC) FILETIME=[9084A760:01C32EEF] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5A1SNB21721 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 10 Jun 2003 04:28:14 +0300 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit I agree. As you suggest, I think at this point it is probably best to table the identification issue, pending the "what is a tuple" results. Especially since I think this issue can be treated independently from the versioning issue, as well as independent from any text we may need to add explaining the generic property of "semantically identical" event segments. Thanks, Aki > -----Original Message----- > From: ext Adam Roach [mailto:adam@dynamicsoft.com] > Sent: 09 June, 2003 18:08 > To: 'Thanos Diacakis'; Adam Roach; Niemi Aki (NMP/Helsinki); > simple@ietf.org > Subject: RE: [Simple] PUBLISH: identification of presence segments > > > The consensus that was reached among the participants at > the interim meeting, by my recollection, is that > identification of subdocuments for publication was an > issue that would be decided on a package-by-package > basis. Given the wide variation in the body types that > have and will be developed for these event packages, > I contend that this is the only tractable way to > approach the problem, so revisiting this decision > seems pointless. > > As far as I can tell, the ongoing conversation is > trying to solve the problem of how to perform > this identification for presence; i.e., how to > identify PIDF tuples. I think it's pretty self- > explanatory that trying to identify something > before we're even sure what that thing is won't > yield much progress. > > To put it another way: I have a hunch that once > we come to consensus on what a tuple is, the > issue of how to identify one will become obvious. > > /a > > > -----Original Message----- > > From: Thanos Diacakis [mailto:thanos.diacakis@openwave.com] > > Sent: Monday, June 09, 2003 8:05 > > To: Adam Roach; aki.niemi@nokia.com; simple@ietf.org > > Subject: Re: [Simple] PUBLISH: identification of presence segments > > > > > > Well, yes and no. Although that appears as a valid way to go > > about this, as > > you pointed out in your previous email, PUBLISH might be used > > for other > > things, so defining what a tuple means for *presence* won't > > really help us. > > We'd need to define what a tuple is in general. This gives > > the problem a > > very broad scope, where a tuple is just a container. Then > > one of the very > > few things we might be able to define is how to identify a tuple... > > > > Thanos > > --- > > Thanos Diacakis > > Openwave Systems > > thanos.diacakis@openwave.com > > +1-303 385 6705 > > > > ----- Original Message ----- > > From: "Adam Roach" > > To: "'Thanos Diacakis'" ; > > ; > > Sent: Sunday, June 08, 2003 11:08 AM > > Subject: RE: [Simple] PUBLISH: identification of presence segments > > > > > > > Thanos Diacakis [mailto:thanos.diacakis@openwave.com] writes: > > > > > > >...[T]his is related to the "what is a tuple" > > > > discussion, so we should take this into consideration when > > > > having the "what is a tuple" discussion. > > > > > > Actually, I would argue that the answer to this is not just > > > related to the "what is a tuple" discussion; based on the > > > arguments I've seen in this thread, it is *predicated* on > > > it. Almost every argument so far has made implicit or > > > explicit assumptions about tuples that may or may not end > > > up being true, pending the output of the "what is a tuple?" > > > team. > > > > > > I would suggest that we table trying to solve the > > > identification problem until we actually have a > > > shared view of what it is we're trying to identify. > > > > > > /a > > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Jun 10 08:34:10 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 IAA24212; Tue, 10 Jun 2003 08:34:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PiIK-0004dG-00; Tue, 10 Jun 2003 08:32:08 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19PiIJ-0004dD-00; Tue, 10 Jun 2003 08:32:07 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5ACUdB16100; Tue, 10 Jun 2003 08:30:39 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5ACR7B15843 for ; Tue, 10 Jun 2003 08:27: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 IAA23711 for ; Tue, 10 Jun 2003 08:27:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PiBS-0004Tz-00 for simple@ietf.org; Tue, 10 Jun 2003 08:25:02 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by ietf-mx with esmtp (Exim 4.12) id 19PiBQ-0004RX-00 for simple@ietf.org; Tue, 10 Jun 2003 08:25:01 -0400 Received: from cannon.cisco.com (IDENT:mirapoint@cannon.cisco.com [161.44.118.24]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h5ACQ3pi029865; Tue, 10 Jun 2003 08:26:08 -0400 (EDT) Received: from cisco.com (dhcp-171-71-188-55.cisco.com [171.71.188.55]) by cannon.cisco.com (Mirapoint) with ESMTP id ABK68737; Tue, 10 Jun 2003 08:34:58 -0400 (EDT) Message-ID: <3EE4DD02.9040606@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Campbell CC: Jonathan Rosenberg , Avshalom Houri , Simple WG Subject: Re: [Simple] PUBLISH and REGISTER relationship References: <1052938287.2539.27.camel@verite.localdomain> <3ED76B4D.10504@dynamicsoft.com> <1054305744.1215.19.camel@verite.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 09 Jun 2003 15:16:18 -0400 Content-Transfer-Encoding: 7bit I agree with Ben that there is no requirement for a registrar to behave in this way. It is equially possible that a presence server might flip that around, and subscribe to the "reg" package in order to obtain that information. Or an endpoint might push some or all of the information to both places - doing both REGISTER and PUBLISH. It may be (probably is) premature, but I suspect we eventually may want to start limiting these possibilities in some way. Without doing so there are going to be interoperability problems between devices and the environments in which they operate. Again it may be premature, but I do see presence as a potentially richer source of information for a proxy to use in routing requests to an AOR. With the proper set of conventions, it *could* be possible to use such a mechanism as an alternative to registration. Once presence use is ubiquitous this could provide a simpler system. Paul Ben Campbell wrote: > On Fri, 2003-05-30 at 09:31, Jonathan Rosenberg wrote: > >>The interim has motivated me to respond to this somewhat old thread. >> >>I think there is a distinction, and it lies with the model of how >>presence works. >> >>In my mind, there is an existing universe of data about users. This >>data is embedded in many, many places - in HLRs, in VLRs, in >>registrars, in corporate databases, in cell phones, in PBXs, etc. This >>data has meaning within the systems in which it resides, and there are >>protocols within those systems for manipulation of it. Protocols like >>LDAP, SIP REGISTER, SS7, etc. >> >>Separate from that is a presence system. The presence system provides >>a "front end" for this data below, allowing interested parties to >>subscribe to it, and based on authorization policies, receive >>notifications to it. PUBLISH is an interface between these existing >>systems and the presence system, providing a standardized way to move >>information between them. >> >>However, PUBLISH in no way replaces any of the above protocols. >> >>So, in the specific case of SIP, the existing system is the registrar. >>It has state, manipulated by REGISTER, and consumed by proxies for >>call routing. Separately, ontop of this system, lies a presence >>server. The registrar would push registration state into the presence >>server using PUBLISH. >> >>So, I would argue that a PUBLISH has no impact on registration state, >>unless there is some very odd, domain-specific policy that decides to >>make it that way. This isn't a PUBLISH specific issue. One can imagine >>that an enterprise has a web system where users login to the corporate >>website when they come to work. This login could trigger a sip >>registration to be created. We dont disallow this kind of thing, but >>there is no expectation that it exists as a general rule. >> > > > I will go further and say that there is no SIMPLE requirement that > REGISTER and PUBLISH are related in any way. REGISTER _might_ affect > presence state in the way you mention above, and probably will for most > systems. But if someone builds a system in which it does not, that > system is not in violation of any SIMPLE principle. Just because it is > extremely useful does not make it required. > > > > >>-Jonathan R. >> >>Ben Campbell wrote: >> >>>On Wed, 2003-05-14 at 07:25, Avshalom Houri wrote: >>> >>> >>>>If we were creating the SIP protocol today I am not sure that both >>>>REGISTER and PUBLISH would have been >>>>created. We would have created only one of them. Now we have both several >>>>questions may arise: >>> >>> >>>I agree we may not have gone the same route if we were inventing from >>>scratch. That is, of course, true of many things. However, REGISTER and >>>PUBLISH have different purposes. REGISTER puts rendezvous info into the >>>SIP network infrastructure--sort of a higer-layer route generation. >>>PUBLISH carries presence info to be distributed to watchers. Now, that >>>presence info _might_ be a superset of the rendezvous info, but it >>>doesn't have to be. >>> >>> >>> >>>>* Is it "legal" for a system to add the contacts it got through PUBLISH to >>>>the registrar? >>> >>> >>>Assuming you mean in the broader sense of a location service, sure. It's >>>legal to put contacts into a location service from _any_ source. It is >>>up to the implementer to decide what sources make sense for his >>>implementation. (This particular case might not be a good idea, but the >>>protocol does not categorically rule out bad policy decisions.) >>> >>> >>> >>>> Someone would like to reveal some contacts only to the users that can >>>>see her/his presence. >>> >>> >>>Sure. But as above, don't equate policy with protocol rules. There are >>>many policies a network could follow that would allow this bit of >>>choice. >>> >>> >>> >>>>* Probably the same question from a different angle: What should be the >>>>awareness of the user >>>> to the system behavior. The user may think that if the PUBLISH have >>>>expired he/she is no longer >>>> available online while the system may use REGISTER in order to consider >>>>the user as online. >>> >>> >>>I don't think we have fully defined what it means for a publication to >>>expire. I would suggest it meanst that the watcher should consider the >>>presence state to be indeterminant. Indeterminant is not the same thing >>>as off-line. >>> >>>I don't see why presence expiration should necessarily imply anything >>>about registration state. Certainly, there is no protocol rule that >>>prevents an AoR from working, even if presence state indicates the user >>>is offline. If a user wants to make sure this does not happen, he could >>>simply set the same expiration for registered contacts as he does for >>>published presence state. >>> >>>Personally, I don't think we can pre-define any relationship between >>>REGISTER and PUBLISH. Such things are a matter of local policy. The >>>architecture draft may suggest some possible useful policies, but should >>>not preclude creativity in creating totally different policies. >>> >>> >>> >>> >>>>Avshalom >>>> >>>> >>>> >>>> >>>> >>>>Paul Kyzivat >>>>07/05/2003 21:28 >>>> >>>>To >>>>Ben Campbell >>>>cc >>>>Avshalom Houri/Haifa/IBM@IBMIL, Simple WG >>>>Subject >>>>Re: [Simple] PUBLISH and REGISTER relationship >>>> >>>> >>>> >>>> >>>> >>>> >>>>I'm assuming you are questioning the relationship between requests that >>>>start out somethin like: >>>> >>>> REGISTER sip:example.com >>>> To: sip:foo@example.com >>>> ... >>>> >>>>and >>>> >>>> PUBLISH sip:foo@example.com >>>> To: sip:foo@example.com >>>> ... >>>> >>>>If so, I think there is some probable precedence of the REGISTER over >>>>the SUBSCRIBE. The REGISTER affects the candidate set of contacts for >>>>address sip:foo@example.com. It is not routed according to the prior set >>>>of registered contacts for that address. >>>> >>>>OTOH, the PUBLISH, at least in principle, is just an ordinary message, >>>>and is routed based on the registered contacts, plus local policy of the >>>>proxy/registrar. >>>> >>>>So, the REGISTER *could* have been installing a contact for the presence >>>>server itself. In that case, prior to the register the PUBLISH might >>>>have failed, whereas after it might succeed. I don't think the converse >>>>is a likely scenario. (That before the publish the register would fail, >>>>but after the register would succeed.) >>>> >>>>I do agree that there are similarities between REGISTER and PUBLISH. I >>>>can imagine a system that supports PUBLISH and not REGISTER, and does >>>>all routing based on presence, using the contact addresses in presence >>>>tuples. That would be an unusual sip system today, though it may be less >>>>so in the future. >>>> >>>>I also agree with Ben that there is plenty of opportunity for local >>>>policy to determine what happens here. I expect there will be plenty of >>>>systems where the registrar, presence server, and proxy are all bundled >>>>together and cooperate via local configuration. >>>> >>>> Paul >>>> >>>>Ben Campbell wrote: >>>> >>>> >>>>>I think that is entirely a question of local policy. There is no >>>>>protocol requirement for the two operations to be linked in any way, but >>>>>a given service provider might choose to do so. >>>>> >>>>>If you _do_ link them, you are making assumptions about a relationship >>>>>between the device doing the publishing and the device doing the >>>>>registering that may or may not exist. >>>>> >>>>>On Tue, 2003-05-06 at 00:21, Avshalom Houri wrote: >>>>> >>>>> >>>>> >>>>>>In a system that has both a registrar and a presence server what should >>>>> >>>>be >>>> >>>> >>>>>>the relationships between >>>>>>REGISTER and PUBLISH? >>>>>> >>>>>>* Should a REGISTER make the user on-line even though PUBLISH was not >>>>> >>>>sent >>>> >>>> >>>>>>yet? >>>>>>* Should PUBLISH be considered as a login to the system as REGISTER? >>>>>> >>>>>>To some extent it seems that PUBLISH and REGISTER have a similar >>>>>>functionality but one is for the registrar >>>>>>while the other is for the presence server. >>>>>> >>>>>>Avshalom >>>>>> >>>>>> >>>>>>_______________________________________________ >>>>>>Simple mailing list >>>>>>Simple@ietf.org >>>>>>https://www1.ietf.org/mailman/listinfo/simple >>>>> >>>>> >>>>>_______________________________________________ >>>>>Simple mailing list >>>>>Simple@ietf.org >>>>>https://www1.ietf.org/mailman/listinfo/simple >>>>> >>>> >>>_______________________________________________ >>>Simple mailing list >>>Simple@ietf.org >>>https://www1.ietf.org/mailman/listinfo/simple >>> >> > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Tue Jun 10 08:34:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24234 for ; Tue, 10 Jun 2003 08:34:41 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5ACYEL16431 for simple-archive@odin.ietf.org; Tue, 10 Jun 2003 08:34:14 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5ACYEB16428 for ; Tue, 10 Jun 2003 08:34:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24212; Tue, 10 Jun 2003 08:34:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PiIK-0004dG-00; Tue, 10 Jun 2003 08:32:08 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19PiIJ-0004dD-00; Tue, 10 Jun 2003 08:32:07 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5ACUdB16100; Tue, 10 Jun 2003 08:30:39 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5ACR7B15843 for ; Tue, 10 Jun 2003 08:27: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 IAA23711 for ; Tue, 10 Jun 2003 08:27:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PiBS-0004Tz-00 for simple@ietf.org; Tue, 10 Jun 2003 08:25:02 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by ietf-mx with esmtp (Exim 4.12) id 19PiBQ-0004RX-00 for simple@ietf.org; Tue, 10 Jun 2003 08:25:01 -0400 Received: from cannon.cisco.com (IDENT:mirapoint@cannon.cisco.com [161.44.118.24]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h5ACQ3pi029865; Tue, 10 Jun 2003 08:26:08 -0400 (EDT) Received: from cisco.com (dhcp-171-71-188-55.cisco.com [171.71.188.55]) by cannon.cisco.com (Mirapoint) with ESMTP id ABK68737; Tue, 10 Jun 2003 08:34:58 -0400 (EDT) Message-ID: <3EE4DD02.9040606@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Campbell CC: Jonathan Rosenberg , Avshalom Houri , Simple WG Subject: Re: [Simple] PUBLISH and REGISTER relationship References: <1052938287.2539.27.camel@verite.localdomain> <3ED76B4D.10504@dynamicsoft.com> <1054305744.1215.19.camel@verite.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 09 Jun 2003 15:16:18 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I agree with Ben that there is no requirement for a registrar to behave in this way. It is equially possible that a presence server might flip that around, and subscribe to the "reg" package in order to obtain that information. Or an endpoint might push some or all of the information to both places - doing both REGISTER and PUBLISH. It may be (probably is) premature, but I suspect we eventually may want to start limiting these possibilities in some way. Without doing so there are going to be interoperability problems between devices and the environments in which they operate. Again it may be premature, but I do see presence as a potentially richer source of information for a proxy to use in routing requests to an AOR. With the proper set of conventions, it *could* be possible to use such a mechanism as an alternative to registration. Once presence use is ubiquitous this could provide a simpler system. Paul Ben Campbell wrote: > On Fri, 2003-05-30 at 09:31, Jonathan Rosenberg wrote: > >>The interim has motivated me to respond to this somewhat old thread. >> >>I think there is a distinction, and it lies with the model of how >>presence works. >> >>In my mind, there is an existing universe of data about users. This >>data is embedded in many, many places - in HLRs, in VLRs, in >>registrars, in corporate databases, in cell phones, in PBXs, etc. This >>data has meaning within the systems in which it resides, and there are >>protocols within those systems for manipulation of it. Protocols like >>LDAP, SIP REGISTER, SS7, etc. >> >>Separate from that is a presence system. The presence system provides >>a "front end" for this data below, allowing interested parties to >>subscribe to it, and based on authorization policies, receive >>notifications to it. PUBLISH is an interface between these existing >>systems and the presence system, providing a standardized way to move >>information between them. >> >>However, PUBLISH in no way replaces any of the above protocols. >> >>So, in the specific case of SIP, the existing system is the registrar. >>It has state, manipulated by REGISTER, and consumed by proxies for >>call routing. Separately, ontop of this system, lies a presence >>server. The registrar would push registration state into the presence >>server using PUBLISH. >> >>So, I would argue that a PUBLISH has no impact on registration state, >>unless there is some very odd, domain-specific policy that decides to >>make it that way. This isn't a PUBLISH specific issue. One can imagine >>that an enterprise has a web system where users login to the corporate >>website when they come to work. This login could trigger a sip >>registration to be created. We dont disallow this kind of thing, but >>there is no expectation that it exists as a general rule. >> > > > I will go further and say that there is no SIMPLE requirement that > REGISTER and PUBLISH are related in any way. REGISTER _might_ affect > presence state in the way you mention above, and probably will for most > systems. But if someone builds a system in which it does not, that > system is not in violation of any SIMPLE principle. Just because it is > extremely useful does not make it required. > > > > >>-Jonathan R. >> >>Ben Campbell wrote: >> >>>On Wed, 2003-05-14 at 07:25, Avshalom Houri wrote: >>> >>> >>>>If we were creating the SIP protocol today I am not sure that both >>>>REGISTER and PUBLISH would have been >>>>created. We would have created only one of them. Now we have both several >>>>questions may arise: >>> >>> >>>I agree we may not have gone the same route if we were inventing from >>>scratch. That is, of course, true of many things. However, REGISTER and >>>PUBLISH have different purposes. REGISTER puts rendezvous info into the >>>SIP network infrastructure--sort of a higer-layer route generation. >>>PUBLISH carries presence info to be distributed to watchers. Now, that >>>presence info _might_ be a superset of the rendezvous info, but it >>>doesn't have to be. >>> >>> >>> >>>>* Is it "legal" for a system to add the contacts it got through PUBLISH to >>>>the registrar? >>> >>> >>>Assuming you mean in the broader sense of a location service, sure. It's >>>legal to put contacts into a location service from _any_ source. It is >>>up to the implementer to decide what sources make sense for his >>>implementation. (This particular case might not be a good idea, but the >>>protocol does not categorically rule out bad policy decisions.) >>> >>> >>> >>>> Someone would like to reveal some contacts only to the users that can >>>>see her/his presence. >>> >>> >>>Sure. But as above, don't equate policy with protocol rules. There are >>>many policies a network could follow that would allow this bit of >>>choice. >>> >>> >>> >>>>* Probably the same question from a different angle: What should be the >>>>awareness of the user >>>> to the system behavior. The user may think that if the PUBLISH have >>>>expired he/she is no longer >>>> available online while the system may use REGISTER in order to consider >>>>the user as online. >>> >>> >>>I don't think we have fully defined what it means for a publication to >>>expire. I would suggest it meanst that the watcher should consider the >>>presence state to be indeterminant. Indeterminant is not the same thing >>>as off-line. >>> >>>I don't see why presence expiration should necessarily imply anything >>>about registration state. Certainly, there is no protocol rule that >>>prevents an AoR from working, even if presence state indicates the user >>>is offline. If a user wants to make sure this does not happen, he could >>>simply set the same expiration for registered contacts as he does for >>>published presence state. >>> >>>Personally, I don't think we can pre-define any relationship between >>>REGISTER and PUBLISH. Such things are a matter of local policy. The >>>architecture draft may suggest some possible useful policies, but should >>>not preclude creativity in creating totally different policies. >>> >>> >>> >>> >>>>Avshalom >>>> >>>> >>>> >>>> >>>> >>>>Paul Kyzivat >>>>07/05/2003 21:28 >>>> >>>>To >>>>Ben Campbell >>>>cc >>>>Avshalom Houri/Haifa/IBM@IBMIL, Simple WG >>>>Subject >>>>Re: [Simple] PUBLISH and REGISTER relationship >>>> >>>> >>>> >>>> >>>> >>>> >>>>I'm assuming you are questioning the relationship between requests that >>>>start out somethin like: >>>> >>>> REGISTER sip:example.com >>>> To: sip:foo@example.com >>>> ... >>>> >>>>and >>>> >>>> PUBLISH sip:foo@example.com >>>> To: sip:foo@example.com >>>> ... >>>> >>>>If so, I think there is some probable precedence of the REGISTER over >>>>the SUBSCRIBE. The REGISTER affects the candidate set of contacts for >>>>address sip:foo@example.com. It is not routed according to the prior set >>>>of registered contacts for that address. >>>> >>>>OTOH, the PUBLISH, at least in principle, is just an ordinary message, >>>>and is routed based on the registered contacts, plus local policy of the >>>>proxy/registrar. >>>> >>>>So, the REGISTER *could* have been installing a contact for the presence >>>>server itself. In that case, prior to the register the PUBLISH might >>>>have failed, whereas after it might succeed. I don't think the converse >>>>is a likely scenario. (That before the publish the register would fail, >>>>but after the register would succeed.) >>>> >>>>I do agree that there are similarities between REGISTER and PUBLISH. I >>>>can imagine a system that supports PUBLISH and not REGISTER, and does >>>>all routing based on presence, using the contact addresses in presence >>>>tuples. That would be an unusual sip system today, though it may be less >>>>so in the future. >>>> >>>>I also agree with Ben that there is plenty of opportunity for local >>>>policy to determine what happens here. I expect there will be plenty of >>>>systems where the registrar, presence server, and proxy are all bundled >>>>together and cooperate via local configuration. >>>> >>>> Paul >>>> >>>>Ben Campbell wrote: >>>> >>>> >>>>>I think that is entirely a question of local policy. There is no >>>>>protocol requirement for the two operations to be linked in any way, but >>>>>a given service provider might choose to do so. >>>>> >>>>>If you _do_ link them, you are making assumptions about a relationship >>>>>between the device doing the publishing and the device doing the >>>>>registering that may or may not exist. >>>>> >>>>>On Tue, 2003-05-06 at 00:21, Avshalom Houri wrote: >>>>> >>>>> >>>>> >>>>>>In a system that has both a registrar and a presence server what should >>>>> >>>>be >>>> >>>> >>>>>>the relationships between >>>>>>REGISTER and PUBLISH? >>>>>> >>>>>>* Should a REGISTER make the user on-line even though PUBLISH was not >>>>> >>>>sent >>>> >>>> >>>>>>yet? >>>>>>* Should PUBLISH be considered as a login to the system as REGISTER? >>>>>> >>>>>>To some extent it seems that PUBLISH and REGISTER have a similar >>>>>>functionality but one is for the registrar >>>>>>while the other is for the presence server. >>>>>> >>>>>>Avshalom >>>>>> >>>>>> >>>>>>_______________________________________________ >>>>>>Simple mailing list >>>>>>Simple@ietf.org >>>>>>https://www1.ietf.org/mailman/listinfo/simple >>>>> >>>>> >>>>>_______________________________________________ >>>>>Simple mailing list >>>>>Simple@ietf.org >>>>>https://www1.ietf.org/mailman/listinfo/simple >>>>> >>>> >>>_______________________________________________ >>>Simple mailing list >>>Simple@ietf.org >>>https://www1.ietf.org/mailman/listinfo/simple >>> >> > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Jun 11 19:32:43 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 TAA09502; Wed, 11 Jun 2003 19:32:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QF3A-0005If-00; Wed, 11 Jun 2003 19:30:40 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19QF3A-0005Ia-00; Wed, 11 Jun 2003 19:30:40 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BNTHm17015; Wed, 11 Jun 2003 19:29:17 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BNSTm16979 for ; Wed, 11 Jun 2003 19:28: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 TAA09290 for ; Wed, 11 Jun 2003 19:28:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QEz1-0005Fj-00 for simple@ietf.org; Wed, 11 Jun 2003 19:26:23 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by ietf-mx with esmtp (Exim 4.12) id 19QEz0-0005Fd-00 for simple@ietf.org; Wed, 11 Jun 2003 19:26:22 -0400 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h5BNRowc004136; Wed, 11 Jun 2003 16:27:50 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AIA55875; Wed, 11 Jun 2003 16:22:51 -0700 (PDT) Subject: Re: [Simple] XCAP issue: batching Content-Type: text/plain; delsp=yes; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: simple@ietf.org To: Jonathan Rosenberg From: Rohan Mahy In-Reply-To: <3EDC2BAE.2060608@dynamicsoft.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) 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, 11 Jun 2003 16:10:31 -0700 Content-Transfer-Encoding: 7bit I like option 4. Webdav servers are easy to come by these days (for example Apache has an excellent DAV implementation). I don't see any reason the whole XCAP space can't be considered webdav-enabled. The server needs to support all the webdav extensions, but there is no reason the client has to use PROPFIND, LOCK, UNLOCK, PROPPATCH, etc.. This would require us to use MKCOL, but that is pretty simple. a few more comments inline... thanks, -rohan On Monday, June 2, 2003, at 10:01 PM, Jonathan Rosenberg wrote: > Folks, > > The main open issue in xcap at this time is batching. We discussed it > during the interim, and I have done some additional investigating > since then. > > The issue is this. In many cases, a client will want to modify a > document from X to Y. This modification may require a series of > changes to the document. However, the intermediate versions of the > document which result from those changes do not represent a state that > the client finds acceptable. This could be because they are not > compliant to the schema, or because they are wrong or inappropriate. > An example is moving a buddy from a white list to a black list. That > would require two xcap operations - one to remove from the white list, > one to add to the black list. After completing the first step, the > buddy is on NEITHER list, and if a subscription should arrive at > exactly that moment, the wrong thing would happen. This is basically > the consistency property of ACID. > > There are several ways this feature can be provided: > > Soln 1: Least Common Parent > > The "least common parent" is the XML element whose descendants include > all of the nodes to be modified in the transaction, and for whom no > descendant also has this property. So, to provide the transaction, the > client would read the value of the least common parent, modify all of > the elements as needed, and write it back to the server. > > The main drawback of this approach is overhead. The client may be > forced to read and write a lot of extra elements which are not > actually modified, but are within the subtree of the least common > parent. For buddy lists, this might mean reading the entire list, > modifying some of the entries, and writing it back. Not pretty. > > This approach works with xcap as written now. > > Approach II: Body Commands > > In this approach, we introduce a new operation that can be done on a > document. The body of the request (POST) would contain XML that > contains the sequence of operations to perform. So: > > POST > http://xcap.example.com/services/presence-lists/users/joe/ > list1.xml?batch > > > > /presence-lists/list[@name=friends]/entry[@name=bill] > > Seems like a long road. > > Option IV: COPY/MOVE > > We can enable batched operations by defining a piece of the URI > namespace thats a "scratchpad". Documents in this area can never be > read directly by anyone but the document owner. To make a bunch of > changes, the client would COPY (using webdav copy) the document into > the area, using a random filename as the target. It then makes the > changes using a series of PUT/POST/DELETE, with pipelining. When done, > it performs a Webdav MOVE to place it back into the right place. We > can specify some rules for the server on only allowing a move of a > dcument back to the place where it was copied from. > > I *think* we can support MOVE and COPY (and the additional webdav > headers) without all of the rest of webdav, but I would need to > confirm that. I didnt find any words that said MOVE or COPY can be > applied to a non-webdav resource. > > If any intermediate operation should fail, the client just DELETEs the > document from the scratch area, and the original remains as it was. We > would also probably want to have documents in the scratch area expire > automatically after some time, so as to cleanup from incomplete > transactions. > > > > > Assuming it is possible to MOVE or COPY non-webdav resources, my > current preference is for option IV. > > Comments, questions, or other proposals? > > Thanks, > Jonathan R. > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Scientist Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Wed Jun 11 19:33:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09525 for ; Wed, 11 Jun 2003 19:33:14 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5BNWmc17216 for simple-archive@odin.ietf.org; Wed, 11 Jun 2003 19:32:48 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BNWlm17213 for ; Wed, 11 Jun 2003 19:32:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09502; Wed, 11 Jun 2003 19:32:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QF3A-0005If-00; Wed, 11 Jun 2003 19:30:40 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19QF3A-0005Ia-00; Wed, 11 Jun 2003 19:30:40 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BNTHm17015; Wed, 11 Jun 2003 19:29:17 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BNSTm16979 for ; Wed, 11 Jun 2003 19:28: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 TAA09290 for ; Wed, 11 Jun 2003 19:28:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QEz1-0005Fj-00 for simple@ietf.org; Wed, 11 Jun 2003 19:26:23 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by ietf-mx with esmtp (Exim 4.12) id 19QEz0-0005Fd-00 for simple@ietf.org; Wed, 11 Jun 2003 19:26:22 -0400 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h5BNRowc004136; Wed, 11 Jun 2003 16:27:50 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AIA55875; Wed, 11 Jun 2003 16:22:51 -0700 (PDT) Subject: Re: [Simple] XCAP issue: batching Content-Type: text/plain; delsp=yes; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: simple@ietf.org To: Jonathan Rosenberg From: Rohan Mahy In-Reply-To: <3EDC2BAE.2060608@dynamicsoft.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) 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, 11 Jun 2003 16:10:31 -0700 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I like option 4. Webdav servers are easy to come by these days (for example Apache has an excellent DAV implementation). I don't see any reason the whole XCAP space can't be considered webdav-enabled. The server needs to support all the webdav extensions, but there is no reason the client has to use PROPFIND, LOCK, UNLOCK, PROPPATCH, etc.. This would require us to use MKCOL, but that is pretty simple. a few more comments inline... thanks, -rohan On Monday, June 2, 2003, at 10:01 PM, Jonathan Rosenberg wrote: > Folks, > > The main open issue in xcap at this time is batching. We discussed it > during the interim, and I have done some additional investigating > since then. > > The issue is this. In many cases, a client will want to modify a > document from X to Y. This modification may require a series of > changes to the document. However, the intermediate versions of the > document which result from those changes do not represent a state that > the client finds acceptable. This could be because they are not > compliant to the schema, or because they are wrong or inappropriate. > An example is moving a buddy from a white list to a black list. That > would require two xcap operations - one to remove from the white list, > one to add to the black list. After completing the first step, the > buddy is on NEITHER list, and if a subscription should arrive at > exactly that moment, the wrong thing would happen. This is basically > the consistency property of ACID. > > There are several ways this feature can be provided: > > Soln 1: Least Common Parent > > The "least common parent" is the XML element whose descendants include > all of the nodes to be modified in the transaction, and for whom no > descendant also has this property. So, to provide the transaction, the > client would read the value of the least common parent, modify all of > the elements as needed, and write it back to the server. > > The main drawback of this approach is overhead. The client may be > forced to read and write a lot of extra elements which are not > actually modified, but are within the subtree of the least common > parent. For buddy lists, this might mean reading the entire list, > modifying some of the entries, and writing it back. Not pretty. > > This approach works with xcap as written now. > > Approach II: Body Commands > > In this approach, we introduce a new operation that can be done on a > document. The body of the request (POST) would contain XML that > contains the sequence of operations to perform. So: > > POST > http://xcap.example.com/services/presence-lists/users/joe/ > list1.xml?batch > > > > /presence-lists/list[@name=friends]/entry[@name=bill] > > Seems like a long road. > > Option IV: COPY/MOVE > > We can enable batched operations by defining a piece of the URI > namespace thats a "scratchpad". Documents in this area can never be > read directly by anyone but the document owner. To make a bunch of > changes, the client would COPY (using webdav copy) the document into > the area, using a random filename as the target. It then makes the > changes using a series of PUT/POST/DELETE, with pipelining. When done, > it performs a Webdav MOVE to place it back into the right place. We > can specify some rules for the server on only allowing a move of a > dcument back to the place where it was copied from. > > I *think* we can support MOVE and COPY (and the additional webdav > headers) without all of the rest of webdav, but I would need to > confirm that. I didnt find any words that said MOVE or COPY can be > applied to a non-webdav resource. > > If any intermediate operation should fail, the client just DELETEs the > document from the scratch area, and the original remains as it was. We > would also probably want to have documents in the scratch area expire > automatically after some time, so as to cleanup from incomplete > transactions. > > > > > Assuming it is possible to MOVE or COPY non-webdav resources, my > current preference is for option IV. > > Comments, questions, or other proposals? > > Thanks, > Jonathan R. > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Scientist Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Jun 11 19:54:33 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 TAA09792; Wed, 11 Jun 2003 19:54:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QFOG-0005PF-00; Wed, 11 Jun 2003 19:52:28 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19QFOG-0005PC-00; Wed, 11 Jun 2003 19:52:28 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BNpFm18746; Wed, 11 Jun 2003 19:51:15 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BNoam18687 for ; Wed, 11 Jun 2003 19:50:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09757 for ; Wed, 11 Jun 2003 19:50:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QFKQ-0005Nn-00 for simple@ietf.org; Wed, 11 Jun 2003 19:48:30 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by ietf-mx with esmtp (Exim 4.12) id 19QFKP-0005NL-00 for simple@ietf.org; Wed, 11 Jun 2003 19:48:29 -0400 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h5BNo3jc004981; Wed, 11 Jun 2003 16:50:03 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AIA58297; Wed, 11 Jun 2003 16:45:04 -0700 (PDT) Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: lisa@xythos.com To: simple@ietf.org From: Rohan Mahy Content-Transfer-Encoding: 7bit Message-Id: <8EFA31FE-9C67-11D7-A0EF-0003938AF740@cisco.com> X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Subject: [Simple] XCAP and Webdav (was: XCAP batching) Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 11 Jun 2003 16:51:02 -0700 Content-Transfer-Encoding: 7bit Hi Folks, I had a side conversation with Lisa Dusseault today (one of the co-chairs of Webdav) about the XCAP batching thread. Here are her comments. Please keep here cc:ed on this thread since she does not follow the SIMPLE list. thanks, -rohan ----------- >> During the interim, we talked about using webdav. The idea there was >> to first have the client LOCK the document, then perform a series of >> changes (PUT, POST, DELETE), and then UNLOCK. AFter the LOCK, all of >> the modification requests could be pipelined. The overhead here is >> probably pretty small, since HTTP has few mandatory headers. >> >> I looked into webdav, and ran into the following issues: >> >> 1. Webdav doesnt specify a read lock. We would need to standardize >> that in order to use it. Why would you need read locks? Clients who are simply reading the buddy lists should just continue to be able to read it until the change (set of changes) is made. >> 2. The document would need to support a bunch of other webdav >> operations, such as PROPFIND. You cant JUST do locking. You dont need >> all of webdav, though. Might as well use all of WebDAV tho -- I believe you could use an out-of-the-box WebDAV server or server library, including - Alphaworks DAV4J, - Apache 2.0 which includes mod_dav - Microsoft IIS etc That is, if the design is done right, the server where buddy lists is stored may not need any new code. If the server is also a IM server, the IM server could simply tack on the WebDAV component using an extra servlet (the alphaworks dav4j approach) or cgi module (the mod_dav approach). >> 3. There is no rollback or versioning. So, if there is an intermediate >> failure, there is no easy way to go back. We could fix that by >> introducing versioning into webdav. Uhh, versioning was standardized in WebDAV already -- RFC3253. The 'core' versioning module is probably all you'd need for "an easy way to go back". At any rate, intermediate failures are not a common problem in Web site authoring because if a HTTP server does not receive the full body it doesn't save it. >> We can enable batched operations by defining a piece of the URI >> namespace thats a "scratchpad". Documents in this area can never be >> read directly by anyone but the document owner. To make a bunch of >> changes, the client would COPY (using webdav copy) the document into >> the area, using a random filename as the target. It then makes the >> changes using a series of PUT/POST/DELETE, with pipelining. When done, >> it performs a Webdav MOVE to place it back into the right place. We >> can specify some rules for the server on only allowing a move of a >> dcument back to the place where it was copied from. Yes this is completely feasible. >> I *think* we can support MOVE and COPY (and the additional webdav >> headers) without all of the rest of webdav, but I would need to >> confirm that. I didnt find any words that said MOVE or COPY can be >> applied to a non-webdav resource. You might want to support LOCK too. LOCK the original document, COPY it to the 'scratch' file, make changes, COPY it over the original (to avoid overwriting the original's version history), DELETE the scratch file, UNLOCK the original. If this sequence is followed by all clients then scratch documents can be used in combination with locks to advertise to other clients that somebody is currently working on the document. Note that this 'scratch' document functionality is standardized as a "working resource" in RFC3253 which extends WebDAV. This is an optional feature but easy to implement -- the working resource feature. (And you'd probably still want 'the rest of webdav' because PROPFIND at least is needed to see document changes, etags, lock tokens, etc. PROPPATCH and MKCOL may not be strictly necessary but they're not hard either.) >> >> If any intermediate operation should fail, the client just DELETEs the >> document from the scratch area, and the original remains as it was. We >> would also probably want to have documents in the scratch area expire >> automatically after some time, so as to cleanup from incomplete >> transactions. >> >> Assuming it is possible to MOVE or COPY non-webdav resources, my >> current preference is for option IV. Why are non-webdav resources involved in the MOVE or COPY? Why wouldn't the scratch file as well as the official file *both* webdav resources? But to answer the implied question, the specification doesn't forbid making a non-WebDAV HTTP resource the _destination_ of a MOVE or COPY. Since the MOVE or COPY request is sent to the source resource, by supporting MOVE or COPY the source resource implicitly supports WebDAV and therefore is a WebDAV resource. Overall, I'm still confused by the level of complexity being considered here. Perhaps WebDAV/authoring seems more complicated than it really is. Here's how I'd suggest proceeding: 1. Define a WebDAV collection to be the buddy list location. 2. Define a main/default file for the buddy list. This file might be identified through a standard property on the collection. 3.Define other files for different 'profiles' (buddy lists with different rules for different devices). Again these could be identified as real buddy lists through a WebDAV property on the collection. 4. Place all the internally-consistent information within an XML format as the body of the WebDAV buddy list file. If the block and allow lists must be changed together (when adding from one and removing from the other) then put them in the same file. 5. To change the default buddy list, or any profile buddy list, the client does a LOCK, GET, PUT, UNLOCK. As soon as the PUT occurs the new buddy list is visible to other clients but since the whole file is internally consistent this is great. 6. If integrity is a concern, require support for the standard MD-5 header as well, so that the client can confirm the server's signature for the file as stored. Alternatively, require support for the DeltaV/RFC3253 core package and the working resource package, then you can do CHECKOUT, PUT, CHECKIN (with or without LOCK/UNLOCK) to edit a buddy list. None of this requires any protocol elements that aren't already standardized -- just a new property or two, and a new XML format for the body of each buddy list or profile. Lisa _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Wed Jun 11 19:55:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09825 for ; Wed, 11 Jun 2003 19:55:04 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5BNsaE18824 for simple-archive@odin.ietf.org; Wed, 11 Jun 2003 19:54:36 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BNsZm18821 for ; Wed, 11 Jun 2003 19:54: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 TAA09792; Wed, 11 Jun 2003 19:54:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QFOG-0005PF-00; Wed, 11 Jun 2003 19:52:28 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19QFOG-0005PC-00; Wed, 11 Jun 2003 19:52:28 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BNpFm18746; Wed, 11 Jun 2003 19:51:15 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BNoam18687 for ; Wed, 11 Jun 2003 19:50:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09757 for ; Wed, 11 Jun 2003 19:50:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QFKQ-0005Nn-00 for simple@ietf.org; Wed, 11 Jun 2003 19:48:30 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by ietf-mx with esmtp (Exim 4.12) id 19QFKP-0005NL-00 for simple@ietf.org; Wed, 11 Jun 2003 19:48:29 -0400 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h5BNo3jc004981; Wed, 11 Jun 2003 16:50:03 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AIA58297; Wed, 11 Jun 2003 16:45:04 -0700 (PDT) Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: lisa@xythos.com To: simple@ietf.org From: Rohan Mahy Content-Transfer-Encoding: 7bit Message-Id: <8EFA31FE-9C67-11D7-A0EF-0003938AF740@cisco.com> X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Subject: [Simple] XCAP and Webdav (was: XCAP batching) Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 11 Jun 2003 16:51:02 -0700 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Folks, I had a side conversation with Lisa Dusseault today (one of the co-chairs of Webdav) about the XCAP batching thread. Here are her comments. Please keep here cc:ed on this thread since she does not follow the SIMPLE list. thanks, -rohan ----------- >> During the interim, we talked about using webdav. The idea there was >> to first have the client LOCK the document, then perform a series of >> changes (PUT, POST, DELETE), and then UNLOCK. AFter the LOCK, all of >> the modification requests could be pipelined. The overhead here is >> probably pretty small, since HTTP has few mandatory headers. >> >> I looked into webdav, and ran into the following issues: >> >> 1. Webdav doesnt specify a read lock. We would need to standardize >> that in order to use it. Why would you need read locks? Clients who are simply reading the buddy lists should just continue to be able to read it until the change (set of changes) is made. >> 2. The document would need to support a bunch of other webdav >> operations, such as PROPFIND. You cant JUST do locking. You dont need >> all of webdav, though. Might as well use all of WebDAV tho -- I believe you could use an out-of-the-box WebDAV server or server library, including - Alphaworks DAV4J, - Apache 2.0 which includes mod_dav - Microsoft IIS etc That is, if the design is done right, the server where buddy lists is stored may not need any new code. If the server is also a IM server, the IM server could simply tack on the WebDAV component using an extra servlet (the alphaworks dav4j approach) or cgi module (the mod_dav approach). >> 3. There is no rollback or versioning. So, if there is an intermediate >> failure, there is no easy way to go back. We could fix that by >> introducing versioning into webdav. Uhh, versioning was standardized in WebDAV already -- RFC3253. The 'core' versioning module is probably all you'd need for "an easy way to go back". At any rate, intermediate failures are not a common problem in Web site authoring because if a HTTP server does not receive the full body it doesn't save it. >> We can enable batched operations by defining a piece of the URI >> namespace thats a "scratchpad". Documents in this area can never be >> read directly by anyone but the document owner. To make a bunch of >> changes, the client would COPY (using webdav copy) the document into >> the area, using a random filename as the target. It then makes the >> changes using a series of PUT/POST/DELETE, with pipelining. When done, >> it performs a Webdav MOVE to place it back into the right place. We >> can specify some rules for the server on only allowing a move of a >> dcument back to the place where it was copied from. Yes this is completely feasible. >> I *think* we can support MOVE and COPY (and the additional webdav >> headers) without all of the rest of webdav, but I would need to >> confirm that. I didnt find any words that said MOVE or COPY can be >> applied to a non-webdav resource. You might want to support LOCK too. LOCK the original document, COPY it to the 'scratch' file, make changes, COPY it over the original (to avoid overwriting the original's version history), DELETE the scratch file, UNLOCK the original. If this sequence is followed by all clients then scratch documents can be used in combination with locks to advertise to other clients that somebody is currently working on the document. Note that this 'scratch' document functionality is standardized as a "working resource" in RFC3253 which extends WebDAV. This is an optional feature but easy to implement -- the working resource feature. (And you'd probably still want 'the rest of webdav' because PROPFIND at least is needed to see document changes, etags, lock tokens, etc. PROPPATCH and MKCOL may not be strictly necessary but they're not hard either.) >> >> If any intermediate operation should fail, the client just DELETEs the >> document from the scratch area, and the original remains as it was. We >> would also probably want to have documents in the scratch area expire >> automatically after some time, so as to cleanup from incomplete >> transactions. >> >> Assuming it is possible to MOVE or COPY non-webdav resources, my >> current preference is for option IV. Why are non-webdav resources involved in the MOVE or COPY? Why wouldn't the scratch file as well as the official file *both* webdav resources? But to answer the implied question, the specification doesn't forbid making a non-WebDAV HTTP resource the _destination_ of a MOVE or COPY. Since the MOVE or COPY request is sent to the source resource, by supporting MOVE or COPY the source resource implicitly supports WebDAV and therefore is a WebDAV resource. Overall, I'm still confused by the level of complexity being considered here. Perhaps WebDAV/authoring seems more complicated than it really is. Here's how I'd suggest proceeding: 1. Define a WebDAV collection to be the buddy list location. 2. Define a main/default file for the buddy list. This file might be identified through a standard property on the collection. 3.Define other files for different 'profiles' (buddy lists with different rules for different devices). Again these could be identified as real buddy lists through a WebDAV property on the collection. 4. Place all the internally-consistent information within an XML format as the body of the WebDAV buddy list file. If the block and allow lists must be changed together (when adding from one and removing from the other) then put them in the same file. 5. To change the default buddy list, or any profile buddy list, the client does a LOCK, GET, PUT, UNLOCK. As soon as the PUT occurs the new buddy list is visible to other clients but since the whole file is internally consistent this is great. 6. If integrity is a concern, require support for the standard MD-5 header as well, so that the client can confirm the server's signature for the file as stored. Alternatively, require support for the DeltaV/RFC3253 core package and the working resource package, then you can do CHECKOUT, PUT, CHECKIN (with or without LOCK/UNLOCK) to edit a buddy list. None of this requires any protocol elements that aren't already standardized -- just a new property or two, and a new XML format for the body of each buddy list or profile. Lisa _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Jun 12 10:07:32 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 KAA11353; Thu, 12 Jun 2003 10:07:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QShi-0002gy-00; Thu, 12 Jun 2003 10:05:26 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19QShh-0002gv-00; Thu, 12 Jun 2003 10:05:25 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CE4Cm23828; Thu, 12 Jun 2003 10:04:12 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CE3Xm23794 for ; Thu, 12 Jun 2003 10:03: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 KAA10928 for ; Thu, 12 Jun 2003 10:03:29 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QSdn-0002el-00 for simple@ietf.org; Thu, 12 Jun 2003 10:01:23 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19QSdm-0002eU-00 for simple@ietf.org; Thu, 12 Jun 2003 10:01:22 -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 h5CE3Ia19853 for ; Thu, 12 Jun 2003 17:03:18 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 12 Jun 2003 17:03:17 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 12 Jun 2003 17:03:17 +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" Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701796D94@esebe019.ntc.nokia.com> Thread-Topic: Presence filtering idea Thread-Index: AcMwWEvlmkCW0JnxTJWir3ted0ncwgAj0s9Q To: Cc: , , X-OriginalArrivalTime: 12 Jun 2003 14:03:17.0678 (UTC) FILETIME=[5FA7B4E0:01C330EB] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5CE3Xm23796 Subject: [Simple] RE: Presence filtering idea Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 12 Jun 2003 17:03:17 +0300 Content-Transfer-Encoding: 8bit Moving the discussion to the mailing list. Comments inline... > -----Original Message----- > From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Wednesday, June 11, 2003 11:29 PM > To: Khartabil Hisham (NMP/Helsinki) > Cc: hgs@cs.columbia.edu; Niemi Aki (NMP/Helsinki) > Subject: Re: Presence filtering idea > > > Actually, the recent discussions amongst the "what is a tuple" design > team have convinced me further that xpath is the wrong thing > for filters. > > The reason is, that the same information can appear within the > presence document in a lot of different possible places, depending on > the "axes" along which the presence agent chooses to organize the > data. We have discussed multiple different views of a presentity - a > device-centric view (where each tuple represents a device), a service > centric view (where each tuple represents a service, like voice or > IM), and a media centric view (where each tuple represents a media > type - audio, video, messaging). The same piece of information - say, > whether I am in a call or out of a call, might appear in different > places in different ways depending on how the document is structured. I still don't understand how the subscriber can render the information given in the tuple of the NOTIFY if it receives the info in an XML format it does not understand, especially info it specifically asked for in a filter. Someone in the interim suggested that you can just show the whole XML document to the user, but that's not feasable, especially for automata. eg: I want to know when Jonathan is available for IM so that I automatically send him an IM to call me. Using Jonathan's idea of not using XPath, I need to, for example, use the keyword "im" in the filter. Jonathan now become available for IM and I receive the IM info in a device tuple that looks like: OPEN But my device only understands it in the form that the tuple represents a service: IM OPEN Either there must be a standardised way of representing something, or this automaty will not work. Using XPath as the indicator of what the subscriber exactly wants, the server can probably construct the tuple is the indicated format. The alternative is that the subscriber has to inform the compositor the representation of tuples it accepts. We we need to go down that path? Also, one more thing to point out: filtering is not just for presence. It is for any event package and the solution needs to be generic enough. I say we fix the tuple problem instead of making other solutions that are generic more complicated. > > Furthermore, you run into issues when you introduce > dependencies. Lets > say a PA knows whether the phone is in-call or out-of-call. The > filter says that you want to know call state. If the PA produces a > device-centric document, it might decide to omit in-call or > out-of-call and instead represent this information by setting the > status to busy. In a service centric view, the status might > instead be > reflected in an actual in-call/out-of-call attribute. > > So, the heart of the issue here - do we think filters should also > apply to the data used as INPUTs to a composition process, or not? No, filters are only applied to the already composed NOTIFY contents. Regards, Hisham > > -Jonathan R. > > hisham.khartabil@nokia.com wrote: > > Henning, > > > > I don't think you have read the proposed draft carefully, or at > > all. I urge you to spend a few minutes looking through it. > > > > XPath is only one small part of the overall solution. It is used > > purely for pointing out an element in an XML document. There are > > other elements and attributes in the proposed filter MIME that make > > the proposed filtering solution complete (or almost complete). > > > > I don't understand Aki's proposal beyond the fact that it is only > > another way of expressing a filter. The fact remains that you want > > to filter out parts of an xml document. We can expand filtering to > > include such solution, but it is not a replacement. > > > > I acknowledge Jonathan's comments in the interim about a URI > > identifying to whom the filter is. We will tackle that (borrowing > > some ideas from XCAP authorization list solution when released). > > > > Regards, Hisham > > > > > >> -----Original Message----- From: ext Henning Schulzrinne > >> [mailto:hgs@cs.columbia.edu] Sent: Wednesday, June 11, 2003 12:56 > >> AM To: Jonathan Rosenberg Cc: Niemi Aki (NMP/Helsinki); Khartabil > >> Hisham (NMP/Helsinki) Subject: Re: Presence filtering idea > >> > >> > >> My remark as not a disagreement, just an elaboration (or to make > >> sure that I understood what you were saying...). > >> > >> Jonathan Rosenberg wrote: > >> > >> > >>> I'm confused - I agree with you. I dont like Xpath for filters, > >>> and strongly argued in favor of a semantic model during the > >> > >> interim. The > >> > >>> idea was to use the XML document format for authorization > >> > >> policy as the > >> > >>> filter format as well, to unify them. > >>> > >>> -Jonathan R. > >>> > >>> Henning Schulzrinne wrote: > >>> > >>> > >>>> I actually find XPATH in this context less expressive and > >> > >> needlessly > >> > >>>> more complex than a simple boolean expression, but that's > >> > >> a syntax issue. > >> > >>>> Jonathan Rosenberg wrote: > >>>> > >>>> > >>>>> Aki, > >>>>> > >>>>> This is exactly the kind of thing I meant by a semantic > >> > >> filter. Other > >> > >>>>> types of things would be to specify the actual status > >> > >> elements within > >> > >>>>> the namespace, and to specify the types of tuples which > >> > >> are desired > >> > >>>>> (this is, of course, presuming we can get some agreement > >> > >> on what a > >> > >>>>> tuple is...). > >>>>> > >>>>> The current data manipulation requirements draft spells out > >>>>> the specific semantic authorization operations that are > >> > >> desired, many of > >> > >>>>> which map into filters. > >>>>> > >>>>> -Jonathan R. > >>>>> > >>>>> aki.niemi@nokia.com wrote: > >>>>> > >>>>> > >>>>>> Hi, > >>>>>> > >>>>>> I wanted to circulate a wild idea I got after the > >>>>>> syntactic vs. semantic discussion at the interim. > >>>>>> > >>>>>> What if we do filtering based on namespaces? > >>>>>> > >>>>>> A filter would simply be a list of URNs, defining the > >>>>>> namespaces that are interesting to the subscriber. A bare > >>>>>> bones PIDF filter would define cpim-pidf (could be the > >>>>>> default) as the only allowed namespace, effectively > >>>>>> stripping out everyting else - standard or proprietary. > >>>>>> The subscriber could allow more namespaces based on what > >>>>>> it supports. > >>>>>> > >>>>>> I think this might be a pretty nice middle ground > >> > >> between a purely > >> > >>>>>> syntactical approach (XPath-based) and the semantic > >> > >> approach (This > >> > >>>>>> pending of course Jonathan's proposal ;). Also, I think > >> > >> this would > >> > >>>>>> be a nice way to align the authorization and filtering > >>>>>> solutions. > >>>>>> > >>>>>> Thoughts? > >>>>>> > >>>>>> Cheers, Aki > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>> > >> > > > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Scientist 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 mailnull@www1.ietf.org Thu Jun 12 10:08:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11508 for ; Thu, 12 Jun 2003 10:08:03 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5CE7aP24761 for simple-archive@odin.ietf.org; Thu, 12 Jun 2003 10:07:36 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CE7am24758 for ; Thu, 12 Jun 2003 10:07:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11353; Thu, 12 Jun 2003 10:07:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QShi-0002gy-00; Thu, 12 Jun 2003 10:05:26 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19QShh-0002gv-00; Thu, 12 Jun 2003 10:05:25 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CE4Cm23828; Thu, 12 Jun 2003 10:04:12 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CE3Xm23794 for ; Thu, 12 Jun 2003 10:03: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 KAA10928 for ; Thu, 12 Jun 2003 10:03:29 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QSdn-0002el-00 for simple@ietf.org; Thu, 12 Jun 2003 10:01:23 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19QSdm-0002eU-00 for simple@ietf.org; Thu, 12 Jun 2003 10:01:22 -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 h5CE3Ia19853 for ; Thu, 12 Jun 2003 17:03:18 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 12 Jun 2003 17:03:17 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 12 Jun 2003 17:03:17 +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" Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701796D94@esebe019.ntc.nokia.com> Thread-Topic: Presence filtering idea Thread-Index: AcMwWEvlmkCW0JnxTJWir3ted0ncwgAj0s9Q To: Cc: , , X-OriginalArrivalTime: 12 Jun 2003 14:03:17.0678 (UTC) FILETIME=[5FA7B4E0:01C330EB] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5CE3Xm23796 Subject: [Simple] RE: Presence filtering idea Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 12 Jun 2003 17:03:17 +0300 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Moving the discussion to the mailing list. Comments inline... > -----Original Message----- > From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Wednesday, June 11, 2003 11:29 PM > To: Khartabil Hisham (NMP/Helsinki) > Cc: hgs@cs.columbia.edu; Niemi Aki (NMP/Helsinki) > Subject: Re: Presence filtering idea > > > Actually, the recent discussions amongst the "what is a tuple" design > team have convinced me further that xpath is the wrong thing > for filters. > > The reason is, that the same information can appear within the > presence document in a lot of different possible places, depending on > the "axes" along which the presence agent chooses to organize the > data. We have discussed multiple different views of a presentity - a > device-centric view (where each tuple represents a device), a service > centric view (where each tuple represents a service, like voice or > IM), and a media centric view (where each tuple represents a media > type - audio, video, messaging). The same piece of information - say, > whether I am in a call or out of a call, might appear in different > places in different ways depending on how the document is structured. I still don't understand how the subscriber can render the information given in the tuple of the NOTIFY if it receives the info in an XML format it does not understand, especially info it specifically asked for in a filter. Someone in the interim suggested that you can just show the whole XML document to the user, but that's not feasable, especially for automata. eg: I want to know when Jonathan is available for IM so that I automatically send him an IM to call me. Using Jonathan's idea of not using XPath, I need to, for example, use the keyword "im" in the filter. Jonathan now become available for IM and I receive the IM info in a device tuple that looks like: OPEN But my device only understands it in the form that the tuple represents a service: IM OPEN Either there must be a standardised way of representing something, or this automaty will not work. Using XPath as the indicator of what the subscriber exactly wants, the server can probably construct the tuple is the indicated format. The alternative is that the subscriber has to inform the compositor the representation of tuples it accepts. We we need to go down that path? Also, one more thing to point out: filtering is not just for presence. It is for any event package and the solution needs to be generic enough. I say we fix the tuple problem instead of making other solutions that are generic more complicated. > > Furthermore, you run into issues when you introduce > dependencies. Lets > say a PA knows whether the phone is in-call or out-of-call. The > filter says that you want to know call state. If the PA produces a > device-centric document, it might decide to omit in-call or > out-of-call and instead represent this information by setting the > status to busy. In a service centric view, the status might > instead be > reflected in an actual in-call/out-of-call attribute. > > So, the heart of the issue here - do we think filters should also > apply to the data used as INPUTs to a composition process, or not? No, filters are only applied to the already composed NOTIFY contents. Regards, Hisham > > -Jonathan R. > > hisham.khartabil@nokia.com wrote: > > Henning, > > > > I don't think you have read the proposed draft carefully, or at > > all. I urge you to spend a few minutes looking through it. > > > > XPath is only one small part of the overall solution. It is used > > purely for pointing out an element in an XML document. There are > > other elements and attributes in the proposed filter MIME that make > > the proposed filtering solution complete (or almost complete). > > > > I don't understand Aki's proposal beyond the fact that it is only > > another way of expressing a filter. The fact remains that you want > > to filter out parts of an xml document. We can expand filtering to > > include such solution, but it is not a replacement. > > > > I acknowledge Jonathan's comments in the interim about a URI > > identifying to whom the filter is. We will tackle that (borrowing > > some ideas from XCAP authorization list solution when released). > > > > Regards, Hisham > > > > > >> -----Original Message----- From: ext Henning Schulzrinne > >> [mailto:hgs@cs.columbia.edu] Sent: Wednesday, June 11, 2003 12:56 > >> AM To: Jonathan Rosenberg Cc: Niemi Aki (NMP/Helsinki); Khartabil > >> Hisham (NMP/Helsinki) Subject: Re: Presence filtering idea > >> > >> > >> My remark as not a disagreement, just an elaboration (or to make > >> sure that I understood what you were saying...). > >> > >> Jonathan Rosenberg wrote: > >> > >> > >>> I'm confused - I agree with you. I dont like Xpath for filters, > >>> and strongly argued in favor of a semantic model during the > >> > >> interim. The > >> > >>> idea was to use the XML document format for authorization > >> > >> policy as the > >> > >>> filter format as well, to unify them. > >>> > >>> -Jonathan R. > >>> > >>> Henning Schulzrinne wrote: > >>> > >>> > >>>> I actually find XPATH in this context less expressive and > >> > >> needlessly > >> > >>>> more complex than a simple boolean expression, but that's > >> > >> a syntax issue. > >> > >>>> Jonathan Rosenberg wrote: > >>>> > >>>> > >>>>> Aki, > >>>>> > >>>>> This is exactly the kind of thing I meant by a semantic > >> > >> filter. Other > >> > >>>>> types of things would be to specify the actual status > >> > >> elements within > >> > >>>>> the namespace, and to specify the types of tuples which > >> > >> are desired > >> > >>>>> (this is, of course, presuming we can get some agreement > >> > >> on what a > >> > >>>>> tuple is...). > >>>>> > >>>>> The current data manipulation requirements draft spells out > >>>>> the specific semantic authorization operations that are > >> > >> desired, many of > >> > >>>>> which map into filters. > >>>>> > >>>>> -Jonathan R. > >>>>> > >>>>> aki.niemi@nokia.com wrote: > >>>>> > >>>>> > >>>>>> Hi, > >>>>>> > >>>>>> I wanted to circulate a wild idea I got after the > >>>>>> syntactic vs. semantic discussion at the interim. > >>>>>> > >>>>>> What if we do filtering based on namespaces? > >>>>>> > >>>>>> A filter would simply be a list of URNs, defining the > >>>>>> namespaces that are interesting to the subscriber. A bare > >>>>>> bones PIDF filter would define cpim-pidf (could be the > >>>>>> default) as the only allowed namespace, effectively > >>>>>> stripping out everyting else - standard or proprietary. > >>>>>> The subscriber could allow more namespaces based on what > >>>>>> it supports. > >>>>>> > >>>>>> I think this might be a pretty nice middle ground > >> > >> between a purely > >> > >>>>>> syntactical approach (XPath-based) and the semantic > >> > >> approach (This > >> > >>>>>> pending of course Jonathan's proposal ;). Also, I think > >> > >> this would > >> > >>>>>> be a nice way to align the authorization and filtering > >>>>>> solutions. > >>>>>> > >>>>>> Thoughts? > >>>>>> > >>>>>> Cheers, Aki > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>> > >> > > > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Scientist Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Jun 12 11:16:34 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 LAA15462; Thu, 12 Jun 2003 11:16:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QTmX-0003PY-00; Thu, 12 Jun 2003 11:14:29 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19QTmW-0003PV-00; Thu, 12 Jun 2003 11:14:28 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CFDDm31081; Thu, 12 Jun 2003 11:13:13 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CFCAm31033 for ; Thu, 12 Jun 2003 11:12:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15327 for ; Thu, 12 Jun 2003 11:12:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QTiE-0003NK-00 for simple@ietf.org; Thu, 12 Jun 2003 11:10:02 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19QTiD-0003MG-00 for simple@ietf.org; Thu, 12 Jun 2003 11:10:01 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h5CFBaU03345 for ; Thu, 12 Jun 2003 10:11:36 -0500 From: Robert Sparks To: simple@ietf.org Content-Type: text/plain Message-Id: <1055430694.1048.26.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] XCAP drafts to become working group items 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: 12 Jun 2003 10:11:34 -0500 Content-Transfer-Encoding: 7bit Folks - Consensus at the interim was to accept the XCAP drafts as the starting point for meeting this milestone: Jul 03 Submission of presencelist auth/modify mechanism drafts to IESG for publication as Proposed Standard Jonathan has indicated he'll have the drafts ready for submission as WG -00 drafts before the cut-off. If you've not already read and commented on these drafts, please take a few moments to do so now. RjS _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu Jun 12 11:17:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15514 for ; Thu, 12 Jun 2003 11:17:05 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5CFGbe31201 for simple-archive@odin.ietf.org; Thu, 12 Jun 2003 11:16:37 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CFGbm31198 for ; Thu, 12 Jun 2003 11:16: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 LAA15462; Thu, 12 Jun 2003 11:16:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QTmX-0003PY-00; Thu, 12 Jun 2003 11:14:29 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19QTmW-0003PV-00; Thu, 12 Jun 2003 11:14:28 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CFDDm31081; Thu, 12 Jun 2003 11:13:13 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CFCAm31033 for ; Thu, 12 Jun 2003 11:12:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15327 for ; Thu, 12 Jun 2003 11:12:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QTiE-0003NK-00 for simple@ietf.org; Thu, 12 Jun 2003 11:10:02 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19QTiD-0003MG-00 for simple@ietf.org; Thu, 12 Jun 2003 11:10:01 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h5CFBaU03345 for ; Thu, 12 Jun 2003 10:11:36 -0500 From: Robert Sparks To: simple@ietf.org Content-Type: text/plain Message-Id: <1055430694.1048.26.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] XCAP drafts to become working group items 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: 12 Jun 2003 10:11:34 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Folks - Consensus at the interim was to accept the XCAP drafts as the starting point for meeting this milestone: Jul 03 Submission of presencelist auth/modify mechanism drafts to IESG for publication as Proposed Standard Jonathan has indicated he'll have the drafts ready for submission as WG -00 drafts before the cut-off. If you've not already read and commented on these drafts, please take a few moments to do so now. RjS _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Jun 12 11:27:17 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 LAA15820; Thu, 12 Jun 2003 11:27:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QTwt-0003Ul-00; Thu, 12 Jun 2003 11:25:11 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19QTws-0003Uh-00; Thu, 12 Jun 2003 11:25:10 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CFNum31704; Thu, 12 Jun 2003 11:23:56 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CFIOm31292 for ; Thu, 12 Jun 2003 11:18:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15540 for ; Thu, 12 Jun 2003 11:18:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QToG-0003Q7-00 for simple@ietf.org; Thu, 12 Jun 2003 11:16:16 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19QToF-0003Q2-00 for simple@ietf.org; Thu, 12 Jun 2003 11:16:15 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h5CFHqU03377 for ; Thu, 12 Jun 2003 10:17:52 -0500 From: Robert Sparks To: simple@ietf.org Content-Type: text/plain Message-Id: <1055431071.1048.34.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] new -00 WG draft requirement 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: 12 Jun 2003 10:17:51 -0500 Content-Transfer-Encoding: 7bit We have a new requirement from the ID repository administrators for this meeting. The chairs need to let them know _in advance_ about WG -00 drafts that will be submitted between now and the -00 cut-off. The XCAP drafts are all that I'm expecting. If I've forgotten something, please remind me quickly. Thanks, RjS _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu Jun 12 11:27:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15850 for ; Thu, 12 Jun 2003 11:27:48 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5CFRKp31909 for simple-archive@odin.ietf.org; Thu, 12 Jun 2003 11:27:20 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CFRKm31906 for ; Thu, 12 Jun 2003 11:27: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 LAA15820; Thu, 12 Jun 2003 11:27:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QTwt-0003Ul-00; Thu, 12 Jun 2003 11:25:11 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19QTws-0003Uh-00; Thu, 12 Jun 2003 11:25:10 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CFNum31704; Thu, 12 Jun 2003 11:23:56 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CFIOm31292 for ; Thu, 12 Jun 2003 11:18:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15540 for ; Thu, 12 Jun 2003 11:18:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QToG-0003Q7-00 for simple@ietf.org; Thu, 12 Jun 2003 11:16:16 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19QToF-0003Q2-00 for simple@ietf.org; Thu, 12 Jun 2003 11:16:15 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h5CFHqU03377 for ; Thu, 12 Jun 2003 10:17:52 -0500 From: Robert Sparks To: simple@ietf.org Content-Type: text/plain Message-Id: <1055431071.1048.34.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] new -00 WG draft requirement 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: 12 Jun 2003 10:17:51 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit We have a new requirement from the ID repository administrators for this meeting. The chairs need to let them know _in advance_ about WG -00 drafts that will be submitted between now and the -00 cut-off. The XCAP drafts are all that I'm expecting. If I've forgotten something, please remind me quickly. Thanks, RjS _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Jun 12 12:20:47 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 MAA17378; Thu, 12 Jun 2003 12:20:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QUmg-0003tN-00; Thu, 12 Jun 2003 12:18:42 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19QUmf-0003tK-00; Thu, 12 Jun 2003 12:18:41 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CGHTm03372; Thu, 12 Jun 2003 12:17:29 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CFodm01215 for ; Thu, 12 Jun 2003 11:50: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 LAA16491 for ; Thu, 12 Jun 2003 11:50:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QUJT-0003eO-00 for simple@ietf.org; Thu, 12 Jun 2003 11:48:31 -0400 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 19QUJS-0003e1-00 for simple@ietf.org; Thu, 12 Jun 2003 11:48:30 -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 h5CFnkDc017007; Thu, 12 Jun 2003 11:49:46 -0400 (EDT) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Thu, 12 Jun 2003 10:49:45 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A6484F@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'Rohan Mahy'" , simple@ietf.org Cc: lisa@xythos.com Subject: RE: [Simple] XCAP and Webdav (was: XCAP batching) 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: Thu, 12 Jun 2003 10:49:44 -0500 Lisa Dusseault wrote: > 5. To change the default buddy list, or any profile buddy list, the > client does a LOCK, GET, PUT, UNLOCK. As soon as the PUT occurs the > new buddy listis visible to other clients but since the whole file > is internally consistent this is great. The issue is that XCAP is specifically being defined so that you don't have to PUT the entire document. In a nutshell, it uses XPATH syntax to specify a subset of an XML document to be updated. Consequently, there's a need to be able to lock a whole document, perform *several* updates on subsections of that document, and then unlock the whole document. Until the final update, the document is not typically in a consistent state. So, the two approaches that have been mentioned so far are: 1) Prevent reading while a document is locked for writing (except, obviously, by the client who has the document locked). or: 2) LOCK the document, COPY it somewhere that others won't try to access it, perform multiple updates on the temporary copy, COPY the temporary document back to its original location, and UNLOCK the document. It's a bit chatty, but it doesn't require any modifications to existing WEBDAV servers. /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu Jun 12 12:21:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17411 for ; Thu, 12 Jun 2003 12:21:18 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5CGKpl03604 for simple-archive@odin.ietf.org; Thu, 12 Jun 2003 12:20:51 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CGKpm03601 for ; Thu, 12 Jun 2003 12:20:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17378; Thu, 12 Jun 2003 12:20:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QUmg-0003tN-00; Thu, 12 Jun 2003 12:18:42 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19QUmf-0003tK-00; Thu, 12 Jun 2003 12:18:41 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CGHTm03372; Thu, 12 Jun 2003 12:17:29 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CFodm01215 for ; Thu, 12 Jun 2003 11:50: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 LAA16491 for ; Thu, 12 Jun 2003 11:50:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QUJT-0003eO-00 for simple@ietf.org; Thu, 12 Jun 2003 11:48:31 -0400 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 19QUJS-0003e1-00 for simple@ietf.org; Thu, 12 Jun 2003 11:48:30 -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 h5CFnkDc017007; Thu, 12 Jun 2003 11:49:46 -0400 (EDT) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Thu, 12 Jun 2003 10:49:45 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A6484F@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'Rohan Mahy'" , simple@ietf.org Cc: lisa@xythos.com Subject: RE: [Simple] XCAP and Webdav (was: XCAP batching) 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: Thu, 12 Jun 2003 10:49:44 -0500 Lisa Dusseault wrote: > 5. To change the default buddy list, or any profile buddy list, the > client does a LOCK, GET, PUT, UNLOCK. As soon as the PUT occurs the > new buddy listis visible to other clients but since the whole file > is internally consistent this is great. The issue is that XCAP is specifically being defined so that you don't have to PUT the entire document. In a nutshell, it uses XPATH syntax to specify a subset of an XML document to be updated. Consequently, there's a need to be able to lock a whole document, perform *several* updates on subsections of that document, and then unlock the whole document. Until the final update, the document is not typically in a consistent state. So, the two approaches that have been mentioned so far are: 1) Prevent reading while a document is locked for writing (except, obviously, by the client who has the document locked). or: 2) LOCK the document, COPY it somewhere that others won't try to access it, perform multiple updates on the temporary copy, COPY the temporary document back to its original location, and UNLOCK the document. It's a bit chatty, but it doesn't require any modifications to existing WEBDAV servers. /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Jun 12 20:28:47 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 UAA02648; Thu, 12 Jun 2003 20:28:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QcOu-0007MR-00; Thu, 12 Jun 2003 20:26:40 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19QcOu-0007MM-00; Thu, 12 Jun 2003 20:26:40 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CLY1a26643; Thu, 12 Jun 2003 17:34:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CLXMm26623 for ; Thu, 12 Jun 2003 17:33:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27766 for ; Thu, 12 Jun 2003 17:33:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QZf7-0006Gj-00 for simple@ietf.org; Thu, 12 Jun 2003 17:31:13 -0400 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 19QZf6-0006Gf-00 for simple@ietf.org; Thu, 12 Jun 2003 17:31:12 -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 h5CLWdDc017732; Thu, 12 Jun 2003 17:32:39 -0400 (EDT) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Thu, 12 Jun 2003 16:32:38 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A64852@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'Lisa Dusseault'" , Adam Roach , "'Rohan Mahy'" , simple@ietf.org Subject: RE: [Simple] XCAP and Webdav (was: XCAP batching) 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: Thu, 12 Jun 2003 16:32:32 -0500 > Sure, but why wouldn't you use XPATH to change pieces of the > document on the client side then send the whole thing back to > the server? Over Internet latencies with files this small, > this is likely to be faster for the user anyway. When your access technology is CDMA 1xRTT or UMTS (or even current deployments of GPRS), minimization of bytes sent is somewhat more important than it is for, say, DSL or DOCSIS users. Utilization of scarce radio channel resources (and the resultant volume-based billing) is at least as important as the latency induced by potentially low data rates. Wireless presence is one of the many drivers behind the SIMPLE work right now, so we need to take these constraints into account when designing our protocols. /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu Jun 12 20:29:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02673 for ; Thu, 12 Jun 2003 20:29:18 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5D0Sou05144 for simple-archive@odin.ietf.org; Thu, 12 Jun 2003 20:28:50 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5D0Som05141 for ; Thu, 12 Jun 2003 20:28: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 UAA02648; Thu, 12 Jun 2003 20:28:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QcOu-0007MR-00; Thu, 12 Jun 2003 20:26:40 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19QcOu-0007MM-00; Thu, 12 Jun 2003 20:26:40 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CLY1a26643; Thu, 12 Jun 2003 17:34:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CLXMm26623 for ; Thu, 12 Jun 2003 17:33:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27766 for ; Thu, 12 Jun 2003 17:33:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QZf7-0006Gj-00 for simple@ietf.org; Thu, 12 Jun 2003 17:31:13 -0400 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 19QZf6-0006Gf-00 for simple@ietf.org; Thu, 12 Jun 2003 17:31:12 -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 h5CLWdDc017732; Thu, 12 Jun 2003 17:32:39 -0400 (EDT) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Thu, 12 Jun 2003 16:32:38 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A64852@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'Lisa Dusseault'" , Adam Roach , "'Rohan Mahy'" , simple@ietf.org Subject: RE: [Simple] XCAP and Webdav (was: XCAP batching) 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: Thu, 12 Jun 2003 16:32:32 -0500 > Sure, but why wouldn't you use XPATH to change pieces of the > document on the client side then send the whole thing back to > the server? Over Internet latencies with files this small, > this is likely to be faster for the user anyway. When your access technology is CDMA 1xRTT or UMTS (or even current deployments of GPRS), minimization of bytes sent is somewhat more important than it is for, say, DSL or DOCSIS users. Utilization of scarce radio channel resources (and the resultant volume-based billing) is at least as important as the latency induced by potentially low data rates. Wireless presence is one of the many drivers behind the SIMPLE work right now, so we need to take these constraints into account when designing our protocols. /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Jun 12 22:15:39 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 WAA05316; Thu, 12 Jun 2003 22:15:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Qe4K-0000J4-00; Thu, 12 Jun 2003 22:13:32 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Qe4K-0000J1-00; Thu, 12 Jun 2003 22:13:32 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CM83a29681; Thu, 12 Jun 2003 18:08:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CM7Tm29499 for ; Thu, 12 Jun 2003 18: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 SAA28946 for ; Thu, 12 Jun 2003 18:07:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QaC8-0006WZ-00 for simple@ietf.org; Thu, 12 Jun 2003 18:05:20 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by ietf-mx with esmtp (Exim 4.12) id 19QaC7-0006UT-00 for simple@ietf.org; Thu, 12 Jun 2003 18:05:19 -0400 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h5CM6m3p000997; Thu, 12 Jun 2003 15:06:48 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AIB68594; Thu, 12 Jun 2003 15:01:40 -0700 (PDT) Subject: Re: [Simple] XCAP and Webdav (was: XCAP batching) Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: "'Lisa Dusseault'" , simple@ietf.org To: Adam Roach From: Rohan Mahy In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3A64852@dyn-tx-exch-001.dynamicsoft.com> Message-Id: <4E1B7B15-9D22-11D7-A0EF-0003938AF740@cisco.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 12 Jun 2003 15:07:49 -0700 Content-Transfer-Encoding: 7bit On Thursday, June 12, 2003, at 02:32 PM, Adam Roach wrote: >> Sure, but why wouldn't you use XPATH to change pieces of the >> document on the client side then send the whole thing back to >> the server? Over Internet latencies with files this small, >> this is likely to be faster for the user anyway. > > When your access technology is CDMA 1xRTT or UMTS (or even current > deployments of GPRS), minimization of bytes sent is somewhat > more important than it is for, say, DSL or DOCSIS users. > Utilization of scarce radio channel resources (and the resultant > volume-based billing) is at least as important as the latency > induced by potentially low data rates. These links suck pretty badly for latency as well. Which is worse, consuming bw or RTTs? I think you make a good case why using lots of bandwidth is a problem, but not why its more of a problem than having lots of delay. thx, -r > Wireless presence is one of the many drivers behind the SIMPLE > work right now, so we need to take these constraints into account > when designing our protocols. > > /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu Jun 12 22:16:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05362 for ; Thu, 12 Jun 2003 22:16:11 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5D2Fj613010 for simple-archive@odin.ietf.org; Thu, 12 Jun 2003 22:15:45 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5D2Fjm13007 for ; Thu, 12 Jun 2003 22:15: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 WAA05316; Thu, 12 Jun 2003 22:15:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Qe4K-0000J4-00; Thu, 12 Jun 2003 22:13:32 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Qe4K-0000J1-00; Thu, 12 Jun 2003 22:13:32 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CM83a29681; Thu, 12 Jun 2003 18:08:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CM7Tm29499 for ; Thu, 12 Jun 2003 18: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 SAA28946 for ; Thu, 12 Jun 2003 18:07:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QaC8-0006WZ-00 for simple@ietf.org; Thu, 12 Jun 2003 18:05:20 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by ietf-mx with esmtp (Exim 4.12) id 19QaC7-0006UT-00 for simple@ietf.org; Thu, 12 Jun 2003 18:05:19 -0400 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h5CM6m3p000997; Thu, 12 Jun 2003 15:06:48 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AIB68594; Thu, 12 Jun 2003 15:01:40 -0700 (PDT) Subject: Re: [Simple] XCAP and Webdav (was: XCAP batching) Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: "'Lisa Dusseault'" , simple@ietf.org To: Adam Roach From: Rohan Mahy In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3A64852@dyn-tx-exch-001.dynamicsoft.com> Message-Id: <4E1B7B15-9D22-11D7-A0EF-0003938AF740@cisco.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 12 Jun 2003 15:07:49 -0700 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Thursday, June 12, 2003, at 02:32 PM, Adam Roach wrote: >> Sure, but why wouldn't you use XPATH to change pieces of the >> document on the client side then send the whole thing back to >> the server? Over Internet latencies with files this small, >> this is likely to be faster for the user anyway. > > When your access technology is CDMA 1xRTT or UMTS (or even current > deployments of GPRS), minimization of bytes sent is somewhat > more important than it is for, say, DSL or DOCSIS users. > Utilization of scarce radio channel resources (and the resultant > volume-based billing) is at least as important as the latency > induced by potentially low data rates. These links suck pretty badly for latency as well. Which is worse, consuming bw or RTTs? I think you make a good case why using lots of bandwidth is a problem, but not why its more of a problem than having lots of delay. thx, -r > Wireless presence is one of the many drivers behind the SIMPLE > work right now, so we need to take these constraints into account > when designing our protocols. > > /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Jun 12 23:30:43 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 XAA06724; Thu, 12 Jun 2003 23:30:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QfEz-0000dv-00; Thu, 12 Jun 2003 23:28:37 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19QfEy-0000ds-00; Thu, 12 Jun 2003 23:28:36 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CKI1a21697; Thu, 12 Jun 2003 16:18:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CKHrm21683 for ; Thu, 12 Jun 2003 16:17:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25609 for ; Thu, 12 Jun 2003 16:17:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QYU5-0005gQ-00 for simple@ietf.org; Thu, 12 Jun 2003 16:15:45 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19QYU3-0005gJ-00 for simple@ietf.org; Thu, 12 Jun 2003 16:15:44 -0400 Received: from dynamicsoft.com ([63.113.46.50]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h5CKHGZE012697; Thu, 12 Jun 2003 16:17:16 -0400 (EDT) Message-ID: <3EE8DFC8.5070707@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adam Roach CC: "'Rohan Mahy'" , simple@ietf.org, lisa@xythos.com Subject: Re: [Simple] XCAP and Webdav (was: XCAP batching) References: <9BF66EBF6BEFD942915B4D4D45C051F3A6484F@dyn-tx-exch-001.dynamicsoft.com> In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3A6484F@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: Thu, 12 Jun 2003 16:17:12 -0400 Content-Transfer-Encoding: 7bit Adam Roach wrote: > Lisa Dusseault wrote: > > >>5. To change the default buddy list, or any profile buddy list, the >>client does a LOCK, GET, PUT, UNLOCK. As soon as the PUT occurs the >>new buddy listis visible to other clients but since the whole file >>is internally consistent this is great. > > > The issue is that XCAP is specifically being defined so that you don't > have to PUT the entire document. In a nutshell, it uses XPATH syntax > to specify a subset of an XML document to be updated. > > Consequently, there's a need to be able to lock a whole document, > perform *several* updates on subsections of that document, and then > unlock the whole document. Until the final update, the document is > not typically in a consistent state. Right. To hammer this home - we are specifically managing things like authorization policies, where an intermediate state might represent something truly undesirable. We absolutely MUST have the document only read by presence servers when it is in a consistent state. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Scientist 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 mailnull@www1.ietf.org Thu Jun 12 23:31:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06753 for ; Thu, 12 Jun 2003 23:31:39 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5D3VAG17240 for simple-archive@odin.ietf.org; Thu, 12 Jun 2003 23:31:10 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5D3Upm17237 for ; Thu, 12 Jun 2003 23:30:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06724; Thu, 12 Jun 2003 23:30:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QfEz-0000dv-00; Thu, 12 Jun 2003 23:28:37 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19QfEy-0000ds-00; Thu, 12 Jun 2003 23:28:36 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CKI1a21697; Thu, 12 Jun 2003 16:18:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CKHrm21683 for ; Thu, 12 Jun 2003 16:17:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25609 for ; Thu, 12 Jun 2003 16:17:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QYU5-0005gQ-00 for simple@ietf.org; Thu, 12 Jun 2003 16:15:45 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19QYU3-0005gJ-00 for simple@ietf.org; Thu, 12 Jun 2003 16:15:44 -0400 Received: from dynamicsoft.com ([63.113.46.50]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h5CKHGZE012697; Thu, 12 Jun 2003 16:17:16 -0400 (EDT) Message-ID: <3EE8DFC8.5070707@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adam Roach CC: "'Rohan Mahy'" , simple@ietf.org, lisa@xythos.com Subject: Re: [Simple] XCAP and Webdav (was: XCAP batching) References: <9BF66EBF6BEFD942915B4D4D45C051F3A6484F@dyn-tx-exch-001.dynamicsoft.com> In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3A6484F@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: Thu, 12 Jun 2003 16:17:12 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Adam Roach wrote: > Lisa Dusseault wrote: > > >>5. To change the default buddy list, or any profile buddy list, the >>client does a LOCK, GET, PUT, UNLOCK. As soon as the PUT occurs the >>new buddy listis visible to other clients but since the whole file >>is internally consistent this is great. > > > The issue is that XCAP is specifically being defined so that you don't > have to PUT the entire document. In a nutshell, it uses XPATH syntax > to specify a subset of an XML document to be updated. > > Consequently, there's a need to be able to lock a whole document, > perform *several* updates on subsections of that document, and then > unlock the whole document. Until the final update, the document is > not typically in a consistent state. Right. To hammer this home - we are specifically managing things like authorization policies, where an intermediate state might represent something truly undesirable. We absolutely MUST have the document only read by presence servers when it is in a consistent state. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Scientist Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Jun 12 23:41: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 XAA06855; Thu, 12 Jun 2003 23:41:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QfP1-0000ft-00; Thu, 12 Jun 2003 23:38:59 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19QfP1-0000fq-00; Thu, 12 Jun 2003 23:38:59 -0400 Received: from optimus.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5D2W1a13537; Thu, 12 Jun 2003 22:32:01 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5D2V0m13496 for ; Thu, 12 Jun 2003 22:31:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05632 for ; Thu, 12 Jun 2003 22:30:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QeJ8-0000N0-00 for simple@ietf.org; Thu, 12 Jun 2003 22:28:50 -0400 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 19QeJ7-0000Mn-00 for simple@ietf.org; Thu, 12 Jun 2003 22:28:49 -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 h5D2UEDc018336; Thu, 12 Jun 2003 22:30:14 -0400 (EDT) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Thu, 12 Jun 2003 21:30:13 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A6485E@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'Lisa Dusseault'" , Adam Roach , "'Rohan Mahy'" , simple@ietf.org Subject: RE: [Simple] XCAP and Webdav (was: XCAP batching) 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: Thu, 12 Jun 2003 21:30:09 -0500 > POST has some opponents in the IETF for new defined arbitrary > semantics (although it's widely accepted for custom work, just > not for standard protocols). You may recall the "going postal" > ID by Cohen in 1998. That draft, as best I can tell, railed against the use of POST solely as an end around firewalls. It's the same argument that is put forth by RFC 3093, albeit in slightly drier terms. It's not entirely clear that the sentiment applies to XCAP's proposed use of POST. /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu Jun 12 23:42:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06889 for ; Thu, 12 Jun 2003 23:42:02 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5D3fW218560 for simple-archive@odin.ietf.org; Thu, 12 Jun 2003 23:41:32 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5D3fDm18556 for ; Thu, 12 Jun 2003 23:41:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06855; Thu, 12 Jun 2003 23:41:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QfP1-0000ft-00; Thu, 12 Jun 2003 23:38:59 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19QfP1-0000fq-00; Thu, 12 Jun 2003 23:38:59 -0400 Received: from optimus.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5D2W1a13537; Thu, 12 Jun 2003 22:32:01 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5D2V0m13496 for ; Thu, 12 Jun 2003 22:31:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05632 for ; Thu, 12 Jun 2003 22:30:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QeJ8-0000N0-00 for simple@ietf.org; Thu, 12 Jun 2003 22:28:50 -0400 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 19QeJ7-0000Mn-00 for simple@ietf.org; Thu, 12 Jun 2003 22:28:49 -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 h5D2UEDc018336; Thu, 12 Jun 2003 22:30:14 -0400 (EDT) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Thu, 12 Jun 2003 21:30:13 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A6485E@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'Lisa Dusseault'" , Adam Roach , "'Rohan Mahy'" , simple@ietf.org Subject: RE: [Simple] XCAP and Webdav (was: XCAP batching) 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: Thu, 12 Jun 2003 21:30:09 -0500 > POST has some opponents in the IETF for new defined arbitrary > semantics (although it's widely accepted for custom work, just > not for standard protocols). You may recall the "going postal" > ID by Cohen in 1998. That draft, as best I can tell, railed against the use of POST solely as an end around firewalls. It's the same argument that is put forth by RFC 3093, albeit in slightly drier terms. It's not entirely clear that the sentiment applies to XCAP's proposed use of POST. /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Jun 13 00:08:17 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 AAA07575; Fri, 13 Jun 2003 00:08:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QfpL-0000rP-00; Fri, 13 Jun 2003 00:06:11 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19QfpK-0000rM-00; Fri, 13 Jun 2003 00:06:10 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5D2O2a13270; Thu, 12 Jun 2003 22:24:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5D2NLm13253 for ; Thu, 12 Jun 2003 22:23:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05522 for ; Thu, 12 Jun 2003 22:23:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QeBi-0000Kw-00 for simple@ietf.org; Thu, 12 Jun 2003 22:21:11 -0400 Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx with esmtp (Exim 4.12) id 19QeBi-0000Kt-00 for simple@ietf.org; Thu, 12 Jun 2003 22:21:10 -0400 Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by opus.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h5D2NFue000242; Thu, 12 Jun 2003 22:23:15 -0400 (EDT) Message-ID: <3EE934AA.1010802@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030603 Thunderbird/0.1a X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rohan Mahy CC: Adam Roach , "'Lisa Dusseault'" , simple@ietf.org Subject: Re: [Simple] XCAP and Webdav References: <4E1B7B15-9D22-11D7-A0EF-0003938AF740@cisco.com> In-Reply-To: <4E1B7B15-9D22-11D7-A0EF-0003938AF740@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: Thu, 12 Jun 2003 22:19:22 -0400 Content-Transfer-Encoding: 7bit Why couldn't you structure the buddy list like a logical directory, where retrieving the directory gets the whole list, but each 'file' is one entry? As in example.com/buddy/ example.com/buddy/joe@foo.com etc. For typical operations, like adding and deleting buddy list members, you'd have one DELETE etc. operation. No need for XPath, fragment identifiers or anything else fancy. Rohan Mahy wrote: > These links suck pretty badly for latency as well. Which is worse, > consuming bw or RTTs? I think you make a good case why using lots of > bandwidth is a problem, but not why its more of a problem than having > lots of delay. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Fri Jun 13 00:09:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07599 for ; Fri, 13 Jun 2003 00:09:00 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5D48WL20761 for simple-archive@odin.ietf.org; Fri, 13 Jun 2003 00:08:32 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5D48Om20756 for ; Fri, 13 Jun 2003 00:08:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07575; Fri, 13 Jun 2003 00:08:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QfpL-0000rP-00; Fri, 13 Jun 2003 00:06:11 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19QfpK-0000rM-00; Fri, 13 Jun 2003 00:06:10 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5D2O2a13270; Thu, 12 Jun 2003 22:24:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5D2NLm13253 for ; Thu, 12 Jun 2003 22:23:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05522 for ; Thu, 12 Jun 2003 22:23:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QeBi-0000Kw-00 for simple@ietf.org; Thu, 12 Jun 2003 22:21:11 -0400 Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx with esmtp (Exim 4.12) id 19QeBi-0000Kt-00 for simple@ietf.org; Thu, 12 Jun 2003 22:21:10 -0400 Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by opus.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h5D2NFue000242; Thu, 12 Jun 2003 22:23:15 -0400 (EDT) Message-ID: <3EE934AA.1010802@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030603 Thunderbird/0.1a X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rohan Mahy CC: Adam Roach , "'Lisa Dusseault'" , simple@ietf.org Subject: Re: [Simple] XCAP and Webdav References: <4E1B7B15-9D22-11D7-A0EF-0003938AF740@cisco.com> In-Reply-To: <4E1B7B15-9D22-11D7-A0EF-0003938AF740@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: Thu, 12 Jun 2003 22:19:22 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Why couldn't you structure the buddy list like a logical directory, where retrieving the directory gets the whole list, but each 'file' is one entry? As in example.com/buddy/ example.com/buddy/joe@foo.com etc. For typical operations, like adding and deleting buddy list members, you'd have one DELETE etc. operation. No need for XPath, fragment identifiers or anything else fancy. Rohan Mahy wrote: > These links suck pretty badly for latency as well. Which is worse, > consuming bw or RTTs? I think you make a good case why using lots of > bandwidth is a problem, but not why its more of a problem than having > lots of delay. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Jun 13 00:36:32 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 AAA08264; Fri, 13 Jun 2003 00:36:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QgGg-0000zJ-00; Fri, 13 Jun 2003 00:34:27 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19QgGg-0000zG-00; Fri, 13 Jun 2003 00:34:26 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5D2O2a13278; Thu, 12 Jun 2003 22:24:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5D2NRm13257 for ; Thu, 12 Jun 2003 22:23:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05525 for ; Thu, 12 Jun 2003 22:23:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QeBo-0000L2-00 for simple@ietf.org; Thu, 12 Jun 2003 22:21:17 -0400 Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx with esmtp (Exim 4.12) id 19QeBo-0000Kz-00 for simple@ietf.org; Thu, 12 Jun 2003 22:21:16 -0400 Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by opus.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h5D2NLue000249; Thu, 12 Jun 2003 22:23:21 -0400 (EDT) Message-ID: <3EE934B8.1090107@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030603 Thunderbird/0.1a X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rohan Mahy CC: Adam Roach , "'Lisa Dusseault'" , simple@ietf.org Subject: Re: [Simple] XCAP and Webdav References: <4E1B7B15-9D22-11D7-A0EF-0003938AF740@cisco.com> In-Reply-To: <4E1B7B15-9D22-11D7-A0EF-0003938AF740@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: Thu, 12 Jun 2003 22:19:36 -0400 Content-Transfer-Encoding: 7bit Why couldn't you structure the buddy list like a logical directory, where retrieving the directory gets the whole list, but each 'file' is one entry? As in example.com/buddy/ example.com/buddy/joe@foo.com etc. For typical operations, like adding and deleting buddy list members, you'd have one DELETE etc. operation. No need for XPath, fragment identifiers or anything else fancy. Rohan Mahy wrote: > These links suck pretty badly for latency as well. Which is worse, > consuming bw or RTTs? I think you make a good case why using lots of > bandwidth is a problem, but not why its more of a problem than having > lots of delay. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Fri Jun 13 00:37:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08287 for ; Fri, 13 Jun 2003 00:37:23 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5D4at121898 for simple-archive@odin.ietf.org; Fri, 13 Jun 2003 00:36:55 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5D4aem21895 for ; Fri, 13 Jun 2003 00:36: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 AAA08264; Fri, 13 Jun 2003 00:36:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QgGg-0000zJ-00; Fri, 13 Jun 2003 00:34:27 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19QgGg-0000zG-00; Fri, 13 Jun 2003 00:34:26 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5D2O2a13278; Thu, 12 Jun 2003 22:24:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5D2NRm13257 for ; Thu, 12 Jun 2003 22:23:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05525 for ; Thu, 12 Jun 2003 22:23:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QeBo-0000L2-00 for simple@ietf.org; Thu, 12 Jun 2003 22:21:17 -0400 Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx with esmtp (Exim 4.12) id 19QeBo-0000Kz-00 for simple@ietf.org; Thu, 12 Jun 2003 22:21:16 -0400 Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by opus.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h5D2NLue000249; Thu, 12 Jun 2003 22:23:21 -0400 (EDT) Message-ID: <3EE934B8.1090107@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030603 Thunderbird/0.1a X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rohan Mahy CC: Adam Roach , "'Lisa Dusseault'" , simple@ietf.org Subject: Re: [Simple] XCAP and Webdav References: <4E1B7B15-9D22-11D7-A0EF-0003938AF740@cisco.com> In-Reply-To: <4E1B7B15-9D22-11D7-A0EF-0003938AF740@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: Thu, 12 Jun 2003 22:19:36 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Why couldn't you structure the buddy list like a logical directory, where retrieving the directory gets the whole list, but each 'file' is one entry? As in example.com/buddy/ example.com/buddy/joe@foo.com etc. For typical operations, like adding and deleting buddy list members, you'd have one DELETE etc. operation. No need for XPath, fragment identifiers or anything else fancy. Rohan Mahy wrote: > These links suck pretty badly for latency as well. Which is worse, > consuming bw or RTTs? I think you make a good case why using lots of > bandwidth is a problem, but not why its more of a problem than having > lots of delay. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Jun 13 01:49:20 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 BAA09822; Fri, 13 Jun 2003 01:49:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QhP6-0001R8-00; Fri, 13 Jun 2003 01:47:12 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19QhP5-0001R5-00; Fri, 13 Jun 2003 01:47:11 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5D2U2a13447; Thu, 12 Jun 2003 22:30:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CNJ1m01060 for ; Thu, 12 Jun 2003 19:19:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01136 for ; Thu, 12 Jun 2003 19:18:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QbJM-0006uC-00 for simple@ietf.org; Thu, 12 Jun 2003 19:16:52 -0400 Received: from [206.14.210.116] (helo=mail.xythos.com) by ietf-mx with esmtp (Exim 4.12) id 19QbJM-0006u8-00 for simple@ietf.org; Thu, 12 Jun 2003 19:16:52 -0400 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 19QbLO-0000ey-00; Thu, 12 Jun 2003 23:18:58 +0000 Received: from [216.36.77.241] (helo=lisalap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 19QbLO-0000en-00; Thu, 12 Jun 2003 23:18:58 +0000 From: "Lisa Dusseault" To: "'Adam Roach'" , "'Rohan Mahy'" , Subject: RE: [Simple] XCAP and Webdav (was: XCAP batching) Message-ID: <04de01c33139$035c1890$fdcb90c6@lisalap> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3A64853@dyn-tx-exch-001.dynamicsoft.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Envelope-To: adam@dynamicsoft.com, rohan@cisco.com, simple@ietf.org Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 12 Jun 2003 16:19:03 -0700 Content-Transfer-Encoding: 7bit > > XCAP as currently proposed sort of does this, but it uses the > URL instead of a body, to identify where the change is to be > placed. For example, adding a new entry to a element > with a "name" attribute set to "friends" would look something > like this (the exact Content-Type to use is still being > worked out, so ignore it): > > > POST > http://xcap.example.com/services/presence-lists/users/bill/fr. xml?presence-l ists/list[@name="friends"] HTTP/1.1 Content-Type:text/plain Content-Length: ... Bill Doe POST has some opponents in the IETF for new defined arbitrary semantics (although it's widely accepted for custom work, just not for standard protocols). You may recall the "going postal" ID by Cohen in 1998. An alternative to putting the presence list information on the end of the URL is to put it in the body. THen the custom code only needs the body of the special POST request to handle it. Lisa _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Fri Jun 13 01:49:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09859 for ; Fri, 13 Jun 2003 01:49:51 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5D5nNw27606 for simple-archive@odin.ietf.org; Fri, 13 Jun 2003 01:49:23 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5D5nNm27603 for ; Fri, 13 Jun 2003 01:49: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 BAA09822; Fri, 13 Jun 2003 01:49:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QhP6-0001R8-00; Fri, 13 Jun 2003 01:47:12 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19QhP5-0001R5-00; Fri, 13 Jun 2003 01:47:11 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5D2U2a13447; Thu, 12 Jun 2003 22:30:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CNJ1m01060 for ; Thu, 12 Jun 2003 19:19:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01136 for ; Thu, 12 Jun 2003 19:18:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QbJM-0006uC-00 for simple@ietf.org; Thu, 12 Jun 2003 19:16:52 -0400 Received: from [206.14.210.116] (helo=mail.xythos.com) by ietf-mx with esmtp (Exim 4.12) id 19QbJM-0006u8-00 for simple@ietf.org; Thu, 12 Jun 2003 19:16:52 -0400 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 19QbLO-0000ey-00; Thu, 12 Jun 2003 23:18:58 +0000 Received: from [216.36.77.241] (helo=lisalap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 19QbLO-0000en-00; Thu, 12 Jun 2003 23:18:58 +0000 From: "Lisa Dusseault" To: "'Adam Roach'" , "'Rohan Mahy'" , Subject: RE: [Simple] XCAP and Webdav (was: XCAP batching) Message-ID: <04de01c33139$035c1890$fdcb90c6@lisalap> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3A64853@dyn-tx-exch-001.dynamicsoft.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Envelope-To: adam@dynamicsoft.com, rohan@cisco.com, simple@ietf.org Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 12 Jun 2003 16:19:03 -0700 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > > XCAP as currently proposed sort of does this, but it uses the > URL instead of a body, to identify where the change is to be > placed. For example, adding a new entry to a element > with a "name" attribute set to "friends" would look something > like this (the exact Content-Type to use is still being > worked out, so ignore it): > > > POST > http://xcap.example.com/services/presence-lists/users/bill/fr. xml?presence-l ists/list[@name="friends"] HTTP/1.1 Content-Type:text/plain Content-Length: ... Bill Doe POST has some opponents in the IETF for new defined arbitrary semantics (although it's widely accepted for custom work, just not for standard protocols). You may recall the "going postal" ID by Cohen in 1998. An alternative to putting the presence list information on the end of the URL is to put it in the body. THen the custom code only needs the body of the special POST request to handle it. Lisa _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Jun 13 04:23:34 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 EAA24928; Fri, 13 Jun 2003 04:23:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QjoN-0002hp-00; Fri, 13 Jun 2003 04:21:27 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19QjoM-0002hm-00; Fri, 13 Jun 2003 04:21:26 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5D1n1a11094; Thu, 12 Jun 2003 21:49:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5D1mXm11069 for ; Thu, 12 Jun 2003 21:48:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04510 for ; Thu, 12 Jun 2003 21:48:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Qde3-00004l-00 for simple@ietf.org; Thu, 12 Jun 2003 21:46:23 -0400 Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx with esmtp (Exim 4.12) id 19Qde2-00004i-00 for simple@ietf.org; Thu, 12 Jun 2003 21:46:22 -0400 Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by opus.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h5D1mSue026462; Thu, 12 Jun 2003 21:48:28 -0400 (EDT) Message-ID: <3EE92C8B.2040501@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030603 Thunderbird/0.1a X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: jdrosen@dynamicsoft.com, aki.niemi@nokia.com, simple@ietf.org References: <2038BCC78B1AD641891A0D1AE133DBB701796D94@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701796D94@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Re: Presence filtering idea Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 12 Jun 2003 21:44:43 -0400 Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > > I still don't understand how the subscriber can render the > information given in the tuple of the NOTIFY if it receives the info > in an XML format it does not understand, especially info it > specifically asked for in a filter. > > Someone in the interim suggested that you can just show the whole XML > document to the user, but that's not feasable, especially for > automata. Not for automata, but any recent browser will render XML, of any schema, in a reasonably human-readable format. > Either there must be a standardised way of representing something, or > this automaty will not work. Can't speak for others, but I'm not suggesting that we allow any random presence format. I'm just not convinced that a generic XPath mechanism is the most intuitive way of representing this information. It is necessary if we assume two things - events (including presence) can be any valid XML schema that's agreed upon by both sides or - events are more than a simple hierarchy. Otherwise, something much more intuitive like privacy > 'public' and media contains 'audio' would do the trick, somewhat similar to the Sieve. > The alternative is that the subscriber has to inform the compositor > the representation of tuples it accepts. We we need to go down that > path? That's a false alternative; see above for something that is neither XPath nor random event documents. > generic enough. I say we fix the tuple problem instead of making > other solutions that are generic more complicated. I don't see that there is a tuple problem to fix. The current capabilities description in RPIDS is unnecessarily messy, but I think there are better solutions that explicitly extend the XML definition rather than using the cop-out of capabilities in tags. (At least in my opinion, capabilities should be first-class citizens, not second-class ones, living lowly string existences.) _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Fri Jun 13 04:24:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24944 for ; Fri, 13 Jun 2003 04:24:06 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5D8NbB18456 for simple-archive@odin.ietf.org; Fri, 13 Jun 2003 04:23:37 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5D8Nbm18453 for ; Fri, 13 Jun 2003 04:23: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 EAA24928; Fri, 13 Jun 2003 04:23:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QjoN-0002hp-00; Fri, 13 Jun 2003 04:21:27 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19QjoM-0002hm-00; Fri, 13 Jun 2003 04:21:26 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5D1n1a11094; Thu, 12 Jun 2003 21:49:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5D1mXm11069 for ; Thu, 12 Jun 2003 21:48:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04510 for ; Thu, 12 Jun 2003 21:48:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Qde3-00004l-00 for simple@ietf.org; Thu, 12 Jun 2003 21:46:23 -0400 Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx with esmtp (Exim 4.12) id 19Qde2-00004i-00 for simple@ietf.org; Thu, 12 Jun 2003 21:46:22 -0400 Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by opus.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h5D1mSue026462; Thu, 12 Jun 2003 21:48:28 -0400 (EDT) Message-ID: <3EE92C8B.2040501@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030603 Thunderbird/0.1a X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: jdrosen@dynamicsoft.com, aki.niemi@nokia.com, simple@ietf.org References: <2038BCC78B1AD641891A0D1AE133DBB701796D94@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701796D94@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Re: Presence filtering idea Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 12 Jun 2003 21:44:43 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > > I still don't understand how the subscriber can render the > information given in the tuple of the NOTIFY if it receives the info > in an XML format it does not understand, especially info it > specifically asked for in a filter. > > Someone in the interim suggested that you can just show the whole XML > document to the user, but that's not feasable, especially for > automata. Not for automata, but any recent browser will render XML, of any schema, in a reasonably human-readable format. > Either there must be a standardised way of representing something, or > this automaty will not work. Can't speak for others, but I'm not suggesting that we allow any random presence format. I'm just not convinced that a generic XPath mechanism is the most intuitive way of representing this information. It is necessary if we assume two things - events (including presence) can be any valid XML schema that's agreed upon by both sides or - events are more than a simple hierarchy. Otherwise, something much more intuitive like privacy > 'public' and media contains 'audio' would do the trick, somewhat similar to the Sieve. > The alternative is that the subscriber has to inform the compositor > the representation of tuples it accepts. We we need to go down that > path? That's a false alternative; see above for something that is neither XPath nor random event documents. > generic enough. I say we fix the tuple problem instead of making > other solutions that are generic more complicated. I don't see that there is a tuple problem to fix. The current capabilities description in RPIDS is unnecessarily messy, but I think there are better solutions that explicitly extend the XML definition rather than using the cop-out of capabilities in tags. (At least in my opinion, capabilities should be first-class citizens, not second-class ones, living lowly string existences.) _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Jun 13 04:37: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 EAA25200; Fri, 13 Jun 2003 04:37:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Qk1q-0002ms-00; Fri, 13 Jun 2003 04:35:22 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Qk1p-0002mp-00; Fri, 13 Jun 2003 04:35:21 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5D1n2a11103; Thu, 12 Jun 2003 21:49:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5D1mdm11073 for ; Thu, 12 Jun 2003 21:48: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 VAA04515 for ; Thu, 12 Jun 2003 21:48:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Qde9-00004r-00 for simple@ietf.org; Thu, 12 Jun 2003 21:46:29 -0400 Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx with esmtp (Exim 4.12) id 19Qde8-00004o-00 for simple@ietf.org; Thu, 12 Jun 2003 21:46:29 -0400 Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by opus.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h5D1mZue026466; Thu, 12 Jun 2003 21:48:35 -0400 (EDT) Message-ID: <3EE92C93.8010403@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030603 Thunderbird/0.1a X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: jdrosen@dynamicsoft.com, aki.niemi@nokia.com, simple@ietf.org References: <2038BCC78B1AD641891A0D1AE133DBB701796D94@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701796D94@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Re: Presence filtering idea Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 12 Jun 2003 21:44:51 -0400 Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > > I still don't understand how the subscriber can render the > information given in the tuple of the NOTIFY if it receives the info > in an XML format it does not understand, especially info it > specifically asked for in a filter. > > Someone in the interim suggested that you can just show the whole XML > document to the user, but that's not feasable, especially for > automata. Not for automata, but any recent browser will render XML, of any schema, in a reasonably human-readable format. > Either there must be a standardised way of representing something, or > this automaty will not work. Can't speak for others, but I'm not suggesting that we allow any random presence format. I'm just not convinced that a generic XPath mechanism is the most intuitive way of representing this information. It is necessary if we assume two things - events (including presence) can be any valid XML schema that's agreed upon by both sides or - events are more than a simple hierarchy. Otherwise, something much more intuitive like privacy > 'public' and media contains 'audio' would do the trick, somewhat similar to the Sieve. > The alternative is that the subscriber has to inform the compositor > the representation of tuples it accepts. We we need to go down that > path? That's a false alternative; see above for something that is neither XPath nor random event documents. > generic enough. I say we fix the tuple problem instead of making > other solutions that are generic more complicated. I don't see that there is a tuple problem to fix. The current capabilities description in RPIDS is unnecessarily messy, but I think there are better solutions that explicitly extend the XML definition rather than using the cop-out of capabilities in tags. (At least in my opinion, capabilities should be first-class citizens, not second-class ones, living lowly string existences.) _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Fri Jun 13 04:38:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25232 for ; Fri, 13 Jun 2003 04:38:00 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5D8bW919847 for simple-archive@odin.ietf.org; Fri, 13 Jun 2003 04:37:32 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5D8bWm19844 for ; Fri, 13 Jun 2003 04:37:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25200; Fri, 13 Jun 2003 04:37:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Qk1q-0002ms-00; Fri, 13 Jun 2003 04:35:22 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Qk1p-0002mp-00; Fri, 13 Jun 2003 04:35:21 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5D1n2a11103; Thu, 12 Jun 2003 21:49:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5D1mdm11073 for ; Thu, 12 Jun 2003 21:48: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 VAA04515 for ; Thu, 12 Jun 2003 21:48:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Qde9-00004r-00 for simple@ietf.org; Thu, 12 Jun 2003 21:46:29 -0400 Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx with esmtp (Exim 4.12) id 19Qde8-00004o-00 for simple@ietf.org; Thu, 12 Jun 2003 21:46:29 -0400 Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by opus.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h5D1mZue026466; Thu, 12 Jun 2003 21:48:35 -0400 (EDT) Message-ID: <3EE92C93.8010403@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030603 Thunderbird/0.1a X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: jdrosen@dynamicsoft.com, aki.niemi@nokia.com, simple@ietf.org References: <2038BCC78B1AD641891A0D1AE133DBB701796D94@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701796D94@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Re: Presence filtering idea Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 12 Jun 2003 21:44:51 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > > I still don't understand how the subscriber can render the > information given in the tuple of the NOTIFY if it receives the info > in an XML format it does not understand, especially info it > specifically asked for in a filter. > > Someone in the interim suggested that you can just show the whole XML > document to the user, but that's not feasable, especially for > automata. Not for automata, but any recent browser will render XML, of any schema, in a reasonably human-readable format. > Either there must be a standardised way of representing something, or > this automaty will not work. Can't speak for others, but I'm not suggesting that we allow any random presence format. I'm just not convinced that a generic XPath mechanism is the most intuitive way of representing this information. It is necessary if we assume two things - events (including presence) can be any valid XML schema that's agreed upon by both sides or - events are more than a simple hierarchy. Otherwise, something much more intuitive like privacy > 'public' and media contains 'audio' would do the trick, somewhat similar to the Sieve. > The alternative is that the subscriber has to inform the compositor > the representation of tuples it accepts. We we need to go down that > path? That's a false alternative; see above for something that is neither XPath nor random event documents. > generic enough. I say we fix the tuple problem instead of making > other solutions that are generic more complicated. I don't see that there is a tuple problem to fix. The current capabilities description in RPIDS is unnecessarily messy, but I think there are better solutions that explicitly extend the XML definition rather than using the cop-out of capabilities in tags. (At least in my opinion, capabilities should be first-class citizens, not second-class ones, living lowly string existences.) _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Jun 13 04:48: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 EAA25369; Fri, 13 Jun 2003 04:48:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QkCa-0002qW-00; Fri, 13 Jun 2003 04:46:28 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19QkCa-0002qT-00; Fri, 13 Jun 2003 04:46:28 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CLr1a28083; Thu, 12 Jun 2003 17:53:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CLqYm28057 for ; Thu, 12 Jun 2003 17:52:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28097 for ; Thu, 12 Jun 2003 17:52:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QZxg-0006NX-00 for simple@ietf.org; Thu, 12 Jun 2003 17:50:24 -0400 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 19QZxf-0006NM-00 for simple@ietf.org; Thu, 12 Jun 2003 17:50:23 -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 h5CLpnDc017796; Thu, 12 Jun 2003 17:51:50 -0400 (EDT) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Thu, 12 Jun 2003 16:51:48 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A64853@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'Lisa Dusseault'" , Adam Roach , "'Rohan Mahy'" , simple@ietf.org Subject: RE: [Simple] XCAP and Webdav (was: XCAP batching) 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: Thu, 12 Jun 2003 16:51:43 -0500 Lisa Dusseault [mailto:lisa@xythos.com] writes: > I would recommend the following (and you would likely get > support or assistance from other WebDAV implementors in > defining and developing this): > - Define a MIME type for an XPATH-based modification to an > XML document. Perhaps this MIME type exists already -- > a stylesheet type? XCAP as currently proposed sort of does this, but it uses the URL instead of a body, to identify where the change is to be placed. For example, adding a new entry to a element with a "name" attribute set to "friends" would look something like this (the exact Content-Type to use is still being worked out, so ignore it): POST http://xcap.example.com/services/presence-lists/users/bill/fr.xml?presence-l ists/list[@name="friends"] HTTP/1.1 Content-Type:text/plain Content-Length: ... Bill Doe > - Define a method like PATCH or PUTPATCH to send this document to the > resource to be modified We're actually using POST. If you look at the example above, you can sort of see why: performing a GET on the URL specified would retrieve the entire list, not just a single element of the list. Since calling PUT(x) with a document followed immediately by GET(x) would not yield the same document, it seems that PUT would be the wrong choice. Personally, I'm a bit loathe to propose any new HTTP methods to solve any XCAP issues, because the ability to use off-the-shelf HTTP servers is very compelling. > - Beyond this new mechanism, simply use HTTP GET/PUT/DELETE, > and WebDAV PROPFIND/MOVE/COPY/LOCK/UNLOCK, and possibly the > DeltaV CHECKOUT/CHECKIN to create a working resource in a > 'sandbox' while the PATCHes are applied. So, it sounds like you're favoring, at a high level, a lock/copy/munge/move/unlock approach. Actually, that's pretty nice, because it also solves another problem we had with transaction rollbacks. If something goes wrong in the munging stage, you can just delete the copy instead of moving it back to the location of the original. /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Fri Jun 13 04:49:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25385 for ; Fri, 13 Jun 2003 04:49:07 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5D8md120557 for simple-archive@odin.ietf.org; Fri, 13 Jun 2003 04:48:39 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5D8mdm20554 for ; Fri, 13 Jun 2003 04:48: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 EAA25369; Fri, 13 Jun 2003 04:48:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QkCa-0002qW-00; Fri, 13 Jun 2003 04:46:28 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19QkCa-0002qT-00; Fri, 13 Jun 2003 04:46:28 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CLr1a28083; Thu, 12 Jun 2003 17:53:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CLqYm28057 for ; Thu, 12 Jun 2003 17:52:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28097 for ; Thu, 12 Jun 2003 17:52:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QZxg-0006NX-00 for simple@ietf.org; Thu, 12 Jun 2003 17:50:24 -0400 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 19QZxf-0006NM-00 for simple@ietf.org; Thu, 12 Jun 2003 17:50:23 -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 h5CLpnDc017796; Thu, 12 Jun 2003 17:51:50 -0400 (EDT) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Thu, 12 Jun 2003 16:51:48 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A64853@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'Lisa Dusseault'" , Adam Roach , "'Rohan Mahy'" , simple@ietf.org Subject: RE: [Simple] XCAP and Webdav (was: XCAP batching) 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: Thu, 12 Jun 2003 16:51:43 -0500 Lisa Dusseault [mailto:lisa@xythos.com] writes: > I would recommend the following (and you would likely get > support or assistance from other WebDAV implementors in > defining and developing this): > - Define a MIME type for an XPATH-based modification to an > XML document. Perhaps this MIME type exists already -- > a stylesheet type? XCAP as currently proposed sort of does this, but it uses the URL instead of a body, to identify where the change is to be placed. For example, adding a new entry to a element with a "name" attribute set to "friends" would look something like this (the exact Content-Type to use is still being worked out, so ignore it): POST http://xcap.example.com/services/presence-lists/users/bill/fr.xml?presence-l ists/list[@name="friends"] HTTP/1.1 Content-Type:text/plain Content-Length: ... Bill Doe > - Define a method like PATCH or PUTPATCH to send this document to the > resource to be modified We're actually using POST. If you look at the example above, you can sort of see why: performing a GET on the URL specified would retrieve the entire list, not just a single element of the list. Since calling PUT(x) with a document followed immediately by GET(x) would not yield the same document, it seems that PUT would be the wrong choice. Personally, I'm a bit loathe to propose any new HTTP methods to solve any XCAP issues, because the ability to use off-the-shelf HTTP servers is very compelling. > - Beyond this new mechanism, simply use HTTP GET/PUT/DELETE, > and WebDAV PROPFIND/MOVE/COPY/LOCK/UNLOCK, and possibly the > DeltaV CHECKOUT/CHECKIN to create a working resource in a > 'sandbox' while the PATCHes are applied. So, it sounds like you're favoring, at a high level, a lock/copy/munge/move/unlock approach. Actually, that's pretty nice, because it also solves another problem we had with transaction rollbacks. If something goes wrong in the munging stage, you can just delete the copy instead of moving it back to the location of the original. /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Jun 13 06:17:20 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 GAA27339; Fri, 13 Jun 2003 06:17:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QlaT-0003PQ-00; Fri, 13 Jun 2003 06:15:13 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19QlaT-0003PN-00; Fri, 13 Jun 2003 06:15:13 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CLH1a26056; Thu, 12 Jun 2003 17:17:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CHFtm08657 for ; Thu, 12 Jun 2003 13:15:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19217 for ; Thu, 12 Jun 2003 13:15:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QVdy-0004Ki-00 for simple@ietf.org; Thu, 12 Jun 2003 13:13:46 -0400 Received: from [206.14.210.116] (helo=mail.xythos.com) by ietf-mx with esmtp (Exim 4.12) id 19QVdy-0004KW-00 for simple@ietf.org; Thu, 12 Jun 2003 13:13:46 -0400 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 19QVg0-00039f-00; Thu, 12 Jun 2003 17:15:52 +0000 Received: from [216.36.77.241] (helo=lisalap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 19QVg0-00039T-00; Thu, 12 Jun 2003 17:15:52 +0000 From: "Lisa Dusseault" To: "'Adam Roach'" , "'Rohan Mahy'" , Subject: RE: [Simple] XCAP and Webdav (was: XCAP batching) Message-ID: <048d01c33106$49eb0650$fdcb90c6@lisalap> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3A6484F@dyn-tx-exch-001.dynamicsoft.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Envelope-To: adam@dynamicsoft.com, rohan@cisco.com, simple@ietf.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5CHFtm08658 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 12 Jun 2003 10:15:56 -0700 Content-Transfer-Encoding: 8bit Sure, but why wouldn't you use XPATH to change pieces of the document on the client side then send the whole thing back to the server? Over Internet latencies with files this small, this is likely to be faster for the user anyway. Then the protocol needn't bother with this complication. I really don't understand why partial PUT is necessary, but if it is, I would recommend the following (and you would likely get support or assistance from other WebDAV implementors in defining and developing this): - Define a MIME type for an XPATH-based modification to an XML document. Perhaps this MIME type exists already -- a stylesheet type? - Define a method like PATCH or PUTPATCH to send this document to the resource to be modified - Beyond this new mechanism, simply use HTTP GET/PUT/DELETE, and WebDAV PROPFIND/MOVE/COPY/LOCK/UNLOCK, and possibly the DeltaV CHECKOUT/CHECKIN to create a working resource in a 'sandbox' while the PATCHes are applied. A patch or "partial put" mechanism has been discussed in WebDAV circles for a long time, and only other work has prevented us from proceeding on it. Generally the idea is to have a byte-oriented diff mechanism that isn't limited to XML -- one that can be applied to text documents, images, etc. However, much of the same work would need to be done. For example, a PATCH method could be defined that took a couple of different MIME types depending on what mechanism is used to patch the target file. Lisa > -----Original Message----- > From: Adam Roach [mailto:adam@dynamicsoft.com] > Sent: Thursday, June 12, 2003 8:50 AM > To: 'Rohan Mahy'; simple@ietf.org > Cc: lisa@xythos.com > Subject: RE: [Simple] XCAP and Webdav (was: XCAP batching) > > > Lisa Dusseault wrote: > > > 5. To change the default buddy list, or any profile buddy list, the > > client does a LOCK, GET, PUT, UNLOCK. As soon as the PUT > occurs the > > new buddy listis visible to other clients but since the whole file > > is internally consistent this is great. > > The issue is that XCAP is specifically being defined so that > you don't have to PUT the entire document. In a nutshell, it > uses XPATH syntax to specify a subset of an XML document to > be updated. > > Consequently, there's a need to be able to lock a whole > document, perform *several* updates on subsections of that > document, and then unlock the whole document. Until the final > update, the document is not typically in a consistent state. > > So, the two approaches that have been mentioned so far are: > > 1) Prevent reading while a document is locked for writing > (except, obviously, by the client who has the document locked). > > or: > > 2) LOCK the document, COPY it somewhere that others won't try to > access it, perform multiple updates on the temporary copy, COPY > the temporary document back to its original location, and UNLOCK > the document. It's a bit chatty, but it doesn't require any > modifications to existing WEBDAV servers. > > /a > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Fri Jun 13 06:17:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27375 for ; Fri, 13 Jun 2003 06:17:51 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5DAHOu27846 for simple-archive@odin.ietf.org; Fri, 13 Jun 2003 06:17:24 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DAHOm27843 for ; Fri, 13 Jun 2003 06:17:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27339; Fri, 13 Jun 2003 06:17:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QlaT-0003PQ-00; Fri, 13 Jun 2003 06:15:13 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19QlaT-0003PN-00; Fri, 13 Jun 2003 06:15:13 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CLH1a26056; Thu, 12 Jun 2003 17:17:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CHFtm08657 for ; Thu, 12 Jun 2003 13:15:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19217 for ; Thu, 12 Jun 2003 13:15:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QVdy-0004Ki-00 for simple@ietf.org; Thu, 12 Jun 2003 13:13:46 -0400 Received: from [206.14.210.116] (helo=mail.xythos.com) by ietf-mx with esmtp (Exim 4.12) id 19QVdy-0004KW-00 for simple@ietf.org; Thu, 12 Jun 2003 13:13:46 -0400 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 19QVg0-00039f-00; Thu, 12 Jun 2003 17:15:52 +0000 Received: from [216.36.77.241] (helo=lisalap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 19QVg0-00039T-00; Thu, 12 Jun 2003 17:15:52 +0000 From: "Lisa Dusseault" To: "'Adam Roach'" , "'Rohan Mahy'" , Subject: RE: [Simple] XCAP and Webdav (was: XCAP batching) Message-ID: <048d01c33106$49eb0650$fdcb90c6@lisalap> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3A6484F@dyn-tx-exch-001.dynamicsoft.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Envelope-To: adam@dynamicsoft.com, rohan@cisco.com, simple@ietf.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5CHFtm08658 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 12 Jun 2003 10:15:56 -0700 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sure, but why wouldn't you use XPATH to change pieces of the document on the client side then send the whole thing back to the server? Over Internet latencies with files this small, this is likely to be faster for the user anyway. Then the protocol needn't bother with this complication. I really don't understand why partial PUT is necessary, but if it is, I would recommend the following (and you would likely get support or assistance from other WebDAV implementors in defining and developing this): - Define a MIME type for an XPATH-based modification to an XML document. Perhaps this MIME type exists already -- a stylesheet type? - Define a method like PATCH or PUTPATCH to send this document to the resource to be modified - Beyond this new mechanism, simply use HTTP GET/PUT/DELETE, and WebDAV PROPFIND/MOVE/COPY/LOCK/UNLOCK, and possibly the DeltaV CHECKOUT/CHECKIN to create a working resource in a 'sandbox' while the PATCHes are applied. A patch or "partial put" mechanism has been discussed in WebDAV circles for a long time, and only other work has prevented us from proceeding on it. Generally the idea is to have a byte-oriented diff mechanism that isn't limited to XML -- one that can be applied to text documents, images, etc. However, much of the same work would need to be done. For example, a PATCH method could be defined that took a couple of different MIME types depending on what mechanism is used to patch the target file. Lisa > -----Original Message----- > From: Adam Roach [mailto:adam@dynamicsoft.com] > Sent: Thursday, June 12, 2003 8:50 AM > To: 'Rohan Mahy'; simple@ietf.org > Cc: lisa@xythos.com > Subject: RE: [Simple] XCAP and Webdav (was: XCAP batching) > > > Lisa Dusseault wrote: > > > 5. To change the default buddy list, or any profile buddy list, the > > client does a LOCK, GET, PUT, UNLOCK. As soon as the PUT > occurs the > > new buddy listis visible to other clients but since the whole file > > is internally consistent this is great. > > The issue is that XCAP is specifically being defined so that > you don't have to PUT the entire document. In a nutshell, it > uses XPATH syntax to specify a subset of an XML document to > be updated. > > Consequently, there's a need to be able to lock a whole > document, perform *several* updates on subsections of that > document, and then unlock the whole document. Until the final > update, the document is not typically in a consistent state. > > So, the two approaches that have been mentioned so far are: > > 1) Prevent reading while a document is locked for writing > (except, obviously, by the client who has the document locked). > > or: > > 2) LOCK the document, COPY it somewhere that others won't try to > access it, perform multiple updates on the temporary copy, COPY > the temporary document back to its original location, and UNLOCK > the document. It's a bit chatty, but it doesn't require any > modifications to existing WEBDAV servers. > > /a > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Jun 13 11:18:35 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 LAA09423; Fri, 13 Jun 2003 11:18:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QqHz-00068n-00; Fri, 13 Jun 2003 11:16:27 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19QqHy-00068k-00; Fri, 13 Jun 2003 11:16:26 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CNS1a01295; Thu, 12 Jun 2003 19:28:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CNR2m01264 for ; Thu, 12 Jun 2003 19:27:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01308 for ; Thu, 12 Jun 2003 19:26:59 -0400 (EDT) From: Markus.Isomaki@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QbR8-0006xD-00 for simple@ietf.org; Thu, 12 Jun 2003 19:24:54 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19QbR7-0006xA-00 for simple@ietf.org; Thu, 12 Jun 2003 19:24:53 -0400 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h5CNQx927654 for ; Fri, 13 Jun 2003 02:26:59 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 13 Jun 2003 02:26:59 +0300 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 13 Jun 2003 02:26:59 +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" Message-ID: Thread-Topic: Comments on draft-ietf-simple-data-req-02.txt Thread-Index: AcMLWgybkc+7eTOkQvqecZ+lcN5n0Al2SRsA To: Cc: X-OriginalArrivalTime: 12 Jun 2003 23:26:59.0349 (UTC) FILETIME=[1EF12450:01C3313A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5CNR2m01265 Subject: [Simple] RE: Comments on draft-ietf-simple-data-req-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: Fri, 13 Jun 2003 02:26:58 +0300 Content-Transfer-Encoding: 8bit Hi, I'll be working on a new version of the data manipulation requirements draft. During the WG last call there were basically only two comments to the -02 version of the draft, one from Ben Campbell and the other from Krisztian Kiss. I'll answer both separately to try to establish concensus on the points raised in them. (To my knowledge 3GPP CN1 WG is also reviewing their specific reqs to data manipulation, so if there is something specific, please send that to the list too.) The main scoping issue is whether to inlude the default presence document publishing/upload reqs in this document, or should they be separated. My assumption would be to have a separate reqs draft for them, but I would be happy to incorporate them in this doc as well, if people prefer that. Comments to Ben inline: > -----Original Message----- > From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] > Sent: 25 April, 2003 21:39 > To: Isomaki Markus (NRC/Helsinki) > Cc: Simple WG > Subject: Comments on draft-ietf-simple-data-req-02.txt > > > General: Although there are a couple of extensibility > requirements, I am > a litte concerned that this document is too focused on > current concrete > data requirements, and not enough focused on abstracting > these data in a > more extensible way. I cannot imagine that we can predict the > data needs > of every deployed system in advance, but I would expect the data > _mechanism_ to be extensible to types of data we have not yet thought > about. > Personally I completely agree with you. However, I think the scoping of this initial SIMPLE data manipulation work was discussed a couple of times last year, and the conclusion was that for now we should focus on requirements for presence list and presence authorization policy management, as stated in the charter. So, the scope of this draft is that, not data manipulation in general. Having a protocol such as XCAP for doing these operations does allow flexibility, and I think separate requirements drafts for new XCAP application usages would be fine, such as for default presence state publishing. > For example, there was considerable discussion about default presence > documents on a different thread, where several people suggested that > configuration of these defaults should be a data manipulation > mechanism > requirement. But that is not listed in this doc, nor do I see any > extensibility requirement that leads me to expect that the mechanism > must be extensible to handle this class of data. (There is a > requirement > about choosing the presence doc a user sees in the authorization > section, but it is not clear to me if that was intended to meet this > requirement.) > These are good points and I belive the concensus definitely is that default presence document uploading will be done with the same data manipulation solution (in practice XCAP). This is not in the scope of this requirements draft, however. I think we need separate reqs for that (that can be very short, and should be done quickly), and for other data manipulation usages in the future too. > I think this document could use some more explicit scoping language. > There are some requirements that are to be applied to events > other than > presence, and others that appear to be presence specific. > This should be > stated explicitly. > OK, I think that the scope of this draft should be presence, even though it is easy to see that the same reqs could apply to SIP events in general. > PC-1 - The wording can be interpreted to imply a single presentity > collection. I think it must be possible to create multiple collections > with distinct URIs. Later requirements seem to support this, but it > should be explicit. > Yes, I think a user should be able to have multiple presentity collections. > PC-2 and 3: These seems like mechanism rather than requirement. Why is > necessary for the protocol to allow both approaches? > In some cases the (human) user might want to influence what the URI should be, in other cases the client would like to leave this completely up to the server. I don't see such harm in having both ways possible. > PC-5: There is nothing inherent in a URI that tells you if it > represents > a list or a single presentity. The only way to implement this would be > to actually attempt a subscription, which I doubt is your > intent. Do you > mean this as a way to control where the supported header for lists is > used? If this is a real requirement, it may force new requirements on > the list draft. > I think you are right. URI for a list is exactly similar to URI for a single presentity. So in all cases clearly this req can't be met. Unless someone has a good reason for keeping this req as it is, I'll reword it. I think a more relevant req is that a presence list can be hierarchically structured, as in XCAP presence list usage proposal. > PC-10: May need to break this up into read and write access, etc. You > may want to have users who can read the collection contents, but not > change it. > Agreed. I'll add that. > PC-12: I don't believe cached lists necessarily imply a > requirement for > change notification. The real thing that forces this > requirement is the > ability for the list to be changed by some other actor than the client > while the client is running. If this is the intent, then we need a > requirement for it. > Agreed. Change notification is needed since multiple clients may be manipulating the same data, while they are on-line. I'll reword the reqs. > > PC-15: Unless there is an assumption that the protocol cannot > offer any > feature not listed as a requirement, then MAY requirements are not > useful in a requirements document. If this is important enough to > mention, it probably should be a SHOULD. > OK. > PC-21. I think this requirement needs more justification. In fact, we > should probably back up and look for root requirements behind it. What > is it you want to accomplish with a proxy? For example, if it is for > firewall traversal, then the requirements should be about firewall > traversal--and proxies might be a mechanism to accomplish that. > True. Firewall traversal is probably one thing that would be beneficial, also I think something like compression and security association sharing (one client using multiple servers) on the first hop would be derirable features, that proxy allows, so at least for me it would be OK to enumerate the real needs separately. > PC-22: (nit) this seems out of place--it should be grouped with the > other manipulation requirements. > OK, will be moved. > PC-23: I think we should separate intermittent and low bandwidth into > two requirements. Also, it might be useful to define what sort of > bandwidth is considered low--newer wireless devices are every bit as > fast as an average dial up connection. > Right. Even though I'm very much involved with wireless devices I'm not sure if this kind of requirement is really quantifiable. It might be best to speak about ability to compress and aiming at efficient encoding. > PC-24: This looks suspiciously like one of those "you can't make us > implement multiple protocols in a client" requirements, which are > generally looked upon with skepticism in the IETF. Do we want > this to be > a general directory interface? Also, this requirement would seem to > imply we need to be able to create entries to which we do not > intend to > subscribe. > I think this could be a SHOULD-level requirement. I think it makes sense that a user can share lists among multiple applications, so that the "master-copy" is in some kind of phonebook, but it is not completely clear to me how much this is just implementation issue. In practice I think this means that it MUST be possible to have links to data elsewhere within the presence list structure. Would that sound more reasonable? > PC-25: (nit) out of place. (see comment on 22) OK. > > 5.1: I think we need a requirement allowing for wildcards in > blocked and > allow lists. For example, allow everyone in my domain... > True. However, I think we could limit the support to just that: allow everyone in some domain, and not make this completely generic, for simplicity, and just to support the real need. > g-5 (and previous similar) I really think this should be a > SHOULD, not a > must. That is, I would really hate to reject some existing > protocol for > the sole reason of it using a different authentication scheme > than SIP. > I think you mean G-6. Agree, can be SHOULD. > 7: To Do items need to be closed before progressing the draft. > OK. Markus > > On Thu, 2003-04-17 at 09:27, Robert Sparks wrote: > > This is a SIMPLE working group Last Call for comments on > > > http://www.ietf.org/internet-drafts/draft-ietf-simple-data-req-02.txt > > > > Please review the draft and provide comments by May 5 > > > > RjS. > > > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Fri Jun 13 11:19:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09447 for ; Fri, 13 Jun 2003 11:19:06 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5DFIcj20134 for simple-archive@odin.ietf.org; Fri, 13 Jun 2003 11:18:38 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DFIbm20131 for ; Fri, 13 Jun 2003 11:18: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 LAA09423; Fri, 13 Jun 2003 11:18:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QqHz-00068n-00; Fri, 13 Jun 2003 11:16:27 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19QqHy-00068k-00; Fri, 13 Jun 2003 11:16:26 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CNS1a01295; Thu, 12 Jun 2003 19:28:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CNR2m01264 for ; Thu, 12 Jun 2003 19:27:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01308 for ; Thu, 12 Jun 2003 19:26:59 -0400 (EDT) From: Markus.Isomaki@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QbR8-0006xD-00 for simple@ietf.org; Thu, 12 Jun 2003 19:24:54 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19QbR7-0006xA-00 for simple@ietf.org; Thu, 12 Jun 2003 19:24:53 -0400 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h5CNQx927654 for ; Fri, 13 Jun 2003 02:26:59 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 13 Jun 2003 02:26:59 +0300 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 13 Jun 2003 02:26:59 +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" Message-ID: Thread-Topic: Comments on draft-ietf-simple-data-req-02.txt Thread-Index: AcMLWgybkc+7eTOkQvqecZ+lcN5n0Al2SRsA To: Cc: X-OriginalArrivalTime: 12 Jun 2003 23:26:59.0349 (UTC) FILETIME=[1EF12450:01C3313A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5CNR2m01265 Subject: [Simple] RE: Comments on draft-ietf-simple-data-req-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: Fri, 13 Jun 2003 02:26:58 +0300 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi, I'll be working on a new version of the data manipulation requirements draft. During the WG last call there were basically only two comments to the -02 version of the draft, one from Ben Campbell and the other from Krisztian Kiss. I'll answer both separately to try to establish concensus on the points raised in them. (To my knowledge 3GPP CN1 WG is also reviewing their specific reqs to data manipulation, so if there is something specific, please send that to the list too.) The main scoping issue is whether to inlude the default presence document publishing/upload reqs in this document, or should they be separated. My assumption would be to have a separate reqs draft for them, but I would be happy to incorporate them in this doc as well, if people prefer that. Comments to Ben inline: > -----Original Message----- > From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] > Sent: 25 April, 2003 21:39 > To: Isomaki Markus (NRC/Helsinki) > Cc: Simple WG > Subject: Comments on draft-ietf-simple-data-req-02.txt > > > General: Although there are a couple of extensibility > requirements, I am > a litte concerned that this document is too focused on > current concrete > data requirements, and not enough focused on abstracting > these data in a > more extensible way. I cannot imagine that we can predict the > data needs > of every deployed system in advance, but I would expect the data > _mechanism_ to be extensible to types of data we have not yet thought > about. > Personally I completely agree with you. However, I think the scoping of this initial SIMPLE data manipulation work was discussed a couple of times last year, and the conclusion was that for now we should focus on requirements for presence list and presence authorization policy management, as stated in the charter. So, the scope of this draft is that, not data manipulation in general. Having a protocol such as XCAP for doing these operations does allow flexibility, and I think separate requirements drafts for new XCAP application usages would be fine, such as for default presence state publishing. > For example, there was considerable discussion about default presence > documents on a different thread, where several people suggested that > configuration of these defaults should be a data manipulation > mechanism > requirement. But that is not listed in this doc, nor do I see any > extensibility requirement that leads me to expect that the mechanism > must be extensible to handle this class of data. (There is a > requirement > about choosing the presence doc a user sees in the authorization > section, but it is not clear to me if that was intended to meet this > requirement.) > These are good points and I belive the concensus definitely is that default presence document uploading will be done with the same data manipulation solution (in practice XCAP). This is not in the scope of this requirements draft, however. I think we need separate reqs for that (that can be very short, and should be done quickly), and for other data manipulation usages in the future too. > I think this document could use some more explicit scoping language. > There are some requirements that are to be applied to events > other than > presence, and others that appear to be presence specific. > This should be > stated explicitly. > OK, I think that the scope of this draft should be presence, even though it is easy to see that the same reqs could apply to SIP events in general. > PC-1 - The wording can be interpreted to imply a single presentity > collection. I think it must be possible to create multiple collections > with distinct URIs. Later requirements seem to support this, but it > should be explicit. > Yes, I think a user should be able to have multiple presentity collections. > PC-2 and 3: These seems like mechanism rather than requirement. Why is > necessary for the protocol to allow both approaches? > In some cases the (human) user might want to influence what the URI should be, in other cases the client would like to leave this completely up to the server. I don't see such harm in having both ways possible. > PC-5: There is nothing inherent in a URI that tells you if it > represents > a list or a single presentity. The only way to implement this would be > to actually attempt a subscription, which I doubt is your > intent. Do you > mean this as a way to control where the supported header for lists is > used? If this is a real requirement, it may force new requirements on > the list draft. > I think you are right. URI for a list is exactly similar to URI for a single presentity. So in all cases clearly this req can't be met. Unless someone has a good reason for keeping this req as it is, I'll reword it. I think a more relevant req is that a presence list can be hierarchically structured, as in XCAP presence list usage proposal. > PC-10: May need to break this up into read and write access, etc. You > may want to have users who can read the collection contents, but not > change it. > Agreed. I'll add that. > PC-12: I don't believe cached lists necessarily imply a > requirement for > change notification. The real thing that forces this > requirement is the > ability for the list to be changed by some other actor than the client > while the client is running. If this is the intent, then we need a > requirement for it. > Agreed. Change notification is needed since multiple clients may be manipulating the same data, while they are on-line. I'll reword the reqs. > > PC-15: Unless there is an assumption that the protocol cannot > offer any > feature not listed as a requirement, then MAY requirements are not > useful in a requirements document. If this is important enough to > mention, it probably should be a SHOULD. > OK. > PC-21. I think this requirement needs more justification. In fact, we > should probably back up and look for root requirements behind it. What > is it you want to accomplish with a proxy? For example, if it is for > firewall traversal, then the requirements should be about firewall > traversal--and proxies might be a mechanism to accomplish that. > True. Firewall traversal is probably one thing that would be beneficial, also I think something like compression and security association sharing (one client using multiple servers) on the first hop would be derirable features, that proxy allows, so at least for me it would be OK to enumerate the real needs separately. > PC-22: (nit) this seems out of place--it should be grouped with the > other manipulation requirements. > OK, will be moved. > PC-23: I think we should separate intermittent and low bandwidth into > two requirements. Also, it might be useful to define what sort of > bandwidth is considered low--newer wireless devices are every bit as > fast as an average dial up connection. > Right. Even though I'm very much involved with wireless devices I'm not sure if this kind of requirement is really quantifiable. It might be best to speak about ability to compress and aiming at efficient encoding. > PC-24: This looks suspiciously like one of those "you can't make us > implement multiple protocols in a client" requirements, which are > generally looked upon with skepticism in the IETF. Do we want > this to be > a general directory interface? Also, this requirement would seem to > imply we need to be able to create entries to which we do not > intend to > subscribe. > I think this could be a SHOULD-level requirement. I think it makes sense that a user can share lists among multiple applications, so that the "master-copy" is in some kind of phonebook, but it is not completely clear to me how much this is just implementation issue. In practice I think this means that it MUST be possible to have links to data elsewhere within the presence list structure. Would that sound more reasonable? > PC-25: (nit) out of place. (see comment on 22) OK. > > 5.1: I think we need a requirement allowing for wildcards in > blocked and > allow lists. For example, allow everyone in my domain... > True. However, I think we could limit the support to just that: allow everyone in some domain, and not make this completely generic, for simplicity, and just to support the real need. > g-5 (and previous similar) I really think this should be a > SHOULD, not a > must. That is, I would really hate to reject some existing > protocol for > the sole reason of it using a different authentication scheme > than SIP. > I think you mean G-6. Agree, can be SHOULD. > 7: To Do items need to be closed before progressing the draft. > OK. Markus > > On Thu, 2003-04-17 at 09:27, Robert Sparks wrote: > > This is a SIMPLE working group Last Call for comments on > > > http://www.ietf.org/internet-drafts/draft-ietf-simple-data-req-02.txt > > > > Please review the draft and provide comments by May 5 > > > > RjS. > > > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Jun 13 11:29: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 LAA09723; Fri, 13 Jun 2003 11:29:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QqS7-0006C6-00; Fri, 13 Jun 2003 11:26:55 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19QqS7-0006C3-00; Fri, 13 Jun 2003 11:26:55 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CNv1a02979; Thu, 12 Jun 2003 19:57:01 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CNuSm02967 for ; Thu, 12 Jun 2003 19:56: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 TAA01871 for ; Thu, 12 Jun 2003 19:56:27 -0400 (EDT) From: Markus.Isomaki@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Qbtb-00077T-00 for simple@ietf.org; Thu, 12 Jun 2003 19:54:19 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19Qbtb-00077Q-00 for simple@ietf.org; Thu, 12 Jun 2003 19:54:19 -0400 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h5CNuP912114 for ; Fri, 13 Jun 2003 02:56:25 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 13 Jun 2003 02:56:25 +0300 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 13 Jun 2003 02:56:25 +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" Subject: RE: [Simple] Comments on draft-ietf-simple-data-req-02.txt Message-ID: Thread-Topic: [Simple] Comments on draft-ietf-simple-data-req-02.txt Thread-Index: AcMLWjgklYRv+iOORKK1rCGOICaepAFZ+4MACB3/nxA= To: , Cc: X-OriginalArrivalTime: 12 Jun 2003 23:56:25.0653 (UTC) FILETIME=[3BBDBE50:01C3313E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5CNuSm02968 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 13 Jun 2003 02:56:24 +0300 Content-Transfer-Encoding: 8bit Hi Krisztian, Thanks for your comments, see my responses inline. I think the main points about these comments are these: - Do we need the notification policies at all? - What information should it be possible to use for authorizing presence document, and do we operate on tuple-level or with higher granularity when deciding what to give. Markus > -----Original Message----- > From: Kiss Krisztian (NRC/Tampere) > Sent: 02 May, 2003 20:51 > To: 'ext Ben Campbell'; Isomaki Markus (NRC/Helsinki) > Cc: 'Simple WG' > Subject: RE: [Simple] Comments on draft-ietf-simple-data-req-02.txt > > > Jonathan et al, > > Please find below some comments on draft-ietf-simple-data-req-02: > > - REQ PC-9 defines that a user could query for a "set of > URIs" of a collection. I believe this kind of query should > return all information available for the presentity > collection in addition to the set of URIs. Additionally, the > REQ should also define those users who are authorized to make > this query. According to PC-10 and PC-11, there are already > two kind of authorized lists defined, one list is for the > users who are allowed to subscribe to the list, another list > is for the users who are allowed to manipulate the attributes > of the list. Probably the group of the users allowed to query > equals to the group who are allowed to subscribe. One > re-wording of the sentence could be as follows: "It MUST be > possible for the authorized users allowed to subscribe to the > list also to query for information of the particular > presentity collection by providing the URI for the presentity > collection." > At least as a default authorization policy this would make sense, so if there are no objections, we could incorporate your proposal. > -REQ PC-24: I am wondering about the justification for this > REQ. It sounds rather an implementation issue instead of a > requirement that would have effects on the final solution. It > might cause unnecessary and additional complexity for the > solution. To tell the truth, I am confused why the network > resident address book has some special role here, if this is > the case, we could also have REQs for other type of > "collection kind of resources", e.g. presence access list, > etc. Anyway, it'd good to have a more generic REQ instead, > with a strength SHOULD instead of MUST. > Ben Campbell had similar comment. I think it would be useful to allow sharing of lists (or other data) among applications. I think SHOULD-level req is OK, with explanation that this kind of linking is the intended use here. > -REQ AP-7: I believe there is no need for this requirement. > In the requirement phase, the best would be to keep distinct > roles for the different lists, the buddy list is for the > presentity's own subscription purposes, the allowed and > blocked lists are for authorization purposes. > I tend to agree. This req is generated by Jonathan. I believe he derived it from some existing IM/presence systems, which have this kind of feature. Jonathan (&others), do you see this as a necessary feature? On the other hand, if we allow links to be included, then I suppose the allowed-list would be just a link to presence list. Would this be an OK approach? > -REQ AP-8: would be good to have more exact wording in the > last sentence of the requirement. I guess the assumption here > is that the meaning behind the "add, remove, modify, read, > clear and create and delete" operations must be clear for the > reader based on the PC requirements, however here we are > talking about multiple lists, therefore it is unclear whether > the remove, delete and clear operations are meant for the > individual entries of a list, the list itself, or all the > lists handled by the authorization policy. > I think they are for individual entries. I'll try to make this more clear. > -REQ N1-5: all the notification requirements listed in > chapter 5.2 are somehow "less important". If we can set > "when" type of requirements (criteria when notifications are > delivered to watchers) also to authorization, additionally to > filtering, throttling and local server policies, we may end > up having too complex rules about generating notifications. > Yes, I think there hasn't been enough discussion on the necessity of these requirements. Personally I don't see them necessary. Jonathan? In any case I'll start a separate thread about this to see if anyone has any opinion. > -REQ C1-3: These requirements seem too specific and rather > unclear. The first issue is why only the contact address and > status are chosen as presence attributes that the user can > set by authorization. Maybe a generic requirement would be > enough saying that the authorized content could be specified > by using any presence attribute. The second issue, which is > rather important, if these requirements mean that after > authorization the whole tuple including the attribute is > omitted, or only the chosen attribute from the tuple. More > clearly, is the aim to allow for the user to define which > presence attributes to authorize within a tuple or rather to > authorize tuples (i.e. what is the atomic element handled by > the content policy)? > Well, nowadays it is hard to say even what a tuple is ;) I think this will need more list discussion as well. > -REQ C-4: I guess it would be better to place this before > C1-3. Assuming that the previous requirements were meant for > selecting attributes within a tuple, this REQ seem to allow > to select a whole tuple. Does this requirement allow any > presence attribute (e.g. one RPIDS extensions, tuple-id) to > be used as a criteria for selecting the tuples? > To be handled within the same discussion. > -REQ C-6: this REQ sounds like one covering the delivery of > default presence documents. I would prefer to mention here > explicitly that DM is used for publication of the default > presence document. Also, a strength of MUST would be better > instead of the SHOULD. A rewording could be: It MUST be > possible for the user to publish a presence document with > default presence attributes. > I think it would be OK to take away this requirement from this draft and collect the requirements for default presence doc publishing separately. Unless someone thinks this req is important for some other purpose. > Additional requirements: > > -REQ-PC-x: > A requirement about storing an XML document including > filtering information by using the data manipulation > mechanism. This could be useful for presentity collections > where different URIs of the collection could have either > common or individual filter definitions pre-defined, and the > watcher(s) would not need to include any filter information > within the subscription. > OK, I suppose this could be an addition to the presence list requirements. Something that could be optionally supported by the server. > -REQ AP-x: > A requirement might be justified for the expected behavior of > the acceptance policy when a watcher is part of several > lists, e.g. multiple allowed lists. The policy could define, > for example, an evaluation order for the lists, and the > policy would stop evaluating the lists when the particular > watcher is found. An alternative could be that the watcher > cannot belong to several lists, however this does not sound > feasible, especially if it is possible to use wildcards for > defining URIs. Well, there are two models: either separate lists for different acceptance rule (allow, block etc.) or a single list with different rule for each entry. Maybe I need to reword the reqs so that this is not yet determined. What we want to achieve is to accept some users and block some others, and have some "pending". I don't think we need to actually even say how these rules are organized in this requirements draft. > > -REQ C-x: > A requirement, when the presentity authorizes different > values of the otherwise same "data segment" to different > watchers. One motivation here is the ability to give > different level of details of information (e.g. w.r.t. > location) to different watchers. Perhaps this is hidden > behind some of the requirements, but it would be rather good > to explicitly state it. I think this is a valid case, so I'll try to include it somehow. I don't think this will actually add anything new for the solution, but probably it has some link to publishing as well. > REQ C-5 covers this partly, however it makes a hint that new > values of attributes are to be modified from existing values. > By taking the geographical location information example, the > difference between the information to be delivered to > different watchers is only in the level of details. > Therefore, there could be another approach that tuples would > be assigned for the different level of details and > authorization would be done based on some kind of "level of > detail" attribute. > OK, do you have some text to propose? > -REQ ?-x: > Relation between the content requirements and the acceptance > policy requirements are somehow undefined. When the > acceptance policy results in accepting a watcher, then which > content/notification requirements shall be applied, how and > where this relation would be defined. > OK, I'll try to clarify that. I guess acceptance is the first steps, and subsequent rules would cover the content to be given. > Thanks, > Krisztian > Markus _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Fri Jun 13 11:29:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09772 for ; Fri, 13 Jun 2003 11:29:34 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5DFT6m20695 for simple-archive@odin.ietf.org; Fri, 13 Jun 2003 11:29:06 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DFT6m20692 for ; Fri, 13 Jun 2003 11: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 LAA09723; Fri, 13 Jun 2003 11:29:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QqS7-0006C6-00; Fri, 13 Jun 2003 11:26:55 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19QqS7-0006C3-00; Fri, 13 Jun 2003 11:26:55 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CNv1a02979; Thu, 12 Jun 2003 19:57:01 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CNuSm02967 for ; Thu, 12 Jun 2003 19:56: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 TAA01871 for ; Thu, 12 Jun 2003 19:56:27 -0400 (EDT) From: Markus.Isomaki@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Qbtb-00077T-00 for simple@ietf.org; Thu, 12 Jun 2003 19:54:19 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19Qbtb-00077Q-00 for simple@ietf.org; Thu, 12 Jun 2003 19:54:19 -0400 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h5CNuP912114 for ; Fri, 13 Jun 2003 02:56:25 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 13 Jun 2003 02:56:25 +0300 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 13 Jun 2003 02:56:25 +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" Subject: RE: [Simple] Comments on draft-ietf-simple-data-req-02.txt Message-ID: Thread-Topic: [Simple] Comments on draft-ietf-simple-data-req-02.txt Thread-Index: AcMLWjgklYRv+iOORKK1rCGOICaepAFZ+4MACB3/nxA= To: , Cc: X-OriginalArrivalTime: 12 Jun 2003 23:56:25.0653 (UTC) FILETIME=[3BBDBE50:01C3313E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5CNuSm02968 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 13 Jun 2003 02:56:24 +0300 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi Krisztian, Thanks for your comments, see my responses inline. I think the main points about these comments are these: - Do we need the notification policies at all? - What information should it be possible to use for authorizing presence document, and do we operate on tuple-level or with higher granularity when deciding what to give. Markus > -----Original Message----- > From: Kiss Krisztian (NRC/Tampere) > Sent: 02 May, 2003 20:51 > To: 'ext Ben Campbell'; Isomaki Markus (NRC/Helsinki) > Cc: 'Simple WG' > Subject: RE: [Simple] Comments on draft-ietf-simple-data-req-02.txt > > > Jonathan et al, > > Please find below some comments on draft-ietf-simple-data-req-02: > > - REQ PC-9 defines that a user could query for a "set of > URIs" of a collection. I believe this kind of query should > return all information available for the presentity > collection in addition to the set of URIs. Additionally, the > REQ should also define those users who are authorized to make > this query. According to PC-10 and PC-11, there are already > two kind of authorized lists defined, one list is for the > users who are allowed to subscribe to the list, another list > is for the users who are allowed to manipulate the attributes > of the list. Probably the group of the users allowed to query > equals to the group who are allowed to subscribe. One > re-wording of the sentence could be as follows: "It MUST be > possible for the authorized users allowed to subscribe to the > list also to query for information of the particular > presentity collection by providing the URI for the presentity > collection." > At least as a default authorization policy this would make sense, so if there are no objections, we could incorporate your proposal. > -REQ PC-24: I am wondering about the justification for this > REQ. It sounds rather an implementation issue instead of a > requirement that would have effects on the final solution. It > might cause unnecessary and additional complexity for the > solution. To tell the truth, I am confused why the network > resident address book has some special role here, if this is > the case, we could also have REQs for other type of > "collection kind of resources", e.g. presence access list, > etc. Anyway, it'd good to have a more generic REQ instead, > with a strength SHOULD instead of MUST. > Ben Campbell had similar comment. I think it would be useful to allow sharing of lists (or other data) among applications. I think SHOULD-level req is OK, with explanation that this kind of linking is the intended use here. > -REQ AP-7: I believe there is no need for this requirement. > In the requirement phase, the best would be to keep distinct > roles for the different lists, the buddy list is for the > presentity's own subscription purposes, the allowed and > blocked lists are for authorization purposes. > I tend to agree. This req is generated by Jonathan. I believe he derived it from some existing IM/presence systems, which have this kind of feature. Jonathan (&others), do you see this as a necessary feature? On the other hand, if we allow links to be included, then I suppose the allowed-list would be just a link to presence list. Would this be an OK approach? > -REQ AP-8: would be good to have more exact wording in the > last sentence of the requirement. I guess the assumption here > is that the meaning behind the "add, remove, modify, read, > clear and create and delete" operations must be clear for the > reader based on the PC requirements, however here we are > talking about multiple lists, therefore it is unclear whether > the remove, delete and clear operations are meant for the > individual entries of a list, the list itself, or all the > lists handled by the authorization policy. > I think they are for individual entries. I'll try to make this more clear. > -REQ N1-5: all the notification requirements listed in > chapter 5.2 are somehow "less important". If we can set > "when" type of requirements (criteria when notifications are > delivered to watchers) also to authorization, additionally to > filtering, throttling and local server policies, we may end > up having too complex rules about generating notifications. > Yes, I think there hasn't been enough discussion on the necessity of these requirements. Personally I don't see them necessary. Jonathan? In any case I'll start a separate thread about this to see if anyone has any opinion. > -REQ C1-3: These requirements seem too specific and rather > unclear. The first issue is why only the contact address and > status are chosen as presence attributes that the user can > set by authorization. Maybe a generic requirement would be > enough saying that the authorized content could be specified > by using any presence attribute. The second issue, which is > rather important, if these requirements mean that after > authorization the whole tuple including the attribute is > omitted, or only the chosen attribute from the tuple. More > clearly, is the aim to allow for the user to define which > presence attributes to authorize within a tuple or rather to > authorize tuples (i.e. what is the atomic element handled by > the content policy)? > Well, nowadays it is hard to say even what a tuple is ;) I think this will need more list discussion as well. > -REQ C-4: I guess it would be better to place this before > C1-3. Assuming that the previous requirements were meant for > selecting attributes within a tuple, this REQ seem to allow > to select a whole tuple. Does this requirement allow any > presence attribute (e.g. one RPIDS extensions, tuple-id) to > be used as a criteria for selecting the tuples? > To be handled within the same discussion. > -REQ C-6: this REQ sounds like one covering the delivery of > default presence documents. I would prefer to mention here > explicitly that DM is used for publication of the default > presence document. Also, a strength of MUST would be better > instead of the SHOULD. A rewording could be: It MUST be > possible for the user to publish a presence document with > default presence attributes. > I think it would be OK to take away this requirement from this draft and collect the requirements for default presence doc publishing separately. Unless someone thinks this req is important for some other purpose. > Additional requirements: > > -REQ-PC-x: > A requirement about storing an XML document including > filtering information by using the data manipulation > mechanism. This could be useful for presentity collections > where different URIs of the collection could have either > common or individual filter definitions pre-defined, and the > watcher(s) would not need to include any filter information > within the subscription. > OK, I suppose this could be an addition to the presence list requirements. Something that could be optionally supported by the server. > -REQ AP-x: > A requirement might be justified for the expected behavior of > the acceptance policy when a watcher is part of several > lists, e.g. multiple allowed lists. The policy could define, > for example, an evaluation order for the lists, and the > policy would stop evaluating the lists when the particular > watcher is found. An alternative could be that the watcher > cannot belong to several lists, however this does not sound > feasible, especially if it is possible to use wildcards for > defining URIs. Well, there are two models: either separate lists for different acceptance rule (allow, block etc.) or a single list with different rule for each entry. Maybe I need to reword the reqs so that this is not yet determined. What we want to achieve is to accept some users and block some others, and have some "pending". I don't think we need to actually even say how these rules are organized in this requirements draft. > > -REQ C-x: > A requirement, when the presentity authorizes different > values of the otherwise same "data segment" to different > watchers. One motivation here is the ability to give > different level of details of information (e.g. w.r.t. > location) to different watchers. Perhaps this is hidden > behind some of the requirements, but it would be rather good > to explicitly state it. I think this is a valid case, so I'll try to include it somehow. I don't think this will actually add anything new for the solution, but probably it has some link to publishing as well. > REQ C-5 covers this partly, however it makes a hint that new > values of attributes are to be modified from existing values. > By taking the geographical location information example, the > difference between the information to be delivered to > different watchers is only in the level of details. > Therefore, there could be another approach that tuples would > be assigned for the different level of details and > authorization would be done based on some kind of "level of > detail" attribute. > OK, do you have some text to propose? > -REQ ?-x: > Relation between the content requirements and the acceptance > policy requirements are somehow undefined. When the > acceptance policy results in accepting a watcher, then which > content/notification requirements shall be applied, how and > where this relation would be defined. > OK, I'll try to clarify that. I guess acceptance is the first steps, and subsequent rules would cover the content to be given. > Thanks, > Krisztian > Markus _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Jun 13 12:57:53 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 MAA12212; Fri, 13 Jun 2003 12:57:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Qrq6-0006kW-00; Fri, 13 Jun 2003 12:55:46 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Qrq5-0006kT-00; Fri, 13 Jun 2003 12:55:45 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DFZ2a21054; Fri, 13 Jun 2003 11:35:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DFYVm21031 for ; Fri, 13 Jun 2003 11:34:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09946 for ; Fri, 13 Jun 2003 11:34:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QqXN-0006ER-00 for simple@ietf.org; Fri, 13 Jun 2003 11:32:21 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 19QqXM-0006EO-00 for simple@ietf.org; Fri, 13 Jun 2003 11:32:20 -0400 Received: from localhost (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id h5DFYM5k043052; Fri, 13 Jun 2003 10:34:23 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) From: Ben Campbell To: Markus.Isomaki@nokia.com Cc: Simple WG In-Reply-To: References: Content-Type: text/plain Message-Id: <1055517934.2614.30.camel@verite.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.0 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] RE: Comments on draft-ietf-simple-data-req-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: 13 Jun 2003 10:25:35 -0500 Content-Transfer-Encoding: 7bit On Thu, 2003-06-12 at 18:26, Markus.Isomaki@nokia.com wrote: [...] > > > PC-2 and 3: These seems like mechanism rather than requirement. Why is > > necessary for the protocol to allow both approaches? > > > > In some cases the (human) user might want to influence what the URI should be, in other cases the client would like to leave this completely up to the server. I don't see such harm in having both ways possible. > Just so long as we think the value of having both approaches is greater than the cost of additional protocol complexity to support both. [...] _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Fri Jun 13 12:58:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12406 for ; Fri, 13 Jun 2003 12:58:24 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5DGvv001805 for simple-archive@odin.ietf.org; Fri, 13 Jun 2003 12:57:57 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DGvvm01802 for ; Fri, 13 Jun 2003 12:57: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 MAA12212; Fri, 13 Jun 2003 12:57:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Qrq6-0006kW-00; Fri, 13 Jun 2003 12:55:46 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Qrq5-0006kT-00; Fri, 13 Jun 2003 12:55:45 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DFZ2a21054; Fri, 13 Jun 2003 11:35:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DFYVm21031 for ; Fri, 13 Jun 2003 11:34:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09946 for ; Fri, 13 Jun 2003 11:34:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QqXN-0006ER-00 for simple@ietf.org; Fri, 13 Jun 2003 11:32:21 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 19QqXM-0006EO-00 for simple@ietf.org; Fri, 13 Jun 2003 11:32:20 -0400 Received: from localhost (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id h5DFYM5k043052; Fri, 13 Jun 2003 10:34:23 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) From: Ben Campbell To: Markus.Isomaki@nokia.com Cc: Simple WG In-Reply-To: References: Content-Type: text/plain Message-Id: <1055517934.2614.30.camel@verite.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.0 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] RE: Comments on draft-ietf-simple-data-req-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: 13 Jun 2003 10:25:35 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Thu, 2003-06-12 at 18:26, Markus.Isomaki@nokia.com wrote: [...] > > > PC-2 and 3: These seems like mechanism rather than requirement. Why is > > necessary for the protocol to allow both approaches? > > > > In some cases the (human) user might want to influence what the URI should be, in other cases the client would like to leave this completely up to the server. I don't see such harm in having both ways possible. > Just so long as we think the value of having both approaches is greater than the cost of additional protocol complexity to support both. [...] _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Jun 13 13:19:55 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 NAA13938; Fri, 13 Jun 2003 13:19:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QsBQ-0007AH-00; Fri, 13 Jun 2003 13:17:48 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19QsBP-0007AE-00; Fri, 13 Jun 2003 13:17:47 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5D8M0a18351; Fri, 13 Jun 2003 04:22:00 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5D8Lsm18341 for ; Fri, 13 Jun 2003 04:21: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 EAA24893 for ; Fri, 13 Jun 2003 04:21:51 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Qjmi-0002gg-00 for simple@ietf.org; Fri, 13 Jun 2003 04:19:44 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19Qjmh-0002gd-00 for simple@ietf.org; Fri, 13 Jun 2003 04:19:43 -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 h5D8Loa08989 for ; Fri, 13 Jun 2003 11:21:50 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 13 Jun 2003 11:21:50 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 13 Jun 2003 11:21:50 +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" Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701796D99@esebe019.ntc.nokia.com> Thread-Topic: Presence filtering idea Thread-Index: AcMxTeratAA/omcIT5uktmegCOHxagAMhy4g To: Cc: , , X-OriginalArrivalTime: 13 Jun 2003 08:21:50.0486 (UTC) FILETIME=[D6C00B60:01C33184] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5D8Lsm18342 Subject: [Simple] RE: Presence filtering idea Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 13 Jun 2003 11:21:49 +0300 Content-Transfer-Encoding: 8bit > -----Original Message----- > From: ext Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Friday, June 13, 2003 4:45 AM > To: Khartabil Hisham (NMP/Helsinki) > Cc: jdrosen@dynamicsoft.com; Niemi Aki (NMP/Helsinki); simple@ietf.org > Subject: Re: Presence filtering idea > > > hisham.khartabil@nokia.com wrote: > > > > > I still don't understand how the subscriber can render the > > information given in the tuple of the NOTIFY if it receives the info > > in an XML format it does not understand, especially info it > > specifically asked for in a filter. > > > > Someone in the interim suggested that you can just show the > whole XML > > document to the user, but that's not feasable, especially for > > automata. > > Not for automata, but any recent browser will render XML, of > any schema, > in a reasonably human-readable format. Maybe you, me and others on the list can read the XML document and figure out what information it carries, but most people can't. What does an element called mean to an average user? Referring to the example I presented in an earlier email, I cannot automate sending an IM to someone when he comes online unless my terminal understands the format of the XML document it receives and consequently sends the IM. Do you want to eliminate such automated feature? I'm not happy when saying that any recent Brower can render XML in a human-readable format, I want to automate things. > > > Either there must be a standardised way of representing > something, or > > this automaty will not work. > > Can't speak for others, but I'm not suggesting that we allow > any random > presence format. I'm just not convinced that a generic XPath > mechanism > is the most intuitive way of representing this information. It is > necessary if we assume two things > > - events (including presence) can be any valid XML schema > that's agreed > upon by both sides I'm not convinced that it can done otherwise. Again, the client of the resulting XML document is not necessarily a human. The notifier must send the requested information in a format the subscriber understands. 2 reasons: - Automata - I don't want my application client to pop up my web Brower every time it doesn't understand how to fit the XML document into a pre-defined GUI. I want my application server to send info in a format that the application client was build to handle and elements in doesn't understand. > > or > > - events are more than a simple hierarchy. > > Otherwise, something much more intuitive like > > privacy > 'public' and media contains 'audio' > > would do the trick, somewhat similar to the Sieve. Along with the arguments I present above, I would like to re-state that the proposal we put forward is not just presence specific, its a generic filtering solution for any event package. > > > The alternative is that the subscriber has to inform the compositor > > the representation of tuple it accepts. We we need to go down that > > path? > > That's a false alternative; see above for something that is neither > XPath nor random event documents. Remember that every other event package has a fixed XML format with well defined representation of information, it is the tuple that is causing the problems. Examine winfo for example. > > > generic enough. I say we fix the tuple problem instead of making > > other solutions that are generic more complicated. > > I don't see that there is a tuple problem to fix. The current > capabilities description in RPIDS is unnecessarily messy, but I think > there are better solutions that explicitly extend the XML definition > rather than using the cop-out of capabilities in tags. (At > least in my > opinion, capabilities should be first-class citizens, not > second-class > ones, living lowly string existences.) Perhaps I'm arguing this in the wrong thread, but I don't think representing the same info in different ways is a good solution. IM info should be represented in the same way no matter what the tuple itself represents. Regards, Hisham > > > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Fri Jun 13 13:20:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14026 for ; Fri, 13 Jun 2003 13:20:26 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5DHJxT17336 for simple-archive@odin.ietf.org; Fri, 13 Jun 2003 13:19:59 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DHJxm17333 for ; Fri, 13 Jun 2003 13:19: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 NAA13938; Fri, 13 Jun 2003 13:19:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QsBQ-0007AH-00; Fri, 13 Jun 2003 13:17:48 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19QsBP-0007AE-00; Fri, 13 Jun 2003 13:17:47 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5D8M0a18351; Fri, 13 Jun 2003 04:22:00 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5D8Lsm18341 for ; Fri, 13 Jun 2003 04:21: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 EAA24893 for ; Fri, 13 Jun 2003 04:21:51 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Qjmi-0002gg-00 for simple@ietf.org; Fri, 13 Jun 2003 04:19:44 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19Qjmh-0002gd-00 for simple@ietf.org; Fri, 13 Jun 2003 04:19:43 -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 h5D8Loa08989 for ; Fri, 13 Jun 2003 11:21:50 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 13 Jun 2003 11:21:50 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 13 Jun 2003 11:21:50 +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" Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701796D99@esebe019.ntc.nokia.com> Thread-Topic: Presence filtering idea Thread-Index: AcMxTeratAA/omcIT5uktmegCOHxagAMhy4g To: Cc: , , X-OriginalArrivalTime: 13 Jun 2003 08:21:50.0486 (UTC) FILETIME=[D6C00B60:01C33184] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5D8Lsm18342 Subject: [Simple] RE: Presence filtering idea Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 13 Jun 2003 11:21:49 +0300 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit > -----Original Message----- > From: ext Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Friday, June 13, 2003 4:45 AM > To: Khartabil Hisham (NMP/Helsinki) > Cc: jdrosen@dynamicsoft.com; Niemi Aki (NMP/Helsinki); simple@ietf.org > Subject: Re: Presence filtering idea > > > hisham.khartabil@nokia.com wrote: > > > > > I still don't understand how the subscriber can render the > > information given in the tuple of the NOTIFY if it receives the info > > in an XML format it does not understand, especially info it > > specifically asked for in a filter. > > > > Someone in the interim suggested that you can just show the > whole XML > > document to the user, but that's not feasable, especially for > > automata. > > Not for automata, but any recent browser will render XML, of > any schema, > in a reasonably human-readable format. Maybe you, me and others on the list can read the XML document and figure out what information it carries, but most people can't. What does an element called mean to an average user? Referring to the example I presented in an earlier email, I cannot automate sending an IM to someone when he comes online unless my terminal understands the format of the XML document it receives and consequently sends the IM. Do you want to eliminate such automated feature? I'm not happy when saying that any recent Brower can render XML in a human-readable format, I want to automate things. > > > Either there must be a standardised way of representing > something, or > > this automaty will not work. > > Can't speak for others, but I'm not suggesting that we allow > any random > presence format. I'm just not convinced that a generic XPath > mechanism > is the most intuitive way of representing this information. It is > necessary if we assume two things > > - events (including presence) can be any valid XML schema > that's agreed > upon by both sides I'm not convinced that it can done otherwise. Again, the client of the resulting XML document is not necessarily a human. The notifier must send the requested information in a format the subscriber understands. 2 reasons: - Automata - I don't want my application client to pop up my web Brower every time it doesn't understand how to fit the XML document into a pre-defined GUI. I want my application server to send info in a format that the application client was build to handle and elements in doesn't understand. > > or > > - events are more than a simple hierarchy. > > Otherwise, something much more intuitive like > > privacy > 'public' and media contains 'audio' > > would do the trick, somewhat similar to the Sieve. Along with the arguments I present above, I would like to re-state that the proposal we put forward is not just presence specific, its a generic filtering solution for any event package. > > > The alternative is that the subscriber has to inform the compositor > > the representation of tuple it accepts. We we need to go down that > > path? > > That's a false alternative; see above for something that is neither > XPath nor random event documents. Remember that every other event package has a fixed XML format with well defined representation of information, it is the tuple that is causing the problems. Examine winfo for example. > > > generic enough. I say we fix the tuple problem instead of making > > other solutions that are generic more complicated. > > I don't see that there is a tuple problem to fix. The current > capabilities description in RPIDS is unnecessarily messy, but I think > there are better solutions that explicitly extend the XML definition > rather than using the cop-out of capabilities in tags. (At > least in my > opinion, capabilities should be first-class citizens, not > second-class > ones, living lowly string existences.) Perhaps I'm arguing this in the wrong thread, but I don't think representing the same info in different ways is a good solution. IM info should be represented in the same way no matter what the tuple itself represents. Regards, Hisham > > > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Jun 13 13:22:47 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 NAA14205; Fri, 13 Jun 2003 13:22:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QsEC-0007Ef-00; Fri, 13 Jun 2003 13:20:40 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19QsEB-0007EZ-00; Fri, 13 Jun 2003 13:20:39 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DCi1a06503; Fri, 13 Jun 2003 08:44:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DChgm06480 for ; Fri, 13 Jun 2003 08:43:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00526 for ; Fri, 13 Jun 2003 08:43:41 -0400 (EDT) From: eva-maria.leppanen@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Qns4-000490-00 for simple@ietf.org; Fri, 13 Jun 2003 08:41:32 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19Qns3-00048x-00 for simple@ietf.org; Fri, 13 Jun 2003 08:41:31 -0400 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h5DChd926604 for ; Fri, 13 Jun 2003 15:43:39 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 13 Jun 2003 15:43:39 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 13 Jun 2003 15:43:39 +0300 Received: from esebe009.NOE.Nokia.com ([172.21.138.41]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 13 Jun 2003 15:43:38 +0300 Received: from trebe003.NOE.Nokia.com ([172.22.232.175]) by esebe009.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 13 Jun 2003 15:43:38 +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" Subject: RE: [Simple] data manipulation protocol: XML Configuration Access Protocol (XCAP) -> comments Message-ID: <902B96A872B24840B48412649C0E8A42012FD65D@trebe003.europe.nokia.com> Thread-Topic: [Simple] data manipulation protocol: XML Configuration Access Protocol (XCAP) Thread-Index: AcMjYTrTIit+CarATc+rLGSWo93qFwOM+vfA To: , X-OriginalArrivalTime: 13 Jun 2003 12:43:38.0335 (UTC) FILETIME=[695B96F0:01C331A9] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5DChgm06481 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 13 Jun 2003 15:43:37 +0300 Content-Transfer-Encoding: 8bit Hi all, First of all: I found the new solution for data manipulation very good. Please find below some initial comments to the XCAP base protocol draft. * More exact wording could be used in the chapter 6 "Client Operations". It is difficult to know if some operation affects only a _value_ of some XML item (either XML attribute or XML element), or the whole content between the start and end tag of an XML element, or if only an XML element with its value is managed instead of also the XML attributes with their values etc. E.g., it is said in the chapter 6.5 "Creating a new element" that the Node-Selector identifies the point in the document where the new element is to be added. --> it's unclear whether all the contents between the start and end tags of the new element (incl. lower level XML elements and XML attributes) are also added and not just the new element and its value, or whether the attributes of the created element are also included or not. The same comment applies also to the replace operation (CH 6.6): it is said that the Node-Selecor identifies the element whose value is to be replaced --> is it really only the value of the XML element or also the whole content between the start and end tags? The last chapter of 6.6. says that the operation modifies the value of an element, but cannot modify the attributes of the element --> how about the XML attributes of the lower level elements? And why not to include the whole content of the element (also attributes at the same time)? I think that the examples had also some attributes added within the addition of the element (?). How about the case when an XML attribute is mandatory for the created XML element? The term "element" in the chapter 6.7 "Delete an Element" seems to mean the XML element itself, its XML attributes and its "nested" content. * Basically the same comment applies also to the chapter 7. * In the example (of the chapter 8) the PL of "Friends" is created before the first entry to the list. Would it have been possible to include also some entries in the body at the same time as the Friends list was created? (This is just a question for clarification.) To make clearer mapping between the specification part of the draft and the example it'd be good to use the same names for operations in the examples than used in the chapter 6. * An example about having the AUID specific authorisation policy could be added. BR, Eva -----Original Message----- From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: 26 May, 2003 11:27 To: simple@ietf.org Subject: [Simple] data manipulation protocol: XML Configuration Access Protocol (XCAP) Folks, I've just submitted three I-Ds to the archives, which provide a concrete protocol meeting the data manipulation requirements. This protocol is called XCAP - the XML Configuration Access Protocol. This is an evolution of the SEACAP proposal discussed in http://www.ietf.org/internet-drafts/draft-rosenberg-simple-acap-data-00.txt, which I presented at the last IETF. This new protocol is quite different than the SEACAP concept. It is no longer based on acap (though it borrows some good ideas from it). Instead, things like buddy lists and authorization policies are represented using XML documents. XCAP allows a client to manipulate those documents through HTTP GET, POST, and DELETE operations. The big idea is that the URIs used with HTTP can refer not just to a whole document, but to elements, attributes, and other components of the document itself. This is done using XPath addressing as part of the HTTP URI. Thus, to add a buddy to a list, you would do an HTTP POST to the XML element containing the list, and the body of the request is the XML document fragment describing that buddy. In addition, a SIP event package is used to allow a client to get notified of changes in a document, to deal with the multi-client synchronization problem. That package provides an indication of exactly what changed, so the client can reconstruct the document on the server. The package also uses canonical XML to provide a hash so that the client can verify that it has the same document as the server. This should help a lot on wireless. I am really happy with where this has gone. XCAP is really, really simple. No acap, not even SOAP. Just vanilla HTTP, and some Xpath. I also really like the usage of XML to specify the buddy lists and authorization policy, rather than ACAP dataset classes (the SEACAP proposal), since it nicely separates the data from the way we move it around. It will also allow us to unify the authorization policy work here with the filtering work, by allowing us to share a common XML document. Until the drafts hit the archives, you can pick them up here: http://www.jdrosen.net/papers/draft-rosenberg-simple-xcap-00.txt http://www.jdrosen.net/papers/draft-rosenberg-simple-xcap-package-00.txt http://www.jdrosen.net/papers/draft-rosenberg-simple-xcap-list-usage-00.txt The first one is the core XCAP protocol. The second is the SIP event package. The third is the XML schema for buddy lists. I havent finished the XML schema for authorization policy yet, but I wanted to put these documents in front of the group as soon as I finished them, so as to provide maximum review time before the interim. I apologize for missing the 22nd deadline for interim documents, but both work and personal issues in particular added to the delay for this work. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Scientist Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Fri Jun 13 13:23:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14266 for ; Fri, 13 Jun 2003 13:23:22 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5DHMs631755 for simple-archive@odin.ietf.org; Fri, 13 Jun 2003 13:22:54 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DHMpm30426 for ; Fri, 13 Jun 2003 13:22:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14205; Fri, 13 Jun 2003 13:22:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QsEC-0007Ef-00; Fri, 13 Jun 2003 13:20:40 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19QsEB-0007EZ-00; Fri, 13 Jun 2003 13:20:39 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DCi1a06503; Fri, 13 Jun 2003 08:44:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DChgm06480 for ; Fri, 13 Jun 2003 08:43:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00526 for ; Fri, 13 Jun 2003 08:43:41 -0400 (EDT) From: eva-maria.leppanen@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Qns4-000490-00 for simple@ietf.org; Fri, 13 Jun 2003 08:41:32 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19Qns3-00048x-00 for simple@ietf.org; Fri, 13 Jun 2003 08:41:31 -0400 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h5DChd926604 for ; Fri, 13 Jun 2003 15:43:39 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 13 Jun 2003 15:43:39 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 13 Jun 2003 15:43:39 +0300 Received: from esebe009.NOE.Nokia.com ([172.21.138.41]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 13 Jun 2003 15:43:38 +0300 Received: from trebe003.NOE.Nokia.com ([172.22.232.175]) by esebe009.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 13 Jun 2003 15:43:38 +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" Subject: RE: [Simple] data manipulation protocol: XML Configuration Access Protocol (XCAP) -> comments Message-ID: <902B96A872B24840B48412649C0E8A42012FD65D@trebe003.europe.nokia.com> Thread-Topic: [Simple] data manipulation protocol: XML Configuration Access Protocol (XCAP) Thread-Index: AcMjYTrTIit+CarATc+rLGSWo93qFwOM+vfA To: , X-OriginalArrivalTime: 13 Jun 2003 12:43:38.0335 (UTC) FILETIME=[695B96F0:01C331A9] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5DChgm06481 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 13 Jun 2003 15:43:37 +0300 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi all, First of all: I found the new solution for data manipulation very good. Please find below some initial comments to the XCAP base protocol draft. * More exact wording could be used in the chapter 6 "Client Operations". It is difficult to know if some operation affects only a _value_ of some XML item (either XML attribute or XML element), or the whole content between the start and end tag of an XML element, or if only an XML element with its value is managed instead of also the XML attributes with their values etc. E.g., it is said in the chapter 6.5 "Creating a new element" that the Node-Selector identifies the point in the document where the new element is to be added. --> it's unclear whether all the contents between the start and end tags of the new element (incl. lower level XML elements and XML attributes) are also added and not just the new element and its value, or whether the attributes of the created element are also included or not. The same comment applies also to the replace operation (CH 6.6): it is said that the Node-Selecor identifies the element whose value is to be replaced --> is it really only the value of the XML element or also the whole content between the start and end tags? The last chapter of 6.6. says that the operation modifies the value of an element, but cannot modify the attributes of the element --> how about the XML attributes of the lower level elements? And why not to include the whole content of the element (also attributes at the same time)? I think that the examples had also some attributes added within the addition of the element (?). How about the case when an XML attribute is mandatory for the created XML element? The term "element" in the chapter 6.7 "Delete an Element" seems to mean the XML element itself, its XML attributes and its "nested" content. * Basically the same comment applies also to the chapter 7. * In the example (of the chapter 8) the PL of "Friends" is created before the first entry to the list. Would it have been possible to include also some entries in the body at the same time as the Friends list was created? (This is just a question for clarification.) To make clearer mapping between the specification part of the draft and the example it'd be good to use the same names for operations in the examples than used in the chapter 6. * An example about having the AUID specific authorisation policy could be added. BR, Eva -----Original Message----- From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: 26 May, 2003 11:27 To: simple@ietf.org Subject: [Simple] data manipulation protocol: XML Configuration Access Protocol (XCAP) Folks, I've just submitted three I-Ds to the archives, which provide a concrete protocol meeting the data manipulation requirements. This protocol is called XCAP - the XML Configuration Access Protocol. This is an evolution of the SEACAP proposal discussed in http://www.ietf.org/internet-drafts/draft-rosenberg-simple-acap-data-00.txt, which I presented at the last IETF. This new protocol is quite different than the SEACAP concept. It is no longer based on acap (though it borrows some good ideas from it). Instead, things like buddy lists and authorization policies are represented using XML documents. XCAP allows a client to manipulate those documents through HTTP GET, POST, and DELETE operations. The big idea is that the URIs used with HTTP can refer not just to a whole document, but to elements, attributes, and other components of the document itself. This is done using XPath addressing as part of the HTTP URI. Thus, to add a buddy to a list, you would do an HTTP POST to the XML element containing the list, and the body of the request is the XML document fragment describing that buddy. In addition, a SIP event package is used to allow a client to get notified of changes in a document, to deal with the multi-client synchronization problem. That package provides an indication of exactly what changed, so the client can reconstruct the document on the server. The package also uses canonical XML to provide a hash so that the client can verify that it has the same document as the server. This should help a lot on wireless. I am really happy with where this has gone. XCAP is really, really simple. No acap, not even SOAP. Just vanilla HTTP, and some Xpath. I also really like the usage of XML to specify the buddy lists and authorization policy, rather than ACAP dataset classes (the SEACAP proposal), since it nicely separates the data from the way we move it around. It will also allow us to unify the authorization policy work here with the filtering work, by allowing us to share a common XML document. Until the drafts hit the archives, you can pick them up here: http://www.jdrosen.net/papers/draft-rosenberg-simple-xcap-00.txt http://www.jdrosen.net/papers/draft-rosenberg-simple-xcap-package-00.txt http://www.jdrosen.net/papers/draft-rosenberg-simple-xcap-list-usage-00.txt The first one is the core XCAP protocol. The second is the SIP event package. The third is the XML schema for buddy lists. I havent finished the XML schema for authorization policy yet, but I wanted to put these documents in front of the group as soon as I finished them, so as to provide maximum review time before the interim. I apologize for missing the 22nd deadline for interim documents, but both work and personal issues in particular added to the delay for this work. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Scientist Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Jun 13 13:25:06 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 NAA14351; Fri, 13 Jun 2003 13:25:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QsGR-0007H5-00; Fri, 13 Jun 2003 13:22:59 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19QsGQ-0007H2-00; Fri, 13 Jun 2003 13:22:58 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DAp1a30099; Fri, 13 Jun 2003 06:51:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DAoqm30085 for ; Fri, 13 Jun 2003 06:50:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27923 for ; Fri, 13 Jun 2003 06:50:48 -0400 (EDT) From: Markus.Isomaki@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Qm6r-0003ZM-00 for simple@ietf.org; Fri, 13 Jun 2003 06:48:41 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19Qm6q-0003ZJ-00 for simple@ietf.org; Fri, 13 Jun 2003 06:48:40 -0400 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h5DAol906269 for ; Fri, 13 Jun 2003 13:50:47 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 13 Jun 2003 13:50:46 +0300 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 13 Jun 2003 13:50:45 +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" Message-ID: Thread-Topic: Comments on draft-ietf-simple-data-req-02.txt Thread-Index: AcMLWgybkc+7eTOkQvqecZ+lcN5n0Al2SRsAABmNwxA= To: X-OriginalArrivalTime: 13 Jun 2003 10:50:45.0425 (UTC) FILETIME=[A4638A10:01C33199] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5DAoqm30086 Subject: [Simple] FW: Comments on draft-ietf-simple-data-req-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: Fri, 13 Jun 2003 13:50:45 +0300 Content-Transfer-Encoding: 8bit For some reason this did not appear on SIMPLE list, so I'm resending: > -----Original Message----- > From: Isomaki Markus (NRC/Helsinki) > Sent: 13 June, 2003 02:27 > To: 'ext Ben Campbell' > Cc: Simple WG > Subject: RE: Comments on draft-ietf-simple-data-req-02.txt > > > Hi, > > I'll be working on a new version of the data manipulation > requirements draft. During the WG last call there were > basically only two comments to the -02 version of the draft, > one from Ben Campbell and the other from Krisztian Kiss. I'll > answer both separately to try to establish concensus on the > points raised in them. (To my knowledge 3GPP CN1 WG is also > reviewing their specific reqs to data manipulation, so if > there is something specific, please send that to the list too.) > > The main scoping issue is whether to inlude the default > presence document publishing/upload reqs in this document, or > should they be separated. My assumption would be to have a > separate reqs draft for them, but I would be happy to > incorporate them in this doc as well, if people prefer that. > > Comments to Ben inline: > > > -----Original Message----- > > From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] > > Sent: 25 April, 2003 21:39 > > To: Isomaki Markus (NRC/Helsinki) > > Cc: Simple WG > > Subject: Comments on draft-ietf-simple-data-req-02.txt > > > > > > General: Although there are a couple of extensibility > > requirements, I am > > a litte concerned that this document is too focused on > > current concrete > > data requirements, and not enough focused on abstracting > > these data in a > > more extensible way. I cannot imagine that we can predict the > > data needs > > of every deployed system in advance, but I would expect the data > > _mechanism_ to be extensible to types of data we have not > yet thought > > about. > > > > Personally I completely agree with you. However, I think the > scoping of this initial SIMPLE data manipulation work was > discussed a couple of times last year, and the conclusion was > that for now we should focus on requirements for presence > list and presence authorization policy management, as stated > in the charter. So, the scope of this draft is that, not data > manipulation in general. Having a protocol such as XCAP for > doing these operations does allow flexibility, and I think > separate requirements drafts for new XCAP application usages > would be fine, such as for default presence state publishing. > > > For example, there was considerable discussion about > default presence > > documents on a different thread, where several people suggested that > > configuration of these defaults should be a data manipulation > > mechanism > > requirement. But that is not listed in this doc, nor do I see any > > extensibility requirement that leads me to expect that the mechanism > > must be extensible to handle this class of data. (There is a > > requirement > > about choosing the presence doc a user sees in the authorization > > section, but it is not clear to me if that was intended to meet this > > requirement.) > > > > These are good points and I belive the concensus definitely > is that default presence document uploading will be done with > the same data manipulation solution (in practice XCAP). This > is not in the scope of this requirements draft, however. I > think we need separate reqs for that (that can be very short, > and should be done quickly), and for other data manipulation > usages in the future too. > > > I think this document could use some more explicit scoping language. > > There are some requirements that are to be applied to events > > other than > > presence, and others that appear to be presence specific. > > This should be > > stated explicitly. > > > > OK, I think that the scope of this draft should be presence, > even though it is easy to see that the same reqs could apply > to SIP events in general. > > > PC-1 - The wording can be interpreted to imply a single presentity > > collection. I think it must be possible to create multiple > collections > > with distinct URIs. Later requirements seem to support this, but it > > should be explicit. > > > > Yes, I think a user should be able to have multiple > presentity collections. > > > PC-2 and 3: These seems like mechanism rather than > requirement. Why is > > necessary for the protocol to allow both approaches? > > > > In some cases the (human) user might want to influence what > the URI should be, in other cases the client would like to > leave this completely up to the server. I don't see such harm > in having both ways possible. > > > PC-5: There is nothing inherent in a URI that tells you if it > > represents > > a list or a single presentity. The only way to implement > this would be > > to actually attempt a subscription, which I doubt is your > > intent. Do you > > mean this as a way to control where the supported header > for lists is > > used? If this is a real requirement, it may force new > requirements on > > the list draft. > > > > I think you are right. URI for a list is exactly similar to > URI for a single presentity. So in all cases clearly this req > can't be met. Unless someone has a good reason for keeping > this req as it is, I'll reword it. I think a more relevant > req is that a presence list can be hierarchically structured, > as in XCAP presence list usage proposal. > > > PC-10: May need to break this up into read and write > access, etc. You > > may want to have users who can read the collection contents, but not > > change it. > > > > Agreed. I'll add that. > > > PC-12: I don't believe cached lists necessarily imply a > > requirement for > > change notification. The real thing that forces this > > requirement is the > > ability for the list to be changed by some other actor than > the client > > while the client is running. If this is the intent, then we need a > > requirement for it. > > > > Agreed. Change notification is needed since multiple clients > may be manipulating the same data, while they are on-line. > I'll reword the reqs. > > > > > PC-15: Unless there is an assumption that the protocol cannot > > offer any > > feature not listed as a requirement, then MAY requirements are not > > useful in a requirements document. If this is important enough to > > mention, it probably should be a SHOULD. > > > > OK. > > > PC-21. I think this requirement needs more justification. > In fact, we > > should probably back up and look for root requirements > behind it. What > > is it you want to accomplish with a proxy? For example, if it is for > > firewall traversal, then the requirements should be about firewall > > traversal--and proxies might be a mechanism to accomplish that. > > > > True. Firewall traversal is probably one thing that would be > beneficial, also I think something like compression and > security association sharing (one client using multiple > servers) on the first hop would be derirable features, that > proxy allows, so at least for me it would be OK to enumerate > the real needs separately. > > > PC-22: (nit) this seems out of place--it should be grouped with the > > other manipulation requirements. > > > > OK, will be moved. > > > PC-23: I think we should separate intermittent and low > bandwidth into > > two requirements. Also, it might be useful to define what sort of > > bandwidth is considered low--newer wireless devices are every bit as > > fast as an average dial up connection. > > > > Right. Even though I'm very much involved with wireless > devices I'm not sure if this kind of requirement is really > quantifiable. It might be best to speak about ability to > compress and aiming at efficient encoding. > > > PC-24: This looks suspiciously like one of those "you can't make us > > implement multiple protocols in a client" requirements, which are > > generally looked upon with skepticism in the IETF. Do we want > > this to be > > a general directory interface? Also, this requirement would seem to > > imply we need to be able to create entries to which we do not > > intend to > > subscribe. > > > > I think this could be a SHOULD-level requirement. I think it > makes sense that a user can share lists among multiple > applications, so that the "master-copy" is in some kind of > phonebook, but it is not completely clear to me how much this > is just implementation issue. In practice I think this means > that it MUST be possible to have links to data elsewhere > within the presence list structure. Would that sound more reasonable? > > > PC-25: (nit) out of place. (see comment on 22) > > OK. > > > > > 5.1: I think we need a requirement allowing for wildcards in > > blocked and > > allow lists. For example, allow everyone in my domain... > > > > True. However, I think we could limit the support to just > that: allow everyone in some domain, and not make this > completely generic, for simplicity, and just to support the real need. > > > g-5 (and previous similar) I really think this should be a > > SHOULD, not a > > must. That is, I would really hate to reject some existing > > protocol for > > the sole reason of it using a different authentication scheme > > than SIP. > > > > I think you mean G-6. Agree, can be SHOULD. > > > 7: To Do items need to be closed before progressing the draft. > > > > OK. > > Markus > > > > > On Thu, 2003-04-17 at 09:27, Robert Sparks wrote: > > > This is a SIMPLE working group Last Call for comments on > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-simple-data-req-02.txt > > > > > > Please review the draft and provide comments by May 5 > > > > > > RjS. > > > > > > _______________________________________________ > > > Simple mailing list > > > Simple@ietf.org > > > https://www1.ietf.org/mailman/listinfo/simple > > > > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Fri Jun 13 13:25:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14402 for ; Fri, 13 Jun 2003 13:25:37 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5DHPA609946 for simple-archive@odin.ietf.org; Fri, 13 Jun 2003 13:25:10 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DHPAm09943 for ; Fri, 13 Jun 2003 13:25:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14351; Fri, 13 Jun 2003 13:25:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QsGR-0007H5-00; Fri, 13 Jun 2003 13:22:59 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19QsGQ-0007H2-00; Fri, 13 Jun 2003 13:22:58 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DAp1a30099; Fri, 13 Jun 2003 06:51:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DAoqm30085 for ; Fri, 13 Jun 2003 06:50:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27923 for ; Fri, 13 Jun 2003 06:50:48 -0400 (EDT) From: Markus.Isomaki@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Qm6r-0003ZM-00 for simple@ietf.org; Fri, 13 Jun 2003 06:48:41 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19Qm6q-0003ZJ-00 for simple@ietf.org; Fri, 13 Jun 2003 06:48:40 -0400 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h5DAol906269 for ; Fri, 13 Jun 2003 13:50:47 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 13 Jun 2003 13:50:46 +0300 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 13 Jun 2003 13:50:45 +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" Message-ID: Thread-Topic: Comments on draft-ietf-simple-data-req-02.txt Thread-Index: AcMLWgybkc+7eTOkQvqecZ+lcN5n0Al2SRsAABmNwxA= To: X-OriginalArrivalTime: 13 Jun 2003 10:50:45.0425 (UTC) FILETIME=[A4638A10:01C33199] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5DAoqm30086 Subject: [Simple] FW: Comments on draft-ietf-simple-data-req-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: Fri, 13 Jun 2003 13:50:45 +0300 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit For some reason this did not appear on SIMPLE list, so I'm resending: > -----Original Message----- > From: Isomaki Markus (NRC/Helsinki) > Sent: 13 June, 2003 02:27 > To: 'ext Ben Campbell' > Cc: Simple WG > Subject: RE: Comments on draft-ietf-simple-data-req-02.txt > > > Hi, > > I'll be working on a new version of the data manipulation > requirements draft. During the WG last call there were > basically only two comments to the -02 version of the draft, > one from Ben Campbell and the other from Krisztian Kiss. I'll > answer both separately to try to establish concensus on the > points raised in them. (To my knowledge 3GPP CN1 WG is also > reviewing their specific reqs to data manipulation, so if > there is something specific, please send that to the list too.) > > The main scoping issue is whether to inlude the default > presence document publishing/upload reqs in this document, or > should they be separated. My assumption would be to have a > separate reqs draft for them, but I would be happy to > incorporate them in this doc as well, if people prefer that. > > Comments to Ben inline: > > > -----Original Message----- > > From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] > > Sent: 25 April, 2003 21:39 > > To: Isomaki Markus (NRC/Helsinki) > > Cc: Simple WG > > Subject: Comments on draft-ietf-simple-data-req-02.txt > > > > > > General: Although there are a couple of extensibility > > requirements, I am > > a litte concerned that this document is too focused on > > current concrete > > data requirements, and not enough focused on abstracting > > these data in a > > more extensible way. I cannot imagine that we can predict the > > data needs > > of every deployed system in advance, but I would expect the data > > _mechanism_ to be extensible to types of data we have not > yet thought > > about. > > > > Personally I completely agree with you. However, I think the > scoping of this initial SIMPLE data manipulation work was > discussed a couple of times last year, and the conclusion was > that for now we should focus on requirements for presence > list and presence authorization policy management, as stated > in the charter. So, the scope of this draft is that, not data > manipulation in general. Having a protocol such as XCAP for > doing these operations does allow flexibility, and I think > separate requirements drafts for new XCAP application usages > would be fine, such as for default presence state publishing. > > > For example, there was considerable discussion about > default presence > > documents on a different thread, where several people suggested that > > configuration of these defaults should be a data manipulation > > mechanism > > requirement. But that is not listed in this doc, nor do I see any > > extensibility requirement that leads me to expect that the mechanism > > must be extensible to handle this class of data. (There is a > > requirement > > about choosing the presence doc a user sees in the authorization > > section, but it is not clear to me if that was intended to meet this > > requirement.) > > > > These are good points and I belive the concensus definitely > is that default presence document uploading will be done with > the same data manipulation solution (in practice XCAP). This > is not in the scope of this requirements draft, however. I > think we need separate reqs for that (that can be very short, > and should be done quickly), and for other data manipulation > usages in the future too. > > > I think this document could use some more explicit scoping language. > > There are some requirements that are to be applied to events > > other than > > presence, and others that appear to be presence specific. > > This should be > > stated explicitly. > > > > OK, I think that the scope of this draft should be presence, > even though it is easy to see that the same reqs could apply > to SIP events in general. > > > PC-1 - The wording can be interpreted to imply a single presentity > > collection. I think it must be possible to create multiple > collections > > with distinct URIs. Later requirements seem to support this, but it > > should be explicit. > > > > Yes, I think a user should be able to have multiple > presentity collections. > > > PC-2 and 3: These seems like mechanism rather than > requirement. Why is > > necessary for the protocol to allow both approaches? > > > > In some cases the (human) user might want to influence what > the URI should be, in other cases the client would like to > leave this completely up to the server. I don't see such harm > in having both ways possible. > > > PC-5: There is nothing inherent in a URI that tells you if it > > represents > > a list or a single presentity. The only way to implement > this would be > > to actually attempt a subscription, which I doubt is your > > intent. Do you > > mean this as a way to control where the supported header > for lists is > > used? If this is a real requirement, it may force new > requirements on > > the list draft. > > > > I think you are right. URI for a list is exactly similar to > URI for a single presentity. So in all cases clearly this req > can't be met. Unless someone has a good reason for keeping > this req as it is, I'll reword it. I think a more relevant > req is that a presence list can be hierarchically structured, > as in XCAP presence list usage proposal. > > > PC-10: May need to break this up into read and write > access, etc. You > > may want to have users who can read the collection contents, but not > > change it. > > > > Agreed. I'll add that. > > > PC-12: I don't believe cached lists necessarily imply a > > requirement for > > change notification. The real thing that forces this > > requirement is the > > ability for the list to be changed by some other actor than > the client > > while the client is running. If this is the intent, then we need a > > requirement for it. > > > > Agreed. Change notification is needed since multiple clients > may be manipulating the same data, while they are on-line. > I'll reword the reqs. > > > > > PC-15: Unless there is an assumption that the protocol cannot > > offer any > > feature not listed as a requirement, then MAY requirements are not > > useful in a requirements document. If this is important enough to > > mention, it probably should be a SHOULD. > > > > OK. > > > PC-21. I think this requirement needs more justification. > In fact, we > > should probably back up and look for root requirements > behind it. What > > is it you want to accomplish with a proxy? For example, if it is for > > firewall traversal, then the requirements should be about firewall > > traversal--and proxies might be a mechanism to accomplish that. > > > > True. Firewall traversal is probably one thing that would be > beneficial, also I think something like compression and > security association sharing (one client using multiple > servers) on the first hop would be derirable features, that > proxy allows, so at least for me it would be OK to enumerate > the real needs separately. > > > PC-22: (nit) this seems out of place--it should be grouped with the > > other manipulation requirements. > > > > OK, will be moved. > > > PC-23: I think we should separate intermittent and low > bandwidth into > > two requirements. Also, it might be useful to define what sort of > > bandwidth is considered low--newer wireless devices are every bit as > > fast as an average dial up connection. > > > > Right. Even though I'm very much involved with wireless > devices I'm not sure if this kind of requirement is really > quantifiable. It might be best to speak about ability to > compress and aiming at efficient encoding. > > > PC-24: This looks suspiciously like one of those "you can't make us > > implement multiple protocols in a client" requirements, which are > > generally looked upon with skepticism in the IETF. Do we want > > this to be > > a general directory interface? Also, this requirement would seem to > > imply we need to be able to create entries to which we do not > > intend to > > subscribe. > > > > I think this could be a SHOULD-level requirement. I think it > makes sense that a user can share lists among multiple > applications, so that the "master-copy" is in some kind of > phonebook, but it is not completely clear to me how much this > is just implementation issue. In practice I think this means > that it MUST be possible to have links to data elsewhere > within the presence list structure. Would that sound more reasonable? > > > PC-25: (nit) out of place. (see comment on 22) > > OK. > > > > > 5.1: I think we need a requirement allowing for wildcards in > > blocked and > > allow lists. For example, allow everyone in my domain... > > > > True. However, I think we could limit the support to just > that: allow everyone in some domain, and not make this > completely generic, for simplicity, and just to support the real need. > > > g-5 (and previous similar) I really think this should be a > > SHOULD, not a > > must. That is, I would really hate to reject some existing > > protocol for > > the sole reason of it using a different authentication scheme > > than SIP. > > > > I think you mean G-6. Agree, can be SHOULD. > > > 7: To Do items need to be closed before progressing the draft. > > > > OK. > > Markus > > > > > On Thu, 2003-04-17 at 09:27, Robert Sparks wrote: > > > This is a SIMPLE working group Last Call for comments on > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-simple-data-req-02.txt > > > > > > Please review the draft and provide comments by May 5 > > > > > > RjS. > > > > > > _______________________________________________ > > > Simple mailing list > > > Simple@ietf.org > > > https://www1.ietf.org/mailman/listinfo/simple > > > > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Jun 13 13:25:40 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 NAA14441; Fri, 13 Jun 2003 13:25:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QsGy-0007J5-00; Fri, 13 Jun 2003 13:23:32 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19QsGy-0007J2-00; Fri, 13 Jun 2003 13:23:32 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DAq1a30151; Fri, 13 Jun 2003 06:52:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DAp8m30111 for ; Fri, 13 Jun 2003 06:51: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 GAA27926 for ; Fri, 13 Jun 2003 06:51:04 -0400 (EDT) From: Markus.Isomaki@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Qm77-0003ZU-00 for simple@ietf.org; Fri, 13 Jun 2003 06:48:57 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19Qm76-0003ZR-00 for simple@ietf.org; Fri, 13 Jun 2003 06:48:56 -0400 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h5DAp3906510 for ; Fri, 13 Jun 2003 13:51:03 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 13 Jun 2003 13:51:03 +0300 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 13 Jun 2003 13:51:02 +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" Subject: FW: [Simple] Comments on draft-ietf-simple-data-req-02.txt Message-ID: Thread-Topic: [Simple] Comments on draft-ietf-simple-data-req-02.txt Thread-Index: AcMLWjgklYRv+iOORKK1rCGOICaepAFZ+4MACB3/nxAAF+CO0A== To: X-OriginalArrivalTime: 13 Jun 2003 10:51:02.0953 (UTC) FILETIME=[AED61990:01C33199] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5DAp8m30112 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 13 Jun 2003 13:51:02 +0300 Content-Transfer-Encoding: 8bit For some reason this did not appear on SIMPLE list, so I'm resending: > -----Original Message----- > From: Isomaki Markus (NRC/Helsinki) > Sent: 13 June, 2003 02:56 > To: Kiss Krisztian (NRC/Tampere); 'ext Ben Campbell' > Cc: 'Simple WG' > Subject: RE: [Simple] Comments on draft-ietf-simple-data-req-02.txt > > > Hi Krisztian, > > Thanks for your comments, see my responses inline. > > I think the main points about these comments are these: > - Do we need the notification policies at all? > - What information should it be possible to use for > authorizing presence document, and do we operate on > tuple-level or with higher granularity when deciding what to give. > > Markus > > > -----Original Message----- > > From: Kiss Krisztian (NRC/Tampere) > > Sent: 02 May, 2003 20:51 > > To: 'ext Ben Campbell'; Isomaki Markus (NRC/Helsinki) > > Cc: 'Simple WG' > > Subject: RE: [Simple] Comments on draft-ietf-simple-data-req-02.txt > > > > > > Jonathan et al, > > > > Please find below some comments on draft-ietf-simple-data-req-02: > > > > - REQ PC-9 defines that a user could query for a "set of > > URIs" of a collection. I believe this kind of query should > > return all information available for the presentity > > collection in addition to the set of URIs. Additionally, the > > REQ should also define those users who are authorized to make > > this query. According to PC-10 and PC-11, there are already > > two kind of authorized lists defined, one list is for the > > users who are allowed to subscribe to the list, another list > > is for the users who are allowed to manipulate the attributes > > of the list. Probably the group of the users allowed to query > > equals to the group who are allowed to subscribe. One > > re-wording of the sentence could be as follows: "It MUST be > > possible for the authorized users allowed to subscribe to the > > list also to query for information of the particular > > presentity collection by providing the URI for the presentity > > collection." > > > > At least as a default authorization policy this would make > sense, so if there are no objections, we could incorporate > your proposal. > > > -REQ PC-24: I am wondering about the justification for this > > REQ. It sounds rather an implementation issue instead of a > > requirement that would have effects on the final solution. It > > might cause unnecessary and additional complexity for the > > solution. To tell the truth, I am confused why the network > > resident address book has some special role here, if this is > > the case, we could also have REQs for other type of > > "collection kind of resources", e.g. presence access list, > > etc. Anyway, it'd good to have a more generic REQ instead, > > with a strength SHOULD instead of MUST. > > > > Ben Campbell had similar comment. I think it would be useful > to allow sharing of lists (or other data) among applications. > I think SHOULD-level req is OK, with explanation that this > kind of linking is the intended use here. > > > -REQ AP-7: I believe there is no need for this requirement. > > In the requirement phase, the best would be to keep distinct > > roles for the different lists, the buddy list is for the > > presentity's own subscription purposes, the allowed and > > blocked lists are for authorization purposes. > > > > I tend to agree. This req is generated by Jonathan. I believe > he derived it from some existing IM/presence systems, which > have this kind of feature. Jonathan (&others), do you see > this as a necessary feature? > > On the other hand, if we allow links to be included, then I > suppose the allowed-list would be just a link to presence > list. Would this be an OK approach? > > > -REQ AP-8: would be good to have more exact wording in the > > last sentence of the requirement. I guess the assumption here > > is that the meaning behind the "add, remove, modify, read, > > clear and create and delete" operations must be clear for the > > reader based on the PC requirements, however here we are > > talking about multiple lists, therefore it is unclear whether > > the remove, delete and clear operations are meant for the > > individual entries of a list, the list itself, or all the > > lists handled by the authorization policy. > > > > I think they are for individual entries. I'll try to make > this more clear. > > > -REQ N1-5: all the notification requirements listed in > > chapter 5.2 are somehow "less important". If we can set > > "when" type of requirements (criteria when notifications are > > delivered to watchers) also to authorization, additionally to > > filtering, throttling and local server policies, we may end > > up having too complex rules about generating notifications. > > > > Yes, I think there hasn't been enough discussion on the > necessity of these requirements. Personally I don't see them > necessary. Jonathan? In any case I'll start a separate thread > about this to see if anyone has any opinion. > > > -REQ C1-3: These requirements seem too specific and rather > > unclear. The first issue is why only the contact address and > > status are chosen as presence attributes that the user can > > set by authorization. Maybe a generic requirement would be > > enough saying that the authorized content could be specified > > by using any presence attribute. The second issue, which is > > rather important, if these requirements mean that after > > authorization the whole tuple including the attribute is > > omitted, or only the chosen attribute from the tuple. More > > clearly, is the aim to allow for the user to define which > > presence attributes to authorize within a tuple or rather to > > authorize tuples (i.e. what is the atomic element handled by > > the content policy)? > > > > Well, nowadays it is hard to say even what a tuple is ;) I > think this will need more list discussion as well. > > > -REQ C-4: I guess it would be better to place this before > > C1-3. Assuming that the previous requirements were meant for > > selecting attributes within a tuple, this REQ seem to allow > > to select a whole tuple. Does this requirement allow any > > presence attribute (e.g. one RPIDS extensions, tuple-id) to > > be used as a criteria for selecting the tuples? > > > > To be handled within the same discussion. > > > -REQ C-6: this REQ sounds like one covering the delivery of > > default presence documents. I would prefer to mention here > > explicitly that DM is used for publication of the default > > presence document. Also, a strength of MUST would be better > > instead of the SHOULD. A rewording could be: It MUST be > > possible for the user to publish a presence document with > > default presence attributes. > > > > I think it would be OK to take away this requirement from > this draft and collect the requirements for default presence > doc publishing separately. Unless someone thinks this req is > important for some other purpose. > > > Additional requirements: > > > > -REQ-PC-x: > > A requirement about storing an XML document including > > filtering information by using the data manipulation > > mechanism. This could be useful for presentity collections > > where different URIs of the collection could have either > > common or individual filter definitions pre-defined, and the > > watcher(s) would not need to include any filter information > > within the subscription. > > > > OK, I suppose this could be an addition to the presence list > requirements. Something that could be optionally supported by > the server. > > > -REQ AP-x: > > A requirement might be justified for the expected behavior of > > the acceptance policy when a watcher is part of several > > lists, e.g. multiple allowed lists. The policy could define, > > for example, an evaluation order for the lists, and the > > policy would stop evaluating the lists when the particular > > watcher is found. An alternative could be that the watcher > > cannot belong to several lists, however this does not sound > > feasible, especially if it is possible to use wildcards for > > defining URIs. > > Well, there are two models: either separate lists for > different acceptance rule (allow, block etc.) or a single > list with different rule for each entry. Maybe I need to > reword the reqs so that this is not yet determined. What we > want to achieve is to accept some users and block some > others, and have some "pending". I don't think we need to > actually even say how these rules are organized in this > requirements draft. > > > > > -REQ C-x: > > A requirement, when the presentity authorizes different > > values of the otherwise same "data segment" to different > > watchers. One motivation here is the ability to give > > different level of details of information (e.g. w.r.t. > > location) to different watchers. Perhaps this is hidden > > behind some of the requirements, but it would be rather good > > to explicitly state it. > > I think this is a valid case, so I'll try to include it > somehow. I don't think this will actually add anything new > for the solution, but probably it has some link to publishing as well. > > > REQ C-5 covers this partly, however it makes a hint that new > > values of attributes are to be modified from existing values. > > By taking the geographical location information example, the > > difference between the information to be delivered to > > different watchers is only in the level of details. > > Therefore, there could be another approach that tuples would > > be assigned for the different level of details and > > authorization would be done based on some kind of "level of > > detail" attribute. > > > > OK, do you have some text to propose? > > > -REQ ?-x: > > Relation between the content requirements and the acceptance > > policy requirements are somehow undefined. When the > > acceptance policy results in accepting a watcher, then which > > content/notification requirements shall be applied, how and > > where this relation would be defined. > > > > OK, I'll try to clarify that. I guess acceptance is the first > steps, and subsequent rules would cover the content to be given. > > > Thanks, > > Krisztian > > > > Markus > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Fri Jun 13 13:26:11 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14520 for ; Fri, 13 Jun 2003 13:26:10 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5DHPir12017 for simple-archive@odin.ietf.org; Fri, 13 Jun 2003 13:25:44 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DHPim12012 for ; Fri, 13 Jun 2003 13:25:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14441; Fri, 13 Jun 2003 13:25:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QsGy-0007J5-00; Fri, 13 Jun 2003 13:23:32 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19QsGy-0007J2-00; Fri, 13 Jun 2003 13:23:32 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DAq1a30151; Fri, 13 Jun 2003 06:52:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DAp8m30111 for ; Fri, 13 Jun 2003 06:51: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 GAA27926 for ; Fri, 13 Jun 2003 06:51:04 -0400 (EDT) From: Markus.Isomaki@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Qm77-0003ZU-00 for simple@ietf.org; Fri, 13 Jun 2003 06:48:57 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19Qm76-0003ZR-00 for simple@ietf.org; Fri, 13 Jun 2003 06:48:56 -0400 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h5DAp3906510 for ; Fri, 13 Jun 2003 13:51:03 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 13 Jun 2003 13:51:03 +0300 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 13 Jun 2003 13:51:02 +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" Subject: FW: [Simple] Comments on draft-ietf-simple-data-req-02.txt Message-ID: Thread-Topic: [Simple] Comments on draft-ietf-simple-data-req-02.txt Thread-Index: AcMLWjgklYRv+iOORKK1rCGOICaepAFZ+4MACB3/nxAAF+CO0A== To: X-OriginalArrivalTime: 13 Jun 2003 10:51:02.0953 (UTC) FILETIME=[AED61990:01C33199] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5DAp8m30112 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 13 Jun 2003 13:51:02 +0300 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit For some reason this did not appear on SIMPLE list, so I'm resending: > -----Original Message----- > From: Isomaki Markus (NRC/Helsinki) > Sent: 13 June, 2003 02:56 > To: Kiss Krisztian (NRC/Tampere); 'ext Ben Campbell' > Cc: 'Simple WG' > Subject: RE: [Simple] Comments on draft-ietf-simple-data-req-02.txt > > > Hi Krisztian, > > Thanks for your comments, see my responses inline. > > I think the main points about these comments are these: > - Do we need the notification policies at all? > - What information should it be possible to use for > authorizing presence document, and do we operate on > tuple-level or with higher granularity when deciding what to give. > > Markus > > > -----Original Message----- > > From: Kiss Krisztian (NRC/Tampere) > > Sent: 02 May, 2003 20:51 > > To: 'ext Ben Campbell'; Isomaki Markus (NRC/Helsinki) > > Cc: 'Simple WG' > > Subject: RE: [Simple] Comments on draft-ietf-simple-data-req-02.txt > > > > > > Jonathan et al, > > > > Please find below some comments on draft-ietf-simple-data-req-02: > > > > - REQ PC-9 defines that a user could query for a "set of > > URIs" of a collection. I believe this kind of query should > > return all information available for the presentity > > collection in addition to the set of URIs. Additionally, the > > REQ should also define those users who are authorized to make > > this query. According to PC-10 and PC-11, there are already > > two kind of authorized lists defined, one list is for the > > users who are allowed to subscribe to the list, another list > > is for the users who are allowed to manipulate the attributes > > of the list. Probably the group of the users allowed to query > > equals to the group who are allowed to subscribe. One > > re-wording of the sentence could be as follows: "It MUST be > > possible for the authorized users allowed to subscribe to the > > list also to query for information of the particular > > presentity collection by providing the URI for the presentity > > collection." > > > > At least as a default authorization policy this would make > sense, so if there are no objections, we could incorporate > your proposal. > > > -REQ PC-24: I am wondering about the justification for this > > REQ. It sounds rather an implementation issue instead of a > > requirement that would have effects on the final solution. It > > might cause unnecessary and additional complexity for the > > solution. To tell the truth, I am confused why the network > > resident address book has some special role here, if this is > > the case, we could also have REQs for other type of > > "collection kind of resources", e.g. presence access list, > > etc. Anyway, it'd good to have a more generic REQ instead, > > with a strength SHOULD instead of MUST. > > > > Ben Campbell had similar comment. I think it would be useful > to allow sharing of lists (or other data) among applications. > I think SHOULD-level req is OK, with explanation that this > kind of linking is the intended use here. > > > -REQ AP-7: I believe there is no need for this requirement. > > In the requirement phase, the best would be to keep distinct > > roles for the different lists, the buddy list is for the > > presentity's own subscription purposes, the allowed and > > blocked lists are for authorization purposes. > > > > I tend to agree. This req is generated by Jonathan. I believe > he derived it from some existing IM/presence systems, which > have this kind of feature. Jonathan (&others), do you see > this as a necessary feature? > > On the other hand, if we allow links to be included, then I > suppose the allowed-list would be just a link to presence > list. Would this be an OK approach? > > > -REQ AP-8: would be good to have more exact wording in the > > last sentence of the requirement. I guess the assumption here > > is that the meaning behind the "add, remove, modify, read, > > clear and create and delete" operations must be clear for the > > reader based on the PC requirements, however here we are > > talking about multiple lists, therefore it is unclear whether > > the remove, delete and clear operations are meant for the > > individual entries of a list, the list itself, or all the > > lists handled by the authorization policy. > > > > I think they are for individual entries. I'll try to make > this more clear. > > > -REQ N1-5: all the notification requirements listed in > > chapter 5.2 are somehow "less important". If we can set > > "when" type of requirements (criteria when notifications are > > delivered to watchers) also to authorization, additionally to > > filtering, throttling and local server policies, we may end > > up having too complex rules about generating notifications. > > > > Yes, I think there hasn't been enough discussion on the > necessity of these requirements. Personally I don't see them > necessary. Jonathan? In any case I'll start a separate thread > about this to see if anyone has any opinion. > > > -REQ C1-3: These requirements seem too specific and rather > > unclear. The first issue is why only the contact address and > > status are chosen as presence attributes that the user can > > set by authorization. Maybe a generic requirement would be > > enough saying that the authorized content could be specified > > by using any presence attribute. The second issue, which is > > rather important, if these requirements mean that after > > authorization the whole tuple including the attribute is > > omitted, or only the chosen attribute from the tuple. More > > clearly, is the aim to allow for the user to define which > > presence attributes to authorize within a tuple or rather to > > authorize tuples (i.e. what is the atomic element handled by > > the content policy)? > > > > Well, nowadays it is hard to say even what a tuple is ;) I > think this will need more list discussion as well. > > > -REQ C-4: I guess it would be better to place this before > > C1-3. Assuming that the previous requirements were meant for > > selecting attributes within a tuple, this REQ seem to allow > > to select a whole tuple. Does this requirement allow any > > presence attribute (e.g. one RPIDS extensions, tuple-id) to > > be used as a criteria for selecting the tuples? > > > > To be handled within the same discussion. > > > -REQ C-6: this REQ sounds like one covering the delivery of > > default presence documents. I would prefer to mention here > > explicitly that DM is used for publication of the default > > presence document. Also, a strength of MUST would be better > > instead of the SHOULD. A rewording could be: It MUST be > > possible for the user to publish a presence document with > > default presence attributes. > > > > I think it would be OK to take away this requirement from > this draft and collect the requirements for default presence > doc publishing separately. Unless someone thinks this req is > important for some other purpose. > > > Additional requirements: > > > > -REQ-PC-x: > > A requirement about storing an XML document including > > filtering information by using the data manipulation > > mechanism. This could be useful for presentity collections > > where different URIs of the collection could have either > > common or individual filter definitions pre-defined, and the > > watcher(s) would not need to include any filter information > > within the subscription. > > > > OK, I suppose this could be an addition to the presence list > requirements. Something that could be optionally supported by > the server. > > > -REQ AP-x: > > A requirement might be justified for the expected behavior of > > the acceptance policy when a watcher is part of several > > lists, e.g. multiple allowed lists. The policy could define, > > for example, an evaluation order for the lists, and the > > policy would stop evaluating the lists when the particular > > watcher is found. An alternative could be that the watcher > > cannot belong to several lists, however this does not sound > > feasible, especially if it is possible to use wildcards for > > defining URIs. > > Well, there are two models: either separate lists for > different acceptance rule (allow, block etc.) or a single > list with different rule for each entry. Maybe I need to > reword the reqs so that this is not yet determined. What we > want to achieve is to accept some users and block some > others, and have some "pending". I don't think we need to > actually even say how these rules are organized in this > requirements draft. > > > > > -REQ C-x: > > A requirement, when the presentity authorizes different > > values of the otherwise same "data segment" to different > > watchers. One motivation here is the ability to give > > different level of details of information (e.g. w.r.t. > > location) to different watchers. Perhaps this is hidden > > behind some of the requirements, but it would be rather good > > to explicitly state it. > > I think this is a valid case, so I'll try to include it > somehow. I don't think this will actually add anything new > for the solution, but probably it has some link to publishing as well. > > > REQ C-5 covers this partly, however it makes a hint that new > > values of attributes are to be modified from existing values. > > By taking the geographical location information example, the > > difference between the information to be delivered to > > different watchers is only in the level of details. > > Therefore, there could be another approach that tuples would > > be assigned for the different level of details and > > authorization would be done based on some kind of "level of > > detail" attribute. > > > > OK, do you have some text to propose? > > > -REQ ?-x: > > Relation between the content requirements and the acceptance > > policy requirements are somehow undefined. When the > > acceptance policy results in accepting a watcher, then which > > content/notification requirements shall be applied, how and > > where this relation would be defined. > > > > OK, I'll try to clarify that. I guess acceptance is the first > steps, and subsequent rules would cover the content to be given. > > > Thanks, > > Krisztian > > > > Markus > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Jun 13 18: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 SAA26471; Fri, 13 Jun 2003 18:29:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Qx0W-0001pF-00; Fri, 13 Jun 2003 18:26:52 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Qx0W-0001pC-00; Fri, 13 Jun 2003 18:26:52 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DIm1a14134; Fri, 13 Jun 2003 14:48:01 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DIlEm13300 for ; Fri, 13 Jun 2003 14:47:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18221 for ; Fri, 13 Jun 2003 14:47:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QtXq-0000Pn-00 for simple@ietf.org; Fri, 13 Jun 2003 14:45:02 -0400 Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx with esmtp (Exim 4.12) id 19QtXp-0000Pk-00 for simple@ietf.org; Fri, 13 Jun 2003 14:45:01 -0400 Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by opus.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h5DIl8ue026757; Fri, 13 Jun 2003 14:47:08 -0400 (EDT) Message-ID: <3EEA1B4A.4010507@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030603 Thunderbird/0.1a X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: jdrosen@dynamicsoft.com, aki.niemi@nokia.com, simple@ietf.org References: <2038BCC78B1AD641891A0D1AE133DBB701796D99@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701796D99@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Re: Presence filtering idea Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 13 Jun 2003 14:43:22 -0400 Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > > Maybe you, me and others on the list can read the XML document and > figure out what information it carries, but most people can't. What > does an element called mean to an average user? > > Referring to the example I presented in an earlier email, I cannot > automate sending an IM to someone when he comes online unless my > terminal understands the format of the XML document it receives and > consequently sends the IM. Do you want to eliminate such automated > feature? I'm not happy when saying that any recent Brower can render > XML in a human-readable format, I want to automate things. Nobody here, I believe, is suggesting some unstructured or non-standardized presence or event document. I certainly never did. I simply noted that extensions, while not accessible to automatons, may still be accessible to humans. Certainly, most of the tags in the RPIDS description are pretty obvious. This is a non-issue, so we should probably not waste additional electrons on this. > I'm not convinced that it can done otherwise. Again, the client of > the resulting XML document is not necessarily a human. The notifier > must send the requested information in a format the subscriber > understands. 2 reasons: Again, this is not in contention. You are not understanding my concern. The issue is not the standardization of the presence format, but rather the language used to express filtering. I'm not convinced that XPath is necessarily the most appropriate language. > > Along with the arguments I present above, I would like to re-state > that the proposal we put forward is not just presence specific, its a > generic filtering solution for any event package. Your concerns above do not apply; your concerns here only apply if we assume that event description are arbitrarily structured XML, as I noted in my original message. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Fri Jun 13 18:29:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26492 for ; Fri, 13 Jun 2003 18:29:32 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5DMT5O28199 for simple-archive@odin.ietf.org; Fri, 13 Jun 2003 18:29:05 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DMT5m28196 for ; Fri, 13 Jun 2003 18: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 SAA26471; Fri, 13 Jun 2003 18:29:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Qx0W-0001pF-00; Fri, 13 Jun 2003 18:26:52 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Qx0W-0001pC-00; Fri, 13 Jun 2003 18:26:52 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DIm1a14134; Fri, 13 Jun 2003 14:48:01 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DIlEm13300 for ; Fri, 13 Jun 2003 14:47:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18221 for ; Fri, 13 Jun 2003 14:47:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QtXq-0000Pn-00 for simple@ietf.org; Fri, 13 Jun 2003 14:45:02 -0400 Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx with esmtp (Exim 4.12) id 19QtXp-0000Pk-00 for simple@ietf.org; Fri, 13 Jun 2003 14:45:01 -0400 Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by opus.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h5DIl8ue026757; Fri, 13 Jun 2003 14:47:08 -0400 (EDT) Message-ID: <3EEA1B4A.4010507@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030603 Thunderbird/0.1a X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: jdrosen@dynamicsoft.com, aki.niemi@nokia.com, simple@ietf.org References: <2038BCC78B1AD641891A0D1AE133DBB701796D99@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701796D99@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Re: Presence filtering idea Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 13 Jun 2003 14:43:22 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > > Maybe you, me and others on the list can read the XML document and > figure out what information it carries, but most people can't. What > does an element called mean to an average user? > > Referring to the example I presented in an earlier email, I cannot > automate sending an IM to someone when he comes online unless my > terminal understands the format of the XML document it receives and > consequently sends the IM. Do you want to eliminate such automated > feature? I'm not happy when saying that any recent Brower can render > XML in a human-readable format, I want to automate things. Nobody here, I believe, is suggesting some unstructured or non-standardized presence or event document. I certainly never did. I simply noted that extensions, while not accessible to automatons, may still be accessible to humans. Certainly, most of the tags in the RPIDS description are pretty obvious. This is a non-issue, so we should probably not waste additional electrons on this. > I'm not convinced that it can done otherwise. Again, the client of > the resulting XML document is not necessarily a human. The notifier > must send the requested information in a format the subscriber > understands. 2 reasons: Again, this is not in contention. You are not understanding my concern. The issue is not the standardization of the presence format, but rather the language used to express filtering. I'm not convinced that XPath is necessarily the most appropriate language. > > Along with the arguments I present above, I would like to re-state > that the proposal we put forward is not just presence specific, its a > generic filtering solution for any event package. Your concerns above do not apply; your concerns here only apply if we assume that event description are arbitrarily structured XML, as I noted in my original message. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Jun 13 20:09:35 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 UAA29321; Fri, 13 Jun 2003 20:09:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QyZp-0002Yu-00; Fri, 13 Jun 2003 20:07:25 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19QyZo-0002Yr-00; Fri, 13 Jun 2003 20:07:25 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DKl0a17057; Fri, 13 Jun 2003 16:47:00 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DKkcm17020 for ; Fri, 13 Jun 2003 16:46: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 QAA22489 for ; Fri, 13 Jun 2003 16:46:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QvPP-00016b-00 for simple@ietf.org; Fri, 13 Jun 2003 16:44:27 -0400 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 19QvPO-00016Y-00 for simple@ietf.org; Fri, 13 Jun 2003 16:44:26 -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 h5DKjlqn000883; Fri, 13 Jun 2003 16:45:47 -0400 (EDT) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Fri, 13 Jun 2003 15:45:46 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A64865@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'Henning Schulzrinne'" , Rohan Mahy Cc: Adam Roach , "'Lisa Dusseault'" , simple@ietf.org Subject: RE: [Simple] XCAP and Webdav 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: Fri, 13 Jun 2003 15:45:38 -0500 Henning Schulzrinne [mailto:hgs@cs.columbia.edu] wrote: > Why couldn't you structure the buddy list like a logical directory, > where retrieving the directory gets the whole list, but each > 'file' is > one entry? As in > > example.com/buddy/ > example.com/buddy/joe@foo.com We want XCAP to work for manipulation of arbitrary XML documents, not just buddy lists. Your proposal requires either mandating the presence of a "name" attribute in every manipulatable XML element, or some additional meta-information for every XML schema that calls out some canonical identifier for each element. /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Fri Jun 13 20:10:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29341 for ; Fri, 13 Jun 2003 20:10:05 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5E09b104439 for simple-archive@odin.ietf.org; Fri, 13 Jun 2003 20:09:37 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5E09am04436 for ; Fri, 13 Jun 2003 20:09:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29321; Fri, 13 Jun 2003 20:09:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QyZp-0002Yu-00; Fri, 13 Jun 2003 20:07:25 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19QyZo-0002Yr-00; Fri, 13 Jun 2003 20:07:25 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DKl0a17057; Fri, 13 Jun 2003 16:47:00 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DKkcm17020 for ; Fri, 13 Jun 2003 16:46: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 QAA22489 for ; Fri, 13 Jun 2003 16:46:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QvPP-00016b-00 for simple@ietf.org; Fri, 13 Jun 2003 16:44:27 -0400 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 19QvPO-00016Y-00 for simple@ietf.org; Fri, 13 Jun 2003 16:44:26 -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 h5DKjlqn000883; Fri, 13 Jun 2003 16:45:47 -0400 (EDT) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Fri, 13 Jun 2003 15:45:46 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A64865@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'Henning Schulzrinne'" , Rohan Mahy Cc: Adam Roach , "'Lisa Dusseault'" , simple@ietf.org Subject: RE: [Simple] XCAP and Webdav 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: Fri, 13 Jun 2003 15:45:38 -0500 Henning Schulzrinne [mailto:hgs@cs.columbia.edu] wrote: > Why couldn't you structure the buddy list like a logical directory, > where retrieving the directory gets the whole list, but each > 'file' is > one entry? As in > > example.com/buddy/ > example.com/buddy/joe@foo.com We want XCAP to work for manipulation of arbitrary XML documents, not just buddy lists. Your proposal requires either mandating the presence of a "name" attribute in every manipulatable XML element, or some additional meta-information for every XML schema that calls out some canonical identifier for each element. /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Sat Jun 14 00:03:37 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 AAA04954; Sat, 14 Jun 2003 00:03:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19R2EL-0003vV-00; Sat, 14 Jun 2003 00:01:29 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19R2EK-0003vQ-00; Sat, 14 Jun 2003 00:01:28 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5E2B2a12262; Fri, 13 Jun 2003 22:11:02 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5E2Aem12248 for ; Fri, 13 Jun 2003 22:10: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 WAA02232 for ; Fri, 13 Jun 2003 22:10:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19R0Sy-0003HD-00 for simple@ietf.org; Fri, 13 Jun 2003 22:08:28 -0400 Received: from dewberry.cc.columbia.edu ([128.59.59.68] ident=cu41754) by ietf-mx with esmtp (Exim 4.12) id 19R0Sx-0003HA-00 for simple@ietf.org; Fri, 13 Jun 2003 22:08:27 -0400 Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (user=hgs10 mech=PLAIN bits=0) by dewberry.cc.columbia.edu (8.12.8p1/8.12.8) with ESMTP id h5E2ASl4011209 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 13 Jun 2003 22:10:29 -0400 (EDT) Message-ID: <3EEA8408.1070906@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030529 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adam Roach CC: Rohan Mahy , "'Lisa Dusseault'" , simple@ietf.org Subject: Re: [Simple] XCAP and Webdav References: <9BF66EBF6BEFD942915B4D4D45C051F3A64865@dyn-tx-exch-001.dynamicsoft.com> In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3A64865@dyn-tx-exch-001.dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.32 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 13 Jun 2003 22:10:16 -0400 Content-Transfer-Encoding: 7bit > We want XCAP to work for manipulation of arbitrary XML documents, > not just buddy lists. Certainly. > > Your proposal requires either mandating the presence of a "name" > attribute in every manipulatable XML element, or some additional > meta-information for every XML schema that calls out some canonical > identifier for each element. Why does this prevent using a named-element approach for those cases where this is possible, thus avoiding either the complexity, latency or the byte overhead inherent in other approaches? _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Sat Jun 14 00:04:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04972 for ; Sat, 14 Jun 2003 00:04:20 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5E43qS18577 for simple-archive@odin.ietf.org; Sat, 14 Jun 2003 00:03:52 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5E43km18574 for ; Sat, 14 Jun 2003 00:03:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04954; Sat, 14 Jun 2003 00:03:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19R2EL-0003vV-00; Sat, 14 Jun 2003 00:01:29 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19R2EK-0003vQ-00; Sat, 14 Jun 2003 00:01:28 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5E2B2a12262; Fri, 13 Jun 2003 22:11:02 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5E2Aem12248 for ; Fri, 13 Jun 2003 22:10: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 WAA02232 for ; Fri, 13 Jun 2003 22:10:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19R0Sy-0003HD-00 for simple@ietf.org; Fri, 13 Jun 2003 22:08:28 -0400 Received: from dewberry.cc.columbia.edu ([128.59.59.68] ident=cu41754) by ietf-mx with esmtp (Exim 4.12) id 19R0Sx-0003HA-00 for simple@ietf.org; Fri, 13 Jun 2003 22:08:27 -0400 Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (user=hgs10 mech=PLAIN bits=0) by dewberry.cc.columbia.edu (8.12.8p1/8.12.8) with ESMTP id h5E2ASl4011209 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 13 Jun 2003 22:10:29 -0400 (EDT) Message-ID: <3EEA8408.1070906@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030529 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adam Roach CC: Rohan Mahy , "'Lisa Dusseault'" , simple@ietf.org Subject: Re: [Simple] XCAP and Webdav References: <9BF66EBF6BEFD942915B4D4D45C051F3A64865@dyn-tx-exch-001.dynamicsoft.com> In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3A64865@dyn-tx-exch-001.dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.32 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 13 Jun 2003 22:10:16 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > We want XCAP to work for manipulation of arbitrary XML documents, > not just buddy lists. Certainly. > > Your proposal requires either mandating the presence of a "name" > attribute in every manipulatable XML element, or some additional > meta-information for every XML schema that calls out some canonical > identifier for each element. Why does this prevent using a named-element approach for those cases where this is possible, thus avoiding either the complexity, latency or the byte overhead inherent in other approaches? _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Sat Jun 14 01:55: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 BAA07469; Sat, 14 Jun 2003 01:55:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19R3yB-0004Uo-00; Sat, 14 Jun 2003 01:52:55 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19R3yA-0004Ul-00; Sat, 14 Jun 2003 01:52:54 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DNk1a02482; Fri, 13 Jun 2003 19:46:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DNjGm02455 for ; Fri, 13 Jun 2003 19:45:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28635 for ; Fri, 13 Jun 2003 19:45:12 -0400 (EDT) From: hardie@qualcomm.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QyCH-0002NN-00 for simple@ietf.org; Fri, 13 Jun 2003 19:43:05 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx with esmtp (Exim 4.12) id 19QyCG-0002NJ-00 for simple@ietf.org; Fri, 13 Jun 2003 19:43:04 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h5DNjCxO017612 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Fri, 13 Jun 2003 16:45:12 -0700 (PDT) Received: from [129.46.227.161] (carbuncle.qualcomm.com [129.46.227.161]) by neophyte.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h5DNjAuh023459 for ; Fri, 13 Jun 2003 16:45:11 -0700 (PDT) Mime-Version: 1.0 X-Sender: hardie@mage.qualcomm.com Message-Id: To: simple@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [Simple] Thoughts on XCAP Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 13 Jun 2003 16:45:08 -0700 Howdy folks, As you know from recent traffic on the list, there was an agreement at the Interim Meeting to accept the XCAP docs as working group drafts. After that was announced to the working group, Jonathan asked me to take a look at them to see if there were any gotchas likely on the use of HTTP, XPATH, and the other components of the proposal. After reading the core doc and re-reading the XPATH doc, Jonathan, Jon, and I had a phone call earlier today to discuss the proposals and to talk about the conversation around this proposal that happened at the Interim. First, let me say that I understand the approach of the group is to define a set of schemas which allows the manipulation of this data, but that the group intends that the data manipulation and transport will be out-of-band to SIMPLE itself. Second, let me say that I am very happy to see energy in the group around solving this problem, and I appreciate the work that has gone into hammering on this solution. Last, let me say that I think the XCAP docs provide a foundation for work that the working group can take forward if this is the consensus of the group. There are, however, some issues that I would like to ask the working group to consider. First, the IETF has in the past asked working groups re-using HTTP to be very careful that the semantics of their use fit within the semantics of HTTP (It has in particular asked working groups to be very careful about using "POST" as an operator to extend the semantics of HTTP). Where a re-use of HTTP extended or restricted the semantics of HTTP, the IETF has asked that the group create a new uri scheme, select a new port, and describe the protocol in full. The Internet Printing Protocol (IPP) and WebDav are both cases where this has occurred. As I read the documents at the moment, I believe that XCAP would fall in to this category; right now it is sufficiently different from the basic semantics of HTTP that it would require full specification, and would likely need to shift some of the "POST"-based semantics to other methods. While I don't think this a bad idea (indeed, I suspect the resulting protocol would see reuse almost immediately), it is likely to take time and effort. It may also require some expertise from those who are not currently core participants in the SIMPLE effort. I can work with the chairs to help identify those resources, if required. Both Jon and Jonathan have expressed concern that taking the XCAP documents down that road would take more time than is practical for SIMPLE. While no one really wants to re-visit a decision that has already been made, I wanted to make sure the working group understands the type of output that would likely be expected for XCAP. I certainly don't want to do anything that dims the energy of the group, though, and I'm sure we would all like to find a way forward which minimizes delay. In the call today, Jon, Jonathan, and I brainstormed a bit on the roads forward, and I'd like to share my view of them below. I believe Jonathan will also be sending his view. 1) Continue work on XCAP with the current set of requirements as a guide. With a strong design team in place, work to complete a spec which is fully functional for SIMPLE's needs and is either sufficiently general or extensible that it can be used by other likely consumers of an XML-based data manipulation and update protocol. Four to six months would be the most optimistic imaginable timeframe for this, and it might be much longer. 2) Shift the XCAP framework so that it fits fully within the semantics of HTPP. This likely would involve paring some requirements, since locking would not be enabled. Depending on the extent to which XPATH-based URIs were supported, this might or might force the fundamental unit of manipulation to always be the full list, which could have an impact on wireless users. 3) Shift the model so that the individual elements are seen as collection members with specific attributes, and re-use WebDav's locking and methods to accomplish the manipulation of the components. This may constrain implementations in ways that reduce efficiency for some operations. It is unfortunate that there is no easier answer here; each has an engineering trade-off that requires either a shift in the requirements, the view of the components, or the scope of the effort. As the working group considers these documents and this requirement, I would appreciate you considering each of these trade-offs and sharing with the group your view and other considerations which occur to you. thanks, Ted Hardie _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Sat Jun 14 01:55:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07485 for ; Sat, 14 Jun 2003 01:55:36 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5E5t7o26350 for simple-archive@odin.ietf.org; Sat, 14 Jun 2003 01:55:07 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5E5t7m26346 for ; Sat, 14 Jun 2003 01:55: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 BAA07469; Sat, 14 Jun 2003 01:55:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19R3yB-0004Uo-00; Sat, 14 Jun 2003 01:52:55 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19R3yA-0004Ul-00; Sat, 14 Jun 2003 01:52:54 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DNk1a02482; Fri, 13 Jun 2003 19:46:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DNjGm02455 for ; Fri, 13 Jun 2003 19:45:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28635 for ; Fri, 13 Jun 2003 19:45:12 -0400 (EDT) From: hardie@qualcomm.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QyCH-0002NN-00 for simple@ietf.org; Fri, 13 Jun 2003 19:43:05 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx with esmtp (Exim 4.12) id 19QyCG-0002NJ-00 for simple@ietf.org; Fri, 13 Jun 2003 19:43:04 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h5DNjCxO017612 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Fri, 13 Jun 2003 16:45:12 -0700 (PDT) Received: from [129.46.227.161] (carbuncle.qualcomm.com [129.46.227.161]) by neophyte.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h5DNjAuh023459 for ; Fri, 13 Jun 2003 16:45:11 -0700 (PDT) Mime-Version: 1.0 X-Sender: hardie@mage.qualcomm.com Message-Id: To: simple@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [Simple] Thoughts on XCAP Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 13 Jun 2003 16:45:08 -0700 Howdy folks, As you know from recent traffic on the list, there was an agreement at the Interim Meeting to accept the XCAP docs as working group drafts. After that was announced to the working group, Jonathan asked me to take a look at them to see if there were any gotchas likely on the use of HTTP, XPATH, and the other components of the proposal. After reading the core doc and re-reading the XPATH doc, Jonathan, Jon, and I had a phone call earlier today to discuss the proposals and to talk about the conversation around this proposal that happened at the Interim. First, let me say that I understand the approach of the group is to define a set of schemas which allows the manipulation of this data, but that the group intends that the data manipulation and transport will be out-of-band to SIMPLE itself. Second, let me say that I am very happy to see energy in the group around solving this problem, and I appreciate the work that has gone into hammering on this solution. Last, let me say that I think the XCAP docs provide a foundation for work that the working group can take forward if this is the consensus of the group. There are, however, some issues that I would like to ask the working group to consider. First, the IETF has in the past asked working groups re-using HTTP to be very careful that the semantics of their use fit within the semantics of HTTP (It has in particular asked working groups to be very careful about using "POST" as an operator to extend the semantics of HTTP). Where a re-use of HTTP extended or restricted the semantics of HTTP, the IETF has asked that the group create a new uri scheme, select a new port, and describe the protocol in full. The Internet Printing Protocol (IPP) and WebDav are both cases where this has occurred. As I read the documents at the moment, I believe that XCAP would fall in to this category; right now it is sufficiently different from the basic semantics of HTTP that it would require full specification, and would likely need to shift some of the "POST"-based semantics to other methods. While I don't think this a bad idea (indeed, I suspect the resulting protocol would see reuse almost immediately), it is likely to take time and effort. It may also require some expertise from those who are not currently core participants in the SIMPLE effort. I can work with the chairs to help identify those resources, if required. Both Jon and Jonathan have expressed concern that taking the XCAP documents down that road would take more time than is practical for SIMPLE. While no one really wants to re-visit a decision that has already been made, I wanted to make sure the working group understands the type of output that would likely be expected for XCAP. I certainly don't want to do anything that dims the energy of the group, though, and I'm sure we would all like to find a way forward which minimizes delay. In the call today, Jon, Jonathan, and I brainstormed a bit on the roads forward, and I'd like to share my view of them below. I believe Jonathan will also be sending his view. 1) Continue work on XCAP with the current set of requirements as a guide. With a strong design team in place, work to complete a spec which is fully functional for SIMPLE's needs and is either sufficiently general or extensible that it can be used by other likely consumers of an XML-based data manipulation and update protocol. Four to six months would be the most optimistic imaginable timeframe for this, and it might be much longer. 2) Shift the XCAP framework so that it fits fully within the semantics of HTPP. This likely would involve paring some requirements, since locking would not be enabled. Depending on the extent to which XPATH-based URIs were supported, this might or might force the fundamental unit of manipulation to always be the full list, which could have an impact on wireless users. 3) Shift the model so that the individual elements are seen as collection members with specific attributes, and re-use WebDav's locking and methods to accomplish the manipulation of the components. This may constrain implementations in ways that reduce efficiency for some operations. It is unfortunate that there is no easier answer here; each has an engineering trade-off that requires either a shift in the requirements, the view of the components, or the scope of the effort. As the working group considers these documents and this requirement, I would appreciate you considering each of these trade-offs and sharing with the group your view and other considerations which occur to you. thanks, Ted Hardie _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Sun Jun 15 04:43:44 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 EAA26233; Sun, 15 Jun 2003 04:43:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19RT4u-0002YK-00; Sun, 15 Jun 2003 04:41:33 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19RT4u-0002YF-00; Sun, 15 Jun 2003 04:41:32 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5F7Bxa07245; Sun, 15 Jun 2003 03:11:59 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5F7B9m07222 for ; Sun, 15 Jun 2003 03:11: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 DAA25102 for ; Sun, 15 Jun 2003 03:11:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19RRdG-0002J1-00 for simple@ietf.org; Sun, 15 Jun 2003 03:08:54 -0400 Received: from [80.74.106.10] (helo=nt-mail.radvision.com) by ietf-mx with esmtp (Exim 4.12) id 19RRdE-0002Iy-00 for simple@ietf.org; Sun, 15 Jun 2003 03:08:53 -0400 Received: from nt-mail.radvision.com [172.20.2.100] by nt-mail.radvision.com with XWall v3.26 ; Sun, 15 Jun 2003 10:09:58 +0300 Received: by nt-mail.radvision.com with Internet Mail Service (5.5.2653.19) id ; Sun, 15 Jun 2003 10:09:58 +0300 Message-ID: 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] Request-URI is identity of the Presentity Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 15 Jun 2003 10:09:52 +0300 Hi. In draft-ietf-simple-presence-10 it is defined that the Request-URI identifies the desired Presentity in a Subscribe request. This is also defined in RFC 3265 ("The Request-URI of a Subscribe request ..... It also contains enough information to identify the resource for which event notification is desired ..."). Since the Subscribe request is defined as a dialog-creating method, the Request-URI is not one of its identifiers. I think that the result is that two Subscribe requests with different Request-URIs can be handled by the same dialog, where they represent different Presentities. Isn't this a problem? Thanks, Orly. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Sun Jun 15 04:44:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26249 for ; Sun, 15 Jun 2003 04:44:16 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5F8hmw16961 for simple-archive@odin.ietf.org; Sun, 15 Jun 2003 04:43:48 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5F8hlm16958 for ; Sun, 15 Jun 2003 04:43:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26233; Sun, 15 Jun 2003 04:43:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19RT4u-0002YK-00; Sun, 15 Jun 2003 04:41:33 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19RT4u-0002YF-00; Sun, 15 Jun 2003 04:41:32 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5F7Bxa07245; Sun, 15 Jun 2003 03:11:59 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5F7B9m07222 for ; Sun, 15 Jun 2003 03:11: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 DAA25102 for ; Sun, 15 Jun 2003 03:11:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19RRdG-0002J1-00 for simple@ietf.org; Sun, 15 Jun 2003 03:08:54 -0400 Received: from [80.74.106.10] (helo=nt-mail.radvision.com) by ietf-mx with esmtp (Exim 4.12) id 19RRdE-0002Iy-00 for simple@ietf.org; Sun, 15 Jun 2003 03:08:53 -0400 Received: from nt-mail.radvision.com [172.20.2.100] by nt-mail.radvision.com with XWall v3.26 ; Sun, 15 Jun 2003 10:09:58 +0300 Received: by nt-mail.radvision.com with Internet Mail Service (5.5.2653.19) id ; Sun, 15 Jun 2003 10:09:58 +0300 Message-ID: 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] Request-URI is identity of the Presentity Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 15 Jun 2003 10:09:52 +0300 Hi. In draft-ietf-simple-presence-10 it is defined that the Request-URI identifies the desired Presentity in a Subscribe request. This is also defined in RFC 3265 ("The Request-URI of a Subscribe request ..... It also contains enough information to identify the resource for which event notification is desired ..."). Since the Subscribe request is defined as a dialog-creating method, the Request-URI is not one of its identifiers. I think that the result is that two Subscribe requests with different Request-URIs can be handled by the same dialog, where they represent different Presentities. Isn't this a problem? Thanks, Orly. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Jun 16 08:51:40 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 IAA12228; Mon, 16 Jun 2003 08:51:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19RtQL-0002N9-00; Mon, 16 Jun 2003 08:49:25 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19RtQL-0002N4-00; Mon, 16 Jun 2003 08:49:25 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5G7p3a12318; Mon, 16 Jun 2003 03:51:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5G7ohm12302 for ; Mon, 16 Jun 2003 03:50: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 DAA04671 for ; Mon, 16 Jun 2003 03:50:41 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Roj5-0000XQ-00 for simple@ietf.org; Mon, 16 Jun 2003 03:48:27 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19Roj4-0000XM-00 for simple@ietf.org; Mon, 16 Jun 2003 03:48:26 -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 h5G7oda06199 for ; Mon, 16 Jun 2003 10:50:39 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 16 Jun 2003 10:50:39 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 16 Jun 2003 10:50:39 +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" Subject: RE: [Simple] Re: Presence filtering idea Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701796DB2@esebe019.ntc.nokia.com> Thread-Topic: [Simple] Re: Presence filtering idea Thread-Index: AcMyCIQ7XESMRu2yRwiV/80maZLfJQB0gEbQ To: Cc: , , X-OriginalArrivalTime: 16 Jun 2003 07:50:39.0493 (UTC) FILETIME=[FACA6B50:01C333DB] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5G7ohm12303 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 16 Jun 2003 10:50:38 +0300 Content-Transfer-Encoding: 8bit > -----Original Message----- > From: ext Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Friday, June 13, 2003 9:43 PM > To: Khartabil Hisham (NMP/Helsinki) > Cc: jdrosen@dynamicsoft.com; Niemi Aki (NMP/Helsinki); simple@ietf.org > Subject: [Simple] Re: Presence filtering idea > > > hisham.khartabil@nokia.com wrote: > > > > > > Maybe you, me and others on the list can read the XML document and > > figure out what information it carries, but most people can't. What > > does an element called mean to an average user? > > > > Referring to the example I presented in an earlier email, I cannot > > automate sending an IM to someone when he comes online unless my > > terminal understands the format of the XML document it receives and > > consequently sends the IM. Do you want to eliminate such automated > > feature? I'm not happy when saying that any recent Brower > can render > > XML in a human-readable format, I want to automate things. > > Nobody here, I believe, is suggesting some unstructured or > non-standardized presence or event document. I certainly never did. I > simply noted that extensions, while not accessible to automatons, may > still be accessible to humans. Certainly, most of the tags in > the RPIDS > description are pretty obvious. This is a non-issue, so we should > probably not waste additional electrons on this. > > > I'm not convinced that it can done otherwise. Again, the client of > > the resulting XML document is not necessarily a human. The notifier > > must send the requested information in a format the subscriber > > understands. 2 reasons: > > Again, this is not in contention. You are not understanding > my concern. > The issue is not the standardization of the presence format, > but rather > the language used to express filtering. I'm not convinced > that XPath is > necessarily the most appropriate language. > > > > > Along with the arguments I present above, I would like to re-state > > that the proposal we put forward is not just presence > specific, its a > > generic filtering solution for any event package. > > Your concerns above do not apply; your concerns here only apply if we > assume that event description are arbitrarily structured XML, > as I noted > in my original message. My concern was about the comment that was made that a presence state can be expressed in many different standardised ways depending on what a tuple represents. My argument was that either the client needs to understand all the standardised ways of representing a certain presence state, or the compositor has to know/agree with the client. In both cases, I don't see the difference between representing the filter like: media="audio" or in xpath //*[/media="audio" /Hisham > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon Jun 16 08:52:11 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12260 for ; Mon, 16 Jun 2003 08:52:10 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5GCpgj32514 for simple-archive@odin.ietf.org; Mon, 16 Jun 2003 08:51:42 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GCpgm32511 for ; Mon, 16 Jun 2003 08:51:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12228; Mon, 16 Jun 2003 08:51:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19RtQL-0002N9-00; Mon, 16 Jun 2003 08:49:25 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19RtQL-0002N4-00; Mon, 16 Jun 2003 08:49:25 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5G7p3a12318; Mon, 16 Jun 2003 03:51:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5G7ohm12302 for ; Mon, 16 Jun 2003 03:50: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 DAA04671 for ; Mon, 16 Jun 2003 03:50:41 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Roj5-0000XQ-00 for simple@ietf.org; Mon, 16 Jun 2003 03:48:27 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19Roj4-0000XM-00 for simple@ietf.org; Mon, 16 Jun 2003 03:48:26 -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 h5G7oda06199 for ; Mon, 16 Jun 2003 10:50:39 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 16 Jun 2003 10:50:39 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 16 Jun 2003 10:50:39 +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" Subject: RE: [Simple] Re: Presence filtering idea Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701796DB2@esebe019.ntc.nokia.com> Thread-Topic: [Simple] Re: Presence filtering idea Thread-Index: AcMyCIQ7XESMRu2yRwiV/80maZLfJQB0gEbQ To: Cc: , , X-OriginalArrivalTime: 16 Jun 2003 07:50:39.0493 (UTC) FILETIME=[FACA6B50:01C333DB] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5G7ohm12303 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 16 Jun 2003 10:50:38 +0300 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit > -----Original Message----- > From: ext Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Friday, June 13, 2003 9:43 PM > To: Khartabil Hisham (NMP/Helsinki) > Cc: jdrosen@dynamicsoft.com; Niemi Aki (NMP/Helsinki); simple@ietf.org > Subject: [Simple] Re: Presence filtering idea > > > hisham.khartabil@nokia.com wrote: > > > > > > Maybe you, me and others on the list can read the XML document and > > figure out what information it carries, but most people can't. What > > does an element called mean to an average user? > > > > Referring to the example I presented in an earlier email, I cannot > > automate sending an IM to someone when he comes online unless my > > terminal understands the format of the XML document it receives and > > consequently sends the IM. Do you want to eliminate such automated > > feature? I'm not happy when saying that any recent Brower > can render > > XML in a human-readable format, I want to automate things. > > Nobody here, I believe, is suggesting some unstructured or > non-standardized presence or event document. I certainly never did. I > simply noted that extensions, while not accessible to automatons, may > still be accessible to humans. Certainly, most of the tags in > the RPIDS > description are pretty obvious. This is a non-issue, so we should > probably not waste additional electrons on this. > > > I'm not convinced that it can done otherwise. Again, the client of > > the resulting XML document is not necessarily a human. The notifier > > must send the requested information in a format the subscriber > > understands. 2 reasons: > > Again, this is not in contention. You are not understanding > my concern. > The issue is not the standardization of the presence format, > but rather > the language used to express filtering. I'm not convinced > that XPath is > necessarily the most appropriate language. > > > > > Along with the arguments I present above, I would like to re-state > > that the proposal we put forward is not just presence > specific, its a > > generic filtering solution for any event package. > > Your concerns above do not apply; your concerns here only apply if we > assume that event description are arbitrarily structured XML, > as I noted > in my original message. My concern was about the comment that was made that a presence state can be expressed in many different standardised ways depending on what a tuple represents. My argument was that either the client needs to understand all the standardised ways of representing a certain presence state, or the compositor has to know/agree with the client. In both cases, I don't see the difference between representing the filter like: media="audio" or in xpath //*[/media="audio" /Hisham > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Jun 16 13:33:13 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 NAA21790; Mon, 16 Jun 2003 13:33:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Rxoo-0004FU-00; Mon, 16 Jun 2003 13:30:58 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Rxon-0004FR-00; Mon, 16 Jun 2003 13:30:57 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GBv3a28226; Mon, 16 Jun 2003 07:57:03 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GBuHm28184 for ; Mon, 16 Jun 2003 07:56:17 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09159; Mon, 16 Jun 2003 07:56:15 -0400 (EDT) Message-Id: <200306161156.HAA09159@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: simple@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-event-list-04.txt Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 16 Jun 2003 07:56:15 -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 : A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists Author(s) : A. Roach, J. Rosenberg, B. Campbell Filename : draft-ietf-simple-event-list-04.txt Pages : 42 Date : 2003-6-13 This document presents an extension to the Session Initiation Protocol (SIP)-Specific Event Notification mechanism for subscribing to a homogeneous list of resources. Instead of the subscriber sending a SUBSCRIBE for each resource individually, the subscriber can subscribe to an entire list, and then receive notifications when the state of any of the resources in the list changes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-event-list-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-event-list-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-event-list-04.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-6-16080911.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-event-list-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-event-list-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-16080911.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon Jun 16 13:33:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21814 for ; Mon, 16 Jun 2003 13:33:44 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5GHXFB20289 for simple-archive@odin.ietf.org; Mon, 16 Jun 2003 13:33:15 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GHXFm20286 for ; Mon, 16 Jun 2003 13:33:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21790; Mon, 16 Jun 2003 13:33:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Rxoo-0004FU-00; Mon, 16 Jun 2003 13:30:58 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Rxon-0004FR-00; Mon, 16 Jun 2003 13:30:57 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GBv3a28226; Mon, 16 Jun 2003 07:57:03 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GBuHm28184 for ; Mon, 16 Jun 2003 07:56:17 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09159; Mon, 16 Jun 2003 07:56:15 -0400 (EDT) Message-Id: <200306161156.HAA09159@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: simple@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-event-list-04.txt Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 16 Jun 2003 07:56:15 -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 : A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists Author(s) : A. Roach, J. Rosenberg, B. Campbell Filename : draft-ietf-simple-event-list-04.txt Pages : 42 Date : 2003-6-13 This document presents an extension to the Session Initiation Protocol (SIP)-Specific Event Notification mechanism for subscribing to a homogeneous list of resources. Instead of the subscriber sending a SUBSCRIBE for each resource individually, the subscriber can subscribe to an entire list, and then receive notifications when the state of any of the resources in the list changes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-event-list-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-event-list-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-event-list-04.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-6-16080911.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-event-list-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-event-list-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-16080911.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Jun 16 20:11: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 UAA09631; Mon, 16 Jun 2003 20:11:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19S42c-0000ef-00; Mon, 16 Jun 2003 20:09:39 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19S42c-0000ec-00; Mon, 16 Jun 2003 20:09:38 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GFb0a12001; Mon, 16 Jun 2003 11:37:00 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GFaPm11931 for ; Mon, 16 Jun 2003 11:36:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18113 for ; Mon, 16 Jun 2003 11:36:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Rvzl-0003PU-00 for simple@ietf.org; Mon, 16 Jun 2003 11:34:09 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19Rvzl-0003P7-00 for simple@ietf.org; Mon, 16 Jun 2003 11:34:09 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h5GFZbi10940; Mon, 16 Jun 2003 10:35:38 -0500 Subject: Re: [Simple] Request-URI is identity of the Presentity From: Robert Sparks To: Orly Rosenberg Cc: "'simple@ietf.org'" In-Reply-To: References: Content-Type: text/plain Message-Id: <1055777736.923.57.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 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: 16 Jun 2003 10:35:36 -0500 Content-Transfer-Encoding: 7bit Are you objecting to the possibility of having to maintain state for more than one subscription sharing the same dialog identifiers (To/From tags, Call-ID)? That's something you have to handle even if the Request-URI doesn't change. You can have subscriptions to different events reusing those identifiers (Event: presence, Event: presence.winfo, Event: refer). Within a package, you can have different subscriptions using the same dialog identifier differentiated by the "id" parameter on the Event header field value. If not, and it really is the potential for a changing Request-URI that's bothering you, can you sketch a scenario where that would (without violating protocol) happen and a problem results? RjS On Sun, 2003-06-15 at 02:09, Orly Rosenberg wrote: > Hi. > In draft-ietf-simple-presence-10 it is defined that the Request-URI > identifies the desired Presentity in a Subscribe request. This is also > defined in RFC 3265 ("The Request-URI of a Subscribe request ..... It also > contains enough information to identify the resource for which event > notification is desired ..."). > Since the Subscribe request is defined as a dialog-creating method, the > Request-URI is not one of its identifiers. I think that the result is that > two Subscribe requests with different Request-URIs can be handled by the > same dialog, where they represent different Presentities. > Isn't this a problem? > Thanks, > Orly. > _______________________________________________ > Simple mailing 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 mailnull@www1.ietf.org Mon Jun 16 20:12:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09669 for ; Mon, 16 Jun 2003 20:12:25 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5H0BuL18434 for simple-archive@odin.ietf.org; Mon, 16 Jun 2003 20:11:56 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5H0Bum18431 for ; Mon, 16 Jun 2003 20:11: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 UAA09631; Mon, 16 Jun 2003 20:11:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19S42c-0000ef-00; Mon, 16 Jun 2003 20:09:39 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19S42c-0000ec-00; Mon, 16 Jun 2003 20:09:38 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GFb0a12001; Mon, 16 Jun 2003 11:37:00 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GFaPm11931 for ; Mon, 16 Jun 2003 11:36:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18113 for ; Mon, 16 Jun 2003 11:36:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Rvzl-0003PU-00 for simple@ietf.org; Mon, 16 Jun 2003 11:34:09 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19Rvzl-0003P7-00 for simple@ietf.org; Mon, 16 Jun 2003 11:34:09 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h5GFZbi10940; Mon, 16 Jun 2003 10:35:38 -0500 Subject: Re: [Simple] Request-URI is identity of the Presentity From: Robert Sparks To: Orly Rosenberg Cc: "'simple@ietf.org'" In-Reply-To: References: Content-Type: text/plain Message-Id: <1055777736.923.57.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 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: 16 Jun 2003 10:35:36 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Are you objecting to the possibility of having to maintain state for more than one subscription sharing the same dialog identifiers (To/From tags, Call-ID)? That's something you have to handle even if the Request-URI doesn't change. You can have subscriptions to different events reusing those identifiers (Event: presence, Event: presence.winfo, Event: refer). Within a package, you can have different subscriptions using the same dialog identifier differentiated by the "id" parameter on the Event header field value. If not, and it really is the potential for a changing Request-URI that's bothering you, can you sketch a scenario where that would (without violating protocol) happen and a problem results? RjS On Sun, 2003-06-15 at 02:09, Orly Rosenberg wrote: > Hi. > In draft-ietf-simple-presence-10 it is defined that the Request-URI > identifies the desired Presentity in a Subscribe request. This is also > defined in RFC 3265 ("The Request-URI of a Subscribe request ..... It also > contains enough information to identify the resource for which event > notification is desired ..."). > Since the Subscribe request is defined as a dialog-creating method, the > Request-URI is not one of its identifiers. I think that the result is that > two Subscribe requests with different Request-URIs can be handled by the > same dialog, where they represent different Presentities. > Isn't this a problem? > Thanks, > Orly. > _______________________________________________ > Simple mailing 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 Jun 17 10:01:18 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 KAA16277; Tue, 17 Jun 2003 10:01:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SGzG-0007L8-00; Tue, 17 Jun 2003 09:59:02 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19SGzG-0007L3-00; Tue, 17 Jun 2003 09:59:02 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5H9M1a10031; Tue, 17 Jun 2003 05:22:01 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5H9Ljm10008 for ; Tue, 17 Jun 2003 05:21: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 FAA04513 for ; Tue, 17 Jun 2003 05:21:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SCch-0004Kk-00 for simple@ietf.org; Tue, 17 Jun 2003 05:19:27 -0400 Received: from igate2.vodafone.co.uk ([194.62.232.66]) by ietf-mx with esmtp (Exim 4.12) id 19SCcg-0004KH-00 for simple@ietf.org; Tue, 17 Jun 2003 05:19:26 -0400 Received: by igate2.vodafone.co.uk; (8.8.8/1.3/10May95) id KAA23581; Tue, 17 Jun 2003 10:21:12 +0100 (BST) Received: from ukwmxc02.vf-uk.internal.vodafone.com (ukwmxc02 [10.33.126.170]) by mailguard2 (4.6.1.123) with ESMTP id for ; Tue, 17 Jun 2003 10:18:27 +0100 Received: from ukwmxc04.vf-uk.internal.vodafone.com ([10.33.126.173]) by ukwmxc02.vf-uk.internal.vodafone.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 17 Jun 2003 10:20:19 +0100 Received: from ukwmxm02.vf-uk.internal.vodafone.com ([10.33.126.242]) by ukwmxc04.vf-uk.internal.vodafone.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 17 Jun 2003 10:20:19 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message Message-ID: Thread-Topic: Question on draft-ietf-simple-winfo-package-05 Thread-Index: AcM0sTj12mYLQ+ZPSCKk8P8Zor61MA== From: "Mills, Duncan, D, CND Tech Dev, VF UK" To: X-OriginalArrivalTime: 17 Jun 2003 09:20:19.0340 (UTC) FILETIME=[ABD7ACC0:01C334B1] MIME-Version: 1.0 (Generated by Clearswift ES version 4.6.1.122) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5H9Ljm10010 Subject: [Simple] Question on draft-ietf-simple-winfo-package-05 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, 17 Jun 2003 10:20:18 +0100 Content-Transfer-Encoding: 8bit Hi, I have a question on the above internet-draft: In section 5, "example usage," we see Joe subscribing to his own 'presence.winfo' event. Then we see another user, A@example.com trying to SUBSCRIBE to Joe's presence state. Joe is sent a NOTIFY request to tell him that a subscription is pending. Joe responds to this with a 200 OK. The draft then says that "Joe then authorizes A's subscription through some means." Can someone give me an example of how Joe authorises A's subscription? Is there no possibility to allow the 200 OK to carry the authorisation, implicit or otherwise? Regards, Duncan Duncan Mills Senior Engineer Network Standards & Technical Audit Technology Development (Network Systems) Vodafone (UK) Ltd Tel: +44 (0)1635 676074 Mob: +44 7867 900955 Fax: +44 (0)1635 234445 mailto:duncan.mills@vf.vodafone.co.uk _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Tue Jun 17 10:01:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16315 for ; Tue, 17 Jun 2003 10:01:50 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5HE1M330292 for simple-archive@odin.ietf.org; Tue, 17 Jun 2003 10:01:22 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5HE1Mm30289 for ; Tue, 17 Jun 2003 10:01:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16277; Tue, 17 Jun 2003 10:01:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SGzG-0007L8-00; Tue, 17 Jun 2003 09:59:02 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19SGzG-0007L3-00; Tue, 17 Jun 2003 09:59:02 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5H9M1a10031; Tue, 17 Jun 2003 05:22:01 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5H9Ljm10008 for ; Tue, 17 Jun 2003 05:21: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 FAA04513 for ; Tue, 17 Jun 2003 05:21:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SCch-0004Kk-00 for simple@ietf.org; Tue, 17 Jun 2003 05:19:27 -0400 Received: from igate2.vodafone.co.uk ([194.62.232.66]) by ietf-mx with esmtp (Exim 4.12) id 19SCcg-0004KH-00 for simple@ietf.org; Tue, 17 Jun 2003 05:19:26 -0400 Received: by igate2.vodafone.co.uk; (8.8.8/1.3/10May95) id KAA23581; Tue, 17 Jun 2003 10:21:12 +0100 (BST) Received: from ukwmxc02.vf-uk.internal.vodafone.com (ukwmxc02 [10.33.126.170]) by mailguard2 (4.6.1.123) with ESMTP id for ; Tue, 17 Jun 2003 10:18:27 +0100 Received: from ukwmxc04.vf-uk.internal.vodafone.com ([10.33.126.173]) by ukwmxc02.vf-uk.internal.vodafone.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 17 Jun 2003 10:20:19 +0100 Received: from ukwmxm02.vf-uk.internal.vodafone.com ([10.33.126.242]) by ukwmxc04.vf-uk.internal.vodafone.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 17 Jun 2003 10:20:19 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message Message-ID: Thread-Topic: Question on draft-ietf-simple-winfo-package-05 Thread-Index: AcM0sTj12mYLQ+ZPSCKk8P8Zor61MA== From: "Mills, Duncan, D, CND Tech Dev, VF UK" To: X-OriginalArrivalTime: 17 Jun 2003 09:20:19.0340 (UTC) FILETIME=[ABD7ACC0:01C334B1] MIME-Version: 1.0 (Generated by Clearswift ES version 4.6.1.122) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5H9Ljm10010 Subject: [Simple] Question on draft-ietf-simple-winfo-package-05 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, 17 Jun 2003 10:20:18 +0100 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi, I have a question on the above internet-draft: In section 5, "example usage," we see Joe subscribing to his own 'presence.winfo' event. Then we see another user, A@example.com trying to SUBSCRIBE to Joe's presence state. Joe is sent a NOTIFY request to tell him that a subscription is pending. Joe responds to this with a 200 OK. The draft then says that "Joe then authorizes A's subscription through some means." Can someone give me an example of how Joe authorises A's subscription? Is there no possibility to allow the 200 OK to carry the authorisation, implicit or otherwise? Regards, Duncan Duncan Mills Senior Engineer Network Standards & Technical Audit Technology Development (Network Systems) Vodafone (UK) Ltd Tel: +44 (0)1635 676074 Mob: +44 7867 900955 Fax: +44 (0)1635 234445 mailto:duncan.mills@vf.vodafone.co.uk _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Jun 17 11:48:53 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 LAA23532; Tue, 17 Jun 2003 11:48:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SIfN-000120-00; Tue, 17 Jun 2003 11:46:37 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19SIfM-00011w-00; Tue, 17 Jun 2003 11:46:36 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5H8g0a07056; Tue, 17 Jun 2003 04:42:00 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5H8fbm07007 for ; Tue, 17 Jun 2003 04:41: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 EAA03845 for ; Tue, 17 Jun 2003 04:41:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SBzr-00048j-00 for simple@ietf.org; Tue, 17 Jun 2003 04:39:19 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19SBzq-00048d-00 for simple@ietf.org; Tue, 17 Jun 2003 04:39:18 -0400 Received: from dynamicsoft.com ([63.113.46.81]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h5H8f6sm002519; Tue, 17 Jun 2003 04:41:06 -0400 (EDT) Message-ID: <3EEED41F.5040403@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Sparks CC: Orly Rosenberg , "'simple@ietf.org'" Subject: Re: [Simple] Request-URI is identity of the Presentity References: <1055777736.923.57.camel@RjS.localdomain> In-Reply-To: <1055777736.923.57.camel@RjS.localdomain> 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, 17 Jun 2003 04:41:03 -0400 Content-Transfer-Encoding: 7bit I don't think you can change the request-URI after the dialog is established. Thats because the route-set will determine what the r-uri looks like when it hits the UAS. Assuming everyone is a loose router, it means that the request URI at the UAS will be the Contact that the UA had placed in its 200 OK to the initial SUBSCRIBE. The notifier can change this, but the subscriber can't go and pick a new URI. -Jonathan R. Robert Sparks wrote: > Are you objecting to the possibility of having to maintain state > for more than one subscription sharing the same dialog identifiers > (To/From tags, Call-ID)? > > That's something you have to handle even if the Request-URI doesn't > change. You can have subscriptions to different events reusing > those identifiers (Event: presence, Event: presence.winfo, > Event: refer). Within a package, you can have different subscriptions > using the same dialog identifier differentiated by the "id" parameter > on the Event header field value. > > If not, and it really is the potential for a changing Request-URI that's > bothering you, can you sketch a scenario where that would (without > violating protocol) happen and a problem results? > > RjS > > > On Sun, 2003-06-15 at 02:09, Orly Rosenberg wrote: > >>Hi. >>In draft-ietf-simple-presence-10 it is defined that the Request-URI >>identifies the desired Presentity in a Subscribe request. This is also >>defined in RFC 3265 ("The Request-URI of a Subscribe request ..... It also >>contains enough information to identify the resource for which event >>notification is desired ..."). >>Since the Subscribe request is defined as a dialog-creating method, the >>Request-URI is not one of its identifiers. I think that the result is that >>two Subscribe requests with different Request-URIs can be handled by the >>same dialog, where they represent different Presentities. >>Isn't this a problem? >>Thanks, >>Orly. >>_______________________________________________ >>Simple mailing list >>Simple@ietf.org >>https://www1.ietf.org/mailman/listinfo/simple > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Scientist 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 mailnull@www1.ietf.org Tue Jun 17 11:49:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23569 for ; Tue, 17 Jun 2003 11:49:24 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5HFmuF07148 for simple-archive@odin.ietf.org; Tue, 17 Jun 2003 11:48:56 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5HFmum07145 for ; Tue, 17 Jun 2003 11:48:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23532; Tue, 17 Jun 2003 11:48:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SIfN-000120-00; Tue, 17 Jun 2003 11:46:37 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19SIfM-00011w-00; Tue, 17 Jun 2003 11:46:36 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5H8g0a07056; Tue, 17 Jun 2003 04:42:00 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5H8fbm07007 for ; Tue, 17 Jun 2003 04:41: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 EAA03845 for ; Tue, 17 Jun 2003 04:41:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SBzr-00048j-00 for simple@ietf.org; Tue, 17 Jun 2003 04:39:19 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19SBzq-00048d-00 for simple@ietf.org; Tue, 17 Jun 2003 04:39:18 -0400 Received: from dynamicsoft.com ([63.113.46.81]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h5H8f6sm002519; Tue, 17 Jun 2003 04:41:06 -0400 (EDT) Message-ID: <3EEED41F.5040403@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Sparks CC: Orly Rosenberg , "'simple@ietf.org'" Subject: Re: [Simple] Request-URI is identity of the Presentity References: <1055777736.923.57.camel@RjS.localdomain> In-Reply-To: <1055777736.923.57.camel@RjS.localdomain> 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, 17 Jun 2003 04:41:03 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I don't think you can change the request-URI after the dialog is established. Thats because the route-set will determine what the r-uri looks like when it hits the UAS. Assuming everyone is a loose router, it means that the request URI at the UAS will be the Contact that the UA had placed in its 200 OK to the initial SUBSCRIBE. The notifier can change this, but the subscriber can't go and pick a new URI. -Jonathan R. Robert Sparks wrote: > Are you objecting to the possibility of having to maintain state > for more than one subscription sharing the same dialog identifiers > (To/From tags, Call-ID)? > > That's something you have to handle even if the Request-URI doesn't > change. You can have subscriptions to different events reusing > those identifiers (Event: presence, Event: presence.winfo, > Event: refer). Within a package, you can have different subscriptions > using the same dialog identifier differentiated by the "id" parameter > on the Event header field value. > > If not, and it really is the potential for a changing Request-URI that's > bothering you, can you sketch a scenario where that would (without > violating protocol) happen and a problem results? > > RjS > > > On Sun, 2003-06-15 at 02:09, Orly Rosenberg wrote: > >>Hi. >>In draft-ietf-simple-presence-10 it is defined that the Request-URI >>identifies the desired Presentity in a Subscribe request. This is also >>defined in RFC 3265 ("The Request-URI of a Subscribe request ..... It also >>contains enough information to identify the resource for which event >>notification is desired ..."). >>Since the Subscribe request is defined as a dialog-creating method, the >>Request-URI is not one of its identifiers. I think that the result is that >>two Subscribe requests with different Request-URIs can be handled by the >>same dialog, where they represent different Presentities. >>Isn't this a problem? >>Thanks, >>Orly. >>_______________________________________________ >>Simple mailing list >>Simple@ietf.org >>https://www1.ietf.org/mailman/listinfo/simple > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Scientist 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 Jun 17 14:03:28 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 OAA28832; Tue, 17 Jun 2003 14:03:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SKlb-0002NI-00; Tue, 17 Jun 2003 14:01:11 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19SKla-0002NF-00; Tue, 17 Jun 2003 14:01:10 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5HEA1a31680; Tue, 17 Jun 2003 10:10:01 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5HE92m31625 for ; Tue, 17 Jun 2003 10:09:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17237 for ; Tue, 17 Jun 2003 10:08:59 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SH6h-0007RR-00 for simple@ietf.org; Tue, 17 Jun 2003 10:06:43 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19SH6g-0007Qt-00 for simple@ietf.org; Tue, 17 Jun 2003 10:06:42 -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 h5HE7oa08984 for ; Tue, 17 Jun 2003 17:07:50 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 17 Jun 2003 17:07:41 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 17 Jun 2003 17:07:41 +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" Subject: RE: [Simple] Question on draft-ietf-simple-winfo-package-05 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701796DE9@esebe019.ntc.nokia.com> Thread-Topic: Question on draft-ietf-simple-winfo-package-05 Thread-Index: AcM0sTj12mYLQ+ZPSCKk8P8Zor61MAAKA9uA To: , X-OriginalArrivalTime: 17 Jun 2003 14:07:41.0453 (UTC) FILETIME=[D0F153D0:01C334D9] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5HE92m31626 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, 17 Jun 2003 17:07:40 +0300 Content-Transfer-Encoding: 8bit This is an on going work in the SIMPLE WG. Take a look at the requirements: http://www.ietf.org/internet-drafts/draft-ietf-simple-data-req-02.txt And the proposed solution: http://www.jdrosen.net/papers/draft-rosenberg-simple-xcap-00.txt http://www.jdrosen.net/papers/draft-rosenberg-simple-xcap-package-00.txt http://www.jdrosen.net/papers/draft-rosenberg-simple-xcap-list-usage-00.txt Authorisation list usage should be published soon by Jonathan Rosenberg. Regards, Hisham > -----Original Message----- > From: ext Mills, Duncan, D, CND Tech Dev, VF UK > [mailto:Duncan.Mills@gb.vodafone.co.uk] > Sent: Tuesday, June 17, 2003 12:20 PM > To: simple@ietf.org > Subject: [Simple] Question on draft-ietf-simple-winfo-package-05 > > > Hi, > > I have a question on the above internet-draft: > > In section 5, "example usage," we see Joe subscribing to his > own 'presence.winfo' event. Then we see another user, > A@example.com trying to SUBSCRIBE to Joe's presence state. > Joe is sent a NOTIFY request to tell him that a subscription > is pending. Joe responds to this with a 200 OK. > > The draft then says that "Joe then authorizes A's > subscription through some means." > > Can someone give me an example of how Joe authorises A's subscription? > > Is there no possibility to allow the 200 OK to carry the > authorisation, implicit or otherwise? > > Regards, > > Duncan > > > > Duncan Mills > Senior Engineer > Network Standards & Technical Audit > Technology Development (Network Systems) > Vodafone (UK) Ltd > Tel: +44 (0)1635 676074 > Mob: +44 7867 900955 > Fax: +44 (0)1635 234445 > mailto:duncan.mills@vf.vodafone.co.uk > > > _______________________________________________ > Simple mailing 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 Jun 17 14:15:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29865 for ; Tue, 17 Jun 2003 14:15:54 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5HIFPb12769 for simple-archive@odin.ietf.org; Tue, 17 Jun 2003 14:15:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SKnr-00023J-MR for simple-web-archive@optimus.ietf.org; Tue, 17 Jun 2003 14:03:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28832; Tue, 17 Jun 2003 14:03:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SKlb-0002NI-00; Tue, 17 Jun 2003 14:01:11 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19SKla-0002NF-00; Tue, 17 Jun 2003 14:01:10 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5HEA1a31680; Tue, 17 Jun 2003 10:10:01 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5HE92m31625 for ; Tue, 17 Jun 2003 10:09:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17237 for ; Tue, 17 Jun 2003 10:08:59 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SH6h-0007RR-00 for simple@ietf.org; Tue, 17 Jun 2003 10:06:43 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19SH6g-0007Qt-00 for simple@ietf.org; Tue, 17 Jun 2003 10:06:42 -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 h5HE7oa08984 for ; Tue, 17 Jun 2003 17:07:50 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 17 Jun 2003 17:07:41 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 17 Jun 2003 17:07:41 +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" Subject: RE: [Simple] Question on draft-ietf-simple-winfo-package-05 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701796DE9@esebe019.ntc.nokia.com> Thread-Topic: Question on draft-ietf-simple-winfo-package-05 Thread-Index: AcM0sTj12mYLQ+ZPSCKk8P8Zor61MAAKA9uA To: , X-OriginalArrivalTime: 17 Jun 2003 14:07:41.0453 (UTC) FILETIME=[D0F153D0:01C334D9] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5HE92m31626 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, 17 Jun 2003 17:07:40 +0300 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit This is an on going work in the SIMPLE WG. Take a look at the requirements: http://www.ietf.org/internet-drafts/draft-ietf-simple-data-req-02.txt And the proposed solution: http://www.jdrosen.net/papers/draft-rosenberg-simple-xcap-00.txt http://www.jdrosen.net/papers/draft-rosenberg-simple-xcap-package-00.txt http://www.jdrosen.net/papers/draft-rosenberg-simple-xcap-list-usage-00.txt Authorisation list usage should be published soon by Jonathan Rosenberg. Regards, Hisham > -----Original Message----- > From: ext Mills, Duncan, D, CND Tech Dev, VF UK > [mailto:Duncan.Mills@gb.vodafone.co.uk] > Sent: Tuesday, June 17, 2003 12:20 PM > To: simple@ietf.org > Subject: [Simple] Question on draft-ietf-simple-winfo-package-05 > > > Hi, > > I have a question on the above internet-draft: > > In section 5, "example usage," we see Joe subscribing to his > own 'presence.winfo' event. Then we see another user, > A@example.com trying to SUBSCRIBE to Joe's presence state. > Joe is sent a NOTIFY request to tell him that a subscription > is pending. Joe responds to this with a 200 OK. > > The draft then says that "Joe then authorizes A's > subscription through some means." > > Can someone give me an example of how Joe authorises A's subscription? > > Is there no possibility to allow the 200 OK to carry the > authorisation, implicit or otherwise? > > Regards, > > Duncan > > > > Duncan Mills > Senior Engineer > Network Standards & Technical Audit > Technology Development (Network Systems) > Vodafone (UK) Ltd > Tel: +44 (0)1635 676074 > Mob: +44 7867 900955 > Fax: +44 (0)1635 234445 > mailto:duncan.mills@vf.vodafone.co.uk > > > _______________________________________________ > Simple mailing 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 Jun 17 15:52:17 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 PAA07951; Tue, 17 Jun 2003 15:52:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SMSv-0004HB-00; Tue, 17 Jun 2003 15:50:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19SMSu-0004H8-00; Tue, 17 Jun 2003 15:50:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SMQ4-00064Q-0b; Tue, 17 Jun 2003 15:47:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SMIY-00045w-EK for simple@optimus.ietf.org; Tue, 17 Jun 2003 15:39:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06718 for ; Tue, 17 Jun 2003 15:39:16 -0400 (EDT) From: AndrewAllen007@aol.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SMGK-00040f-00 for simple@ietf.org; Tue, 17 Jun 2003 15:37:00 -0400 Received: from imo-m08.mx.aol.com ([64.12.136.163]) by ietf-mx with esmtp (Exim 4.12) id 19SMGJ-00040Q-00 for simple@ietf.org; Tue, 17 Jun 2003 15:36:59 -0400 Received: from AndrewAllen007@aol.com by imo-m08.mx.aol.com (mail_out_v36.3.) id z.11d.234969fd (16098); Tue, 17 Jun 2003 15:38:40 -0400 (EDT) Received: from aol.com (mow-m10.webmail.aol.com [64.12.184.138]) by air-id11.mx.aol.com (v93.13) with ESMTP id MAILINID112-3ee23eef6e4021a; Tue, 17 Jun 2003 15:38:40 -0400 To: Duncan.Mills@gb.vodafone.co.uk Cc: simple@ietf.org, AndrewAllen007@aol.com Subject: Re: [Simple] Question on draft-ietf-simple-winfo-package-05 MIME-Version: 1.0 Message-ID: <1BDD6A0E.213E25E0.2E6F5200@aol.com> X-Mailer: Atlas Mailer 2.0 Content-Type: text/plain; charset=utf-8 X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id PAA06719 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, 17 Jun 2003 15:38:40 -0400 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA07951 Duncan, My understanding is that the currently proposed means for modification of the authorization policy (including in response to a pending subscription) is XCAP (draft-rosenberg-simple-xcap). The XCAP proposal is for a set of conventions for using HTTP to read, write and modify the data stored on the server (including the authorization policy document). The 200 OK to the Notify acknowledges that the Notify was received and processed by the UA. Authorization will likely require human intervention and may take place some minutes or even hours after the notification is received, if at all. The authorization policy may be considerably more complex than authorized or not authorized. There may be some data that is to be set to false indications (e.g. IF “at lunch” THEN show “in a meeting”) and other presence information that is to be completely hidden from the subscriber even though the subscription is accepted. Authorizing the subscriber requires a modification to the authorization policy document. For these reasons alone “piggy backing” the authorization on the 200 OK would not be suitable. Regards Andrew _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Jun 17 16:00:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08215 for ; Tue, 17 Jun 2003 16:00:26 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5HJxvx25542 for simple-archive@odin.ietf.org; Tue, 17 Jun 2003 15:59:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SMV9-0006RK-DW for simple-web-archive@optimus.ietf.org; Tue, 17 Jun 2003 15:52: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 PAA07951; Tue, 17 Jun 2003 15:52:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SMSv-0004HB-00; Tue, 17 Jun 2003 15:50:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19SMSu-0004H8-00; Tue, 17 Jun 2003 15:50:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SMQ4-00064Q-0b; Tue, 17 Jun 2003 15:47:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SMIY-00045w-EK for simple@optimus.ietf.org; Tue, 17 Jun 2003 15:39:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06718 for ; Tue, 17 Jun 2003 15:39:16 -0400 (EDT) From: AndrewAllen007@aol.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SMGK-00040f-00 for simple@ietf.org; Tue, 17 Jun 2003 15:37:00 -0400 Received: from imo-m08.mx.aol.com ([64.12.136.163]) by ietf-mx with esmtp (Exim 4.12) id 19SMGJ-00040Q-00 for simple@ietf.org; Tue, 17 Jun 2003 15:36:59 -0400 Received: from AndrewAllen007@aol.com by imo-m08.mx.aol.com (mail_out_v36.3.) id z.11d.234969fd (16098); Tue, 17 Jun 2003 15:38:40 -0400 (EDT) Received: from aol.com (mow-m10.webmail.aol.com [64.12.184.138]) by air-id11.mx.aol.com (v93.13) with ESMTP id MAILINID112-3ee23eef6e4021a; Tue, 17 Jun 2003 15:38:40 -0400 To: Duncan.Mills@gb.vodafone.co.uk Cc: simple@ietf.org, AndrewAllen007@aol.com Subject: Re: [Simple] Question on draft-ietf-simple-winfo-package-05 MIME-Version: 1.0 Message-ID: <1BDD6A0E.213E25E0.2E6F5200@aol.com> X-Mailer: Atlas Mailer 2.0 Content-Type: text/plain; charset=utf-8 X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id PAA06719 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, 17 Jun 2003 15:38:40 -0400 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA08215 Duncan, My understanding is that the currently proposed means for modification of the authorization policy (including in response to a pending subscription) is XCAP (draft-rosenberg-simple-xcap). The XCAP proposal is for a set of conventions for using HTTP to read, write and modify the data stored on the server (including the authorization policy document). The 200 OK to the Notify acknowledges that the Notify was received and processed by the UA. Authorization will likely require human intervention and may take place some minutes or even hours after the notification is received, if at all. The authorization policy may be considerably more complex than authorized or not authorized. There may be some data that is to be set to false indications (e.g. IF “at lunch” THEN show “in a meeting”) and other presence information that is to be completely hidden from the subscriber even though the subscription is accepted. Authorizing the subscriber requires a modification to the authorization policy document. For these reasons alone “piggy backing” the authorization on the 200 OK would not be suitable. Regards Andrew _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Jun 18 04:20: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 EAA23556; Wed, 18 Jun 2003 04:20:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SY8Y-0001Fy-00; Wed, 18 Jun 2003 04:17:46 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19SY8Y-0001Fv-00; Wed, 18 Jun 2003 04:17:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SYAi-0005m2-Sx; Wed, 18 Jun 2003 04:20:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SYAH-0005lO-V6 for simple@optimus.ietf.org; Wed, 18 Jun 2003 04:19:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23543 for ; Wed, 18 Jun 2003 04:19:31 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SY81-0001Fj-00 for simple@ietf.org; Wed, 18 Jun 2003 04:17:13 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19SY81-0001Fg-00 for simple@ietf.org; Wed, 18 Jun 2003 04:17:13 -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 h5I8JTa03745 for ; Wed, 18 Jun 2003 11:19:29 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 18 Jun 2003 11:19:29 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 18 Jun 2003 11:19:28 +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" Subject: RE: [Simple] Thoughts on XCAP Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701796DF3@esebe019.ntc.nokia.com> Thread-Topic: [Simple] Thoughts on XCAP Thread-Index: AcMyOKW+i8jNRlgHQAmMFKij84U+FQDOJ/Mg To: , Cc: X-OriginalArrivalTime: 18 Jun 2003 08:19:28.0401 (UTC) FILETIME=[56205810:01C33572] 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, 18 Jun 2003 11:19:27 +0300 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA23556 Hi, First of all, I don't like the idea of creating a new port for XCAP and defining it as a new protocol. To speed up the development and adoption of Data Manipulation (and potentially Conference Control), we need to be able to reuse existing HTTP stacks, for both client and server. It isn't enough to consider only the existing server side support for Webdav. Client side support is equally (if not more) important and probably more scarce. What about not doing batching at all? Could that be an option. In practise: o 1# We would have only have independent operations - no MOVE. For example, if you wanted to move a buddy from "public" authorization list to "friends", you could first ADD to friends, then delete from public. The question is: does this introduce an inconsistent state for authorization that would require locking the document in between the operations? Any other scenario that would? o #2 If operations are such that they leave the document in an inconsistent state, you would do a highest common element replacement. This means going towards the root element of the document until reaching a node under which all of these operations were performed - then replacing the entire sub-tree. In a worst case scenario, you would end up replacing the entire document. o #3 No batching of multiple requests. How often would you do off-line edits to authorization lists, presence-lists etc., where #2 would not be an option? So I would still like to revisit our original requirements in order to see if we really need to go beyond the HTTP semantics, e.g., WebDav style locks etc. Regards, Hisham > -----Original Message----- > From: ext hardie@qualcomm.com [mailto:hardie@qualcomm.com] > Sent: Saturday, June 14, 2003 2:45 AM > To: simple@ietf.org > Subject: [Simple] Thoughts on XCAP > > > Howdy folks, > As you know from recent traffic on the list, there was an > agreement at the Interim Meeting to accept the XCAP docs as working > group drafts. After that was announced to the working group, Jonathan > asked me to take a look at them to see if there were any gotchas > likely on the use of HTTP, XPATH, and the other components of the > proposal. > After reading the core doc and re-reading the XPATH doc, > Jonathan, Jon, and I had a phone call earlier today to discuss the > proposals and to talk about the conversation around this proposal that > happened at the Interim. First, let me say that I understand the > approach of the group is to define a set of schemas which allows the > manipulation of this data, but that the group intends that the data > manipulation and transport will be out-of-band to SIMPLE itself. > Second, let me say that I am very happy to see energy in the group > around solving this problem, and I appreciate the work that has gone > into hammering on this solution. Last, let me say that I think the > XCAP docs provide a foundation for work that the working group can > take forward if this is the consensus of the group. > There are, however, some issues that I would like to ask the > working group to consider. First, the IETF has in the past asked > working groups re-using HTTP to be very careful that the semantics of > their use fit within the semantics of HTTP (It has in particular asked > working groups to be very careful about using "POST" as an operator to > extend the semantics of HTTP). Where a re-use of HTTP extended or > restricted the semantics of HTTP, the IETF has asked that the group > create a new uri scheme, select a new port, and describe the protocol > in full. The Internet Printing Protocol (IPP) and WebDav are both > cases where this has occurred. > As I read the documents at the moment, I believe that XCAP > would fall in to this category; right now it is sufficiently different > from the basic semantics of HTTP that it would require full > specification, and would likely need to shift some of the "POST"-based > semantics to other methods. While I don't think this a bad idea > (indeed, I suspect the resulting protocol would see reuse almost > immediately), it is likely to take time and effort. It may also > require some expertise from those who are not currently core > participants in the SIMPLE effort. I can work with the chairs to > help identify those resources, if required. > Both Jon and Jonathan have expressed concern that taking the > XCAP documents down that road would take more time than is practical > for SIMPLE. While no one really wants to re-visit a decision that has > already been made, I wanted to make sure the working group understands > the type of output that would likely be expected for XCAP. I > certainly don't want to do anything that dims the energy of the group, > though, and I'm sure we would all like to find a way forward which > minimizes delay. In the call today, Jon, Jonathan, and I brainstormed > a bit on the roads forward, and I'd like to share my view of them > below. I believe Jonathan will also be sending his view. > > 1) Continue work on XCAP with the current set of requirements as a > guide. With a strong design team in place, work to complete a > spec which is fully functional for SIMPLE's needs and is either > sufficiently general or extensible that it can be used by other > likely consumers of an XML-based data manipulation and update > protocol. Four to six months would be the most > optimistic imaginable > timeframe for this, and it might be much longer. > > 2) Shift the XCAP framework so that it fits fully within the semantics > of HTPP. This likely would involve paring some requirements, > since locking would not be enabled. Depending on the extent > to which XPATH-based URIs were supported, this might or might > force the fundamental unit of manipulation to always be the > full list, which could have an impact on wireless users. > > 3) Shift the model so that the individual elements are > seen as collection members with specific attributes, and re-use > WebDav's locking and methods to accomplish the manipulation of > the components. This may constrain implementations in ways that > reduce efficiency for some operations. > > It is unfortunate that there is no easier answer here; each > has an engineering trade-off that requires either a shift in the > requirements, the view of the components, or the scope of the effort. > As the working group considers these documents and this requirement, I > would appreciate you considering each of these trade-offs and sharing > with the group your view and other considerations which occur to you. > > thanks, > Ted Hardie > > > _______________________________________________ > Simple mailing 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 Wed Jun 18 04:20:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23593 for ; Wed, 18 Jun 2003 04:20:35 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5I8K7g22238 for simple-archive@odin.ietf.org; Wed, 18 Jun 2003 04:20:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SYAp-0005mb-4b for simple-web-archive@optimus.ietf.org; Wed, 18 Jun 2003 04:20: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 EAA23556; Wed, 18 Jun 2003 04:20:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SY8Y-0001Fy-00; Wed, 18 Jun 2003 04:17:46 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19SY8Y-0001Fv-00; Wed, 18 Jun 2003 04:17:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SYAi-0005m2-Sx; Wed, 18 Jun 2003 04:20:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SYAH-0005lO-V6 for simple@optimus.ietf.org; Wed, 18 Jun 2003 04:19:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23543 for ; Wed, 18 Jun 2003 04:19:31 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SY81-0001Fj-00 for simple@ietf.org; Wed, 18 Jun 2003 04:17:13 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19SY81-0001Fg-00 for simple@ietf.org; Wed, 18 Jun 2003 04:17:13 -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 h5I8JTa03745 for ; Wed, 18 Jun 2003 11:19:29 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 18 Jun 2003 11:19:29 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 18 Jun 2003 11:19:28 +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" Subject: RE: [Simple] Thoughts on XCAP Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701796DF3@esebe019.ntc.nokia.com> Thread-Topic: [Simple] Thoughts on XCAP Thread-Index: AcMyOKW+i8jNRlgHQAmMFKij84U+FQDOJ/Mg To: , Cc: X-OriginalArrivalTime: 18 Jun 2003 08:19:28.0401 (UTC) FILETIME=[56205810:01C33572] 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, 18 Jun 2003 11:19:27 +0300 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA23593 Hi, First of all, I don't like the idea of creating a new port for XCAP and defining it as a new protocol. To speed up the development and adoption of Data Manipulation (and potentially Conference Control), we need to be able to reuse existing HTTP stacks, for both client and server. It isn't enough to consider only the existing server side support for Webdav. Client side support is equally (if not more) important and probably more scarce. What about not doing batching at all? Could that be an option. In practise: o 1# We would have only have independent operations - no MOVE. For example, if you wanted to move a buddy from "public" authorization list to "friends", you could first ADD to friends, then delete from public. The question is: does this introduce an inconsistent state for authorization that would require locking the document in between the operations? Any other scenario that would? o #2 If operations are such that they leave the document in an inconsistent state, you would do a highest common element replacement. This means going towards the root element of the document until reaching a node under which all of these operations were performed - then replacing the entire sub-tree. In a worst case scenario, you would end up replacing the entire document. o #3 No batching of multiple requests. How often would you do off-line edits to authorization lists, presence-lists etc., where #2 would not be an option? So I would still like to revisit our original requirements in order to see if we really need to go beyond the HTTP semantics, e.g., WebDav style locks etc. Regards, Hisham > -----Original Message----- > From: ext hardie@qualcomm.com [mailto:hardie@qualcomm.com] > Sent: Saturday, June 14, 2003 2:45 AM > To: simple@ietf.org > Subject: [Simple] Thoughts on XCAP > > > Howdy folks, > As you know from recent traffic on the list, there was an > agreement at the Interim Meeting to accept the XCAP docs as working > group drafts. After that was announced to the working group, Jonathan > asked me to take a look at them to see if there were any gotchas > likely on the use of HTTP, XPATH, and the other components of the > proposal. > After reading the core doc and re-reading the XPATH doc, > Jonathan, Jon, and I had a phone call earlier today to discuss the > proposals and to talk about the conversation around this proposal that > happened at the Interim. First, let me say that I understand the > approach of the group is to define a set of schemas which allows the > manipulation of this data, but that the group intends that the data > manipulation and transport will be out-of-band to SIMPLE itself. > Second, let me say that I am very happy to see energy in the group > around solving this problem, and I appreciate the work that has gone > into hammering on this solution. Last, let me say that I think the > XCAP docs provide a foundation for work that the working group can > take forward if this is the consensus of the group. > There are, however, some issues that I would like to ask the > working group to consider. First, the IETF has in the past asked > working groups re-using HTTP to be very careful that the semantics of > their use fit within the semantics of HTTP (It has in particular asked > working groups to be very careful about using "POST" as an operator to > extend the semantics of HTTP). Where a re-use of HTTP extended or > restricted the semantics of HTTP, the IETF has asked that the group > create a new uri scheme, select a new port, and describe the protocol > in full. The Internet Printing Protocol (IPP) and WebDav are both > cases where this has occurred. > As I read the documents at the moment, I believe that XCAP > would fall in to this category; right now it is sufficiently different > from the basic semantics of HTTP that it would require full > specification, and would likely need to shift some of the "POST"-based > semantics to other methods. While I don't think this a bad idea > (indeed, I suspect the resulting protocol would see reuse almost > immediately), it is likely to take time and effort. It may also > require some expertise from those who are not currently core > participants in the SIMPLE effort. I can work with the chairs to > help identify those resources, if required. > Both Jon and Jonathan have expressed concern that taking the > XCAP documents down that road would take more time than is practical > for SIMPLE. While no one really wants to re-visit a decision that has > already been made, I wanted to make sure the working group understands > the type of output that would likely be expected for XCAP. I > certainly don't want to do anything that dims the energy of the group, > though, and I'm sure we would all like to find a way forward which > minimizes delay. In the call today, Jon, Jonathan, and I brainstormed > a bit on the roads forward, and I'd like to share my view of them > below. I believe Jonathan will also be sending his view. > > 1) Continue work on XCAP with the current set of requirements as a > guide. With a strong design team in place, work to complete a > spec which is fully functional for SIMPLE's needs and is either > sufficiently general or extensible that it can be used by other > likely consumers of an XML-based data manipulation and update > protocol. Four to six months would be the most > optimistic imaginable > timeframe for this, and it might be much longer. > > 2) Shift the XCAP framework so that it fits fully within the semantics > of HTPP. This likely would involve paring some requirements, > since locking would not be enabled. Depending on the extent > to which XPATH-based URIs were supported, this might or might > force the fundamental unit of manipulation to always be the > full list, which could have an impact on wireless users. > > 3) Shift the model so that the individual elements are > seen as collection members with specific attributes, and re-use > WebDav's locking and methods to accomplish the manipulation of > the components. This may constrain implementations in ways that > reduce efficiency for some operations. > > It is unfortunate that there is no easier answer here; each > has an engineering trade-off that requires either a shift in the > requirements, the view of the components, or the scope of the effort. > As the working group considers these documents and this requirement, I > would appreciate you considering each of these trade-offs and sharing > with the group your view and other considerations which occur to you. > > thanks, > Ted Hardie > > > _______________________________________________ > Simple mailing 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 Wed Jun 18 14:16: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 OAA19484; Wed, 18 Jun 2003 14:16:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ShRH-0007cn-00; Wed, 18 Jun 2003 14:13:43 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ShRG-0007cf-00; Wed, 18 Jun 2003 14:13:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Sgmw-0004JL-Sd; Wed, 18 Jun 2003 13:32:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SgIt-0002uC-Mo for simple@optimus.ietf.org; Wed, 18 Jun 2003 13:00: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 NAA16196 for ; Wed, 18 Jun 2003 13:00:56 -0400 (EDT) From: hardie@qualcomm.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SgGc-0006ii-00 for simple@ietf.org; Wed, 18 Jun 2003 12:58:38 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx with esmtp (Exim 4.12) id 19SgGT-0006iR-00 for simple@ietf.org; Wed, 18 Jun 2003 12:58:29 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h5IH0jBd014457 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 18 Jun 2003 10:00:46 -0700 (PDT) Received: from [129.46.74.110] (carbuncle.qualcomm.com [129.46.74.110]) by neophyte.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h5IH0huh018900; Wed, 18 Jun 2003 10:00:44 -0700 (PDT) Mime-Version: 1.0 X-Sender: hardie@mage.qualcomm.com Message-Id: In-Reply-To: <03c501c335b0$f40e4d00$fdcb90c6@lisalap> References: <03c501c335b0$f40e4d00$fdcb90c6@lisalap> To: "Lisa Dusseault" , , Subject: RE: [Simple] Thoughts on XCAP 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: Wed, 18 Jun 2003 10:00:44 -0700 At 8:47 AM -0700 6/18/03, Lisa Dusseault wrote: > >Not sure if we're all clear on this but the semantics of WebDAV MOVE is to >move a whole document from one URL to another (perhaps overwriting an >existing document at the target URL). The command does not have the >semantics of moving only partial information from one document to another. >Neither does WebDAV have the ability to ADD only partial information to the >body of a document although with PROPPATCH it may add/modify a single >property on an existing document's metadata. "Whole document", however, can also be read as "atomic resource", and that gives some flexibility. If you treat the "buddy list" as a collection of buddy resources, then the individual buddy resources are atomic resources and a MOVE can be applied to them. Theoretically, you could also treat each of the buddy resources as a collection of attribute resources, so that you could move them, update them, or change the metadata on them as atomic resources. (Henning made some comments along these lines a week or so ago). The balance here is between how much work the server goes through to manage elements of the buddy lists (buddy resources, attributes) and how much work it goes through to (possibly assemble from parts and then) return the list. Which one the group optimizes needs to depend both on the capabilities of the users and on the perceived rate of the action. Downloading a buddy list, making a change, and uploading is expensive to a wireless client, but if it is a once-a-month thing, jumping through hoops to make it possible to work on elements of the list is a waste. If it is three times a day, it may be critical. In general, the right balance there will also depend on how much the requirement is to update and modify hierarchically structured uniquely named resources (which can be mapped in both XML and WebDav pretty easily) and how much it needs to handle arbitrary XML structures. The latter will definitely restrict how well Dav can be used (either directly or as a model) regards, Ted Hardie _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Jun 18 14:41:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20504 for ; Wed, 18 Jun 2003 14:41:34 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5IIf7l30002 for simple-archive@odin.ietf.org; Wed, 18 Jun 2003 14:41:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ShTZ-0006dJ-IC for simple-web-archive@optimus.ietf.org; Wed, 18 Jun 2003 14:16: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 OAA19484; Wed, 18 Jun 2003 14:16:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ShRH-0007cn-00; Wed, 18 Jun 2003 14:13:43 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ShRG-0007cf-00; Wed, 18 Jun 2003 14:13:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Sgmw-0004JL-Sd; Wed, 18 Jun 2003 13:32:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SgIt-0002uC-Mo for simple@optimus.ietf.org; Wed, 18 Jun 2003 13:00: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 NAA16196 for ; Wed, 18 Jun 2003 13:00:56 -0400 (EDT) From: hardie@qualcomm.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SgGc-0006ii-00 for simple@ietf.org; Wed, 18 Jun 2003 12:58:38 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx with esmtp (Exim 4.12) id 19SgGT-0006iR-00 for simple@ietf.org; Wed, 18 Jun 2003 12:58:29 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h5IH0jBd014457 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 18 Jun 2003 10:00:46 -0700 (PDT) Received: from [129.46.74.110] (carbuncle.qualcomm.com [129.46.74.110]) by neophyte.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h5IH0huh018900; Wed, 18 Jun 2003 10:00:44 -0700 (PDT) Mime-Version: 1.0 X-Sender: hardie@mage.qualcomm.com Message-Id: In-Reply-To: <03c501c335b0$f40e4d00$fdcb90c6@lisalap> References: <03c501c335b0$f40e4d00$fdcb90c6@lisalap> To: "Lisa Dusseault" , , Subject: RE: [Simple] Thoughts on XCAP 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: Wed, 18 Jun 2003 10:00:44 -0700 At 8:47 AM -0700 6/18/03, Lisa Dusseault wrote: > >Not sure if we're all clear on this but the semantics of WebDAV MOVE is to >move a whole document from one URL to another (perhaps overwriting an >existing document at the target URL). The command does not have the >semantics of moving only partial information from one document to another. >Neither does WebDAV have the ability to ADD only partial information to the >body of a document although with PROPPATCH it may add/modify a single >property on an existing document's metadata. "Whole document", however, can also be read as "atomic resource", and that gives some flexibility. If you treat the "buddy list" as a collection of buddy resources, then the individual buddy resources are atomic resources and a MOVE can be applied to them. Theoretically, you could also treat each of the buddy resources as a collection of attribute resources, so that you could move them, update them, or change the metadata on them as atomic resources. (Henning made some comments along these lines a week or so ago). The balance here is between how much work the server goes through to manage elements of the buddy lists (buddy resources, attributes) and how much work it goes through to (possibly assemble from parts and then) return the list. Which one the group optimizes needs to depend both on the capabilities of the users and on the perceived rate of the action. Downloading a buddy list, making a change, and uploading is expensive to a wireless client, but if it is a once-a-month thing, jumping through hoops to make it possible to work on elements of the list is a waste. If it is three times a day, it may be critical. In general, the right balance there will also depend on how much the requirement is to update and modify hierarchically structured uniquely named resources (which can be mapped in both XML and WebDav pretty easily) and how much it needs to handle arbitrary XML structures. The latter will definitely restrict how well Dav can be used (either directly or as a model) regards, Ted Hardie _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Jun 18 14:47:46 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 OAA20795; Wed, 18 Jun 2003 14:47:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Shw0-00005H-00; Wed, 18 Jun 2003 14:45:28 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Shvz-00005E-00; Wed, 18 Jun 2003 14:45:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Shiy-00077E-3d; Wed, 18 Jun 2003 14:32:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Sf9z-00089y-CO for simple@optimus.ietf.org; Wed, 18 Jun 2003 11:47: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 LAA13692 for ; Wed, 18 Jun 2003 11:47:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Sf7j-00063z-00 for simple@ietf.org; Wed, 18 Jun 2003 11:45:23 -0400 Received: from [206.14.210.116] (helo=mail.xythos.com) by ietf-mx with esmtp (Exim 4.12) id 19Sf7i-00063v-00 for simple@ietf.org; Wed, 18 Jun 2003 11:45:22 -0400 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 19Sf9w-0006Zy-00; Wed, 18 Jun 2003 15:47:40 +0000 Received: from [198.144.203.253] (helo=lisalap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 19Sf9v-0006Za-00; Wed, 18 Jun 2003 15:47:39 +0000 From: "Lisa Dusseault" To: , , Subject: RE: [Simple] Thoughts on XCAP Message-ID: <03c501c335b0$f40e4d00$fdcb90c6@lisalap> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701796DF3@esebe019.ntc.nokia.com> X-Envelope-To: hardie@qualcomm.com, hisham.khartabil@nokia.com, simple@ietf.org 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, 18 Jun 2003 08:47:41 -0700 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA20795 > It isn't enough to consider only the existing server side > support for Webdav. Client side support is equally (if not > more) important and probably more scarce. General WebDAV client availability is actually huge-- WebDAV clients now ship with every copy of Windows (since Win98) and Macs (since Mac OS X) and are freely available for Unixes. That might well help the developers of IM clients needing to save buddy lists -- the client developer might simply be able to use file system scripting or API capabilities to specify the location of the remote WebDAV server and save the buddy list there as a regular document. That approach would definitely require the buddy list to be one or more regular MIME type documents stored in a fully WebDAV-compatible collection. WebDAV client API availability is pretty good too. C and Java libraries are available free (and open source). Python 2.0 ships including WebDAV client libraries. Even with only a bare HTTP library, it's pretty easy to put together WebDAV client requests. > o 1# We would have only have independent operations - no > MOVE. For example, if you wanted to move a buddy from > "public" authorization list to "friends", you could first ADD > to friends, then delete from public. The question is: does > this introduce an inconsistent state for authorization that > would require locking the document in between the operations? > Any other scenario that would? Not sure if we're all clear on this but the semantics of WebDAV MOVE is to move a whole document from one URL to another (perhaps overwriting an existing document at the target URL). The command does not have the semantics of moving only partial information from one document to another. Neither does WebDAV have the ability to ADD only partial information to the body of a document although with PROPPATCH it may add/modify a single property on an existing document's metadata. > > o #2 If operations are such that they leave the document in > an inconsistent state, you would do a highest common element > replacement. This means going towards the root element of the > document until reaching a node under which all of these > operations were performed - then replacing the entire > sub-tree. In a worst case scenario, you would end up > replacing the entire document. > > o #3 No batching of multiple requests. How often would you do > off-line edits to authorization lists, presence-lists etc., > where #2 would not be an option? > > So I would still like to revisit our original requirements in > order to see if we really need to go beyond the HTTP > semantics, e.g., WebDav style locks etc. > > Regards, > Hisham > > > -----Original Message----- > > From: ext hardie@qualcomm.com [mailto:hardie@qualcomm.com] > > Sent: Saturday, June 14, 2003 2:45 AM > > To: simple@ietf.org > > Subject: [Simple] Thoughts on XCAP > > > > > > Howdy folks, > > As you know from recent traffic on the list, there was > an agreement > > at the Interim Meeting to accept the XCAP docs as working group > > drafts. After that was announced to the working group, > Jonathan asked > > me to take a look at them to see if there were any gotchas > likely on > > the use of HTTP, XPATH, and the other components of the proposal. > > After reading the core doc and re-reading the XPATH doc, > > Jonathan, Jon, and I had a phone call earlier today to discuss the > > proposals and to talk about the conversation around this > proposal that > > happened at the Interim. First, let me say that I understand the > > approach of the group is to define a set of schemas which allows the > > manipulation of this data, but that the group intends that the data > > manipulation and transport will be out-of-band to SIMPLE itself. > > Second, let me say that I am very happy to see energy in the group > > around solving this problem, and I appreciate the work that has gone > > into hammering on this solution. Last, let me say that I think the > > XCAP docs provide a foundation for work that the working group can > > take forward if this is the consensus of the group. > > There are, however, some issues that I would like to ask the > > working group to consider. First, the IETF has in the past asked > > working groups re-using HTTP to be very careful that the > semantics of > > their use fit within the semantics of HTTP (It has in > particular asked > > working groups to be very careful about using "POST" as an > operator to > > extend the semantics of HTTP). Where a re-use of HTTP extended or > > restricted the semantics of HTTP, the IETF has asked that the group > > create a new uri scheme, select a new port, and describe > the protocol > > in full. The Internet Printing Protocol (IPP) and WebDav are both > > cases where this has occurred. > > As I read the documents at the moment, I believe that XCAP > > would fall in to this category; right now it is > sufficiently different > > from the basic semantics of HTTP that it would require full > > specification, and would likely need to shift some of the > "POST"-based > > semantics to other methods. While I don't think this a bad idea > > (indeed, I suspect the resulting protocol would see reuse almost > > immediately), it is likely to take time and effort. It may also > > require some expertise from those who are not currently core > > participants in the SIMPLE effort. I can work with the chairs to > > help identify those resources, if required. > > Both Jon and Jonathan have expressed concern that taking the > > XCAP documents down that road would take more time than is practical > > for SIMPLE. While no one really wants to re-visit a > decision that has > > already been made, I wanted to make sure the working group > understands > > the type of output that would likely be expected for XCAP. I > > certainly don't want to do anything that dims the energy of > the group, > > though, and I'm sure we would all like to find a way forward which > > minimizes delay. In the call today, Jon, Jonathan, and I > brainstormed > > a bit on the roads forward, and I'd like to share my view of them > > below. I believe Jonathan will also be sending his view. > > > > 1) Continue work on XCAP with the current set of requirements as a > > guide. With a strong design team in place, work to complete a > > spec which is fully functional for SIMPLE's needs and is either > > sufficiently general or extensible that it can be used by other > > likely consumers of an XML-based data manipulation and update > > protocol. Four to six months would be the most > > optimistic imaginable > > timeframe for this, and it might be much longer. > > > > 2) Shift the XCAP framework so that it fits fully within > the semantics > > of HTPP. This likely would involve paring some requirements, > > since locking would not be enabled. Depending on the extent > > to which XPATH-based URIs were supported, this might or might > > force the fundamental unit of manipulation to always be the > > full list, which could have an impact on wireless users. > > > > 3) Shift the model so that the individual elements are > > seen as collection members with specific attributes, and re-use > > WebDav's locking and methods to accomplish the manipulation of > > the components. This may constrain implementations in ways that > > reduce efficiency for some operations. > > > > It is unfortunate that there is no easier answer here; > each has an > > engineering trade-off that requires either a shift in the > > requirements, the view of the components, or the scope of > the effort. > > As the working group considers these documents and this > requirement, I > > would appreciate you considering each of these trade-offs > and sharing > > with the group your view and other considerations which > occur to you. > > > > thanks, > > Ted Hardie > > > > > > _______________________________________________ > > Simple mailing 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 Wed Jun 18 15:02:46 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22067 for ; Wed, 18 Jun 2003 15:02:46 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5IJ2J501934 for simple-archive@odin.ietf.org; Wed, 18 Jun 2003 15:02:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ShyI-0008Cy-4S for simple-web-archive@optimus.ietf.org; Wed, 18 Jun 2003 14: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 OAA20795; Wed, 18 Jun 2003 14:47:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Shw0-00005H-00; Wed, 18 Jun 2003 14:45:28 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Shvz-00005E-00; Wed, 18 Jun 2003 14:45:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Shiy-00077E-3d; Wed, 18 Jun 2003 14:32:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Sf9z-00089y-CO for simple@optimus.ietf.org; Wed, 18 Jun 2003 11:47: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 LAA13692 for ; Wed, 18 Jun 2003 11:47:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Sf7j-00063z-00 for simple@ietf.org; Wed, 18 Jun 2003 11:45:23 -0400 Received: from [206.14.210.116] (helo=mail.xythos.com) by ietf-mx with esmtp (Exim 4.12) id 19Sf7i-00063v-00 for simple@ietf.org; Wed, 18 Jun 2003 11:45:22 -0400 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 19Sf9w-0006Zy-00; Wed, 18 Jun 2003 15:47:40 +0000 Received: from [198.144.203.253] (helo=lisalap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 19Sf9v-0006Za-00; Wed, 18 Jun 2003 15:47:39 +0000 From: "Lisa Dusseault" To: , , Subject: RE: [Simple] Thoughts on XCAP Message-ID: <03c501c335b0$f40e4d00$fdcb90c6@lisalap> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701796DF3@esebe019.ntc.nokia.com> X-Envelope-To: hardie@qualcomm.com, hisham.khartabil@nokia.com, simple@ietf.org 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, 18 Jun 2003 08:47:41 -0700 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA22067 > It isn't enough to consider only the existing server side > support for Webdav. Client side support is equally (if not > more) important and probably more scarce. General WebDAV client availability is actually huge-- WebDAV clients now ship with every copy of Windows (since Win98) and Macs (since Mac OS X) and are freely available for Unixes. That might well help the developers of IM clients needing to save buddy lists -- the client developer might simply be able to use file system scripting or API capabilities to specify the location of the remote WebDAV server and save the buddy list there as a regular document. That approach would definitely require the buddy list to be one or more regular MIME type documents stored in a fully WebDAV-compatible collection. WebDAV client API availability is pretty good too. C and Java libraries are available free (and open source). Python 2.0 ships including WebDAV client libraries. Even with only a bare HTTP library, it's pretty easy to put together WebDAV client requests. > o 1# We would have only have independent operations - no > MOVE. For example, if you wanted to move a buddy from > "public" authorization list to "friends", you could first ADD > to friends, then delete from public. The question is: does > this introduce an inconsistent state for authorization that > would require locking the document in between the operations? > Any other scenario that would? Not sure if we're all clear on this but the semantics of WebDAV MOVE is to move a whole document from one URL to another (perhaps overwriting an existing document at the target URL). The command does not have the semantics of moving only partial information from one document to another. Neither does WebDAV have the ability to ADD only partial information to the body of a document although with PROPPATCH it may add/modify a single property on an existing document's metadata. > > o #2 If operations are such that they leave the document in > an inconsistent state, you would do a highest common element > replacement. This means going towards the root element of the > document until reaching a node under which all of these > operations were performed - then replacing the entire > sub-tree. In a worst case scenario, you would end up > replacing the entire document. > > o #3 No batching of multiple requests. How often would you do > off-line edits to authorization lists, presence-lists etc., > where #2 would not be an option? > > So I would still like to revisit our original requirements in > order to see if we really need to go beyond the HTTP > semantics, e.g., WebDav style locks etc. > > Regards, > Hisham > > > -----Original Message----- > > From: ext hardie@qualcomm.com [mailto:hardie@qualcomm.com] > > Sent: Saturday, June 14, 2003 2:45 AM > > To: simple@ietf.org > > Subject: [Simple] Thoughts on XCAP > > > > > > Howdy folks, > > As you know from recent traffic on the list, there was > an agreement > > at the Interim Meeting to accept the XCAP docs as working group > > drafts. After that was announced to the working group, > Jonathan asked > > me to take a look at them to see if there were any gotchas > likely on > > the use of HTTP, XPATH, and the other components of the proposal. > > After reading the core doc and re-reading the XPATH doc, > > Jonathan, Jon, and I had a phone call earlier today to discuss the > > proposals and to talk about the conversation around this > proposal that > > happened at the Interim. First, let me say that I understand the > > approach of the group is to define a set of schemas which allows the > > manipulation of this data, but that the group intends that the data > > manipulation and transport will be out-of-band to SIMPLE itself. > > Second, let me say that I am very happy to see energy in the group > > around solving this problem, and I appreciate the work that has gone > > into hammering on this solution. Last, let me say that I think the > > XCAP docs provide a foundation for work that the working group can > > take forward if this is the consensus of the group. > > There are, however, some issues that I would like to ask the > > working group to consider. First, the IETF has in the past asked > > working groups re-using HTTP to be very careful that the > semantics of > > their use fit within the semantics of HTTP (It has in > particular asked > > working groups to be very careful about using "POST" as an > operator to > > extend the semantics of HTTP). Where a re-use of HTTP extended or > > restricted the semantics of HTTP, the IETF has asked that the group > > create a new uri scheme, select a new port, and describe > the protocol > > in full. The Internet Printing Protocol (IPP) and WebDav are both > > cases where this has occurred. > > As I read the documents at the moment, I believe that XCAP > > would fall in to this category; right now it is > sufficiently different > > from the basic semantics of HTTP that it would require full > > specification, and would likely need to shift some of the > "POST"-based > > semantics to other methods. While I don't think this a bad idea > > (indeed, I suspect the resulting protocol would see reuse almost > > immediately), it is likely to take time and effort. It may also > > require some expertise from those who are not currently core > > participants in the SIMPLE effort. I can work with the chairs to > > help identify those resources, if required. > > Both Jon and Jonathan have expressed concern that taking the > > XCAP documents down that road would take more time than is practical > > for SIMPLE. While no one really wants to re-visit a > decision that has > > already been made, I wanted to make sure the working group > understands > > the type of output that would likely be expected for XCAP. I > > certainly don't want to do anything that dims the energy of > the group, > > though, and I'm sure we would all like to find a way forward which > > minimizes delay. In the call today, Jon, Jonathan, and I > brainstormed > > a bit on the roads forward, and I'd like to share my view of them > > below. I believe Jonathan will also be sending his view. > > > > 1) Continue work on XCAP with the current set of requirements as a > > guide. With a strong design team in place, work to complete a > > spec which is fully functional for SIMPLE's needs and is either > > sufficiently general or extensible that it can be used by other > > likely consumers of an XML-based data manipulation and update > > protocol. Four to six months would be the most > > optimistic imaginable > > timeframe for this, and it might be much longer. > > > > 2) Shift the XCAP framework so that it fits fully within > the semantics > > of HTPP. This likely would involve paring some requirements, > > since locking would not be enabled. Depending on the extent > > to which XPATH-based URIs were supported, this might or might > > force the fundamental unit of manipulation to always be the > > full list, which could have an impact on wireless users. > > > > 3) Shift the model so that the individual elements are > > seen as collection members with specific attributes, and re-use > > WebDav's locking and methods to accomplish the manipulation of > > the components. This may constrain implementations in ways that > > reduce efficiency for some operations. > > > > It is unfortunate that there is no easier answer here; > each has an > > engineering trade-off that requires either a shift in the > > requirements, the view of the components, or the scope of > the effort. > > As the working group considers these documents and this > requirement, I > > would appreciate you considering each of these trade-offs > and sharing > > with the group your view and other considerations which > occur to you. > > > > thanks, > > Ted Hardie > > > > > > _______________________________________________ > > Simple mailing 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 Thu Jun 19 05:40:43 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 FAA06200; Thu, 19 Jun 2003 05:40:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Svs8-0001AG-00; Thu, 19 Jun 2003 05:38:24 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Svs8-0001AD-00; Thu, 19 Jun 2003 05:38:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SvdF-0004dN-OU; Thu, 19 Jun 2003 05:23:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SvLT-0003aR-H1 for simple@optimus.ietf.org; Thu, 19 Jun 2003 05:04: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 FAA05719 for ; Thu, 19 Jun 2003 05:04:36 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SvJB-000128-00 for simple@ietf.org; Thu, 19 Jun 2003 05:02:17 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19SvJA-000125-00 for simple@ietf.org; Thu, 19 Jun 2003 05:02:16 -0400 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h5J94Z908896 for ; Thu, 19 Jun 2003 12:04:35 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 19 Jun 2003 12:04:33 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 19 Jun 2003 12:04:35 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 19 Jun 2003 12:04:34 +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" Subject: RE: [Simple] Thoughts on XCAP Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701796E08@esebe019.ntc.nokia.com> Thread-Topic: [Simple] Thoughts on XCAP Thread-Index: AcM1sPvDjkV3G6auQB224tGhywYHIAAkC9Ag To: , , X-OriginalArrivalTime: 19 Jun 2003 09:04:34.0744 (UTC) FILETIME=[CDA54380:01C33641] 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, 19 Jun 2003 12:04:34 +0300 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id FAA06200 Lisa, My comment about availability of WebDav to clients was not restricted to PCs and work stations. In any case, my email was mainly questioning the severity of the problem at hand and the real need to use something like WebDav to solve it. There are certainly simpler ways to solve this problem, if we see the need. One of them is what I listed as option 2 in my earlier posting. Regards, Hisham > -----Original Message----- > From: ext Lisa Dusseault [mailto:lisa@xythos.com] > Sent: Wednesday, June 18, 2003 6:48 PM > To: Khartabil Hisham (NMP/Helsinki); hardie@qualcomm.com; > simple@ietf.org > Subject: RE: [Simple] Thoughts on XCAP > > > > > It isn't enough to consider only the existing server side > > support for Webdav. Client side support is equally (if not > > more) important and probably more scarce. > > General WebDAV client availability is actually huge-- WebDAV > clients now > ship with every copy of Windows (since Win98) and Macs (since > Mac OS X) and > are freely available for Unixes. That might well help the > developers of IM > clients needing to save buddy lists -- the client developer > might simply be > able to use file system scripting or API capabilities to specify the > location of the remote WebDAV server and save the buddy list > there as a > regular document. That approach would definitely require the > buddy list to > be one or more regular MIME type documents stored in a fully > WebDAV-compatible collection. > > WebDAV client API availability is pretty good too. C and > Java libraries are > available free (and open source). Python 2.0 ships including > WebDAV client > libraries. Even with only a bare HTTP library, it's pretty > easy to put > together WebDAV client requests. > > > o 1# We would have only have independent operations - no > > MOVE. For example, if you wanted to move a buddy from > > "public" authorization list to "friends", you could first ADD > > to friends, then delete from public. The question is: does > > this introduce an inconsistent state for authorization that > > would require locking the document in between the operations? > > Any other scenario that would? > > Not sure if we're all clear on this but the semantics of > WebDAV MOVE is to > move a whole document from one URL to another (perhaps overwriting an > existing document at the target URL). The command does not have the > semantics of moving only partial information from one > document to another. > Neither does WebDAV have the ability to ADD only partial > information to the > body of a document although with PROPPATCH it may add/modify a single > property on an existing document's metadata. > > > > > o #2 If operations are such that they leave the document in > > an inconsistent state, you would do a highest common element > > replacement. This means going towards the root element of the > > document until reaching a node under which all of these > > operations were performed - then replacing the entire > > sub-tree. In a worst case scenario, you would end up > > replacing the entire document. > > > > o #3 No batching of multiple requests. How often would you do > > off-line edits to authorization lists, presence-lists etc., > > where #2 would not be an option? > > > > So I would still like to revisit our original requirements in > > order to see if we really need to go beyond the HTTP > > semantics, e.g., WebDav style locks etc. > > > > Regards, > > Hisham > > > > > -----Original Message----- > > > From: ext hardie@qualcomm.com [mailto:hardie@qualcomm.com] > > > Sent: Saturday, June 14, 2003 2:45 AM > > > To: simple@ietf.org > > > Subject: [Simple] Thoughts on XCAP > > > > > > > > > Howdy folks, > > > As you know from recent traffic on the list, there was > > an agreement > > > at the Interim Meeting to accept the XCAP docs as working group > > > drafts. After that was announced to the working group, > > Jonathan asked > > > me to take a look at them to see if there were any gotchas > > likely on > > > the use of HTTP, XPATH, and the other components of the proposal. > > > After reading the core doc and re-reading the XPATH doc, > > > Jonathan, Jon, and I had a phone call earlier today to discuss the > > > proposals and to talk about the conversation around this > > proposal that > > > happened at the Interim. First, let me say that I understand the > > > approach of the group is to define a set of schemas which > allows the > > > manipulation of this data, but that the group intends > that the data > > > manipulation and transport will be out-of-band to SIMPLE itself. > > > Second, let me say that I am very happy to see energy in the group > > > around solving this problem, and I appreciate the work > that has gone > > > into hammering on this solution. Last, let me say that I > think the > > > XCAP docs provide a foundation for work that the working group can > > > take forward if this is the consensus of the group. > > > There are, however, some issues that I would like to ask the > > > working group to consider. First, the IETF has in the past asked > > > working groups re-using HTTP to be very careful that the > > semantics of > > > their use fit within the semantics of HTTP (It has in > > particular asked > > > working groups to be very careful about using "POST" as an > > operator to > > > extend the semantics of HTTP). Where a re-use of HTTP extended or > > > restricted the semantics of HTTP, the IETF has asked that > the group > > > create a new uri scheme, select a new port, and describe > > the protocol > > > in full. The Internet Printing Protocol (IPP) and WebDav are both > > > cases where this has occurred. > > > As I read the documents at the moment, I believe that XCAP > > > would fall in to this category; right now it is > > sufficiently different > > > from the basic semantics of HTTP that it would require full > > > specification, and would likely need to shift some of the > > "POST"-based > > > semantics to other methods. While I don't think this a bad idea > > > (indeed, I suspect the resulting protocol would see reuse almost > > > immediately), it is likely to take time and effort. It may also > > > require some expertise from those who are not currently core > > > participants in the SIMPLE effort. I can work with the chairs to > > > help identify those resources, if required. > > > Both Jon and Jonathan have expressed concern that taking the > > > XCAP documents down that road would take more time than > is practical > > > for SIMPLE. While no one really wants to re-visit a > > decision that has > > > already been made, I wanted to make sure the working group > > understands > > > the type of output that would likely be expected for XCAP. I > > > certainly don't want to do anything that dims the energy of > > the group, > > > though, and I'm sure we would all like to find a way forward which > > > minimizes delay. In the call today, Jon, Jonathan, and I > > brainstormed > > > a bit on the roads forward, and I'd like to share my view of them > > > below. I believe Jonathan will also be sending his view. > > > > > > 1) Continue work on XCAP with the current set of requirements as a > > > guide. With a strong design team in place, work to complete a > > > spec which is fully functional for SIMPLE's needs and > is either > > > sufficiently general or extensible that it can be > used by other > > > likely consumers of an XML-based data manipulation and update > > > protocol. Four to six months would be the most > > > optimistic imaginable > > > timeframe for this, and it might be much longer. > > > > > > 2) Shift the XCAP framework so that it fits fully within > > the semantics > > > of HTPP. This likely would involve paring some requirements, > > > since locking would not be enabled. Depending on the extent > > > to which XPATH-based URIs were supported, this might or might > > > force the fundamental unit of manipulation to always be the > > > full list, which could have an impact on wireless users. > > > > > > 3) Shift the model so that the individual elements are > > > seen as collection members with specific attributes, > and re-use > > > WebDav's locking and methods to accomplish the manipulation of > > > the components. This may constrain implementations in > ways that > > > reduce efficiency for some operations. > > > > > > It is unfortunate that there is no easier answer here; > > each has an > > > engineering trade-off that requires either a shift in the > > > requirements, the view of the components, or the scope of > > the effort. > > > As the working group considers these documents and this > > requirement, I > > > would appreciate you considering each of these trade-offs > > and sharing > > > with the group your view and other considerations which > > occur to you. > > > > > > thanks, > > > Ted Hardie > > > > > > > > > _______________________________________________ > > > Simple mailing 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 Thu Jun 19 05:46:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06341 for ; Thu, 19 Jun 2003 05:46:20 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5J9jrI22280 for simple-archive@odin.ietf.org; Thu, 19 Jun 2003 05:45:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SvuR-0005XA-Lq for simple-web-archive@optimus.ietf.org; Thu, 19 Jun 2003 05:40:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06200; Thu, 19 Jun 2003 05:40:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Svs8-0001AG-00; Thu, 19 Jun 2003 05:38:24 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Svs8-0001AD-00; Thu, 19 Jun 2003 05:38:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SvdF-0004dN-OU; Thu, 19 Jun 2003 05:23:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SvLT-0003aR-H1 for simple@optimus.ietf.org; Thu, 19 Jun 2003 05:04: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 FAA05719 for ; Thu, 19 Jun 2003 05:04:36 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SvJB-000128-00 for simple@ietf.org; Thu, 19 Jun 2003 05:02:17 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19SvJA-000125-00 for simple@ietf.org; Thu, 19 Jun 2003 05:02:16 -0400 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h5J94Z908896 for ; Thu, 19 Jun 2003 12:04:35 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 19 Jun 2003 12:04:33 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 19 Jun 2003 12:04:35 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 19 Jun 2003 12:04:34 +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" Subject: RE: [Simple] Thoughts on XCAP Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701796E08@esebe019.ntc.nokia.com> Thread-Topic: [Simple] Thoughts on XCAP Thread-Index: AcM1sPvDjkV3G6auQB224tGhywYHIAAkC9Ag To: , , X-OriginalArrivalTime: 19 Jun 2003 09:04:34.0744 (UTC) FILETIME=[CDA54380:01C33641] 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, 19 Jun 2003 12:04:34 +0300 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id FAA06341 Lisa, My comment about availability of WebDav to clients was not restricted to PCs and work stations. In any case, my email was mainly questioning the severity of the problem at hand and the real need to use something like WebDav to solve it. There are certainly simpler ways to solve this problem, if we see the need. One of them is what I listed as option 2 in my earlier posting. Regards, Hisham > -----Original Message----- > From: ext Lisa Dusseault [mailto:lisa@xythos.com] > Sent: Wednesday, June 18, 2003 6:48 PM > To: Khartabil Hisham (NMP/Helsinki); hardie@qualcomm.com; > simple@ietf.org > Subject: RE: [Simple] Thoughts on XCAP > > > > > It isn't enough to consider only the existing server side > > support for Webdav. Client side support is equally (if not > > more) important and probably more scarce. > > General WebDAV client availability is actually huge-- WebDAV > clients now > ship with every copy of Windows (since Win98) and Macs (since > Mac OS X) and > are freely available for Unixes. That might well help the > developers of IM > clients needing to save buddy lists -- the client developer > might simply be > able to use file system scripting or API capabilities to specify the > location of the remote WebDAV server and save the buddy list > there as a > regular document. That approach would definitely require the > buddy list to > be one or more regular MIME type documents stored in a fully > WebDAV-compatible collection. > > WebDAV client API availability is pretty good too. C and > Java libraries are > available free (and open source). Python 2.0 ships including > WebDAV client > libraries. Even with only a bare HTTP library, it's pretty > easy to put > together WebDAV client requests. > > > o 1# We would have only have independent operations - no > > MOVE. For example, if you wanted to move a buddy from > > "public" authorization list to "friends", you could first ADD > > to friends, then delete from public. The question is: does > > this introduce an inconsistent state for authorization that > > would require locking the document in between the operations? > > Any other scenario that would? > > Not sure if we're all clear on this but the semantics of > WebDAV MOVE is to > move a whole document from one URL to another (perhaps overwriting an > existing document at the target URL). The command does not have the > semantics of moving only partial information from one > document to another. > Neither does WebDAV have the ability to ADD only partial > information to the > body of a document although with PROPPATCH it may add/modify a single > property on an existing document's metadata. > > > > > o #2 If operations are such that they leave the document in > > an inconsistent state, you would do a highest common element > > replacement. This means going towards the root element of the > > document until reaching a node under which all of these > > operations were performed - then replacing the entire > > sub-tree. In a worst case scenario, you would end up > > replacing the entire document. > > > > o #3 No batching of multiple requests. How often would you do > > off-line edits to authorization lists, presence-lists etc., > > where #2 would not be an option? > > > > So I would still like to revisit our original requirements in > > order to see if we really need to go beyond the HTTP > > semantics, e.g., WebDav style locks etc. > > > > Regards, > > Hisham > > > > > -----Original Message----- > > > From: ext hardie@qualcomm.com [mailto:hardie@qualcomm.com] > > > Sent: Saturday, June 14, 2003 2:45 AM > > > To: simple@ietf.org > > > Subject: [Simple] Thoughts on XCAP > > > > > > > > > Howdy folks, > > > As you know from recent traffic on the list, there was > > an agreement > > > at the Interim Meeting to accept the XCAP docs as working group > > > drafts. After that was announced to the working group, > > Jonathan asked > > > me to take a look at them to see if there were any gotchas > > likely on > > > the use of HTTP, XPATH, and the other components of the proposal. > > > After reading the core doc and re-reading the XPATH doc, > > > Jonathan, Jon, and I had a phone call earlier today to discuss the > > > proposals and to talk about the conversation around this > > proposal that > > > happened at the Interim. First, let me say that I understand the > > > approach of the group is to define a set of schemas which > allows the > > > manipulation of this data, but that the group intends > that the data > > > manipulation and transport will be out-of-band to SIMPLE itself. > > > Second, let me say that I am very happy to see energy in the group > > > around solving this problem, and I appreciate the work > that has gone > > > into hammering on this solution. Last, let me say that I > think the > > > XCAP docs provide a foundation for work that the working group can > > > take forward if this is the consensus of the group. > > > There are, however, some issues that I would like to ask the > > > working group to consider. First, the IETF has in the past asked > > > working groups re-using HTTP to be very careful that the > > semantics of > > > their use fit within the semantics of HTTP (It has in > > particular asked > > > working groups to be very careful about using "POST" as an > > operator to > > > extend the semantics of HTTP). Where a re-use of HTTP extended or > > > restricted the semantics of HTTP, the IETF has asked that > the group > > > create a new uri scheme, select a new port, and describe > > the protocol > > > in full. The Internet Printing Protocol (IPP) and WebDav are both > > > cases where this has occurred. > > > As I read the documents at the moment, I believe that XCAP > > > would fall in to this category; right now it is > > sufficiently different > > > from the basic semantics of HTTP that it would require full > > > specification, and would likely need to shift some of the > > "POST"-based > > > semantics to other methods. While I don't think this a bad idea > > > (indeed, I suspect the resulting protocol would see reuse almost > > > immediately), it is likely to take time and effort. It may also > > > require some expertise from those who are not currently core > > > participants in the SIMPLE effort. I can work with the chairs to > > > help identify those resources, if required. > > > Both Jon and Jonathan have expressed concern that taking the > > > XCAP documents down that road would take more time than > is practical > > > for SIMPLE. While no one really wants to re-visit a > > decision that has > > > already been made, I wanted to make sure the working group > > understands > > > the type of output that would likely be expected for XCAP. I > > > certainly don't want to do anything that dims the energy of > > the group, > > > though, and I'm sure we would all like to find a way forward which > > > minimizes delay. In the call today, Jon, Jonathan, and I > > brainstormed > > > a bit on the roads forward, and I'd like to share my view of them > > > below. I believe Jonathan will also be sending his view. > > > > > > 1) Continue work on XCAP with the current set of requirements as a > > > guide. With a strong design team in place, work to complete a > > > spec which is fully functional for SIMPLE's needs and > is either > > > sufficiently general or extensible that it can be > used by other > > > likely consumers of an XML-based data manipulation and update > > > protocol. Four to six months would be the most > > > optimistic imaginable > > > timeframe for this, and it might be much longer. > > > > > > 2) Shift the XCAP framework so that it fits fully within > > the semantics > > > of HTPP. This likely would involve paring some requirements, > > > since locking would not be enabled. Depending on the extent > > > to which XPATH-based URIs were supported, this might or might > > > force the fundamental unit of manipulation to always be the > > > full list, which could have an impact on wireless users. > > > > > > 3) Shift the model so that the individual elements are > > > seen as collection members with specific attributes, > and re-use > > > WebDav's locking and methods to accomplish the manipulation of > > > the components. This may constrain implementations in > ways that > > > reduce efficiency for some operations. > > > > > > It is unfortunate that there is no easier answer here; > > each has an > > > engineering trade-off that requires either a shift in the > > > requirements, the view of the components, or the scope of > > the effort. > > > As the working group considers these documents and this > > requirement, I > > > would appreciate you considering each of these trade-offs > > and sharing > > > with the group your view and other considerations which > > occur to you. > > > > > > thanks, > > > Ted Hardie > > > > > > > > > _______________________________________________ > > > Simple mailing 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 Fri Jun 20 07:36: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 HAA26578; Fri, 20 Jun 2003 07:36:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TK9D-0001is-00; Fri, 20 Jun 2003 07:33:39 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19TK9C-0001in-00; Fri, 20 Jun 2003 07:33:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TKBV-00058Y-LA; Fri, 20 Jun 2003 07:36:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TKBH-00056F-7V for simple@optimus.ietf.org; Fri, 20 Jun 2003 07:35:47 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26490; Fri, 20 Jun 2003 07:35:45 -0400 (EDT) Message-Id: <200306201135.HAA26490@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-01.txt Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 20 Jun 2003 07:35:45 -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) : T. Moran et al. Filename : draft-ietf-simple-pres-filter-reqs-01.txt Pages : 13 Date : 2003-6-19 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-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-pres-filter-reqs-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-pres-filter-reqs-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-6-19154440.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-pres-filter-reqs-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-pres-filter-reqs-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-19154440.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 Jun 20 07:36:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26654 for ; Fri, 20 Jun 2003 07:36:34 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5KBa5g19953 for simple-archive@odin.ietf.org; Fri, 20 Jun 2003 07:36:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TKBZ-0005Bk-DF for simple-web-archive@optimus.ietf.org; Fri, 20 Jun 2003 07:36: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 HAA26578; Fri, 20 Jun 2003 07:36:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TK9D-0001is-00; Fri, 20 Jun 2003 07:33:39 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19TK9C-0001in-00; Fri, 20 Jun 2003 07:33:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TKBV-00058Y-LA; Fri, 20 Jun 2003 07:36:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TKBH-00056F-7V for simple@optimus.ietf.org; Fri, 20 Jun 2003 07:35:47 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26490; Fri, 20 Jun 2003 07:35:45 -0400 (EDT) Message-Id: <200306201135.HAA26490@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-01.txt Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 20 Jun 2003 07:35:45 -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) : T. Moran et al. Filename : draft-ietf-simple-pres-filter-reqs-01.txt Pages : 13 Date : 2003-6-19 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-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-pres-filter-reqs-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-pres-filter-reqs-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-6-19154440.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-pres-filter-reqs-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-pres-filter-reqs-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-19154440.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Sun Jun 22 06:51:18 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 GAA09508; Sun, 22 Jun 2003 06:51:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19U2RK-0003wv-00; Sun, 22 Jun 2003 06:51:18 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19U2RE-0003wo-00; Sun, 22 Jun 2003 06:51:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19U2R2-0005iL-Gm; Sun, 22 Jun 2003 06:51:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19U2Pw-0005hd-TT for simple@optimus.ietf.org; Sun, 22 Jun 2003 06:50: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 GAA09485 for ; Sun, 22 Jun 2003 06:49:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19U2Pd-0003wi-00 for simple@ietf.org; Sun, 22 Jun 2003 06:49:33 -0400 Received: from il-tlv-firewall-main.icomverse.com ([192.118.48.248] helo=il-tlv-smtpout2.icomverse.com) by ietf-mx with esmtp (Exim 4.12) id 19U2PS-0003wf-00 for simple@ietf.org; Sun, 22 Jun 2003 06:49:23 -0400 Received: from il-tlv-mbdg1.comverse.com (localhost.localdomain [127.0.0.1]) by il-tlv-smtpout2.icomverse.com (8.11.6/8.11.6) with ESMTP id h5MAmmA25322; Sun, 22 Jun 2003 13:48:49 +0300 Received: by il-tlv-mbdg1.comverse.com with Internet Mail Service (5.5.2655.55) id ; Sun, 22 Jun 2003 13:48:55 +0300 Message-ID: <385D702A9C11D511A9E90008C7160AD505454454@ISMAIL1> From: Cnaan Oded To: "'Thanos Diacakis'" , hisham.khartabil@nokia.com, aki.niemi@nokia.com, simple@ietf.org Subject: RE: [Simple] PUBLISH: identification of presence segments X-Mailer: Internet Mail Service (5.5.2655.55) 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, 22 Jun 2003 13:48:53 +0300 I hope that we can agree, that in a typical implementation, users will not be exposed to tuples and might not even know that they exist. Tuples are just a method for describing Presence information in a hierarchical way that can be understood by UAs (and PSs). Saying that, it would be very rare to have _users_ selecting tuple IDs or referring to tuples by their names. In most cases, users will change their 'Video' availability and have their UA handle the details for them. I believe that the tuple identification problem is caused by using the same Presence document for both PUBLISH and NOTIFY. Let's take for example user A with the following Presence document, as generated by the PS (schematic syntax): online busy meeting im:someone@mobilecarrier.net tel:+44-254-54462211 online offline im:someone@mobilecarrier.net The first tuple represents a mobile phone that runs an IM client and that is capable of receiving phone calls. The latter describes a PC running an IM client from the same service provider. Changing the IM availability on the PC requires the PC to recognize that the phone has published voice capabilities as part of the same tuple and even to re-publish information related to the phone. A different approach would be to have publishers send only raw information, leaving the document composition task to the Presence Server. This allows the PS to apply rules as well as transformations on the raw information, without the need to 'identify' tuples. Doing so, also solves the problem of tuple IDs as only the server now generates them. When publishing Presence information, there are 3 basic questions to answer: 1. What is the information element that we would like to update (e.g., MSN IM Service) 2. What is the new value of the information element (e.g., status is BUSY and contact is ...) 3. To which device/service this element belongs (e.g., specific phone) These questions can be used on any Presence view (i.e., Device/Service/Media based). For example, in a service-view, the third answer may be "specific service". Now, let's see how this new approach facilitates the publication problems identified by Thanos, Hisham and Aki. 1. Thanos showed that having 2 UAs publish using the same tuple ID may result in a conflict on the PS. Here, tuple IDs are not used for publication. If 2 UAs publish a new IM status, they do not relate to a specific tuple, but to the same service. 2. Thanos also raised the problem of having PS change tuple IDs based on some server based rules (e.g., transformation rules). Here, there is no conflict as the UA publishes raw info regardless of the tuple structure. 3. Aki suggested to restrict the composer so that published tuples are never merged or modified. This is no longer required as we've separated between the published info and the Presence document sent to watchers. 4. Hisham raised the question of relating 2 tuples and mentioned that in some circumstances, there would be a need to publish the whole document to avoid conflicts.. This is a non-issue as we now publish raw info not related to a specific tuple. We can now build an XML document that will be used for publications. This document needs to answer the above questions and, for optimization, allow publishing more than one update at a time. It will be used as part of PUBLISH messages while PIDF will continue to serve NOTIFY messages. I understand that this idea conflicts previous PUBLISH drafts but I hope you'll consider it as it solves many of the problems identified in this thread. Oded _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Sun Jun 22 06:51:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09524 for ; Sun, 22 Jun 2003 06:51:49 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5MApMU22283 for simple-archive@odin.ietf.org; Sun, 22 Jun 2003 06:51:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19U2RO-0005nK-P9 for simple-web-archive@optimus.ietf.org; Sun, 22 Jun 2003 06:51:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09508; Sun, 22 Jun 2003 06:51:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19U2RK-0003wv-00; Sun, 22 Jun 2003 06:51:18 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19U2RE-0003wo-00; Sun, 22 Jun 2003 06:51:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19U2R2-0005iL-Gm; Sun, 22 Jun 2003 06:51:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19U2Pw-0005hd-TT for simple@optimus.ietf.org; Sun, 22 Jun 2003 06:50: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 GAA09485 for ; Sun, 22 Jun 2003 06:49:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19U2Pd-0003wi-00 for simple@ietf.org; Sun, 22 Jun 2003 06:49:33 -0400 Received: from il-tlv-firewall-main.icomverse.com ([192.118.48.248] helo=il-tlv-smtpout2.icomverse.com) by ietf-mx with esmtp (Exim 4.12) id 19U2PS-0003wf-00 for simple@ietf.org; Sun, 22 Jun 2003 06:49:23 -0400 Received: from il-tlv-mbdg1.comverse.com (localhost.localdomain [127.0.0.1]) by il-tlv-smtpout2.icomverse.com (8.11.6/8.11.6) with ESMTP id h5MAmmA25322; Sun, 22 Jun 2003 13:48:49 +0300 Received: by il-tlv-mbdg1.comverse.com with Internet Mail Service (5.5.2655.55) id ; Sun, 22 Jun 2003 13:48:55 +0300 Message-ID: <385D702A9C11D511A9E90008C7160AD505454454@ISMAIL1> From: Cnaan Oded To: "'Thanos Diacakis'" , hisham.khartabil@nokia.com, aki.niemi@nokia.com, simple@ietf.org Subject: RE: [Simple] PUBLISH: identification of presence segments X-Mailer: Internet Mail Service (5.5.2655.55) 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, 22 Jun 2003 13:48:53 +0300 I hope that we can agree, that in a typical implementation, users will not be exposed to tuples and might not even know that they exist. Tuples are just a method for describing Presence information in a hierarchical way that can be understood by UAs (and PSs). Saying that, it would be very rare to have _users_ selecting tuple IDs or referring to tuples by their names. In most cases, users will change their 'Video' availability and have their UA handle the details for them. I believe that the tuple identification problem is caused by using the same Presence document for both PUBLISH and NOTIFY. Let's take for example user A with the following Presence document, as generated by the PS (schematic syntax): online busy meeting im:someone@mobilecarrier.net tel:+44-254-54462211 online offline im:someone@mobilecarrier.net The first tuple represents a mobile phone that runs an IM client and that is capable of receiving phone calls. The latter describes a PC running an IM client from the same service provider. Changing the IM availability on the PC requires the PC to recognize that the phone has published voice capabilities as part of the same tuple and even to re-publish information related to the phone. A different approach would be to have publishers send only raw information, leaving the document composition task to the Presence Server. This allows the PS to apply rules as well as transformations on the raw information, without the need to 'identify' tuples. Doing so, also solves the problem of tuple IDs as only the server now generates them. When publishing Presence information, there are 3 basic questions to answer: 1. What is the information element that we would like to update (e.g., MSN IM Service) 2. What is the new value of the information element (e.g., status is BUSY and contact is ...) 3. To which device/service this element belongs (e.g., specific phone) These questions can be used on any Presence view (i.e., Device/Service/Media based). For example, in a service-view, the third answer may be "specific service". Now, let's see how this new approach facilitates the publication problems identified by Thanos, Hisham and Aki. 1. Thanos showed that having 2 UAs publish using the same tuple ID may result in a conflict on the PS. Here, tuple IDs are not used for publication. If 2 UAs publish a new IM status, they do not relate to a specific tuple, but to the same service. 2. Thanos also raised the problem of having PS change tuple IDs based on some server based rules (e.g., transformation rules). Here, there is no conflict as the UA publishes raw info regardless of the tuple structure. 3. Aki suggested to restrict the composer so that published tuples are never merged or modified. This is no longer required as we've separated between the published info and the Presence document sent to watchers. 4. Hisham raised the question of relating 2 tuples and mentioned that in some circumstances, there would be a need to publish the whole document to avoid conflicts.. This is a non-issue as we now publish raw info not related to a specific tuple. We can now build an XML document that will be used for publications. This document needs to answer the above questions and, for optimization, allow publishing more than one update at a time. It will be used as part of PUBLISH messages while PIDF will continue to serve NOTIFY messages. I understand that this idea conflicts previous PUBLISH drafts but I hope you'll consider it as it solves many of the problems identified in this thread. Oded _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Jun 23 01:50:09 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 BAA27695; Mon, 23 Jun 2003 01:50:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UKDQ-0007Mz-00; Mon, 23 Jun 2003 01:50:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19UKDL-0007Mw-00; Mon, 23 Jun 2003 01:50:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UKDK-00081E-Bx; Mon, 23 Jun 2003 01:50:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UKCw-00080S-8R for simple@optimus.ietf.org; Mon, 23 Jun 2003 01:49: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 BAA27677 for ; Mon, 23 Jun 2003 01:49:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UKCt-0007MT-00 for simple@ietf.org; Mon, 23 Jun 2003 01:49:35 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19UKCh-0007M4-00 for simple@ietf.org; Mon, 23 Jun 2003 01:49:24 -0400 Received: from dynamicsoft.com ([63.113.46.135]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h5N5mlsm007401 for ; Mon, 23 Jun 2003 01:48:48 -0400 (EDT) Message-ID: <3EF694BC.7010409@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Simple WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] XCAP authorization usage 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, 23 Jun 2003 01:48:44 -0400 Content-Transfer-Encoding: 7bit Folks, I've finally finished the xcap usage specification for authorization. Until it appears in the archives, you can pick it up at: http://www.jdrosen.net/papers/draft-ietf-simple-xcap-auth-usage-00.txt http://www.jdrosen.net/papers/draft-ietf-simple-xcap-auth-usage-00.html There are actually three usages in there (i.e., three schemas). One is for actual authorization policy, which is expressed as a "permission statements" document. The second is for compound permissions, which allows a client to define new permissions as a combination of others. The third is for supported permissions, which allows a client to learn the permissions understood by the server. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Scientist 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 Jun 23 01:50:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27732 for ; Mon, 23 Jun 2003 01:50:40 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5N5oCe31200 for simple-archive@odin.ietf.org; Mon, 23 Jun 2003 01:50:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UKDU-000879-Df for simple-web-archive@optimus.ietf.org; Mon, 23 Jun 2003 01:50:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27695; Mon, 23 Jun 2003 01:50:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UKDQ-0007Mz-00; Mon, 23 Jun 2003 01:50:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19UKDL-0007Mw-00; Mon, 23 Jun 2003 01:50:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UKDK-00081E-Bx; Mon, 23 Jun 2003 01:50:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UKCw-00080S-8R for simple@optimus.ietf.org; Mon, 23 Jun 2003 01:49: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 BAA27677 for ; Mon, 23 Jun 2003 01:49:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UKCt-0007MT-00 for simple@ietf.org; Mon, 23 Jun 2003 01:49:35 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19UKCh-0007M4-00 for simple@ietf.org; Mon, 23 Jun 2003 01:49:24 -0400 Received: from dynamicsoft.com ([63.113.46.135]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h5N5mlsm007401 for ; Mon, 23 Jun 2003 01:48:48 -0400 (EDT) Message-ID: <3EF694BC.7010409@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Simple WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] XCAP authorization usage 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, 23 Jun 2003 01:48:44 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Folks, I've finally finished the xcap usage specification for authorization. Until it appears in the archives, you can pick it up at: http://www.jdrosen.net/papers/draft-ietf-simple-xcap-auth-usage-00.txt http://www.jdrosen.net/papers/draft-ietf-simple-xcap-auth-usage-00.html There are actually three usages in there (i.e., three schemas). One is for actual authorization policy, which is expressed as a "permission statements" document. The second is for compound permissions, which allows a client to define new permissions as a combination of others. The third is for supported permissions, which allows a client to learn the permissions understood by the server. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Scientist 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 Jun 23 02:26:07 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 CAA10349; Mon, 23 Jun 2003 02:26:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UKmE-0007WK-00; Mon, 23 Jun 2003 02:26:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19UKm9-0007WH-00; Mon, 23 Jun 2003 02:26:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UKmA-0003fs-5w; Mon, 23 Jun 2003 02:26:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UKlF-0003fM-LG for simple@optimus.ietf.org; Mon, 23 Jun 2003 02:25: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 CAA10338 for ; Mon, 23 Jun 2003 02:24:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UKkw-0007WA-00 for simple@ietf.org; Mon, 23 Jun 2003 02:24:46 -0400 Received: from il-tlv-firewall-main.icomverse.com ([192.118.48.248] helo=il-tlv-smtpout2.icomverse.com) by ietf-mx with esmtp (Exim 4.12) id 19UKkl-0007Vu-00 for simple@ietf.org; Mon, 23 Jun 2003 02:24:35 -0400 Received: from il-tlv-mbdg2.comverse.com (localhost.localdomain [127.0.0.1]) by il-tlv-smtpout2.icomverse.com (8.11.6/8.11.6) with ESMTP id h5N6OAo06126 for ; Mon, 23 Jun 2003 09:24:10 +0300 Received: by il-tlv-mbdg2.comverse.com with Internet Mail Service (5.5.2655.55) id ; Mon, 23 Jun 2003 09:24:14 +0300 Message-ID: <385D702A9C11D511A9E90008C7160AD50545445A@ISMAIL1> From: Cnaan Oded To: simple@ietf.org MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C33950.0D14DC86" Subject: [Simple] Single / multiple tuples 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, 23 Jun 2003 09:24:08 +0300 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C33950.0D14DC86 Content-Type: text/plain; charset="windows-1255" Single tuple ---------------- There are cases, where a PS would prefer using a single tuple to represent each device (or service) and specify all the services (devices) associated with it. For example, a tuple that represents a mobile phone that has an IM, PTT and voice services. This structure can be achieved using PIDF but the result would be very hard to manage or even understand. Following the above example, the tuple may look like that: online busy meeting offline im:imuser@mobilecarrier.net sip:pttuser@mobilecarrier.net tel:+44-254-54462211 There are several problem with this representation: 1. There is no way to associate each of the services with its matching contact. In other words, a UA cannot determine that the second contact element should be used for PTT. 2. There is no specification of a service name/ID. If a UA is running 2 IM clients (e.g., MSN and AOL), there is no way to determine which one is specified by the im:im element. Moreover, any additional information within the tuple cannot be associated with a specific service since there is no sufficient internal structuring. 3. The PS and UA must have a-priori agreed on the _extended_ elements and their meaning 4. There is no way to determine if the tuple represents a device or a service. 5. There is no way to specify, when a tuple represents a device, the device type (e.g., mobile phone) Note that RPIDS, which adds some information elements to the PIDF structure, does not provide any solutions to these problems as well. Several steps can be taken to fix these problems: 1. The first problem can be solved in several ways. One alternative would be to create an internal tuple format that structures the elements for each services. 2. A collection of elements (representing a device/service) would be given a name/ID that will be used for both UI representation (e.g., "MSN Messenger") and parsing. 3. This problem will probably not be completely solved and integration will be required. 4. Add an attribute to the tuple element that specifies what it represents. I understand that there is a big discussion on "what a tuple is" but we can also define 2-3 values and leave it to implementers to add their own. 5. Add an attribute to the tuple element specifying the device type. Again, some obvious values can be determined, leaving implementers to add their own in the future. Oded ------_=_NextPart_001_01C33950.0D14DC86 Content-Type: text/html; charset="windows-1255"
Single tuple
----------------
There are cases, where a PS would prefer using a single tuple to represent each device (or service) and specify all the services (devices) associated with it. For example, a tuple that represents a mobile phone that has an IM, PTT and voice services.
 
This structure can be achieved using PIDF but the result would be very hard to manage or even understand. Following the above example, the tuple may look like that:
 
<presence>
  <tuple id="A1">
    <status>
      <basic>online</basic>
      <im:im>busy</im:im>
       <ext:voice-call>meeting</ext:voice-call>
       <ext:ptt>offline</ext:ptt>
    </status>
    <contact>im:imuser@mobilecarrier.net</contact>
    <contact>sip:pttuser@mobilecarrier.net</contact>
    <contact>tel:+44-254-54462211</contact>
  </tuple>
</presence>
 
There are several problem with this representation:
1. There is no way to associate each of the services with its matching contact. In other words, a UA cannot determine that the second contact element should be used for PTT.
2. There is no specification of a service name/ID. If a UA is running 2 IM clients (e.g., MSN and AOL), there is no way to determine which one is specified by the im:im element. Moreover, any additional information within the tuple cannot be associated with a specific service since there is no sufficient internal structuring.
3. The PS and UA must have a-priori agreed on the _extended_ elements and their meaning
4. There is no way to determine if the tuple represents a device or a service.
5. There is no way to specify, when a tuple represents a device, the device type (e.g., mobile phone)
 
Note that RPIDS, which adds some information elements to the PIDF structure, does not provide any solutions to these problems as well.
 
Several steps can be taken to fix these problems:
1. The first problem can be solved in several ways. One alternative would be to create an internal tuple format that structures the elements for each services.
2. A collection of elements (representing a device/service) would be given a name/ID that will be used for both UI representation (e.g., "MSN Messenger") and parsing.
3. This problem will probably not be completely solved and integration will be required.
4. Add an attribute to the tuple element that specifies what it represents. I understand that there is a big discussion on "what a tuple is" but we can also define 2-3 values and leave it to implementers to add their own.
 5. Add an attribute to the tuple element specifying the device type. Again, some obvious values can be determined, leaving implementers to add their own in the future.
 
Oded
------_=_NextPart_001_01C33950.0D14DC86-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Jun 23 02:27:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10374 for ; Mon, 23 Jun 2003 02:27:00 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5N6QCY14351 for simple-archive@odin.ietf.org; Mon, 23 Jun 2003 02:26:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UKmJ-0003jO-G8 for simple-web-archive@optimus.ietf.org; Mon, 23 Jun 2003 02:26: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 CAA10349; Mon, 23 Jun 2003 02:26:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UKmE-0007WK-00; Mon, 23 Jun 2003 02:26:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19UKm9-0007WH-00; Mon, 23 Jun 2003 02:26:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UKmA-0003fs-5w; Mon, 23 Jun 2003 02:26:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UKlF-0003fM-LG for simple@optimus.ietf.org; Mon, 23 Jun 2003 02:25: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 CAA10338 for ; Mon, 23 Jun 2003 02:24:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UKkw-0007WA-00 for simple@ietf.org; Mon, 23 Jun 2003 02:24:46 -0400 Received: from il-tlv-firewall-main.icomverse.com ([192.118.48.248] helo=il-tlv-smtpout2.icomverse.com) by ietf-mx with esmtp (Exim 4.12) id 19UKkl-0007Vu-00 for simple@ietf.org; Mon, 23 Jun 2003 02:24:35 -0400 Received: from il-tlv-mbdg2.comverse.com (localhost.localdomain [127.0.0.1]) by il-tlv-smtpout2.icomverse.com (8.11.6/8.11.6) with ESMTP id h5N6OAo06126 for ; Mon, 23 Jun 2003 09:24:10 +0300 Received: by il-tlv-mbdg2.comverse.com with Internet Mail Service (5.5.2655.55) id ; Mon, 23 Jun 2003 09:24:14 +0300 Message-ID: <385D702A9C11D511A9E90008C7160AD50545445A@ISMAIL1> From: Cnaan Oded To: simple@ietf.org MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C33950.0D14DC86" Subject: [Simple] Single / multiple tuples 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, 23 Jun 2003 09:24:08 +0300 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C33950.0D14DC86 Content-Type: text/plain; charset="windows-1255" Single tuple ---------------- There are cases, where a PS would prefer using a single tuple to represent each device (or service) and specify all the services (devices) associated with it. For example, a tuple that represents a mobile phone that has an IM, PTT and voice services. This structure can be achieved using PIDF but the result would be very hard to manage or even understand. Following the above example, the tuple may look like that: online busy meeting offline im:imuser@mobilecarrier.net sip:pttuser@mobilecarrier.net tel:+44-254-54462211 There are several problem with this representation: 1. There is no way to associate each of the services with its matching contact. In other words, a UA cannot determine that the second contact element should be used for PTT. 2. There is no specification of a service name/ID. If a UA is running 2 IM clients (e.g., MSN and AOL), there is no way to determine which one is specified by the im:im element. Moreover, any additional information within the tuple cannot be associated with a specific service since there is no sufficient internal structuring. 3. The PS and UA must have a-priori agreed on the _extended_ elements and their meaning 4. There is no way to determine if the tuple represents a device or a service. 5. There is no way to specify, when a tuple represents a device, the device type (e.g., mobile phone) Note that RPIDS, which adds some information elements to the PIDF structure, does not provide any solutions to these problems as well. Several steps can be taken to fix these problems: 1. The first problem can be solved in several ways. One alternative would be to create an internal tuple format that structures the elements for each services. 2. A collection of elements (representing a device/service) would be given a name/ID that will be used for both UI representation (e.g., "MSN Messenger") and parsing. 3. This problem will probably not be completely solved and integration will be required. 4. Add an attribute to the tuple element that specifies what it represents. I understand that there is a big discussion on "what a tuple is" but we can also define 2-3 values and leave it to implementers to add their own. 5. Add an attribute to the tuple element specifying the device type. Again, some obvious values can be determined, leaving implementers to add their own in the future. Oded ------_=_NextPart_001_01C33950.0D14DC86 Content-Type: text/html; charset="windows-1255"
Single tuple
----------------
There are cases, where a PS would prefer using a single tuple to represent each device (or service) and specify all the services (devices) associated with it. For example, a tuple that represents a mobile phone that has an IM, PTT and voice services.
 
This structure can be achieved using PIDF but the result would be very hard to manage or even understand. Following the above example, the tuple may look like that:
 
<presence>
  <tuple id="A1">
    <status>
      <basic>online</basic>
      <im:im>busy</im:im>
       <ext:voice-call>meeting</ext:voice-call>
       <ext:ptt>offline</ext:ptt>
    </status>
    <contact>im:imuser@mobilecarrier.net</contact>
    <contact>sip:pttuser@mobilecarrier.net</contact>
    <contact>tel:+44-254-54462211</contact>
  </tuple>
</presence>
 
There are several problem with this representation:
1. There is no way to associate each of the services with its matching contact. In other words, a UA cannot determine that the second contact element should be used for PTT.
2. There is no specification of a service name/ID. If a UA is running 2 IM clients (e.g., MSN and AOL), there is no way to determine which one is specified by the im:im element. Moreover, any additional information within the tuple cannot be associated with a specific service since there is no sufficient internal structuring.
3. The PS and UA must have a-priori agreed on the _extended_ elements and their meaning
4. There is no way to determine if the tuple represents a device or a service.
5. There is no way to specify, when a tuple represents a device, the device type (e.g., mobile phone)
 
Note that RPIDS, which adds some information elements to the PIDF structure, does not provide any solutions to these problems as well.
 
Several steps can be taken to fix these problems:
1. The first problem can be solved in several ways. One alternative would be to create an internal tuple format that structures the elements for each services.
2. A collection of elements (representing a device/service) would be given a name/ID that will be used for both UI representation (e.g., "MSN Messenger") and parsing.
3. This problem will probably not be completely solved and integration will be required.
4. Add an attribute to the tuple element that specifies what it represents. I understand that there is a big discussion on "what a tuple is" but we can also define 2-3 values and leave it to implementers to add their own.
 5. Add an attribute to the tuple element specifying the device type. Again, some obvious values can be determined, leaving implementers to add their own in the future.
 
Oded
------_=_NextPart_001_01C33950.0D14DC86-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Jun 23 02:30:10 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 CAA10492; Mon, 23 Jun 2003 02:30:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UKq9-0007dB-00; Mon, 23 Jun 2003 02:30:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19UKq3-0007d5-00; Mon, 23 Jun 2003 02:30:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UKq2-0003sx-W0; Mon, 23 Jun 2003 02:30:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UKpd-0003sA-BV for simple@optimus.ietf.org; Mon, 23 Jun 2003 02:29: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 CAA10439 for ; Mon, 23 Jun 2003 02:29:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UKpZ-0007Y1-00 for simple@ietf.org; Mon, 23 Jun 2003 02:29:33 -0400 Received: from il-tlv-firewall-main.icomverse.com ([192.118.48.248] helo=il-tlv-smtpout1.icomverse.com) by ietf-mx with esmtp (Exim 4.12) id 19UKpO-0007Xw-00 for simple@ietf.org; Mon, 23 Jun 2003 02:29:22 -0400 Received: from il-tlv-mbdg2.comverse.com (localhost.localdomain [127.0.0.1]) by il-tlv-smtpout1.icomverse.com (8.11.6/8.11.6) with ESMTP id h5N6TBc28354 for ; Mon, 23 Jun 2003 09:29:11 +0300 Received: by il-tlv-mbdg2.comverse.com with Internet Mail Service (5.5.2655.55) id ; Mon, 23 Jun 2003 09:29:16 +0300 Message-ID: <385D702A9C11D511A9E90008C7160AD50545445B@ISMAIL1> From: Cnaan Oded To: simple@ietf.org MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C33950.BF40B844" Subject: [Simple] Single / multiple tuples 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, 23 Jun 2003 09:29:06 +0300 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C33950.BF40B844 Content-Type: text/plain; charset="windows-1255" Multiple tuples --------------------- The problems mentioned in my previous email can be facilitated if separate tuples are used to describe each service on the device, however, this causes data duplication as the device information needs to repeat several times. This problem can be solved by allowing a tuple to reference another tuple. In this case, the service tuples would reference the device tuple so that information is not repeated. online meeting tel:+44-254-54462211 busy im:imuser@mobilecarrier.net offline sip:pttuser@mobilecarrier.net Note that most of the problems mentioned in the previous email (in particular 2-5) are not solved by this new structuring and the solutions suggested for a single tuple are still required. Oded ------_=_NextPart_001_01C33950.BF40B844 Content-Type: text/html; charset="windows-1255"
Multiple tuples
---------------------
The problems mentioned in my previous email can be facilitated if separate tuples are used to describe each service on the device, however, this causes data duplication as the device information needs to repeat several times. This problem can be solved by allowing a tuple to reference another tuple. In this case, the service tuples would reference the device tuple so that information is not repeated.
 
<presence>
  <!-- this tuple represents the device itself -->
  <!-- voice may also be considered as a separate service in a separate tuple -->
  <tuple id="A1">
    <status>
      <basic>online</basic>
      <ext:voice-call>meeting</ext:voice-call>
    </status>
    <contact>tel:+44-254-54462211</contact>
  </tuple>
 
  <tuple id="A2" device-ref="A1">
    <status>
      <im:im>busy</im:im>
    </status>
    <contact>im:imuser@mobilecarrier.net</contact> 
  </tuple>
 
  <tuple id="A3" device-ref="A1">
    <status>
       <ext:ptt>offline</ext:ptt>
    </status>
    <contact>sip:pttuser@mobilecarrier.net</contact>
  </tuple>
</presence>
 
Note that most of the problems mentioned in the previous email (in particular 2-5) are not solved by this new structuring and the solutions suggested for a single tuple are still required.
 
Oded
 
------_=_NextPart_001_01C33950.BF40B844-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Jun 23 02:30:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10554 for ; Mon, 23 Jun 2003 02:30:41 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5N6UEW15192 for simple-archive@odin.ietf.org; Mon, 23 Jun 2003 02:30:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UKqE-0003wx-6O for simple-web-archive@optimus.ietf.org; Mon, 23 Jun 2003 02:30:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10492; Mon, 23 Jun 2003 02:30:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UKq9-0007dB-00; Mon, 23 Jun 2003 02:30:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19UKq3-0007d5-00; Mon, 23 Jun 2003 02:30:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UKq2-0003sx-W0; Mon, 23 Jun 2003 02:30:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UKpd-0003sA-BV for simple@optimus.ietf.org; Mon, 23 Jun 2003 02:29: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 CAA10439 for ; Mon, 23 Jun 2003 02:29:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UKpZ-0007Y1-00 for simple@ietf.org; Mon, 23 Jun 2003 02:29:33 -0400 Received: from il-tlv-firewall-main.icomverse.com ([192.118.48.248] helo=il-tlv-smtpout1.icomverse.com) by ietf-mx with esmtp (Exim 4.12) id 19UKpO-0007Xw-00 for simple@ietf.org; Mon, 23 Jun 2003 02:29:22 -0400 Received: from il-tlv-mbdg2.comverse.com (localhost.localdomain [127.0.0.1]) by il-tlv-smtpout1.icomverse.com (8.11.6/8.11.6) with ESMTP id h5N6TBc28354 for ; Mon, 23 Jun 2003 09:29:11 +0300 Received: by il-tlv-mbdg2.comverse.com with Internet Mail Service (5.5.2655.55) id ; Mon, 23 Jun 2003 09:29:16 +0300 Message-ID: <385D702A9C11D511A9E90008C7160AD50545445B@ISMAIL1> From: Cnaan Oded To: simple@ietf.org MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C33950.BF40B844" Subject: [Simple] Single / multiple tuples 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, 23 Jun 2003 09:29:06 +0300 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C33950.BF40B844 Content-Type: text/plain; charset="windows-1255" Multiple tuples --------------------- The problems mentioned in my previous email can be facilitated if separate tuples are used to describe each service on the device, however, this causes data duplication as the device information needs to repeat several times. This problem can be solved by allowing a tuple to reference another tuple. In this case, the service tuples would reference the device tuple so that information is not repeated. online meeting tel:+44-254-54462211 busy im:imuser@mobilecarrier.net offline sip:pttuser@mobilecarrier.net Note that most of the problems mentioned in the previous email (in particular 2-5) are not solved by this new structuring and the solutions suggested for a single tuple are still required. Oded ------_=_NextPart_001_01C33950.BF40B844 Content-Type: text/html; charset="windows-1255"
Multiple tuples
---------------------
The problems mentioned in my previous email can be facilitated if separate tuples are used to describe each service on the device, however, this causes data duplication as the device information needs to repeat several times. This problem can be solved by allowing a tuple to reference another tuple. In this case, the service tuples would reference the device tuple so that information is not repeated.
 
<presence>
  <!-- this tuple represents the device itself -->
  <!-- voice may also be considered as a separate service in a separate tuple -->
  <tuple id="A1">
    <status>
      <basic>online</basic>
      <ext:voice-call>meeting</ext:voice-call>
    </status>
    <contact>tel:+44-254-54462211</contact>
  </tuple>
 
  <tuple id="A2" device-ref="A1">
    <status>
      <im:im>busy</im:im>
    </status>
    <contact>im:imuser@mobilecarrier.net</contact> 
  </tuple>
 
  <tuple id="A3" device-ref="A1">
    <status>
       <ext:ptt>offline</ext:ptt>
    </status>
    <contact>sip:pttuser@mobilecarrier.net</contact>
  </tuple>
</presence>
 
Note that most of the problems mentioned in the previous email (in particular 2-5) are not solved by this new structuring and the solutions suggested for a single tuple are still required.
 
Oded
 
------_=_NextPart_001_01C33950.BF40B844-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Jun 23 09:36:21 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 JAA19956; Mon, 23 Jun 2003 09:36:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19URUc-0002F6-00; Mon, 23 Jun 2003 09:36:22 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19URUX-0002Ew-00; Mon, 23 Jun 2003 09:36:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19URUG-0000hI-LJ; Mon, 23 Jun 2003 09:36:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19URTS-0000gl-KD for simple@optimus.ietf.org; Mon, 23 Jun 2003 09:35:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19938 for ; Mon, 23 Jun 2003 09:35:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19URTQ-0002EU-00 for simple@ietf.org; Mon, 23 Jun 2003 09:35:08 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 19URTA-0002EJ-00 for simple@ietf.org; Mon, 23 Jun 2003 09:34:52 -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 h5NDYMkM011342; Mon, 23 Jun 2003 09:34:22 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h5NDYKN06260; Mon, 23 Jun 2003 09:34:20 -0400 Message-ID: <3EF700F3.1030602@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030603 Thunderbird/0.1a X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cnaan Oded CC: simple@ietf.org Subject: Re: [Simple] Single / multiple tuples References: <385D702A9C11D511A9E90008C7160AD50545445A@ISMAIL1> In-Reply-To: <385D702A9C11D511A9E90008C7160AD50545445A@ISMAIL1> 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, 23 Jun 2003 09:30:27 -0400 Content-Transfer-Encoding: 7bit Cnaan Oded wrote: > Single tuple > ---------------- > This structure can be achieved using PIDF but the result would be very > hard to manage or even understand. Following the above example, the > tuple may look like that: > > > > > online > busy > meeting > offline > > im:imuser@mobilecarrier.net > sip:pttuser@mobilecarrier.net > tel:+44-254-54462211 > > > > 4. There is no way to determine if the tuple represents a device or a > service. > 5. There is no way to specify, when a tuple represents a device, the > device type (e.g., mobile phone) > > Note that RPIDS, which adds some information elements to the PIDF > structure, does not provide any solutions to these problems as well. Based on a 'regularized' proposal of tuple view that has been discussed, the problem is avoided by having each tuple have no more than one Contact (plus an AOR reference). This follows standard design rules for relational databases, where having multiple columns that have the same content is generally considered a bad idea. Once you have that, composition rules can be used by various entities to compose any desired view. > > Several steps can be taken to fix these problems: > 1. The first problem can be solved in several ways. One alternative > would be to create an internal tuple format that structures the elements > for each services. > 2. A collection of elements (representing a device/service) would be > given a name/ID that will be used for both UI representation (e.g., "MSN > Messenger") and parsing. The new RPIDS drafts, submitted early this morning and found at http://www1.cs.columbia.edu/sip/drafts/draft-ietf-simple-rpids-00.txt, offers the 'class' attribute for this, if I understand you correctly. I didn't get to write up the tuple composition rules in the draft yet, unfortunately. > 3. This problem will probably not be completely solved and integration > will be required. > 4. Add an attribute to the tuple element that specifies what it > represents. I understand that there is a big discussion on "what a tuple > is" but we can also define 2-3 values and leave it to implementers to > add their own. In my personal opinion, until somebody provides a clear and concise definitions of these 'what a tuple represents' labels, I see this doing more harm than good. Labeling conveys certainty where none exists and thus encourages brittle implementations that only deal with the set of labels that the implementor considers important (or existed at the time the implementation was written). > 5. Add an attribute to the tuple element specifying the device type. > Again, some obvious values can be determined, leaving implementers to > add their own in the future. I'm afraid there are no 'obvious' values, but maybe you have suggestions. > > Oded _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Jun 23 09:36:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19992 for ; Mon, 23 Jun 2003 09:36:52 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5NDaPM02990 for simple-archive@odin.ietf.org; Mon, 23 Jun 2003 09:36:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19URUf-0000m9-3M for simple-web-archive@optimus.ietf.org; Mon, 23 Jun 2003 09:36:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19956; Mon, 23 Jun 2003 09:36:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19URUc-0002F6-00; Mon, 23 Jun 2003 09:36:22 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19URUX-0002Ew-00; Mon, 23 Jun 2003 09:36:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19URUG-0000hI-LJ; Mon, 23 Jun 2003 09:36:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19URTS-0000gl-KD for simple@optimus.ietf.org; Mon, 23 Jun 2003 09:35:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19938 for ; Mon, 23 Jun 2003 09:35:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19URTQ-0002EU-00 for simple@ietf.org; Mon, 23 Jun 2003 09:35:08 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 19URTA-0002EJ-00 for simple@ietf.org; Mon, 23 Jun 2003 09:34:52 -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 h5NDYMkM011342; Mon, 23 Jun 2003 09:34:22 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h5NDYKN06260; Mon, 23 Jun 2003 09:34:20 -0400 Message-ID: <3EF700F3.1030602@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030603 Thunderbird/0.1a X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cnaan Oded CC: simple@ietf.org Subject: Re: [Simple] Single / multiple tuples References: <385D702A9C11D511A9E90008C7160AD50545445A@ISMAIL1> In-Reply-To: <385D702A9C11D511A9E90008C7160AD50545445A@ISMAIL1> 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, 23 Jun 2003 09:30:27 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cnaan Oded wrote: > Single tuple > ---------------- > This structure can be achieved using PIDF but the result would be very > hard to manage or even understand. Following the above example, the > tuple may look like that: > > > > > online > busy > meeting > offline > > im:imuser@mobilecarrier.net > sip:pttuser@mobilecarrier.net > tel:+44-254-54462211 > > > > 4. There is no way to determine if the tuple represents a device or a > service. > 5. There is no way to specify, when a tuple represents a device, the > device type (e.g., mobile phone) > > Note that RPIDS, which adds some information elements to the PIDF > structure, does not provide any solutions to these problems as well. Based on a 'regularized' proposal of tuple view that has been discussed, the problem is avoided by having each tuple have no more than one Contact (plus an AOR reference). This follows standard design rules for relational databases, where having multiple columns that have the same content is generally considered a bad idea. Once you have that, composition rules can be used by various entities to compose any desired view. > > Several steps can be taken to fix these problems: > 1. The first problem can be solved in several ways. One alternative > would be to create an internal tuple format that structures the elements > for each services. > 2. A collection of elements (representing a device/service) would be > given a name/ID that will be used for both UI representation (e.g., "MSN > Messenger") and parsing. The new RPIDS drafts, submitted early this morning and found at http://www1.cs.columbia.edu/sip/drafts/draft-ietf-simple-rpids-00.txt, offers the 'class' attribute for this, if I understand you correctly. I didn't get to write up the tuple composition rules in the draft yet, unfortunately. > 3. This problem will probably not be completely solved and integration > will be required. > 4. Add an attribute to the tuple element that specifies what it > represents. I understand that there is a big discussion on "what a tuple > is" but we can also define 2-3 values and leave it to implementers to > add their own. In my personal opinion, until somebody provides a clear and concise definitions of these 'what a tuple represents' labels, I see this doing more harm than good. Labeling conveys certainty where none exists and thus encourages brittle implementations that only deal with the set of labels that the implementor considers important (or existed at the time the implementation was written). > 5. Add an attribute to the tuple element specifying the device type. > Again, some obvious values can be determined, leaving implementers to > add their own in the future. I'm afraid there are no 'obvious' values, but maybe you have suggestions. > > Oded _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Jun 23 09:48:07 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 JAA20324; Mon, 23 Jun 2003 09:48:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19URg0-0002LA-00; Mon, 23 Jun 2003 09:48:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19URfv-0002L7-00; Mon, 23 Jun 2003 09:48:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19URft-0001Y3-8B; Mon, 23 Jun 2003 09:48:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19URet-0001OX-Ld for simple@optimus.ietf.org; Mon, 23 Jun 2003 09:47:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20309 for ; Mon, 23 Jun 2003 09:46:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19URer-0002KT-00 for simple@ietf.org; Mon, 23 Jun 2003 09:46:57 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by ietf-mx with esmtp (Exim 4.12) id 19UReh-0002Ju-00 for simple@ietf.org; Mon, 23 Jun 2003 09:46:47 -0400 Received: from cannon.cisco.com (IDENT:mirapoint@cannon.cisco.com [161.44.118.24]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h5NDjbai008124; Mon, 23 Jun 2003 09:45:37 -0400 (EDT) Received: from cisco.com ([161.44.79.70]) by cannon.cisco.com (Mirapoint) with ESMTP id ABL53454; Mon, 23 Jun 2003 09:54:33 -0400 (EDT) Message-ID: <3EF7047D.2010001@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: Cnaan Oded CC: "'Thanos Diacakis'" , hisham.khartabil@nokia.com, aki.niemi@nokia.com, simple@ietf.org Subject: Re: [Simple] PUBLISH: identification of presence segments References: <385D702A9C11D511A9E90008C7160AD505454454@ISMAIL1> 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, 23 Jun 2003 09:45:33 -0400 Content-Transfer-Encoding: 7bit Oded, Your examples exhibit a misconception: they are using multiple entries per tuple, but only one is permitted. I suspect that correcting that will require changes to your thesis, so I am not going to otherwise comment yet. Paul Cnaan Oded wrote: > I hope that we can agree, that in a typical implementation, users will not > be exposed to tuples and might not even know that they exist. Tuples are > just a method for describing Presence information in a hierarchical way that > can be understood by UAs (and PSs). Saying that, it would be very rare to > have _users_ selecting tuple IDs or referring to tuples by their names. In > most cases, users will change their 'Video' availability and have their UA > handle the details for them. > > I believe that the tuple identification problem is caused by using the same > Presence document for both PUBLISH and NOTIFY. Let's take for example user A > with the following Presence document, as generated by the PS (schematic > syntax): > > > > > online > busy > meeting > > im:someone@mobilecarrier.net > tel:+44-254-54462211 > > > > > online > offline > > im:someone@mobilecarrier.net > > > > The first tuple represents a mobile phone that runs an IM client and that is > capable of receiving phone calls. The latter describes a PC running an IM > client from the same service provider. Changing the IM availability on the > PC requires the PC to recognize that the phone has published voice > capabilities as part of the same tuple and even to re-publish information > related to the phone. > > > A different approach would be to have publishers send only raw information, > leaving the document composition task to the Presence Server. This allows > the PS to apply rules as well as transformations on the raw information, > without the need to 'identify' tuples. Doing so, also solves the problem of > tuple IDs as only the server now generates them. > > When publishing Presence information, there are 3 basic questions to answer: > 1. What is the information element that we would like to update (e.g., MSN > IM Service) > 2. What is the new value of the information element (e.g., status is BUSY > and contact is ...) > 3. To which device/service this element belongs (e.g., specific phone) > > These questions can be used on any Presence view (i.e., Device/Service/Media > based). For example, in a service-view, the third answer may be "specific > service". > > Now, let's see how this new approach facilitates the publication problems > identified by Thanos, Hisham and Aki. > 1. Thanos showed that having 2 UAs publish using the same tuple ID may > result in a conflict on the PS. Here, tuple IDs are not used for > publication. If 2 UAs publish a new IM status, they do not relate to a > specific tuple, but to the same service. > 2. Thanos also raised the problem of having PS change tuple IDs based on > some server based rules (e.g., transformation rules). Here, there is no > conflict as the UA publishes raw info regardless of the tuple structure. > 3. Aki suggested to restrict the composer so that published tuples are never > merged or modified. This is no longer required as we've separated between > the published info and the Presence document sent to watchers. > 4. Hisham raised the question of relating 2 tuples and mentioned that in > some circumstances, there would be a need to publish the whole document to > avoid conflicts.. This is a non-issue as we now publish raw info not related > to a specific tuple. > > We can now build an XML document that will be used for publications. This > document needs to answer the above questions and, for optimization, allow > publishing more than one update at a time. It will be used as part of > PUBLISH messages while PIDF will continue to serve NOTIFY messages. > > I understand that this idea conflicts previous PUBLISH drafts but I hope > you'll consider it as it solves many of the problems identified in this > thread. > > Oded > > > _______________________________________________ > Simple mailing 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 Jun 23 09:48:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20359 for ; Mon, 23 Jun 2003 09:48:38 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5NDmBM06145 for simple-archive@odin.ietf.org; Mon, 23 Jun 2003 09:48:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19URg3-0001b2-9r for simple-web-archive@optimus.ietf.org; Mon, 23 Jun 2003 09:48: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 JAA20324; Mon, 23 Jun 2003 09:48:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19URg0-0002LA-00; Mon, 23 Jun 2003 09:48:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19URfv-0002L7-00; Mon, 23 Jun 2003 09:48:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19URft-0001Y3-8B; Mon, 23 Jun 2003 09:48:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19URet-0001OX-Ld for simple@optimus.ietf.org; Mon, 23 Jun 2003 09:47:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20309 for ; Mon, 23 Jun 2003 09:46:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19URer-0002KT-00 for simple@ietf.org; Mon, 23 Jun 2003 09:46:57 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by ietf-mx with esmtp (Exim 4.12) id 19UReh-0002Ju-00 for simple@ietf.org; Mon, 23 Jun 2003 09:46:47 -0400 Received: from cannon.cisco.com (IDENT:mirapoint@cannon.cisco.com [161.44.118.24]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h5NDjbai008124; Mon, 23 Jun 2003 09:45:37 -0400 (EDT) Received: from cisco.com ([161.44.79.70]) by cannon.cisco.com (Mirapoint) with ESMTP id ABL53454; Mon, 23 Jun 2003 09:54:33 -0400 (EDT) Message-ID: <3EF7047D.2010001@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: Cnaan Oded CC: "'Thanos Diacakis'" , hisham.khartabil@nokia.com, aki.niemi@nokia.com, simple@ietf.org Subject: Re: [Simple] PUBLISH: identification of presence segments References: <385D702A9C11D511A9E90008C7160AD505454454@ISMAIL1> 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, 23 Jun 2003 09:45:33 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Oded, Your examples exhibit a misconception: they are using multiple entries per tuple, but only one is permitted. I suspect that correcting that will require changes to your thesis, so I am not going to otherwise comment yet. Paul Cnaan Oded wrote: > I hope that we can agree, that in a typical implementation, users will not > be exposed to tuples and might not even know that they exist. Tuples are > just a method for describing Presence information in a hierarchical way that > can be understood by UAs (and PSs). Saying that, it would be very rare to > have _users_ selecting tuple IDs or referring to tuples by their names. In > most cases, users will change their 'Video' availability and have their UA > handle the details for them. > > I believe that the tuple identification problem is caused by using the same > Presence document for both PUBLISH and NOTIFY. Let's take for example user A > with the following Presence document, as generated by the PS (schematic > syntax): > > > > > online > busy > meeting > > im:someone@mobilecarrier.net > tel:+44-254-54462211 > > > > > online > offline > > im:someone@mobilecarrier.net > > > > The first tuple represents a mobile phone that runs an IM client and that is > capable of receiving phone calls. The latter describes a PC running an IM > client from the same service provider. Changing the IM availability on the > PC requires the PC to recognize that the phone has published voice > capabilities as part of the same tuple and even to re-publish information > related to the phone. > > > A different approach would be to have publishers send only raw information, > leaving the document composition task to the Presence Server. This allows > the PS to apply rules as well as transformations on the raw information, > without the need to 'identify' tuples. Doing so, also solves the problem of > tuple IDs as only the server now generates them. > > When publishing Presence information, there are 3 basic questions to answer: > 1. What is the information element that we would like to update (e.g., MSN > IM Service) > 2. What is the new value of the information element (e.g., status is BUSY > and contact is ...) > 3. To which device/service this element belongs (e.g., specific phone) > > These questions can be used on any Presence view (i.e., Device/Service/Media > based). For example, in a service-view, the third answer may be "specific > service". > > Now, let's see how this new approach facilitates the publication problems > identified by Thanos, Hisham and Aki. > 1. Thanos showed that having 2 UAs publish using the same tuple ID may > result in a conflict on the PS. Here, tuple IDs are not used for > publication. If 2 UAs publish a new IM status, they do not relate to a > specific tuple, but to the same service. > 2. Thanos also raised the problem of having PS change tuple IDs based on > some server based rules (e.g., transformation rules). Here, there is no > conflict as the UA publishes raw info regardless of the tuple structure. > 3. Aki suggested to restrict the composer so that published tuples are never > merged or modified. This is no longer required as we've separated between > the published info and the Presence document sent to watchers. > 4. Hisham raised the question of relating 2 tuples and mentioned that in > some circumstances, there would be a need to publish the whole document to > avoid conflicts.. This is a non-issue as we now publish raw info not related > to a specific tuple. > > We can now build an XML document that will be used for publications. This > document needs to answer the above questions and, for optimization, allow > publishing more than one update at a time. It will be used as part of > PUBLISH messages while PIDF will continue to serve NOTIFY messages. > > I understand that this idea conflicts previous PUBLISH drafts but I hope > you'll consider it as it solves many of the problems identified in this > thread. > > Oded > > > _______________________________________________ > Simple mailing 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 Jun 23 09:52:06 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 JAA20436; Mon, 23 Jun 2003 09:52:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19URjr-0002Mu-00; Mon, 23 Jun 2003 09:52:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19URjl-0002Mr-00; Mon, 23 Jun 2003 09:52:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19URjk-0001m3-VO; Mon, 23 Jun 2003 09:52:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19URj4-0001hr-Ol for simple@optimus.ietf.org; Mon, 23 Jun 2003 09:51:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20423 for ; Mon, 23 Jun 2003 09:51:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19URj2-0002MU-00 for simple@ietf.org; Mon, 23 Jun 2003 09:51:16 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by ietf-mx with esmtp (Exim 4.12) id 19URis-0002MH-00 for simple@ietf.org; Mon, 23 Jun 2003 09:51:06 -0400 Received: from cannon.cisco.com (IDENT:mirapoint@cannon.cisco.com [161.44.118.24]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h5NDoDdJ029474; Mon, 23 Jun 2003 09:50:14 -0400 (EDT) Received: from cisco.com ([161.44.79.70]) by cannon.cisco.com (Mirapoint) with ESMTP id ABL53510; Mon, 23 Jun 2003 09:59:11 -0400 (EDT) Message-ID: <3EF70593.6000909@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: Cnaan Oded CC: simple@ietf.org Subject: Re: [Simple] Single / multiple tuples References: <385D702A9C11D511A9E90008C7160AD50545445A@ISMAIL1> 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, 23 Jun 2003 09:50:11 -0400 Content-Transfer-Encoding: 7bit Oded, As I commented in an earlier reply, you can't use multiple contacts in a single tuple, so your examples require some rework. However you do bring up something I want to ask about: You talk about "IM, PTT and voice services". This concept of "service" has been bandied about here, but I have never been able to get a clear understanding of what it means. Can you define what you mean by "service"? How is it different from "device" or "media"? Paul Cnaan Oded wrote: > Single tuple > ---------------- > There are cases, where a PS would prefer using a single tuple to > represent each device (or service) and specify all the services > (devices) associated with it. For example, a tuple that represents a > mobile phone that has an IM, PTT and voice services. > > This structure can be achieved using PIDF but the result would be very > hard to manage or even understand. Following the above example, the > tuple may look like that: > > > > > online > busy > meeting > offline > > im:imuser@mobilecarrier.net > sip:pttuser@mobilecarrier.net > tel:+44-254-54462211 > > > > There are several problem with this representation: > 1. There is no way to associate each of the services with its matching > contact. In other words, a UA cannot determine that the second contact > element should be used for PTT. > 2. There is no specification of a service name/ID. If a UA is running 2 > IM clients (e.g., MSN and AOL), there is no way to determine which one > is specified by the im:im element. Moreover, any additional information > within the tuple cannot be associated with a specific service since > there is no sufficient internal structuring. > 3. The PS and UA must have a-priori agreed on the _extended_ elements > and their meaning > 4. There is no way to determine if the tuple represents a device or a > service. > 5. There is no way to specify, when a tuple represents a device, the > device type (e.g., mobile phone) > > Note that RPIDS, which adds some information elements to the PIDF > structure, does not provide any solutions to these problems as well. > > Several steps can be taken to fix these problems: > 1. The first problem can be solved in several ways. One alternative > would be to create an internal tuple format that structures the elements > for each services. > 2. A collection of elements (representing a device/service) would be > given a name/ID that will be used for both UI representation (e.g., "MSN > Messenger") and parsing. > 3. This problem will probably not be completely solved and integration > will be required. > 4. Add an attribute to the tuple element that specifies what it > represents. I understand that there is a big discussion on "what a tuple > is" but we can also define 2-3 values and leave it to implementers to > add their own. > 5. Add an attribute to the tuple element specifying the device type. > Again, some obvious values can be determined, leaving implementers to > add their own in the future. > > Oded _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Jun 23 09:52:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20471 for ; Mon, 23 Jun 2003 09:52:36 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5NDq9R07019 for simple-archive@odin.ietf.org; Mon, 23 Jun 2003 09:52:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19URjt-0001p8-LV for simple-web-archive@optimus.ietf.org; Mon, 23 Jun 2003 09:52: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 JAA20436; Mon, 23 Jun 2003 09:52:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19URjr-0002Mu-00; Mon, 23 Jun 2003 09:52:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19URjl-0002Mr-00; Mon, 23 Jun 2003 09:52:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19URjk-0001m3-VO; Mon, 23 Jun 2003 09:52:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19URj4-0001hr-Ol for simple@optimus.ietf.org; Mon, 23 Jun 2003 09:51:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20423 for ; Mon, 23 Jun 2003 09:51:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19URj2-0002MU-00 for simple@ietf.org; Mon, 23 Jun 2003 09:51:16 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by ietf-mx with esmtp (Exim 4.12) id 19URis-0002MH-00 for simple@ietf.org; Mon, 23 Jun 2003 09:51:06 -0400 Received: from cannon.cisco.com (IDENT:mirapoint@cannon.cisco.com [161.44.118.24]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h5NDoDdJ029474; Mon, 23 Jun 2003 09:50:14 -0400 (EDT) Received: from cisco.com ([161.44.79.70]) by cannon.cisco.com (Mirapoint) with ESMTP id ABL53510; Mon, 23 Jun 2003 09:59:11 -0400 (EDT) Message-ID: <3EF70593.6000909@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: Cnaan Oded CC: simple@ietf.org Subject: Re: [Simple] Single / multiple tuples References: <385D702A9C11D511A9E90008C7160AD50545445A@ISMAIL1> 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, 23 Jun 2003 09:50:11 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Oded, As I commented in an earlier reply, you can't use multiple contacts in a single tuple, so your examples require some rework. However you do bring up something I want to ask about: You talk about "IM, PTT and voice services". This concept of "service" has been bandied about here, but I have never been able to get a clear understanding of what it means. Can you define what you mean by "service"? How is it different from "device" or "media"? Paul Cnaan Oded wrote: > Single tuple > ---------------- > There are cases, where a PS would prefer using a single tuple to > represent each device (or service) and specify all the services > (devices) associated with it. For example, a tuple that represents a > mobile phone that has an IM, PTT and voice services. > > This structure can be achieved using PIDF but the result would be very > hard to manage or even understand. Following the above example, the > tuple may look like that: > > > > > online > busy > meeting > offline > > im:imuser@mobilecarrier.net > sip:pttuser@mobilecarrier.net > tel:+44-254-54462211 > > > > There are several problem with this representation: > 1. There is no way to associate each of the services with its matching > contact. In other words, a UA cannot determine that the second contact > element should be used for PTT. > 2. There is no specification of a service name/ID. If a UA is running 2 > IM clients (e.g., MSN and AOL), there is no way to determine which one > is specified by the im:im element. Moreover, any additional information > within the tuple cannot be associated with a specific service since > there is no sufficient internal structuring. > 3. The PS and UA must have a-priori agreed on the _extended_ elements > and their meaning > 4. There is no way to determine if the tuple represents a device or a > service. > 5. There is no way to specify, when a tuple represents a device, the > device type (e.g., mobile phone) > > Note that RPIDS, which adds some information elements to the PIDF > structure, does not provide any solutions to these problems as well. > > Several steps can be taken to fix these problems: > 1. The first problem can be solved in several ways. One alternative > would be to create an internal tuple format that structures the elements > for each services. > 2. A collection of elements (representing a device/service) would be > given a name/ID that will be used for both UI representation (e.g., "MSN > Messenger") and parsing. > 3. This problem will probably not be completely solved and integration > will be required. > 4. Add an attribute to the tuple element that specifies what it > represents. I understand that there is a big discussion on "what a tuple > is" but we can also define 2-3 values and leave it to implementers to > add their own. > 5. Add an attribute to the tuple element specifying the device type. > Again, some obvious values can be determined, leaving implementers to > add their own in the future. > > Oded _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Jun 23 10:02:07 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 KAA20657; Mon, 23 Jun 2003 10:02:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19URtY-0002PI-00; Mon, 23 Jun 2003 10:02:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19URtS-0002PF-00; Mon, 23 Jun 2003 10:02:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19URtR-00021A-Ap; Mon, 23 Jun 2003 10:02:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19URtB-00020w-QD for simple@optimus.ietf.org; Mon, 23 Jun 2003 10:01: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 KAA20648 for ; Mon, 23 Jun 2003 10:01:42 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19URt9-0002PC-00 for simple@ietf.org; Mon, 23 Jun 2003 10:01:43 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19URsy-0002P5-00 for simple@ietf.org; Mon, 23 Jun 2003 10:01:32 -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 h5NE1Ba01667 for ; Mon, 23 Jun 2003 17:01:11 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 23 Jun 2003 17:01:10 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 23 Jun 2003 17:01:10 +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] Single / multiple tuples Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701796E19@esebe019.ntc.nokia.com> Thread-Topic: [Simple] Single / multiple tuples Thread-Index: AcM5jqSO9B5/d1x5Sdmq5VRZF9RIrgAAPg1g To: , Cc: X-OriginalArrivalTime: 23 Jun 2003 14:01:10.0601 (UTC) FILETIME=[E6748B90:01C3398F] 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, 23 Jun 2003 17:01:10 +0300 Content-Transfer-Encoding: quoted-printable Is geoloc considered device or media? It is a service, but not a device = nor media. /Hisham > -----Original Message----- > From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Monday, June 23, 2003 4:50 PM > To: Cnaan Oded > Cc: simple@ietf.org > Subject: Re: [Simple] Single / multiple tuples >=20 >=20 > Oded, >=20 > As I commented in an earlier reply, you can't use multiple=20 > contacts in a=20 > single tuple, so your examples require some rework. However=20 > you do bring=20 > up something I want to ask about: >=20 > You talk about "IM, PTT and voice services". This concept of=20 > "service"=20 > has been bandied about here, but I have never been able to=20 > get a clear=20 > understanding of what it means. Can you define what you mean by=20 > "service"? How is it different from "device" or "media"? >=20 > Paul >=20 > Cnaan Oded wrote: > > Single tuple > > ---------------- > > There are cases, where a PS would prefer using a single tuple to=20 > > represent each device (or service) and specify all the services=20 > > (devices) associated with it. For example, a tuple that=20 > represents a=20 > > mobile phone that has an IM, PTT and voice services. > > =20 > > This structure can be achieved using PIDF but the result=20 > would be very=20 > > hard to manage or even understand. Following the above example, the=20 > > tuple may look like that: > > =20 > > > > > > > > online > > busy > > meeting > > offline > > > > im:imuser@mobilecarrier.net > > sip:pttuser@mobilecarrier.net > > tel:+44-254-54462211 > > > > > > =20 > > There are several problem with this representation: > > 1. There is no way to associate each of the services with=20 > its matching=20 > > contact. In other words, a UA cannot determine that the=20 > second contact=20 > > element should be used for PTT. > > 2. There is no specification of a service name/ID. If a UA=20 > is running 2=20 > > IM clients (e.g., MSN and AOL), there is no way to=20 > determine which one=20 > > is specified by the im:im element. Moreover, any additional=20 > information=20 > > within the tuple cannot be associated with a specific service since=20 > > there is no sufficient internal structuring. > > 3. The PS and UA must have a-priori agreed on the=20 > _extended_ elements=20 > > and their meaning > > 4. There is no way to determine if the tuple represents a=20 > device or a=20 > > service. > > 5. There is no way to specify, when a tuple represents a=20 > device, the=20 > > device type (e.g., mobile phone) > > =20 > > Note that RPIDS, which adds some information elements to the PIDF=20 > > structure, does not provide any solutions to these problems as well. > > =20 > > Several steps can be taken to fix these problems: > > 1. The first problem can be solved in several ways. One alternative=20 > > would be to create an internal tuple format that structures=20 > the elements=20 > > for each services. > > 2. A collection of elements (representing a device/service)=20 > would be=20 > > given a name/ID that will be used for both UI=20 > representation (e.g., "MSN=20 > > Messenger") and parsing. > > 3. This problem will probably not be completely solved and=20 > integration=20 > > will be required. > > 4. Add an attribute to the tuple element that specifies what it=20 > > represents. I understand that there is a big discussion on=20 > "what a tuple=20 > > is" but we can also define 2-3 values and leave it to=20 > implementers to=20 > > add their own. > > 5. Add an attribute to the tuple element specifying the=20 > device type.=20 > > Again, some obvious values can be determined, leaving=20 > implementers to=20 > > add their own in the future. > > =20 > > Oded >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Jun 23 10:02:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20689 for ; Mon, 23 Jun 2003 10:02:38 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5NE2B307946 for simple-archive@odin.ietf.org; Mon, 23 Jun 2003 10:02:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19URtb-000245-3N for simple-web-archive@optimus.ietf.org; Mon, 23 Jun 2003 10:02: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 KAA20657; Mon, 23 Jun 2003 10:02:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19URtY-0002PI-00; Mon, 23 Jun 2003 10:02:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19URtS-0002PF-00; Mon, 23 Jun 2003 10:02:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19URtR-00021A-Ap; Mon, 23 Jun 2003 10:02:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19URtB-00020w-QD for simple@optimus.ietf.org; Mon, 23 Jun 2003 10:01: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 KAA20648 for ; Mon, 23 Jun 2003 10:01:42 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19URt9-0002PC-00 for simple@ietf.org; Mon, 23 Jun 2003 10:01:43 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19URsy-0002P5-00 for simple@ietf.org; Mon, 23 Jun 2003 10:01:32 -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 h5NE1Ba01667 for ; Mon, 23 Jun 2003 17:01:11 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 23 Jun 2003 17:01:10 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 23 Jun 2003 17:01:10 +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] Single / multiple tuples Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701796E19@esebe019.ntc.nokia.com> Thread-Topic: [Simple] Single / multiple tuples Thread-Index: AcM5jqSO9B5/d1x5Sdmq5VRZF9RIrgAAPg1g To: , Cc: X-OriginalArrivalTime: 23 Jun 2003 14:01:10.0601 (UTC) FILETIME=[E6748B90:01C3398F] 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, 23 Jun 2003 17:01:10 +0300 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Is geoloc considered device or media? It is a service, but not a device = nor media. /Hisham > -----Original Message----- > From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Monday, June 23, 2003 4:50 PM > To: Cnaan Oded > Cc: simple@ietf.org > Subject: Re: [Simple] Single / multiple tuples >=20 >=20 > Oded, >=20 > As I commented in an earlier reply, you can't use multiple=20 > contacts in a=20 > single tuple, so your examples require some rework. However=20 > you do bring=20 > up something I want to ask about: >=20 > You talk about "IM, PTT and voice services". This concept of=20 > "service"=20 > has been bandied about here, but I have never been able to=20 > get a clear=20 > understanding of what it means. Can you define what you mean by=20 > "service"? How is it different from "device" or "media"? >=20 > Paul >=20 > Cnaan Oded wrote: > > Single tuple > > ---------------- > > There are cases, where a PS would prefer using a single tuple to=20 > > represent each device (or service) and specify all the services=20 > > (devices) associated with it. For example, a tuple that=20 > represents a=20 > > mobile phone that has an IM, PTT and voice services. > > =20 > > This structure can be achieved using PIDF but the result=20 > would be very=20 > > hard to manage or even understand. Following the above example, the=20 > > tuple may look like that: > > =20 > > > > > > > > online > > busy > > meeting > > offline > > > > im:imuser@mobilecarrier.net > > sip:pttuser@mobilecarrier.net > > tel:+44-254-54462211 > > > > > > =20 > > There are several problem with this representation: > > 1. There is no way to associate each of the services with=20 > its matching=20 > > contact. In other words, a UA cannot determine that the=20 > second contact=20 > > element should be used for PTT. > > 2. There is no specification of a service name/ID. If a UA=20 > is running 2=20 > > IM clients (e.g., MSN and AOL), there is no way to=20 > determine which one=20 > > is specified by the im:im element. Moreover, any additional=20 > information=20 > > within the tuple cannot be associated with a specific service since=20 > > there is no sufficient internal structuring. > > 3. The PS and UA must have a-priori agreed on the=20 > _extended_ elements=20 > > and their meaning > > 4. There is no way to determine if the tuple represents a=20 > device or a=20 > > service. > > 5. There is no way to specify, when a tuple represents a=20 > device, the=20 > > device type (e.g., mobile phone) > > =20 > > Note that RPIDS, which adds some information elements to the PIDF=20 > > structure, does not provide any solutions to these problems as well. > > =20 > > Several steps can be taken to fix these problems: > > 1. The first problem can be solved in several ways. One alternative=20 > > would be to create an internal tuple format that structures=20 > the elements=20 > > for each services. > > 2. A collection of elements (representing a device/service)=20 > would be=20 > > given a name/ID that will be used for both UI=20 > representation (e.g., "MSN=20 > > Messenger") and parsing. > > 3. This problem will probably not be completely solved and=20 > integration=20 > > will be required. > > 4. Add an attribute to the tuple element that specifies what it=20 > > represents. I understand that there is a big discussion on=20 > "what a tuple=20 > > is" but we can also define 2-3 values and leave it to=20 > implementers to=20 > > add their own. > > 5. Add an attribute to the tuple element specifying the=20 > device type.=20 > > Again, some obvious values can be determined, leaving=20 > implementers to=20 > > add their own in the future. > > =20 > > Oded >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Jun 23 18:34: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 SAA13728; Mon, 23 Jun 2003 18:34:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UZt0-0006Dr-00; Mon, 23 Jun 2003 18:34:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19UZsu-0006Do-00; Mon, 23 Jun 2003 18:34:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UZsv-00078o-2n; Mon, 23 Jun 2003 18:34:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UZrv-00077Z-Ia for simple@optimus.ietf.org; Mon, 23 Jun 2003 18:33:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13689 for ; Mon, 23 Jun 2003 18:32:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UZrs-0006DP-00 for simple@ietf.org; Mon, 23 Jun 2003 18:32:56 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by ietf-mx with esmtp (Exim 4.12) id 19UZrh-0006DB-00 for simple@ietf.org; Mon, 23 Jun 2003 18:32:46 -0400 Received: from cannon.cisco.com (IDENT:mirapoint@cannon.cisco.com [161.44.118.24]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h5NMVfai015509; Mon, 23 Jun 2003 18:31:42 -0400 (EDT) Received: from cisco.com ([161.44.79.70]) by cannon.cisco.com (Mirapoint) with ESMTP id ABL58340; Mon, 23 Jun 2003 18:40:38 -0400 (EDT) Message-ID: <3EF77FCC.5020400@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: Oded.Cnaan@comverse.com, simple@ietf.org Subject: Re: [Simple] Single / multiple tuples References: <2038BCC78B1AD641891A0D1AE133DBB701796E19@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 23 Jun 2003 18:31:40 -0400 Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > Is geoloc considered device or media? It is a service, but not a device nor media. I agree it probably isn't either a device or media, but it is an attribute. It happens that "device" and "media" are attributes that some people find especially interesting and want to single out as important for deriving views. Geoloc probably isn't of as great special interest. In principle, I suppose you might consider clustering or "pivoting" data by geoloc, in the same sense that you might do so by media. But it would be less useful. If I cluster by media I can at least decide if it is useful to attempt to contact using that media (with the AOR as communication address). With luck, the devices that support that media will be tried. But if I cluster by geoloc, while I can decide to call you based on the reported location, it will only be effective if there is a unique contact address for each reported location. If you have two geoloc entries, one saying you are in Boston, and another saying you are in Paris, both giving only your AOR, what should I do if I only want to talk to you in Boston? I'm still trying to find out what a service is. You suggest that geoloc is a service. What do you mean by that? Is it something that is available because the user that owns the presentity contracted specially for it? Or is it some kind of application a watcher uses that cares about this information? Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Jun 23 18:34:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13782 for ; Mon, 23 Jun 2003 18:34:36 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5NMYAG27667 for simple-archive@odin.ietf.org; Mon, 23 Jun 2003 18:34:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UZt4-0007CA-C8 for simple-web-archive@optimus.ietf.org; Mon, 23 Jun 2003 18:34:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13728; Mon, 23 Jun 2003 18:34:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UZt0-0006Dr-00; Mon, 23 Jun 2003 18:34:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19UZsu-0006Do-00; Mon, 23 Jun 2003 18:34:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UZsv-00078o-2n; Mon, 23 Jun 2003 18:34:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UZrv-00077Z-Ia for simple@optimus.ietf.org; Mon, 23 Jun 2003 18:33:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13689 for ; Mon, 23 Jun 2003 18:32:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UZrs-0006DP-00 for simple@ietf.org; Mon, 23 Jun 2003 18:32:56 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by ietf-mx with esmtp (Exim 4.12) id 19UZrh-0006DB-00 for simple@ietf.org; Mon, 23 Jun 2003 18:32:46 -0400 Received: from cannon.cisco.com (IDENT:mirapoint@cannon.cisco.com [161.44.118.24]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h5NMVfai015509; Mon, 23 Jun 2003 18:31:42 -0400 (EDT) Received: from cisco.com ([161.44.79.70]) by cannon.cisco.com (Mirapoint) with ESMTP id ABL58340; Mon, 23 Jun 2003 18:40:38 -0400 (EDT) Message-ID: <3EF77FCC.5020400@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: Oded.Cnaan@comverse.com, simple@ietf.org Subject: Re: [Simple] Single / multiple tuples References: <2038BCC78B1AD641891A0D1AE133DBB701796E19@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 23 Jun 2003 18:31:40 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > Is geoloc considered device or media? It is a service, but not a device nor media. I agree it probably isn't either a device or media, but it is an attribute. It happens that "device" and "media" are attributes that some people find especially interesting and want to single out as important for deriving views. Geoloc probably isn't of as great special interest. In principle, I suppose you might consider clustering or "pivoting" data by geoloc, in the same sense that you might do so by media. But it would be less useful. If I cluster by media I can at least decide if it is useful to attempt to contact using that media (with the AOR as communication address). With luck, the devices that support that media will be tried. But if I cluster by geoloc, while I can decide to call you based on the reported location, it will only be effective if there is a unique contact address for each reported location. If you have two geoloc entries, one saying you are in Boston, and another saying you are in Paris, both giving only your AOR, what should I do if I only want to talk to you in Boston? I'm still trying to find out what a service is. You suggest that geoloc is a service. What do you mean by that? Is it something that is available because the user that owns the presentity contracted specially for it? Or is it some kind of application a watcher uses that cares about this information? Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Jun 24 05:57:06 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 FAA08650; Tue, 24 Jun 2003 05:57:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UkXy-0001ms-00; Tue, 24 Jun 2003 05:57:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19UkXs-0001mp-00; Tue, 24 Jun 2003 05:57:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UkXt-0002uC-GQ; Tue, 24 Jun 2003 05:57:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UkX8-0002tf-HL for simple@optimus.ietf.org; Tue, 24 Jun 2003 05:56: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 FAA08642 for ; Tue, 24 Jun 2003 05:56:10 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UkX4-0001mR-00 for simple@ietf.org; Tue, 24 Jun 2003 05:56:11 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19UkWu-0001mO-00 for simple@ietf.org; Tue, 24 Jun 2003 05:56:00 -0400 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h5O9tt908096 for ; Tue, 24 Jun 2003 12:55:55 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 24 Jun 2003 12:55:55 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 24 Jun 2003 12:55:55 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 24 Jun 2003 12:55:55 +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] Single / multiple tuples Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701796E1D@esebe019.ntc.nokia.com> Thread-Topic: [Simple] Single / multiple tuples Thread-Index: AcM512HPZeo4j6TYQ0aVO30qKj8NTwAXqgaw To: Cc: , X-OriginalArrivalTime: 24 Jun 2003 09:55:55.0021 (UTC) FILETIME=[CDB2FBD0:01C33A36] 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, 24 Jun 2003 12:55:53 +0300 Content-Transfer-Encoding: quoted-printable Service to me means something that an operator can offer (as part of a = package) and charge for. This is what I meant when I suggested that = geoloc is a service. In technical terms, I don't know what a service is either. One comment inline... > -----Original Message----- > From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Tuesday, June 24, 2003 1:32 AM > To: Khartabil Hisham (NMP/Helsinki) > Cc: Oded.Cnaan@comverse.com; simple@ietf.org > Subject: Re: [Simple] Single / multiple tuples >=20 >=20 >=20 >=20 > hisham.khartabil@nokia.com wrote: > > Is geoloc considered device or media? It is a service, but=20 > not a device nor media. >=20 > I agree it probably isn't either a device or media, but it is an=20 > attribute. It happens that "device" and "media" are=20 > attributes that some=20 > people find especially interesting and want to single out as=20 > important=20 > for deriving views. Geoloc probably isn't of as great special=20 > interest. >=20 > In principle, I suppose you might consider clustering or=20 > "pivoting" data=20 > by geoloc,=20 Geoloc could be a tuple on its own, just identifying the location of the = principal (principal is a more appropriate word here than presentity). = Nothing to do with clustering. Regards, Hisham > in the same sense that you might do so by media.=20 > But it would=20 > be less useful. If I cluster by media I can at least decide if it is=20 > useful to attempt to contact using that media (with the AOR as=20 > communication address). With luck, the devices that support=20 > that media=20 > will be tried. But if I cluster by geoloc, while I can decide to call=20 > you based on the reported location, it will only be effective=20 > if there=20 > is a unique contact address for each reported location. If=20 > you have two=20 > geoloc entries, one saying you are in Boston, and another=20 > saying you are=20 > in Paris, both giving only your AOR, what should I do if I=20 > only want to=20 > talk to you in Boston? >=20 > I'm still trying to find out what a service is. You suggest=20 > that geoloc=20 > is a service. What do you mean by that? Is it something that is=20 > available because the user that owns the presentity=20 > contracted specially=20 > for it? Or is it some kind of application a watcher uses that cares=20 > about this information? >=20 > Paul >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Jun 24 05:57:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08692 for ; Tue, 24 Jun 2003 05:57:36 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5O9vAT11264 for simple-archive@odin.ietf.org; Tue, 24 Jun 2003 05:57:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UkY2-0002vb-4V for simple-web-archive@optimus.ietf.org; Tue, 24 Jun 2003 05:57:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08650; Tue, 24 Jun 2003 05:57:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UkXy-0001ms-00; Tue, 24 Jun 2003 05:57:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19UkXs-0001mp-00; Tue, 24 Jun 2003 05:57:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UkXt-0002uC-GQ; Tue, 24 Jun 2003 05:57:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UkX8-0002tf-HL for simple@optimus.ietf.org; Tue, 24 Jun 2003 05:56: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 FAA08642 for ; Tue, 24 Jun 2003 05:56:10 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UkX4-0001mR-00 for simple@ietf.org; Tue, 24 Jun 2003 05:56:11 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19UkWu-0001mO-00 for simple@ietf.org; Tue, 24 Jun 2003 05:56:00 -0400 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h5O9tt908096 for ; Tue, 24 Jun 2003 12:55:55 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 24 Jun 2003 12:55:55 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 24 Jun 2003 12:55:55 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 24 Jun 2003 12:55:55 +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] Single / multiple tuples Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701796E1D@esebe019.ntc.nokia.com> Thread-Topic: [Simple] Single / multiple tuples Thread-Index: AcM512HPZeo4j6TYQ0aVO30qKj8NTwAXqgaw To: Cc: , X-OriginalArrivalTime: 24 Jun 2003 09:55:55.0021 (UTC) FILETIME=[CDB2FBD0:01C33A36] 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, 24 Jun 2003 12:55:53 +0300 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Service to me means something that an operator can offer (as part of a = package) and charge for. This is what I meant when I suggested that = geoloc is a service. In technical terms, I don't know what a service is either. One comment inline... > -----Original Message----- > From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Tuesday, June 24, 2003 1:32 AM > To: Khartabil Hisham (NMP/Helsinki) > Cc: Oded.Cnaan@comverse.com; simple@ietf.org > Subject: Re: [Simple] Single / multiple tuples >=20 >=20 >=20 >=20 > hisham.khartabil@nokia.com wrote: > > Is geoloc considered device or media? It is a service, but=20 > not a device nor media. >=20 > I agree it probably isn't either a device or media, but it is an=20 > attribute. It happens that "device" and "media" are=20 > attributes that some=20 > people find especially interesting and want to single out as=20 > important=20 > for deriving views. Geoloc probably isn't of as great special=20 > interest. >=20 > In principle, I suppose you might consider clustering or=20 > "pivoting" data=20 > by geoloc,=20 Geoloc could be a tuple on its own, just identifying the location of the = principal (principal is a more appropriate word here than presentity). = Nothing to do with clustering. Regards, Hisham > in the same sense that you might do so by media.=20 > But it would=20 > be less useful. If I cluster by media I can at least decide if it is=20 > useful to attempt to contact using that media (with the AOR as=20 > communication address). With luck, the devices that support=20 > that media=20 > will be tried. But if I cluster by geoloc, while I can decide to call=20 > you based on the reported location, it will only be effective=20 > if there=20 > is a unique contact address for each reported location. If=20 > you have two=20 > geoloc entries, one saying you are in Boston, and another=20 > saying you are=20 > in Paris, both giving only your AOR, what should I do if I=20 > only want to=20 > talk to you in Boston? >=20 > I'm still trying to find out what a service is. You suggest=20 > that geoloc=20 > is a service. What do you mean by that? Is it something that is=20 > available because the user that owns the presentity=20 > contracted specially=20 > for it? Or is it some kind of application a watcher uses that cares=20 > about this information? >=20 > Paul >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Jun 24 09:12:07 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 JAA14998; Tue, 24 Jun 2003 09:12:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Unai-0002qM-00; Tue, 24 Jun 2003 09:12:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Unac-0002qJ-00; Tue, 24 Jun 2003 09: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 19Unaa-0001pE-Ra; Tue, 24 Jun 2003 09:12:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UnZz-0001ov-2U for simple@optimus.ietf.org; Tue, 24 Jun 2003 09:11:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14990 for ; Tue, 24 Jun 2003 09:11:20 -0400 (EDT) From: aki.niemi@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UnZx-0002q7-00 for simple@ietf.org; Tue, 24 Jun 2003 09:11:21 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19UnZm-0002q0-00 for simple@ietf.org; Tue, 24 Jun 2003 09:11:10 -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 h5ODAga03163 for ; Tue, 24 Jun 2003 16:10:42 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 24 Jun 2003 16:10:42 +0300 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 24 Jun 2003 16:10:42 +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] PUBLISH: identification of presence segments Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9019452E6@esebe013.ntc.nokia.com> Thread-Topic: [Simple] PUBLISH: identification of presence segments Thread-Index: AcM4q+W9fgrk3f6BSWCfkCdH9CPCFgBofgHA To: , , , X-OriginalArrivalTime: 24 Jun 2003 13:10:42.0008 (UTC) FILETIME=[03AFAD80:01C33A52] 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, 24 Jun 2003 16:10:41 +0300 Content-Transfer-Encoding: quoted-printable Hi Oded, Inline. > -----Original Message----- > From: ext Cnaan Oded [mailto:Oded.Cnaan@comverse.com] > Sent: 22 June, 2003 13:49 > To: 'Thanos Diacakis'; Khartabil Hisham (NMP/Helsinki); Niemi Aki > (NMP/Helsinki); simple@ietf.org > Subject: RE: [Simple] PUBLISH: identification of presence segments >=20 >=20 > I hope that we can agree, that in a typical implementation,=20 > users will not > be exposed to tuples and might not even know that they=20 > exist. Tuples are > just a method for describing Presence information in a=20 > hierarchical way that > can be understood by UAs (and PSs).=20 Yes. > Saying that, it would be=20 > very rare to > have _users_ selecting tuple IDs or referring to tuples by=20 > their names. In > most cases, users will change their 'Video' availability and=20 > have their UA > handle the details for them. I would even go further than that and say that in most cases the user = won't manually change their 'video' availability, but instead the = application will do it. For example, if a user is already on a video = call, her presence might automagically show unavailability. >=20 > I believe that the tuple identification problem is caused by=20 > using the same > Presence document for both PUBLISH and NOTIFY. Let's take=20 > for example user A > with the following Presence document, as generated by the PS=20 > (schematic > syntax): >=20 > > > > online > busy > meeting > > im:someone@mobilecarrier.net > tel:+44-254-54462211 > As Paul pointed out in a separate thread, the element is only = supposed to contain a single element or no contact at all. = Therefore I think that the tuple needs to be split into two separate = tuples for this to work. >=20 > > > online > offline > > im:someone@mobilecarrier.net > > >=20 > The first tuple represents a mobile phone that runs an IM=20 > client and that is > capable of receiving phone calls. The latter describes a PC=20 > running an IM > client from the same service provider. Changing the IM=20 > availability on the > PC requires the PC to recognize that the phone has published voice > capabilities as part of the same tuple and even to=20 > re-publish information > related to the phone. This seems to be along the lines of a concept Thanos brought in, namely = the concept of "semantically equivalent" tuples, or event segments.=20 We need to have a way for the composer to detect when two independent = publications are in fact two representations of a single tuple, instead = of being representations of two separate tuples. > A different approach would be to have publishers send only=20 > raw information, > leaving the document composition task to the Presence=20 > Server. This allows > the PS to apply rules as well as transformations on the raw=20 > information, > without the need to 'identify' tuples. Doing so, also solves=20 > the problem of > tuple IDs as only the server now generates them. I think the problem still remains. How would the composer know if two = chunks of raw data are representations of the same piece of presence = state? =20 > When publishing Presence information, there are 3 basic=20 > questions to answer: > 1. What is the information element that we would like to=20 > update (e.g., MSN > IM Service) > 2. What is the new value of the information element (e.g.,=20 > status is BUSY > and contact is ...) > 3. To which device/service this element belongs (e.g.,=20 > specific phone) >=20 > These questions can be used on any Presence view (i.e.,=20 > Device/Service/Media > based). For example, in a service-view, the third answer may=20 > be "specific > service". We have RPIDS defined for the PIDF already, so perhaps they could also = work here? =20 > Now, let's see how this new approach facilitates the=20 > publication problems > identified by Thanos, Hisham and Aki. > 1. Thanos showed that having 2 UAs publish using the same=20 > tuple ID may > result in a conflict on the PS. Here, tuple IDs are not used for > publication. If 2 UAs publish a new IM status, they do not=20 > relate to a > specific tuple, but to the same service. > 2. Thanos also raised the problem of having PS change tuple=20 > IDs based on > some server based rules (e.g., transformation rules). Here,=20 > there is no > conflict as the UA publishes raw info regardless of the=20 > tuple structure. > 3. Aki suggested to restrict the composer so that published=20 > tuples are never > merged or modified. This is no longer required as we've=20 > separated between > the published info and the Presence document sent to watchers. > 4. Hisham raised the question of relating 2 tuples and=20 > mentioned that in > some circumstances, there would be a need to publish the=20 > whole document to > avoid conflicts.. This is a non-issue as we now publish raw=20 > info not related > to a specific tuple. >=20 > We can now build an XML document that will be used for=20 > publications. This > document needs to answer the above questions and, for=20 > optimization, allow > publishing more than one update at a time. It will be used as part of > PUBLISH messages while PIDF will continue to serve NOTIFY messages. If I understand you correctly, the proposal is to specify a new XML = document for publications instead of using PIDF directly? This relates to another open item we have on whether to have the PUBLISH = always carry a PIDF fragment, namely a tuple fragment or perhaps a = presentity-level note fragment. But overall, I still think it is important to maintain using PIDF in = PUBLISH in some shape or form, because the identification problem still = needs to be solved. I don't think it helps if we end up with different = identification mechanisms for PUBLISH and NOTIFY. E.g., some new way in = PUBLISH, and RPIDS+PIDF in NOTIFY. Also, other event state may not share this problem in any case, so by = default, the notification and the publication would share a common = format. Cheers, Aki > I understand that this idea conflicts previous PUBLISH=20 > drafts but I hope > you'll consider it as it solves many of the problems=20 > identified in this > thread. >=20 > Oded=20 >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Jun 24 09:12:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15019 for ; Tue, 24 Jun 2003 09:12:38 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5ODCAC07154 for simple-archive@odin.ietf.org; Tue, 24 Jun 2003 09:12:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Unak-0001rJ-3w for simple-web-archive@optimus.ietf.org; Tue, 24 Jun 2003 09:12:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14998; Tue, 24 Jun 2003 09:12:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Unai-0002qM-00; Tue, 24 Jun 2003 09:12:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Unac-0002qJ-00; Tue, 24 Jun 2003 09: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 19Unaa-0001pE-Ra; Tue, 24 Jun 2003 09:12:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UnZz-0001ov-2U for simple@optimus.ietf.org; Tue, 24 Jun 2003 09:11:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14990 for ; Tue, 24 Jun 2003 09:11:20 -0400 (EDT) From: aki.niemi@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UnZx-0002q7-00 for simple@ietf.org; Tue, 24 Jun 2003 09:11:21 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19UnZm-0002q0-00 for simple@ietf.org; Tue, 24 Jun 2003 09:11:10 -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 h5ODAga03163 for ; Tue, 24 Jun 2003 16:10:42 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 24 Jun 2003 16:10:42 +0300 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 24 Jun 2003 16:10:42 +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] PUBLISH: identification of presence segments Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9019452E6@esebe013.ntc.nokia.com> Thread-Topic: [Simple] PUBLISH: identification of presence segments Thread-Index: AcM4q+W9fgrk3f6BSWCfkCdH9CPCFgBofgHA To: , , , X-OriginalArrivalTime: 24 Jun 2003 13:10:42.0008 (UTC) FILETIME=[03AFAD80:01C33A52] 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, 24 Jun 2003 16:10:41 +0300 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Oded, Inline. > -----Original Message----- > From: ext Cnaan Oded [mailto:Oded.Cnaan@comverse.com] > Sent: 22 June, 2003 13:49 > To: 'Thanos Diacakis'; Khartabil Hisham (NMP/Helsinki); Niemi Aki > (NMP/Helsinki); simple@ietf.org > Subject: RE: [Simple] PUBLISH: identification of presence segments >=20 >=20 > I hope that we can agree, that in a typical implementation,=20 > users will not > be exposed to tuples and might not even know that they=20 > exist. Tuples are > just a method for describing Presence information in a=20 > hierarchical way that > can be understood by UAs (and PSs).=20 Yes. > Saying that, it would be=20 > very rare to > have _users_ selecting tuple IDs or referring to tuples by=20 > their names. In > most cases, users will change their 'Video' availability and=20 > have their UA > handle the details for them. I would even go further than that and say that in most cases the user = won't manually change their 'video' availability, but instead the = application will do it. For example, if a user is already on a video = call, her presence might automagically show unavailability. >=20 > I believe that the tuple identification problem is caused by=20 > using the same > Presence document for both PUBLISH and NOTIFY. Let's take=20 > for example user A > with the following Presence document, as generated by the PS=20 > (schematic > syntax): >=20 > > > > online > busy > meeting > > im:someone@mobilecarrier.net > tel:+44-254-54462211 > As Paul pointed out in a separate thread, the element is only = supposed to contain a single element or no contact at all. = Therefore I think that the tuple needs to be split into two separate = tuples for this to work. >=20 > > > online > offline > > im:someone@mobilecarrier.net > > >=20 > The first tuple represents a mobile phone that runs an IM=20 > client and that is > capable of receiving phone calls. The latter describes a PC=20 > running an IM > client from the same service provider. Changing the IM=20 > availability on the > PC requires the PC to recognize that the phone has published voice > capabilities as part of the same tuple and even to=20 > re-publish information > related to the phone. This seems to be along the lines of a concept Thanos brought in, namely = the concept of "semantically equivalent" tuples, or event segments.=20 We need to have a way for the composer to detect when two independent = publications are in fact two representations of a single tuple, instead = of being representations of two separate tuples. > A different approach would be to have publishers send only=20 > raw information, > leaving the document composition task to the Presence=20 > Server. This allows > the PS to apply rules as well as transformations on the raw=20 > information, > without the need to 'identify' tuples. Doing so, also solves=20 > the problem of > tuple IDs as only the server now generates them. I think the problem still remains. How would the composer know if two = chunks of raw data are representations of the same piece of presence = state? =20 > When publishing Presence information, there are 3 basic=20 > questions to answer: > 1. What is the information element that we would like to=20 > update (e.g., MSN > IM Service) > 2. What is the new value of the information element (e.g.,=20 > status is BUSY > and contact is ...) > 3. To which device/service this element belongs (e.g.,=20 > specific phone) >=20 > These questions can be used on any Presence view (i.e.,=20 > Device/Service/Media > based). For example, in a service-view, the third answer may=20 > be "specific > service". We have RPIDS defined for the PIDF already, so perhaps they could also = work here? =20 > Now, let's see how this new approach facilitates the=20 > publication problems > identified by Thanos, Hisham and Aki. > 1. Thanos showed that having 2 UAs publish using the same=20 > tuple ID may > result in a conflict on the PS. Here, tuple IDs are not used for > publication. If 2 UAs publish a new IM status, they do not=20 > relate to a > specific tuple, but to the same service. > 2. Thanos also raised the problem of having PS change tuple=20 > IDs based on > some server based rules (e.g., transformation rules). Here,=20 > there is no > conflict as the UA publishes raw info regardless of the=20 > tuple structure. > 3. Aki suggested to restrict the composer so that published=20 > tuples are never > merged or modified. This is no longer required as we've=20 > separated between > the published info and the Presence document sent to watchers. > 4. Hisham raised the question of relating 2 tuples and=20 > mentioned that in > some circumstances, there would be a need to publish the=20 > whole document to > avoid conflicts.. This is a non-issue as we now publish raw=20 > info not related > to a specific tuple. >=20 > We can now build an XML document that will be used for=20 > publications. This > document needs to answer the above questions and, for=20 > optimization, allow > publishing more than one update at a time. It will be used as part of > PUBLISH messages while PIDF will continue to serve NOTIFY messages. If I understand you correctly, the proposal is to specify a new XML = document for publications instead of using PIDF directly? This relates to another open item we have on whether to have the PUBLISH = always carry a PIDF fragment, namely a tuple fragment or perhaps a = presentity-level note fragment. But overall, I still think it is important to maintain using PIDF in = PUBLISH in some shape or form, because the identification problem still = needs to be solved. I don't think it helps if we end up with different = identification mechanisms for PUBLISH and NOTIFY. E.g., some new way in = PUBLISH, and RPIDS+PIDF in NOTIFY. Also, other event state may not share this problem in any case, so by = default, the notification and the publication would share a common = format. Cheers, Aki > I understand that this idea conflicts previous PUBLISH=20 > drafts but I hope > you'll consider it as it solves many of the problems=20 > identified in this > thread. >=20 > Oded=20 >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Jun 24 09:45:20 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 JAA16024; Tue, 24 Jun 2003 09:45:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Uo6r-00032j-00; Tue, 24 Jun 2003 09:45:21 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Uo6l-00032c-00; Tue, 24 Jun 2003 09:45:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Uo6W-0002qc-RI; Tue, 24 Jun 2003 09:45:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Uo5a-0002pb-Bv for simple@optimus.ietf.org; Tue, 24 Jun 2003 09: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 ESMTP id JAA15996 for ; Tue, 24 Jun 2003 09:43:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Uo5J-00032E-00 for simple@ietf.org; Tue, 24 Jun 2003 09:43:45 -0400 Received: from igate2.vodafone.co.uk ([194.62.232.66]) by ietf-mx with esmtp (Exim 4.12) id 19Uo54-000327-00 for simple@ietf.org; Tue, 24 Jun 2003 09:43:31 -0400 Received: by igate2.vodafone.co.uk; (8.8.8/1.3/10May95) id OAA12964; Tue, 24 Jun 2003 14:42:39 +0100 (BST) Received: from ukwmxc02.vf-uk.internal.vodafone.com (ukwmxc02 [10.33.126.170]) by mailguard2 (4.6.1.123) with ESMTP id for ; Tue, 24 Jun 2003 14:40:08 +0100 Received: from ukwmxc04.vf-uk.internal.vodafone.com ([10.33.126.173]) by ukwmxc02.vf-uk.internal.vodafone.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 24 Jun 2003 14:42:15 +0100 Received: from ukwmxm02.vf-uk.internal.vodafone.com ([10.33.126.242]) by ukwmxc04.vf-uk.internal.vodafone.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 24 Jun 2003 14:42:15 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message Message-ID: Thread-Topic: Sending 1 to n MESSAGEs Thread-Index: AcM6VmuFY+fh1zhrTJGnaSl4SdVS5g== From: "Mills, Duncan, D, CND Tech Dev, VF UK" To: X-OriginalArrivalTime: 24 Jun 2003 13:42:15.0387 (UTC) FILETIME=[6C3A62B0:01C33A56] MIME-Version: 1.0 (Generated by Clearswift ES version 4.6.1.122) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Subject: [Simple] Sending 1 to n MESSAGEs 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, 24 Jun 2003 14:42:13 +0100 Content-Transfer-Encoding: quoted-printable SIMPLE people, I've just been thinking about how my e-mail works, and what I like best = about it. It is really easy to type a long message and then send it to = a list of (more than one) people. Better still, I don't have to have = pre-configured that list of people. I can just type in the addresses in = the To: field and the mail will be sent to each address. As far as I know, I can't do this with the SIP MESSAGE method. Yes, I = can create a resource URI in a server and send one MESSAGE request to = that resource-URI, and the server may fork the MESSAGE to each URI in my = pre-configured list. But if I don't want to have to set up a new list = of recipients each time I send a MESSAGE then I have to send the same = MESSAGE several times. Please correct me if I'm wrong. Now... looking at this from a wireless operator perspective, I = immediately see warning signs about my =A36 billion radio interface ;-) = Currently, in GSM, if we want to send an SMS to more 'n' recipients, we = have the same situation- either create a user group in the network or = send the message 'n' times. However, a SIP MESSAGE request is likely to = be about ten times the size of an SMS. Is this a problem? If not, why not? Maybe I'm missing some = background/historical information? If it is a problem, might it be possible to extend SIP in such a way as = to state that the request-URI be set to the address of my SIP proxy = server in my home network and then the To: field be filled with the list = of intended recipients, with the server then being responsible for = sending the MESSAGE to all the intended recipients? Any comments/views? Best Regards, Duncan Duncan Mills Senior Engineer Network Standards & Technical Audit Technology Development (Network Systems) Vodafone (UK) Ltd Tel: +44 (0)1635 676074 Mob: +44 7867 900955 Fax: +44 (0)1635 234445 mailto:duncan.mills@vf.vodafone.co.uk _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Jun 24 09:45:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16048 for ; Tue, 24 Jun 2003 09:45:50 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5ODjNV11163 for simple-archive@odin.ietf.org; Tue, 24 Jun 2003 09:45:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Uo6t-0002ty-EF for simple-web-archive@optimus.ietf.org; Tue, 24 Jun 2003 09:45: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 JAA16024; Tue, 24 Jun 2003 09:45:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Uo6r-00032j-00; Tue, 24 Jun 2003 09:45:21 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Uo6l-00032c-00; Tue, 24 Jun 2003 09:45:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Uo6W-0002qc-RI; Tue, 24 Jun 2003 09:45:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Uo5a-0002pb-Bv for simple@optimus.ietf.org; Tue, 24 Jun 2003 09: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 ESMTP id JAA15996 for ; Tue, 24 Jun 2003 09:43:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Uo5J-00032E-00 for simple@ietf.org; Tue, 24 Jun 2003 09:43:45 -0400 Received: from igate2.vodafone.co.uk ([194.62.232.66]) by ietf-mx with esmtp (Exim 4.12) id 19Uo54-000327-00 for simple@ietf.org; Tue, 24 Jun 2003 09:43:31 -0400 Received: by igate2.vodafone.co.uk; (8.8.8/1.3/10May95) id OAA12964; Tue, 24 Jun 2003 14:42:39 +0100 (BST) Received: from ukwmxc02.vf-uk.internal.vodafone.com (ukwmxc02 [10.33.126.170]) by mailguard2 (4.6.1.123) with ESMTP id for ; Tue, 24 Jun 2003 14:40:08 +0100 Received: from ukwmxc04.vf-uk.internal.vodafone.com ([10.33.126.173]) by ukwmxc02.vf-uk.internal.vodafone.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 24 Jun 2003 14:42:15 +0100 Received: from ukwmxm02.vf-uk.internal.vodafone.com ([10.33.126.242]) by ukwmxc04.vf-uk.internal.vodafone.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 24 Jun 2003 14:42:15 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message Message-ID: Thread-Topic: Sending 1 to n MESSAGEs Thread-Index: AcM6VmuFY+fh1zhrTJGnaSl4SdVS5g== From: "Mills, Duncan, D, CND Tech Dev, VF UK" To: X-OriginalArrivalTime: 24 Jun 2003 13:42:15.0387 (UTC) FILETIME=[6C3A62B0:01C33A56] MIME-Version: 1.0 (Generated by Clearswift ES version 4.6.1.122) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Subject: [Simple] Sending 1 to n MESSAGEs 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, 24 Jun 2003 14:42:13 +0100 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable SIMPLE people, I've just been thinking about how my e-mail works, and what I like best = about it. It is really easy to type a long message and then send it to = a list of (more than one) people. Better still, I don't have to have = pre-configured that list of people. I can just type in the addresses in = the To: field and the mail will be sent to each address. As far as I know, I can't do this with the SIP MESSAGE method. Yes, I = can create a resource URI in a server and send one MESSAGE request to = that resource-URI, and the server may fork the MESSAGE to each URI in my = pre-configured list. But if I don't want to have to set up a new list = of recipients each time I send a MESSAGE then I have to send the same = MESSAGE several times. Please correct me if I'm wrong. Now... looking at this from a wireless operator perspective, I = immediately see warning signs about my =A36 billion radio interface ;-) = Currently, in GSM, if we want to send an SMS to more 'n' recipients, we = have the same situation- either create a user group in the network or = send the message 'n' times. However, a SIP MESSAGE request is likely to = be about ten times the size of an SMS. Is this a problem? If not, why not? Maybe I'm missing some = background/historical information? If it is a problem, might it be possible to extend SIP in such a way as = to state that the request-URI be set to the address of my SIP proxy = server in my home network and then the To: field be filled with the list = of intended recipients, with the server then being responsible for = sending the MESSAGE to all the intended recipients? Any comments/views? Best Regards, Duncan Duncan Mills Senior Engineer Network Standards & Technical Audit Technology Development (Network Systems) Vodafone (UK) Ltd Tel: +44 (0)1635 676074 Mob: +44 7867 900955 Fax: +44 (0)1635 234445 mailto:duncan.mills@vf.vodafone.co.uk _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Jun 24 10:39:08 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 KAA18665; Tue, 24 Jun 2003 10:39:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Uowv-0003Lv-00; Tue, 24 Jun 2003 10:39:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Uowp-0003Ls-00; Tue, 24 Jun 2003 10:39:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Uown-0005D2-A6; Tue, 24 Jun 2003 10:39:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Uowb-0005Cr-JV for simple@optimus.ietf.org; Tue, 24 Jun 2003 10:38: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 KAA18662 for ; Tue, 24 Jun 2003 10:38:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UowY-0003Lp-00 for simple@ietf.org; Tue, 24 Jun 2003 10:38:47 -0400 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 19UowN-0003LZ-00 for simple@ietf.org; Tue, 24 Jun 2003 10:38:36 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA27851; Tue, 24 Jun 2003 10:37:43 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA23078; Tue, 24 Jun 2003 10:37:43 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Tue, 24 Jun 2003 10:37:43 -0400 Message-ID: <313680C9A886D511A06000204840E1CF070B5B2A@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Mills, Duncan, D, CND Tech Dev, VF UK'" , simple@ietf.org Subject: RE: [Simple] Sending 1 to n MESSAGEs MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 24 Jun 2003 10:37:37 -0400 Content-Transfer-Encoding: quoted-printable Was the salutation to your message a comment on the quality of the discourse on this list? ;) =20 Good thought. Interacts with conferencing (mass invite to a = conference). You don't want to have to have a complex interaction prior to sending a list of recipients. Smells like a kind of forking behavior, but=20 clearly different (not all the same AOR). Obviously creates multiple dialogs if/when multiple responses are received. The proxy can't be the origination point; it's not a UA. All the responses are going to be forwarded to the UA. The only way around that is B2BUA behavior. Is that a better, or a worse idea? Gotta think through what this means for Message Sessions. You want the proxy to replicate each message, but you don't really want to repeat the list of recipients. Does that argue for B2BUA more strongly? With a B2BUA approach you send the message to the exploder. It sends individual messages to recipients, and handles all the dialogs. That reminds me of a buddy list subscription without the prearranged=20 buddy list. Brian > -----Original Message----- > From: Mills, Duncan, D, CND Tech Dev, VF UK > [mailto:Duncan.Mills@gb.vodafone.co.uk] > Sent: Tuesday, June 24, 2003 9:42 AM > To: simple@ietf.org > Subject: [Simple] Sending 1 to n MESSAGEs >=20 >=20 > SIMPLE people, >=20 > I've just been thinking about how my e-mail works, and what I=20 > like best about it. It is really easy to type a long message=20 > and then send it to a list of (more than one) people. Better=20 > still, I don't have to have pre-configured that list of=20 > people. I can just type in the addresses in the To: field=20 > and the mail will be sent to each address. >=20 > As far as I know, I can't do this with the SIP MESSAGE=20 > method. Yes, I can create a resource URI in a server and=20 > send one MESSAGE request to that resource-URI, and the server=20 > may fork the MESSAGE to each URI in my pre-configured list. =20 > But if I don't want to have to set up a new list of=20 > recipients each time I send a MESSAGE then I have to send the=20 > same MESSAGE several times. Please correct me if I'm wrong. >=20 > Now... looking at this from a wireless operator perspective,=20 > I immediately see warning signs about my =A36 billion radio=20 > interface ;-) Currently, in GSM, if we want to send an SMS=20 > to more 'n' recipients, we have the same situation- either=20 > create a user group in the network or send the message 'n'=20 > times. However, a SIP MESSAGE request is likely to be about=20 > ten times the size of an SMS. >=20 > Is this a problem? If not, why not? Maybe I'm missing some=20 > background/historical information? >=20 > If it is a problem, might it be possible to extend SIP in=20 > such a way as to state that the request-URI be set to the=20 > address of my SIP proxy server in my home network and then=20 > the To: field be filled with the list of intended recipients,=20 > with the server then being responsible for sending the=20 > MESSAGE to all the intended recipients? >=20 > Any comments/views? >=20 > Best Regards, >=20 > Duncan >=20 >=20 > Duncan Mills > Senior Engineer > Network Standards & Technical Audit > Technology Development (Network Systems) > Vodafone (UK) Ltd > Tel: +44 (0)1635 676074 > Mob: +44 7867 900955 > Fax: +44 (0)1635 234445 > mailto:duncan.mills@vf.vodafone.co.uk >=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 Jun 24 10:39:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18692 for ; Tue, 24 Jun 2003 10:39:39 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5OEdD620221 for simple-archive@odin.ietf.org; Tue, 24 Jun 2003 10:39:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Uowz-0005G4-3t for simple-web-archive@optimus.ietf.org; Tue, 24 Jun 2003 10:39:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18665; Tue, 24 Jun 2003 10:39:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Uowv-0003Lv-00; Tue, 24 Jun 2003 10:39:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Uowp-0003Ls-00; Tue, 24 Jun 2003 10:39:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Uown-0005D2-A6; Tue, 24 Jun 2003 10:39:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Uowb-0005Cr-JV for simple@optimus.ietf.org; Tue, 24 Jun 2003 10:38: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 KAA18662 for ; Tue, 24 Jun 2003 10:38:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UowY-0003Lp-00 for simple@ietf.org; Tue, 24 Jun 2003 10:38:47 -0400 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 19UowN-0003LZ-00 for simple@ietf.org; Tue, 24 Jun 2003 10:38:36 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA27851; Tue, 24 Jun 2003 10:37:43 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA23078; Tue, 24 Jun 2003 10:37:43 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Tue, 24 Jun 2003 10:37:43 -0400 Message-ID: <313680C9A886D511A06000204840E1CF070B5B2A@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Mills, Duncan, D, CND Tech Dev, VF UK'" , simple@ietf.org Subject: RE: [Simple] Sending 1 to n MESSAGEs MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 24 Jun 2003 10:37:37 -0400 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Was the salutation to your message a comment on the quality of the discourse on this list? ;) =20 Good thought. Interacts with conferencing (mass invite to a = conference). You don't want to have to have a complex interaction prior to sending a list of recipients. Smells like a kind of forking behavior, but=20 clearly different (not all the same AOR). Obviously creates multiple dialogs if/when multiple responses are received. The proxy can't be the origination point; it's not a UA. All the responses are going to be forwarded to the UA. The only way around that is B2BUA behavior. Is that a better, or a worse idea? Gotta think through what this means for Message Sessions. You want the proxy to replicate each message, but you don't really want to repeat the list of recipients. Does that argue for B2BUA more strongly? With a B2BUA approach you send the message to the exploder. It sends individual messages to recipients, and handles all the dialogs. That reminds me of a buddy list subscription without the prearranged=20 buddy list. Brian > -----Original Message----- > From: Mills, Duncan, D, CND Tech Dev, VF UK > [mailto:Duncan.Mills@gb.vodafone.co.uk] > Sent: Tuesday, June 24, 2003 9:42 AM > To: simple@ietf.org > Subject: [Simple] Sending 1 to n MESSAGEs >=20 >=20 > SIMPLE people, >=20 > I've just been thinking about how my e-mail works, and what I=20 > like best about it. It is really easy to type a long message=20 > and then send it to a list of (more than one) people. Better=20 > still, I don't have to have pre-configured that list of=20 > people. I can just type in the addresses in the To: field=20 > and the mail will be sent to each address. >=20 > As far as I know, I can't do this with the SIP MESSAGE=20 > method. Yes, I can create a resource URI in a server and=20 > send one MESSAGE request to that resource-URI, and the server=20 > may fork the MESSAGE to each URI in my pre-configured list. =20 > But if I don't want to have to set up a new list of=20 > recipients each time I send a MESSAGE then I have to send the=20 > same MESSAGE several times. Please correct me if I'm wrong. >=20 > Now... looking at this from a wireless operator perspective,=20 > I immediately see warning signs about my =A36 billion radio=20 > interface ;-) Currently, in GSM, if we want to send an SMS=20 > to more 'n' recipients, we have the same situation- either=20 > create a user group in the network or send the message 'n'=20 > times. However, a SIP MESSAGE request is likely to be about=20 > ten times the size of an SMS. >=20 > Is this a problem? If not, why not? Maybe I'm missing some=20 > background/historical information? >=20 > If it is a problem, might it be possible to extend SIP in=20 > such a way as to state that the request-URI be set to the=20 > address of my SIP proxy server in my home network and then=20 > the To: field be filled with the list of intended recipients,=20 > with the server then being responsible for sending the=20 > MESSAGE to all the intended recipients? >=20 > Any comments/views? >=20 > Best Regards, >=20 > Duncan >=20 >=20 > Duncan Mills > Senior Engineer > Network Standards & Technical Audit > Technology Development (Network Systems) > Vodafone (UK) Ltd > Tel: +44 (0)1635 676074 > Mob: +44 7867 900955 > Fax: +44 (0)1635 234445 > mailto:duncan.mills@vf.vodafone.co.uk >=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 Jun 24 10:57:08 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 KAA19223; Tue, 24 Jun 2003 10:57:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UpEL-0003Sw-00; Tue, 24 Jun 2003 10:57:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19UpEF-0003St-00; Tue, 24 Jun 2003 10:57:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UpED-0005sy-EX; Tue, 24 Jun 2003 10:57:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UpE7-0005si-6w for simple@optimus.ietf.org; Tue, 24 Jun 2003 10:56:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19215 for ; Tue, 24 Jun 2003 10:56:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UpE4-0003Sj-00 for simple@ietf.org; Tue, 24 Jun 2003 10:56:52 -0400 Received: from igate2.vodafone.co.uk ([194.62.232.66]) by ietf-mx with esmtp (Exim 4.12) id 19UpDs-0003SD-00 for simple@ietf.org; Tue, 24 Jun 2003 10:56:40 -0400 Received: by igate2.vodafone.co.uk; (8.8.8/1.3/10May95) id PAA02775; Tue, 24 Jun 2003 15:55:45 +0100 (BST) Received: from ukwmxc01.vf-uk.internal.vodafone.com (ukwmxc01 [10.33.126.160]) by mailguard1 (4.6.1.123) with ESMTP id ; Tue, 24 Jun 2003 15:55:44 +0100 Received: from ukwmxc03.vf-uk.internal.vodafone.com ([10.33.126.155]) by ukwmxc01.vf-uk.internal.vodafone.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 24 Jun 2003 15:55:30 +0100 Received: from ukwmxm02.vf-uk.internal.vodafone.com ([10.33.126.242]) by ukwmxc03.vf-uk.internal.vodafone.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 24 Jun 2003 15:55:28 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message Subject: RE: [Simple] Sending 1 to n MESSAGEs Message-ID: Thread-Topic: [Simple] Sending 1 to n MESSAGEs Thread-Index: AcM6XltoDR2uFgjdRZKYwWVhhg9Y5AAATJhg From: "Mills, Duncan, D, CND Tech Dev, VF UK" To: "Rosen, Brian" , X-OriginalArrivalTime: 24 Jun 2003 14:55:28.0645 (UTC) FILETIME=[A6D05B50:01C33A60] MIME-Version: 1.0 (Generated by Clearswift ES version 4.6.1.122) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 24 Jun 2003 15:55:28 +0100 Content-Transfer-Encoding: quoted-printable Dear CLEVER people (of the SIMPLE WG) ;-) Brian- yes, my thought was to allow a B2BUA function to fork the MESSAGE = request. This way, the user doesn't have to pre-configure the recipient = list, but perhaps they do have to pre-configure the address of their = MESSAGING server (the B2BUA). When I say pre-configure, I'm sure there = are more dynamic ways to get the B2BUA address to the UA. I must admit, I am coming at this from the 3GPP perspective and so a SIP = AS (acting in B2BUA mode) would seem to do the trick. However, it would = require- I believe- some extensions to SIP. However, 3GPP radio interface constraints aside, I think it would be a = shame to design SIP messaging without the ability to fork a message to n = recipients, in the same way you can with e-mail. Thanks for your initial thoughts- I'd be interested in progressing this = issue, if you and others feel it worthwhile... Cheers, Duncan -----Original Message----- From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] Sent: 24 June 2003 15:38 To: Mills, Duncan, D, CND Tech Dev, VF UK; simple@ietf.org Subject: RE: [Simple] Sending 1 to n MESSAGEs Was the salutation to your message a comment on the quality of the discourse on this list? ;) =20 Good thought. Interacts with conferencing (mass invite to a = conference). You don't want to have to have a complex interaction prior to sending a list of recipients. Smells like a kind of forking behavior, but=20 clearly different (not all the same AOR). Obviously creates multiple dialogs if/when multiple responses are received. The proxy can't be the origination point; it's not a UA. All the responses are going to be forwarded to the UA. The only way around that is B2BUA behavior. Is that a better, or a worse idea? Gotta think through what this means for Message Sessions. You want the proxy to replicate each message, but you don't really want to repeat the list of recipients. Does that argue for B2BUA more strongly? With a B2BUA approach you send the message to the exploder. It sends individual messages to recipients, and handles all the dialogs. That reminds me of a buddy list subscription without the prearranged=20 buddy list. Brian > -----Original Message----- > From: Mills, Duncan, D, CND Tech Dev, VF UK > [mailto:Duncan.Mills@gb.vodafone.co.uk] > Sent: Tuesday, June 24, 2003 9:42 AM > To: simple@ietf.org > Subject: [Simple] Sending 1 to n MESSAGEs >=20 >=20 > SIMPLE people, >=20 > I've just been thinking about how my e-mail works, and what I=20 > like best about it. It is really easy to type a long message=20 > and then send it to a list of (more than one) people. Better=20 > still, I don't have to have pre-configured that list of=20 > people. I can just type in the addresses in the To: field=20 > and the mail will be sent to each address. >=20 > As far as I know, I can't do this with the SIP MESSAGE=20 > method. Yes, I can create a resource URI in a server and=20 > send one MESSAGE request to that resource-URI, and the server=20 > may fork the MESSAGE to each URI in my pre-configured list. =20 > But if I don't want to have to set up a new list of=20 > recipients each time I send a MESSAGE then I have to send the=20 > same MESSAGE several times. Please correct me if I'm wrong. >=20 > Now... looking at this from a wireless operator perspective,=20 > I immediately see warning signs about my =A36 billion radio=20 > interface ;-) Currently, in GSM, if we want to send an SMS=20 > to more 'n' recipients, we have the same situation- either=20 > create a user group in the network or send the message 'n'=20 > times. However, a SIP MESSAGE request is likely to be about=20 > ten times the size of an SMS. >=20 > Is this a problem? If not, why not? Maybe I'm missing some=20 > background/historical information? >=20 > If it is a problem, might it be possible to extend SIP in=20 > such a way as to state that the request-URI be set to the=20 > address of my SIP proxy server in my home network and then=20 > the To: field be filled with the list of intended recipients,=20 > with the server then being responsible for sending the=20 > MESSAGE to all the intended recipients? >=20 > Any comments/views? >=20 > Best Regards, >=20 > Duncan >=20 >=20 > Duncan Mills > Senior Engineer > Network Standards & Technical Audit > Technology Development (Network Systems) > Vodafone (UK) Ltd > Tel: +44 (0)1635 676074 > Mob: +44 7867 900955 > Fax: +44 (0)1635 234445 > mailto:duncan.mills@vf.vodafone.co.uk >=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 Jun 24 10:57:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19251 for ; Tue, 24 Jun 2003 10:57:39 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5OEvCm22711 for simple-archive@odin.ietf.org; Tue, 24 Jun 2003 10:57:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UpEO-0005uE-I8 for simple-web-archive@optimus.ietf.org; Tue, 24 Jun 2003 10:57:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19223; Tue, 24 Jun 2003 10:57:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UpEL-0003Sw-00; Tue, 24 Jun 2003 10:57:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19UpEF-0003St-00; Tue, 24 Jun 2003 10:57:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UpED-0005sy-EX; Tue, 24 Jun 2003 10:57:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UpE7-0005si-6w for simple@optimus.ietf.org; Tue, 24 Jun 2003 10:56:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19215 for ; Tue, 24 Jun 2003 10:56:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UpE4-0003Sj-00 for simple@ietf.org; Tue, 24 Jun 2003 10:56:52 -0400 Received: from igate2.vodafone.co.uk ([194.62.232.66]) by ietf-mx with esmtp (Exim 4.12) id 19UpDs-0003SD-00 for simple@ietf.org; Tue, 24 Jun 2003 10:56:40 -0400 Received: by igate2.vodafone.co.uk; (8.8.8/1.3/10May95) id PAA02775; Tue, 24 Jun 2003 15:55:45 +0100 (BST) Received: from ukwmxc01.vf-uk.internal.vodafone.com (ukwmxc01 [10.33.126.160]) by mailguard1 (4.6.1.123) with ESMTP id ; Tue, 24 Jun 2003 15:55:44 +0100 Received: from ukwmxc03.vf-uk.internal.vodafone.com ([10.33.126.155]) by ukwmxc01.vf-uk.internal.vodafone.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 24 Jun 2003 15:55:30 +0100 Received: from ukwmxm02.vf-uk.internal.vodafone.com ([10.33.126.242]) by ukwmxc03.vf-uk.internal.vodafone.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 24 Jun 2003 15:55:28 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message Subject: RE: [Simple] Sending 1 to n MESSAGEs Message-ID: Thread-Topic: [Simple] Sending 1 to n MESSAGEs Thread-Index: AcM6XltoDR2uFgjdRZKYwWVhhg9Y5AAATJhg From: "Mills, Duncan, D, CND Tech Dev, VF UK" To: "Rosen, Brian" , X-OriginalArrivalTime: 24 Jun 2003 14:55:28.0645 (UTC) FILETIME=[A6D05B50:01C33A60] MIME-Version: 1.0 (Generated by Clearswift ES version 4.6.1.122) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 24 Jun 2003 15:55:28 +0100 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Dear CLEVER people (of the SIMPLE WG) ;-) Brian- yes, my thought was to allow a B2BUA function to fork the MESSAGE = request. This way, the user doesn't have to pre-configure the recipient = list, but perhaps they do have to pre-configure the address of their = MESSAGING server (the B2BUA). When I say pre-configure, I'm sure there = are more dynamic ways to get the B2BUA address to the UA. I must admit, I am coming at this from the 3GPP perspective and so a SIP = AS (acting in B2BUA mode) would seem to do the trick. However, it would = require- I believe- some extensions to SIP. However, 3GPP radio interface constraints aside, I think it would be a = shame to design SIP messaging without the ability to fork a message to n = recipients, in the same way you can with e-mail. Thanks for your initial thoughts- I'd be interested in progressing this = issue, if you and others feel it worthwhile... Cheers, Duncan -----Original Message----- From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] Sent: 24 June 2003 15:38 To: Mills, Duncan, D, CND Tech Dev, VF UK; simple@ietf.org Subject: RE: [Simple] Sending 1 to n MESSAGEs Was the salutation to your message a comment on the quality of the discourse on this list? ;) =20 Good thought. Interacts with conferencing (mass invite to a = conference). You don't want to have to have a complex interaction prior to sending a list of recipients. Smells like a kind of forking behavior, but=20 clearly different (not all the same AOR). Obviously creates multiple dialogs if/when multiple responses are received. The proxy can't be the origination point; it's not a UA. All the responses are going to be forwarded to the UA. The only way around that is B2BUA behavior. Is that a better, or a worse idea? Gotta think through what this means for Message Sessions. You want the proxy to replicate each message, but you don't really want to repeat the list of recipients. Does that argue for B2BUA more strongly? With a B2BUA approach you send the message to the exploder. It sends individual messages to recipients, and handles all the dialogs. That reminds me of a buddy list subscription without the prearranged=20 buddy list. Brian > -----Original Message----- > From: Mills, Duncan, D, CND Tech Dev, VF UK > [mailto:Duncan.Mills@gb.vodafone.co.uk] > Sent: Tuesday, June 24, 2003 9:42 AM > To: simple@ietf.org > Subject: [Simple] Sending 1 to n MESSAGEs >=20 >=20 > SIMPLE people, >=20 > I've just been thinking about how my e-mail works, and what I=20 > like best about it. It is really easy to type a long message=20 > and then send it to a list of (more than one) people. Better=20 > still, I don't have to have pre-configured that list of=20 > people. I can just type in the addresses in the To: field=20 > and the mail will be sent to each address. >=20 > As far as I know, I can't do this with the SIP MESSAGE=20 > method. Yes, I can create a resource URI in a server and=20 > send one MESSAGE request to that resource-URI, and the server=20 > may fork the MESSAGE to each URI in my pre-configured list. =20 > But if I don't want to have to set up a new list of=20 > recipients each time I send a MESSAGE then I have to send the=20 > same MESSAGE several times. Please correct me if I'm wrong. >=20 > Now... looking at this from a wireless operator perspective,=20 > I immediately see warning signs about my =A36 billion radio=20 > interface ;-) Currently, in GSM, if we want to send an SMS=20 > to more 'n' recipients, we have the same situation- either=20 > create a user group in the network or send the message 'n'=20 > times. However, a SIP MESSAGE request is likely to be about=20 > ten times the size of an SMS. >=20 > Is this a problem? If not, why not? Maybe I'm missing some=20 > background/historical information? >=20 > If it is a problem, might it be possible to extend SIP in=20 > such a way as to state that the request-URI be set to the=20 > address of my SIP proxy server in my home network and then=20 > the To: field be filled with the list of intended recipients,=20 > with the server then being responsible for sending the=20 > MESSAGE to all the intended recipients? >=20 > Any comments/views? >=20 > Best Regards, >=20 > Duncan >=20 >=20 > Duncan Mills > Senior Engineer > Network Standards & Technical Audit > Technology Development (Network Systems) > Vodafone (UK) Ltd > Tel: +44 (0)1635 676074 > Mob: +44 7867 900955 > Fax: +44 (0)1635 234445 > mailto:duncan.mills@vf.vodafone.co.uk >=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 Jun 24 11:10:10 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 LAA19665; Tue, 24 Jun 2003 11:10:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UpQx-0003ZH-00; Tue, 24 Jun 2003 11:10:11 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19UpQr-0003ZE-00; Tue, 24 Jun 2003 11:10:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UpQm-0006gE-SM; Tue, 24 Jun 2003 11:10:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UpPr-0006a7-BJ for simple@optimus.ietf.org; Tue, 24 Jun 2003 11:09:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19605 for ; Tue, 24 Jun 2003 11:08:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UpPo-0003Xv-00 for simple@ietf.org; Tue, 24 Jun 2003 11:09:00 -0400 Received: from mail1.dynamicsoft.com ([63.113.40.10] helo=mail2.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19UpPd-0003X0-00 for simple@ietf.org; Tue, 24 Jun 2003 11:08:49 -0400 Received: from DYN-EXCH-01.dynamicsoft.com (dyn-exch-001b [63.113.44.8]) by mail2.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h5OF459O007277; Tue, 24 Jun 2003 11:04:05 -0400 (EDT) Received: by DYN-EXCH-01.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Tue, 24 Jun 2003 11:06:27 -0400 Message-ID: <786B3DFD70C41E49BFA5DE59F611862803E318@DYN-EXCH-01.dynamicsoft.com> From: Chris Harris To: "'Mills, Duncan, D, CND Tech Dev, VF UK'" , "Rosen, Brian" , simple@ietf.org Subject: RE: [Simple] Sending 1 to n MESSAGEs MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mail2.dynamicsoft.com id h5OF459O007277 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, 24 Jun 2003 11:06:23 -0400 Content-Transfer-Encoding: quoted-printable Duncan, One possibility for this ad-hoc group messaging is to address the message= to a message exploder application, and to use other custom headers for the l= ist of actual recipients (say a list of X-Recipient: headers) that the explod= er understands. Once the exploder accepts the message it would presumably se= nd a 202 response to the sender and be responsible for the delivery of the messages to the recipients. Regards, Chris Harris=20 > -----Original Message----- > From: Mills, Duncan, D, CND Tech Dev, VF UK > [mailto:Duncan.Mills@gb.vodafone.co.uk] > Sent: Tuesday, June 24, 2003 10:55 AM > To: Rosen, Brian; simple@ietf.org > Subject: RE: [Simple] Sending 1 to n MESSAGEs >=20 >=20 > Dear CLEVER people (of the SIMPLE WG) ;-) >=20 > Brian- yes, my thought was to allow a B2BUA function to fork=20 > the MESSAGE request. This way, the user doesn't have to=20 > pre-configure the recipient list, but perhaps they do have to=20 > pre-configure the address of their MESSAGING server (the=20 > B2BUA). When I say pre-configure, I'm sure there are more=20 > dynamic ways to get the B2BUA address to the UA. >=20 > I must admit, I am coming at this from the 3GPP perspective=20 > and so a SIP AS (acting in B2BUA mode) would seem to do the=20 > trick. However, it would require- I believe- some extensions to SIP. >=20 > However, 3GPP radio interface constraints aside, I think it=20 > would be a shame to design SIP messaging without the ability=20 > to fork a message to n recipients, in the same way you can=20 > with e-mail. >=20 > Thanks for your initial thoughts- I'd be interested in=20 > progressing this issue, if you and others feel it worthwhile... >=20 > Cheers, >=20 > Duncan >=20 >=20 > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: 24 June 2003 15:38 > To: Mills, Duncan, D, CND Tech Dev, VF UK; simple@ietf.org > Subject: RE: [Simple] Sending 1 to n MESSAGEs >=20 >=20 > Was the salutation to your message a comment on the quality of > the discourse on this list? ;) =20 >=20 > Good thought. Interacts with conferencing (mass invite to a=20 > conference). > You don't want to have to have a complex interaction prior to sending > a list of recipients. Smells like a kind of forking behavior, but=20 > clearly different (not all the same AOR). Obviously creates multiple > dialogs if/when multiple responses are received. The proxy can't be > the origination point; it's not a UA. All the responses are going to > be forwarded to the UA. The only way around that is B2BUA behavior. > Is that a better, or a worse idea? >=20 > Gotta think through what this means for Message Sessions. =20 > You want the > proxy to replicate each message, but you don't really want to repeat > the list of recipients. Does that argue for B2BUA more strongly? >=20 > With a B2BUA approach you send the message to the exploder. It > sends individual messages to recipients, and handles all the dialogs. > That reminds me of a buddy list subscription without the prearranged=20 > buddy list. >=20 > Brian >=20 > > -----Original Message----- > > From: Mills, Duncan, D, CND Tech Dev, VF UK > > [mailto:Duncan.Mills@gb.vodafone.co.uk] > > Sent: Tuesday, June 24, 2003 9:42 AM > > To: simple@ietf.org > > Subject: [Simple] Sending 1 to n MESSAGEs > >=20 > >=20 > > SIMPLE people, > >=20 > > I've just been thinking about how my e-mail works, and what I=20 > > like best about it. It is really easy to type a long message=20 > > and then send it to a list of (more than one) people. Better=20 > > still, I don't have to have pre-configured that list of=20 > > people. I can just type in the addresses in the To: field=20 > > and the mail will be sent to each address. > >=20 > > As far as I know, I can't do this with the SIP MESSAGE=20 > > method. Yes, I can create a resource URI in a server and=20 > > send one MESSAGE request to that resource-URI, and the server=20 > > may fork the MESSAGE to each URI in my pre-configured list. =20 > > But if I don't want to have to set up a new list of=20 > > recipients each time I send a MESSAGE then I have to send the=20 > > same MESSAGE several times. Please correct me if I'm wrong. > >=20 > > Now... looking at this from a wireless operator perspective,=20 > > I immediately see warning signs about my =A36 billion radio=20 > > interface ;-) Currently, in GSM, if we want to send an SMS=20 > > to more 'n' recipients, we have the same situation- either=20 > > create a user group in the network or send the message 'n'=20 > > times. However, a SIP MESSAGE request is likely to be about=20 > > ten times the size of an SMS. > >=20 > > Is this a problem? If not, why not? Maybe I'm missing some=20 > > background/historical information? > >=20 > > If it is a problem, might it be possible to extend SIP in=20 > > such a way as to state that the request-URI be set to the=20 > > address of my SIP proxy server in my home network and then=20 > > the To: field be filled with the list of intended recipients,=20 > > with the server then being responsible for sending the=20 > > MESSAGE to all the intended recipients? > >=20 > > Any comments/views? > >=20 > > Best Regards, > >=20 > > Duncan > >=20 > >=20 > > Duncan Mills > > Senior Engineer > > Network Standards & Technical Audit > > Technology Development (Network Systems) > > Vodafone (UK) Ltd > > Tel: +44 (0)1635 676074 > > Mob: +44 7867 900955 > > Fax: +44 (0)1635 234445 > > mailto:duncan.mills@vf.vodafone.co.uk > >=20 > >=20 > >=20 > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Jun 24 11:10:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19703 for ; Tue, 24 Jun 2003 11:10:41 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5OFAEi25880 for simple-archive@odin.ietf.org; Tue, 24 Jun 2003 11:10:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UpR0-0006jL-S2 for simple-web-archive@optimus.ietf.org; Tue, 24 Jun 2003 11:10:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19665; Tue, 24 Jun 2003 11:10:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UpQx-0003ZH-00; Tue, 24 Jun 2003 11:10:11 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19UpQr-0003ZE-00; Tue, 24 Jun 2003 11:10:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UpQm-0006gE-SM; Tue, 24 Jun 2003 11:10:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UpPr-0006a7-BJ for simple@optimus.ietf.org; Tue, 24 Jun 2003 11:09:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19605 for ; Tue, 24 Jun 2003 11:08:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UpPo-0003Xv-00 for simple@ietf.org; Tue, 24 Jun 2003 11:09:00 -0400 Received: from mail1.dynamicsoft.com ([63.113.40.10] helo=mail2.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19UpPd-0003X0-00 for simple@ietf.org; Tue, 24 Jun 2003 11:08:49 -0400 Received: from DYN-EXCH-01.dynamicsoft.com (dyn-exch-001b [63.113.44.8]) by mail2.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h5OF459O007277; Tue, 24 Jun 2003 11:04:05 -0400 (EDT) Received: by DYN-EXCH-01.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Tue, 24 Jun 2003 11:06:27 -0400 Message-ID: <786B3DFD70C41E49BFA5DE59F611862803E318@DYN-EXCH-01.dynamicsoft.com> From: Chris Harris To: "'Mills, Duncan, D, CND Tech Dev, VF UK'" , "Rosen, Brian" , simple@ietf.org Subject: RE: [Simple] Sending 1 to n MESSAGEs MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mail2.dynamicsoft.com id h5OF459O007277 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, 24 Jun 2003 11:06:23 -0400 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Duncan, One possibility for this ad-hoc group messaging is to address the message= to a message exploder application, and to use other custom headers for the l= ist of actual recipients (say a list of X-Recipient: headers) that the explod= er understands. Once the exploder accepts the message it would presumably se= nd a 202 response to the sender and be responsible for the delivery of the messages to the recipients. Regards, Chris Harris=20 > -----Original Message----- > From: Mills, Duncan, D, CND Tech Dev, VF UK > [mailto:Duncan.Mills@gb.vodafone.co.uk] > Sent: Tuesday, June 24, 2003 10:55 AM > To: Rosen, Brian; simple@ietf.org > Subject: RE: [Simple] Sending 1 to n MESSAGEs >=20 >=20 > Dear CLEVER people (of the SIMPLE WG) ;-) >=20 > Brian- yes, my thought was to allow a B2BUA function to fork=20 > the MESSAGE request. This way, the user doesn't have to=20 > pre-configure the recipient list, but perhaps they do have to=20 > pre-configure the address of their MESSAGING server (the=20 > B2BUA). When I say pre-configure, I'm sure there are more=20 > dynamic ways to get the B2BUA address to the UA. >=20 > I must admit, I am coming at this from the 3GPP perspective=20 > and so a SIP AS (acting in B2BUA mode) would seem to do the=20 > trick. However, it would require- I believe- some extensions to SIP. >=20 > However, 3GPP radio interface constraints aside, I think it=20 > would be a shame to design SIP messaging without the ability=20 > to fork a message to n recipients, in the same way you can=20 > with e-mail. >=20 > Thanks for your initial thoughts- I'd be interested in=20 > progressing this issue, if you and others feel it worthwhile... >=20 > Cheers, >=20 > Duncan >=20 >=20 > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: 24 June 2003 15:38 > To: Mills, Duncan, D, CND Tech Dev, VF UK; simple@ietf.org > Subject: RE: [Simple] Sending 1 to n MESSAGEs >=20 >=20 > Was the salutation to your message a comment on the quality of > the discourse on this list? ;) =20 >=20 > Good thought. Interacts with conferencing (mass invite to a=20 > conference). > You don't want to have to have a complex interaction prior to sending > a list of recipients. Smells like a kind of forking behavior, but=20 > clearly different (not all the same AOR). Obviously creates multiple > dialogs if/when multiple responses are received. The proxy can't be > the origination point; it's not a UA. All the responses are going to > be forwarded to the UA. The only way around that is B2BUA behavior. > Is that a better, or a worse idea? >=20 > Gotta think through what this means for Message Sessions. =20 > You want the > proxy to replicate each message, but you don't really want to repeat > the list of recipients. Does that argue for B2BUA more strongly? >=20 > With a B2BUA approach you send the message to the exploder. It > sends individual messages to recipients, and handles all the dialogs. > That reminds me of a buddy list subscription without the prearranged=20 > buddy list. >=20 > Brian >=20 > > -----Original Message----- > > From: Mills, Duncan, D, CND Tech Dev, VF UK > > [mailto:Duncan.Mills@gb.vodafone.co.uk] > > Sent: Tuesday, June 24, 2003 9:42 AM > > To: simple@ietf.org > > Subject: [Simple] Sending 1 to n MESSAGEs > >=20 > >=20 > > SIMPLE people, > >=20 > > I've just been thinking about how my e-mail works, and what I=20 > > like best about it. It is really easy to type a long message=20 > > and then send it to a list of (more than one) people. Better=20 > > still, I don't have to have pre-configured that list of=20 > > people. I can just type in the addresses in the To: field=20 > > and the mail will be sent to each address. > >=20 > > As far as I know, I can't do this with the SIP MESSAGE=20 > > method. Yes, I can create a resource URI in a server and=20 > > send one MESSAGE request to that resource-URI, and the server=20 > > may fork the MESSAGE to each URI in my pre-configured list. =20 > > But if I don't want to have to set up a new list of=20 > > recipients each time I send a MESSAGE then I have to send the=20 > > same MESSAGE several times. Please correct me if I'm wrong. > >=20 > > Now... looking at this from a wireless operator perspective,=20 > > I immediately see warning signs about my =A36 billion radio=20 > > interface ;-) Currently, in GSM, if we want to send an SMS=20 > > to more 'n' recipients, we have the same situation- either=20 > > create a user group in the network or send the message 'n'=20 > > times. However, a SIP MESSAGE request is likely to be about=20 > > ten times the size of an SMS. > >=20 > > Is this a problem? If not, why not? Maybe I'm missing some=20 > > background/historical information? > >=20 > > If it is a problem, might it be possible to extend SIP in=20 > > such a way as to state that the request-URI be set to the=20 > > address of my SIP proxy server in my home network and then=20 > > the To: field be filled with the list of intended recipients,=20 > > with the server then being responsible for sending the=20 > > MESSAGE to all the intended recipients? > >=20 > > Any comments/views? > >=20 > > Best Regards, > >=20 > > Duncan > >=20 > >=20 > > Duncan Mills > > Senior Engineer > > Network Standards & Technical Audit > > Technology Development (Network Systems) > > Vodafone (UK) Ltd > > Tel: +44 (0)1635 676074 > > Mob: +44 7867 900955 > > Fax: +44 (0)1635 234445 > > mailto:duncan.mills@vf.vodafone.co.uk > >=20 > >=20 > >=20 > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Jun 24 11:15:10 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 LAA19826; Tue, 24 Jun 2003 11:15:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UpVn-0003ao-00; Tue, 24 Jun 2003 11:15:11 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19UpVh-0003al-00; Tue, 24 Jun 2003 11:15:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UpVd-0006t0-DG; Tue, 24 Jun 2003 11:15:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UpV7-0006ry-IC for simple@optimus.ietf.org; Tue, 24 Jun 2003 11:14: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 LAA19796 for ; Tue, 24 Jun 2003 11:14:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UpV6-0003a6-00 for simple@ietf.org; Tue, 24 Jun 2003 11:14:28 -0400 Received: from igate2.vodafone.co.uk ([194.62.232.66]) by ietf-mx with esmtp (Exim 4.12) id 19UpUs-0003Zy-00 for simple@ietf.org; Tue, 24 Jun 2003 11:14:14 -0400 Received: by igate2.vodafone.co.uk; (8.8.8/1.3/10May95) id QAA09080; Tue, 24 Jun 2003 16:13:36 +0100 (BST) Received: from ukwmxc02.vf-uk.internal.vodafone.com (ukwmxc02 [10.33.126.170]) by mailguard2 (4.6.1.123) with ESMTP id ; Tue, 24 Jun 2003 16:10:59 +0100 Received: from ukwmxc04.vf-uk.internal.vodafone.com ([10.33.126.173]) by ukwmxc02.vf-uk.internal.vodafone.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 24 Jun 2003 16:13:06 +0100 Received: from ukwmxm02.vf-uk.internal.vodafone.com ([10.33.126.242]) by ukwmxc04.vf-uk.internal.vodafone.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 24 Jun 2003 16:13:03 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message Subject: RE: [Simple] Sending 1 to n MESSAGEs Message-ID: Thread-Topic: [Simple] Sending 1 to n MESSAGEs Thread-Index: AcM6Yk7hUE6eq5AARvGA969Z94cyvgAAKZjg From: "Mills, Duncan, D, CND Tech Dev, VF UK" To: "Chris Harris" , "Rosen, Brian" , X-OriginalArrivalTime: 24 Jun 2003 15:13:03.0450 (UTC) FILETIME=[1B86D3A0:01C33A63] MIME-Version: 1.0 (Generated by Clearswift ES version 4.6.1.122) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 24 Jun 2003 16:13:02 +0100 Content-Transfer-Encoding: quoted-printable Chris, Thanks for your thoughts. I agree, that a custome header of some sort = would help. I'd probably want to standardise that header with an RFC = though- what are thoughts on this? Duncan -----Original Message----- From: Chris Harris [mailto:CHarris@dynamicsoft.com] Sent: 24 June 2003 16:06 To: Mills, Duncan, D, CND Tech Dev, VF UK; Rosen, Brian; simple@ietf.org Subject: RE: [Simple] Sending 1 to n MESSAGEs Duncan, One possibility for this ad-hoc group messaging is to address the = message to a message exploder application, and to use other custom headers for the = list of actual recipients (say a list of X-Recipient: headers) that the = exploder understands. Once the exploder accepts the message it would presumably = send a 202 response to the sender and be responsible for the delivery of the messages to the recipients. Regards, Chris Harris=20 > -----Original Message----- > From: Mills, Duncan, D, CND Tech Dev, VF UK > [mailto:Duncan.Mills@gb.vodafone.co.uk] > Sent: Tuesday, June 24, 2003 10:55 AM > To: Rosen, Brian; simple@ietf.org > Subject: RE: [Simple] Sending 1 to n MESSAGEs >=20 >=20 > Dear CLEVER people (of the SIMPLE WG) ;-) >=20 > Brian- yes, my thought was to allow a B2BUA function to fork=20 > the MESSAGE request. This way, the user doesn't have to=20 > pre-configure the recipient list, but perhaps they do have to=20 > pre-configure the address of their MESSAGING server (the=20 > B2BUA). When I say pre-configure, I'm sure there are more=20 > dynamic ways to get the B2BUA address to the UA. >=20 > I must admit, I am coming at this from the 3GPP perspective=20 > and so a SIP AS (acting in B2BUA mode) would seem to do the=20 > trick. However, it would require- I believe- some extensions to SIP. >=20 > However, 3GPP radio interface constraints aside, I think it=20 > would be a shame to design SIP messaging without the ability=20 > to fork a message to n recipients, in the same way you can=20 > with e-mail. >=20 > Thanks for your initial thoughts- I'd be interested in=20 > progressing this issue, if you and others feel it worthwhile... >=20 > Cheers, >=20 > Duncan >=20 >=20 > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: 24 June 2003 15:38 > To: Mills, Duncan, D, CND Tech Dev, VF UK; simple@ietf.org > Subject: RE: [Simple] Sending 1 to n MESSAGEs >=20 >=20 > Was the salutation to your message a comment on the quality of > the discourse on this list? ;) =20 >=20 > Good thought. Interacts with conferencing (mass invite to a=20 > conference). > You don't want to have to have a complex interaction prior to sending > a list of recipients. Smells like a kind of forking behavior, but=20 > clearly different (not all the same AOR). Obviously creates multiple > dialogs if/when multiple responses are received. The proxy can't be > the origination point; it's not a UA. All the responses are going to > be forwarded to the UA. The only way around that is B2BUA behavior. > Is that a better, or a worse idea? >=20 > Gotta think through what this means for Message Sessions. =20 > You want the > proxy to replicate each message, but you don't really want to repeat > the list of recipients. Does that argue for B2BUA more strongly? >=20 > With a B2BUA approach you send the message to the exploder. It > sends individual messages to recipients, and handles all the dialogs. > That reminds me of a buddy list subscription without the prearranged=20 > buddy list. >=20 > Brian >=20 > > -----Original Message----- > > From: Mills, Duncan, D, CND Tech Dev, VF UK > > [mailto:Duncan.Mills@gb.vodafone.co.uk] > > Sent: Tuesday, June 24, 2003 9:42 AM > > To: simple@ietf.org > > Subject: [Simple] Sending 1 to n MESSAGEs > >=20 > >=20 > > SIMPLE people, > >=20 > > I've just been thinking about how my e-mail works, and what I=20 > > like best about it. It is really easy to type a long message=20 > > and then send it to a list of (more than one) people. Better=20 > > still, I don't have to have pre-configured that list of=20 > > people. I can just type in the addresses in the To: field=20 > > and the mail will be sent to each address. > >=20 > > As far as I know, I can't do this with the SIP MESSAGE=20 > > method. Yes, I can create a resource URI in a server and=20 > > send one MESSAGE request to that resource-URI, and the server=20 > > may fork the MESSAGE to each URI in my pre-configured list. =20 > > But if I don't want to have to set up a new list of=20 > > recipients each time I send a MESSAGE then I have to send the=20 > > same MESSAGE several times. Please correct me if I'm wrong. > >=20 > > Now... looking at this from a wireless operator perspective,=20 > > I immediately see warning signs about my =A36 billion radio=20 > > interface ;-) Currently, in GSM, if we want to send an SMS=20 > > to more 'n' recipients, we have the same situation- either=20 > > create a user group in the network or send the message 'n'=20 > > times. However, a SIP MESSAGE request is likely to be about=20 > > ten times the size of an SMS. > >=20 > > Is this a problem? If not, why not? Maybe I'm missing some=20 > > background/historical information? > >=20 > > If it is a problem, might it be possible to extend SIP in=20 > > such a way as to state that the request-URI be set to the=20 > > address of my SIP proxy server in my home network and then=20 > > the To: field be filled with the list of intended recipients,=20 > > with the server then being responsible for sending the=20 > > MESSAGE to all the intended recipients? > >=20 > > Any comments/views? > >=20 > > Best Regards, > >=20 > > Duncan > >=20 > >=20 > > Duncan Mills > > Senior Engineer > > Network Standards & Technical Audit > > Technology Development (Network Systems) > > Vodafone (UK) Ltd > > Tel: +44 (0)1635 676074 > > Mob: +44 7867 900955 > > Fax: +44 (0)1635 234445 > > mailto:duncan.mills@vf.vodafone.co.uk > >=20 > >=20 > >=20 > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Jun 24 11:15:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19856 for ; Tue, 24 Jun 2003 11:15:41 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5OFFD626712 for simple-archive@odin.ietf.org; Tue, 24 Jun 2003 11:15:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UpVp-0006wl-Db for simple-web-archive@optimus.ietf.org; Tue, 24 Jun 2003 11:15:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19826; Tue, 24 Jun 2003 11:15:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UpVn-0003ao-00; Tue, 24 Jun 2003 11:15:11 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19UpVh-0003al-00; Tue, 24 Jun 2003 11:15:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UpVd-0006t0-DG; Tue, 24 Jun 2003 11:15:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UpV7-0006ry-IC for simple@optimus.ietf.org; Tue, 24 Jun 2003 11:14: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 LAA19796 for ; Tue, 24 Jun 2003 11:14:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UpV6-0003a6-00 for simple@ietf.org; Tue, 24 Jun 2003 11:14:28 -0400 Received: from igate2.vodafone.co.uk ([194.62.232.66]) by ietf-mx with esmtp (Exim 4.12) id 19UpUs-0003Zy-00 for simple@ietf.org; Tue, 24 Jun 2003 11:14:14 -0400 Received: by igate2.vodafone.co.uk; (8.8.8/1.3/10May95) id QAA09080; Tue, 24 Jun 2003 16:13:36 +0100 (BST) Received: from ukwmxc02.vf-uk.internal.vodafone.com (ukwmxc02 [10.33.126.170]) by mailguard2 (4.6.1.123) with ESMTP id ; Tue, 24 Jun 2003 16:10:59 +0100 Received: from ukwmxc04.vf-uk.internal.vodafone.com ([10.33.126.173]) by ukwmxc02.vf-uk.internal.vodafone.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 24 Jun 2003 16:13:06 +0100 Received: from ukwmxm02.vf-uk.internal.vodafone.com ([10.33.126.242]) by ukwmxc04.vf-uk.internal.vodafone.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 24 Jun 2003 16:13:03 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message Subject: RE: [Simple] Sending 1 to n MESSAGEs Message-ID: Thread-Topic: [Simple] Sending 1 to n MESSAGEs Thread-Index: AcM6Yk7hUE6eq5AARvGA969Z94cyvgAAKZjg From: "Mills, Duncan, D, CND Tech Dev, VF UK" To: "Chris Harris" , "Rosen, Brian" , X-OriginalArrivalTime: 24 Jun 2003 15:13:03.0450 (UTC) FILETIME=[1B86D3A0:01C33A63] MIME-Version: 1.0 (Generated by Clearswift ES version 4.6.1.122) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 24 Jun 2003 16:13:02 +0100 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Chris, Thanks for your thoughts. I agree, that a custome header of some sort = would help. I'd probably want to standardise that header with an RFC = though- what are thoughts on this? Duncan -----Original Message----- From: Chris Harris [mailto:CHarris@dynamicsoft.com] Sent: 24 June 2003 16:06 To: Mills, Duncan, D, CND Tech Dev, VF UK; Rosen, Brian; simple@ietf.org Subject: RE: [Simple] Sending 1 to n MESSAGEs Duncan, One possibility for this ad-hoc group messaging is to address the = message to a message exploder application, and to use other custom headers for the = list of actual recipients (say a list of X-Recipient: headers) that the = exploder understands. Once the exploder accepts the message it would presumably = send a 202 response to the sender and be responsible for the delivery of the messages to the recipients. Regards, Chris Harris=20 > -----Original Message----- > From: Mills, Duncan, D, CND Tech Dev, VF UK > [mailto:Duncan.Mills@gb.vodafone.co.uk] > Sent: Tuesday, June 24, 2003 10:55 AM > To: Rosen, Brian; simple@ietf.org > Subject: RE: [Simple] Sending 1 to n MESSAGEs >=20 >=20 > Dear CLEVER people (of the SIMPLE WG) ;-) >=20 > Brian- yes, my thought was to allow a B2BUA function to fork=20 > the MESSAGE request. This way, the user doesn't have to=20 > pre-configure the recipient list, but perhaps they do have to=20 > pre-configure the address of their MESSAGING server (the=20 > B2BUA). When I say pre-configure, I'm sure there are more=20 > dynamic ways to get the B2BUA address to the UA. >=20 > I must admit, I am coming at this from the 3GPP perspective=20 > and so a SIP AS (acting in B2BUA mode) would seem to do the=20 > trick. However, it would require- I believe- some extensions to SIP. >=20 > However, 3GPP radio interface constraints aside, I think it=20 > would be a shame to design SIP messaging without the ability=20 > to fork a message to n recipients, in the same way you can=20 > with e-mail. >=20 > Thanks for your initial thoughts- I'd be interested in=20 > progressing this issue, if you and others feel it worthwhile... >=20 > Cheers, >=20 > Duncan >=20 >=20 > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: 24 June 2003 15:38 > To: Mills, Duncan, D, CND Tech Dev, VF UK; simple@ietf.org > Subject: RE: [Simple] Sending 1 to n MESSAGEs >=20 >=20 > Was the salutation to your message a comment on the quality of > the discourse on this list? ;) =20 >=20 > Good thought. Interacts with conferencing (mass invite to a=20 > conference). > You don't want to have to have a complex interaction prior to sending > a list of recipients. Smells like a kind of forking behavior, but=20 > clearly different (not all the same AOR). Obviously creates multiple > dialogs if/when multiple responses are received. The proxy can't be > the origination point; it's not a UA. All the responses are going to > be forwarded to the UA. The only way around that is B2BUA behavior. > Is that a better, or a worse idea? >=20 > Gotta think through what this means for Message Sessions. =20 > You want the > proxy to replicate each message, but you don't really want to repeat > the list of recipients. Does that argue for B2BUA more strongly? >=20 > With a B2BUA approach you send the message to the exploder. It > sends individual messages to recipients, and handles all the dialogs. > That reminds me of a buddy list subscription without the prearranged=20 > buddy list. >=20 > Brian >=20 > > -----Original Message----- > > From: Mills, Duncan, D, CND Tech Dev, VF UK > > [mailto:Duncan.Mills@gb.vodafone.co.uk] > > Sent: Tuesday, June 24, 2003 9:42 AM > > To: simple@ietf.org > > Subject: [Simple] Sending 1 to n MESSAGEs > >=20 > >=20 > > SIMPLE people, > >=20 > > I've just been thinking about how my e-mail works, and what I=20 > > like best about it. It is really easy to type a long message=20 > > and then send it to a list of (more than one) people. Better=20 > > still, I don't have to have pre-configured that list of=20 > > people. I can just type in the addresses in the To: field=20 > > and the mail will be sent to each address. > >=20 > > As far as I know, I can't do this with the SIP MESSAGE=20 > > method. Yes, I can create a resource URI in a server and=20 > > send one MESSAGE request to that resource-URI, and the server=20 > > may fork the MESSAGE to each URI in my pre-configured list. =20 > > But if I don't want to have to set up a new list of=20 > > recipients each time I send a MESSAGE then I have to send the=20 > > same MESSAGE several times. Please correct me if I'm wrong. > >=20 > > Now... looking at this from a wireless operator perspective,=20 > > I immediately see warning signs about my =A36 billion radio=20 > > interface ;-) Currently, in GSM, if we want to send an SMS=20 > > to more 'n' recipients, we have the same situation- either=20 > > create a user group in the network or send the message 'n'=20 > > times. However, a SIP MESSAGE request is likely to be about=20 > > ten times the size of an SMS. > >=20 > > Is this a problem? If not, why not? Maybe I'm missing some=20 > > background/historical information? > >=20 > > If it is a problem, might it be possible to extend SIP in=20 > > such a way as to state that the request-URI be set to the=20 > > address of my SIP proxy server in my home network and then=20 > > the To: field be filled with the list of intended recipients,=20 > > with the server then being responsible for sending the=20 > > MESSAGE to all the intended recipients? > >=20 > > Any comments/views? > >=20 > > Best Regards, > >=20 > > Duncan > >=20 > >=20 > > Duncan Mills > > Senior Engineer > > Network Standards & Technical Audit > > Technology Development (Network Systems) > > Vodafone (UK) Ltd > > Tel: +44 (0)1635 676074 > > Mob: +44 7867 900955 > > Fax: +44 (0)1635 234445 > > mailto:duncan.mills@vf.vodafone.co.uk > >=20 > >=20 > >=20 > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Jun 24 11:21: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 LAA20149; Tue, 24 Jun 2003 11:21:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Upbd-0003eg-00; Tue, 24 Jun 2003 11:21:13 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19UpbY-0003ed-00; Tue, 24 Jun 2003 11:21:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UpbR-000790-CT; Tue, 24 Jun 2003 11: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 19Upb0-00077s-3W for simple@optimus.ietf.org; Tue, 24 Jun 2003 11:20:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20114 for ; Tue, 24 Jun 2003 11:20:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Upaz-0003eG-00 for simple@ietf.org; Tue, 24 Jun 2003 11:20:33 -0400 Received: from news.ubiquity.net ([194.202.146.92] helo=gbnewp0186s1.eu.ubiquity.net) by ietf-mx with smtp (Exim 4.12) id 19Upan-0003e7-00 for simple@ietf.org; Tue, 24 Jun 2003 11:20:21 -0400 Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; Tue, 24 Jun 2003 16:22:58 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Sending 1 to n MESSAGEs Message-ID: <45730E094814E44488F789C1CDED27AE01E22BF4@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [Simple] Sending 1 to n MESSAGEs Thread-Index: AcM6Yk7hUE6eq5AARvGA969Z94cyvgAAKZjgAAA+L1A= From: "Chris Boulton" To: "Mills, Duncan, D, CND Tech Dev, VF UK" , "Chris Harris" , "Rosen, Brian" , 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, 24 Jun 2003 16:20:12 +0100 Content-Transfer-Encoding: quoted-printable Chris, Wouldn't this be an expensive way of including a list of X-recipients = (message size)? Chris B. >-----Original Message----- >From: Mills, Duncan, D, CND Tech Dev, VF UK >[mailto:Duncan.Mills@gb.vodafone.co.uk] >Sent: 24 June 2003 16:13 >To: Chris Harris; Rosen, Brian; simple@ietf.org >Subject: RE: [Simple] Sending 1 to n MESSAGEs > >Chris, > >Thanks for your thoughts. I agree, that a custome header of some sort >would help. I'd probably want to standardise that header with an RFC >though- what are thoughts on this? > >Duncan > >-----Original Message----- >From: Chris Harris [mailto:CHarris@dynamicsoft.com] >Sent: 24 June 2003 16:06 >To: Mills, Duncan, D, CND Tech Dev, VF UK; Rosen, Brian; = simple@ietf.org >Subject: RE: [Simple] Sending 1 to n MESSAGEs > > >Duncan, > >One possibility for this ad-hoc group messaging is to address the = message >to >a message exploder application, and to use other custom headers for the >list >of actual recipients (say a list of X-Recipient: headers) that the = exploder >understands. Once the exploder accepts the message it would presumably = send >a 202 response to the sender and be responsible for the delivery of the >messages to the recipients. > >Regards, >Chris Harris > >> -----Original Message----- >> From: Mills, Duncan, D, CND Tech Dev, VF UK >> [mailto:Duncan.Mills@gb.vodafone.co.uk] >> Sent: Tuesday, June 24, 2003 10:55 AM >> To: Rosen, Brian; simple@ietf.org >> Subject: RE: [Simple] Sending 1 to n MESSAGEs >> >> >> Dear CLEVER people (of the SIMPLE WG) ;-) >> >> Brian- yes, my thought was to allow a B2BUA function to fork >> the MESSAGE request. This way, the user doesn't have to >> pre-configure the recipient list, but perhaps they do have to >> pre-configure the address of their MESSAGING server (the >> B2BUA). When I say pre-configure, I'm sure there are more >> dynamic ways to get the B2BUA address to the UA. >> >> I must admit, I am coming at this from the 3GPP perspective >> and so a SIP AS (acting in B2BUA mode) would seem to do the >> trick. However, it would require- I believe- some extensions to SIP. >> >> However, 3GPP radio interface constraints aside, I think it >> would be a shame to design SIP messaging without the ability >> to fork a message to n recipients, in the same way you can >> with e-mail. >> >> Thanks for your initial thoughts- I'd be interested in >> progressing this issue, if you and others feel it worthwhile... >> >> Cheers, >> >> Duncan >> >> >> -----Original Message----- >> From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] >> Sent: 24 June 2003 15:38 >> To: Mills, Duncan, D, CND Tech Dev, VF UK; simple@ietf.org >> Subject: RE: [Simple] Sending 1 to n MESSAGEs >> >> >> Was the salutation to your message a comment on the quality of >> the discourse on this list? ;) >> >> Good thought. Interacts with conferencing (mass invite to a >> conference). >> You don't want to have to have a complex interaction prior to sending >> a list of recipients. Smells like a kind of forking behavior, but >> clearly different (not all the same AOR). Obviously creates multiple >> dialogs if/when multiple responses are received. The proxy can't be >> the origination point; it's not a UA. All the responses are going to >> be forwarded to the UA. The only way around that is B2BUA behavior. >> Is that a better, or a worse idea? >> >> Gotta think through what this means for Message Sessions. >> You want the >> proxy to replicate each message, but you don't really want to repeat >> the list of recipients. Does that argue for B2BUA more strongly? >> >> With a B2BUA approach you send the message to the exploder. It >> sends individual messages to recipients, and handles all the dialogs. >> That reminds me of a buddy list subscription without the prearranged >> buddy list. >> >> Brian >> >> > -----Original Message----- >> > From: Mills, Duncan, D, CND Tech Dev, VF UK >> > [mailto:Duncan.Mills@gb.vodafone.co.uk] >> > Sent: Tuesday, June 24, 2003 9:42 AM >> > To: simple@ietf.org >> > Subject: [Simple] Sending 1 to n MESSAGEs >> > >> > >> > SIMPLE people, >> > >> > I've just been thinking about how my e-mail works, and what I >> > like best about it. It is really easy to type a long message >> > and then send it to a list of (more than one) people. Better >> > still, I don't have to have pre-configured that list of >> > people. I can just type in the addresses in the To: field >> > and the mail will be sent to each address. >> > >> > As far as I know, I can't do this with the SIP MESSAGE >> > method. Yes, I can create a resource URI in a server and >> > send one MESSAGE request to that resource-URI, and the server >> > may fork the MESSAGE to each URI in my pre-configured list. >> > But if I don't want to have to set up a new list of >> > recipients each time I send a MESSAGE then I have to send the >> > same MESSAGE several times. Please correct me if I'm wrong. >> > >> > Now... looking at this from a wireless operator perspective, >> > I immediately see warning signs about my =A36 billion radio >> > interface ;-) Currently, in GSM, if we want to send an SMS >> > to more 'n' recipients, we have the same situation- either >> > create a user group in the network or send the message 'n' >> > times. However, a SIP MESSAGE request is likely to be about >> > ten times the size of an SMS. >> > >> > Is this a problem? If not, why not? Maybe I'm missing some >> > background/historical information? >> > >> > If it is a problem, might it be possible to extend SIP in >> > such a way as to state that the request-URI be set to the >> > address of my SIP proxy server in my home network and then >> > the To: field be filled with the list of intended recipients, >> > with the server then being responsible for sending the >> > MESSAGE to all the intended recipients? >> > >> > Any comments/views? >> > >> > Best Regards, >> > >> > Duncan >> > >> > >> > Duncan Mills >> > Senior Engineer >> > Network Standards & Technical Audit >> > Technology Development (Network Systems) >> > Vodafone (UK) Ltd >> > Tel: +44 (0)1635 676074 >> > Mob: +44 7867 900955 >> > Fax: +44 (0)1635 234445 >> > mailto:duncan.mills@vf.vodafone.co.uk >> > >> > >> > >> > _______________________________________________ >> > Simple mailing list >> > Simple@ietf.org >> > https://www1.ietf.org/mailman/listinfo/simple >> > >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple >> > >_______________________________________________ >Simple mailing list >Simple@ietf.org >https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Jun 24 11:21:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20175 for ; Tue, 24 Jun 2003 11:21:43 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5OFLFP27654 for simple-archive@odin.ietf.org; Tue, 24 Jun 2003 11:21:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Upbf-0007Bx-57 for simple-web-archive@optimus.ietf.org; Tue, 24 Jun 2003 11:21:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20149; Tue, 24 Jun 2003 11:21:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Upbd-0003eg-00; Tue, 24 Jun 2003 11:21:13 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19UpbY-0003ed-00; Tue, 24 Jun 2003 11:21:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UpbR-000790-CT; Tue, 24 Jun 2003 11: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 19Upb0-00077s-3W for simple@optimus.ietf.org; Tue, 24 Jun 2003 11:20:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20114 for ; Tue, 24 Jun 2003 11:20:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Upaz-0003eG-00 for simple@ietf.org; Tue, 24 Jun 2003 11:20:33 -0400 Received: from news.ubiquity.net ([194.202.146.92] helo=gbnewp0186s1.eu.ubiquity.net) by ietf-mx with smtp (Exim 4.12) id 19Upan-0003e7-00 for simple@ietf.org; Tue, 24 Jun 2003 11:20:21 -0400 Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; Tue, 24 Jun 2003 16:22:58 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Sending 1 to n MESSAGEs Message-ID: <45730E094814E44488F789C1CDED27AE01E22BF4@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [Simple] Sending 1 to n MESSAGEs Thread-Index: AcM6Yk7hUE6eq5AARvGA969Z94cyvgAAKZjgAAA+L1A= From: "Chris Boulton" To: "Mills, Duncan, D, CND Tech Dev, VF UK" , "Chris Harris" , "Rosen, Brian" , 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, 24 Jun 2003 16:20:12 +0100 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Chris, Wouldn't this be an expensive way of including a list of X-recipients = (message size)? Chris B. >-----Original Message----- >From: Mills, Duncan, D, CND Tech Dev, VF UK >[mailto:Duncan.Mills@gb.vodafone.co.uk] >Sent: 24 June 2003 16:13 >To: Chris Harris; Rosen, Brian; simple@ietf.org >Subject: RE: [Simple] Sending 1 to n MESSAGEs > >Chris, > >Thanks for your thoughts. I agree, that a custome header of some sort >would help. I'd probably want to standardise that header with an RFC >though- what are thoughts on this? > >Duncan > >-----Original Message----- >From: Chris Harris [mailto:CHarris@dynamicsoft.com] >Sent: 24 June 2003 16:06 >To: Mills, Duncan, D, CND Tech Dev, VF UK; Rosen, Brian; = simple@ietf.org >Subject: RE: [Simple] Sending 1 to n MESSAGEs > > >Duncan, > >One possibility for this ad-hoc group messaging is to address the = message >to >a message exploder application, and to use other custom headers for the >list >of actual recipients (say a list of X-Recipient: headers) that the = exploder >understands. Once the exploder accepts the message it would presumably = send >a 202 response to the sender and be responsible for the delivery of the >messages to the recipients. > >Regards, >Chris Harris > >> -----Original Message----- >> From: Mills, Duncan, D, CND Tech Dev, VF UK >> [mailto:Duncan.Mills@gb.vodafone.co.uk] >> Sent: Tuesday, June 24, 2003 10:55 AM >> To: Rosen, Brian; simple@ietf.org >> Subject: RE: [Simple] Sending 1 to n MESSAGEs >> >> >> Dear CLEVER people (of the SIMPLE WG) ;-) >> >> Brian- yes, my thought was to allow a B2BUA function to fork >> the MESSAGE request. This way, the user doesn't have to >> pre-configure the recipient list, but perhaps they do have to >> pre-configure the address of their MESSAGING server (the >> B2BUA). When I say pre-configure, I'm sure there are more >> dynamic ways to get the B2BUA address to the UA. >> >> I must admit, I am coming at this from the 3GPP perspective >> and so a SIP AS (acting in B2BUA mode) would seem to do the >> trick. However, it would require- I believe- some extensions to SIP. >> >> However, 3GPP radio interface constraints aside, I think it >> would be a shame to design SIP messaging without the ability >> to fork a message to n recipients, in the same way you can >> with e-mail. >> >> Thanks for your initial thoughts- I'd be interested in >> progressing this issue, if you and others feel it worthwhile... >> >> Cheers, >> >> Duncan >> >> >> -----Original Message----- >> From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] >> Sent: 24 June 2003 15:38 >> To: Mills, Duncan, D, CND Tech Dev, VF UK; simple@ietf.org >> Subject: RE: [Simple] Sending 1 to n MESSAGEs >> >> >> Was the salutation to your message a comment on the quality of >> the discourse on this list? ;) >> >> Good thought. Interacts with conferencing (mass invite to a >> conference). >> You don't want to have to have a complex interaction prior to sending >> a list of recipients. Smells like a kind of forking behavior, but >> clearly different (not all the same AOR). Obviously creates multiple >> dialogs if/when multiple responses are received. The proxy can't be >> the origination point; it's not a UA. All the responses are going to >> be forwarded to the UA. The only way around that is B2BUA behavior. >> Is that a better, or a worse idea? >> >> Gotta think through what this means for Message Sessions. >> You want the >> proxy to replicate each message, but you don't really want to repeat >> the list of recipients. Does that argue for B2BUA more strongly? >> >> With a B2BUA approach you send the message to the exploder. It >> sends individual messages to recipients, and handles all the dialogs. >> That reminds me of a buddy list subscription without the prearranged >> buddy list. >> >> Brian >> >> > -----Original Message----- >> > From: Mills, Duncan, D, CND Tech Dev, VF UK >> > [mailto:Duncan.Mills@gb.vodafone.co.uk] >> > Sent: Tuesday, June 24, 2003 9:42 AM >> > To: simple@ietf.org >> > Subject: [Simple] Sending 1 to n MESSAGEs >> > >> > >> > SIMPLE people, >> > >> > I've just been thinking about how my e-mail works, and what I >> > like best about it. It is really easy to type a long message >> > and then send it to a list of (more than one) people. Better >> > still, I don't have to have pre-configured that list of >> > people. I can just type in the addresses in the To: field >> > and the mail will be sent to each address. >> > >> > As far as I know, I can't do this with the SIP MESSAGE >> > method. Yes, I can create a resource URI in a server and >> > send one MESSAGE request to that resource-URI, and the server >> > may fork the MESSAGE to each URI in my pre-configured list. >> > But if I don't want to have to set up a new list of >> > recipients each time I send a MESSAGE then I have to send the >> > same MESSAGE several times. Please correct me if I'm wrong. >> > >> > Now... looking at this from a wireless operator perspective, >> > I immediately see warning signs about my =A36 billion radio >> > interface ;-) Currently, in GSM, if we want to send an SMS >> > to more 'n' recipients, we have the same situation- either >> > create a user group in the network or send the message 'n' >> > times. However, a SIP MESSAGE request is likely to be about >> > ten times the size of an SMS. >> > >> > Is this a problem? If not, why not? Maybe I'm missing some >> > background/historical information? >> > >> > If it is a problem, might it be possible to extend SIP in >> > such a way as to state that the request-URI be set to the >> > address of my SIP proxy server in my home network and then >> > the To: field be filled with the list of intended recipients, >> > with the server then being responsible for sending the >> > MESSAGE to all the intended recipients? >> > >> > Any comments/views? >> > >> > Best Regards, >> > >> > Duncan >> > >> > >> > Duncan Mills >> > Senior Engineer >> > Network Standards & Technical Audit >> > Technology Development (Network Systems) >> > Vodafone (UK) Ltd >> > Tel: +44 (0)1635 676074 >> > Mob: +44 7867 900955 >> > Fax: +44 (0)1635 234445 >> > mailto:duncan.mills@vf.vodafone.co.uk >> > >> > >> > >> > _______________________________________________ >> > Simple mailing list >> > Simple@ietf.org >> > https://www1.ietf.org/mailman/listinfo/simple >> > >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple >> > >_______________________________________________ >Simple mailing list >Simple@ietf.org >https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Jun 24 11:26:10 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 LAA20336; Tue, 24 Jun 2003 11:26:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UpgR-0003gs-00; Tue, 24 Jun 2003 11:26:11 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19UpgL-0003gp-00; Tue, 24 Jun 2003 11:26:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UpgI-0007I1-Bf; Tue, 24 Jun 2003 11:26:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UpfX-0007HF-IC for simple@optimus.ietf.org; Tue, 24 Jun 2003 11:25:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20303 for ; Tue, 24 Jun 2003 11:25:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UpfW-0003gT-00 for simple@ietf.org; Tue, 24 Jun 2003 11:25:14 -0400 Received: from mail1.dynamicsoft.com ([63.113.40.10] helo=mail2.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19UpfK-0003gB-00 for simple@ietf.org; Tue, 24 Jun 2003 11:25:03 -0400 Received: from DYN-EXCH-01.dynamicsoft.com (dyn-exch-001b [63.113.44.8]) by mail2.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h5OFLt9O007364; Tue, 24 Jun 2003 11:21:55 -0400 (EDT) Received: by DYN-EXCH-01.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Tue, 24 Jun 2003 11:24:18 -0400 Message-ID: <786B3DFD70C41E49BFA5DE59F611862803E319@DYN-EXCH-01.dynamicsoft.com> From: Chris Harris To: "'Chris Boulton'" , "Mills, Duncan, D, CND Tech Dev, VF UK" , Chris Harris , "Rosen, Brian" , simple@ietf.org Subject: RE: [Simple] Sending 1 to n MESSAGEs MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mail2.dynamicsoft.com id h5OFLt9O007364 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, 24 Jun 2003 11:24:11 -0400 Content-Transfer-Encoding: quoted-printable Chris B, I would assume that such a header would use comma separated values to sav= e space e.g. X-Recipient: sip:charris@dynamicsoft.com, sip:cboulton@ubiquity.net Chris H > -----Original Message----- > From: Chris Boulton [mailto:cboulton@ubiquity.net] > Sent: Tuesday, June 24, 2003 11:20 AM > To: Mills, Duncan, D, CND Tech Dev, VF UK; Chris Harris; Rosen, Brian; > simple@ietf.org > Subject: RE: [Simple] Sending 1 to n MESSAGEs >=20 >=20 > Chris, >=20 > Wouldn't this be an expensive way of including a list=20 > of X-recipients (message size)? >=20 > Chris B. >=20 >=20 > >-----Original Message----- > >From: Mills, Duncan, D, CND Tech Dev, VF UK > >[mailto:Duncan.Mills@gb.vodafone.co.uk] > >Sent: 24 June 2003 16:13 > >To: Chris Harris; Rosen, Brian; simple@ietf.org > >Subject: RE: [Simple] Sending 1 to n MESSAGEs > > > >Chris, > > > >Thanks for your thoughts. I agree, that a custome header of=20 > some sort > >would help. I'd probably want to standardise that header with an RFC > >though- what are thoughts on this? > > > >Duncan > > > >-----Original Message----- > >From: Chris Harris [mailto:CHarris@dynamicsoft.com] > >Sent: 24 June 2003 16:06 > >To: Mills, Duncan, D, CND Tech Dev, VF UK; Rosen, Brian;=20 > simple@ietf.org > >Subject: RE: [Simple] Sending 1 to n MESSAGEs > > > > > >Duncan, > > > >One possibility for this ad-hoc group messaging is to=20 > address the message > >to > >a message exploder application, and to use other custom=20 > headers for the > >list > >of actual recipients (say a list of X-Recipient: headers)=20 > that the exploder > >understands. Once the exploder accepts the message it would=20 > presumably send > >a 202 response to the sender and be responsible for the=20 > delivery of the > >messages to the recipients. > > > >Regards, > >Chris Harris > > > >> -----Original Message----- > >> From: Mills, Duncan, D, CND Tech Dev, VF UK > >> [mailto:Duncan.Mills@gb.vodafone.co.uk] > >> Sent: Tuesday, June 24, 2003 10:55 AM > >> To: Rosen, Brian; simple@ietf.org > >> Subject: RE: [Simple] Sending 1 to n MESSAGEs > >> > >> > >> Dear CLEVER people (of the SIMPLE WG) ;-) > >> > >> Brian- yes, my thought was to allow a B2BUA function to fork > >> the MESSAGE request. This way, the user doesn't have to > >> pre-configure the recipient list, but perhaps they do have to > >> pre-configure the address of their MESSAGING server (the > >> B2BUA). When I say pre-configure, I'm sure there are more > >> dynamic ways to get the B2BUA address to the UA. > >> > >> I must admit, I am coming at this from the 3GPP perspective > >> and so a SIP AS (acting in B2BUA mode) would seem to do the > >> trick. However, it would require- I believe- some=20 > extensions to SIP. > >> > >> However, 3GPP radio interface constraints aside, I think it > >> would be a shame to design SIP messaging without the ability > >> to fork a message to n recipients, in the same way you can > >> with e-mail. > >> > >> Thanks for your initial thoughts- I'd be interested in > >> progressing this issue, if you and others feel it worthwhile... > >> > >> Cheers, > >> > >> Duncan > >> > >> > >> -----Original Message----- > >> From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > >> Sent: 24 June 2003 15:38 > >> To: Mills, Duncan, D, CND Tech Dev, VF UK; simple@ietf.org > >> Subject: RE: [Simple] Sending 1 to n MESSAGEs > >> > >> > >> Was the salutation to your message a comment on the quality of > >> the discourse on this list? ;) > >> > >> Good thought. Interacts with conferencing (mass invite to a > >> conference). > >> You don't want to have to have a complex interaction prior=20 > to sending > >> a list of recipients. Smells like a kind of forking behavior, but > >> clearly different (not all the same AOR). Obviously=20 > creates multiple > >> dialogs if/when multiple responses are received. The=20 > proxy can't be > >> the origination point; it's not a UA. All the responses=20 > are going to > >> be forwarded to the UA. The only way around that is B2BUA=20 > behavior. > >> Is that a better, or a worse idea? > >> > >> Gotta think through what this means for Message Sessions. > >> You want the > >> proxy to replicate each message, but you don't really want=20 > to repeat > >> the list of recipients. Does that argue for B2BUA more strongly? > >> > >> With a B2BUA approach you send the message to the exploder. It > >> sends individual messages to recipients, and handles all=20 > the dialogs. > >> That reminds me of a buddy list subscription without the=20 > prearranged > >> buddy list. > >> > >> Brian > >> > >> > -----Original Message----- > >> > From: Mills, Duncan, D, CND Tech Dev, VF UK > >> > [mailto:Duncan.Mills@gb.vodafone.co.uk] > >> > Sent: Tuesday, June 24, 2003 9:42 AM > >> > To: simple@ietf.org > >> > Subject: [Simple] Sending 1 to n MESSAGEs > >> > > >> > > >> > SIMPLE people, > >> > > >> > I've just been thinking about how my e-mail works, and what I > >> > like best about it. It is really easy to type a long message > >> > and then send it to a list of (more than one) people. Better > >> > still, I don't have to have pre-configured that list of > >> > people. I can just type in the addresses in the To: field > >> > and the mail will be sent to each address. > >> > > >> > As far as I know, I can't do this with the SIP MESSAGE > >> > method. Yes, I can create a resource URI in a server and > >> > send one MESSAGE request to that resource-URI, and the server > >> > may fork the MESSAGE to each URI in my pre-configured list. > >> > But if I don't want to have to set up a new list of > >> > recipients each time I send a MESSAGE then I have to send the > >> > same MESSAGE several times. Please correct me if I'm wrong. > >> > > >> > Now... looking at this from a wireless operator perspective, > >> > I immediately see warning signs about my =A36 billion radio > >> > interface ;-) Currently, in GSM, if we want to send an SMS > >> > to more 'n' recipients, we have the same situation- either > >> > create a user group in the network or send the message 'n' > >> > times. However, a SIP MESSAGE request is likely to be about > >> > ten times the size of an SMS. > >> > > >> > Is this a problem? If not, why not? Maybe I'm missing some > >> > background/historical information? > >> > > >> > If it is a problem, might it be possible to extend SIP in > >> > such a way as to state that the request-URI be set to the > >> > address of my SIP proxy server in my home network and then > >> > the To: field be filled with the list of intended recipients, > >> > with the server then being responsible for sending the > >> > MESSAGE to all the intended recipients? > >> > > >> > Any comments/views? > >> > > >> > Best Regards, > >> > > >> > Duncan > >> > > >> > > >> > Duncan Mills > >> > Senior Engineer > >> > Network Standards & Technical Audit > >> > Technology Development (Network Systems) > >> > Vodafone (UK) Ltd > >> > Tel: +44 (0)1635 676074 > >> > Mob: +44 7867 900955 > >> > Fax: +44 (0)1635 234445 > >> > mailto:duncan.mills@vf.vodafone.co.uk > >> > > >> > > >> > > >> > _______________________________________________ > >> > Simple mailing list > >> > Simple@ietf.org > >> > https://www1.ietf.org/mailman/listinfo/simple > >> > > >> > >> _______________________________________________ > >> Simple mailing list > >> Simple@ietf.org > >> https://www1.ietf.org/mailman/listinfo/simple > >> > > > >_______________________________________________ > >Simple mailing list > >Simple@ietf.org > >https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Jun 24 11:26:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20386 for ; Tue, 24 Jun 2003 11:26:41 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5OFQD228118 for simple-archive@odin.ietf.org; Tue, 24 Jun 2003 11:26:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UpgT-0007JO-EX for simple-web-archive@optimus.ietf.org; Tue, 24 Jun 2003 11:26:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20336; Tue, 24 Jun 2003 11:26:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UpgR-0003gs-00; Tue, 24 Jun 2003 11:26:11 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19UpgL-0003gp-00; Tue, 24 Jun 2003 11:26:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UpgI-0007I1-Bf; Tue, 24 Jun 2003 11:26:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UpfX-0007HF-IC for simple@optimus.ietf.org; Tue, 24 Jun 2003 11:25:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20303 for ; Tue, 24 Jun 2003 11:25:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UpfW-0003gT-00 for simple@ietf.org; Tue, 24 Jun 2003 11:25:14 -0400 Received: from mail1.dynamicsoft.com ([63.113.40.10] helo=mail2.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19UpfK-0003gB-00 for simple@ietf.org; Tue, 24 Jun 2003 11:25:03 -0400 Received: from DYN-EXCH-01.dynamicsoft.com (dyn-exch-001b [63.113.44.8]) by mail2.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h5OFLt9O007364; Tue, 24 Jun 2003 11:21:55 -0400 (EDT) Received: by DYN-EXCH-01.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Tue, 24 Jun 2003 11:24:18 -0400 Message-ID: <786B3DFD70C41E49BFA5DE59F611862803E319@DYN-EXCH-01.dynamicsoft.com> From: Chris Harris To: "'Chris Boulton'" , "Mills, Duncan, D, CND Tech Dev, VF UK" , Chris Harris , "Rosen, Brian" , simple@ietf.org Subject: RE: [Simple] Sending 1 to n MESSAGEs MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mail2.dynamicsoft.com id h5OFLt9O007364 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, 24 Jun 2003 11:24:11 -0400 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Chris B, I would assume that such a header would use comma separated values to sav= e space e.g. X-Recipient: sip:charris@dynamicsoft.com, sip:cboulton@ubiquity.net Chris H > -----Original Message----- > From: Chris Boulton [mailto:cboulton@ubiquity.net] > Sent: Tuesday, June 24, 2003 11:20 AM > To: Mills, Duncan, D, CND Tech Dev, VF UK; Chris Harris; Rosen, Brian; > simple@ietf.org > Subject: RE: [Simple] Sending 1 to n MESSAGEs >=20 >=20 > Chris, >=20 > Wouldn't this be an expensive way of including a list=20 > of X-recipients (message size)? >=20 > Chris B. >=20 >=20 > >-----Original Message----- > >From: Mills, Duncan, D, CND Tech Dev, VF UK > >[mailto:Duncan.Mills@gb.vodafone.co.uk] > >Sent: 24 June 2003 16:13 > >To: Chris Harris; Rosen, Brian; simple@ietf.org > >Subject: RE: [Simple] Sending 1 to n MESSAGEs > > > >Chris, > > > >Thanks for your thoughts. I agree, that a custome header of=20 > some sort > >would help. I'd probably want to standardise that header with an RFC > >though- what are thoughts on this? > > > >Duncan > > > >-----Original Message----- > >From: Chris Harris [mailto:CHarris@dynamicsoft.com] > >Sent: 24 June 2003 16:06 > >To: Mills, Duncan, D, CND Tech Dev, VF UK; Rosen, Brian;=20 > simple@ietf.org > >Subject: RE: [Simple] Sending 1 to n MESSAGEs > > > > > >Duncan, > > > >One possibility for this ad-hoc group messaging is to=20 > address the message > >to > >a message exploder application, and to use other custom=20 > headers for the > >list > >of actual recipients (say a list of X-Recipient: headers)=20 > that the exploder > >understands. Once the exploder accepts the message it would=20 > presumably send > >a 202 response to the sender and be responsible for the=20 > delivery of the > >messages to the recipients. > > > >Regards, > >Chris Harris > > > >> -----Original Message----- > >> From: Mills, Duncan, D, CND Tech Dev, VF UK > >> [mailto:Duncan.Mills@gb.vodafone.co.uk] > >> Sent: Tuesday, June 24, 2003 10:55 AM > >> To: Rosen, Brian; simple@ietf.org > >> Subject: RE: [Simple] Sending 1 to n MESSAGEs > >> > >> > >> Dear CLEVER people (of the SIMPLE WG) ;-) > >> > >> Brian- yes, my thought was to allow a B2BUA function to fork > >> the MESSAGE request. This way, the user doesn't have to > >> pre-configure the recipient list, but perhaps they do have to > >> pre-configure the address of their MESSAGING server (the > >> B2BUA). When I say pre-configure, I'm sure there are more > >> dynamic ways to get the B2BUA address to the UA. > >> > >> I must admit, I am coming at this from the 3GPP perspective > >> and so a SIP AS (acting in B2BUA mode) would seem to do the > >> trick. However, it would require- I believe- some=20 > extensions to SIP. > >> > >> However, 3GPP radio interface constraints aside, I think it > >> would be a shame to design SIP messaging without the ability > >> to fork a message to n recipients, in the same way you can > >> with e-mail. > >> > >> Thanks for your initial thoughts- I'd be interested in > >> progressing this issue, if you and others feel it worthwhile... > >> > >> Cheers, > >> > >> Duncan > >> > >> > >> -----Original Message----- > >> From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > >> Sent: 24 June 2003 15:38 > >> To: Mills, Duncan, D, CND Tech Dev, VF UK; simple@ietf.org > >> Subject: RE: [Simple] Sending 1 to n MESSAGEs > >> > >> > >> Was the salutation to your message a comment on the quality of > >> the discourse on this list? ;) > >> > >> Good thought. Interacts with conferencing (mass invite to a > >> conference). > >> You don't want to have to have a complex interaction prior=20 > to sending > >> a list of recipients. Smells like a kind of forking behavior, but > >> clearly different (not all the same AOR). Obviously=20 > creates multiple > >> dialogs if/when multiple responses are received. The=20 > proxy can't be > >> the origination point; it's not a UA. All the responses=20 > are going to > >> be forwarded to the UA. The only way around that is B2BUA=20 > behavior. > >> Is that a better, or a worse idea? > >> > >> Gotta think through what this means for Message Sessions. > >> You want the > >> proxy to replicate each message, but you don't really want=20 > to repeat > >> the list of recipients. Does that argue for B2BUA more strongly? > >> > >> With a B2BUA approach you send the message to the exploder. It > >> sends individual messages to recipients, and handles all=20 > the dialogs. > >> That reminds me of a buddy list subscription without the=20 > prearranged > >> buddy list. > >> > >> Brian > >> > >> > -----Original Message----- > >> > From: Mills, Duncan, D, CND Tech Dev, VF UK > >> > [mailto:Duncan.Mills@gb.vodafone.co.uk] > >> > Sent: Tuesday, June 24, 2003 9:42 AM > >> > To: simple@ietf.org > >> > Subject: [Simple] Sending 1 to n MESSAGEs > >> > > >> > > >> > SIMPLE people, > >> > > >> > I've just been thinking about how my e-mail works, and what I > >> > like best about it. It is really easy to type a long message > >> > and then send it to a list of (more than one) people. Better > >> > still, I don't have to have pre-configured that list of > >> > people. I can just type in the addresses in the To: field > >> > and the mail will be sent to each address. > >> > > >> > As far as I know, I can't do this with the SIP MESSAGE > >> > method. Yes, I can create a resource URI in a server and > >> > send one MESSAGE request to that resource-URI, and the server > >> > may fork the MESSAGE to each URI in my pre-configured list. > >> > But if I don't want to have to set up a new list of > >> > recipients each time I send a MESSAGE then I have to send the > >> > same MESSAGE several times. Please correct me if I'm wrong. > >> > > >> > Now... looking at this from a wireless operator perspective, > >> > I immediately see warning signs about my =A36 billion radio > >> > interface ;-) Currently, in GSM, if we want to send an SMS > >> > to more 'n' recipients, we have the same situation- either > >> > create a user group in the network or send the message 'n' > >> > times. However, a SIP MESSAGE request is likely to be about > >> > ten times the size of an SMS. > >> > > >> > Is this a problem? If not, why not? Maybe I'm missing some > >> > background/historical information? > >> > > >> > If it is a problem, might it be possible to extend SIP in > >> > such a way as to state that the request-URI be set to the > >> > address of my SIP proxy server in my home network and then > >> > the To: field be filled with the list of intended recipients, > >> > with the server then being responsible for sending the > >> > MESSAGE to all the intended recipients? > >> > > >> > Any comments/views? > >> > > >> > Best Regards, > >> > > >> > Duncan > >> > > >> > > >> > Duncan Mills > >> > Senior Engineer > >> > Network Standards & Technical Audit > >> > Technology Development (Network Systems) > >> > Vodafone (UK) Ltd > >> > Tel: +44 (0)1635 676074 > >> > Mob: +44 7867 900955 > >> > Fax: +44 (0)1635 234445 > >> > mailto:duncan.mills@vf.vodafone.co.uk > >> > > >> > > >> > > >> > _______________________________________________ > >> > Simple mailing list > >> > Simple@ietf.org > >> > https://www1.ietf.org/mailman/listinfo/simple > >> > > >> > >> _______________________________________________ > >> Simple mailing list > >> Simple@ietf.org > >> https://www1.ietf.org/mailman/listinfo/simple > >> > > > >_______________________________________________ > >Simple mailing list > >Simple@ietf.org > >https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Jun 24 11:29:07 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 LAA20452; Tue, 24 Jun 2003 11:29:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UpjJ-0003iA-00; Tue, 24 Jun 2003 11:29:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19UpjD-0003i7-00; Tue, 24 Jun 2003 11: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 19UpjA-0007NA-Oa; Tue, 24 Jun 2003 11: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 19UpiG-0007Mg-QN for simple@optimus.ietf.org; Tue, 24 Jun 2003 11:28: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 LAA20439 for ; Tue, 24 Jun 2003 11:28:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UpiF-0003i0-00 for simple@ietf.org; Tue, 24 Jun 2003 11:28:03 -0400 Received: from igate2.vodafone.co.uk ([194.62.232.66]) by ietf-mx with esmtp (Exim 4.12) id 19Upi4-0003ho-00 for simple@ietf.org; Tue, 24 Jun 2003 11:27:52 -0400 Received: by igate2.vodafone.co.uk; (8.8.8/1.3/10May95) id QAA12535; Tue, 24 Jun 2003 16:27:15 +0100 (BST) Received: from ukwmxc02.vf-uk.internal.vodafone.com (ukwmxc02 [10.33.126.170]) by mailguard1 (4.6.1.123) with ESMTP id ; Tue, 24 Jun 2003 16:26:49 +0100 Received: from ukwmxc04.vf-uk.internal.vodafone.com ([10.33.126.173]) by ukwmxc02.vf-uk.internal.vodafone.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 24 Jun 2003 16:26:34 +0100 Received: from ukwmxm02.vf-uk.internal.vodafone.com ([10.33.126.242]) by ukwmxc04.vf-uk.internal.vodafone.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 24 Jun 2003 16:26:34 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message Subject: RE: [Simple] Sending 1 to n MESSAGEs Message-ID: Thread-Topic: [Simple] Sending 1 to n MESSAGEs Thread-Index: AcM6Yk7hUE6eq5AARvGA969Z94cyvgAAKZjgAAA+L1AAACkF4A== From: "Mills, Duncan, D, CND Tech Dev, VF UK" To: "Chris Boulton" , X-OriginalArrivalTime: 24 Jun 2003 15:26:34.0481 (UTC) FILETIME=[FEF05610:01C33A64] MIME-Version: 1.0 (Generated by Clearswift ES version 4.6.1.122) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 24 Jun 2003 16:26:34 +0100 Content-Transfer-Encoding: quoted-printable Chris, For the sake of a few extra addresses in the MESSAGE headers, for a 1000 = byte MESSAGE request destined for 8 recipients, we can go from (for = example) 8 * 1000 bytes to 1 * 1800 bytes (and that assumes each = recipient address requires 100 bytes). I know which I'd prefer... Duncan -----Original Message----- From: Chris Boulton [mailto:cboulton@ubiquity.net] Sent: 24 June 2003 16:20 To: Mills, Duncan, D, CND Tech Dev, VF UK; Chris Harris; Rosen, Brian; simple@ietf.org Subject: RE: [Simple] Sending 1 to n MESSAGEs Chris, Wouldn't this be an expensive way of including a list of X-recipients = (message size)? Chris B. >-----Original Message----- >From: Mills, Duncan, D, CND Tech Dev, VF UK >[mailto:Duncan.Mills@gb.vodafone.co.uk] >Sent: 24 June 2003 16:13 >To: Chris Harris; Rosen, Brian; simple@ietf.org >Subject: RE: [Simple] Sending 1 to n MESSAGEs > >Chris, > >Thanks for your thoughts. I agree, that a custome header of some sort >would help. I'd probably want to standardise that header with an RFC >though- what are thoughts on this? > >Duncan > >-----Original Message----- >From: Chris Harris [mailto:CHarris@dynamicsoft.com] >Sent: 24 June 2003 16:06 >To: Mills, Duncan, D, CND Tech Dev, VF UK; Rosen, Brian; = simple@ietf.org >Subject: RE: [Simple] Sending 1 to n MESSAGEs > > >Duncan, > >One possibility for this ad-hoc group messaging is to address the = message >to >a message exploder application, and to use other custom headers for the >list >of actual recipients (say a list of X-Recipient: headers) that the = exploder >understands. Once the exploder accepts the message it would presumably = send >a 202 response to the sender and be responsible for the delivery of the >messages to the recipients. > >Regards, >Chris Harris > >> -----Original Message----- >> From: Mills, Duncan, D, CND Tech Dev, VF UK >> [mailto:Duncan.Mills@gb.vodafone.co.uk] >> Sent: Tuesday, June 24, 2003 10:55 AM >> To: Rosen, Brian; simple@ietf.org >> Subject: RE: [Simple] Sending 1 to n MESSAGEs >> >> >> Dear CLEVER people (of the SIMPLE WG) ;-) >> >> Brian- yes, my thought was to allow a B2BUA function to fork >> the MESSAGE request. This way, the user doesn't have to >> pre-configure the recipient list, but perhaps they do have to >> pre-configure the address of their MESSAGING server (the >> B2BUA). When I say pre-configure, I'm sure there are more >> dynamic ways to get the B2BUA address to the UA. >> >> I must admit, I am coming at this from the 3GPP perspective >> and so a SIP AS (acting in B2BUA mode) would seem to do the >> trick. However, it would require- I believe- some extensions to SIP. >> >> However, 3GPP radio interface constraints aside, I think it >> would be a shame to design SIP messaging without the ability >> to fork a message to n recipients, in the same way you can >> with e-mail. >> >> Thanks for your initial thoughts- I'd be interested in >> progressing this issue, if you and others feel it worthwhile... >> >> Cheers, >> >> Duncan >> >> >> -----Original Message----- >> From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] >> Sent: 24 June 2003 15:38 >> To: Mills, Duncan, D, CND Tech Dev, VF UK; simple@ietf.org >> Subject: RE: [Simple] Sending 1 to n MESSAGEs >> >> >> Was the salutation to your message a comment on the quality of >> the discourse on this list? ;) >> >> Good thought. Interacts with conferencing (mass invite to a >> conference). >> You don't want to have to have a complex interaction prior to sending >> a list of recipients. Smells like a kind of forking behavior, but >> clearly different (not all the same AOR). Obviously creates multiple >> dialogs if/when multiple responses are received. The proxy can't be >> the origination point; it's not a UA. All the responses are going to >> be forwarded to the UA. The only way around that is B2BUA behavior. >> Is that a better, or a worse idea? >> >> Gotta think through what this means for Message Sessions. >> You want the >> proxy to replicate each message, but you don't really want to repeat >> the list of recipients. Does that argue for B2BUA more strongly? >> >> With a B2BUA approach you send the message to the exploder. It >> sends individual messages to recipients, and handles all the dialogs. >> That reminds me of a buddy list subscription without the prearranged >> buddy list. >> >> Brian >> >> > -----Original Message----- >> > From: Mills, Duncan, D, CND Tech Dev, VF UK >> > [mailto:Duncan.Mills@gb.vodafone.co.uk] >> > Sent: Tuesday, June 24, 2003 9:42 AM >> > To: simple@ietf.org >> > Subject: [Simple] Sending 1 to n MESSAGEs >> > >> > >> > SIMPLE people, >> > >> > I've just been thinking about how my e-mail works, and what I >> > like best about it. It is really easy to type a long message >> > and then send it to a list of (more than one) people. Better >> > still, I don't have to have pre-configured that list of >> > people. I can just type in the addresses in the To: field >> > and the mail will be sent to each address. >> > >> > As far as I know, I can't do this with the SIP MESSAGE >> > method. Yes, I can create a resource URI in a server and >> > send one MESSAGE request to that resource-URI, and the server >> > may fork the MESSAGE to each URI in my pre-configured list. >> > But if I don't want to have to set up a new list of >> > recipients each time I send a MESSAGE then I have to send the >> > same MESSAGE several times. Please correct me if I'm wrong. >> > >> > Now... looking at this from a wireless operator perspective, >> > I immediately see warning signs about my =A36 billion radio >> > interface ;-) Currently, in GSM, if we want to send an SMS >> > to more 'n' recipients, we have the same situation- either >> > create a user group in the network or send the message 'n' >> > times. However, a SIP MESSAGE request is likely to be about >> > ten times the size of an SMS. >> > >> > Is this a problem? If not, why not? Maybe I'm missing some >> > background/historical information? >> > >> > If it is a problem, might it be possible to extend SIP in >> > such a way as to state that the request-URI be set to the >> > address of my SIP proxy server in my home network and then >> > the To: field be filled with the list of intended recipients, >> > with the server then being responsible for sending the >> > MESSAGE to all the intended recipients? >> > >> > Any comments/views? >> > >> > Best Regards, >> > >> > Duncan >> > >> > >> > Duncan Mills >> > Senior Engineer >> > Network Standards & Technical Audit >> > Technology Development (Network Systems) >> > Vodafone (UK) Ltd >> > Tel: +44 (0)1635 676074 >> > Mob: +44 7867 900955 >> > Fax: +44 (0)1635 234445 >> > mailto:duncan.mills@vf.vodafone.co.uk >> > >> > >> > >> > _______________________________________________ >> > Simple mailing list >> > Simple@ietf.org >> > https://www1.ietf.org/mailman/listinfo/simple >> > >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple >> > >_______________________________________________ >Simple mailing list >Simple@ietf.org >https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Jun 24 11:29:53 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20499 for ; Tue, 24 Jun 2003 11:29:53 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5OFTPD28543 for simple-archive@odin.ietf.org; Tue, 24 Jun 2003 11:29:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UpjZ-0007QI-CO for simple-web-archive@optimus.ietf.org; Tue, 24 Jun 2003 11:29:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20452; Tue, 24 Jun 2003 11:29:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UpjJ-0003iA-00; Tue, 24 Jun 2003 11:29:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19UpjD-0003i7-00; Tue, 24 Jun 2003 11: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 19UpjA-0007NA-Oa; Tue, 24 Jun 2003 11: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 19UpiG-0007Mg-QN for simple@optimus.ietf.org; Tue, 24 Jun 2003 11:28: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 LAA20439 for ; Tue, 24 Jun 2003 11:28:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UpiF-0003i0-00 for simple@ietf.org; Tue, 24 Jun 2003 11:28:03 -0400 Received: from igate2.vodafone.co.uk ([194.62.232.66]) by ietf-mx with esmtp (Exim 4.12) id 19Upi4-0003ho-00 for simple@ietf.org; Tue, 24 Jun 2003 11:27:52 -0400 Received: by igate2.vodafone.co.uk; (8.8.8/1.3/10May95) id QAA12535; Tue, 24 Jun 2003 16:27:15 +0100 (BST) Received: from ukwmxc02.vf-uk.internal.vodafone.com (ukwmxc02 [10.33.126.170]) by mailguard1 (4.6.1.123) with ESMTP id ; Tue, 24 Jun 2003 16:26:49 +0100 Received: from ukwmxc04.vf-uk.internal.vodafone.com ([10.33.126.173]) by ukwmxc02.vf-uk.internal.vodafone.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 24 Jun 2003 16:26:34 +0100 Received: from ukwmxm02.vf-uk.internal.vodafone.com ([10.33.126.242]) by ukwmxc04.vf-uk.internal.vodafone.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 24 Jun 2003 16:26:34 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message Subject: RE: [Simple] Sending 1 to n MESSAGEs Message-ID: Thread-Topic: [Simple] Sending 1 to n MESSAGEs Thread-Index: AcM6Yk7hUE6eq5AARvGA969Z94cyvgAAKZjgAAA+L1AAACkF4A== From: "Mills, Duncan, D, CND Tech Dev, VF UK" To: "Chris Boulton" , X-OriginalArrivalTime: 24 Jun 2003 15:26:34.0481 (UTC) FILETIME=[FEF05610:01C33A64] MIME-Version: 1.0 (Generated by Clearswift ES version 4.6.1.122) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 24 Jun 2003 16:26:34 +0100 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Chris, For the sake of a few extra addresses in the MESSAGE headers, for a 1000 = byte MESSAGE request destined for 8 recipients, we can go from (for = example) 8 * 1000 bytes to 1 * 1800 bytes (and that assumes each = recipient address requires 100 bytes). I know which I'd prefer... Duncan -----Original Message----- From: Chris Boulton [mailto:cboulton@ubiquity.net] Sent: 24 June 2003 16:20 To: Mills, Duncan, D, CND Tech Dev, VF UK; Chris Harris; Rosen, Brian; simple@ietf.org Subject: RE: [Simple] Sending 1 to n MESSAGEs Chris, Wouldn't this be an expensive way of including a list of X-recipients = (message size)? Chris B. >-----Original Message----- >From: Mills, Duncan, D, CND Tech Dev, VF UK >[mailto:Duncan.Mills@gb.vodafone.co.uk] >Sent: 24 June 2003 16:13 >To: Chris Harris; Rosen, Brian; simple@ietf.org >Subject: RE: [Simple] Sending 1 to n MESSAGEs > >Chris, > >Thanks for your thoughts. I agree, that a custome header of some sort >would help. I'd probably want to standardise that header with an RFC >though- what are thoughts on this? > >Duncan > >-----Original Message----- >From: Chris Harris [mailto:CHarris@dynamicsoft.com] >Sent: 24 June 2003 16:06 >To: Mills, Duncan, D, CND Tech Dev, VF UK; Rosen, Brian; = simple@ietf.org >Subject: RE: [Simple] Sending 1 to n MESSAGEs > > >Duncan, > >One possibility for this ad-hoc group messaging is to address the = message >to >a message exploder application, and to use other custom headers for the >list >of actual recipients (say a list of X-Recipient: headers) that the = exploder >understands. Once the exploder accepts the message it would presumably = send >a 202 response to the sender and be responsible for the delivery of the >messages to the recipients. > >Regards, >Chris Harris > >> -----Original Message----- >> From: Mills, Duncan, D, CND Tech Dev, VF UK >> [mailto:Duncan.Mills@gb.vodafone.co.uk] >> Sent: Tuesday, June 24, 2003 10:55 AM >> To: Rosen, Brian; simple@ietf.org >> Subject: RE: [Simple] Sending 1 to n MESSAGEs >> >> >> Dear CLEVER people (of the SIMPLE WG) ;-) >> >> Brian- yes, my thought was to allow a B2BUA function to fork >> the MESSAGE request. This way, the user doesn't have to >> pre-configure the recipient list, but perhaps they do have to >> pre-configure the address of their MESSAGING server (the >> B2BUA). When I say pre-configure, I'm sure there are more >> dynamic ways to get the B2BUA address to the UA. >> >> I must admit, I am coming at this from the 3GPP perspective >> and so a SIP AS (acting in B2BUA mode) would seem to do the >> trick. However, it would require- I believe- some extensions to SIP. >> >> However, 3GPP radio interface constraints aside, I think it >> would be a shame to design SIP messaging without the ability >> to fork a message to n recipients, in the same way you can >> with e-mail. >> >> Thanks for your initial thoughts- I'd be interested in >> progressing this issue, if you and others feel it worthwhile... >> >> Cheers, >> >> Duncan >> >> >> -----Original Message----- >> From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] >> Sent: 24 June 2003 15:38 >> To: Mills, Duncan, D, CND Tech Dev, VF UK; simple@ietf.org >> Subject: RE: [Simple] Sending 1 to n MESSAGEs >> >> >> Was the salutation to your message a comment on the quality of >> the discourse on this list? ;) >> >> Good thought. Interacts with conferencing (mass invite to a >> conference). >> You don't want to have to have a complex interaction prior to sending >> a list of recipients. Smells like a kind of forking behavior, but >> clearly different (not all the same AOR). Obviously creates multiple >> dialogs if/when multiple responses are received. The proxy can't be >> the origination point; it's not a UA. All the responses are going to >> be forwarded to the UA. The only way around that is B2BUA behavior. >> Is that a better, or a worse idea? >> >> Gotta think through what this means for Message Sessions. >> You want the >> proxy to replicate each message, but you don't really want to repeat >> the list of recipients. Does that argue for B2BUA more strongly? >> >> With a B2BUA approach you send the message to the exploder. It >> sends individual messages to recipients, and handles all the dialogs. >> That reminds me of a buddy list subscription without the prearranged >> buddy list. >> >> Brian >> >> > -----Original Message----- >> > From: Mills, Duncan, D, CND Tech Dev, VF UK >> > [mailto:Duncan.Mills@gb.vodafone.co.uk] >> > Sent: Tuesday, June 24, 2003 9:42 AM >> > To: simple@ietf.org >> > Subject: [Simple] Sending 1 to n MESSAGEs >> > >> > >> > SIMPLE people, >> > >> > I've just been thinking about how my e-mail works, and what I >> > like best about it. It is really easy to type a long message >> > and then send it to a list of (more than one) people. Better >> > still, I don't have to have pre-configured that list of >> > people. I can just type in the addresses in the To: field >> > and the mail will be sent to each address. >> > >> > As far as I know, I can't do this with the SIP MESSAGE >> > method. Yes, I can create a resource URI in a server and >> > send one MESSAGE request to that resource-URI, and the server >> > may fork the MESSAGE to each URI in my pre-configured list. >> > But if I don't want to have to set up a new list of >> > recipients each time I send a MESSAGE then I have to send the >> > same MESSAGE several times. Please correct me if I'm wrong. >> > >> > Now... looking at this from a wireless operator perspective, >> > I immediately see warning signs about my =A36 billion radio >> > interface ;-) Currently, in GSM, if we want to send an SMS >> > to more 'n' recipients, we have the same situation- either >> > create a user group in the network or send the message 'n' >> > times. However, a SIP MESSAGE request is likely to be about >> > ten times the size of an SMS. >> > >> > Is this a problem? If not, why not? Maybe I'm missing some >> > background/historical information? >> > >> > If it is a problem, might it be possible to extend SIP in >> > such a way as to state that the request-URI be set to the >> > address of my SIP proxy server in my home network and then >> > the To: field be filled with the list of intended recipients, >> > with the server then being responsible for sending the >> > MESSAGE to all the intended recipients? >> > >> > Any comments/views? >> > >> > Best Regards, >> > >> > Duncan >> > >> > >> > Duncan Mills >> > Senior Engineer >> > Network Standards & Technical Audit >> > Technology Development (Network Systems) >> > Vodafone (UK) Ltd >> > Tel: +44 (0)1635 676074 >> > Mob: +44 7867 900955 >> > Fax: +44 (0)1635 234445 >> > mailto:duncan.mills@vf.vodafone.co.uk >> > >> > >> > >> > _______________________________________________ >> > Simple mailing list >> > Simple@ietf.org >> > https://www1.ietf.org/mailman/listinfo/simple >> > >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple >> > >_______________________________________________ >Simple mailing list >Simple@ietf.org >https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Jun 24 11:40:08 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 LAA20741; Tue, 24 Jun 2003 11:40:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Uptx-0003lF-00; Tue, 24 Jun 2003 11:40:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Upts-0003lC-00; Tue, 24 Jun 2003 11:40:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Uptp-0007wb-57; Tue, 24 Jun 2003 11:40:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Upti-0007vu-CY for simple@optimus.ietf.org; Tue, 24 Jun 2003 11:39: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 LAA20714 for ; Tue, 24 Jun 2003 11:39:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Upsl-0003kr-00 for simple@ietf.org; Tue, 24 Jun 2003 11:38:55 -0400 Received: from news.ubiquity.net ([194.202.146.92] helo=gbnewp0186s1.eu.ubiquity.net) by ietf-mx with smtp (Exim 4.12) id 19UpsZ-0003km-00 for simple@ietf.org; Tue, 24 Jun 2003 11:38:44 -0400 Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; Tue, 24 Jun 2003 16:41:21 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Sending 1 to n MESSAGEs Message-ID: <45730E094814E44488F789C1CDED27AE0219B003@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [Simple] Sending 1 to n MESSAGEs Thread-Index: AcM6Yk7hUE6eq5AARvGA969Z94cyvgAAKZjgAAA+L1AAACkF4AAAWgWA From: "Chris Boulton" To: "Mills, Duncan, D, CND Tech Dev, VF UK" , 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, 24 Jun 2003 16:38:38 +0100 Content-Transfer-Encoding: quoted-printable Duncan, I totally agree, I'm not saying that the latter is an option. I was = just thinking of scale e.g. you want to 'explode' to say 80 people. I = guess your exploder would be able to group Sip URL's for this purpose = e.g. sip:mailshot@ubiquity.net which has been configured to fork to 80 = contact addresses. Chris. =20 >-----Original Message----- >From: Mills, Duncan, D, CND Tech Dev, VF UK >[mailto:Duncan.Mills@gb.vodafone.co.uk] >Sent: 24 June 2003 16:27 >To: Chris Boulton; simple@ietf.org >Subject: RE: [Simple] Sending 1 to n MESSAGEs > >Chris, > >For the sake of a few extra addresses in the MESSAGE headers, for a = 1000 >byte MESSAGE request destined for 8 recipients, we can go from (for >example) 8 * 1000 bytes to 1 * 1800 bytes (and that assumes each = recipient >address requires 100 bytes). > >I know which I'd prefer... > >Duncan > >-----Original Message----- >From: Chris Boulton [mailto:cboulton@ubiquity.net] >Sent: 24 June 2003 16:20 >To: Mills, Duncan, D, CND Tech Dev, VF UK; Chris Harris; Rosen, Brian; >simple@ietf.org >Subject: RE: [Simple] Sending 1 to n MESSAGEs > > >Chris, > > Wouldn't this be an expensive way of including a list of X-recipients >(message size)? > >Chris B. > > >>-----Original Message----- >>From: Mills, Duncan, D, CND Tech Dev, VF UK >>[mailto:Duncan.Mills@gb.vodafone.co.uk] >>Sent: 24 June 2003 16:13 >>To: Chris Harris; Rosen, Brian; simple@ietf.org >>Subject: RE: [Simple] Sending 1 to n MESSAGEs >> >>Chris, >> >>Thanks for your thoughts. I agree, that a custome header of some sort >>would help. I'd probably want to standardise that header with an RFC >>though- what are thoughts on this? >> >>Duncan >> >>-----Original Message----- >>From: Chris Harris [mailto:CHarris@dynamicsoft.com] >>Sent: 24 June 2003 16:06 >>To: Mills, Duncan, D, CND Tech Dev, VF UK; Rosen, Brian; = simple@ietf.org >>Subject: RE: [Simple] Sending 1 to n MESSAGEs >> >> >>Duncan, >> >>One possibility for this ad-hoc group messaging is to address the = message >>to >>a message exploder application, and to use other custom headers for = the >>list >>of actual recipients (say a list of X-Recipient: headers) that the >exploder >>understands. Once the exploder accepts the message it would presumably >send >>a 202 response to the sender and be responsible for the delivery of = the >>messages to the recipients. >> >>Regards, >>Chris Harris >> >>> -----Original Message----- >>> From: Mills, Duncan, D, CND Tech Dev, VF UK >>> [mailto:Duncan.Mills@gb.vodafone.co.uk] >>> Sent: Tuesday, June 24, 2003 10:55 AM >>> To: Rosen, Brian; simple@ietf.org >>> Subject: RE: [Simple] Sending 1 to n MESSAGEs >>> >>> >>> Dear CLEVER people (of the SIMPLE WG) ;-) >>> >>> Brian- yes, my thought was to allow a B2BUA function to fork >>> the MESSAGE request. This way, the user doesn't have to >>> pre-configure the recipient list, but perhaps they do have to >>> pre-configure the address of their MESSAGING server (the >>> B2BUA). When I say pre-configure, I'm sure there are more >>> dynamic ways to get the B2BUA address to the UA. >>> >>> I must admit, I am coming at this from the 3GPP perspective >>> and so a SIP AS (acting in B2BUA mode) would seem to do the >>> trick. However, it would require- I believe- some extensions to = SIP. >>> >>> However, 3GPP radio interface constraints aside, I think it >>> would be a shame to design SIP messaging without the ability >>> to fork a message to n recipients, in the same way you can >>> with e-mail. >>> >>> Thanks for your initial thoughts- I'd be interested in >>> progressing this issue, if you and others feel it worthwhile... >>> >>> Cheers, >>> >>> Duncan >>> >>> >>> -----Original Message----- >>> From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] >>> Sent: 24 June 2003 15:38 >>> To: Mills, Duncan, D, CND Tech Dev, VF UK; simple@ietf.org >>> Subject: RE: [Simple] Sending 1 to n MESSAGEs >>> >>> >>> Was the salutation to your message a comment on the quality of >>> the discourse on this list? ;) >>> >>> Good thought. Interacts with conferencing (mass invite to a >>> conference). >>> You don't want to have to have a complex interaction prior to = sending >>> a list of recipients. Smells like a kind of forking behavior, but >>> clearly different (not all the same AOR). Obviously creates = multiple >>> dialogs if/when multiple responses are received. The proxy can't be >>> the origination point; it's not a UA. All the responses are going = to >>> be forwarded to the UA. The only way around that is B2BUA behavior. >>> Is that a better, or a worse idea? >>> >>> Gotta think through what this means for Message Sessions. >>> You want the >>> proxy to replicate each message, but you don't really want to repeat >>> the list of recipients. Does that argue for B2BUA more strongly? >>> >>> With a B2BUA approach you send the message to the exploder. It >>> sends individual messages to recipients, and handles all the = dialogs. >>> That reminds me of a buddy list subscription without the prearranged >>> buddy list. >>> >>> Brian >>> >>> > -----Original Message----- >>> > From: Mills, Duncan, D, CND Tech Dev, VF UK >>> > [mailto:Duncan.Mills@gb.vodafone.co.uk] >>> > Sent: Tuesday, June 24, 2003 9:42 AM >>> > To: simple@ietf.org >>> > Subject: [Simple] Sending 1 to n MESSAGEs >>> > >>> > >>> > SIMPLE people, >>> > >>> > I've just been thinking about how my e-mail works, and what I >>> > like best about it. It is really easy to type a long message >>> > and then send it to a list of (more than one) people. Better >>> > still, I don't have to have pre-configured that list of >>> > people. I can just type in the addresses in the To: field >>> > and the mail will be sent to each address. >>> > >>> > As far as I know, I can't do this with the SIP MESSAGE >>> > method. Yes, I can create a resource URI in a server and >>> > send one MESSAGE request to that resource-URI, and the server >>> > may fork the MESSAGE to each URI in my pre-configured list. >>> > But if I don't want to have to set up a new list of >>> > recipients each time I send a MESSAGE then I have to send the >>> > same MESSAGE several times. Please correct me if I'm wrong. >>> > >>> > Now... looking at this from a wireless operator perspective, >>> > I immediately see warning signs about my =A36 billion radio >>> > interface ;-) Currently, in GSM, if we want to send an SMS >>> > to more 'n' recipients, we have the same situation- either >>> > create a user group in the network or send the message 'n' >>> > times. However, a SIP MESSAGE request is likely to be about >>> > ten times the size of an SMS. >>> > >>> > Is this a problem? If not, why not? Maybe I'm missing some >>> > background/historical information? >>> > >>> > If it is a problem, might it be possible to extend SIP in >>> > such a way as to state that the request-URI be set to the >>> > address of my SIP proxy server in my home network and then >>> > the To: field be filled with the list of intended recipients, >>> > with the server then being responsible for sending the >>> > MESSAGE to all the intended recipients? >>> > >>> > Any comments/views? >>> > >>> > Best Regards, >>> > >>> > Duncan >>> > >>> > >>> > Duncan Mills >>> > Senior Engineer >>> > Network Standards & Technical Audit >>> > Technology Development (Network Systems) >>> > Vodafone (UK) Ltd >>> > Tel: +44 (0)1635 676074 >>> > Mob: +44 7867 900955 >>> > Fax: +44 (0)1635 234445 >>> > mailto:duncan.mills@vf.vodafone.co.uk >>> > >>> > >>> > >>> > _______________________________________________ >>> > Simple mailing list >>> > Simple@ietf.org >>> > https://www1.ietf.org/mailman/listinfo/simple >>> > >>> >>> _______________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> https://www1.ietf.org/mailman/listinfo/simple >>> >> >>_______________________________________________ >>Simple mailing list >>Simple@ietf.org >>https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Jun 24 11:40:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20763 for ; Tue, 24 Jun 2003 11:40:39 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5OFeBN30719 for simple-archive@odin.ietf.org; Tue, 24 Jun 2003 11:40:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Upty-0007yK-Vp for simple-web-archive@optimus.ietf.org; Tue, 24 Jun 2003 11:40: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 LAA20741; Tue, 24 Jun 2003 11:40:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Uptx-0003lF-00; Tue, 24 Jun 2003 11:40:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Upts-0003lC-00; Tue, 24 Jun 2003 11:40:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Uptp-0007wb-57; Tue, 24 Jun 2003 11:40:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Upti-0007vu-CY for simple@optimus.ietf.org; Tue, 24 Jun 2003 11:39: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 LAA20714 for ; Tue, 24 Jun 2003 11:39:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Upsl-0003kr-00 for simple@ietf.org; Tue, 24 Jun 2003 11:38:55 -0400 Received: from news.ubiquity.net ([194.202.146.92] helo=gbnewp0186s1.eu.ubiquity.net) by ietf-mx with smtp (Exim 4.12) id 19UpsZ-0003km-00 for simple@ietf.org; Tue, 24 Jun 2003 11:38:44 -0400 Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; Tue, 24 Jun 2003 16:41:21 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Sending 1 to n MESSAGEs Message-ID: <45730E094814E44488F789C1CDED27AE0219B003@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [Simple] Sending 1 to n MESSAGEs Thread-Index: AcM6Yk7hUE6eq5AARvGA969Z94cyvgAAKZjgAAA+L1AAACkF4AAAWgWA From: "Chris Boulton" To: "Mills, Duncan, D, CND Tech Dev, VF UK" , 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, 24 Jun 2003 16:38:38 +0100 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Duncan, I totally agree, I'm not saying that the latter is an option. I was = just thinking of scale e.g. you want to 'explode' to say 80 people. I = guess your exploder would be able to group Sip URL's for this purpose = e.g. sip:mailshot@ubiquity.net which has been configured to fork to 80 = contact addresses. Chris. =20 >-----Original Message----- >From: Mills, Duncan, D, CND Tech Dev, VF UK >[mailto:Duncan.Mills@gb.vodafone.co.uk] >Sent: 24 June 2003 16:27 >To: Chris Boulton; simple@ietf.org >Subject: RE: [Simple] Sending 1 to n MESSAGEs > >Chris, > >For the sake of a few extra addresses in the MESSAGE headers, for a = 1000 >byte MESSAGE request destined for 8 recipients, we can go from (for >example) 8 * 1000 bytes to 1 * 1800 bytes (and that assumes each = recipient >address requires 100 bytes). > >I know which I'd prefer... > >Duncan > >-----Original Message----- >From: Chris Boulton [mailto:cboulton@ubiquity.net] >Sent: 24 June 2003 16:20 >To: Mills, Duncan, D, CND Tech Dev, VF UK; Chris Harris; Rosen, Brian; >simple@ietf.org >Subject: RE: [Simple] Sending 1 to n MESSAGEs > > >Chris, > > Wouldn't this be an expensive way of including a list of X-recipients >(message size)? > >Chris B. > > >>-----Original Message----- >>From: Mills, Duncan, D, CND Tech Dev, VF UK >>[mailto:Duncan.Mills@gb.vodafone.co.uk] >>Sent: 24 June 2003 16:13 >>To: Chris Harris; Rosen, Brian; simple@ietf.org >>Subject: RE: [Simple] Sending 1 to n MESSAGEs >> >>Chris, >> >>Thanks for your thoughts. I agree, that a custome header of some sort >>would help. I'd probably want to standardise that header with an RFC >>though- what are thoughts on this? >> >>Duncan >> >>-----Original Message----- >>From: Chris Harris [mailto:CHarris@dynamicsoft.com] >>Sent: 24 June 2003 16:06 >>To: Mills, Duncan, D, CND Tech Dev, VF UK; Rosen, Brian; = simple@ietf.org >>Subject: RE: [Simple] Sending 1 to n MESSAGEs >> >> >>Duncan, >> >>One possibility for this ad-hoc group messaging is to address the = message >>to >>a message exploder application, and to use other custom headers for = the >>list >>of actual recipients (say a list of X-Recipient: headers) that the >exploder >>understands. Once the exploder accepts the message it would presumably >send >>a 202 response to the sender and be responsible for the delivery of = the >>messages to the recipients. >> >>Regards, >>Chris Harris >> >>> -----Original Message----- >>> From: Mills, Duncan, D, CND Tech Dev, VF UK >>> [mailto:Duncan.Mills@gb.vodafone.co.uk] >>> Sent: Tuesday, June 24, 2003 10:55 AM >>> To: Rosen, Brian; simple@ietf.org >>> Subject: RE: [Simple] Sending 1 to n MESSAGEs >>> >>> >>> Dear CLEVER people (of the SIMPLE WG) ;-) >>> >>> Brian- yes, my thought was to allow a B2BUA function to fork >>> the MESSAGE request. This way, the user doesn't have to >>> pre-configure the recipient list, but perhaps they do have to >>> pre-configure the address of their MESSAGING server (the >>> B2BUA). When I say pre-configure, I'm sure there are more >>> dynamic ways to get the B2BUA address to the UA. >>> >>> I must admit, I am coming at this from the 3GPP perspective >>> and so a SIP AS (acting in B2BUA mode) would seem to do the >>> trick. However, it would require- I believe- some extensions to = SIP. >>> >>> However, 3GPP radio interface constraints aside, I think it >>> would be a shame to design SIP messaging without the ability >>> to fork a message to n recipients, in the same way you can >>> with e-mail. >>> >>> Thanks for your initial thoughts- I'd be interested in >>> progressing this issue, if you and others feel it worthwhile... >>> >>> Cheers, >>> >>> Duncan >>> >>> >>> -----Original Message----- >>> From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] >>> Sent: 24 June 2003 15:38 >>> To: Mills, Duncan, D, CND Tech Dev, VF UK; simple@ietf.org >>> Subject: RE: [Simple] Sending 1 to n MESSAGEs >>> >>> >>> Was the salutation to your message a comment on the quality of >>> the discourse on this list? ;) >>> >>> Good thought. Interacts with conferencing (mass invite to a >>> conference). >>> You don't want to have to have a complex interaction prior to = sending >>> a list of recipients. Smells like a kind of forking behavior, but >>> clearly different (not all the same AOR). Obviously creates = multiple >>> dialogs if/when multiple responses are received. The proxy can't be >>> the origination point; it's not a UA. All the responses are going = to >>> be forwarded to the UA. The only way around that is B2BUA behavior. >>> Is that a better, or a worse idea? >>> >>> Gotta think through what this means for Message Sessions. >>> You want the >>> proxy to replicate each message, but you don't really want to repeat >>> the list of recipients. Does that argue for B2BUA more strongly? >>> >>> With a B2BUA approach you send the message to the exploder. It >>> sends individual messages to recipients, and handles all the = dialogs. >>> That reminds me of a buddy list subscription without the prearranged >>> buddy list. >>> >>> Brian >>> >>> > -----Original Message----- >>> > From: Mills, Duncan, D, CND Tech Dev, VF UK >>> > [mailto:Duncan.Mills@gb.vodafone.co.uk] >>> > Sent: Tuesday, June 24, 2003 9:42 AM >>> > To: simple@ietf.org >>> > Subject: [Simple] Sending 1 to n MESSAGEs >>> > >>> > >>> > SIMPLE people, >>> > >>> > I've just been thinking about how my e-mail works, and what I >>> > like best about it. It is really easy to type a long message >>> > and then send it to a list of (more than one) people. Better >>> > still, I don't have to have pre-configured that list of >>> > people. I can just type in the addresses in the To: field >>> > and the mail will be sent to each address. >>> > >>> > As far as I know, I can't do this with the SIP MESSAGE >>> > method. Yes, I can create a resource URI in a server and >>> > send one MESSAGE request to that resource-URI, and the server >>> > may fork the MESSAGE to each URI in my pre-configured list. >>> > But if I don't want to have to set up a new list of >>> > recipients each time I send a MESSAGE then I have to send the >>> > same MESSAGE several times. Please correct me if I'm wrong. >>> > >>> > Now... looking at this from a wireless operator perspective, >>> > I immediately see warning signs about my =A36 billion radio >>> > interface ;-) Currently, in GSM, if we want to send an SMS >>> > to more 'n' recipients, we have the same situation- either >>> > create a user group in the network or send the message 'n' >>> > times. However, a SIP MESSAGE request is likely to be about >>> > ten times the size of an SMS. >>> > >>> > Is this a problem? If not, why not? Maybe I'm missing some >>> > background/historical information? >>> > >>> > If it is a problem, might it be possible to extend SIP in >>> > such a way as to state that the request-URI be set to the >>> > address of my SIP proxy server in my home network and then >>> > the To: field be filled with the list of intended recipients, >>> > with the server then being responsible for sending the >>> > MESSAGE to all the intended recipients? >>> > >>> > Any comments/views? >>> > >>> > Best Regards, >>> > >>> > Duncan >>> > >>> > >>> > Duncan Mills >>> > Senior Engineer >>> > Network Standards & Technical Audit >>> > Technology Development (Network Systems) >>> > Vodafone (UK) Ltd >>> > Tel: +44 (0)1635 676074 >>> > Mob: +44 7867 900955 >>> > Fax: +44 (0)1635 234445 >>> > mailto:duncan.mills@vf.vodafone.co.uk >>> > >>> > >>> > >>> > _______________________________________________ >>> > Simple mailing list >>> > Simple@ietf.org >>> > https://www1.ietf.org/mailman/listinfo/simple >>> > >>> >>> _______________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> https://www1.ietf.org/mailman/listinfo/simple >>> >> >>_______________________________________________ >>Simple mailing list >>Simple@ietf.org >>https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Jun 24 11:49:10 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 LAA21015; Tue, 24 Jun 2003 11:49:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Uq2i-0003nc-00; Tue, 24 Jun 2003 11:49:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Uq2c-0003nZ-00; Tue, 24 Jun 2003 11:49:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Uq2W-00086f-Ui; Tue, 24 Jun 2003 11:49:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Uq1u-00086C-Vy for simple@optimus.ietf.org; Tue, 24 Jun 2003 11:48: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 LAA20969 for ; Tue, 24 Jun 2003 11:48:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Uq1u-0003n1-00 for simple@ietf.org; Tue, 24 Jun 2003 11:48:22 -0400 Received: from igate2.vodafone.co.uk ([194.62.232.66]) by ietf-mx with esmtp (Exim 4.12) id 19Uq1i-0003mg-00 for simple@ietf.org; Tue, 24 Jun 2003 11:48:10 -0400 Received: by igate2.vodafone.co.uk; (8.8.8/1.3/10May95) id QAA17348; Tue, 24 Jun 2003 16:47:34 +0100 (BST) Received: from ukwmxc02.vf-uk.internal.vodafone.com (ukwmxc02 [10.33.126.170]) by mailguard2 (4.6.1.123) with ESMTP id ; Tue, 24 Jun 2003 16:45:01 +0100 Received: from ukwmxc03.vf-uk.internal.vodafone.com ([10.33.126.155]) by ukwmxc02.vf-uk.internal.vodafone.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 24 Jun 2003 16:47:08 +0100 Received: from ukwmxm02.vf-uk.internal.vodafone.com ([10.33.126.242]) by ukwmxc03.vf-uk.internal.vodafone.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 24 Jun 2003 16:46:49 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message Subject: RE: [Simple] Sending 1 to n MESSAGEs Message-ID: Thread-Topic: [Simple] Sending 1 to n MESSAGEs Thread-Index: AcM6Yk7hUE6eq5AARvGA969Z94cyvgAAKZjgAAA+L1AAACkF4AAAWgWAAABS8vA= From: "Mills, Duncan, D, CND Tech Dev, VF UK" To: "Chris Boulton" , X-OriginalArrivalTime: 24 Jun 2003 15:46:49.0687 (UTC) FILETIME=[D3420E70:01C33A67] MIME-Version: 1.0 (Generated by Clearswift ES version 4.6.1.122) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 24 Jun 2003 16:46:50 +0100 Content-Transfer-Encoding: quoted-printable Chris, Yes, I think there are two cases here: 1.) The ability to 'explode' MESSAGES to a 'distribution list' 2.) The ability to send the same MESSAGE to several people NOT on a = pre-configured distribution list (as Brian already pointed out, it would = be complex to expect users to have to log onto a server in the network = to set up a list every time) I believe that 1.) can already be overcome in the way that you describe. = Basically, in this case, the user DOES have to set up the distribution = list (a resource-URI) and send one MESSAGE to that list. I am trying to solve case 2.) Duncan -----Original Message----- From: Chris Boulton [mailto:cboulton@ubiquity.net] Sent: 24 June 2003 16:39 To: Mills, Duncan, D, CND Tech Dev, VF UK; simple@ietf.org Subject: RE: [Simple] Sending 1 to n MESSAGEs Duncan, I totally agree, I'm not saying that the latter is an option. I was = just thinking of scale e.g. you want to 'explode' to say 80 people. I = guess your exploder would be able to group Sip URL's for this purpose = e.g. sip:mailshot@ubiquity.net which has been configured to fork to 80 = contact addresses. Chris. =20 >-----Original Message----- >From: Mills, Duncan, D, CND Tech Dev, VF UK >[mailto:Duncan.Mills@gb.vodafone.co.uk] >Sent: 24 June 2003 16:27 >To: Chris Boulton; simple@ietf.org >Subject: RE: [Simple] Sending 1 to n MESSAGEs > >Chris, > >For the sake of a few extra addresses in the MESSAGE headers, for a = 1000 >byte MESSAGE request destined for 8 recipients, we can go from (for >example) 8 * 1000 bytes to 1 * 1800 bytes (and that assumes each = recipient >address requires 100 bytes). > >I know which I'd prefer... > >Duncan > >-----Original Message----- >From: Chris Boulton [mailto:cboulton@ubiquity.net] >Sent: 24 June 2003 16:20 >To: Mills, Duncan, D, CND Tech Dev, VF UK; Chris Harris; Rosen, Brian; >simple@ietf.org >Subject: RE: [Simple] Sending 1 to n MESSAGEs > > >Chris, > > Wouldn't this be an expensive way of including a list of X-recipients >(message size)? > >Chris B. > > >>-----Original Message----- >>From: Mills, Duncan, D, CND Tech Dev, VF UK >>[mailto:Duncan.Mills@gb.vodafone.co.uk] >>Sent: 24 June 2003 16:13 >>To: Chris Harris; Rosen, Brian; simple@ietf.org >>Subject: RE: [Simple] Sending 1 to n MESSAGEs >> >>Chris, >> >>Thanks for your thoughts. I agree, that a custome header of some sort >>would help. I'd probably want to standardise that header with an RFC >>though- what are thoughts on this? >> >>Duncan >> >>-----Original Message----- >>From: Chris Harris [mailto:CHarris@dynamicsoft.com] >>Sent: 24 June 2003 16:06 >>To: Mills, Duncan, D, CND Tech Dev, VF UK; Rosen, Brian; = simple@ietf.org >>Subject: RE: [Simple] Sending 1 to n MESSAGEs >> >> >>Duncan, >> >>One possibility for this ad-hoc group messaging is to address the = message >>to >>a message exploder application, and to use other custom headers for = the >>list >>of actual recipients (say a list of X-Recipient: headers) that the >exploder >>understands. Once the exploder accepts the message it would presumably >send >>a 202 response to the sender and be responsible for the delivery of = the >>messages to the recipients. >> >>Regards, >>Chris Harris >> >>> -----Original Message----- >>> From: Mills, Duncan, D, CND Tech Dev, VF UK >>> [mailto:Duncan.Mills@gb.vodafone.co.uk] >>> Sent: Tuesday, June 24, 2003 10:55 AM >>> To: Rosen, Brian; simple@ietf.org >>> Subject: RE: [Simple] Sending 1 to n MESSAGEs >>> >>> >>> Dear CLEVER people (of the SIMPLE WG) ;-) >>> >>> Brian- yes, my thought was to allow a B2BUA function to fork >>> the MESSAGE request. This way, the user doesn't have to >>> pre-configure the recipient list, but perhaps they do have to >>> pre-configure the address of their MESSAGING server (the >>> B2BUA). When I say pre-configure, I'm sure there are more >>> dynamic ways to get the B2BUA address to the UA. >>> >>> I must admit, I am coming at this from the 3GPP perspective >>> and so a SIP AS (acting in B2BUA mode) would seem to do the >>> trick. However, it would require- I believe- some extensions to = SIP. >>> >>> However, 3GPP radio interface constraints aside, I think it >>> would be a shame to design SIP messaging without the ability >>> to fork a message to n recipients, in the same way you can >>> with e-mail. >>> >>> Thanks for your initial thoughts- I'd be interested in >>> progressing this issue, if you and others feel it worthwhile... >>> >>> Cheers, >>> >>> Duncan >>> >>> >>> -----Original Message----- >>> From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] >>> Sent: 24 June 2003 15:38 >>> To: Mills, Duncan, D, CND Tech Dev, VF UK; simple@ietf.org >>> Subject: RE: [Simple] Sending 1 to n MESSAGEs >>> >>> >>> Was the salutation to your message a comment on the quality of >>> the discourse on this list? ;) >>> >>> Good thought. Interacts with conferencing (mass invite to a >>> conference). >>> You don't want to have to have a complex interaction prior to = sending >>> a list of recipients. Smells like a kind of forking behavior, but >>> clearly different (not all the same AOR). Obviously creates = multiple >>> dialogs if/when multiple responses are received. The proxy can't be >>> the origination point; it's not a UA. All the responses are going = to >>> be forwarded to the UA. The only way around that is B2BUA behavior. >>> Is that a better, or a worse idea? >>> >>> Gotta think through what this means for Message Sessions. >>> You want the >>> proxy to replicate each message, but you don't really want to repeat >>> the list of recipients. Does that argue for B2BUA more strongly? >>> >>> With a B2BUA approach you send the message to the exploder. It >>> sends individual messages to recipients, and handles all the = dialogs. >>> That reminds me of a buddy list subscription without the prearranged >>> buddy list. >>> >>> Brian >>> >>> > -----Original Message----- >>> > From: Mills, Duncan, D, CND Tech Dev, VF UK >>> > [mailto:Duncan.Mills@gb.vodafone.co.uk] >>> > Sent: Tuesday, June 24, 2003 9:42 AM >>> > To: simple@ietf.org >>> > Subject: [Simple] Sending 1 to n MESSAGEs >>> > >>> > >>> > SIMPLE people, >>> > >>> > I've just been thinking about how my e-mail works, and what I >>> > like best about it. It is really easy to type a long message >>> > and then send it to a list of (more than one) people. Better >>> > still, I don't have to have pre-configured that list of >>> > people. I can just type in the addresses in the To: field >>> > and the mail will be sent to each address. >>> > >>> > As far as I know, I can't do this with the SIP MESSAGE >>> > method. Yes, I can create a resource URI in a server and >>> > send one MESSAGE request to that resource-URI, and the server >>> > may fork the MESSAGE to each URI in my pre-configured list. >>> > But if I don't want to have to set up a new list of >>> > recipients each time I send a MESSAGE then I have to send the >>> > same MESSAGE several times. Please correct me if I'm wrong. >>> > >>> > Now... looking at this from a wireless operator perspective, >>> > I immediately see warning signs about my =A36 billion radio >>> > interface ;-) Currently, in GSM, if we want to send an SMS >>> > to more 'n' recipients, we have the same situation- either >>> > create a user group in the network or send the message 'n' >>> > times. However, a SIP MESSAGE request is likely to be about >>> > ten times the size of an SMS. >>> > >>> > Is this a problem? If not, why not? Maybe I'm missing some >>> > background/historical information? >>> > >>> > If it is a problem, might it be possible to extend SIP in >>> > such a way as to state that the request-URI be set to the >>> > address of my SIP proxy server in my home network and then >>> > the To: field be filled with the list of intended recipients, >>> > with the server then being responsible for sending the >>> > MESSAGE to all the intended recipients? >>> > >>> > Any comments/views? >>> > >>> > Best Regards, >>> > >>> > Duncan >>> > >>> > >>> > Duncan Mills >>> > Senior Engineer >>> > Network Standards & Technical Audit >>> > Technology Development (Network Systems) >>> > Vodafone (UK) Ltd >>> > Tel: +44 (0)1635 676074 >>> > Mob: +44 7867 900955 >>> > Fax: +44 (0)1635 234445 >>> > mailto:duncan.mills@vf.vodafone.co.uk >>> > >>> > >>> > >>> > _______________________________________________ >>> > Simple mailing list >>> > Simple@ietf.org >>> > https://www1.ietf.org/mailman/listinfo/simple >>> > >>> >>> _______________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> https://www1.ietf.org/mailman/listinfo/simple >>> >> >>_______________________________________________ >>Simple mailing list >>Simple@ietf.org >>https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Jun 24 11:49:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21066 for ; Tue, 24 Jun 2003 11:49:41 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5OFnDX31369 for simple-archive@odin.ietf.org; Tue, 24 Jun 2003 11:49:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Uq2j-00089s-M4 for simple-web-archive@optimus.ietf.org; Tue, 24 Jun 2003 11:49:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21015; Tue, 24 Jun 2003 11:49:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Uq2i-0003nc-00; Tue, 24 Jun 2003 11:49:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Uq2c-0003nZ-00; Tue, 24 Jun 2003 11:49:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Uq2W-00086f-Ui; Tue, 24 Jun 2003 11:49:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Uq1u-00086C-Vy for simple@optimus.ietf.org; Tue, 24 Jun 2003 11:48: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 LAA20969 for ; Tue, 24 Jun 2003 11:48:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Uq1u-0003n1-00 for simple@ietf.org; Tue, 24 Jun 2003 11:48:22 -0400 Received: from igate2.vodafone.co.uk ([194.62.232.66]) by ietf-mx with esmtp (Exim 4.12) id 19Uq1i-0003mg-00 for simple@ietf.org; Tue, 24 Jun 2003 11:48:10 -0400 Received: by igate2.vodafone.co.uk; (8.8.8/1.3/10May95) id QAA17348; Tue, 24 Jun 2003 16:47:34 +0100 (BST) Received: from ukwmxc02.vf-uk.internal.vodafone.com (ukwmxc02 [10.33.126.170]) by mailguard2 (4.6.1.123) with ESMTP id ; Tue, 24 Jun 2003 16:45:01 +0100 Received: from ukwmxc03.vf-uk.internal.vodafone.com ([10.33.126.155]) by ukwmxc02.vf-uk.internal.vodafone.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 24 Jun 2003 16:47:08 +0100 Received: from ukwmxm02.vf-uk.internal.vodafone.com ([10.33.126.242]) by ukwmxc03.vf-uk.internal.vodafone.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 24 Jun 2003 16:46:49 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message Subject: RE: [Simple] Sending 1 to n MESSAGEs Message-ID: Thread-Topic: [Simple] Sending 1 to n MESSAGEs Thread-Index: AcM6Yk7hUE6eq5AARvGA969Z94cyvgAAKZjgAAA+L1AAACkF4AAAWgWAAABS8vA= From: "Mills, Duncan, D, CND Tech Dev, VF UK" To: "Chris Boulton" , X-OriginalArrivalTime: 24 Jun 2003 15:46:49.0687 (UTC) FILETIME=[D3420E70:01C33A67] MIME-Version: 1.0 (Generated by Clearswift ES version 4.6.1.122) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 24 Jun 2003 16:46:50 +0100 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Chris, Yes, I think there are two cases here: 1.) The ability to 'explode' MESSAGES to a 'distribution list' 2.) The ability to send the same MESSAGE to several people NOT on a = pre-configured distribution list (as Brian already pointed out, it would = be complex to expect users to have to log onto a server in the network = to set up a list every time) I believe that 1.) can already be overcome in the way that you describe. = Basically, in this case, the user DOES have to set up the distribution = list (a resource-URI) and send one MESSAGE to that list. I am trying to solve case 2.) Duncan -----Original Message----- From: Chris Boulton [mailto:cboulton@ubiquity.net] Sent: 24 June 2003 16:39 To: Mills, Duncan, D, CND Tech Dev, VF UK; simple@ietf.org Subject: RE: [Simple] Sending 1 to n MESSAGEs Duncan, I totally agree, I'm not saying that the latter is an option. I was = just thinking of scale e.g. you want to 'explode' to say 80 people. I = guess your exploder would be able to group Sip URL's for this purpose = e.g. sip:mailshot@ubiquity.net which has been configured to fork to 80 = contact addresses. Chris. =20 >-----Original Message----- >From: Mills, Duncan, D, CND Tech Dev, VF UK >[mailto:Duncan.Mills@gb.vodafone.co.uk] >Sent: 24 June 2003 16:27 >To: Chris Boulton; simple@ietf.org >Subject: RE: [Simple] Sending 1 to n MESSAGEs > >Chris, > >For the sake of a few extra addresses in the MESSAGE headers, for a = 1000 >byte MESSAGE request destined for 8 recipients, we can go from (for >example) 8 * 1000 bytes to 1 * 1800 bytes (and that assumes each = recipient >address requires 100 bytes). > >I know which I'd prefer... > >Duncan > >-----Original Message----- >From: Chris Boulton [mailto:cboulton@ubiquity.net] >Sent: 24 June 2003 16:20 >To: Mills, Duncan, D, CND Tech Dev, VF UK; Chris Harris; Rosen, Brian; >simple@ietf.org >Subject: RE: [Simple] Sending 1 to n MESSAGEs > > >Chris, > > Wouldn't this be an expensive way of including a list of X-recipients >(message size)? > >Chris B. > > >>-----Original Message----- >>From: Mills, Duncan, D, CND Tech Dev, VF UK >>[mailto:Duncan.Mills@gb.vodafone.co.uk] >>Sent: 24 June 2003 16:13 >>To: Chris Harris; Rosen, Brian; simple@ietf.org >>Subject: RE: [Simple] Sending 1 to n MESSAGEs >> >>Chris, >> >>Thanks for your thoughts. I agree, that a custome header of some sort >>would help. I'd probably want to standardise that header with an RFC >>though- what are thoughts on this? >> >>Duncan >> >>-----Original Message----- >>From: Chris Harris [mailto:CHarris@dynamicsoft.com] >>Sent: 24 June 2003 16:06 >>To: Mills, Duncan, D, CND Tech Dev, VF UK; Rosen, Brian; = simple@ietf.org >>Subject: RE: [Simple] Sending 1 to n MESSAGEs >> >> >>Duncan, >> >>One possibility for this ad-hoc group messaging is to address the = message >>to >>a message exploder application, and to use other custom headers for = the >>list >>of actual recipients (say a list of X-Recipient: headers) that the >exploder >>understands. Once the exploder accepts the message it would presumably >send >>a 202 response to the sender and be responsible for the delivery of = the >>messages to the recipients. >> >>Regards, >>Chris Harris >> >>> -----Original Message----- >>> From: Mills, Duncan, D, CND Tech Dev, VF UK >>> [mailto:Duncan.Mills@gb.vodafone.co.uk] >>> Sent: Tuesday, June 24, 2003 10:55 AM >>> To: Rosen, Brian; simple@ietf.org >>> Subject: RE: [Simple] Sending 1 to n MESSAGEs >>> >>> >>> Dear CLEVER people (of the SIMPLE WG) ;-) >>> >>> Brian- yes, my thought was to allow a B2BUA function to fork >>> the MESSAGE request. This way, the user doesn't have to >>> pre-configure the recipient list, but perhaps they do have to >>> pre-configure the address of their MESSAGING server (the >>> B2BUA). When I say pre-configure, I'm sure there are more >>> dynamic ways to get the B2BUA address to the UA. >>> >>> I must admit, I am coming at this from the 3GPP perspective >>> and so a SIP AS (acting in B2BUA mode) would seem to do the >>> trick. However, it would require- I believe- some extensions to = SIP. >>> >>> However, 3GPP radio interface constraints aside, I think it >>> would be a shame to design SIP messaging without the ability >>> to fork a message to n recipients, in the same way you can >>> with e-mail. >>> >>> Thanks for your initial thoughts- I'd be interested in >>> progressing this issue, if you and others feel it worthwhile... >>> >>> Cheers, >>> >>> Duncan >>> >>> >>> -----Original Message----- >>> From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] >>> Sent: 24 June 2003 15:38 >>> To: Mills, Duncan, D, CND Tech Dev, VF UK; simple@ietf.org >>> Subject: RE: [Simple] Sending 1 to n MESSAGEs >>> >>> >>> Was the salutation to your message a comment on the quality of >>> the discourse on this list? ;) >>> >>> Good thought. Interacts with conferencing (mass invite to a >>> conference). >>> You don't want to have to have a complex interaction prior to = sending >>> a list of recipients. Smells like a kind of forking behavior, but >>> clearly different (not all the same AOR). Obviously creates = multiple >>> dialogs if/when multiple responses are received. The proxy can't be >>> the origination point; it's not a UA. All the responses are going = to >>> be forwarded to the UA. The only way around that is B2BUA behavior. >>> Is that a better, or a worse idea? >>> >>> Gotta think through what this means for Message Sessions. >>> You want the >>> proxy to replicate each message, but you don't really want to repeat >>> the list of recipients. Does that argue for B2BUA more strongly? >>> >>> With a B2BUA approach you send the message to the exploder. It >>> sends individual messages to recipients, and handles all the = dialogs. >>> That reminds me of a buddy list subscription without the prearranged >>> buddy list. >>> >>> Brian >>> >>> > -----Original Message----- >>> > From: Mills, Duncan, D, CND Tech Dev, VF UK >>> > [mailto:Duncan.Mills@gb.vodafone.co.uk] >>> > Sent: Tuesday, June 24, 2003 9:42 AM >>> > To: simple@ietf.org >>> > Subject: [Simple] Sending 1 to n MESSAGEs >>> > >>> > >>> > SIMPLE people, >>> > >>> > I've just been thinking about how my e-mail works, and what I >>> > like best about it. It is really easy to type a long message >>> > and then send it to a list of (more than one) people. Better >>> > still, I don't have to have pre-configured that list of >>> > people. I can just type in the addresses in the To: field >>> > and the mail will be sent to each address. >>> > >>> > As far as I know, I can't do this with the SIP MESSAGE >>> > method. Yes, I can create a resource URI in a server and >>> > send one MESSAGE request to that resource-URI, and the server >>> > may fork the MESSAGE to each URI in my pre-configured list. >>> > But if I don't want to have to set up a new list of >>> > recipients each time I send a MESSAGE then I have to send the >>> > same MESSAGE several times. Please correct me if I'm wrong. >>> > >>> > Now... looking at this from a wireless operator perspective, >>> > I immediately see warning signs about my =A36 billion radio >>> > interface ;-) Currently, in GSM, if we want to send an SMS >>> > to more 'n' recipients, we have the same situation- either >>> > create a user group in the network or send the message 'n' >>> > times. However, a SIP MESSAGE request is likely to be about >>> > ten times the size of an SMS. >>> > >>> > Is this a problem? If not, why not? Maybe I'm missing some >>> > background/historical information? >>> > >>> > If it is a problem, might it be possible to extend SIP in >>> > such a way as to state that the request-URI be set to the >>> > address of my SIP proxy server in my home network and then >>> > the To: field be filled with the list of intended recipients, >>> > with the server then being responsible for sending the >>> > MESSAGE to all the intended recipients? >>> > >>> > Any comments/views? >>> > >>> > Best Regards, >>> > >>> > Duncan >>> > >>> > >>> > Duncan Mills >>> > Senior Engineer >>> > Network Standards & Technical Audit >>> > Technology Development (Network Systems) >>> > Vodafone (UK) Ltd >>> > Tel: +44 (0)1635 676074 >>> > Mob: +44 7867 900955 >>> > Fax: +44 (0)1635 234445 >>> > mailto:duncan.mills@vf.vodafone.co.uk >>> > >>> > >>> > >>> > _______________________________________________ >>> > Simple mailing list >>> > Simple@ietf.org >>> > https://www1.ietf.org/mailman/listinfo/simple >>> > >>> >>> _______________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> https://www1.ietf.org/mailman/listinfo/simple >>> >> >>_______________________________________________ >>Simple mailing list >>Simple@ietf.org >>https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Jun 24 14:38:06 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 OAA02308; Tue, 24 Jun 2003 14:38:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UsgB-0005mE-00; Tue, 24 Jun 2003 14:38:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Usg5-0005mB-00; Tue, 24 Jun 2003 14:38:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Usg5-0008F1-TN; Tue, 24 Jun 2003 14:38:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Usg1-0008Ei-QD for simple@optimus.ietf.org; Tue, 24 Jun 2003 14:37: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 OAA02302 for ; Tue, 24 Jun 2003 14:37:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Usfz-0005m4-00 for simple@ietf.org; Tue, 24 Jun 2003 14:37:55 -0400 Received: from bdsl.66.12.12.130.gte.net ([66.12.12.130] helo=bdsl.greycouncil.com) by ietf-mx with esmtp (Exim 4.12) id 19Usfo-0005le-00 for simple@ietf.org; Tue, 24 Jun 2003 14:37:44 -0400 Received: from localhost (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h5OIb6Th010084; Tue, 24 Jun 2003 13:37:06 -0500 Subject: Re: [Simple] Sending 1 to n MESSAGEs From: Dean Willis To: "Mills, Duncan, D, CND Tech Dev, VF UK" Cc: simple@ietf.org In-Reply-To: References: Content-Type: text/plain Message-Id: <1056479824.2226.45.camel@bdsl.greycouncil.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.0 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: 24 Jun 2003 13:37:05 -0500 Content-Transfer-Encoding: 7bit Duncan pondered: > I've just been thinking about how my e-mail works, and what I like > best about it. It is really easy to type a long message and then send > it to a list of (more than one) people. Better still, I don't have to > have pre-configured that list of people. I can just type in the > addresses in the To: field and the mail will be sent to each address. What if your application were to take care of the overhead of creating and deleting the list for you? Scenario: 1) You enter multiple recpients in your GUI 2) The UA creates a recipient list on your messaging server witha temprary name 3) The UA sends a message to the recipient list at the messaging server 4) When the list hasn't been used for a while, the UA or server deletes it. This is noce because it provides a chaching opportunity on dynamic lists -- for example, if you send several messages to the same list, the list of addresses has to be transferred only once over the "air interface". The overhead of creating the list in a seperate server transaction is slightly larger than that of including the entire list in the message request (ala "X-recipient"). But not MUCH larger. . . so we gain an advantage very quickly for repeat sends. One could also envision a server-sidesystem that records these "dynamic lists" and makes them available for re-use or server-side editing and review. Perhaps it could work like the "recent calls" feature in a phone, and the ten most recently used dynamic lists per device would be available. -- Dean -- Dean _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Jun 24 14:38:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02346 for ; Tue, 24 Jun 2003 14:38:37 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5OIcA231788 for simple-archive@odin.ietf.org; Tue, 24 Jun 2003 14:38:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UsgE-0008Gd-Bv for simple-web-archive@optimus.ietf.org; Tue, 24 Jun 2003 14:38:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02308; Tue, 24 Jun 2003 14:38:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UsgB-0005mE-00; Tue, 24 Jun 2003 14:38:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Usg5-0005mB-00; Tue, 24 Jun 2003 14:38:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Usg5-0008F1-TN; Tue, 24 Jun 2003 14:38:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Usg1-0008Ei-QD for simple@optimus.ietf.org; Tue, 24 Jun 2003 14:37: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 OAA02302 for ; Tue, 24 Jun 2003 14:37:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Usfz-0005m4-00 for simple@ietf.org; Tue, 24 Jun 2003 14:37:55 -0400 Received: from bdsl.66.12.12.130.gte.net ([66.12.12.130] helo=bdsl.greycouncil.com) by ietf-mx with esmtp (Exim 4.12) id 19Usfo-0005le-00 for simple@ietf.org; Tue, 24 Jun 2003 14:37:44 -0400 Received: from localhost (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h5OIb6Th010084; Tue, 24 Jun 2003 13:37:06 -0500 Subject: Re: [Simple] Sending 1 to n MESSAGEs From: Dean Willis To: "Mills, Duncan, D, CND Tech Dev, VF UK" Cc: simple@ietf.org In-Reply-To: References: Content-Type: text/plain Message-Id: <1056479824.2226.45.camel@bdsl.greycouncil.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.0 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: 24 Jun 2003 13:37:05 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Duncan pondered: > I've just been thinking about how my e-mail works, and what I like > best about it. It is really easy to type a long message and then send > it to a list of (more than one) people. Better still, I don't have to > have pre-configured that list of people. I can just type in the > addresses in the To: field and the mail will be sent to each address. What if your application were to take care of the overhead of creating and deleting the list for you? Scenario: 1) You enter multiple recpients in your GUI 2) The UA creates a recipient list on your messaging server witha temprary name 3) The UA sends a message to the recipient list at the messaging server 4) When the list hasn't been used for a while, the UA or server deletes it. This is noce because it provides a chaching opportunity on dynamic lists -- for example, if you send several messages to the same list, the list of addresses has to be transferred only once over the "air interface". The overhead of creating the list in a seperate server transaction is slightly larger than that of including the entire list in the message request (ala "X-recipient"). But not MUCH larger. . . so we gain an advantage very quickly for repeat sends. One could also envision a server-sidesystem that records these "dynamic lists" and makes them available for re-use or server-side editing and review. Perhaps it could work like the "recent calls" feature in a phone, and the ten most recently used dynamic lists per device would be available. -- Dean -- Dean _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Jun 24 15:18:09 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 PAA05286; Tue, 24 Jun 2003 15:18:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UtIv-0006Ce-00; Tue, 24 Jun 2003 15:18:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19UtIq-0006Cb-00; Tue, 24 Jun 2003 15:18:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UtIp-0001fC-Bv; Tue, 24 Jun 2003 15:18:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UtIY-0001du-9X for simple@optimus.ietf.org; Tue, 24 Jun 2003 15:17:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05206 for ; Tue, 24 Jun 2003 15:17:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UtIX-0006C5-00 for simple@ietf.org; Tue, 24 Jun 2003 15:17:45 -0400 Received: from dgesmtp01.wcom.com ([199.249.16.16]) by ietf-mx with esmtp (Exim 4.12) id 19UtIM-0006BS-00 for simple@ietf.org; Tue, 24 Jun 2003 15:17:34 -0400 Received: from pmismtp01.wcomnet.com ([166.38.62.36]) by firewall.wcom.com (Iplanet MTA 5.2) with ESMTP id <0HH000EM02V830@firewall.wcom.com> for simple@ietf.org; Tue, 24 Jun 2003 19:16:20 +0000 (GMT) Received: from pmismtp01.wcomnet.com by pmismtp01.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0HH000B012V8A1@pmismtp01.wcomnet.com>; Tue, 24 Jun 2003 19:16:20 +0000 (GMT) Received: from xs578v3521.mci.com ([166.50.122.248]) by pmismtp01.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HH0009452V6NT@pmismtp01.wcomnet.com>; Tue, 24 Jun 2003 19:16:20 +0000 (GMT) From: Alan Johnston X-Sender: Alan.Johnston@pop.mcit.com To: simple@ietf.org Cc: Adam Roach Message-id: <5.2.1.1.0.20030624141326.023c0db0@pop.mcit.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Content-type: text/plain; charset=us-ascii; format=flowed Subject: [Simple] Centralized Conferencing (xcon) BOF Announcement 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, 24 Jun 2003 14:16:17 -0500 FYI. Centralized Conferencing BOF (xcon) Tuesday, July 15 at 1700-1800 ============================== CHAIRS: Alan Johnston (alan.johnston@mci.com) Adam Roach (adam@dynamicsoft.com) AGENDA: - Intro and Agenda Bashing (5 min) - Problem Statement and Overview of Scope (10 min) - Charter Discussion (15 min) - Open Discussion (30 min) Description of Proposed Working Group The focus of this working group is to develop a standardized suite of protocols for tightly-coupled multimedia conferences, where strong security and authorization requirements are integral to the solution. Tightly-coupled conferences have a central point of control and authorization so they can enforce specific media and membership relationships, and provide an accurate roster of participants. The media mixing or combining function of a tightly-coupled conference need not be performed centrally, however. Unlike previous attempts at standardizing conferencing-related activities, the scope of this effort is intentionally very narrow, and is intended to enable interoperability in a commercial environment which already has a number of implementations. Privacy, security, and authorization mechanisms are integral to the solution generated by the working group. This includes allowing participants to be completely invisible or to be visible but participate anonymously with respect to some or all of the other participants. Authorization rules allow for participants and non-participants to have roles (ex: speaker, moderator, owner), and to be otherwise authorized to perform membership and media manipulation for or on behalf of other participants. In order to preserve these properties, the protocols used will require implementation of channel security and authentication services. Initially this combination of protocols will be specified with respect to session setup with SIP, but most of the specific components would be applicable to conferences setup using other protocols. [None of the protocols defined by this group will be SIP or require SIP extensions.] The group will use the high-level requirements and framework already described by documents published by the SIPPING WG. The deliverables for the group will be: - A mechanism for membership and authorization control - A mechanism to manipulate and describe media "layout" or "topology" for multiple media types (audio, video, text) - A mechanism for notification of conference related events/changes (for example a roster) - A basic floor control protocol - Peer-to-peer cascading of conferences (one conference is a participant in another and vice versa) The following items are specifically out-of-scope: - Voting - Multicast media (due to security concerns) - Fully distributed conferences - Loosely-coupled conferences (no central point of control) - Far-end device control - Protocol used between the conference controller and the mixer(s) - Capabilities negotiation of the mixer(s) - Master-slave cascaded conferences The working group will coordinate closely with the SIPPING and MMUSIC working groups. In addition the working group will cooperate with other groups as needed, including SIP, AVT, and the W3C SMIL working groups. In addition, the working group will consider a number of existing drafts (a non-exhaustive list is included below) as input to the working group. Related documents in other working groups: - draft-ietf-sipping-conferencing-requirements-00.txt - draft-ietf-sipping-conferencing-framework-00.txt - draft-ietf-sipping-cc-conferencing-00.txt - draft-ietf-sipping-cc-framework-02.txt - draft-ietf-sipping-conference-package-00.txt Partial list of input documents: (All documents available at http://ee.wustl.edu/~alan/xcon/ until they appear in the IETF archives.) - draft-even-xcon-conference-scenarios-00.txt - draft-koskelainen-xcon-cpcp-reqs-00.txt - draft-even-xcon-media-policy-requirements-00.txt - draft-koskelainen-xcon-floor-control-req-00.txt - draft-koskelainen-xcon-xcap-cpcp-usage-00.txt - draft-levin-xcon-cpcp-00.txt - draft-mahy-xcon-media-policy-control-00.txt Comments on the above drafts are welcome on the xcon mailing list: Mailing-List: xcon@softarmor.com http://www.softarmor.com/mailman/listinfo/xcon _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Jun 24 15:18:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05384 for ; Tue, 24 Jun 2003 15:18:40 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5OJIBH06920 for simple-archive@odin.ietf.org; Tue, 24 Jun 2003 15:18:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UtIx-0001nX-Eo for simple-web-archive@optimus.ietf.org; Tue, 24 Jun 2003 15:18: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 PAA05286; Tue, 24 Jun 2003 15:18:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UtIv-0006Ce-00; Tue, 24 Jun 2003 15:18:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19UtIq-0006Cb-00; Tue, 24 Jun 2003 15:18:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UtIp-0001fC-Bv; Tue, 24 Jun 2003 15:18:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UtIY-0001du-9X for simple@optimus.ietf.org; Tue, 24 Jun 2003 15:17:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05206 for ; Tue, 24 Jun 2003 15:17:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UtIX-0006C5-00 for simple@ietf.org; Tue, 24 Jun 2003 15:17:45 -0400 Received: from dgesmtp01.wcom.com ([199.249.16.16]) by ietf-mx with esmtp (Exim 4.12) id 19UtIM-0006BS-00 for simple@ietf.org; Tue, 24 Jun 2003 15:17:34 -0400 Received: from pmismtp01.wcomnet.com ([166.38.62.36]) by firewall.wcom.com (Iplanet MTA 5.2) with ESMTP id <0HH000EM02V830@firewall.wcom.com> for simple@ietf.org; Tue, 24 Jun 2003 19:16:20 +0000 (GMT) Received: from pmismtp01.wcomnet.com by pmismtp01.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0HH000B012V8A1@pmismtp01.wcomnet.com>; Tue, 24 Jun 2003 19:16:20 +0000 (GMT) Received: from xs578v3521.mci.com ([166.50.122.248]) by pmismtp01.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HH0009452V6NT@pmismtp01.wcomnet.com>; Tue, 24 Jun 2003 19:16:20 +0000 (GMT) From: Alan Johnston X-Sender: Alan.Johnston@pop.mcit.com To: simple@ietf.org Cc: Adam Roach Message-id: <5.2.1.1.0.20030624141326.023c0db0@pop.mcit.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Content-type: text/plain; charset=us-ascii; format=flowed Subject: [Simple] Centralized Conferencing (xcon) BOF Announcement 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, 24 Jun 2003 14:16:17 -0500 FYI. Centralized Conferencing BOF (xcon) Tuesday, July 15 at 1700-1800 ============================== CHAIRS: Alan Johnston (alan.johnston@mci.com) Adam Roach (adam@dynamicsoft.com) AGENDA: - Intro and Agenda Bashing (5 min) - Problem Statement and Overview of Scope (10 min) - Charter Discussion (15 min) - Open Discussion (30 min) Description of Proposed Working Group The focus of this working group is to develop a standardized suite of protocols for tightly-coupled multimedia conferences, where strong security and authorization requirements are integral to the solution. Tightly-coupled conferences have a central point of control and authorization so they can enforce specific media and membership relationships, and provide an accurate roster of participants. The media mixing or combining function of a tightly-coupled conference need not be performed centrally, however. Unlike previous attempts at standardizing conferencing-related activities, the scope of this effort is intentionally very narrow, and is intended to enable interoperability in a commercial environment which already has a number of implementations. Privacy, security, and authorization mechanisms are integral to the solution generated by the working group. This includes allowing participants to be completely invisible or to be visible but participate anonymously with respect to some or all of the other participants. Authorization rules allow for participants and non-participants to have roles (ex: speaker, moderator, owner), and to be otherwise authorized to perform membership and media manipulation for or on behalf of other participants. In order to preserve these properties, the protocols used will require implementation of channel security and authentication services. Initially this combination of protocols will be specified with respect to session setup with SIP, but most of the specific components would be applicable to conferences setup using other protocols. [None of the protocols defined by this group will be SIP or require SIP extensions.] The group will use the high-level requirements and framework already described by documents published by the SIPPING WG. The deliverables for the group will be: - A mechanism for membership and authorization control - A mechanism to manipulate and describe media "layout" or "topology" for multiple media types (audio, video, text) - A mechanism for notification of conference related events/changes (for example a roster) - A basic floor control protocol - Peer-to-peer cascading of conferences (one conference is a participant in another and vice versa) The following items are specifically out-of-scope: - Voting - Multicast media (due to security concerns) - Fully distributed conferences - Loosely-coupled conferences (no central point of control) - Far-end device control - Protocol used between the conference controller and the mixer(s) - Capabilities negotiation of the mixer(s) - Master-slave cascaded conferences The working group will coordinate closely with the SIPPING and MMUSIC working groups. In addition the working group will cooperate with other groups as needed, including SIP, AVT, and the W3C SMIL working groups. In addition, the working group will consider a number of existing drafts (a non-exhaustive list is included below) as input to the working group. Related documents in other working groups: - draft-ietf-sipping-conferencing-requirements-00.txt - draft-ietf-sipping-conferencing-framework-00.txt - draft-ietf-sipping-cc-conferencing-00.txt - draft-ietf-sipping-cc-framework-02.txt - draft-ietf-sipping-conference-package-00.txt Partial list of input documents: (All documents available at http://ee.wustl.edu/~alan/xcon/ until they appear in the IETF archives.) - draft-even-xcon-conference-scenarios-00.txt - draft-koskelainen-xcon-cpcp-reqs-00.txt - draft-even-xcon-media-policy-requirements-00.txt - draft-koskelainen-xcon-floor-control-req-00.txt - draft-koskelainen-xcon-xcap-cpcp-usage-00.txt - draft-levin-xcon-cpcp-00.txt - draft-mahy-xcon-media-policy-control-00.txt Comments on the above drafts are welcome on the xcon mailing list: Mailing-List: xcon@softarmor.com http://www.softarmor.com/mailman/listinfo/xcon _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Jun 24 18:02:08 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 SAA12894; Tue, 24 Jun 2003 18:02:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Uvrd-0007d8-00; Tue, 24 Jun 2003 18:02:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19UvrY-0007d5-00; Tue, 24 Jun 2003 18:02:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UvrV-0000aN-5l; Tue, 24 Jun 2003 18:02:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Uvqj-0000ZV-7Y for simple@optimus.ietf.org; Tue, 24 Jun 2003 18:01: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 SAA12871 for ; Tue, 24 Jun 2003 18:01:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Uvqg-0007cd-00 for simple@ietf.org; Tue, 24 Jun 2003 18:01:10 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19UvqQ-0007cU-00 for simple@ietf.org; Tue, 24 Jun 2003 18:00:54 -0400 Received: from dynamicsoft.com ([63.113.46.124]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h5OLZJsm008920; Tue, 24 Jun 2003 17:35:22 -0400 (EDT) Message-ID: <3EF8C410.5030908@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dean Willis CC: "Mills, Duncan, D, CND Tech Dev, VF UK" , simple@ietf.org Subject: Re: [Simple] Sending 1 to n MESSAGEs References: <1056479824.2226.45.camel@bdsl.greycouncil.com> In-Reply-To: <1056479824.2226.45.camel@bdsl.greycouncil.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, 24 Jun 2003 17:35:12 -0400 Content-Transfer-Encoding: 7bit inline. Dean Willis wrote: > Duncan pondered: > >>I've just been thinking about how my e-mail works, and what I like >>best about it. It is really easy to type a long message and then send >>it to a list of (more than one) people. Better still, I don't have to >>have pre-configured that list of people. I can just type in the >>addresses in the To: field and the mail will be sent to each address. > > > What if your application were to take care of the overhead of creating > and deleting the list for you? > > Scenario: > > 1) You enter multiple recpients in your GUI > 2) The UA creates a recipient list on your messaging server witha > temprary name > 3) The UA sends a message to the recipient list at the messaging server > 4) When the list hasn't been used for a while, the UA or server deletes > it. > > This is noce because it provides a chaching opportunity on dynamic lists > -- for example, if you send several messages to the same list, the list > of addresses has to be transferred only once over the "air interface". It depends. Do you want the recipients to know who else received the message? Email works this way. If so, each recipient now needs to pull the list from the server too. That introduces requirements for ACLs on the list (members can pull them), and potentially for inter-domain access to those lists, in the cases where members are in other domains. Thus, if you send to N recipients, thats N+1 transactions on the list - one to set it, N to fetch it. So, the extra overhead is multiplied N+1 times. Another interesting issue with group messaging is delivery confirmation. The 202 sent by the server, as suggested by Chris, works great to know that the exploder received the message. Do we have requirements that the sender can find out if the message was delivered to each recipient? IMHO, if we want to proceed here, we need to write some concrete requirements on what the desired service is, and therefore be certain that its different from what we can already do (i.e., conferencing with session mode) before delving into solutions. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Scientist 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 Jun 24 18:02:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12928 for ; Tue, 24 Jun 2003 18:02:39 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5OM2DG02285 for simple-archive@odin.ietf.org; Tue, 24 Jun 2003 18:02:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Uvrh-0000am-AJ for simple-web-archive@optimus.ietf.org; Tue, 24 Jun 2003 18:02:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12894; Tue, 24 Jun 2003 18:02:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Uvrd-0007d8-00; Tue, 24 Jun 2003 18:02:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19UvrY-0007d5-00; Tue, 24 Jun 2003 18:02:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UvrV-0000aN-5l; Tue, 24 Jun 2003 18:02:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Uvqj-0000ZV-7Y for simple@optimus.ietf.org; Tue, 24 Jun 2003 18:01: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 SAA12871 for ; Tue, 24 Jun 2003 18:01:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Uvqg-0007cd-00 for simple@ietf.org; Tue, 24 Jun 2003 18:01:10 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19UvqQ-0007cU-00 for simple@ietf.org; Tue, 24 Jun 2003 18:00:54 -0400 Received: from dynamicsoft.com ([63.113.46.124]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h5OLZJsm008920; Tue, 24 Jun 2003 17:35:22 -0400 (EDT) Message-ID: <3EF8C410.5030908@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dean Willis CC: "Mills, Duncan, D, CND Tech Dev, VF UK" , simple@ietf.org Subject: Re: [Simple] Sending 1 to n MESSAGEs References: <1056479824.2226.45.camel@bdsl.greycouncil.com> In-Reply-To: <1056479824.2226.45.camel@bdsl.greycouncil.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, 24 Jun 2003 17:35:12 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit inline. Dean Willis wrote: > Duncan pondered: > >>I've just been thinking about how my e-mail works, and what I like >>best about it. It is really easy to type a long message and then send >>it to a list of (more than one) people. Better still, I don't have to >>have pre-configured that list of people. I can just type in the >>addresses in the To: field and the mail will be sent to each address. > > > What if your application were to take care of the overhead of creating > and deleting the list for you? > > Scenario: > > 1) You enter multiple recpients in your GUI > 2) The UA creates a recipient list on your messaging server witha > temprary name > 3) The UA sends a message to the recipient list at the messaging server > 4) When the list hasn't been used for a while, the UA or server deletes > it. > > This is noce because it provides a chaching opportunity on dynamic lists > -- for example, if you send several messages to the same list, the list > of addresses has to be transferred only once over the "air interface". It depends. Do you want the recipients to know who else received the message? Email works this way. If so, each recipient now needs to pull the list from the server too. That introduces requirements for ACLs on the list (members can pull them), and potentially for inter-domain access to those lists, in the cases where members are in other domains. Thus, if you send to N recipients, thats N+1 transactions on the list - one to set it, N to fetch it. So, the extra overhead is multiplied N+1 times. Another interesting issue with group messaging is delivery confirmation. The 202 sent by the server, as suggested by Chris, works great to know that the exploder received the message. Do we have requirements that the sender can find out if the message was delivered to each recipient? IMHO, if we want to proceed here, we need to write some concrete requirements on what the desired service is, and therefore be certain that its different from what we can already do (i.e., conferencing with session mode) before delving into solutions. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Scientist 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 Jun 25 11:09: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 LAA14418; Wed, 25 Jun 2003 11:09: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 19VBtN-0007Vo-Dj; Wed, 25 Jun 2003 11:09:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VBpB-0006YL-Os for simple@optimus.ietf.org; Wed, 25 Jun 2003 11:04: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 KAA13328; Wed, 25 Jun 2003 10:55:05 -0400 (EDT) Message-Id: <200306251455.KAA13328@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-rpids-00.txt Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 25 Jun 2003 10:55:04 -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 : RPIDS -- Rich Presence Information Data Format for Presence Based on the Session Initiation Protocol(SIP) Author(s) : H. Schulzrinne Filename : draft-ietf-simple-rpids-00.txt Pages : 19 Date : 2003-6-24 The Rich Presence Information Data Format for the Session Initiation Protocol (SIP) (RPIDS) 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. The information is designed so that much of it can be derived automatically, e.g., from calendar files or user activity. The capabilities information is compatible with the caller preferences extensions to SIP, but does not depend on these. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-rpids-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-rpids-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-rpids-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-6-25103730.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-rpids-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-rpids-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-25103730.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Jun 25 11:10:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14502 for ; Wed, 25 Jun 2003 11:10:05 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5PF9dm29688 for simple-archive@odin.ietf.org; Wed, 25 Jun 2003 11: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 19VBtz-0007il-J4 for simple-web-archive@optimus.ietf.org; Wed, 25 Jun 2003 11:09:39 -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 LAA14418; Wed, 25 Jun 2003 11:09: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 19VBtN-0007Vo-Dj; Wed, 25 Jun 2003 11:09:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VBpB-0006YL-Os for simple@optimus.ietf.org; Wed, 25 Jun 2003 11:04: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 KAA13328; Wed, 25 Jun 2003 10:55:05 -0400 (EDT) Message-Id: <200306251455.KAA13328@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-rpids-00.txt Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 25 Jun 2003 10:55:04 -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 : RPIDS -- Rich Presence Information Data Format for Presence Based on the Session Initiation Protocol(SIP) Author(s) : H. Schulzrinne Filename : draft-ietf-simple-rpids-00.txt Pages : 19 Date : 2003-6-24 The Rich Presence Information Data Format for the Session Initiation Protocol (SIP) (RPIDS) 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. The information is designed so that much of it can be derived automatically, e.g., from calendar files or user activity. The capabilities information is compatible with the caller preferences extensions to SIP, but does not depend on these. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-rpids-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-rpids-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-rpids-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-6-25103730.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-rpids-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-rpids-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-25103730.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Jun 25 11:35:23 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 LAA15646; Wed, 25 Jun 2003 11:35:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VCIu-0004eH-00; Wed, 25 Jun 2003 11:35:24 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19VCIn-0004cb-00; Wed, 25 Jun 2003 11:35:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VCIb-0000wQ-FQ; Wed, 25 Jun 2003 11:35:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VBpC-0006YL-A1 for simple@optimus.ietf.org; Wed, 25 Jun 2003 11:04:42 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13312; Wed, 25 Jun 2003 10:55:00 -0400 (EDT) Message-Id: <200306251455.KAA13312@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-xcap-auth-usage-00.txt Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 25 Jun 2003 10:55:00 -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 : Extensible Markup Language (XML) Configuration Access Protocol (XCAP)Usages for Setting Presence Authorization Author(s) : J. Rosenberg Filename : draft-ietf-simple-xcap-auth-usage-00.txt Pages : 41 Date : 2003-6-24 This document describes three usages of the Extensible Markup Language (XML) Configuration Access Protocol (XCAP) that allow a client to provide authorization decisions regarding watchers of their presence. The first of these usages, called permission-statements, contains statements about what permissions are to be granted to watchers of presence. The second of these usages, called compound-permissions, allows a client to define new permissions as combinations of other defined permissions. The third usage, called supported-permissions, allows a client to determine what permissions are understood by the provider. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-auth-usage-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-xcap-auth-usage-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-xcap-auth-usage-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-6-25103715.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-xcap-auth-usage-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-xcap-auth-usage-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-25103715.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Jun 25 11:35:42 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 LAA15845; Wed, 25 Jun 2003 11:35:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VCJD-0004gh-00; Wed, 25 Jun 2003 11:35:43 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19VCJ6-0004dU-00; Wed, 25 Jun 2003 11:35:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VCIi-00017Q-VR; Wed, 25 Jun 2003 11:35:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VBso-0006YL-Dp for simple@optimus.ietf.org; Wed, 25 Jun 2003 11:08:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07248 for ; Wed, 25 Jun 2003 07:50:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19V8nS-0003Qj-00 for simple@ietf.org; Wed, 25 Jun 2003 07:50:42 -0400 Received: from igate2.vodafone.co.uk ([194.62.232.66]) by ietf-mx with esmtp (Exim 4.12) id 19V8nH-0003QJ-00 for simple@ietf.org; Wed, 25 Jun 2003 07:50:31 -0400 Received: by igate2.vodafone.co.uk; (8.8.8/1.3/10May95) id MAA02027; Wed, 25 Jun 2003 12:49:40 +0100 (BST) Received: from ukwmxc01.vf-uk.internal.vodafone.com (ukwmxc01 [10.33.126.160]) by mailguard3 (4.6.1.123) with ESMTP id ; Wed, 25 Jun 2003 12:50:25 +0100 Received: from ukwmxc04.vf-uk.internal.vodafone.com ([10.33.126.173]) by ukwmxc01.vf-uk.internal.vodafone.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 25 Jun 2003 12:49:32 +0100 Received: from ukwmxm02.vf-uk.internal.vodafone.com ([10.33.126.242]) by ukwmxc04.vf-uk.internal.vodafone.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 25 Jun 2003 12:49:32 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message Subject: RE: [Simple] Sending 1 to n MESSAGEs Message-ID: Thread-Topic: [Simple] Sending 1 to n MESSAGEs Thread-Index: AcM68VXuXgZ/drVLRxSnfhQ0yjpHMwAAc0TQ From: "Mills, Duncan, D, CND Tech Dev, VF UK" To: Cc: "Miguel A. Garcia" X-OriginalArrivalTime: 25 Jun 2003 11:49:32.0194 (UTC) FILETIME=[D776C820:01C33B0F] MIME-Version: 1.0 (Generated by Clearswift ES version 4.6.1.122) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 25 Jun 2003 12:49:30 +0100 Content-Transfer-Encoding: quoted-printable Hi, Ok, this seems like a good time to try to summarise the discussions so = far- whilst the US is asleep in bed ;-) ! (I'll regret that) 1.) I believe 1:n instant messaging can be achieved by setting up a = distribution list and giving it a resource-URI. QUESTION: Do we need to update 'draft-ietf-simple-event-list-04' to = include some messaging procedures, as currently it only seems to = consider presence? 2.) Is it enough to solve 1.) ? Do we need to alter/extend SIP to allow = a MESSAGE to be sent to more than one recipient without the need to set = up a recipient list on a server? I have heard several good arguments = for allowing a MESSAGE to be addressed towards several recipients = without pre-configuring a list: - Reducing the number of messages (particularly in wireless systems) - Reducing the time it takes the user to send such a message - More like e-mail There are also some issues related to any solution to 2.) that need to = be thought through: - Do recipients need to see who else received the message? - Do we need the sender to receive delivery confirmations? I'd like to encourage people to add to the two lists above (arguments = for doing something & open issues) in order that I can perhaps work on = some requirements. Discussing solutions at this stage is perhaps = premature... Best Regards, Duncan -----Original Message----- From: Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com] Sent: 25 June 2003 09:10 To: Mills, Duncan, D, CND Tech Dev, VF UK Cc: simple@ietf.org Subject: Re: [Simple] Sending 1 to n MESSAGEs Inline Mills, Duncan, D, CND Tech Dev, VF UK wrote: > Chris, >=20 > Yes, I think there are two cases here: >=20 > 1.) The ability to 'explode' MESSAGES to a 'distribution list' I would say that this issue is solve with a resource list. I don't = expect=20 resource lists to be related to presence only. But taking a look at=20 draft-ietf-simple-event-list-04 I see that it is considering only the=20 presence case. Does the WG think that there is space for generalization of the resource = list, so that it is possible to use it not only for presence, but also = for=20 Instant Messaging? >=20 > 2.) The ability to send the same MESSAGE to several people NOT on a = pre-configured distribution list (as Brian already pointed out, it would = be complex to expect users to have to log onto a server in the network = to set up a list every time) I believe SMTP and the Internet Message Format provides this capability, = although SIP does not provide it today (probably because of the initial=20 usage of SIP to establish point-to-point sessions). But I believe that when we apply SIP for Instant Messaging there is a = valid=20 use case that is worth investigating. My first thought on a possible solution would be to relax the = requirement=20 of having a single To header field value, and a server providing the = rest=20 of the functionality. Nothing new, just following RFC 2822. Of course, = we=20 get the problem of how to populate the Request-URI... >=20 > I believe that 1.) can already be overcome in the way that you = describe. Basically, in this case, the user DOES have to set up the = distribution list (a resource-URI) and send one MESSAGE to that list. >=20 > I am trying to solve case 2.) >=20 > Duncan >=20 /Miguel --=20 Miguel-Angel Garcia Oy LM Ericsson AB Jorvas, Finland mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 5140002 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Jun 25 11:35:54 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16016 for ; Wed, 25 Jun 2003 11:35:54 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5PFZRl05811 for simple-archive@odin.ietf.org; Wed, 25 Jun 2003 11:35:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VCIx-0001Vc-2g for simple-web-archive@optimus.ietf.org; Wed, 25 Jun 2003 11:35:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15646; Wed, 25 Jun 2003 11:35:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VCIu-0004eH-00; Wed, 25 Jun 2003 11:35:24 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19VCIn-0004cb-00; Wed, 25 Jun 2003 11:35:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VCIb-0000wQ-FQ; Wed, 25 Jun 2003 11:35:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VBpC-0006YL-A1 for simple@optimus.ietf.org; Wed, 25 Jun 2003 11:04:42 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13312; Wed, 25 Jun 2003 10:55:00 -0400 (EDT) Message-Id: <200306251455.KAA13312@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-xcap-auth-usage-00.txt Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 25 Jun 2003 10:55:00 -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 : Extensible Markup Language (XML) Configuration Access Protocol (XCAP)Usages for Setting Presence Authorization Author(s) : J. Rosenberg Filename : draft-ietf-simple-xcap-auth-usage-00.txt Pages : 41 Date : 2003-6-24 This document describes three usages of the Extensible Markup Language (XML) Configuration Access Protocol (XCAP) that allow a client to provide authorization decisions regarding watchers of their presence. The first of these usages, called permission-statements, contains statements about what permissions are to be granted to watchers of presence. The second of these usages, called compound-permissions, allows a client to define new permissions as combinations of other defined permissions. The third usage, called supported-permissions, allows a client to determine what permissions are understood by the provider. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-auth-usage-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-xcap-auth-usage-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-xcap-auth-usage-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-6-25103715.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-xcap-auth-usage-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-xcap-auth-usage-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-25103715.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Jun 25 11:35:57 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 LAA16054; Wed, 25 Jun 2003 11:35:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VCJS-0004hn-00; Wed, 25 Jun 2003 11:35:58 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19VCJM-0004hh-00; Wed, 25 Jun 2003 11:35:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VCJL-0001nD-Tx; Wed, 25 Jun 2003 11:35:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VBxm-0008Bp-4s for simple@optimus.ietf.org; Wed, 25 Jun 2003 11:13:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04432 for ; Wed, 25 Jun 2003 04:10:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19V5MR-0002iR-00 for simple@ietf.org; Wed, 25 Jun 2003 04:10:35 -0400 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49] helo=albatross.tn.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19V5MG-0002iN-00 for simple@ietf.org; Wed, 25 Jun 2003 04:10:24 -0400 Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by albatross.tn.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5P89sG5004840; Wed, 25 Jun 2003 10:09:54 +0200 (MEST) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LVYRMWFV; Wed, 25 Jun 2003 10:11:44 +0200 Received: from ericsson.com (3NJPI0013L1IJOG.lmf.ericsson.se [131.160.31.89]) by hendrix.lmf.ericsson.se (8.12.8/8.12.8/lmf-2.1-jcs) with ESMTP id h5P89bSZ001895; Wed, 25 Jun 2003 11:09:37 +0300 (EET DST) Message-ID: <3EF958D1.5060406@ericsson.com> X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Miguel A. Garcia" Organization: Ericsson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: es,en MIME-Version: 1.0 To: "Mills, Duncan, D, CND Tech Dev, VF UK" CC: simple@ietf.org Subject: Re: [Simple] Sending 1 to n MESSAGEs References: 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, 25 Jun 2003 11:09:53 +0300 Content-Transfer-Encoding: 7bit Inline Mills, Duncan, D, CND Tech Dev, VF UK wrote: > Chris, > > Yes, I think there are two cases here: > > 1.) The ability to 'explode' MESSAGES to a 'distribution list' I would say that this issue is solve with a resource list. I don't expect resource lists to be related to presence only. But taking a look at draft-ietf-simple-event-list-04 I see that it is considering only the presence case. Does the WG think that there is space for generalization of the resource list, so that it is possible to use it not only for presence, but also for Instant Messaging? > > 2.) The ability to send the same MESSAGE to several people NOT on a pre-configured distribution list (as Brian already pointed out, it would be complex to expect users to have to log onto a server in the network to set up a list every time) I believe SMTP and the Internet Message Format provides this capability, although SIP does not provide it today (probably because of the initial usage of SIP to establish point-to-point sessions). But I believe that when we apply SIP for Instant Messaging there is a valid use case that is worth investigating. My first thought on a possible solution would be to relax the requirement of having a single To header field value, and a server providing the rest of the functionality. Nothing new, just following RFC 2822. Of course, we get the problem of how to populate the Request-URI... > > I believe that 1.) can already be overcome in the way that you describe. Basically, in this case, the user DOES have to set up the distribution list (a resource-URI) and send one MESSAGE to that list. > > I am trying to solve case 2.) > > Duncan > /Miguel -- Miguel-Angel Garcia Oy LM Ericsson AB Jorvas, Finland mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 5140002 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Jun 25 11:36:19 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16165 for ; Wed, 25 Jun 2003 11:36:15 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5PFZlr06789 for simple-archive@odin.ietf.org; Wed, 25 Jun 2003 11:35:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VCJH-0001lQ-Gc for simple-web-archive@optimus.ietf.org; Wed, 25 Jun 2003 11:35:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15845; Wed, 25 Jun 2003 11:35:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VCJD-0004gh-00; Wed, 25 Jun 2003 11:35:43 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19VCJ6-0004dU-00; Wed, 25 Jun 2003 11:35:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VCIi-00017Q-VR; Wed, 25 Jun 2003 11:35:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VBso-0006YL-Dp for simple@optimus.ietf.org; Wed, 25 Jun 2003 11:08:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07248 for ; Wed, 25 Jun 2003 07:50:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19V8nS-0003Qj-00 for simple@ietf.org; Wed, 25 Jun 2003 07:50:42 -0400 Received: from igate2.vodafone.co.uk ([194.62.232.66]) by ietf-mx with esmtp (Exim 4.12) id 19V8nH-0003QJ-00 for simple@ietf.org; Wed, 25 Jun 2003 07:50:31 -0400 Received: by igate2.vodafone.co.uk; (8.8.8/1.3/10May95) id MAA02027; Wed, 25 Jun 2003 12:49:40 +0100 (BST) Received: from ukwmxc01.vf-uk.internal.vodafone.com (ukwmxc01 [10.33.126.160]) by mailguard3 (4.6.1.123) with ESMTP id ; Wed, 25 Jun 2003 12:50:25 +0100 Received: from ukwmxc04.vf-uk.internal.vodafone.com ([10.33.126.173]) by ukwmxc01.vf-uk.internal.vodafone.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 25 Jun 2003 12:49:32 +0100 Received: from ukwmxm02.vf-uk.internal.vodafone.com ([10.33.126.242]) by ukwmxc04.vf-uk.internal.vodafone.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 25 Jun 2003 12:49:32 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message Subject: RE: [Simple] Sending 1 to n MESSAGEs Message-ID: Thread-Topic: [Simple] Sending 1 to n MESSAGEs Thread-Index: AcM68VXuXgZ/drVLRxSnfhQ0yjpHMwAAc0TQ From: "Mills, Duncan, D, CND Tech Dev, VF UK" To: Cc: "Miguel A. Garcia" X-OriginalArrivalTime: 25 Jun 2003 11:49:32.0194 (UTC) FILETIME=[D776C820:01C33B0F] MIME-Version: 1.0 (Generated by Clearswift ES version 4.6.1.122) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 25 Jun 2003 12:49:30 +0100 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi, Ok, this seems like a good time to try to summarise the discussions so = far- whilst the US is asleep in bed ;-) ! (I'll regret that) 1.) I believe 1:n instant messaging can be achieved by setting up a = distribution list and giving it a resource-URI. QUESTION: Do we need to update 'draft-ietf-simple-event-list-04' to = include some messaging procedures, as currently it only seems to = consider presence? 2.) Is it enough to solve 1.) ? Do we need to alter/extend SIP to allow = a MESSAGE to be sent to more than one recipient without the need to set = up a recipient list on a server? I have heard several good arguments = for allowing a MESSAGE to be addressed towards several recipients = without pre-configuring a list: - Reducing the number of messages (particularly in wireless systems) - Reducing the time it takes the user to send such a message - More like e-mail There are also some issues related to any solution to 2.) that need to = be thought through: - Do recipients need to see who else received the message? - Do we need the sender to receive delivery confirmations? I'd like to encourage people to add to the two lists above (arguments = for doing something & open issues) in order that I can perhaps work on = some requirements. Discussing solutions at this stage is perhaps = premature... Best Regards, Duncan -----Original Message----- From: Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com] Sent: 25 June 2003 09:10 To: Mills, Duncan, D, CND Tech Dev, VF UK Cc: simple@ietf.org Subject: Re: [Simple] Sending 1 to n MESSAGEs Inline Mills, Duncan, D, CND Tech Dev, VF UK wrote: > Chris, >=20 > Yes, I think there are two cases here: >=20 > 1.) The ability to 'explode' MESSAGES to a 'distribution list' I would say that this issue is solve with a resource list. I don't = expect=20 resource lists to be related to presence only. But taking a look at=20 draft-ietf-simple-event-list-04 I see that it is considering only the=20 presence case. Does the WG think that there is space for generalization of the resource = list, so that it is possible to use it not only for presence, but also = for=20 Instant Messaging? >=20 > 2.) The ability to send the same MESSAGE to several people NOT on a = pre-configured distribution list (as Brian already pointed out, it would = be complex to expect users to have to log onto a server in the network = to set up a list every time) I believe SMTP and the Internet Message Format provides this capability, = although SIP does not provide it today (probably because of the initial=20 usage of SIP to establish point-to-point sessions). But I believe that when we apply SIP for Instant Messaging there is a = valid=20 use case that is worth investigating. My first thought on a possible solution would be to relax the = requirement=20 of having a single To header field value, and a server providing the = rest=20 of the functionality. Nothing new, just following RFC 2822. Of course, = we=20 get the problem of how to populate the Request-URI... >=20 > I believe that 1.) can already be overcome in the way that you = describe. Basically, in this case, the user DOES have to set up the = distribution list (a resource-URI) and send one MESSAGE to that list. >=20 > I am trying to solve case 2.) >=20 > Duncan >=20 /Miguel --=20 Miguel-Angel Garcia Oy LM Ericsson AB Jorvas, Finland mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 5140002 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Jun 25 11:36: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 LAA16257; Wed, 25 Jun 2003 11:36: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 19VCJW-00024x-Fv; Wed, 25 Jun 2003 11:36:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VBxg-0008Cz-DI for simple@optimus.ietf.org; Wed, 25 Jun 2003 11:13:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05035 for ; Wed, 25 Jun 2003 04:47:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19V5vk-0002rT-00 for simple@ietf.org; Wed, 25 Jun 2003 04:47:04 -0400 Received: from igate2.vodafone.co.uk ([194.62.232.66]) by ietf-mx with esmtp (Exim 4.12) id 19V5vZ-0002r6-00 for simple@ietf.org; Wed, 25 Jun 2003 04:46:53 -0400 Received: by igate2.vodafone.co.uk; (8.8.8/1.3/10May95) id JAA12744; Wed, 25 Jun 2003 09:45:53 +0100 (BST) Received: from ukwmxc02.vf-uk.internal.vodafone.com (ukwmxc02 [10.33.126.170]) by mailguard2 (4.6.1.123) with ESMTP id ; Wed, 25 Jun 2003 09:43:10 +0100 Received: from ukwmxc04.vf-uk.internal.vodafone.com ([10.33.126.173]) by ukwmxc02.vf-uk.internal.vodafone.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 25 Jun 2003 09:45:18 +0100 Received: from ukwmxm02.vf-uk.internal.vodafone.com ([10.33.126.242]) by ukwmxc04.vf-uk.internal.vodafone.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 25 Jun 2003 09:45:18 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message Subject: RE: [Simple] Sending 1 to n MESSAGEs Message-ID: Thread-Topic: [Simple] Sending 1 to n MESSAGEs Thread-Index: AcM68VXuXgZ/drVLRxSnfhQ0yjpHMwAAc0TQ From: "Mills, Duncan, D, CND Tech Dev, VF UK" To: Cc: "Miguel A. Garcia" X-OriginalArrivalTime: 25 Jun 2003 08:45:18.0132 (UTC) FILETIME=[1ABAC740:01C33AF6] MIME-Version: 1.0 (Generated by Clearswift ES version 4.6.1.122) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 25 Jun 2003 09:45:16 +0100 Content-Transfer-Encoding: quoted-printable Hi, Ok, this seems like a good time to try to summarise the discussions so = far- whilst the US is asleep in bed ;-) ! (I'll regret that) 1.) I believe 1:n instant messaging can be achieved by setting up a = distribution list and giving it a resource-URI. QUESTION: Do we need to update 'draft-ietf-simple-event-list-04' to = include some messaging procedures, as currently it only seems to = consider presence? 2.) Is it enough to solve 1.) ? Do we need to alter/extend SIP to allow = a MESSAGE to be sent to more than one recipient without the need to set = up a recipient list on a server? I have heard several good arguments = for allowing a MESSAGE to be addressed towards several recipients = without pre-configuring a list: - Reducing the number of messages (particularly in wireless systems) - Reducing the time it takes the user to send such a message - More like e-mail There are also some issues related to any solution to 2.) that need to = be thought through: - Do recipients need to see who else received the message? - Do we need the sender to receive delivery confirmations? I'd like to encourage people to add to the two lists above (arguments = for doing something & open issues) in order that I can perhaps work on = some requirements. Discussing solutions at this stage is perhaps = premature... Best Regards, Duncan -----Original Message----- From: Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com] Sent: 25 June 2003 09:10 To: Mills, Duncan, D, CND Tech Dev, VF UK Cc: simple@ietf.org Subject: Re: [Simple] Sending 1 to n MESSAGEs Inline Mills, Duncan, D, CND Tech Dev, VF UK wrote: > Chris, >=20 > Yes, I think there are two cases here: >=20 > 1.) The ability to 'explode' MESSAGES to a 'distribution list' I would say that this issue is solve with a resource list. I don't = expect=20 resource lists to be related to presence only. But taking a look at=20 draft-ietf-simple-event-list-04 I see that it is considering only the=20 presence case. Does the WG think that there is space for generalization of the resource = list, so that it is possible to use it not only for presence, but also = for=20 Instant Messaging? >=20 > 2.) The ability to send the same MESSAGE to several people NOT on a = pre-configured distribution list (as Brian already pointed out, it would = be complex to expect users to have to log onto a server in the network = to set up a list every time) I believe SMTP and the Internet Message Format provides this capability, = although SIP does not provide it today (probably because of the initial=20 usage of SIP to establish point-to-point sessions). But I believe that when we apply SIP for Instant Messaging there is a = valid=20 use case that is worth investigating. My first thought on a possible solution would be to relax the = requirement=20 of having a single To header field value, and a server providing the = rest=20 of the functionality. Nothing new, just following RFC 2822. Of course, = we=20 get the problem of how to populate the Request-URI... >=20 > I believe that 1.) can already be overcome in the way that you = describe. Basically, in this case, the user DOES have to set up the = distribution list (a resource-URI) and send one MESSAGE to that list. >=20 > I am trying to solve case 2.) >=20 > Duncan >=20 /Miguel --=20 Miguel-Angel Garcia Oy LM Ericsson AB Jorvas, Finland mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 5140002 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Jun 25 11:45:26 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 LAA17199; Wed, 25 Jun 2003 11:45:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VCSA-0005Qc-M6; Wed, 25 Jun 2003 11:44:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VByX-0008Bp-Fn for simple@optimus.ietf.org; Wed, 25 Jun 2003 11:14:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06415 for ; Wed, 25 Jun 2003 01:40:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19V315-00028y-00 for simple@ietf.org; Wed, 25 Jun 2003 01:40:23 -0400 Received: from il-tlv-firewall-main.icomverse.com ([192.118.48.248] helo=il-tlv-smtpout2.icomverse.com) by ietf-mx with esmtp (Exim 4.12) id 19V30u-00028t-00 for simple@ietf.org; Wed, 25 Jun 2003 01:40:12 -0400 Received: from il-tlv-mbdg2.comverse.com (localhost.localdomain [127.0.0.1]) by il-tlv-smtpout2.icomverse.com (8.11.6/8.11.6) with ESMTP id h5P5ckG25131; Wed, 25 Jun 2003 08:38:50 +0300 X-Authentication-Warning: il-tlv-smtpout2.icomverse.com: iscan owned process doing -bs Received: by il-tlv-mbdg2.comverse.com with Internet Mail Service (5.5.2655.55) id ; Wed, 25 Jun 2003 08:38:50 +0300 Message-ID: <385D702A9C11D511A9E90008C7160AD50545446E@ISMAIL1> From: Cnaan Oded To: "'Jonathan Rosenberg'" , Dean Willis Cc: "Mills, Duncan, D, CND Tech Dev, VF UK" , simple@ietf.org Subject: RE: [Simple] Sending 1 to n MESSAGEs MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C33ADC.0DB2CD46" 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, 25 Jun 2003 08:38:49 +0300 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C33ADC.0DB2CD46 Content-Type: text/plain; charset="iso-8859-1" Inline > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Wednesday, June 25, 2003 12:35 AM > To: Dean Willis > Cc: Mills, Duncan, D, CND Tech Dev, VF UK; simple@ietf.org > Subject: Re: [Simple] Sending 1 to n MESSAGEs > > > It depends. Do you want the recipients to know who else received the > message? Email works this way. If so, each recipient now > needs to pull > the list from the server too. That introduces requirements > for ACLs on > the list (members can pull them), and potentially for inter-domain > access to those lists, in the cases where members are in other > domains. Thus, if you send to N recipients, thats N+1 transactions on > the list - one to set it, N to fetch it. So, the extra overhead is > multiplied N+1 times. > Right. Besides that, instant messaging is all about the immediacy of message delivery and this extra transaction doesn't serve this purpose. You would probably use an HTTP connection to set up the group, and, especially on mobile networks, this can take some time. Another issue to consider is the multi-recipient message behavior. With email, the list of recipients is sent to everybody (except for Bcc) so that a 'reply-to-all' is allowed. However, this causes a spam problem as people cannot remove themselves from these lists and will continue to receive messages as long as someone replies to the message. We can think of two modes of operation suitable for IM: (1) conversation - where the mesage includes the recipients list and replies go to the entire list (To, CC like) or (2) 1:many messaging - where the message includes only the sender and replies are sent only to him (Bcc like). > Another interesting issue with group messaging is delivery > confirmation. The 202 sent by the server, as suggested by > Chris, works > great to know that the exploder received the message. Do we have > requirements that the sender can find out if the message was > delivered > to each recipient? > > IMHO, if we want to proceed here, we need to write some concrete > requirements on what the desired service is, and therefore be certain > that its different from what we can already do (i.e., conferencing > with session mode) before delving into solutions. > I agree that a delivery report mechanism should be separate from SIP acknowledgements. A user may not require a delivery report on each message he sends (like with SMS and Email) and in the usual case may suffice with having the proxy indicate that the message has been received and handled (202). > -Jonathan R. > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Scientist 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 > ------_=_NextPart_001_01C33ADC.0DB2CD46 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Simple] Sending 1 to n MESSAGEs

Inline

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> Sent: Wednesday, June 25, 2003 12:35 AM
> To: Dean Willis
> Cc: Mills, Duncan, D, CND Tech Dev, VF UK; = simple@ietf.org
> Subject: Re: [Simple] Sending 1 to n = MESSAGEs
>
>
> It depends. Do you want the recipients to know = who else received the
> message? Email works this way. If so, each = recipient now
> needs to pull
> the list from the server too. That introduces = requirements
> for ACLs on
> the list (members can pull them), and = potentially for inter-domain
> access to those lists, in the cases where = members are in other
> domains. Thus, if you send to N recipients, = thats N+1 transactions on
> the list - one to set it, N to fetch it.  = So, the extra overhead is
> multiplied N+1 times.
>

Right. Besides that, instant messaging is all about = the immediacy of message delivery and this extra transaction doesn't = serve this purpose. You would probably use an HTTP connection to set up = the group, and, especially on mobile networks, this can take some = time.

Another issue to consider is the multi-recipient = message behavior. With email, the list of recipients is sent to = everybody (except for Bcc) so that a 'reply-to-all' is allowed. = However, this causes a spam problem as people cannot remove themselves = from these lists and will continue to receive messages as long as = someone replies to the message.

We can think of two modes of operation suitable for = IM: (1) conversation - where the mesage includes the recipients list = and replies go to the entire list (To, CC like) or (2) 1:many messaging = - where the message includes only the sender and replies are sent only = to him (Bcc like).

> Another interesting issue with group messaging = is delivery
> confirmation. The 202 sent by the server, as = suggested by
> Chris, works
> great to know that the exploder received the = message. Do we have
> requirements that the sender can find out if = the message was
> delivered
> to each recipient?
>
> IMHO, if we want to proceed here, we need to = write some concrete
> requirements on what the desired service is, = and therefore be certain
> that its different from what we can already do = (i.e., conferencing
> with session mode) before delving into = solutions.
>

I agree that a delivery report mechanism should be = separate from SIP acknowledgements. A user may not require a delivery = report on each message he sends (like with SMS and Email) and in the = usual case may suffice with having the proxy indicate that the message = has been received and handled (202).

> -Jonathan R.
>
> --
> Jonathan D. Rosenberg, = Ph.D.           &= nbsp;    600 Lanidex Plaza
> Chief = Scientist          &nb= sp;           &nb= sp;      Parsippany, NJ 07054-2711
> dynamicsoft
> = jdrosen@dynamicsoft.com        &= nbsp;            = FAX:   (973) 952-5050
> http://www.jdrosen.net    &nbs= p;           &nbs= p;     PHONE: (973) 952-5000
> http://www.dynamicsoft.com
>
>
> = _______________________________________________
> Simple mailing list
> Simple@ietf.org
> https://www1.ietf.org/mailman/listinfo/simple
>

------_=_NextPart_001_01C33ADC.0DB2CD46-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Jun 25 11:45:49 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 LAA17349; Wed, 25 Jun 2003 11:45:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VCSS-0005oN-8P; Wed, 25 Jun 2003 11:45:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VBzQ-0007wP-3L for simple@optimus.ietf.org; Wed, 25 Jun 2003 11:15:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02369 for ; Tue, 24 Jun 2003 21:47:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UzNK-0001NT-00 for simple@ietf.org; Tue, 24 Jun 2003 21:47:06 -0400 Received: from web41502.mail.yahoo.com ([66.218.93.85]) by ietf-mx with smtp (Exim 4.12) id 19UzNA-0001Mv-00 for simple@ietf.org; Tue, 24 Jun 2003 21:46:56 -0400 Message-ID: <20030625014545.28000.qmail@web41502.mail.yahoo.com> Received: from [207.46.228.31] by web41502.mail.yahoo.com via HTTP; Tue, 24 Jun 2003 18:45:45 PDT From: Sean Olson To: adam@dynamicsoft.com, simple@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Simple] draft-roach-simple-blconf-00 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, 24 Jun 2003 18:45:45 -0700 (PDT) This is a problem that should be solved. I don't like the -buddies option I don't like requiring support for device configuration to get this to work, especially since that will usually be a separate operation from buddy list configuration. I think there is a third option that should be considered. Use the user's URI as the buddy list URI and indicate through a Event: parameter that the buddy list is the intended target and not the user. This has the implication that routing of these requests will generally follow the same path as subscribing to that user's presence. SUBSCRIBE sip:adam@pres.example.com SIP/2.0 To: From: ;tag=ie4hbb8t Call-ID: cdB34qLToC@terminal.example.com CSeq: 322723822 SUBSCRIBE Contact: Event: presence ; contactlist Expires: 7200 Require: eventlist Accept: application/cpim-pidf+xml Accept: application/rlmi+xml Accept: multipart/related Accept: multipart/signed Accept: multipart/encrypted my two cents Sean __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Jun 25 12:06: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 MAA19077; Wed, 25 Jun 2003 12:06: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 19VCmY-000173-Aq; Wed, 25 Jun 2003 12:06:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VCmS-00016J-AD for simple@optimus.ietf.org; Wed, 25 Jun 2003 12:05: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 MAA19046 for ; Wed, 25 Jun 2003 12:05:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VCmS-000503-00 for simple@ietf.org; Wed, 25 Jun 2003 12:05:56 -0400 Received: from marionberry.cc.columbia.edu ([128.59.59.100] ident=cu41754) by ietf-mx with esmtp (Exim 4.12) id 19VCmC-0004yb-00 for simple@ietf.org; Wed, 25 Jun 2003 12:05:40 -0400 Received: from cs.columbia.edu (dhcp39.cs.columbia.edu [128.59.19.239]) (user=hgs10 mech=PLAIN bits=0) by marionberry.cc.columbia.edu (8.12.8p1/8.12.8) with ESMTP id h5PG225U004705 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 25 Jun 2003 12:02:03 -0400 (EDT) Message-ID: <3EF9C774.1000008@cs.columbia.edu> From: Henning Schulzrinne 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 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.32 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: 7bit Subject: [Simple] New RPIDS draft Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 25 Jun 2003 12:01:56 -0400 Content-Transfer-Encoding: 7bit The new draft-ietf-simple-rpids-00 draft was just announced. These are the major changes: - temporarily removed the capabilities description until we figure out how to handle this, both technically (I'd like a cleaner syntax that is more similar to the other properties) and procedurally (we don't want to get delayed indefinitely by the glacial progress of caller-preferences) - added a 'class' attribute that allows semantic labeling of tuples, similar to how 'class' is used in HTML; - took the BINPIDF (draft-lonnfors-simple-binpidf-00) ideas and re-shaped them a bit to be more semantically focused, i.e., focus on content, not on the fact that it is an external reference. I defined elements that roughly correspond to the Call-Info items in SIP and hopefully address many of the applications sought for external linking. I didn't get a chance to incorporate some of the 'what's a tuple' discussions yet, but I suspect they require some high-bandwidth discussions in Vienna in any event. Comments are most welcome. Henning _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Jun 25 12:07:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19125 for ; Wed, 25 Jun 2003 12:07:04 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5PG6aN04758 for simple-archive@odin.ietf.org; Wed, 25 Jun 2003 12:06:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VCn6-0001Ef-0j for simple-web-archive@optimus.ietf.org; Wed, 25 Jun 2003 12:06:36 -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 MAA19077; Wed, 25 Jun 2003 12:06: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 19VCmY-000173-Aq; Wed, 25 Jun 2003 12:06:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VCmS-00016J-AD for simple@optimus.ietf.org; Wed, 25 Jun 2003 12:05: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 MAA19046 for ; Wed, 25 Jun 2003 12:05:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VCmS-000503-00 for simple@ietf.org; Wed, 25 Jun 2003 12:05:56 -0400 Received: from marionberry.cc.columbia.edu ([128.59.59.100] ident=cu41754) by ietf-mx with esmtp (Exim 4.12) id 19VCmC-0004yb-00 for simple@ietf.org; Wed, 25 Jun 2003 12:05:40 -0400 Received: from cs.columbia.edu (dhcp39.cs.columbia.edu [128.59.19.239]) (user=hgs10 mech=PLAIN bits=0) by marionberry.cc.columbia.edu (8.12.8p1/8.12.8) with ESMTP id h5PG225U004705 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 25 Jun 2003 12:02:03 -0400 (EDT) Message-ID: <3EF9C774.1000008@cs.columbia.edu> From: Henning Schulzrinne 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 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.32 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: 7bit Subject: [Simple] New RPIDS draft Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 25 Jun 2003 12:01:56 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit The new draft-ietf-simple-rpids-00 draft was just announced. These are the major changes: - temporarily removed the capabilities description until we figure out how to handle this, both technically (I'd like a cleaner syntax that is more similar to the other properties) and procedurally (we don't want to get delayed indefinitely by the glacial progress of caller-preferences) - added a 'class' attribute that allows semantic labeling of tuples, similar to how 'class' is used in HTML; - took the BINPIDF (draft-lonnfors-simple-binpidf-00) ideas and re-shaped them a bit to be more semantically focused, i.e., focus on content, not on the fact that it is an external reference. I defined elements that roughly correspond to the Call-Info items in SIP and hopefully address many of the applications sought for external linking. I didn't get a chance to incorporate some of the 'what's a tuple' discussions yet, but I suspect they require some high-bandwidth discussions in Vienna in any event. Comments are most welcome. Henning _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Jun 25 12:22:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16259 for ; Wed, 25 Jun 2003 11:36:30 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5PFa2e08037 for simple-archive@odin.ietf.org; Wed, 25 Jun 2003 11:36:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VCJW-00025U-Ps for simple-web-archive@optimus.ietf.org; Wed, 25 Jun 2003 11:36:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16054; Wed, 25 Jun 2003 11:35:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VCJS-0004hn-00; Wed, 25 Jun 2003 11:35:58 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19VCJM-0004hh-00; Wed, 25 Jun 2003 11:35:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VCJL-0001nD-Tx; Wed, 25 Jun 2003 11:35:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VBxm-0008Bp-4s for simple@optimus.ietf.org; Wed, 25 Jun 2003 11:13:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04432 for ; Wed, 25 Jun 2003 04:10:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19V5MR-0002iR-00 for simple@ietf.org; Wed, 25 Jun 2003 04:10:35 -0400 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49] helo=albatross.tn.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19V5MG-0002iN-00 for simple@ietf.org; Wed, 25 Jun 2003 04:10:24 -0400 Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by albatross.tn.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5P89sG5004840; Wed, 25 Jun 2003 10:09:54 +0200 (MEST) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LVYRMWFV; Wed, 25 Jun 2003 10:11:44 +0200 Received: from ericsson.com (3NJPI0013L1IJOG.lmf.ericsson.se [131.160.31.89]) by hendrix.lmf.ericsson.se (8.12.8/8.12.8/lmf-2.1-jcs) with ESMTP id h5P89bSZ001895; Wed, 25 Jun 2003 11:09:37 +0300 (EET DST) Message-ID: <3EF958D1.5060406@ericsson.com> X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Miguel A. Garcia" Organization: Ericsson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: es,en MIME-Version: 1.0 To: "Mills, Duncan, D, CND Tech Dev, VF UK" CC: simple@ietf.org Subject: Re: [Simple] Sending 1 to n MESSAGEs References: 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, 25 Jun 2003 11:09:53 +0300 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Inline Mills, Duncan, D, CND Tech Dev, VF UK wrote: > Chris, > > Yes, I think there are two cases here: > > 1.) The ability to 'explode' MESSAGES to a 'distribution list' I would say that this issue is solve with a resource list. I don't expect resource lists to be related to presence only. But taking a look at draft-ietf-simple-event-list-04 I see that it is considering only the presence case. Does the WG think that there is space for generalization of the resource list, so that it is possible to use it not only for presence, but also for Instant Messaging? > > 2.) The ability to send the same MESSAGE to several people NOT on a pre-configured distribution list (as Brian already pointed out, it would be complex to expect users to have to log onto a server in the network to set up a list every time) I believe SMTP and the Internet Message Format provides this capability, although SIP does not provide it today (probably because of the initial usage of SIP to establish point-to-point sessions). But I believe that when we apply SIP for Instant Messaging there is a valid use case that is worth investigating. My first thought on a possible solution would be to relax the requirement of having a single To header field value, and a server providing the rest of the functionality. Nothing new, just following RFC 2822. Of course, we get the problem of how to populate the Request-URI... > > I believe that 1.) can already be overcome in the way that you describe. Basically, in this case, the user DOES have to set up the distribution list (a resource-URI) and send one MESSAGE to that list. > > I am trying to solve case 2.) > > Duncan > /Miguel -- Miguel-Angel Garcia Oy LM Ericsson AB Jorvas, Finland mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 5140002 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Jun 25 12:25:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20017 for ; Wed, 25 Jun 2003 12:25:45 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5PGPIp09306 for simple-archive@odin.ietf.org; Wed, 25 Jun 2003 12:25:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VCTJ-0006F7-Hx for simple-web-archive@optimus.ietf.org; Wed, 25 Jun 2003 11:46:09 -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 LAA17349; Wed, 25 Jun 2003 11:45:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VCSS-0005oN-8P; Wed, 25 Jun 2003 11:45:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VBzQ-0007wP-3L for simple@optimus.ietf.org; Wed, 25 Jun 2003 11:15:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02369 for ; Tue, 24 Jun 2003 21:47:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UzNK-0001NT-00 for simple@ietf.org; Tue, 24 Jun 2003 21:47:06 -0400 Received: from web41502.mail.yahoo.com ([66.218.93.85]) by ietf-mx with smtp (Exim 4.12) id 19UzNA-0001Mv-00 for simple@ietf.org; Tue, 24 Jun 2003 21:46:56 -0400 Message-ID: <20030625014545.28000.qmail@web41502.mail.yahoo.com> Received: from [207.46.228.31] by web41502.mail.yahoo.com via HTTP; Tue, 24 Jun 2003 18:45:45 PDT From: Sean Olson To: adam@dynamicsoft.com, simple@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Simple] draft-roach-simple-blconf-00 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, 24 Jun 2003 18:45:45 -0700 (PDT) This is a problem that should be solved. I don't like the -buddies option I don't like requiring support for device configuration to get this to work, especially since that will usually be a separate operation from buddy list configuration. I think there is a third option that should be considered. Use the user's URI as the buddy list URI and indicate through a Event: parameter that the buddy list is the intended target and not the user. This has the implication that routing of these requests will generally follow the same path as subscribing to that user's presence. SUBSCRIBE sip:adam@pres.example.com SIP/2.0 To: From: ;tag=ie4hbb8t Call-ID: cdB34qLToC@terminal.example.com CSeq: 322723822 SUBSCRIBE Contact: Event: presence ; contactlist Expires: 7200 Require: eventlist Accept: application/cpim-pidf+xml Accept: application/rlmi+xml Accept: multipart/related Accept: multipart/signed Accept: multipart/encrypted my two cents Sean __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Jun 25 12:26:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20091 for ; Wed, 25 Jun 2003 12:26:55 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5PGQRb09408 for simple-archive@odin.ietf.org; Wed, 25 Jun 2003 12:26:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VD6J-0002P1-45 for simple-web-archive@optimus.ietf.org; Wed, 25 Jun 2003 12:26:27 -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 LAA16257; Wed, 25 Jun 2003 11:36: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 19VCJW-00024x-Fv; Wed, 25 Jun 2003 11:36:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VBxg-0008Cz-DI for simple@optimus.ietf.org; Wed, 25 Jun 2003 11:13:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05035 for ; Wed, 25 Jun 2003 04:47:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19V5vk-0002rT-00 for simple@ietf.org; Wed, 25 Jun 2003 04:47:04 -0400 Received: from igate2.vodafone.co.uk ([194.62.232.66]) by ietf-mx with esmtp (Exim 4.12) id 19V5vZ-0002r6-00 for simple@ietf.org; Wed, 25 Jun 2003 04:46:53 -0400 Received: by igate2.vodafone.co.uk; (8.8.8/1.3/10May95) id JAA12744; Wed, 25 Jun 2003 09:45:53 +0100 (BST) Received: from ukwmxc02.vf-uk.internal.vodafone.com (ukwmxc02 [10.33.126.170]) by mailguard2 (4.6.1.123) with ESMTP id ; Wed, 25 Jun 2003 09:43:10 +0100 Received: from ukwmxc04.vf-uk.internal.vodafone.com ([10.33.126.173]) by ukwmxc02.vf-uk.internal.vodafone.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 25 Jun 2003 09:45:18 +0100 Received: from ukwmxm02.vf-uk.internal.vodafone.com ([10.33.126.242]) by ukwmxc04.vf-uk.internal.vodafone.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 25 Jun 2003 09:45:18 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message Subject: RE: [Simple] Sending 1 to n MESSAGEs Message-ID: Thread-Topic: [Simple] Sending 1 to n MESSAGEs Thread-Index: AcM68VXuXgZ/drVLRxSnfhQ0yjpHMwAAc0TQ From: "Mills, Duncan, D, CND Tech Dev, VF UK" To: Cc: "Miguel A. Garcia" X-OriginalArrivalTime: 25 Jun 2003 08:45:18.0132 (UTC) FILETIME=[1ABAC740:01C33AF6] MIME-Version: 1.0 (Generated by Clearswift ES version 4.6.1.122) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 25 Jun 2003 09:45:16 +0100 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi, Ok, this seems like a good time to try to summarise the discussions so = far- whilst the US is asleep in bed ;-) ! (I'll regret that) 1.) I believe 1:n instant messaging can be achieved by setting up a = distribution list and giving it a resource-URI. QUESTION: Do we need to update 'draft-ietf-simple-event-list-04' to = include some messaging procedures, as currently it only seems to = consider presence? 2.) Is it enough to solve 1.) ? Do we need to alter/extend SIP to allow = a MESSAGE to be sent to more than one recipient without the need to set = up a recipient list on a server? I have heard several good arguments = for allowing a MESSAGE to be addressed towards several recipients = without pre-configuring a list: - Reducing the number of messages (particularly in wireless systems) - Reducing the time it takes the user to send such a message - More like e-mail There are also some issues related to any solution to 2.) that need to = be thought through: - Do recipients need to see who else received the message? - Do we need the sender to receive delivery confirmations? I'd like to encourage people to add to the two lists above (arguments = for doing something & open issues) in order that I can perhaps work on = some requirements. Discussing solutions at this stage is perhaps = premature... Best Regards, Duncan -----Original Message----- From: Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com] Sent: 25 June 2003 09:10 To: Mills, Duncan, D, CND Tech Dev, VF UK Cc: simple@ietf.org Subject: Re: [Simple] Sending 1 to n MESSAGEs Inline Mills, Duncan, D, CND Tech Dev, VF UK wrote: > Chris, >=20 > Yes, I think there are two cases here: >=20 > 1.) The ability to 'explode' MESSAGES to a 'distribution list' I would say that this issue is solve with a resource list. I don't = expect=20 resource lists to be related to presence only. But taking a look at=20 draft-ietf-simple-event-list-04 I see that it is considering only the=20 presence case. Does the WG think that there is space for generalization of the resource = list, so that it is possible to use it not only for presence, but also = for=20 Instant Messaging? >=20 > 2.) The ability to send the same MESSAGE to several people NOT on a = pre-configured distribution list (as Brian already pointed out, it would = be complex to expect users to have to log onto a server in the network = to set up a list every time) I believe SMTP and the Internet Message Format provides this capability, = although SIP does not provide it today (probably because of the initial=20 usage of SIP to establish point-to-point sessions). But I believe that when we apply SIP for Instant Messaging there is a = valid=20 use case that is worth investigating. My first thought on a possible solution would be to relax the = requirement=20 of having a single To header field value, and a server providing the = rest=20 of the functionality. Nothing new, just following RFC 2822. Of course, = we=20 get the problem of how to populate the Request-URI... >=20 > I believe that 1.) can already be overcome in the way that you = describe. Basically, in this case, the user DOES have to set up the = distribution list (a resource-URI) and send one MESSAGE to that list. >=20 > I am trying to solve case 2.) >=20 > Duncan >=20 /Miguel --=20 Miguel-Angel Garcia Oy LM Ericsson AB Jorvas, Finland mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 5140002 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Jun 25 14:37:11 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 OAA24521; Wed, 25 Jun 2003 14:37:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VF7q-0005z4-00; Wed, 25 Jun 2003 14:36:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19VF7l-0005z1-00; Wed, 25 Jun 2003 14:36:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VF7i-0000bU-7u; Wed, 25 Jun 2003 14:36:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VF7C-0000ar-53 for simple@optimus.ietf.org; Wed, 25 Jun 2003 14:35: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 OAA24469 for ; Wed, 25 Jun 2003 14:35:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VF7A-0005ye-00 for simple@ietf.org; Wed, 25 Jun 2003 14:35:28 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by ietf-mx with esmtp (Exim 4.12) id 19VF6u-0005wH-00 for simple@ietf.org; Wed, 25 Jun 2003 14:35:13 -0400 Received: from cannon.cisco.com (IDENT:mirapoint@cannon.cisco.com [161.44.118.24]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h5PIUKai023407; Wed, 25 Jun 2003 14:30:21 -0400 (EDT) Received: from cisco.com ([161.44.79.70]) by cannon.cisco.com (Mirapoint) with ESMTP id ABL72386; Wed, 25 Jun 2003 14:39:18 -0400 (EDT) Message-ID: <3EF9EA3C.10904@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: "Rosen, Brian" CC: "'Mills, Duncan, D, CND Tech Dev, VF UK'" , simple@ietf.org Subject: Re: [Simple] Sending 1 to n MESSAGEs References: <313680C9A886D511A06000204840E1CF070B5B2A@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by rtp-core-1.cisco.com id h5PIUKai023407 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: Wed, 25 Jun 2003 14:30:20 -0400 Content-Transfer-Encoding: quoted-printable It should at least be technically possible to do the explosion in a=20 proxy rather than a B2BUA. If you address the message to an exploder,=20 and include the actual list of intended recipients as another header,=20 the exploder can act as a proxy, forking the message to each of the=20 intended recipients. Done this way, the sender will receive a response from each recipient,=20 which may be good in some cases. If you only want a single response, then the exploder can act as a=20 B2BUA. It could even choose to act one way or the other depending on=20 some parameter in the request. Either way, the exploder can either leave the list of recipients in the=20 message for the ultimate recipients to see, or remove it. That is=20 another option or policy. Paul Rosen, Brian wrote: > Was the salutation to your message a comment on the quality of > the discourse on this list? ;) =20 >=20 > Good thought. Interacts with conferencing (mass invite to a conference= ). > You don't want to have to have a complex interaction prior to sending > a list of recipients. Smells like a kind of forking behavior, but=20 > clearly different (not all the same AOR). Obviously creates multiple > dialogs if/when multiple responses are received. The proxy can't be > the origination point; it's not a UA. All the responses are going to > be forwarded to the UA. The only way around that is B2BUA behavior. > Is that a better, or a worse idea? >=20 > Gotta think through what this means for Message Sessions. You want the > proxy to replicate each message, but you don't really want to repeat > the list of recipients. Does that argue for B2BUA more strongly? >=20 > With a B2BUA approach you send the message to the exploder. It > sends individual messages to recipients, and handles all the dialogs. > That reminds me of a buddy list subscription without the prearranged=20 > buddy list. >=20 > Brian >=20 >=20 >>-----Original Message----- >>From: Mills, Duncan, D, CND Tech Dev, VF UK >>[mailto:Duncan.Mills@gb.vodafone.co.uk] >>Sent: Tuesday, June 24, 2003 9:42 AM >>To: simple@ietf.org >>Subject: [Simple] Sending 1 to n MESSAGEs >> >> >>SIMPLE people, >> >>I've just been thinking about how my e-mail works, and what I=20 >>like best about it. It is really easy to type a long message=20 >>and then send it to a list of (more than one) people. Better=20 >>still, I don't have to have pre-configured that list of=20 >>people. I can just type in the addresses in the To: field=20 >>and the mail will be sent to each address. >> >>As far as I know, I can't do this with the SIP MESSAGE=20 >>method. Yes, I can create a resource URI in a server and=20 >>send one MESSAGE request to that resource-URI, and the server=20 >>may fork the MESSAGE to each URI in my pre-configured list. =20 >>But if I don't want to have to set up a new list of=20 >>recipients each time I send a MESSAGE then I have to send the=20 >>same MESSAGE several times. Please correct me if I'm wrong. >> >>Now... looking at this from a wireless operator perspective,=20 >>I immediately see warning signs about my =A36 billion radio=20 >>interface ;-) Currently, in GSM, if we want to send an SMS=20 >>to more 'n' recipients, we have the same situation- either=20 >>create a user group in the network or send the message 'n'=20 >>times. However, a SIP MESSAGE request is likely to be about=20 >>ten times the size of an SMS. >> >>Is this a problem? If not, why not? Maybe I'm missing some=20 >>background/historical information? >> >>If it is a problem, might it be possible to extend SIP in=20 >>such a way as to state that the request-URI be set to the=20 >>address of my SIP proxy server in my home network and then=20 >>the To: field be filled with the list of intended recipients,=20 >>with the server then being responsible for sending the=20 >>MESSAGE to all the intended recipients? >> >>Any comments/views? >> >>Best Regards, >> >>Duncan >> >> >>Duncan Mills >>Senior Engineer >>Network Standards & Technical Audit >>Technology Development (Network Systems) >>Vodafone (UK) Ltd >>Tel: +44 (0)1635 676074 >>Mob: +44 7867 900955 >>Fax: +44 (0)1635 234445 >>mailto:duncan.mills@vf.vodafone.co.uk >> >> >> >>_______________________________________________ >>Simple mailing list >>Simple@ietf.org >>https://www1.ietf.org/mailman/listinfo/simple >> >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Jun 25 14:37:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24603 for ; Wed, 25 Jun 2003 14:37:43 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5PIbF803255 for simple-archive@odin.ietf.org; Wed, 25 Jun 2003 14:37:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VF8t-0000qQ-2B for simple-web-archive@optimus.ietf.org; Wed, 25 Jun 2003 14:37:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24521; Wed, 25 Jun 2003 14:37:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VF7q-0005z4-00; Wed, 25 Jun 2003 14:36:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19VF7l-0005z1-00; Wed, 25 Jun 2003 14:36:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VF7i-0000bU-7u; Wed, 25 Jun 2003 14:36:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VF7C-0000ar-53 for simple@optimus.ietf.org; Wed, 25 Jun 2003 14:35: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 OAA24469 for ; Wed, 25 Jun 2003 14:35:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VF7A-0005ye-00 for simple@ietf.org; Wed, 25 Jun 2003 14:35:28 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by ietf-mx with esmtp (Exim 4.12) id 19VF6u-0005wH-00 for simple@ietf.org; Wed, 25 Jun 2003 14:35:13 -0400 Received: from cannon.cisco.com (IDENT:mirapoint@cannon.cisco.com [161.44.118.24]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h5PIUKai023407; Wed, 25 Jun 2003 14:30:21 -0400 (EDT) Received: from cisco.com ([161.44.79.70]) by cannon.cisco.com (Mirapoint) with ESMTP id ABL72386; Wed, 25 Jun 2003 14:39:18 -0400 (EDT) Message-ID: <3EF9EA3C.10904@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: "Rosen, Brian" CC: "'Mills, Duncan, D, CND Tech Dev, VF UK'" , simple@ietf.org Subject: Re: [Simple] Sending 1 to n MESSAGEs References: <313680C9A886D511A06000204840E1CF070B5B2A@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by rtp-core-1.cisco.com id h5PIUKai023407 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: Wed, 25 Jun 2003 14:30:20 -0400 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable It should at least be technically possible to do the explosion in a=20 proxy rather than a B2BUA. If you address the message to an exploder,=20 and include the actual list of intended recipients as another header,=20 the exploder can act as a proxy, forking the message to each of the=20 intended recipients. Done this way, the sender will receive a response from each recipient,=20 which may be good in some cases. If you only want a single response, then the exploder can act as a=20 B2BUA. It could even choose to act one way or the other depending on=20 some parameter in the request. Either way, the exploder can either leave the list of recipients in the=20 message for the ultimate recipients to see, or remove it. That is=20 another option or policy. Paul Rosen, Brian wrote: > Was the salutation to your message a comment on the quality of > the discourse on this list? ;) =20 >=20 > Good thought. Interacts with conferencing (mass invite to a conference= ). > You don't want to have to have a complex interaction prior to sending > a list of recipients. Smells like a kind of forking behavior, but=20 > clearly different (not all the same AOR). Obviously creates multiple > dialogs if/when multiple responses are received. The proxy can't be > the origination point; it's not a UA. All the responses are going to > be forwarded to the UA. The only way around that is B2BUA behavior. > Is that a better, or a worse idea? >=20 > Gotta think through what this means for Message Sessions. You want the > proxy to replicate each message, but you don't really want to repeat > the list of recipients. Does that argue for B2BUA more strongly? >=20 > With a B2BUA approach you send the message to the exploder. It > sends individual messages to recipients, and handles all the dialogs. > That reminds me of a buddy list subscription without the prearranged=20 > buddy list. >=20 > Brian >=20 >=20 >>-----Original Message----- >>From: Mills, Duncan, D, CND Tech Dev, VF UK >>[mailto:Duncan.Mills@gb.vodafone.co.uk] >>Sent: Tuesday, June 24, 2003 9:42 AM >>To: simple@ietf.org >>Subject: [Simple] Sending 1 to n MESSAGEs >> >> >>SIMPLE people, >> >>I've just been thinking about how my e-mail works, and what I=20 >>like best about it. It is really easy to type a long message=20 >>and then send it to a list of (more than one) people. Better=20 >>still, I don't have to have pre-configured that list of=20 >>people. I can just type in the addresses in the To: field=20 >>and the mail will be sent to each address. >> >>As far as I know, I can't do this with the SIP MESSAGE=20 >>method. Yes, I can create a resource URI in a server and=20 >>send one MESSAGE request to that resource-URI, and the server=20 >>may fork the MESSAGE to each URI in my pre-configured list. =20 >>But if I don't want to have to set up a new list of=20 >>recipients each time I send a MESSAGE then I have to send the=20 >>same MESSAGE several times. Please correct me if I'm wrong. >> >>Now... looking at this from a wireless operator perspective,=20 >>I immediately see warning signs about my =A36 billion radio=20 >>interface ;-) Currently, in GSM, if we want to send an SMS=20 >>to more 'n' recipients, we have the same situation- either=20 >>create a user group in the network or send the message 'n'=20 >>times. However, a SIP MESSAGE request is likely to be about=20 >>ten times the size of an SMS. >> >>Is this a problem? If not, why not? Maybe I'm missing some=20 >>background/historical information? >> >>If it is a problem, might it be possible to extend SIP in=20 >>such a way as to state that the request-URI be set to the=20 >>address of my SIP proxy server in my home network and then=20 >>the To: field be filled with the list of intended recipients,=20 >>with the server then being responsible for sending the=20 >>MESSAGE to all the intended recipients? >> >>Any comments/views? >> >>Best Regards, >> >>Duncan >> >> >>Duncan Mills >>Senior Engineer >>Network Standards & Technical Audit >>Technology Development (Network Systems) >>Vodafone (UK) Ltd >>Tel: +44 (0)1635 676074 >>Mob: +44 7867 900955 >>Fax: +44 (0)1635 234445 >>mailto:duncan.mills@vf.vodafone.co.uk >> >> >> >>_______________________________________________ >>Simple mailing list >>Simple@ietf.org >>https://www1.ietf.org/mailman/listinfo/simple >> >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Jun 25 16:05: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 QAA29275; Wed, 25 Jun 2003 16:05:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VGVv-00079F-00; Wed, 25 Jun 2003 16:05:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19VGVp-00079C-00; Wed, 25 Jun 2003 16:05:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VGVo-00062I-W3; Wed, 25 Jun 2003 16:05:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VGU7-0005sB-AM for simple@optimus.ietf.org; Wed, 25 Jun 2003 16:04:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28914 for ; Wed, 25 Jun 2003 16:03:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VGNz-0006yj-00 for simple@ietf.org; Wed, 25 Jun 2003 15:56:55 -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 19VGNo-0006yI-00 for simple@ietf.org; Wed, 25 Jun 2003 15:56:44 -0400 Received: from cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 25 Jun 2003 12:55:25 -0800 Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h5PJtpgE014674; Wed, 25 Jun 2003 12:55:52 -0700 (PDT) Received: from mhammer-w2k03.cisco.com (dhcp-hrn-64-100-229-140.cisco.com [64.100.229.140]) by fruitpie.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AEW89964; Wed, 25 Jun 2003 12:55:50 -0700 (PDT) Message-Id: <4.3.2.7.2.20030625152623.00b2f3b0@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Cnaan Oded From: Michael Hammer Subject: RE: [Simple] Sending 1 to n MESSAGEs Cc: "'Jonathan Rosenberg'" , Dean Willis , "Mills, Duncan, D, CND Tech Dev, VF UK" , simple@ietf.org In-Reply-To: <385D702A9C11D511A9E90008C7160AD50545446E@ISMAIL1> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_23290990==_.ALT" 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, 25 Jun 2003 15:55:49 -0400 --=====================_23290990==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 08:38 AM 6/25/2003 +0300, Cnaan Oded wrote: >Another issue to consider is the multi-recipient message behavior. With >email, the list of recipients is sent to everybody (except for Bcc) so >that a 'reply-to-all' is allowed. However, this causes a spam problem as >people cannot remove themselves from these lists and will continue to >receive messages as long as someone replies to the message. Should such multi-recipient MESSAGEs be sent within a session to which a recipient could say BYE, future messages to the rejected session get silently discarded? Or, seems like you would need to have an anti-dote header (X-Recipient-Remove-Me:) and a corresponding "Reply-All-Remove-Me" GUI button, that upon receipt could be handled without presentation by each recipient to trim the list. Mike --=====================_23290990==_.ALT Content-Type: text/html; charset="us-ascii" At 08:38 AM 6/25/2003 +0300, Cnaan Oded wrote:
Another issue to consider is the multi-recipient message behavior. With email, the list of recipients is sent to everybody (except for Bcc) so that a 'reply-to-all' is allowed. However, this causes a spam problem as people cannot remove themselves from these lists and will continue to receive messages as long as someone replies to the message.

Should such multi-recipient MESSAGEs be sent within a session to which a recipient could say BYE, future messages to the rejected session get silently discarded?

Or, seems like you would need to have an anti-dote header (X-Recipient-Remove-Me:) and a corresponding "Reply-All-Remove-Me" GUI button, that upon receipt could be handled without presentation by each recipient to trim the list.

Mike


 --=====================_23290990==_.ALT-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Jun 25 16:05:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29338 for ; Wed, 25 Jun 2003 16:05:51 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5PK5Nh23455 for simple-archive@odin.ietf.org; Wed, 25 Jun 2003 16:05:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VGWB-00066E-R7 for simple-web-archive@optimus.ietf.org; Wed, 25 Jun 2003 16:05: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 QAA29275; Wed, 25 Jun 2003 16:05:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VGVv-00079F-00; Wed, 25 Jun 2003 16:05:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19VGVp-00079C-00; Wed, 25 Jun 2003 16:05:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VGVo-00062I-W3; Wed, 25 Jun 2003 16:05:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VGU7-0005sB-AM for simple@optimus.ietf.org; Wed, 25 Jun 2003 16:04:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28914 for ; Wed, 25 Jun 2003 16:03:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VGNz-0006yj-00 for simple@ietf.org; Wed, 25 Jun 2003 15:56:55 -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 19VGNo-0006yI-00 for simple@ietf.org; Wed, 25 Jun 2003 15:56:44 -0400 Received: from cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 25 Jun 2003 12:55:25 -0800 Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h5PJtpgE014674; Wed, 25 Jun 2003 12:55:52 -0700 (PDT) Received: from mhammer-w2k03.cisco.com (dhcp-hrn-64-100-229-140.cisco.com [64.100.229.140]) by fruitpie.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AEW89964; Wed, 25 Jun 2003 12:55:50 -0700 (PDT) Message-Id: <4.3.2.7.2.20030625152623.00b2f3b0@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Cnaan Oded From: Michael Hammer Subject: RE: [Simple] Sending 1 to n MESSAGEs Cc: "'Jonathan Rosenberg'" , Dean Willis , "Mills, Duncan, D, CND Tech Dev, VF UK" , simple@ietf.org In-Reply-To: <385D702A9C11D511A9E90008C7160AD50545446E@ISMAIL1> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_23290990==_.ALT" 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, 25 Jun 2003 15:55:49 -0400 --=====================_23290990==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 08:38 AM 6/25/2003 +0300, Cnaan Oded wrote: >Another issue to consider is the multi-recipient message behavior. With >email, the list of recipients is sent to everybody (except for Bcc) so >that a 'reply-to-all' is allowed. However, this causes a spam problem as >people cannot remove themselves from these lists and will continue to >receive messages as long as someone replies to the message. Should such multi-recipient MESSAGEs be sent within a session to which a recipient could say BYE, future messages to the rejected session get silently discarded? Or, seems like you would need to have an anti-dote header (X-Recipient-Remove-Me:) and a corresponding "Reply-All-Remove-Me" GUI button, that upon receipt could be handled without presentation by each recipient to trim the list. Mike --=====================_23290990==_.ALT Content-Type: text/html; charset="us-ascii" At 08:38 AM 6/25/2003 +0300, Cnaan Oded wrote:
Another issue to consider is the multi-recipient message behavior. With email, the list of recipients is sent to everybody (except for Bcc) so that a 'reply-to-all' is allowed. However, this causes a spam problem as people cannot remove themselves from these lists and will continue to receive messages as long as someone replies to the message.

Should such multi-recipient MESSAGEs be sent within a session to which a recipient could say BYE, future messages to the rejected session get silently discarded?

Or, seems like you would need to have an anti-dote header (X-Recipient-Remove-Me:) and a corresponding "Reply-All-Remove-Me" GUI button, that upon receipt could be handled without presentation by each recipient to trim the list.

Mike


 --=====================_23290990==_.ALT-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Jun 25 20:50:08 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 UAA15674; Wed, 25 Jun 2003 20:50:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VKxk-0003Hq-00; Wed, 25 Jun 2003 20:50:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19VKxf-0003Hm-00; Wed, 25 Jun 2003 20:50:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VKxd-0005MJ-1u; Wed, 25 Jun 2003 20:50:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VKx7-0005KU-Av for simple@optimus.ietf.org; Wed, 25 Jun 2003 20:49: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 UAA15652 for ; Wed, 25 Jun 2003 20:49:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VKx4-0003HG-00 for simple@ietf.org; Wed, 25 Jun 2003 20:49:26 -0400 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 19VKwu-0003Gl-00 for simple@ietf.org; Wed, 25 Jun 2003 20:49:16 -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 h5Q0lUxk016271; Wed, 25 Jun 2003 20:47:35 -0400 (EDT) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 25 Jun 2003 19:47:30 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E8619F@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'Paul Kyzivat'" , "Rosen, Brian" Cc: "'Mills, Duncan, D, CND Tech Dev, VF UK'" , simple@ietf.org Subject: RE: [Simple] Sending 1 to n MESSAGEs 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: Wed, 25 Jun 2003 18:10:38 -0500 Paul Kyzivat [mailto:pkyzivat@cisco.com] writes: > It should at least be technically possible to do the explosion in a > proxy rather than a B2BUA. If you address the message to an exploder, > and include the actual list of intended recipients as another header, > the exploder can act as a proxy, forking the message to each of the > intended recipients. > > Done this way, the sender will receive a response from each > recipient... Sorry, but no. Double-check proxy handling of forked messages in 3261. For non-INVITE messages, you will receive only one response (except in extremely rare and spectacular failure scenarios). Even for INVITE messages, you'll receive more than one response only in the case of certain race conditions (and even then, you'll only get 200-class responses, possibly preceded by a single 600-class response). [Yes, I'm not counting provisionals] /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Jun 25 20:50:08 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 UAA15675; Wed, 25 Jun 2003 20:50:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VKxk-0003Ht-00; Wed, 25 Jun 2003 20:50:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19VKxf-0003Hn-00; Wed, 25 Jun 2003 20:50:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VKxd-0005MR-Cp; Wed, 25 Jun 2003 20:50:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VKx1-0005KT-1n for simple@optimus.ietf.org; Wed, 25 Jun 2003 20:49:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15630 for ; Wed, 25 Jun 2003 20:49:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VKwj-0003Gx-00 for simple@ietf.org; Wed, 25 Jun 2003 20:49:05 -0400 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 19VKwY-0003Gb-00 for simple@ietf.org; Wed, 25 Jun 2003 20:48:54 -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 h5Q0lUxk016272; Wed, 25 Jun 2003 20:47:30 -0400 (EDT) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 25 Jun 2003 19:47:30 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E861A0@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'Michael Hammer'" , Cnaan Oded Cc: Jonathan Rosenberg , Dean Willis , "Mills, Duncan, D, CND Tech Dev, VF UK" , simple@ietf.org Subject: RE: [Simple] Sending 1 to n MESSAGEs 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: Wed, 25 Jun 2003 18:16:34 -0500 So, you mean you want to have a *session* that clients can be invited to and leave? http://www.ietf.org/internet-drafts/draft-ietf-simple-message-sessions-00.tx t And you want the ability to have multiparty IMs in that session? Cool. I'll see you at the XCON bof. /a -----Original Message----- From: Michael Hammer [mailto:mhammer@cisco.com] Sent: Wednesday, June 25, 2003 14:56 To: Cnaan Oded Cc: 'Jonathan Rosenberg'; Dean Willis; Mills, Duncan, D, CND Tech Dev, VF UK; simple@ietf.org Subject: RE: [Simple] Sending 1 to n MESSAGEs At 08:38 AM 6/25/2003 +0300, Cnaan Oded wrote: Another issue to consider is the multi-recipient message behavior. With email, the list of recipients is sent to everybody (except for Bcc) so that a 'reply-to-all' is allowed. However, this causes a spam problem as people cannot remove themselves from these lists and will continue to receive messages as long as someone replies to the message. Should such multi-recipient MESSAGEs be sent within a session to which a recipient could say BYE, future messages to the rejected session get silently discarded? Or, seems like you would need to have an anti-dote header (X-Recipient-Remove-Me:) and a corresponding "Reply-All-Remove-Me" GUI button, that upon receipt could be handled without presentation by each recipient to trim the list. Mike _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Jun 25 20:50:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15722 for ; Wed, 25 Jun 2003 20:50:45 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5Q0oIn20930 for simple-archive@odin.ietf.org; Wed, 25 Jun 2003 20: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 19VKxt-0005RV-S4 for simple-web-archive@optimus.ietf.org; Wed, 25 Jun 2003 20:50:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15674; Wed, 25 Jun 2003 20:50:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VKxk-0003Hq-00; Wed, 25 Jun 2003 20:50:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19VKxf-0003Hm-00; Wed, 25 Jun 2003 20:50:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VKxd-0005MJ-1u; Wed, 25 Jun 2003 20:50:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VKx7-0005KU-Av for simple@optimus.ietf.org; Wed, 25 Jun 2003 20:49: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 UAA15652 for ; Wed, 25 Jun 2003 20:49:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VKx4-0003HG-00 for simple@ietf.org; Wed, 25 Jun 2003 20:49:26 -0400 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 19VKwu-0003Gl-00 for simple@ietf.org; Wed, 25 Jun 2003 20:49:16 -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 h5Q0lUxk016271; Wed, 25 Jun 2003 20:47:35 -0400 (EDT) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 25 Jun 2003 19:47:30 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E8619F@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'Paul Kyzivat'" , "Rosen, Brian" Cc: "'Mills, Duncan, D, CND Tech Dev, VF UK'" , simple@ietf.org Subject: RE: [Simple] Sending 1 to n MESSAGEs 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: Wed, 25 Jun 2003 18:10:38 -0500 Paul Kyzivat [mailto:pkyzivat@cisco.com] writes: > It should at least be technically possible to do the explosion in a > proxy rather than a B2BUA. If you address the message to an exploder, > and include the actual list of intended recipients as another header, > the exploder can act as a proxy, forking the message to each of the > intended recipients. > > Done this way, the sender will receive a response from each > recipient... Sorry, but no. Double-check proxy handling of forked messages in 3261. For non-INVITE messages, you will receive only one response (except in extremely rare and spectacular failure scenarios). Even for INVITE messages, you'll receive more than one response only in the case of certain race conditions (and even then, you'll only get 200-class responses, possibly preceded by a single 600-class response). [Yes, I'm not counting provisionals] /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Jun 25 20:50:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15724 for ; Wed, 25 Jun 2003 20:50:48 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5Q0oL420949 for simple-archive@odin.ietf.org; Wed, 25 Jun 2003 20:50:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VKxx-0005Ro-1P for simple-web-archive@optimus.ietf.org; Wed, 25 Jun 2003 20:50:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15675; Wed, 25 Jun 2003 20:50:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VKxk-0003Ht-00; Wed, 25 Jun 2003 20:50:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19VKxf-0003Hn-00; Wed, 25 Jun 2003 20:50:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VKxd-0005MR-Cp; Wed, 25 Jun 2003 20:50:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VKx1-0005KT-1n for simple@optimus.ietf.org; Wed, 25 Jun 2003 20:49:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15630 for ; Wed, 25 Jun 2003 20:49:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VKwj-0003Gx-00 for simple@ietf.org; Wed, 25 Jun 2003 20:49:05 -0400 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 19VKwY-0003Gb-00 for simple@ietf.org; Wed, 25 Jun 2003 20:48:54 -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 h5Q0lUxk016272; Wed, 25 Jun 2003 20:47:30 -0400 (EDT) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 25 Jun 2003 19:47:30 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E861A0@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'Michael Hammer'" , Cnaan Oded Cc: Jonathan Rosenberg , Dean Willis , "Mills, Duncan, D, CND Tech Dev, VF UK" , simple@ietf.org Subject: RE: [Simple] Sending 1 to n MESSAGEs 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: Wed, 25 Jun 2003 18:16:34 -0500 So, you mean you want to have a *session* that clients can be invited to and leave? http://www.ietf.org/internet-drafts/draft-ietf-simple-message-sessions-00.tx t And you want the ability to have multiparty IMs in that session? Cool. I'll see you at the XCON bof. /a -----Original Message----- From: Michael Hammer [mailto:mhammer@cisco.com] Sent: Wednesday, June 25, 2003 14:56 To: Cnaan Oded Cc: 'Jonathan Rosenberg'; Dean Willis; Mills, Duncan, D, CND Tech Dev, VF UK; simple@ietf.org Subject: RE: [Simple] Sending 1 to n MESSAGEs At 08:38 AM 6/25/2003 +0300, Cnaan Oded wrote: Another issue to consider is the multi-recipient message behavior. With email, the list of recipients is sent to everybody (except for Bcc) so that a 'reply-to-all' is allowed. However, this causes a spam problem as people cannot remove themselves from these lists and will continue to receive messages as long as someone replies to the message. Should such multi-recipient MESSAGEs be sent within a session to which a recipient could say BYE, future messages to the rejected session get silently discarded? Or, seems like you would need to have an anti-dote header (X-Recipient-Remove-Me:) and a corresponding "Reply-All-Remove-Me" GUI button, that upon receipt could be handled without presentation by each recipient to trim the list. Mike _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Jun 25 20:51: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 UAA15753; Wed, 25 Jun 2003 20:51:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VKye-0003II-00; Wed, 25 Jun 2003 20:51:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19VKyZ-0003IF-00; Wed, 25 Jun 2003 20:50:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VKya-0005Xj-Ur; Wed, 25 Jun 2003 20:51:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VKxE-0005LV-0Z for simple@optimus.ietf.org; Wed, 25 Jun 2003 20:50: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 UAA15659 for ; Wed, 25 Jun 2003 20:49:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VKxB-0003HO-00 for simple@ietf.org; Wed, 25 Jun 2003 20:49:33 -0400 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 19VKx0-0003Gs-00 for simple@ietf.org; Wed, 25 Jun 2003 20:49:22 -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 h5Q0lWxk016273; Wed, 25 Jun 2003 20:47:37 -0400 (EDT) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 25 Jun 2003 19:47:32 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E861A1@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'Mills, Duncan, D, CND Tech Dev, VF UK'" , simple@ietf.org Cc: "Miguel A. Garcia" Subject: RE: [Simple] Sending 1 to n MESSAGEs 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: Wed, 25 Jun 2003 19:01:21 -0500 Duncan Mills writes: > 1.) I believe 1:n instant messaging can be achieved by > setting up a distribution list and giving it a resource-URI. > > QUESTION: Do we need to update > 'draft-ietf-simple-event-list-04' to include some messaging > procedures, as currently it only seems to consider presence? I think the problems are completely separable. Keep in mind that the URI that you subscribe to with the event-list extension semantically represents a group of resources. If the server that allows you to subscribe to an event-list can *also* receive MESSAGEs sent to that URI and explode them to all the resources on the list, that's something that it's perfectly okay to do. If it wants to accept INVITEs sent to that URI and set up a centrally controlled multiparty session, that's also something that's perfectly fine, and kind of spiffy. But that kind of binding really needs to remain an implementation decision. I don't think we gain anything by having a standards document -- even a BCP -- that describes such a property. Bottom line: you can come up with fairly reasonable semantics for just about any SIP request sent to a group resource URI (and, in many cases, you can come up with several useful semantics for the same method). Holding up event-lists until we define this sort of thing for all existing methods would not be realistic. And, even if we decided to do so, the event-list document will be outdated as soon as a new method is defined. > 2.) Is it enough to solve 1.) ? Do we need to alter/extend > SIP to allow a MESSAGE to be sent to more than one recipient > without the need to set up a recipient list on a server? I > have heard several good arguments for allowing a MESSAGE to > be addressed towards several recipients without > pre-configuring a list: > > - Reducing the number of messages (particularly in wireless systems) > - Reducing the time it takes the user to send such a message As Dean points out, the *protocol* can semantically: 1) upload the list membership, PUT http://xcap.example.com/s/im/users/12145551212/t1 HTTP/1.1 Content-Type:application/foo+xml sip:bob@example.com sip:joe@example.com sip:ed@example.com 2) send the message, MESSAGE sip:t1@bl.examples.com SIP/2.0 3) and optionally destroy the list. DELETE http://xcap.example.com/s/im/users/12145551212/t1 HTTP/1.1 ...all without the user ever being aware of what's going on. The experience is the *same* as e-mail: the user types in a list of recipients and a message, and the message is sent to those recipients. > - More like e-mail The primary fallacy in comparing MESSAGEs to e-mail is that e-mail necessarily uses SMTP servers that perform the explosion that we're talking about. With SIMPLE, signaling can go directly from one party to the other. > There are also some issues related to any solution to 2.) > that need to be thought through: > > - Do recipients need to see who else received the message? The answer to this will be "yes," "no," and "we need ACLs," depending on who in this working group decides to answer. > - Do we need the sender to receive delivery confirmations? Message receipt confirmation is something that's been on our list of things to do for some time now. The charter addresses this as, "Included might be new mechanisms for message confirmation delivery". I think this probably is completely separable from the multiple recipients problem. As a related issue, you'll need to address the situation in which an IM is sent to a group, and one such member is offline. Imagine that this offline member has a message store that will play back missed messages when he comes back online (cf. current SMS usage). If the online recipients decide to respond to the message in such a way that the response is sent to all the original recipients, and a rather lengthy conversation ensues, the offline user is in for an annoying torrent of messages -- probably stale -- when he finally comes back online. It's been brought up already, but I feel it is important enough to reiterate: once you start doing *group* messaging, you *really* want ways to invite users into the group session, and for them to have the ability to accept or decline, and to leave once they are no longer interested in the conversation. (In fact, I would argue that this is one of the most glaring shortcomings of current e-mail systems; how many times have you seen an e-mail begging, "please remove my e-mail address from this discussion!"?) This points squarely at the use of MESSAGE sessions instead of pager-mode messages. I would argue that any of the other models proposed in this thread go so far in emulating e-mail as to repeat its most annoying flaws. /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Jun 25 20:51:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15788 for ; Wed, 25 Jun 2003 20:51:37 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5Q0pA021448 for simple-archive@odin.ietf.org; Wed, 25 Jun 2003 20:51:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VKyk-0005Zr-EX for simple-web-archive@optimus.ietf.org; Wed, 25 Jun 2003 20:51:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15753; Wed, 25 Jun 2003 20:51:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VKye-0003II-00; Wed, 25 Jun 2003 20:51:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19VKyZ-0003IF-00; Wed, 25 Jun 2003 20:50:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VKya-0005Xj-Ur; Wed, 25 Jun 2003 20:51:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VKxE-0005LV-0Z for simple@optimus.ietf.org; Wed, 25 Jun 2003 20:50: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 UAA15659 for ; Wed, 25 Jun 2003 20:49:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VKxB-0003HO-00 for simple@ietf.org; Wed, 25 Jun 2003 20:49:33 -0400 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 19VKx0-0003Gs-00 for simple@ietf.org; Wed, 25 Jun 2003 20:49:22 -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 h5Q0lWxk016273; Wed, 25 Jun 2003 20:47:37 -0400 (EDT) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 25 Jun 2003 19:47:32 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E861A1@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'Mills, Duncan, D, CND Tech Dev, VF UK'" , simple@ietf.org Cc: "Miguel A. Garcia" Subject: RE: [Simple] Sending 1 to n MESSAGEs 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: Wed, 25 Jun 2003 19:01:21 -0500 Duncan Mills writes: > 1.) I believe 1:n instant messaging can be achieved by > setting up a distribution list and giving it a resource-URI. > > QUESTION: Do we need to update > 'draft-ietf-simple-event-list-04' to include some messaging > procedures, as currently it only seems to consider presence? I think the problems are completely separable. Keep in mind that the URI that you subscribe to with the event-list extension semantically represents a group of resources. If the server that allows you to subscribe to an event-list can *also* receive MESSAGEs sent to that URI and explode them to all the resources on the list, that's something that it's perfectly okay to do. If it wants to accept INVITEs sent to that URI and set up a centrally controlled multiparty session, that's also something that's perfectly fine, and kind of spiffy. But that kind of binding really needs to remain an implementation decision. I don't think we gain anything by having a standards document -- even a BCP -- that describes such a property. Bottom line: you can come up with fairly reasonable semantics for just about any SIP request sent to a group resource URI (and, in many cases, you can come up with several useful semantics for the same method). Holding up event-lists until we define this sort of thing for all existing methods would not be realistic. And, even if we decided to do so, the event-list document will be outdated as soon as a new method is defined. > 2.) Is it enough to solve 1.) ? Do we need to alter/extend > SIP to allow a MESSAGE to be sent to more than one recipient > without the need to set up a recipient list on a server? I > have heard several good arguments for allowing a MESSAGE to > be addressed towards several recipients without > pre-configuring a list: > > - Reducing the number of messages (particularly in wireless systems) > - Reducing the time it takes the user to send such a message As Dean points out, the *protocol* can semantically: 1) upload the list membership, PUT http://xcap.example.com/s/im/users/12145551212/t1 HTTP/1.1 Content-Type:application/foo+xml sip:bob@example.com sip:joe@example.com sip:ed@example.com 2) send the message, MESSAGE sip:t1@bl.examples.com SIP/2.0 3) and optionally destroy the list. DELETE http://xcap.example.com/s/im/users/12145551212/t1 HTTP/1.1 ...all without the user ever being aware of what's going on. The experience is the *same* as e-mail: the user types in a list of recipients and a message, and the message is sent to those recipients. > - More like e-mail The primary fallacy in comparing MESSAGEs to e-mail is that e-mail necessarily uses SMTP servers that perform the explosion that we're talking about. With SIMPLE, signaling can go directly from one party to the other. > There are also some issues related to any solution to 2.) > that need to be thought through: > > - Do recipients need to see who else received the message? The answer to this will be "yes," "no," and "we need ACLs," depending on who in this working group decides to answer. > - Do we need the sender to receive delivery confirmations? Message receipt confirmation is something that's been on our list of things to do for some time now. The charter addresses this as, "Included might be new mechanisms for message confirmation delivery". I think this probably is completely separable from the multiple recipients problem. As a related issue, you'll need to address the situation in which an IM is sent to a group, and one such member is offline. Imagine that this offline member has a message store that will play back missed messages when he comes back online (cf. current SMS usage). If the online recipients decide to respond to the message in such a way that the response is sent to all the original recipients, and a rather lengthy conversation ensues, the offline user is in for an annoying torrent of messages -- probably stale -- when he finally comes back online. It's been brought up already, but I feel it is important enough to reiterate: once you start doing *group* messaging, you *really* want ways to invite users into the group session, and for them to have the ability to accept or decline, and to leave once they are no longer interested in the conversation. (In fact, I would argue that this is one of the most glaring shortcomings of current e-mail systems; how many times have you seen an e-mail begging, "please remove my e-mail address from this discussion!"?) This points squarely at the use of MESSAGE sessions instead of pager-mode messages. I would argue that any of the other models proposed in this thread go so far in emulating e-mail as to repeat its most annoying flaws. /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Jun 25 21:56:07 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 VAA20089; Wed, 25 Jun 2003 21:56:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VLzc-0004GP-00; Wed, 25 Jun 2003 21:56:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19VLzW-0004GM-00; Wed, 25 Jun 2003 21:56:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VLzU-0001Xe-Jo; Wed, 25 Jun 2003 21:56:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VLyk-0001Wq-T9 for simple@optimus.ietf.org; Wed, 25 Jun 2003 21:55:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20008 for ; Wed, 25 Jun 2003 21:55:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VLyh-0004Fa-00 for simple@ietf.org; Wed, 25 Jun 2003 21:55:11 -0400 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 19VLyW-0004E5-00 for simple@ietf.org; Wed, 25 Jun 2003 21:55:00 -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 h5Q1rvxk016751; Wed, 25 Jun 2003 21:53:58 -0400 (EDT) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 25 Jun 2003 20:53:58 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E861A4@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'Sean Olson'" , Adam Roach , simple@ietf.org Subject: RE: [Simple] draft-roach-simple-blconf-00 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: Wed, 25 Jun 2003 20:53:57 -0500 Sean Olson writes: > I don't like requiring support for device > configuration to get this to work, especially since > that will usually be a separate operation from buddy > list configuration. Hmm... perhaps I muddied my description. The intention was not to imply that this would be *part* *of* device configuration; simply that it would use event packages in the same way. The intended solution is more like user configuration. > I think there is a third option that should be > considered. Use the user's URI as the buddy list > URI and indicate through a Event: parameter that the > buddy list is the intended target and not the user. That's an interesting proposition. It still runs afoul the two problems I cite in the draft: it constrains you to a single list, and it requires that list to be maintained by the same domain that handles your presence. > This has the implication that routing of these > requests will generally follow the same path as > subscribing to that user's presence. Which is, IMHO, an unnecessary restriction. I prefer a model that allows a la carte service selection by users over one that requires some sort of monolithic service provider. /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Jun 25 21:56:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20161 for ; Wed, 25 Jun 2003 21:56:43 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5Q1uGp06144 for simple-archive@odin.ietf.org; Wed, 25 Jun 2003 21:56:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VLzk-0001b1-Ou for simple-web-archive@optimus.ietf.org; Wed, 25 Jun 2003 21:56:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20089; Wed, 25 Jun 2003 21:56:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VLzc-0004GP-00; Wed, 25 Jun 2003 21:56:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19VLzW-0004GM-00; Wed, 25 Jun 2003 21:56:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VLzU-0001Xe-Jo; Wed, 25 Jun 2003 21:56:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VLyk-0001Wq-T9 for simple@optimus.ietf.org; Wed, 25 Jun 2003 21:55:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20008 for ; Wed, 25 Jun 2003 21:55:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VLyh-0004Fa-00 for simple@ietf.org; Wed, 25 Jun 2003 21:55:11 -0400 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 19VLyW-0004E5-00 for simple@ietf.org; Wed, 25 Jun 2003 21:55:00 -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 h5Q1rvxk016751; Wed, 25 Jun 2003 21:53:58 -0400 (EDT) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 25 Jun 2003 20:53:58 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E861A4@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'Sean Olson'" , Adam Roach , simple@ietf.org Subject: RE: [Simple] draft-roach-simple-blconf-00 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: Wed, 25 Jun 2003 20:53:57 -0500 Sean Olson writes: > I don't like requiring support for device > configuration to get this to work, especially since > that will usually be a separate operation from buddy > list configuration. Hmm... perhaps I muddied my description. The intention was not to imply that this would be *part* *of* device configuration; simply that it would use event packages in the same way. The intended solution is more like user configuration. > I think there is a third option that should be > considered. Use the user's URI as the buddy list > URI and indicate through a Event: parameter that the > buddy list is the intended target and not the user. That's an interesting proposition. It still runs afoul the two problems I cite in the draft: it constrains you to a single list, and it requires that list to be maintained by the same domain that handles your presence. > This has the implication that routing of these > requests will generally follow the same path as > subscribing to that user's presence. Which is, IMHO, an unnecessary restriction. I prefer a model that allows a la carte service selection by users over one that requires some sort of monolithic service provider. /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Jun 26 02:37:08 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 CAA10196; Thu, 26 Jun 2003 02:37:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VQNX-00068B-00; Thu, 26 Jun 2003 02:37:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19VQNR-000688-00; Thu, 26 Jun 2003 02:37:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VQNS-0006Xw-KI; Thu, 26 Jun 2003 02:37:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VQMo-0006Wr-Iq for simple@optimus.ietf.org; Thu, 26 Jun 2003 02:36:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10183 for ; Thu, 26 Jun 2003 02:36:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VQMk-00067k-00 for simple@ietf.org; Thu, 26 Jun 2003 02:36:18 -0400 Received: from falcon.ericsson.se ([193.180.251.52] helo=falcon.al.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19VQMZ-00067U-00 for simple@ietf.org; Thu, 26 Jun 2003 02:36:07 -0400 Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by falcon.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5Q6aacv011650; Thu, 26 Jun 2003 08:36:36 +0200 Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LVYRW2PG; Thu, 26 Jun 2003 08:37:30 +0200 Received: from ericsson.com (3NJPI0013L1IJOG.lmf.ericsson.se [131.160.31.89]) by hendrix.lmf.ericsson.se (8.12.8/8.12.8/lmf-2.1-jcs) with ESMTP id h5Q6ZISZ009896; Thu, 26 Jun 2003 09:35:18 +0300 (EET DST) Message-ID: <3EFA9437.1000200@ericsson.com> X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Miguel A. Garcia" Organization: Ericsson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: es,en MIME-Version: 1.0 To: Adam Roach CC: "'Mills, Duncan, D, CND Tech Dev, VF UK'" , simple@ietf.org Subject: Re: [Simple] Sending 1 to n MESSAGEs References: <9BF66EBF6BEFD942915B4D4D45C051F3E861A1@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: Thu, 26 Jun 2003 09:35:35 +0300 Content-Transfer-Encoding: 7bit Adam Roach wrote: > Duncan Mills writes: > > >>1.) I believe 1:n instant messaging can be achieved by >>setting up a distribution list and giving it a resource-URI. >> >>QUESTION: Do we need to update >>'draft-ietf-simple-event-list-04' to include some messaging >>procedures, as currently it only seems to consider presence? > > > I think the problems are completely separable. Sure, the problems are separable, but they share a few similarities. > > Keep in mind that the URI that you subscribe to with the > event-list extension semantically represents a group of > resources. If the server that allows you to subscribe to > an event-list can *also* receive MESSAGEs sent to that URI > and explode them to all the resources on the list, that's > something that it's perfectly okay to do. > That was exactly the similarity I found. You want to send a MESSAGE to a collection of receivers, identified by a list. That list represents a group that you may use also for presence purposes. > If it wants to accept INVITEs sent to that URI and set up > a centrally controlled multiparty session, that's also > something that's perfectly fine, and kind of spiffy. That is not the intention... although you could do it. > > But that kind of binding really needs to remain an implementation > decision. I don't think we gain anything by having a standards > document -- even a BCP -- that describes such a property. I agree that a standards document or BCP is not the right way to move forward. My initial proposal was to consider if a generalization of the event list would pay off. > > Bottom line: you can come up with fairly reasonable semantics > for just about any SIP request sent to a group resource > URI (and, in many cases, you can come up with several > useful semantics for the same method). Holding up event-lists > until we define this sort of thing for all existing methods > would not be realistic. And, even if we decided to do > so, the event-list document will be outdated as soon as a > new method is defined. > > >>2.) Is it enough to solve 1.) ? Do we need to alter/extend >>SIP to allow a MESSAGE to be sent to more than one recipient >>without the need to set up a recipient list on a server? I >>have heard several good arguments for allowing a MESSAGE to >>be addressed towards several recipients without >>pre-configuring a list: >> >> - Reducing the number of messages (particularly in wireless systems) >> - Reducing the time it takes the user to send such a message > > > As Dean points out, the *protocol* can semantically: While the mechanism that Dean proposes works, it provides some important drawbacks: it introduces a new significant delay to setup the list, so Instant Messaging becomes more like ... Not-so-instant Messaging. Further more, it introduces new requirements in terms of bandwith to setup and delete this list. > > 1) upload the list membership, > > PUT http://xcap.example.com/s/im/users/12145551212/t1 HTTP/1.1 > Content-Type:application/foo+xml > > > > sip:bob@example.com > sip:joe@example.com > sip:ed@example.com > > > 2) send the message, > > MESSAGE sip:t1@bl.examples.com SIP/2.0 > > > 3) and optionally destroy the list. > DELETE http://xcap.example.com/s/im/users/12145551212/t1 HTTP/1.1 > > ...all without the user ever being aware of what's going on. > The experience is the *same* as e-mail: the user types in a > list of recipients and a message, and the message is sent to > those recipients. I disagree with the "experience is the same as e-mail". In e-mail or MMS the user types the list of receives, press the buttom, and the message is sent. With the "XCAP mechanism on the fly", the user will press the buttom, does the XCAP operations (that will use some valuable time), and finally, if no error to setup the list, the message will be sent. Then the process continues to delete the list (something that may or may not run in the background). To me the user experience is not the same as e-mail. > > >> - More like e-mail > > > The primary fallacy in comparing MESSAGEs to e-mail is that > e-mail necessarily uses SMTP servers that perform the explosion > that we're talking about. With SIMPLE, signaling can go directly > from one party to the other. Agree here. One of the requirements of a possible solution is that the MESSAGE has to visit an entity that provides the exploding capabilities... nothing new, exactly like in the event list. > > >>There are also some issues related to any solution to 2.) >>that need to be thought through: >> >> - Do recipients need to see who else received the message? > > > The answer to this will be "yes," "no," and "we need ACLs," > depending on who in this working group decides to answer. My take on this is that this is a sender option. Doesn't it work like this in e-mail with To, Cc and Bcc fields? > > >> - Do we need the sender to receive delivery confirmations? Same as before. At the senders discretion. > > > Message receipt confirmation is something that's been on our > list of things to do for some time now. The charter addresses > this as, "Included might be new mechanisms for message > confirmation delivery". > > I think this probably is completely separable from the multiple > recipients problem. I agree here. The delivery confirmation is an issue not related to the 1 to n MESSAGEs problem. > > > As a related issue, you'll need to address the situation in which > an IM is sent to a group, and one such member is offline. Imagine > that this offline member has a message store that will play back > missed messages when he comes back online (cf. current SMS usage). > If the online recipients decide to respond to the message in such > a way that the response is sent to all the original recipients, > and a rather lengthy conversation ensues, the offline user is in > for an annoying torrent of messages -- probably stale -- when he > finally comes back online. This issue is orthogonal to the 1 to n MESSAGE problem. You can have to the same problem today with regular IM systems. > > It's been brought up already, but I feel it is important enough > to reiterate: once you start doing *group* messaging, you *really* > want ways to invite users into the group session, and for them > to have the ability to accept or decline, and to leave once they > are no longer interested in the conversation. (In fact, I would > argue that this is one of the most glaring shortcomings of current > e-mail systems; how many times have you seen an e-mail begging, > "please remove my e-mail address from this discussion!"?) > > This points squarely at the use of MESSAGE sessions instead of > pager-mode messages. I would argue that any of the other models > proposed in this thread go so far in emulating e-mail as to repeat > its most annoying flaws. > > /a /Miguel -- Miguel-Angel Garcia Oy LM Ericsson AB Jorvas, Finland mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 5140002 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Jun 26 02:38:54 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10250 for ; Thu, 26 Jun 2003 02:38:54 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5Q6cRO26774 for simple-archive@odin.ietf.org; Thu, 26 Jun 2003 02:38:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VQOp-0006xl-AX for simple-web-archive@optimus.ietf.org; Thu, 26 Jun 2003 02:38:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10196; Thu, 26 Jun 2003 02:37:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VQNX-00068B-00; Thu, 26 Jun 2003 02:37:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19VQNR-000688-00; Thu, 26 Jun 2003 02:37:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VQNS-0006Xw-KI; Thu, 26 Jun 2003 02:37:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VQMo-0006Wr-Iq for simple@optimus.ietf.org; Thu, 26 Jun 2003 02:36:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10183 for ; Thu, 26 Jun 2003 02:36:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VQMk-00067k-00 for simple@ietf.org; Thu, 26 Jun 2003 02:36:18 -0400 Received: from falcon.ericsson.se ([193.180.251.52] helo=falcon.al.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19VQMZ-00067U-00 for simple@ietf.org; Thu, 26 Jun 2003 02:36:07 -0400 Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by falcon.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5Q6aacv011650; Thu, 26 Jun 2003 08:36:36 +0200 Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LVYRW2PG; Thu, 26 Jun 2003 08:37:30 +0200 Received: from ericsson.com (3NJPI0013L1IJOG.lmf.ericsson.se [131.160.31.89]) by hendrix.lmf.ericsson.se (8.12.8/8.12.8/lmf-2.1-jcs) with ESMTP id h5Q6ZISZ009896; Thu, 26 Jun 2003 09:35:18 +0300 (EET DST) Message-ID: <3EFA9437.1000200@ericsson.com> X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Miguel A. Garcia" Organization: Ericsson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: es,en MIME-Version: 1.0 To: Adam Roach CC: "'Mills, Duncan, D, CND Tech Dev, VF UK'" , simple@ietf.org Subject: Re: [Simple] Sending 1 to n MESSAGEs References: <9BF66EBF6BEFD942915B4D4D45C051F3E861A1@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: Thu, 26 Jun 2003 09:35:35 +0300 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Adam Roach wrote: > Duncan Mills writes: > > >>1.) I believe 1:n instant messaging can be achieved by >>setting up a distribution list and giving it a resource-URI. >> >>QUESTION: Do we need to update >>'draft-ietf-simple-event-list-04' to include some messaging >>procedures, as currently it only seems to consider presence? > > > I think the problems are completely separable. Sure, the problems are separable, but they share a few similarities. > > Keep in mind that the URI that you subscribe to with the > event-list extension semantically represents a group of > resources. If the server that allows you to subscribe to > an event-list can *also* receive MESSAGEs sent to that URI > and explode them to all the resources on the list, that's > something that it's perfectly okay to do. > That was exactly the similarity I found. You want to send a MESSAGE to a collection of receivers, identified by a list. That list represents a group that you may use also for presence purposes. > If it wants to accept INVITEs sent to that URI and set up > a centrally controlled multiparty session, that's also > something that's perfectly fine, and kind of spiffy. That is not the intention... although you could do it. > > But that kind of binding really needs to remain an implementation > decision. I don't think we gain anything by having a standards > document -- even a BCP -- that describes such a property. I agree that a standards document or BCP is not the right way to move forward. My initial proposal was to consider if a generalization of the event list would pay off. > > Bottom line: you can come up with fairly reasonable semantics > for just about any SIP request sent to a group resource > URI (and, in many cases, you can come up with several > useful semantics for the same method). Holding up event-lists > until we define this sort of thing for all existing methods > would not be realistic. And, even if we decided to do > so, the event-list document will be outdated as soon as a > new method is defined. > > >>2.) Is it enough to solve 1.) ? Do we need to alter/extend >>SIP to allow a MESSAGE to be sent to more than one recipient >>without the need to set up a recipient list on a server? I >>have heard several good arguments for allowing a MESSAGE to >>be addressed towards several recipients without >>pre-configuring a list: >> >> - Reducing the number of messages (particularly in wireless systems) >> - Reducing the time it takes the user to send such a message > > > As Dean points out, the *protocol* can semantically: While the mechanism that Dean proposes works, it provides some important drawbacks: it introduces a new significant delay to setup the list, so Instant Messaging becomes more like ... Not-so-instant Messaging. Further more, it introduces new requirements in terms of bandwith to setup and delete this list. > > 1) upload the list membership, > > PUT http://xcap.example.com/s/im/users/12145551212/t1 HTTP/1.1 > Content-Type:application/foo+xml > > > > sip:bob@example.com > sip:joe@example.com > sip:ed@example.com > > > 2) send the message, > > MESSAGE sip:t1@bl.examples.com SIP/2.0 > > > 3) and optionally destroy the list. > DELETE http://xcap.example.com/s/im/users/12145551212/t1 HTTP/1.1 > > ...all without the user ever being aware of what's going on. > The experience is the *same* as e-mail: the user types in a > list of recipients and a message, and the message is sent to > those recipients. I disagree with the "experience is the same as e-mail". In e-mail or MMS the user types the list of receives, press the buttom, and the message is sent. With the "XCAP mechanism on the fly", the user will press the buttom, does the XCAP operations (that will use some valuable time), and finally, if no error to setup the list, the message will be sent. Then the process continues to delete the list (something that may or may not run in the background). To me the user experience is not the same as e-mail. > > >> - More like e-mail > > > The primary fallacy in comparing MESSAGEs to e-mail is that > e-mail necessarily uses SMTP servers that perform the explosion > that we're talking about. With SIMPLE, signaling can go directly > from one party to the other. Agree here. One of the requirements of a possible solution is that the MESSAGE has to visit an entity that provides the exploding capabilities... nothing new, exactly like in the event list. > > >>There are also some issues related to any solution to 2.) >>that need to be thought through: >> >> - Do recipients need to see who else received the message? > > > The answer to this will be "yes," "no," and "we need ACLs," > depending on who in this working group decides to answer. My take on this is that this is a sender option. Doesn't it work like this in e-mail with To, Cc and Bcc fields? > > >> - Do we need the sender to receive delivery confirmations? Same as before. At the senders discretion. > > > Message receipt confirmation is something that's been on our > list of things to do for some time now. The charter addresses > this as, "Included might be new mechanisms for message > confirmation delivery". > > I think this probably is completely separable from the multiple > recipients problem. I agree here. The delivery confirmation is an issue not related to the 1 to n MESSAGEs problem. > > > As a related issue, you'll need to address the situation in which > an IM is sent to a group, and one such member is offline. Imagine > that this offline member has a message store that will play back > missed messages when he comes back online (cf. current SMS usage). > If the online recipients decide to respond to the message in such > a way that the response is sent to all the original recipients, > and a rather lengthy conversation ensues, the offline user is in > for an annoying torrent of messages -- probably stale -- when he > finally comes back online. This issue is orthogonal to the 1 to n MESSAGE problem. You can have to the same problem today with regular IM systems. > > It's been brought up already, but I feel it is important enough > to reiterate: once you start doing *group* messaging, you *really* > want ways to invite users into the group session, and for them > to have the ability to accept or decline, and to leave once they > are no longer interested in the conversation. (In fact, I would > argue that this is one of the most glaring shortcomings of current > e-mail systems; how many times have you seen an e-mail begging, > "please remove my e-mail address from this discussion!"?) > > This points squarely at the use of MESSAGE sessions instead of > pager-mode messages. I would argue that any of the other models > proposed in this thread go so far in emulating e-mail as to repeat > its most annoying flaws. > > /a /Miguel -- Miguel-Angel Garcia Oy LM Ericsson AB Jorvas, Finland mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 5140002 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Jun 26 02:53:06 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 CAA10506; Thu, 26 Jun 2003 02:53:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VQcz-0006CI-00; Thu, 26 Jun 2003 02:53:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19VQcu-0006CF-00; Thu, 26 Jun 2003 02:53:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VQcv-0007uf-Ru; Thu, 26 Jun 2003 02:53:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VQbr-0007kT-PD for simple@optimus.ietf.org; Thu, 26 Jun 2003 02:52:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10452 for ; Thu, 26 Jun 2003 02:51:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VQbY-0006BE-00 for simple@ietf.org; Thu, 26 Jun 2003 02:51:37 -0400 Received: from comversegw.icomverse.com ([192.118.48.248] helo=il-tlv-smtpout1.icomverse.com) by ietf-mx with esmtp (Exim 4.12) id 19VQbO-0006B7-00 for simple@ietf.org; Thu, 26 Jun 2003 02:51:26 -0400 Received: from il-tlv-mbdg2.comverse.com (localhost.localdomain [127.0.0.1]) by il-tlv-smtpout1.icomverse.com (8.11.6/8.11.6) with ESMTP id h5Q6oYg29667; Thu, 26 Jun 2003 09:50:35 +0300 Received: by il-tlv-mbdg2.comverse.com with Internet Mail Service (5.5.2655.55) id ; Thu, 26 Jun 2003 09:50:40 +0300 Message-ID: <385D702A9C11D511A9E90008C7160AD50545447E@ISMAIL1> From: Cnaan Oded To: "'Michael Hammer'" Cc: "'Jonathan Rosenberg'" , Dean Willis , "Mills, Duncan, D, CND Tech Dev, VF UK" , simple@ietf.org Subject: RE: [Simple] Sending 1 to n MESSAGEs MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C33BAE.A9784C4C" 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, 26 Jun 2003 09:50:39 +0300 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C33BAE.A9784C4C Content-Type: text/plain; charset="iso-8859-1" Mike, Session based messaging is equivalent to a chat room (where users can join and leave the room) and I was refering to the pager mode which is sessionless. My comment was that even when outside a session, the sender should be able to choose between 2 modes, conversation (To list included) or 1:m (Only sender included). This can be in a form of an indication to the distribution server whether to include the list or not as part of the B2BUA behavior. Oded -----Original Message----- From: Michael Hammer [mailto:mhammer@cisco.com] Sent: Wednesday, June 25, 2003 10:56 PM To: Cnaan Oded Cc: 'Jonathan Rosenberg'; Dean Willis; Mills, Duncan, D, CND Tech Dev, VF UK; simple@ietf.org Subject: RE: [Simple] Sending 1 to n MESSAGEs Should such multi-recipient MESSAGEs be sent within a session to which a recipient could say BYE, future messages to the rejected session get silently discarded? Or, seems like you would need to have an anti-dote header (X-Recipient-Remove-Me:) and a corresponding "Reply-All-Remove-Me" GUI button, that upon receipt could be handled without presentation by each recipient to trim the list. Mike ------_=_NextPart_001_01C33BAE.A9784C4C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Simple] Sending 1 to n MESSAGEs

Mike,

Session based messaging is equivalent to a chat room = (where users can join and leave the room) and I was refering to the = pager mode which is sessionless.

My comment was that even when outside a session, the = sender should be able to choose between 2 modes, conversation (To list = included) or 1:m (Only sender included). This can be in a form of an = indication to the distribution server whether to include the list or = not as part of the B2BUA behavior.

Oded

-----Original Message-----
From: Michael Hammer [mailto:mhammer@cisco.com]
Sent: Wednesday, June 25, 2003 10:56 PM
To: Cnaan Oded
Cc: 'Jonathan Rosenberg'; Dean Willis; Mills, = Duncan, D, CND Tech Dev, VF UK; simple@ietf.org
Subject: RE: [Simple] Sending 1 to n MESSAGEs

Should such multi-recipient MESSAGEs be sent within a = session to which a recipient could say BYE, future messages to the = rejected session get silently discarded?

Or, seems like you would need to have an anti-dote = header (X-Recipient-Remove-Me:) and a corresponding = "Reply-All-Remove-Me" GUI button, that upon receipt could be = handled without presentation by each recipient to trim the = list.

Mike

------_=_NextPart_001_01C33BAE.A9784C4C-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Jun 26 02:53:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10536 for ; Thu, 26 Jun 2003 02:53:37 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5Q6rAd30615 for simple-archive@odin.ietf.org; Thu, 26 Jun 2003 02:53:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VQd4-0007xi-4k for simple-web-archive@optimus.ietf.org; Thu, 26 Jun 2003 02:53:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10506; Thu, 26 Jun 2003 02:53:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VQcz-0006CI-00; Thu, 26 Jun 2003 02:53:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19VQcu-0006CF-00; Thu, 26 Jun 2003 02:53:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VQcv-0007uf-Ru; Thu, 26 Jun 2003 02:53:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VQbr-0007kT-PD for simple@optimus.ietf.org; Thu, 26 Jun 2003 02:52:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10452 for ; Thu, 26 Jun 2003 02:51:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VQbY-0006BE-00 for simple@ietf.org; Thu, 26 Jun 2003 02:51:37 -0400 Received: from comversegw.icomverse.com ([192.118.48.248] helo=il-tlv-smtpout1.icomverse.com) by ietf-mx with esmtp (Exim 4.12) id 19VQbO-0006B7-00 for simple@ietf.org; Thu, 26 Jun 2003 02:51:26 -0400 Received: from il-tlv-mbdg2.comverse.com (localhost.localdomain [127.0.0.1]) by il-tlv-smtpout1.icomverse.com (8.11.6/8.11.6) with ESMTP id h5Q6oYg29667; Thu, 26 Jun 2003 09:50:35 +0300 Received: by il-tlv-mbdg2.comverse.com with Internet Mail Service (5.5.2655.55) id ; Thu, 26 Jun 2003 09:50:40 +0300 Message-ID: <385D702A9C11D511A9E90008C7160AD50545447E@ISMAIL1> From: Cnaan Oded To: "'Michael Hammer'" Cc: "'Jonathan Rosenberg'" , Dean Willis , "Mills, Duncan, D, CND Tech Dev, VF UK" , simple@ietf.org Subject: RE: [Simple] Sending 1 to n MESSAGEs MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C33BAE.A9784C4C" 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, 26 Jun 2003 09:50:39 +0300 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C33BAE.A9784C4C Content-Type: text/plain; charset="iso-8859-1" Mike, Session based messaging is equivalent to a chat room (where users can join and leave the room) and I was refering to the pager mode which is sessionless. My comment was that even when outside a session, the sender should be able to choose between 2 modes, conversation (To list included) or 1:m (Only sender included). This can be in a form of an indication to the distribution server whether to include the list or not as part of the B2BUA behavior. Oded -----Original Message----- From: Michael Hammer [mailto:mhammer@cisco.com] Sent: Wednesday, June 25, 2003 10:56 PM To: Cnaan Oded Cc: 'Jonathan Rosenberg'; Dean Willis; Mills, Duncan, D, CND Tech Dev, VF UK; simple@ietf.org Subject: RE: [Simple] Sending 1 to n MESSAGEs Should such multi-recipient MESSAGEs be sent within a session to which a recipient could say BYE, future messages to the rejected session get silently discarded? Or, seems like you would need to have an anti-dote header (X-Recipient-Remove-Me:) and a corresponding "Reply-All-Remove-Me" GUI button, that upon receipt could be handled without presentation by each recipient to trim the list. Mike ------_=_NextPart_001_01C33BAE.A9784C4C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Simple] Sending 1 to n MESSAGEs

Mike,

Session based messaging is equivalent to a chat room = (where users can join and leave the room) and I was refering to the = pager mode which is sessionless.

My comment was that even when outside a session, the = sender should be able to choose between 2 modes, conversation (To list = included) or 1:m (Only sender included). This can be in a form of an = indication to the distribution server whether to include the list or = not as part of the B2BUA behavior.

Oded

-----Original Message-----
From: Michael Hammer [mailto:mhammer@cisco.com]
Sent: Wednesday, June 25, 2003 10:56 PM
To: Cnaan Oded
Cc: 'Jonathan Rosenberg'; Dean Willis; Mills, = Duncan, D, CND Tech Dev, VF UK; simple@ietf.org
Subject: RE: [Simple] Sending 1 to n MESSAGEs

Should such multi-recipient MESSAGEs be sent within a = session to which a recipient could say BYE, future messages to the = rejected session get silently discarded?

Or, seems like you would need to have an anti-dote = header (X-Recipient-Remove-Me:) and a corresponding = "Reply-All-Remove-Me" GUI button, that upon receipt could be = handled without presentation by each recipient to trim the = list.

Mike

------_=_NextPart_001_01C33BAE.A9784C4C-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Jun 26 04:24:13 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 EAA11896; Thu, 26 Jun 2003 04:24:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VS3B-0006Zr-00; Thu, 26 Jun 2003 04:24:13 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19VS35-0006Zo-00; Thu, 26 Jun 2003 04:24:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VS31-0005c0-99; Thu, 26 Jun 2003 04:24:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VQxD-00018j-If for simple@optimus.ietf.org; Thu, 26 Jun 2003 03:13: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 DAA10887 for ; Thu, 26 Jun 2003 03:13:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VQww-0006J9-00 for simple@ietf.org; Thu, 26 Jun 2003 03:13:42 -0400 Received: from dns1.tilab.com ([163.162.42.4]) by ietf-mx with esmtp (Exim 4.12) id 19VQwl-0006H8-00 for simple@ietf.org; Thu, 26 Jun 2003 03:13:31 -0400 Received: from iowa2k01a.cselt.it (iowa2k01a.cselt.it [163.162.242.203]) by dns1.cselt.it (PMDF V6.0-025 #38895) with ESMTP id <0HH200K69UHM2Q@dns1.cselt.it> for simple@ietf.org; Thu, 26 Jun 2003 09:08:11 +0200 (MEST) Received: from iowa2k01a.cselt.it ([163.162.242.201]) by iowa2k01a.cselt.it with Microsoft SMTPSVC(5.0.2195.5329); Thu, 26 Jun 2003 09:08:30 +0200 Received: from EXC2K01A.cselt.it ([163.162.4.34]) by iowa2k01a.cselt.it with Microsoft SMTPSVC(5.0.2195.5329); Thu, 26 Jun 2003 09:08:30 +0200 From: Goix Walter Subject: RE: [Simple] Sending 1 to n MESSAGEs To: "Miguel A. Garcia" , Adam Roach Cc: "Mills, Duncan, D, CND Tech Dev, VF UK" , simple@ietf.org Message-id: <9620749A0C40FB49B72994B11B077C5D01329ECE@EXC2K01A.cselt.it> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Importance: normal Priority: normal Thread-Topic: [Simple] Sending 1 to n MESSAGEs Thread-Index: AcM7rV+WNUVbMA9cS7ySNEwJonnPtwAAEDWg content-class: urn:content-classes:message X-OriginalArrivalTime: 26 Jun 2003 07:08:30.0455 (UTC) FILETIME=[BF7F5870:01C33BB1] Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 26 Jun 2003 09:08:29 +0200 Content-Transfer-Encoding: 7bit inline > -----Original Message----- > From: Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com] > Sent: Thursday, June 26, 2003 8:36 AM > To: Adam Roach > Cc: 'Mills, Duncan, D, CND Tech Dev, VF UK'; simple@ietf.org > Subject: Re: [Simple] Sending 1 to n MESSAGEs > > > Adam Roach wrote: > > Duncan Mills writes: > > > > > >>1.) I believe 1:n instant messaging can be achieved by > >>setting up a distribution list and giving it a resource-URI. > >> > >>QUESTION: Do we need to update > >>'draft-ietf-simple-event-list-04' to include some messaging > >>procedures, as currently it only seems to consider presence? > > > > > > I think the problems are completely separable. > > Sure, the problems are separable, but they share a few similarities. > > > > > Keep in mind that the URI that you subscribe to with the event-list > > extension semantically represents a group of resources. If > the server > > that allows you to subscribe to an event-list can *also* receive > > MESSAGEs sent to that URI and explode them to all the > resources on the > > list, that's something that it's perfectly okay to do. > > > > That was exactly the similarity I found. You want to send a > MESSAGE to a > collection of receivers, identified by a list. That list > represents a group > that you may use also for presence purposes. > > > If it wants to accept INVITEs sent to that URI and set up > > a centrally controlled multiparty session, that's also something > > that's perfectly fine, and kind of spiffy. > > That is not the intention... although you could do it. > > > > > But that kind of binding really needs to remain an implementation > > decision. I don't think we gain anything by having a standards > > document -- even a BCP -- that describes such a property. > > I agree that a standards document or BCP is not the right way to move > forward. My initial proposal was to consider if a > generalization of the > event list would pay off. > > > > > Bottom line: you can come up with fairly reasonable > semantics for just > > about any SIP request sent to a group resource URI (and, in many > > cases, you can come up with several useful semantics for the same > > method). Holding up event-lists until we define this sort > of thing for > > all existing methods would not be realistic. And, even if > we decided > > to do so, the event-list document will be outdated as soon as a > > new method is defined. > > > > > >>2.) Is it enough to solve 1.) ? Do we need to alter/extend > >>SIP to allow a MESSAGE to be sent to more than one recipient > >>without the need to set up a recipient list on a server? I > >>have heard several good arguments for allowing a MESSAGE to > >>be addressed towards several recipients without > >>pre-configuring a list: > >> > >> - Reducing the number of messages (particularly in > wireless systems) > >> - Reducing the time it takes the user to send such a message > > > > > > As Dean points out, the *protocol* can semantically: > > While the mechanism that Dean proposes works, it provides > some important > drawbacks: it introduces a new significant delay to setup the > list, so > Instant Messaging becomes more like ... Not-so-instant > Messaging. Further > more, it introduces new requirements in terms of bandwith to > setup and > delete this list. > > > > > > 1) upload the list membership, > > > > PUT http://xcap.example.com/s/im/users/12145551212/t1 HTTP/1.1 > > Content-Type:application/foo+xml > > > > > > > > sip:bob@example.com > > sip:joe@example.com > > sip:ed@example.com > > > > > > 2) send the message, > > > > MESSAGE sip:t1@bl.examples.com SIP/2.0 > > > > > > 3) and optionally destroy the list. > > DELETE > http://xcap.example.com/s/im/users/12145551212/t1 HTTP/1.1 > > > > ...all without the user ever being aware of what's going on. The > > experience is the *same* as e-mail: the user types in a list of > > recipients and a message, and the message is sent to those > recipients. > > I disagree with the "experience is the same as e-mail". In > e-mail or MMS > the user types the list of receives, press the buttom, and > the message is > sent. With the "XCAP mechanism on the fly", the user will > press the buttom, > does the XCAP operations (that will use some valuable time), > and finally, > if no error to setup the list, the message will be sent. Then > the process > continues to delete the list (something that may or may not > run in the > background). To me the user experience is not the same as e-mail. Apart from the user 'experience' consideration which may be a bit different, creating a destination list may be really convenient to save bandwidth, and for the sender to configure centralized personal lists that he can reuse across terminals, potentially giving the ability to each member of the list to add/remove itself. It may be interesting to investigate whether we want that list to be known only by the sender (like a personal list that just helps the exploder to fork IMs) or published to all recipients to simplify reply-all functionalities. Having such a list accessible to all original destinations may give each of them the ability to remove itself from the list whenever he wants. In any case, this would lead to ACLs and inter-domain issues. Apart from HTTP, couldn't we use a REGISTER kind of list creation where the sender enters a contact for each recipient and defines an expiration date that may be refreshed. Based on policies (for example only allowed to original contacts), this would give the ability in a SIP way for any recipient to remove itself from the list at any time? That's probably more for a 'single time' use while the HTTP solution may be better to save lists persistently, but it doesn't require any specific infrastructure. As a side-effect the creation of temporary lists may create a virtual chat room and I think we would really prefer session-based messaging for that. > > > > > > >> - More like e-mail > > > > > > The primary fallacy in comparing MESSAGEs to e-mail is that e-mail > > necessarily uses SMTP servers that perform the explosion that we're > > talking about. With SIMPLE, signaling can go directly from > one party > > to the other. > > Agree here. One of the requirements of a possible solution is > that the > MESSAGE has to visit an entity that provides the exploding > capabilities... > nothing new, exactly like in the event list. > > > > > > >>There are also some issues related to any solution to 2.) > >>that need to be thought through: > >> > >> - Do recipients need to see who else received the message? > > > > > > The answer to this will be "yes," "no," and "we need ACLs," > depending > > on who in this working group decides to answer. > > My take on this is that this is a sender option. Doesn't it > work like this > in e-mail with To, Cc and Bcc fields? I totally agree. That should be a requirement. We may create a new header for the 'multiple' To:, (like Too: ;-) ) that lists all primary recipients to the MESSAGE and keep the To: as the exploder address or the resource list address. > > > > > > >> - Do we need the sender to receive delivery confirmations? > > Same as before. At the senders discretion. > > > > > > > Message receipt confirmation is something that's been on > our list of > > things to do for some time now. The charter addresses this as, > > "Included might be new mechanisms for message confirmation > delivery". > > > > I think this probably is completely separable from the multiple > > recipients problem. > > I agree here. The delivery confirmation is an issue not > related to the 1 to > n MESSAGEs problem. I agree that the "mechanisms" for confirmation delivery itself should be considered separately, but don't you think we should also give here the requirement for the sender to be able to ask for delivery confirmation in the MESSAGE itself as well, no matter the notification happens, or do we need an explicit subscription? That subscription would allow to get notified each time the user receives a message, but we probably would need more complicated stuff such as other policies and filters. A new Event type could be interesting to get notified and probably simplier with no SUBSCRIBE and on a per-message basis, although it may be interesting to configure it per recipient... > > > > > > > As a related issue, you'll need to address the situation in > which an > > IM is sent to a group, and one such member is offline. Imagine that > > this offline member has a message store that will play back missed > > messages when he comes back online (cf. current SMS usage). If the > > online recipients decide to respond to the message in such > a way that > > the response is sent to all the original recipients, and a rather > > lengthy conversation ensues, the offline user is in for an annoying > > torrent of messages -- probably stale -- when he finally comes back > > online. > > This issue is orthogonal to the 1 to n MESSAGE problem. You > can have to the > same problem today with regular IM systems. Yeah, that probably depends on the way IM is handled for that recipient. He may use a store-and-forward server typically for this use (like e-mail and SMS) even if the message is stale (until the SAF server has some policy to remove Expired MESSAGEs just like SMS) and have the ability to disable the offline storage whenever he doesn't need it (or based on trickier policies). In this case he'll just loose all IMs when he's offline but that's the way IM usually works. I don't think we can give more flexibility than this and users are quite used to these mechanisms already. > > > > > It's been brought up already, but I feel it is important enough to > > reiterate: once you start doing *group* messaging, you > *really* want > > ways to invite users into the group session, and for them > to have the > > ability to accept or decline, and to leave once they are no longer > > interested in the conversation. (In fact, I would argue > that this is > > one of the most glaring shortcomings of current e-mail systems; how > > many times have you seen an e-mail begging, "please remove > my e-mail > > address from this discussion!"?) Ok, but group messaging is not only a message conference or a chat room, even if these have there advantages to people to join and leave freely or get invited. Group messaging in pager-mode also has its importance and is well used in many communities. A sender may want to page some friends and only get a single answer from each of them, not start an IM session. I see the discussion here more related to this topic. > > > > This points squarely at the use of MESSAGE sessions instead of > > pager-mode messages. I would argue that any of the other models > > proposed in this thread go so far in emulating e-mail as to > repeat its > > most annoying flaws. > > > > /a > > /Miguel > -- > Miguel-Angel Garcia Oy LM Ericsson AB > Jorvas, Finland > mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 > mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 5140002 Walter ________________________ Laurent-Walter Goix Telecom Italia S.p.A. Telecom Italia Lab - StarSIP Services Innovation - Intelligent Services and Platforms (SI/P) Via Reiss Romoli 274 I-10148 Torino (Italy) Tel. +39 011 228 5046 Fax +39 011 228 5069 E-mail mailto:laurentwalter.goix@telecomitalia.it ________________________ Visit us @ http://starsip.telecomitalialab.com ==================================================================== CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by replying to MailAdmin@tilab.com. Thank you ==================================================================== _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Jun 26 04:24:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12162 for ; Thu, 26 Jun 2003 04:24:58 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5Q8OVH23079 for simple-archive@odin.ietf.org; Thu, 26 Jun 2003 04:24:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VS3T-00060A-8z for simple-web-archive@optimus.ietf.org; Thu, 26 Jun 2003 04:24:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11896; Thu, 26 Jun 2003 04:24:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VS3B-0006Zr-00; Thu, 26 Jun 2003 04:24:13 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19VS35-0006Zo-00; Thu, 26 Jun 2003 04:24:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VS31-0005c0-99; Thu, 26 Jun 2003 04:24:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VQxD-00018j-If for simple@optimus.ietf.org; Thu, 26 Jun 2003 03:13: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 DAA10887 for ; Thu, 26 Jun 2003 03:13:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VQww-0006J9-00 for simple@ietf.org; Thu, 26 Jun 2003 03:13:42 -0400 Received: from dns1.tilab.com ([163.162.42.4]) by ietf-mx with esmtp (Exim 4.12) id 19VQwl-0006H8-00 for simple@ietf.org; Thu, 26 Jun 2003 03:13:31 -0400 Received: from iowa2k01a.cselt.it (iowa2k01a.cselt.it [163.162.242.203]) by dns1.cselt.it (PMDF V6.0-025 #38895) with ESMTP id <0HH200K69UHM2Q@dns1.cselt.it> for simple@ietf.org; Thu, 26 Jun 2003 09:08:11 +0200 (MEST) Received: from iowa2k01a.cselt.it ([163.162.242.201]) by iowa2k01a.cselt.it with Microsoft SMTPSVC(5.0.2195.5329); Thu, 26 Jun 2003 09:08:30 +0200 Received: from EXC2K01A.cselt.it ([163.162.4.34]) by iowa2k01a.cselt.it with Microsoft SMTPSVC(5.0.2195.5329); Thu, 26 Jun 2003 09:08:30 +0200 From: Goix Walter Subject: RE: [Simple] Sending 1 to n MESSAGEs To: "Miguel A. Garcia" , Adam Roach Cc: "Mills, Duncan, D, CND Tech Dev, VF UK" , simple@ietf.org Message-id: <9620749A0C40FB49B72994B11B077C5D01329ECE@EXC2K01A.cselt.it> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Importance: normal Priority: normal Thread-Topic: [Simple] Sending 1 to n MESSAGEs Thread-Index: AcM7rV+WNUVbMA9cS7ySNEwJonnPtwAAEDWg content-class: urn:content-classes:message X-OriginalArrivalTime: 26 Jun 2003 07:08:30.0455 (UTC) FILETIME=[BF7F5870:01C33BB1] Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 26 Jun 2003 09:08:29 +0200 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit inline > -----Original Message----- > From: Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com] > Sent: Thursday, June 26, 2003 8:36 AM > To: Adam Roach > Cc: 'Mills, Duncan, D, CND Tech Dev, VF UK'; simple@ietf.org > Subject: Re: [Simple] Sending 1 to n MESSAGEs > > > Adam Roach wrote: > > Duncan Mills writes: > > > > > >>1.) I believe 1:n instant messaging can be achieved by > >>setting up a distribution list and giving it a resource-URI. > >> > >>QUESTION: Do we need to update > >>'draft-ietf-simple-event-list-04' to include some messaging > >>procedures, as currently it only seems to consider presence? > > > > > > I think the problems are completely separable. > > Sure, the problems are separable, but they share a few similarities. > > > > > Keep in mind that the URI that you subscribe to with the event-list > > extension semantically represents a group of resources. If > the server > > that allows you to subscribe to an event-list can *also* receive > > MESSAGEs sent to that URI and explode them to all the > resources on the > > list, that's something that it's perfectly okay to do. > > > > That was exactly the similarity I found. You want to send a > MESSAGE to a > collection of receivers, identified by a list. That list > represents a group > that you may use also for presence purposes. > > > If it wants to accept INVITEs sent to that URI and set up > > a centrally controlled multiparty session, that's also something > > that's perfectly fine, and kind of spiffy. > > That is not the intention... although you could do it. > > > > > But that kind of binding really needs to remain an implementation > > decision. I don't think we gain anything by having a standards > > document -- even a BCP -- that describes such a property. > > I agree that a standards document or BCP is not the right way to move > forward. My initial proposal was to consider if a > generalization of the > event list would pay off. > > > > > Bottom line: you can come up with fairly reasonable > semantics for just > > about any SIP request sent to a group resource URI (and, in many > > cases, you can come up with several useful semantics for the same > > method). Holding up event-lists until we define this sort > of thing for > > all existing methods would not be realistic. And, even if > we decided > > to do so, the event-list document will be outdated as soon as a > > new method is defined. > > > > > >>2.) Is it enough to solve 1.) ? Do we need to alter/extend > >>SIP to allow a MESSAGE to be sent to more than one recipient > >>without the need to set up a recipient list on a server? I > >>have heard several good arguments for allowing a MESSAGE to > >>be addressed towards several recipients without > >>pre-configuring a list: > >> > >> - Reducing the number of messages (particularly in > wireless systems) > >> - Reducing the time it takes the user to send such a message > > > > > > As Dean points out, the *protocol* can semantically: > > While the mechanism that Dean proposes works, it provides > some important > drawbacks: it introduces a new significant delay to setup the > list, so > Instant Messaging becomes more like ... Not-so-instant > Messaging. Further > more, it introduces new requirements in terms of bandwith to > setup and > delete this list. > > > > > > 1) upload the list membership, > > > > PUT http://xcap.example.com/s/im/users/12145551212/t1 HTTP/1.1 > > Content-Type:application/foo+xml > > > > > > > > sip:bob@example.com > > sip:joe@example.com > > sip:ed@example.com > > > > > > 2) send the message, > > > > MESSAGE sip:t1@bl.examples.com SIP/2.0 > > > > > > 3) and optionally destroy the list. > > DELETE > http://xcap.example.com/s/im/users/12145551212/t1 HTTP/1.1 > > > > ...all without the user ever being aware of what's going on. The > > experience is the *same* as e-mail: the user types in a list of > > recipients and a message, and the message is sent to those > recipients. > > I disagree with the "experience is the same as e-mail". In > e-mail or MMS > the user types the list of receives, press the buttom, and > the message is > sent. With the "XCAP mechanism on the fly", the user will > press the buttom, > does the XCAP operations (that will use some valuable time), > and finally, > if no error to setup the list, the message will be sent. Then > the process > continues to delete the list (something that may or may not > run in the > background). To me the user experience is not the same as e-mail. Apart from the user 'experience' consideration which may be a bit different, creating a destination list may be really convenient to save bandwidth, and for the sender to configure centralized personal lists that he can reuse across terminals, potentially giving the ability to each member of the list to add/remove itself. It may be interesting to investigate whether we want that list to be known only by the sender (like a personal list that just helps the exploder to fork IMs) or published to all recipients to simplify reply-all functionalities. Having such a list accessible to all original destinations may give each of them the ability to remove itself from the list whenever he wants. In any case, this would lead to ACLs and inter-domain issues. Apart from HTTP, couldn't we use a REGISTER kind of list creation where the sender enters a contact for each recipient and defines an expiration date that may be refreshed. Based on policies (for example only allowed to original contacts), this would give the ability in a SIP way for any recipient to remove itself from the list at any time? That's probably more for a 'single time' use while the HTTP solution may be better to save lists persistently, but it doesn't require any specific infrastructure. As a side-effect the creation of temporary lists may create a virtual chat room and I think we would really prefer session-based messaging for that. > > > > > > >> - More like e-mail > > > > > > The primary fallacy in comparing MESSAGEs to e-mail is that e-mail > > necessarily uses SMTP servers that perform the explosion that we're > > talking about. With SIMPLE, signaling can go directly from > one party > > to the other. > > Agree here. One of the requirements of a possible solution is > that the > MESSAGE has to visit an entity that provides the exploding > capabilities... > nothing new, exactly like in the event list. > > > > > > >>There are also some issues related to any solution to 2.) > >>that need to be thought through: > >> > >> - Do recipients need to see who else received the message? > > > > > > The answer to this will be "yes," "no," and "we need ACLs," > depending > > on who in this working group decides to answer. > > My take on this is that this is a sender option. Doesn't it > work like this > in e-mail with To, Cc and Bcc fields? I totally agree. That should be a requirement. We may create a new header for the 'multiple' To:, (like Too: ;-) ) that lists all primary recipients to the MESSAGE and keep the To: as the exploder address or the resource list address. > > > > > > >> - Do we need the sender to receive delivery confirmations? > > Same as before. At the senders discretion. > > > > > > > Message receipt confirmation is something that's been on > our list of > > things to do for some time now. The charter addresses this as, > > "Included might be new mechanisms for message confirmation > delivery". > > > > I think this probably is completely separable from the multiple > > recipients problem. > > I agree here. The delivery confirmation is an issue not > related to the 1 to > n MESSAGEs problem. I agree that the "mechanisms" for confirmation delivery itself should be considered separately, but don't you think we should also give here the requirement for the sender to be able to ask for delivery confirmation in the MESSAGE itself as well, no matter the notification happens, or do we need an explicit subscription? That subscription would allow to get notified each time the user receives a message, but we probably would need more complicated stuff such as other policies and filters. A new Event type could be interesting to get notified and probably simplier with no SUBSCRIBE and on a per-message basis, although it may be interesting to configure it per recipient... > > > > > > > As a related issue, you'll need to address the situation in > which an > > IM is sent to a group, and one such member is offline. Imagine that > > this offline member has a message store that will play back missed > > messages when he comes back online (cf. current SMS usage). If the > > online recipients decide to respond to the message in such > a way that > > the response is sent to all the original recipients, and a rather > > lengthy conversation ensues, the offline user is in for an annoying > > torrent of messages -- probably stale -- when he finally comes back > > online. > > This issue is orthogonal to the 1 to n MESSAGE problem. You > can have to the > same problem today with regular IM systems. Yeah, that probably depends on the way IM is handled for that recipient. He may use a store-and-forward server typically for this use (like e-mail and SMS) even if the message is stale (until the SAF server has some policy to remove Expired MESSAGEs just like SMS) and have the ability to disable the offline storage whenever he doesn't need it (or based on trickier policies). In this case he'll just loose all IMs when he's offline but that's the way IM usually works. I don't think we can give more flexibility than this and users are quite used to these mechanisms already. > > > > > It's been brought up already, but I feel it is important enough to > > reiterate: once you start doing *group* messaging, you > *really* want > > ways to invite users into the group session, and for them > to have the > > ability to accept or decline, and to leave once they are no longer > > interested in the conversation. (In fact, I would argue > that this is > > one of the most glaring shortcomings of current e-mail systems; how > > many times have you seen an e-mail begging, "please remove > my e-mail > > address from this discussion!"?) Ok, but group messaging is not only a message conference or a chat room, even if these have there advantages to people to join and leave freely or get invited. Group messaging in pager-mode also has its importance and is well used in many communities. A sender may want to page some friends and only get a single answer from each of them, not start an IM session. I see the discussion here more related to this topic. > > > > This points squarely at the use of MESSAGE sessions instead of > > pager-mode messages. I would argue that any of the other models > > proposed in this thread go so far in emulating e-mail as to > repeat its > > most annoying flaws. > > > > /a > > /Miguel > -- > Miguel-Angel Garcia Oy LM Ericsson AB > Jorvas, Finland > mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 > mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 5140002 Walter ________________________ Laurent-Walter Goix Telecom Italia S.p.A. Telecom Italia Lab - StarSIP Services Innovation - Intelligent Services and Platforms (SI/P) Via Reiss Romoli 274 I-10148 Torino (Italy) Tel. +39 011 228 5046 Fax +39 011 228 5069 E-mail mailto:laurentwalter.goix@telecomitalia.it ________________________ Visit us @ http://starsip.telecomitalialab.com ==================================================================== CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by replying to MailAdmin@tilab.com. Thank you ==================================================================== _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Jun 26 04:36:07 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 EAA12502; Thu, 26 Jun 2003 04:36:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VSEh-0006gw-00; Thu, 26 Jun 2003 04:36:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19VSEb-0006gt-00; Thu, 26 Jun 2003 04:36:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VSEc-0007vA-40; Thu, 26 Jun 2003 04:36:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VSDt-0007ub-6b for simple@optimus.ietf.org; Thu, 26 Jun 2003 04:35:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12491 for ; Thu, 26 Jun 2003 04:35:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VSDq-0006gb-00 for simple@ietf.org; Thu, 26 Jun 2003 04:35:14 -0400 Received: from news.ubiquity.net ([194.202.146.92] helo=gbnewp0186s1.eu.ubiquity.net) by ietf-mx with smtp (Exim 4.12) id 19VSDf-0006gT-00 for simple@ietf.org; Thu, 26 Jun 2003 04:35:03 -0400 Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; Thu, 26 Jun 2003 09:37:43 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Sending 1 to n MESSAGEs Message-ID: <45730E094814E44488F789C1CDED27AE0219B00A@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [Simple] Sending 1 to n MESSAGEs Thread-Index: AcM7fQXPzpWHYL4XReKq8dvDKw1kQQAPX2/Q From: "Chris Boulton" To: "Adam Roach" , "Mills, Duncan, D, CND Tech Dev, VF UK" , Cc: "Miguel A. Garcia" 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: Thu, 26 Jun 2003 09:35:00 +0100 Content-Transfer-Encoding: quoted-printable Adam, Totally agree - message sessions are certainly the preferred solution. For those who insist on pager mode messaging (e.g. For SMS style service replication) will have to overcome the associated problems you mention (only one response) which can only realistically be achieved by a B2BUA. Chris. =09 >-----Original Message----- >From: Adam Roach [mailto:adam@dynamicsoft.com] >Sent: 26 June 2003 01:01 >To: 'Mills, Duncan, D, CND Tech Dev, VF UK'; simple@ietf.org >Cc: Miguel A. Garcia >Subject: RE: [Simple] Sending 1 to n MESSAGEs > >Duncan Mills writes: > >> 1.) I believe 1:n instant messaging can be achieved by >> setting up a distribution list and giving it a resource-URI. >> >> QUESTION: Do we need to update >> 'draft-ietf-simple-event-list-04' to include some messaging >> procedures, as currently it only seems to consider presence? > >I think the problems are completely separable. > >Keep in mind that the URI that you subscribe to with the >event-list extension semantically represents a group of >resources. If the server that allows you to subscribe to >an event-list can *also* receive MESSAGEs sent to that URI >and explode them to all the resources on the list, that's >something that it's perfectly okay to do. > >If it wants to accept INVITEs sent to that URI and set up >a centrally controlled multiparty session, that's also >something that's perfectly fine, and kind of spiffy. > >But that kind of binding really needs to remain an implementation >decision. I don't think we gain anything by having a standards >document -- even a BCP -- that describes such a property. > >Bottom line: you can come up with fairly reasonable semantics >for just about any SIP request sent to a group resource >URI (and, in many cases, you can come up with several >useful semantics for the same method). Holding up event-lists >until we define this sort of thing for all existing methods >would not be realistic. And, even if we decided to do >so, the event-list document will be outdated as soon as a >new method is defined. > >> 2.) Is it enough to solve 1.) ? Do we need to alter/extend >> SIP to allow a MESSAGE to be sent to more than one recipient >> without the need to set up a recipient list on a server? I >> have heard several good arguments for allowing a MESSAGE to >> be addressed towards several recipients without >> pre-configuring a list: >> >> - Reducing the number of messages (particularly in wireless systems) >> - Reducing the time it takes the user to send such a message > >As Dean points out, the *protocol* can semantically: > > 1) upload the list membership, > > PUT http://xcap.example.com/s/im/users/12145551212/t1 HTTP/1.1 > Content-Type:application/foo+xml > > > > sip:bob@example.com > sip:joe@example.com > sip:ed@example.com > > > 2) send the message, > > MESSAGE sip:t1@bl.examples.com SIP/2.0 > > > 3) and optionally destroy the list. > DELETE http://xcap.example.com/s/im/users/12145551212/t1 HTTP/1.1 > >...all without the user ever being aware of what's going on. >The experience is the *same* as e-mail: the user types in a >list of recipients and a message, and the message is sent to >those recipients. > >> - More like e-mail > >The primary fallacy in comparing MESSAGEs to e-mail is that >e-mail necessarily uses SMTP servers that perform the explosion >that we're talking about. With SIMPLE, signaling can go directly >from one party to the other. > >> There are also some issues related to any solution to 2.) >> that need to be thought through: >> >> - Do recipients need to see who else received the message? > >The answer to this will be "yes," "no," and "we need ACLs," >depending on who in this working group decides to answer. > >> - Do we need the sender to receive delivery confirmations? > >Message receipt confirmation is something that's been on our >list of things to do for some time now. The charter addresses >this as, "Included might be new mechanisms for message >confirmation delivery". > >I think this probably is completely separable from the multiple >recipients problem. > > >As a related issue, you'll need to address the situation in which >an IM is sent to a group, and one such member is offline. Imagine >that this offline member has a message store that will play back >missed messages when he comes back online (cf. current SMS usage). >If the online recipients decide to respond to the message in such >a way that the response is sent to all the original recipients, >and a rather lengthy conversation ensues, the offline user is in >for an annoying torrent of messages -- probably stale -- when he >finally comes back online. > >It's been brought up already, but I feel it is important enough >to reiterate: once you start doing *group* messaging, you *really* >want ways to invite users into the group session, and for them >to have the ability to accept or decline, and to leave once they >are no longer interested in the conversation. (In fact, I would >argue that this is one of the most glaring shortcomings of current >e-mail systems; how many times have you seen an e-mail begging, >"please remove my e-mail address from this discussion!"?) > >This points squarely at the use of MESSAGE sessions instead of >pager-mode messages. I would argue that any of the other models >proposed in this thread go so far in emulating e-mail as to repeat >its most annoying flaws. > >/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 Thu Jun 26 04:36:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12526 for ; Thu, 26 Jun 2003 04:36:38 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5Q8aBI30667 for simple-archive@odin.ietf.org; Thu, 26 Jun 2003 04:36:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VSEk-0007yY-Kq for simple-web-archive@optimus.ietf.org; Thu, 26 Jun 2003 04:36:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12502; Thu, 26 Jun 2003 04:36:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VSEh-0006gw-00; Thu, 26 Jun 2003 04:36:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19VSEb-0006gt-00; Thu, 26 Jun 2003 04:36:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VSEc-0007vA-40; Thu, 26 Jun 2003 04:36:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VSDt-0007ub-6b for simple@optimus.ietf.org; Thu, 26 Jun 2003 04:35:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12491 for ; Thu, 26 Jun 2003 04:35:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VSDq-0006gb-00 for simple@ietf.org; Thu, 26 Jun 2003 04:35:14 -0400 Received: from news.ubiquity.net ([194.202.146.92] helo=gbnewp0186s1.eu.ubiquity.net) by ietf-mx with smtp (Exim 4.12) id 19VSDf-0006gT-00 for simple@ietf.org; Thu, 26 Jun 2003 04:35:03 -0400 Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; Thu, 26 Jun 2003 09:37:43 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Sending 1 to n MESSAGEs Message-ID: <45730E094814E44488F789C1CDED27AE0219B00A@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [Simple] Sending 1 to n MESSAGEs Thread-Index: AcM7fQXPzpWHYL4XReKq8dvDKw1kQQAPX2/Q From: "Chris Boulton" To: "Adam Roach" , "Mills, Duncan, D, CND Tech Dev, VF UK" , Cc: "Miguel A. Garcia" 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: Thu, 26 Jun 2003 09:35:00 +0100 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Adam, Totally agree - message sessions are certainly the preferred solution. For those who insist on pager mode messaging (e.g. For SMS style service replication) will have to overcome the associated problems you mention (only one response) which can only realistically be achieved by a B2BUA. Chris. =09 >-----Original Message----- >From: Adam Roach [mailto:adam@dynamicsoft.com] >Sent: 26 June 2003 01:01 >To: 'Mills, Duncan, D, CND Tech Dev, VF UK'; simple@ietf.org >Cc: Miguel A. Garcia >Subject: RE: [Simple] Sending 1 to n MESSAGEs > >Duncan Mills writes: > >> 1.) I believe 1:n instant messaging can be achieved by >> setting up a distribution list and giving it a resource-URI. >> >> QUESTION: Do we need to update >> 'draft-ietf-simple-event-list-04' to include some messaging >> procedures, as currently it only seems to consider presence? > >I think the problems are completely separable. > >Keep in mind that the URI that you subscribe to with the >event-list extension semantically represents a group of >resources. If the server that allows you to subscribe to >an event-list can *also* receive MESSAGEs sent to that URI >and explode them to all the resources on the list, that's >something that it's perfectly okay to do. > >If it wants to accept INVITEs sent to that URI and set up >a centrally controlled multiparty session, that's also >something that's perfectly fine, and kind of spiffy. > >But that kind of binding really needs to remain an implementation >decision. I don't think we gain anything by having a standards >document -- even a BCP -- that describes such a property. > >Bottom line: you can come up with fairly reasonable semantics >for just about any SIP request sent to a group resource >URI (and, in many cases, you can come up with several >useful semantics for the same method). Holding up event-lists >until we define this sort of thing for all existing methods >would not be realistic. And, even if we decided to do >so, the event-list document will be outdated as soon as a >new method is defined. > >> 2.) Is it enough to solve 1.) ? Do we need to alter/extend >> SIP to allow a MESSAGE to be sent to more than one recipient >> without the need to set up a recipient list on a server? I >> have heard several good arguments for allowing a MESSAGE to >> be addressed towards several recipients without >> pre-configuring a list: >> >> - Reducing the number of messages (particularly in wireless systems) >> - Reducing the time it takes the user to send such a message > >As Dean points out, the *protocol* can semantically: > > 1) upload the list membership, > > PUT http://xcap.example.com/s/im/users/12145551212/t1 HTTP/1.1 > Content-Type:application/foo+xml > > > > sip:bob@example.com > sip:joe@example.com > sip:ed@example.com > > > 2) send the message, > > MESSAGE sip:t1@bl.examples.com SIP/2.0 > > > 3) and optionally destroy the list. > DELETE http://xcap.example.com/s/im/users/12145551212/t1 HTTP/1.1 > >...all without the user ever being aware of what's going on. >The experience is the *same* as e-mail: the user types in a >list of recipients and a message, and the message is sent to >those recipients. > >> - More like e-mail > >The primary fallacy in comparing MESSAGEs to e-mail is that >e-mail necessarily uses SMTP servers that perform the explosion >that we're talking about. With SIMPLE, signaling can go directly >from one party to the other. > >> There are also some issues related to any solution to 2.) >> that need to be thought through: >> >> - Do recipients need to see who else received the message? > >The answer to this will be "yes," "no," and "we need ACLs," >depending on who in this working group decides to answer. > >> - Do we need the sender to receive delivery confirmations? > >Message receipt confirmation is something that's been on our >list of things to do for some time now. The charter addresses >this as, "Included might be new mechanisms for message >confirmation delivery". > >I think this probably is completely separable from the multiple >recipients problem. > > >As a related issue, you'll need to address the situation in which >an IM is sent to a group, and one such member is offline. Imagine >that this offline member has a message store that will play back >missed messages when he comes back online (cf. current SMS usage). >If the online recipients decide to respond to the message in such >a way that the response is sent to all the original recipients, >and a rather lengthy conversation ensues, the offline user is in >for an annoying torrent of messages -- probably stale -- when he >finally comes back online. > >It's been brought up already, but I feel it is important enough >to reiterate: once you start doing *group* messaging, you *really* >want ways to invite users into the group session, and for them >to have the ability to accept or decline, and to leave once they >are no longer interested in the conversation. (In fact, I would >argue that this is one of the most glaring shortcomings of current >e-mail systems; how many times have you seen an e-mail begging, >"please remove my e-mail address from this discussion!"?) > >This points squarely at the use of MESSAGE sessions instead of >pager-mode messages. I would argue that any of the other models >proposed in this thread go so far in emulating e-mail as to repeat >its most annoying flaws. > >/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 Thu Jun 26 04:50:06 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 EAA12792; Thu, 26 Jun 2003 04:50:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VSSE-0006ma-00; Thu, 26 Jun 2003 04:50:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19VSS9-0006mX-00; Thu, 26 Jun 2003 04:50:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VSS9-00011d-NX; Thu, 26 Jun 2003 04:50:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VSRm-00010j-Ut for simple@optimus.ietf.org; Thu, 26 Jun 2003 04:49: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 EAA12781 for ; Thu, 26 Jun 2003 04:49:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VSRU-0006mE-00 for simple@ietf.org; Thu, 26 Jun 2003 04:49:20 -0400 Received: from willow.neustar.com ([209.173.53.84]) by ietf-mx with esmtp (Exim 4.12) id 19VSRK-0006lm-00 for simple@ietf.org; Thu, 26 Jun 2003 04:49:10 -0400 Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id h5Q8lfC02225 for ; Thu, 26 Jun 2003 08:47:41 GMT Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id ; Thu, 26 Jun 2003 04:48:26 -0400 Message-ID: <0449D80A0E9B614A83FA9031B07E8D3B257BED@stntexch2.va.neustar.com> From: "Peterson, Jon" To: "Simpletons (E-mail)" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Simple] comments on rpids-01 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 26 Jun 2003 04:48:22 -0400 I have some comments about the new version of the RPIDS draft. I definitely appreciate that the capability stuff has been removed from the document - I think it will makes the scope of this draft more manageable in the short term. Since this is my first really close reading of the document since before the -00 came out, I'm sure I comment on many things here are not new to this -01 version. I am still mindful of our chartered short-term goal to identify and/or provide all of the components necessary to build a commercial IM & Presence system. RPIDS is a collection of relatively diverse elements, and still incorporates many things that go beyond that goal, I think. To me, the note in 6.1, "it is highly unlikely that a presentity will publish or announce all of these elements at the same time", highlights the fact that many of these elements could be in separate extensions without interdependencies - I would prefer if smaller collections of related elements could be used in PIDF instances without importing the whole of RPIDS. In short, rather than having a monolithic entity called RPIDS, I'd rather have a collection of smaller, more tactical XML schemas that extend PIDF towards specific goals. I don't think any of the current RPIDS elements are technically specific to SIP, and thus they might play well with other extensions to PIDF that could be developed inside or even outside of the SIMPLE WG. I think the core elements in this document, the ones that address our most important requirements, are and . Both are currently fine by me, although I'm a little unsure if 'category' is the right name for something that describes 'what the presentity is currently doing'. I actually think the term 'activity' is a much better name for this, and since I'm not sure the element currently named 'activity' is necessary, maybe this could be reused instead of 'category'. Even if not, I think we need an element name that is a bit more explicit than 'category' - 'doing' or something like that. is hard for me to comment on, since the need for this parameter is fundamental to the current controversy about how tuples should be understood, and whether or not watchers need some indication of the intention of the constructor of a tuple. If it turns out that this is necessary, then we need , yes. On another naming point, I wonder if 'contact' doesn't imply that there's a contact address, which of course not all will contain. Speaking of , I would either remove or further motivate the element. I'm not sure what the relationship between and is supposed to be. The motivation given in the Intro for class is: We add an element (Section 6.6) that labels each tuple as being a presentity, a group of presentities or a device. ... but Section 6.6 is where is defined, and has this description, not . is essentially unqualified, given its description in Section 6.5. I also note that is not used in any of the examples, but that is used in the examples in a roughly similar way to how I imagined would be used. There are a number of elements in RPIDS that represent predictive or calendrical presence information - , , and I think , in so far as differs from the baseline PIDF (and following the mention of in 6.16). While I can see the value in specifying these, I'd like to suggest that they should be outside the scope of our initial work here in SIMPLE. First of all, it is debatable to what degree calendar information is presence information. Moreover the precedence and interaction between calendar or predictive information and real-time publication might give rise to new problems. This is not a feature that I currently see in a lot of commercial instant messaging applications. I think that this would be a good separate extension to PIDF, that could be imported/supported as necessary. I'd like to suggest that this be broken off into a separate document that provides calendaring/timing extensions to PIDF. and are, I think, not presence information as such. Icon-sharing is common in instant messaging applications, but there are other ways in SIP (like Call-Info) to share an icon (I'd further note that the IM applications with which I have experience display user-provisioned icons only when a messaging channel is opened, etc). There is an argument to be made that vCard should be included, since it is mentioned in RFC2779 (Req 3.1.6) and not included in PIDF, but even in this turbulent economy, my business card doesn't change enough that I would consider it to be real-time communications info. I think that for the time being, there isn't any pressing motivation to put these features into PIDF to complete our work here. If need be, I'd recommend incorporating them as one or more separate PIDF extensions. Though I like , I'm less sure about . In response to the motivation given in 6.2, if a computer doesn't have a keyboard or mouse, it should be publishing a state of CLOSED; we don't need to supplement this. Similarly, if I see the word 'active' in presence, I would assume that the presentity is around (and thus perhaps ready to communicate) - perhaps not what I should assume if they are on the phone. If someone is totally idle (at a threshold judged by the watcher), they could derivately be considered inactive - that's the quality that we really need here; the only difference that introduces, I think, is that the presentity rather than the watcher makes the judgment call of activeness based on that idleness timer. But then again, the presentity still always gets to choose the threshold at which it starts including an element. Finally, commercial instant messaging systems don't tell me, for example, that a presentity is currently conversing with two other IMers (which would presumably be the corollary of for IM), so I'm not sure I see this sort of activity as being something we immediately need for our short-term goals. and seem to be similar to one another - they convey a sense to watchers of how appropriate various kinds of communication might be given the environment of the presentity. Since the value of these elements can be free text (i.e. arbitrary), it's hard for me to see why doesn't suffice to express these values - an automaton shouldn't be keying off a free text field, and moreover, an automaton isn't going to supervise your IMs (or speech) to determine whether or not what you're saying is appropriate to the presentity's placetype. Moreover, choosing between 'home', 'office' and 'public' doesn't really seem to give a reliable indication of what kinds of communication might be appropriate. Similarly, I might consider this laptop 'private' until somebody walks up and looks over my shoulder - but I'm not always going to change my presence to reflect that condition. In short, I have a hard time seeing how useful these would really be, and I see no reason why a to the same effect wouldn't be just as useful. I'm unsure about because it encourages presentities to publish their presence under another entity's AoR (and for compositors to accept such publications) - given that this would include family members, associates, and the like, it seems to give rise to fairly complicated authorization logic in compositors. I wonder, though, if there aren't other solutions to this problem - like, giving out a group alias as your AoR, or something, that includes any other persons whose presence is 'equivalent' to yours as necessary. It seems weird to include presence information in a document that doesn't below to the resource identified by the 'entity' attribute of the document. Most importantly, I'm not sure that this is very backwards-compatible with baseline PIDF - if you don't understand the element, you might be unpleasantly surprised when you IM one of the contact addresses in the associated . I agree that something that provides this capability (associating presence from one party with that of another) would be useful, but I'm not sure that it should be done as a PIDF extension. I think that from the conclusion of our discussion of tuple composition, we should remove