From mailman-admin@ietf.org Mon Sep 1 22:10: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 WAA21791 for ; Mon, 1 Sep 2003 22:10:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19u0cV-00056e-00 for simple-archive@ietf.org; Mon, 01 Sep 2003 22:10:11 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19txBK-00016t-00 for simple-archive@ietf.org; Mon, 01 Sep 2003 18:29:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19toMz-0001Tm-Ot for simple-archive@ietf.org; Mon, 01 Sep 2003 09:05:21 -0400 Date: Mon, 01 Sep 2003 09:05:21 -0400 Message-ID: <20030901130521.21711.11506.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 Tue Sep 2 03:31: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 DAA25067; Tue, 2 Sep 2003 03:31:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19u5dN-00014v-00; Tue, 02 Sep 2003 03:31:25 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19u5dM-00014q-00; Tue, 02 Sep 2003 03:31:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19u4v1-0003zP-IL; Tue, 02 Sep 2003 02:45:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19u1QB-0003VE-Ew for simple@optimus.ietf.org; Mon, 01 Sep 2003 23:01: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 XAA05004 for ; Mon, 1 Sep 2003 23:01: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 19u1Q6-0005dF-00 for simple@ietf.org; Mon, 01 Sep 2003 23:01:26 -0400 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 19tkoo-000188-00 for simple@ietf.org; Mon, 01 Sep 2003 05:17:50 -0400 Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h819Hou23337 for ; Mon, 1 Sep 2003 12:17:50 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 1 Sep 2003 12:17:49 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 1 Sep 2003 12:17:49 +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] [Fwd: Re: NETCONF WG meeting minutes for IETF #57] Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70179703A@esebe019.ntc.nokia.com> Thread-Topic: [Simple] [Fwd: Re: NETCONF WG meeting minutes for IETF #57] Thread-Index: AcNuRxPbatH7RI53QSaoT8Vh8esipgCIdnHg To: , , X-OriginalArrivalTime: 01 Sep 2003 09:17:49.0663 (UTC) FILETIME=[EA05C6F0:01C37069] 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, 1 Sep 2003 12:17:48 +0300 Content-Transfer-Encoding: quoted-printable I don't buy it. Why would you define an XML schema who's syntax does not = match the semantics? I earlier bought the argument that XPath is too complicated to implement = for a simple use case of just wanting to identify an element in an XML = document, and thereafter agreed to provide some text in the I-D pointing = to this issue and explaining the limited use of XPath in filtering. /Hisham > -----Original Message----- > From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Friday, August 29, 2003 5:36 PM > To: Simple WG; gk@ninebynine.org > Subject: [Simple] [Fwd: Re: NETCONF WG meeting minutes for IETF #57] >=20 >=20 > Graham Klyne posted this note on netconf that has some insights which > I think can benefit us. Pay attention to this statement: >=20 > Graham writes: > > I would be very wary about using XPath as the basis for selective > > access to XMLConf data. XPath, by design, provides selection on > > the syntactic structure of XML: it has been suggested elsewhere > > (e.g. in the netconf protocol document, IIRC) that the data model > > is separate from the protocol framework (which I think is a good > > approach). But the query/selection syntax should be related to the > > data model, not to the carrier syntax. I have seen difficulties > > arise with different XML-based applications where people tried to > > use XPath selection for an XML format used to carry a data model > > that was somewhat different from the XML carrier syntax. If the > > data model does not map directly onto the XML syntax, then XPath > > selection may well prove inadequate to make appropriate selection > > in the configuration data. >=20 > I think this summarizes nicely the concerns I have had about using=20 > xpath for filtering. I am also going to be removing it from element=20 > identification in the next xcap-auth rev. >=20 > -Jonathan R. >=20 > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Sep 2 08:31: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 IAA16926; Tue, 2 Sep 2003 08:31:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uAJy-0000rx-00; Tue, 02 Sep 2003 08:31:42 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19uAJx-0000ru-00; Tue, 02 Sep 2003 08:31:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19u6B2-00080n-TO; Tue, 02 Sep 2003 04:06:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19u3sA-0002fo-Ri for simple@optimus.ietf.org; Tue, 02 Sep 2003 01:38: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 BAA05081 for ; Tue, 2 Sep 2003 01:38:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19u3s6-0007E2-00 for simple@ietf.org; Tue, 02 Sep 2003 01:38:30 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19u3s5-00076l-00 for simple@ietf.org; Tue, 02 Sep 2003 01:38:30 -0400 Received: from dynamicsoft.com ([63.113.46.42]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h825c4Ug008159; Tue, 2 Sep 2003 01:38:05 -0400 (EDT) Message-ID: <3F542CB5.7040006@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: simple@ietf.org, gk@ninebynine.org Subject: Re: [Simple] [Fwd: Re: NETCONF WG meeting minutes for IETF #57] References: <2038BCC78B1AD641891A0D1AE133DBB70179703A@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB70179703A@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, 02 Sep 2003 01:37:57 -0400 Content-Transfer-Encoding: 7bit It ties back into our ongoing debate about "what is a tuple". Its not that the PIDF XML has no semantics, its that the underlying "presence" of a user can map into a variety of different XML documents, depending on the underlying policy of the PA and presentity. Thus, if the desire is to have a filter that restricts geolocation inforamtion, the appropriate XPath expressions depend a lot on how the PA chooses to place the presence information into the presence document. As an example, the PA may use it to compute the "placetype" RPID attribute. Or, it may appear in some tuples, but not others. It may appear as a textual piece of a note, i.e., "at work". Xpath cannot be used to tell a PA "don't put geoloc data anywhere in the document". More abstractly, and in the context of Graham's note, I believe there is an underling data model which has "raw" presence data, and then this data gets encoded into presence documents using PIDF. I believe filters are ultimately useful only in their application to this raw data. Since there is a gap between the raw data and its encoding into a PIDF document, the usage of Xpath expressions on the PIDF document doesnt seem right to me. Thanks, Jonathan R. hisham.khartabil@nokia.com wrote: > I don't buy it. Why would you define an XML schema who's syntax > does not match the semantics? > > I earlier bought the argument that XPath is too complicated to > implement for a simple use case of just wanting to identify an > element in an XML document, and thereafter agreed to provide some > text in the I-D pointing to this issue and explaining the limited > use of XPath in filtering. > > /Hisham > > >> -----Original Message----- From: ext Jonathan Rosenberg >> [mailto:jdrosen@dynamicsoft.com] Sent: Friday, August 29, 2003 >> 5:36 PM To: Simple WG; gk@ninebynine.org Subject: [Simple] [Fwd: >> Re: NETCONF WG meeting minutes for IETF #57] >> >> >> Graham Klyne posted this note on netconf that has some insights >> which I think can benefit us. Pay attention to this statement: >> >> Graham writes: >> >>> I would be very wary about using XPath as the basis for >>> selective access to XMLConf data. XPath, by design, provides >>> selection on the syntactic structure of XML: it has been >>> suggested elsewhere (e.g. in the netconf protocol document, >>> IIRC) that the data model is separate from the protocol >>> framework (which I think is a good approach). But the >>> query/selection syntax should be related to the data model, not >>> to the carrier syntax. I have seen difficulties arise with >>> different XML-based applications where people tried to use >>> XPath selection for an XML format used to carry a data model >>> that was somewhat different from the XML carrier syntax. If >>> the data model does not map directly onto the XML syntax, then >>> XPath selection may well prove inadequate to make appropriate >>> selection in the configuration data. >> >> I think this summarizes nicely the concerns I have had about >> using xpath for filtering. I am also going to be removing it from >> element identification in the next xcap-auth rev. >> >> -Jonathan R. >> >> -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >> Chief Technology Officer Parsippany, NJ >> 07054-2711 dynamicsoft jdrosen@dynamicsoft.com >> FAX: (973) 952-5050 http://www.jdrosen.net >> PHONE: (973) 952-5000 http://www.dynamicsoft.com >> > > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Sep 2 09:39:40 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 JAA24643 for ; Tue, 2 Sep 2003 09:39:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uARW-0001Ue-ON for simple-archive@odin.ietf.org; Tue, 02 Sep 2003 08:39:31 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h82CdUIg005736 for simple-archive@odin.ietf.org; Tue, 2 Sep 2003 08:39:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19u5dR-0002i3-0Z for simple-web-archive@optimus.ietf.org; Tue, 02 Sep 2003 03:31: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 DAA25067; Tue, 2 Sep 2003 03:31:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19u5dN-00014v-00; Tue, 02 Sep 2003 03:31:25 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19u5dM-00014q-00; Tue, 02 Sep 2003 03:31:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19u4v1-0003zP-IL; Tue, 02 Sep 2003 02:45:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19u1QB-0003VE-Ew for simple@optimus.ietf.org; Mon, 01 Sep 2003 23:01: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 XAA05004 for ; Mon, 1 Sep 2003 23:01: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 19u1Q6-0005dF-00 for simple@ietf.org; Mon, 01 Sep 2003 23:01:26 -0400 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 19tkoo-000188-00 for simple@ietf.org; Mon, 01 Sep 2003 05:17:50 -0400 Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h819Hou23337 for ; Mon, 1 Sep 2003 12:17:50 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 1 Sep 2003 12:17:49 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 1 Sep 2003 12:17:49 +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] [Fwd: Re: NETCONF WG meeting minutes for IETF #57] Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70179703A@esebe019.ntc.nokia.com> Thread-Topic: [Simple] [Fwd: Re: NETCONF WG meeting minutes for IETF #57] Thread-Index: AcNuRxPbatH7RI53QSaoT8Vh8esipgCIdnHg To: , , X-OriginalArrivalTime: 01 Sep 2003 09:17:49.0663 (UTC) FILETIME=[EA05C6F0:01C37069] 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, 1 Sep 2003 12:17:48 +0300 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I don't buy it. Why would you define an XML schema who's syntax does not = match the semantics? I earlier bought the argument that XPath is too complicated to implement = for a simple use case of just wanting to identify an element in an XML = document, and thereafter agreed to provide some text in the I-D pointing = to this issue and explaining the limited use of XPath in filtering. /Hisham > -----Original Message----- > From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Friday, August 29, 2003 5:36 PM > To: Simple WG; gk@ninebynine.org > Subject: [Simple] [Fwd: Re: NETCONF WG meeting minutes for IETF #57] >=20 >=20 > Graham Klyne posted this note on netconf that has some insights which > I think can benefit us. Pay attention to this statement: >=20 > Graham writes: > > I would be very wary about using XPath as the basis for selective > > access to XMLConf data. XPath, by design, provides selection on > > the syntactic structure of XML: it has been suggested elsewhere > > (e.g. in the netconf protocol document, IIRC) that the data model > > is separate from the protocol framework (which I think is a good > > approach). But the query/selection syntax should be related to the > > data model, not to the carrier syntax. I have seen difficulties > > arise with different XML-based applications where people tried to > > use XPath selection for an XML format used to carry a data model > > that was somewhat different from the XML carrier syntax. If the > > data model does not map directly onto the XML syntax, then XPath > > selection may well prove inadequate to make appropriate selection > > in the configuration data. >=20 > I think this summarizes nicely the concerns I have had about using=20 > xpath for filtering. I am also going to be removing it from element=20 > identification in the next xcap-auth rev. >=20 > -Jonathan R. >=20 > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Sep 2 09:39:56 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 JAA24694 for ; Tue, 2 Sep 2003 09:39:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uBNb-0002WO-EF for simple-archive@odin.ietf.org; Tue, 02 Sep 2003 09:39:31 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h82DdVZK009682 for simple-archive@odin.ietf.org; Tue, 2 Sep 2003 09:39:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uAK1-0000EM-6Y for simple-web-archive@optimus.ietf.org; Tue, 02 Sep 2003 08:31: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 IAA16926; Tue, 2 Sep 2003 08:31:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uAJy-0000rx-00; Tue, 02 Sep 2003 08:31:42 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19uAJx-0000ru-00; Tue, 02 Sep 2003 08:31:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19u6B2-00080n-TO; Tue, 02 Sep 2003 04:06:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19u3sA-0002fo-Ri for simple@optimus.ietf.org; Tue, 02 Sep 2003 01:38: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 BAA05081 for ; Tue, 2 Sep 2003 01:38:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19u3s6-0007E2-00 for simple@ietf.org; Tue, 02 Sep 2003 01:38:30 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19u3s5-00076l-00 for simple@ietf.org; Tue, 02 Sep 2003 01:38:30 -0400 Received: from dynamicsoft.com ([63.113.46.42]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h825c4Ug008159; Tue, 2 Sep 2003 01:38:05 -0400 (EDT) Message-ID: <3F542CB5.7040006@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: simple@ietf.org, gk@ninebynine.org Subject: Re: [Simple] [Fwd: Re: NETCONF WG meeting minutes for IETF #57] References: <2038BCC78B1AD641891A0D1AE133DBB70179703A@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB70179703A@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, 02 Sep 2003 01:37:57 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit It ties back into our ongoing debate about "what is a tuple". Its not that the PIDF XML has no semantics, its that the underlying "presence" of a user can map into a variety of different XML documents, depending on the underlying policy of the PA and presentity. Thus, if the desire is to have a filter that restricts geolocation inforamtion, the appropriate XPath expressions depend a lot on how the PA chooses to place the presence information into the presence document. As an example, the PA may use it to compute the "placetype" RPID attribute. Or, it may appear in some tuples, but not others. It may appear as a textual piece of a note, i.e., "at work". Xpath cannot be used to tell a PA "don't put geoloc data anywhere in the document". More abstractly, and in the context of Graham's note, I believe there is an underling data model which has "raw" presence data, and then this data gets encoded into presence documents using PIDF. I believe filters are ultimately useful only in their application to this raw data. Since there is a gap between the raw data and its encoding into a PIDF document, the usage of Xpath expressions on the PIDF document doesnt seem right to me. Thanks, Jonathan R. hisham.khartabil@nokia.com wrote: > I don't buy it. Why would you define an XML schema who's syntax > does not match the semantics? > > I earlier bought the argument that XPath is too complicated to > implement for a simple use case of just wanting to identify an > element in an XML document, and thereafter agreed to provide some > text in the I-D pointing to this issue and explaining the limited > use of XPath in filtering. > > /Hisham > > >> -----Original Message----- From: ext Jonathan Rosenberg >> [mailto:jdrosen@dynamicsoft.com] Sent: Friday, August 29, 2003 >> 5:36 PM To: Simple WG; gk@ninebynine.org Subject: [Simple] [Fwd: >> Re: NETCONF WG meeting minutes for IETF #57] >> >> >> Graham Klyne posted this note on netconf that has some insights >> which I think can benefit us. Pay attention to this statement: >> >> Graham writes: >> >>> I would be very wary about using XPath as the basis for >>> selective access to XMLConf data. XPath, by design, provides >>> selection on the syntactic structure of XML: it has been >>> suggested elsewhere (e.g. in the netconf protocol document, >>> IIRC) that the data model is separate from the protocol >>> framework (which I think is a good approach). But the >>> query/selection syntax should be related to the data model, not >>> to the carrier syntax. I have seen difficulties arise with >>> different XML-based applications where people tried to use >>> XPath selection for an XML format used to carry a data model >>> that was somewhat different from the XML carrier syntax. If >>> the data model does not map directly onto the XML syntax, then >>> XPath selection may well prove inadequate to make appropriate >>> selection in the configuration data. >> >> I think this summarizes nicely the concerns I have had about >> using xpath for filtering. I am also going to be removing it from >> element identification in the next xcap-auth rev. >> >> -Jonathan R. >> >> -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >> Chief Technology Officer Parsippany, NJ >> 07054-2711 dynamicsoft jdrosen@dynamicsoft.com >> FAX: (973) 952-5050 http://www.jdrosen.net >> PHONE: (973) 952-5000 http://www.dynamicsoft.com >> > > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Sep 2 09:42:15 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 JAA25090 for ; Tue, 2 Sep 2003 09:42:15 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19u67f-0007Fx-6C for simple-archive@odin.ietf.org; Tue, 02 Sep 2003 04:02:43 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8282haa027885 for simple-archive@odin.ietf.org; Tue, 2 Sep 2003 04:02:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19u10O-0000rI-Un for simple-web-archive@optimus.ietf.org; Mon, 01 Sep 2003 22:34: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 WAA26209 for ; Mon, 1 Sep 2003 22:34:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19u10K-0006lR-00 for simple-web-archive@ietf.org; Mon, 01 Sep 2003 22:34:48 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19tvAY-0001Y1-00 for simple-web-archive@ietf.org; Mon, 01 Sep 2003 16:20:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19toSr-0004QJ-TE for simple-web-archive@ietf.org; Mon, 01 Sep 2003 09:11:25 -0400 Date: Mon, 01 Sep 2003 09:11:25 -0400 Message-ID: <20030901131125.21711.31158.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: simple-web-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: mailman-admin@ietf.org Errors-To: mailman-admin@ietf.org X-BeenThere: mailman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, simple-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. *************************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. *************************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. Thanks! Passwords for simple-web-archive@ietf.org: List Password // URL ---- -------- simple@ietf.org fuasex https://www1.ietf.org/mailman/options/simple/simple-web-archive%40ietf.org From simple-admin@ietf.org Tue Sep 2 09:42: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 JAA25146; Tue, 2 Sep 2003 09:42: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 19uBQ6-0003Cq-7V; Tue, 02 Sep 2003 09:42:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19u8np-0003lm-Bh for simple@optimus.ietf.org; Tue, 02 Sep 2003 06:54: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 GAA09808 for ; Tue, 2 Sep 2003 06:54:17 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19u8nk-00016E-00 for simple@ietf.org; Tue, 02 Sep 2003 06:54:20 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19u8nj-000164-00 for simple@ietf.org; Tue, 02 Sep 2003 06:54:19 -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 h82As4B24139 for ; Tue, 2 Sep 2003 13:54:20 +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, 2 Sep 2003 13:54:04 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 2 Sep 2003 13:54:04 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 2 Sep 2003 13:54:03 +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] [Fwd: Re: NETCONF WG meeting minutes for IETF #57] Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797051@esebe019.ntc.nokia.com> Thread-Topic: [Simple] [Fwd: Re: NETCONF WG meeting minutes for IETF #57] Thread-Index: AcNxFH9T8L5f6yBRRp2LLAM5QHtxlQAKp4Ow To: Cc: , X-OriginalArrivalTime: 02 Sep 2003 10:54:03.0638 (UTC) FILETIME=[85FE3160:01C37140] 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, 2 Sep 2003 13:54:03 +0300 Content-Transfer-Encoding: quoted-printable PIDF and tuple is just one example of where filtering would be used. The = filtering mechanism that we are building is generic for all event = notification packages. There is an open issue in the tuple design team, and that is how a = client can get information about the tuple construction at the server = side. Quoting Robert: "There are still questions around the use of tuples to be discussed. The one this design team was circling around whether a PA needs to expose the policy it used to create tuples to the watcher and whether a watcher needs to be able to request a certain policy. This discussion will move back to the SIMPLE list."=20 This is needed so that the watcher knows how to render the information = to the user using GUI to the like. Note, this is tuple specific issue. I don't think the filtering solution = should be complicated just to satisfy the tuple problem, the tuple = problem should be fixed instead. Regards, Hisham > -----Original Message----- > From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Tuesday, September 02, 2003 8:38 AM > To: Khartabil Hisham (NMP/Helsinki) > Cc: simple@ietf.org; gk@ninebynine.org > Subject: Re: [Simple] [Fwd: Re: NETCONF WG meeting minutes=20 > for IETF #57] >=20 >=20 > It ties back into our ongoing debate about "what is a tuple". Its not=20 > that the PIDF XML has no semantics, its that the underlying=20 > "presence"=20 > of a user can map into a variety of different XML documents,=20 > depending=20 > on the underlying policy of the PA and presentity. Thus, if=20 > the desire=20 > is to have a filter that restricts geolocation inforamtion, the=20 > appropriate XPath expressions depend a lot on how the PA chooses to=20 > place the presence information into the presence document. As an=20 > example, the PA may use it to compute the "placetype" RPID attribute.=20 > Or, it may appear in some tuples, but not others. It may appear as a=20 > textual piece of a note, i.e., "at work". Xpath cannot be=20 > used to tell=20 > a PA "don't put geoloc data anywhere in the document". >=20 > More abstractly, and in the context of Graham's note, I believe there=20 > is an underling data model which has "raw" presence data, and then=20 > this data gets encoded into presence documents using PIDF. I believe=20 > filters are ultimately useful only in their application to this raw=20 > data. Since there is a gap between the raw data and its encoding into=20 > a PIDF document, the usage of Xpath expressions on the PIDF document=20 > doesnt seem right to me. >=20 > Thanks, > Jonathan R. >=20 > hisham.khartabil@nokia.com wrote: >=20 > > I don't buy it. Why would you define an XML schema who's syntax > > does not match the semantics? > >=20 > > I earlier bought the argument that XPath is too complicated to > > implement for a simple use case of just wanting to identify an > > element in an XML document, and thereafter agreed to provide some > > text in the I-D pointing to this issue and explaining the limited > > use of XPath in filtering. > >=20 > > /Hisham > >=20 > >=20 > >> -----Original Message----- From: ext Jonathan Rosenberg > >> [mailto:jdrosen@dynamicsoft.com] Sent: Friday, August 29, 2003 > >> 5:36 PM To: Simple WG; gk@ninebynine.org Subject: [Simple] [Fwd: > >> Re: NETCONF WG meeting minutes for IETF #57] > >>=20 > >>=20 > >> Graham Klyne posted this note on netconf that has some insights > >> which I think can benefit us. Pay attention to this statement: > >>=20 > >> Graham writes: > >>=20 > >>> I would be very wary about using XPath as the basis for > >>> selective access to XMLConf data. XPath, by design, provides > >>> selection on the syntactic structure of XML: it has been > >>> suggested elsewhere (e.g. in the netconf protocol document, > >>> IIRC) that the data model is separate from the protocol > >>> framework (which I think is a good approach). But the > >>> query/selection syntax should be related to the data model, not > >>> to the carrier syntax. I have seen difficulties arise with > >>> different XML-based applications where people tried to use > >>> XPath selection for an XML format used to carry a data model=20 > >>> that was somewhat different from the XML carrier syntax. If > >>> the data model does not map directly onto the XML syntax, then > >>> XPath selection may well prove inadequate to make appropriate > >>> selection in the configuration data. > >>=20 > >> I think this summarizes nicely the concerns I have had about > >> using xpath for filtering. I am also going to be removing it from > >> element identification in the next xcap-auth rev. > >>=20 > >> -Jonathan R. > >>=20 > >> -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza=20 > >> Chief Technology Officer Parsippany, NJ > >> 07054-2711 dynamicsoft jdrosen@dynamicsoft.com > >> FAX: (973) 952-5050 http://www.jdrosen.net > >> PHONE: (973) 952-5000 http://www.dynamicsoft.com > >>=20 > >=20 > >=20 >=20 > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Sep 2 09:45:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25789; Tue, 2 Sep 2003 09:45:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uBSw-0003lq-CH; Tue, 02 Sep 2003 09:45:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19u8sN-0004J0-U1 for simple@optimus.ietf.org; Tue, 02 Sep 2003 06:59: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 GAA10147 for ; Tue, 2 Sep 2003 06:59:00 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19u8sI-0001gq-00 for simple@ietf.org; Tue, 02 Sep 2003 06:59:02 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19u8sH-0001ge-00 for simple@ietf.org; Tue, 02 Sep 2003 06:59:01 -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 h82Ax2B29701 for ; Tue, 2 Sep 2003 13:59:03 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 2 Sep 2003 13:58:51 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 2 Sep 2003 13:58: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" Content-Transfer-Encoding: quoted-printable Subject: What is a tuple (was RE: [Simple] [Fwd: Re: NETCONF WG meeting minutes for IETF #57]) Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797052@esebe019.ntc.nokia.com> Thread-Topic: [Simple] [Fwd: Re: NETCONF WG meeting minutes for IETF #57] Thread-Index: AcNxFH9T8L5f6yBRRp2LLAM5QHtxlQALAssg To: Cc: , X-OriginalArrivalTime: 02 Sep 2003 10:58:50.0972 (UTC) FILETIME=[3141E1C0:01C37141] 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, 2 Sep 2003 13:58:50 +0300 Content-Transfer-Encoding: quoted-printable If you want my opinion about the tuple issue, I think we should reverse = the decision that was make providing flexibility on how to represent = presence information in a tuple. We should on a single way to. We can display all the options to the SIMPLE community and take a = poll/vote. Rough consensus will give us an indication which one will it = be. Regards, Hisham > -----Original Message----- > From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Tuesday, September 02, 2003 8:38 AM > To: Khartabil Hisham (NMP/Helsinki) > Cc: simple@ietf.org; gk@ninebynine.org > Subject: Re: [Simple] [Fwd: Re: NETCONF WG meeting minutes=20 > for IETF #57] >=20 >=20 > It ties back into our ongoing debate about "what is a tuple". Its not=20 > that the PIDF XML has no semantics, its that the underlying=20 > "presence"=20 > of a user can map into a variety of different XML documents,=20 > depending=20 > on the underlying policy of the PA and presentity. Thus, if=20 > the desire=20 > is to have a filter that restricts geolocation inforamtion, the=20 > appropriate XPath expressions depend a lot on how the PA chooses to=20 > place the presence information into the presence document. As an=20 > example, the PA may use it to compute the "placetype" RPID attribute.=20 > Or, it may appear in some tuples, but not others. It may appear as a=20 > textual piece of a note, i.e., "at work". Xpath cannot be=20 > used to tell=20 > a PA "don't put geoloc data anywhere in the document". >=20 > More abstractly, and in the context of Graham's note, I believe there=20 > is an underling data model which has "raw" presence data, and then=20 > this data gets encoded into presence documents using PIDF. I believe=20 > filters are ultimately useful only in their application to this raw=20 > data. Since there is a gap between the raw data and its encoding into=20 > a PIDF document, the usage of Xpath expressions on the PIDF document=20 > doesnt seem right to me. >=20 > Thanks, > Jonathan R. >=20 > hisham.khartabil@nokia.com wrote: >=20 > > I don't buy it. Why would you define an XML schema who's syntax > > does not match the semantics? > >=20 > > I earlier bought the argument that XPath is too complicated to > > implement for a simple use case of just wanting to identify an > > element in an XML document, and thereafter agreed to provide some > > text in the I-D pointing to this issue and explaining the limited > > use of XPath in filtering. > >=20 > > /Hisham > >=20 > >=20 > >> -----Original Message----- From: ext Jonathan Rosenberg > >> [mailto:jdrosen@dynamicsoft.com] Sent: Friday, August 29, 2003 > >> 5:36 PM To: Simple WG; gk@ninebynine.org Subject: [Simple] [Fwd: > >> Re: NETCONF WG meeting minutes for IETF #57] > >>=20 > >>=20 > >> Graham Klyne posted this note on netconf that has some insights > >> which I think can benefit us. Pay attention to this statement: > >>=20 > >> Graham writes: > >>=20 > >>> I would be very wary about using XPath as the basis for > >>> selective access to XMLConf data. XPath, by design, provides > >>> selection on the syntactic structure of XML: it has been > >>> suggested elsewhere (e.g. in the netconf protocol document, > >>> IIRC) that the data model is separate from the protocol > >>> framework (which I think is a good approach). But the > >>> query/selection syntax should be related to the data model, not > >>> to the carrier syntax. I have seen difficulties arise with > >>> different XML-based applications where people tried to use > >>> XPath selection for an XML format used to carry a data model=20 > >>> that was somewhat different from the XML carrier syntax. If > >>> the data model does not map directly onto the XML syntax, then > >>> XPath selection may well prove inadequate to make appropriate > >>> selection in the configuration data. > >>=20 > >> I think this summarizes nicely the concerns I have had about > >> using xpath for filtering. I am also going to be removing it from > >> element identification in the next xcap-auth rev. > >>=20 > >> -Jonathan R. > >>=20 > >> -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza=20 > >> Chief Technology Officer Parsippany, NJ > >> 07054-2711 dynamicsoft jdrosen@dynamicsoft.com > >> FAX: (973) 952-5050 http://www.jdrosen.net > >> PHONE: (973) 952-5000 http://www.dynamicsoft.com > >>=20 > >=20 > >=20 >=20 > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Sep 2 09:46:00 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 JAA25865 for ; Tue, 2 Sep 2003 09:46:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uBTT-0003zK-Cu for simple-archive@odin.ietf.org; Tue, 02 Sep 2003 09:45:35 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h82DjZtm015324 for simple-archive@odin.ietf.org; Tue, 2 Sep 2003 09:45:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uBTT-0003z5-8V for simple-web-archive@optimus.ietf.org; Tue, 02 Sep 2003 09:45:35 -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 JAA25789; Tue, 2 Sep 2003 09:45:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uBSw-0003lq-CH; Tue, 02 Sep 2003 09:45:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19u8sN-0004J0-U1 for simple@optimus.ietf.org; Tue, 02 Sep 2003 06:59: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 GAA10147 for ; Tue, 2 Sep 2003 06:59:00 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19u8sI-0001gq-00 for simple@ietf.org; Tue, 02 Sep 2003 06:59:02 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19u8sH-0001ge-00 for simple@ietf.org; Tue, 02 Sep 2003 06:59:01 -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 h82Ax2B29701 for ; Tue, 2 Sep 2003 13:59:03 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 2 Sep 2003 13:58:51 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 2 Sep 2003 13:58: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" Content-Transfer-Encoding: quoted-printable Subject: What is a tuple (was RE: [Simple] [Fwd: Re: NETCONF WG meeting minutes for IETF #57]) Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797052@esebe019.ntc.nokia.com> Thread-Topic: [Simple] [Fwd: Re: NETCONF WG meeting minutes for IETF #57] Thread-Index: AcNxFH9T8L5f6yBRRp2LLAM5QHtxlQALAssg To: Cc: , X-OriginalArrivalTime: 02 Sep 2003 10:58:50.0972 (UTC) FILETIME=[3141E1C0:01C37141] 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, 2 Sep 2003 13:58:50 +0300 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable If you want my opinion about the tuple issue, I think we should reverse = the decision that was make providing flexibility on how to represent = presence information in a tuple. We should on a single way to. We can display all the options to the SIMPLE community and take a = poll/vote. Rough consensus will give us an indication which one will it = be. Regards, Hisham > -----Original Message----- > From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Tuesday, September 02, 2003 8:38 AM > To: Khartabil Hisham (NMP/Helsinki) > Cc: simple@ietf.org; gk@ninebynine.org > Subject: Re: [Simple] [Fwd: Re: NETCONF WG meeting minutes=20 > for IETF #57] >=20 >=20 > It ties back into our ongoing debate about "what is a tuple". Its not=20 > that the PIDF XML has no semantics, its that the underlying=20 > "presence"=20 > of a user can map into a variety of different XML documents,=20 > depending=20 > on the underlying policy of the PA and presentity. Thus, if=20 > the desire=20 > is to have a filter that restricts geolocation inforamtion, the=20 > appropriate XPath expressions depend a lot on how the PA chooses to=20 > place the presence information into the presence document. As an=20 > example, the PA may use it to compute the "placetype" RPID attribute.=20 > Or, it may appear in some tuples, but not others. It may appear as a=20 > textual piece of a note, i.e., "at work". Xpath cannot be=20 > used to tell=20 > a PA "don't put geoloc data anywhere in the document". >=20 > More abstractly, and in the context of Graham's note, I believe there=20 > is an underling data model which has "raw" presence data, and then=20 > this data gets encoded into presence documents using PIDF. I believe=20 > filters are ultimately useful only in their application to this raw=20 > data. Since there is a gap between the raw data and its encoding into=20 > a PIDF document, the usage of Xpath expressions on the PIDF document=20 > doesnt seem right to me. >=20 > Thanks, > Jonathan R. >=20 > hisham.khartabil@nokia.com wrote: >=20 > > I don't buy it. Why would you define an XML schema who's syntax > > does not match the semantics? > >=20 > > I earlier bought the argument that XPath is too complicated to > > implement for a simple use case of just wanting to identify an > > element in an XML document, and thereafter agreed to provide some > > text in the I-D pointing to this issue and explaining the limited > > use of XPath in filtering. > >=20 > > /Hisham > >=20 > >=20 > >> -----Original Message----- From: ext Jonathan Rosenberg > >> [mailto:jdrosen@dynamicsoft.com] Sent: Friday, August 29, 2003 > >> 5:36 PM To: Simple WG; gk@ninebynine.org Subject: [Simple] [Fwd: > >> Re: NETCONF WG meeting minutes for IETF #57] > >>=20 > >>=20 > >> Graham Klyne posted this note on netconf that has some insights > >> which I think can benefit us. Pay attention to this statement: > >>=20 > >> Graham writes: > >>=20 > >>> I would be very wary about using XPath as the basis for > >>> selective access to XMLConf data. XPath, by design, provides > >>> selection on the syntactic structure of XML: it has been > >>> suggested elsewhere (e.g. in the netconf protocol document, > >>> IIRC) that the data model is separate from the protocol > >>> framework (which I think is a good approach). But the > >>> query/selection syntax should be related to the data model, not > >>> to the carrier syntax. I have seen difficulties arise with > >>> different XML-based applications where people tried to use > >>> XPath selection for an XML format used to carry a data model=20 > >>> that was somewhat different from the XML carrier syntax. If > >>> the data model does not map directly onto the XML syntax, then > >>> XPath selection may well prove inadequate to make appropriate > >>> selection in the configuration data. > >>=20 > >> I think this summarizes nicely the concerns I have had about > >> using xpath for filtering. I am also going to be removing it from > >> element identification in the next xcap-auth rev. > >>=20 > >> -Jonathan R. > >>=20 > >> -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza=20 > >> Chief Technology Officer Parsippany, NJ > >> 07054-2711 dynamicsoft jdrosen@dynamicsoft.com > >> FAX: (973) 952-5050 http://www.jdrosen.net > >> PHONE: (973) 952-5000 http://www.dynamicsoft.com > >>=20 > >=20 > >=20 >=20 > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Sep 2 09:58:58 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 JAA26864; Tue, 2 Sep 2003 09:58:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uBfv-000096-0D; Tue, 02 Sep 2003 09:58:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19u1CR-00027a-Tc for simple@optimus.ietf.org; Mon, 01 Sep 2003 22:47: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 WAA00524 for ; Mon, 1 Sep 2003 22:47:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19u1CM-0001qF-00 for simple@ietf.org; Mon, 01 Sep 2003 22:47:14 -0400 Received: from jay.songbird.com ([208.184.79.253]) by ietf-mx with esmtp (Exim 4.12) id 19tqvj-0006jx-00 for simple@ietf.org; Mon, 01 Sep 2003 11:49:23 -0400 Received: from Rincewind.ninebynine.org (jay.songbird.com [208.184.79.253]) by jay.songbird.com (8.11.6/8.11.3) with ESMTP id h81FnE004062; Mon, 1 Sep 2003 08:49:15 -0700 Message-Id: <5.1.0.14.2.20030901153204.00b88740@127.0.0.1> X-Sender: gk@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 To: , , From: Graham Klyne Subject: RE: [Simple] [Fwd: Re: NETCONF WG meeting minutes for IETF #57] In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB70179703A@esebe019.ntc.noki a.com> Mime-Version: 1.0 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: Mon, 01 Sep 2003 15:40:18 +0100 At 12:17 01/09/03 +0300, hisham.khartabil@nokia.com wrote: >I don't buy it. Why would you define an XML schema who's syntax does not >match the semantics? However you define an XML schema, you're still constrained to use XML's underlying annotated-tree syntax. It is possible to encode different (non-tree) data models using this syntax, but the standard XML tools may not be so useful in these cases. If your application data fits this model, then fine. In some cases, the XML syntactic model may be more complex than required (exemplified by debates about whether to use element content or attributes). In other cases, the basic model may not conform to the tree structure that underpins XML (e.g. any model which contains loops or merged paths). My comments were in no way an attack on using XML, or any of its tools, but simply pointing out that some of those tools (e.g. XPath) are not equally useful for all applications. (And, as noted by someone else, my comments were directed to a different application where I believe that XPath model may not be such a good fit.) #g -- At 12:17 01/09/03 +0300, hisham.khartabil@nokia.com wrote: >I don't buy it. Why would you define an XML schema who's syntax does not >match the semantics? > >I earlier bought the argument that XPath is too complicated to implement >for a simple use case of just wanting to identify an element in an XML >document, and thereafter agreed to provide some text in the I-D pointing >to this issue and explaining the limited use of XPath in filtering. > >/Hisham > > > -----Original Message----- > > From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > Sent: Friday, August 29, 2003 5:36 PM > > To: Simple WG; gk@ninebynine.org > > Subject: [Simple] [Fwd: Re: NETCONF WG meeting minutes for IETF #57] > > > > > > Graham Klyne posted this note on netconf that has some insights which > > I think can benefit us. Pay attention to this statement: > > > > Graham writes: > > > I would be very wary about using XPath as the basis for selective > > > access to XMLConf data. XPath, by design, provides selection on > > > the syntactic structure of XML: it has been suggested elsewhere > > > (e.g. in the netconf protocol document, IIRC) that the data model > > > is separate from the protocol framework (which I think is a good > > > approach). But the query/selection syntax should be related to the > > > data model, not to the carrier syntax. I have seen difficulties > > > arise with different XML-based applications where people tried to > > > use XPath selection for an XML format used to carry a data model > > > that was somewhat different from the XML carrier syntax. If the > > > data model does not map directly onto the XML syntax, then XPath > > > selection may well prove inadequate to make appropriate selection > > > in the configuration data. > > > > I think this summarizes nicely the concerns I have had about using > > xpath for filtering. I am also going to be removing it from element > > identification in the next xcap-auth rev. > > > > -Jonathan R. > > > > -- > > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > > Chief Technology Officer Parsippany, NJ 07054-2711 > > dynamicsoft > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > http://www.jdrosen.net PHONE: (973) 952-5000 > > http://www.dynamicsoft.com > > ------------ Graham Klyne GK@NineByNine.org _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Sep 2 09:59:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26958 for ; Tue, 2 Sep 2003 09:59:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uBgY-0000pz-4f for simple-archive@odin.ietf.org; Tue, 02 Sep 2003 09:59:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h82Dx6wG003208 for simple-archive@odin.ietf.org; Tue, 2 Sep 2003 09:59:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uBgX-0000pJ-Q1 for simple-web-archive@optimus.ietf.org; Tue, 02 Sep 2003 09:59:05 -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 JAA26864; Tue, 2 Sep 2003 09:58:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uBfv-000096-0D; Tue, 02 Sep 2003 09:58:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19u1CR-00027a-Tc for simple@optimus.ietf.org; Mon, 01 Sep 2003 22:47: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 WAA00524 for ; Mon, 1 Sep 2003 22:47:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19u1CM-0001qF-00 for simple@ietf.org; Mon, 01 Sep 2003 22:47:14 -0400 Received: from jay.songbird.com ([208.184.79.253]) by ietf-mx with esmtp (Exim 4.12) id 19tqvj-0006jx-00 for simple@ietf.org; Mon, 01 Sep 2003 11:49:23 -0400 Received: from Rincewind.ninebynine.org (jay.songbird.com [208.184.79.253]) by jay.songbird.com (8.11.6/8.11.3) with ESMTP id h81FnE004062; Mon, 1 Sep 2003 08:49:15 -0700 Message-Id: <5.1.0.14.2.20030901153204.00b88740@127.0.0.1> X-Sender: gk@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 To: , , From: Graham Klyne Subject: RE: [Simple] [Fwd: Re: NETCONF WG meeting minutes for IETF #57] In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB70179703A@esebe019.ntc.noki a.com> Mime-Version: 1.0 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: Mon, 01 Sep 2003 15:40:18 +0100 At 12:17 01/09/03 +0300, hisham.khartabil@nokia.com wrote: >I don't buy it. Why would you define an XML schema who's syntax does not >match the semantics? However you define an XML schema, you're still constrained to use XML's underlying annotated-tree syntax. It is possible to encode different (non-tree) data models using this syntax, but the standard XML tools may not be so useful in these cases. If your application data fits this model, then fine. In some cases, the XML syntactic model may be more complex than required (exemplified by debates about whether to use element content or attributes). In other cases, the basic model may not conform to the tree structure that underpins XML (e.g. any model which contains loops or merged paths). My comments were in no way an attack on using XML, or any of its tools, but simply pointing out that some of those tools (e.g. XPath) are not equally useful for all applications. (And, as noted by someone else, my comments were directed to a different application where I believe that XPath model may not be such a good fit.) #g -- At 12:17 01/09/03 +0300, hisham.khartabil@nokia.com wrote: >I don't buy it. Why would you define an XML schema who's syntax does not >match the semantics? > >I earlier bought the argument that XPath is too complicated to implement >for a simple use case of just wanting to identify an element in an XML >document, and thereafter agreed to provide some text in the I-D pointing >to this issue and explaining the limited use of XPath in filtering. > >/Hisham > > > -----Original Message----- > > From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > Sent: Friday, August 29, 2003 5:36 PM > > To: Simple WG; gk@ninebynine.org > > Subject: [Simple] [Fwd: Re: NETCONF WG meeting minutes for IETF #57] > > > > > > Graham Klyne posted this note on netconf that has some insights which > > I think can benefit us. Pay attention to this statement: > > > > Graham writes: > > > I would be very wary about using XPath as the basis for selective > > > access to XMLConf data. XPath, by design, provides selection on > > > the syntactic structure of XML: it has been suggested elsewhere > > > (e.g. in the netconf protocol document, IIRC) that the data model > > > is separate from the protocol framework (which I think is a good > > > approach). But the query/selection syntax should be related to the > > > data model, not to the carrier syntax. I have seen difficulties > > > arise with different XML-based applications where people tried to > > > use XPath selection for an XML format used to carry a data model > > > that was somewhat different from the XML carrier syntax. If the > > > data model does not map directly onto the XML syntax, then XPath > > > selection may well prove inadequate to make appropriate selection > > > in the configuration data. > > > > I think this summarizes nicely the concerns I have had about using > > xpath for filtering. I am also going to be removing it from element > > identification in the next xcap-auth rev. > > > > -Jonathan R. > > > > -- > > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > > Chief Technology Officer Parsippany, NJ 07054-2711 > > dynamicsoft > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > http://www.jdrosen.net PHONE: (973) 952-5000 > > http://www.dynamicsoft.com > > ------------ Graham Klyne GK@NineByNine.org _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Sep 2 10:03:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27846; Tue, 2 Sep 2003 10:03:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uBkM-0002XN-9H; Tue, 02 Sep 2003 10:03:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uBjw-0002T6-4d for simple@optimus.ietf.org; Tue, 02 Sep 2003 10:02:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27660 for ; Tue, 2 Sep 2003 10:02: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 19uBjt-0000sp-00 for simple@ietf.org; Tue, 02 Sep 2003 10:02:33 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19uBbK-0000NP-00 for simple@ietf.org; Tue, 02 Sep 2003 09:53: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 h82DqqB06246 for ; Tue, 2 Sep 2003 16:52:56 +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, 2 Sep 2003 16:52:52 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 2 Sep 2003 16:52: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" Content-Transfer-Encoding: quoted-printable Subject: RE: What is a tuple (was RE: [Simple] [Fwd: Re: NETCONF WG meeting minutes for IETF #57]) Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797057@esebe019.ntc.nokia.com> Thread-Topic: [Simple] [Fwd: Re: NETCONF WG meeting minutes for IETF #57] Thread-Index: AcNxFH9T8L5f6yBRRp2LLAM5QHtxlQALAssgAAYle+A= To: , Cc: , X-OriginalArrivalTime: 02 Sep 2003 13:52:52.0259 (UTC) FILETIME=[80BFD730:01C37159] 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, 2 Sep 2003 16:52:51 +0300 Content-Transfer-Encoding: quoted-printable (making what I said more readable) If you want my opinion about the tuple issue, I think we should reverse = the decision that was made that provides flexibility on how to represent = presence information in a tuple. We should agree on a single way to = represent this info. We can provide all the options to the SIMPLE community and take a = poll/vote. Rough consensus will give us an indication which one will be = chosen. Regards, Hisham > -----Original Message----- > From: ext hisham.khartabil@nokia.com=20 > [mailto:hisham.khartabil@nokia.com] > Sent: Tuesday, September 02, 2003 1:59 PM > To: jdrosen@dynamicsoft.com > Cc: simple@ietf.org; gk@ninebynine.org > Subject: What is a tuple (was RE: [Simple] [Fwd: Re: NETCONF=20 > WG meeting > minutes for IETF #57]) >=20 >=20 > If you want my opinion about the tuple issue, I think we=20 > should reverse the decision that was make providing=20 > flexibility on how to represent presence information in a=20 > tuple. We should on a single way to. >=20 > We can display all the options to the SIMPLE community and=20 > take a poll/vote. Rough consensus will give us an indication=20 > which one will it be. >=20 > Regards, > Hisham >=20 > > -----Original Message----- > > From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > Sent: Tuesday, September 02, 2003 8:38 AM > > To: Khartabil Hisham (NMP/Helsinki) > > Cc: simple@ietf.org; gk@ninebynine.org > > Subject: Re: [Simple] [Fwd: Re: NETCONF WG meeting minutes=20 > > for IETF #57] > >=20 > >=20 > > It ties back into our ongoing debate about "what is a=20 > tuple". Its not=20 > > that the PIDF XML has no semantics, its that the underlying=20 > > "presence"=20 > > of a user can map into a variety of different XML documents,=20 > > depending=20 > > on the underlying policy of the PA and presentity. Thus, if=20 > > the desire=20 > > is to have a filter that restricts geolocation inforamtion, the=20 > > appropriate XPath expressions depend a lot on how the PA chooses to=20 > > place the presence information into the presence document. As an=20 > > example, the PA may use it to compute the "placetype" RPID=20 > attribute.=20 > > Or, it may appear in some tuples, but not others. It may=20 > appear as a=20 > > textual piece of a note, i.e., "at work". Xpath cannot be=20 > > used to tell=20 > > a PA "don't put geoloc data anywhere in the document". > >=20 > > More abstractly, and in the context of Graham's note, I=20 > believe there=20 > > is an underling data model which has "raw" presence data, and then=20 > > this data gets encoded into presence documents using PIDF.=20 > I believe=20 > > filters are ultimately useful only in their application to this raw=20 > > data. Since there is a gap between the raw data and its=20 > encoding into=20 > > a PIDF document, the usage of Xpath expressions on the PIDF=20 > document=20 > > doesnt seem right to me. > >=20 > > Thanks, > > Jonathan R. > >=20 > > hisham.khartabil@nokia.com wrote: > >=20 > > > I don't buy it. Why would you define an XML schema who's syntax > > > does not match the semantics? > > >=20 > > > I earlier bought the argument that XPath is too complicated to > > > implement for a simple use case of just wanting to identify an > > > element in an XML document, and thereafter agreed to provide some > > > text in the I-D pointing to this issue and explaining the limited > > > use of XPath in filtering. > > >=20 > > > /Hisham > > >=20 > > >=20 > > >> -----Original Message----- From: ext Jonathan Rosenberg > > >> [mailto:jdrosen@dynamicsoft.com] Sent: Friday, August 29, 2003 > > >> 5:36 PM To: Simple WG; gk@ninebynine.org Subject: [Simple] [Fwd: > > >> Re: NETCONF WG meeting minutes for IETF #57] > > >>=20 > > >>=20 > > >> Graham Klyne posted this note on netconf that has some insights > > >> which I think can benefit us. Pay attention to this statement: > > >>=20 > > >> Graham writes: > > >>=20 > > >>> I would be very wary about using XPath as the basis for > > >>> selective access to XMLConf data. XPath, by design, provides > > >>> selection on the syntactic structure of XML: it has been > > >>> suggested elsewhere (e.g. in the netconf protocol document, > > >>> IIRC) that the data model is separate from the protocol > > >>> framework (which I think is a good approach). But the > > >>> query/selection syntax should be related to the data model, not > > >>> to the carrier syntax. I have seen difficulties arise with > > >>> different XML-based applications where people tried to use > > >>> XPath selection for an XML format used to carry a data model=20 > > >>> that was somewhat different from the XML carrier syntax. If > > >>> the data model does not map directly onto the XML syntax, then > > >>> XPath selection may well prove inadequate to make appropriate > > >>> selection in the configuration data. > > >>=20 > > >> I think this summarizes nicely the concerns I have had about > > >> using xpath for filtering. I am also going to be removing it from > > >> element identification in the next xcap-auth rev. > > >>=20 > > >> -Jonathan R. > > >>=20 > > >> -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza=20 > > >> Chief Technology Officer Parsippany, NJ > > >> 07054-2711 dynamicsoft jdrosen@dynamicsoft.com > > >> FAX: (973) 952-5050 http://www.jdrosen.net > > >> PHONE: (973) 952-5000 http://www.dynamicsoft.com > > >>=20 > > >=20 > > >=20 > >=20 > > --=20 > > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > > Chief Technology Officer Parsippany, NJ=20 > 07054-2711 > > dynamicsoft > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > http://www.jdrosen.net PHONE: (973) 952-5000 > > http://www.dynamicsoft.com > >=20 > >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Sep 2 10:04:04 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27904 for ; Tue, 2 Sep 2003 10:04:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uBkx-0002o1-L0 for simple-archive@odin.ietf.org; Tue, 02 Sep 2003 10:03:39 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h82E3dpD010773 for simple-archive@odin.ietf.org; Tue, 2 Sep 2003 10:03:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uBkx-0002ng-GH for simple-web-archive@optimus.ietf.org; Tue, 02 Sep 2003 10:03: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 KAA27846; Tue, 2 Sep 2003 10:03:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uBkM-0002XN-9H; Tue, 02 Sep 2003 10:03:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uBjw-0002T6-4d for simple@optimus.ietf.org; Tue, 02 Sep 2003 10:02:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27660 for ; Tue, 2 Sep 2003 10:02: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 19uBjt-0000sp-00 for simple@ietf.org; Tue, 02 Sep 2003 10:02:33 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19uBbK-0000NP-00 for simple@ietf.org; Tue, 02 Sep 2003 09:53: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 h82DqqB06246 for ; Tue, 2 Sep 2003 16:52:56 +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, 2 Sep 2003 16:52:52 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 2 Sep 2003 16:52: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" Content-Transfer-Encoding: quoted-printable Subject: RE: What is a tuple (was RE: [Simple] [Fwd: Re: NETCONF WG meeting minutes for IETF #57]) Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797057@esebe019.ntc.nokia.com> Thread-Topic: [Simple] [Fwd: Re: NETCONF WG meeting minutes for IETF #57] Thread-Index: AcNxFH9T8L5f6yBRRp2LLAM5QHtxlQALAssgAAYle+A= To: , Cc: , X-OriginalArrivalTime: 02 Sep 2003 13:52:52.0259 (UTC) FILETIME=[80BFD730:01C37159] 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, 2 Sep 2003 16:52:51 +0300 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable (making what I said more readable) If you want my opinion about the tuple issue, I think we should reverse = the decision that was made that provides flexibility on how to represent = presence information in a tuple. We should agree on a single way to = represent this info. We can provide all the options to the SIMPLE community and take a = poll/vote. Rough consensus will give us an indication which one will be = chosen. Regards, Hisham > -----Original Message----- > From: ext hisham.khartabil@nokia.com=20 > [mailto:hisham.khartabil@nokia.com] > Sent: Tuesday, September 02, 2003 1:59 PM > To: jdrosen@dynamicsoft.com > Cc: simple@ietf.org; gk@ninebynine.org > Subject: What is a tuple (was RE: [Simple] [Fwd: Re: NETCONF=20 > WG meeting > minutes for IETF #57]) >=20 >=20 > If you want my opinion about the tuple issue, I think we=20 > should reverse the decision that was make providing=20 > flexibility on how to represent presence information in a=20 > tuple. We should on a single way to. >=20 > We can display all the options to the SIMPLE community and=20 > take a poll/vote. Rough consensus will give us an indication=20 > which one will it be. >=20 > Regards, > Hisham >=20 > > -----Original Message----- > > From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > Sent: Tuesday, September 02, 2003 8:38 AM > > To: Khartabil Hisham (NMP/Helsinki) > > Cc: simple@ietf.org; gk@ninebynine.org > > Subject: Re: [Simple] [Fwd: Re: NETCONF WG meeting minutes=20 > > for IETF #57] > >=20 > >=20 > > It ties back into our ongoing debate about "what is a=20 > tuple". Its not=20 > > that the PIDF XML has no semantics, its that the underlying=20 > > "presence"=20 > > of a user can map into a variety of different XML documents,=20 > > depending=20 > > on the underlying policy of the PA and presentity. Thus, if=20 > > the desire=20 > > is to have a filter that restricts geolocation inforamtion, the=20 > > appropriate XPath expressions depend a lot on how the PA chooses to=20 > > place the presence information into the presence document. As an=20 > > example, the PA may use it to compute the "placetype" RPID=20 > attribute.=20 > > Or, it may appear in some tuples, but not others. It may=20 > appear as a=20 > > textual piece of a note, i.e., "at work". Xpath cannot be=20 > > used to tell=20 > > a PA "don't put geoloc data anywhere in the document". > >=20 > > More abstractly, and in the context of Graham's note, I=20 > believe there=20 > > is an underling data model which has "raw" presence data, and then=20 > > this data gets encoded into presence documents using PIDF.=20 > I believe=20 > > filters are ultimately useful only in their application to this raw=20 > > data. Since there is a gap between the raw data and its=20 > encoding into=20 > > a PIDF document, the usage of Xpath expressions on the PIDF=20 > document=20 > > doesnt seem right to me. > >=20 > > Thanks, > > Jonathan R. > >=20 > > hisham.khartabil@nokia.com wrote: > >=20 > > > I don't buy it. Why would you define an XML schema who's syntax > > > does not match the semantics? > > >=20 > > > I earlier bought the argument that XPath is too complicated to > > > implement for a simple use case of just wanting to identify an > > > element in an XML document, and thereafter agreed to provide some > > > text in the I-D pointing to this issue and explaining the limited > > > use of XPath in filtering. > > >=20 > > > /Hisham > > >=20 > > >=20 > > >> -----Original Message----- From: ext Jonathan Rosenberg > > >> [mailto:jdrosen@dynamicsoft.com] Sent: Friday, August 29, 2003 > > >> 5:36 PM To: Simple WG; gk@ninebynine.org Subject: [Simple] [Fwd: > > >> Re: NETCONF WG meeting minutes for IETF #57] > > >>=20 > > >>=20 > > >> Graham Klyne posted this note on netconf that has some insights > > >> which I think can benefit us. Pay attention to this statement: > > >>=20 > > >> Graham writes: > > >>=20 > > >>> I would be very wary about using XPath as the basis for > > >>> selective access to XMLConf data. XPath, by design, provides > > >>> selection on the syntactic structure of XML: it has been > > >>> suggested elsewhere (e.g. in the netconf protocol document, > > >>> IIRC) that the data model is separate from the protocol > > >>> framework (which I think is a good approach). But the > > >>> query/selection syntax should be related to the data model, not > > >>> to the carrier syntax. I have seen difficulties arise with > > >>> different XML-based applications where people tried to use > > >>> XPath selection for an XML format used to carry a data model=20 > > >>> that was somewhat different from the XML carrier syntax. If > > >>> the data model does not map directly onto the XML syntax, then > > >>> XPath selection may well prove inadequate to make appropriate > > >>> selection in the configuration data. > > >>=20 > > >> I think this summarizes nicely the concerns I have had about > > >> using xpath for filtering. I am also going to be removing it from > > >> element identification in the next xcap-auth rev. > > >>=20 > > >> -Jonathan R. > > >>=20 > > >> -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza=20 > > >> Chief Technology Officer Parsippany, NJ > > >> 07054-2711 dynamicsoft jdrosen@dynamicsoft.com > > >> FAX: (973) 952-5050 http://www.jdrosen.net > > >> PHONE: (973) 952-5000 http://www.dynamicsoft.com > > >>=20 > > >=20 > > >=20 > >=20 > > --=20 > > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > > Chief Technology Officer Parsippany, NJ=20 > 07054-2711 > > dynamicsoft > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > http://www.jdrosen.net PHONE: (973) 952-5000 > > http://www.dynamicsoft.com > >=20 > >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Sep 2 10:54: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 KAA03713; Tue, 2 Sep 2003 10:54:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uCYE-0003F2-00; Tue, 02 Sep 2003 10:54:34 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19uCWm-000316-00; Tue, 02 Sep 2003 10:53:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uCWk-00073i-B4; Tue, 02 Sep 2003 10:53:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uCWU-00071t-Gx for simple@optimus.ietf.org; Tue, 02 Sep 2003 10:52: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 KAA03146 for ; Tue, 2 Sep 2003 10:52:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uCWS-0002vh-00 for simple@ietf.org; Tue, 02 Sep 2003 10:52:44 -0400 Received: from ns.execdsl.net ([208.184.15.238] helo=EXECDSL.COM) by ietf-mx with esmtp (Exim 4.12) id 19uCTG-0002sJ-00 for simple@ietf.org; Tue, 02 Sep 2003 10:49:27 -0400 Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 5330697 for simple@ietf.org; Tue, 02 Sep 2003 10:49:21 -0400 Message-Id: <5.1.0.14.0.20030902104201.018b0700@mail.stevecrocker.com> X-Sender: joel@stevecrocker.com@mail.stevecrocker.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 To: simple@ietf.org From: "Joel M. Halpern" Subject: Re: [Simple] [Fwd: Re: NETCONF WG meeting minutes for IETF #57] In-Reply-To: <3F542CB5.7040006@dynamicsoft.com> References: <2038BCC78B1AD641891A0D1AE133DBB70179703A@esebe019.ntc.nokia.com> <2038BCC78B1AD641891A0D1AE133DBB70179703A@esebe019.ntc.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 02 Sep 2003 10:48:39 -0400 While I can understand why one would want to apply filters to the underlying "raw" data, I am not sure that this is achievable. To be blunt, the representation used by the filter is a specific representation in some specific implementatation model and not the raw underlying data model. To communicate a filter against the data, we will be defining a representation. That representation may not be the PIDF XML representation. It may not be the "tuple" representation. But it is a representation. And in fact, if that representation is the one best suited to defining filters, it would seem that it is also the one that you want to use to communicate the data itself in. (After all, if the logical abstraction for the filtering is not the same as for any given tuple assembly, why is that tuple assembly right for the receiver of the tuple.) To phrase this differently, if the prsence filters are not going to be against the PIDF tuples, then it would seem that the presence data ought not be against the PIDF tuples. If PIDF presence tuples are the right representation, then it would seem that the filters ought to be against that. And if they are, it would seem that XPATH is suitable. Yours, Joel PS: Looking at a different part of the puzzle, xpath reference for the buddy list update looks lie a very good match to the problem and the representation. At 01:37 AM 9/2/2003 -0400, Jonathan Rosenberg wrote: >It ties back into our ongoing debate about "what is a tuple". Its not that >the PIDF XML has no semantics, its that the underlying "presence" of a >user can map into a variety of different XML documents, depending on the >underlying policy of the PA and presentity. Thus, if the desire is to >have a filter that restricts geolocation inforamtion, the appropriate >XPath expressions depend a lot on how the PA chooses to place the presence >information into the presence document. As an example, the PA may use it >to compute the "placetype" RPID attribute. Or, it may appear in some >tuples, but not others. It may appear as a textual piece of a note, i.e., >"at work". Xpath cannot be used to tell a PA "don't put geoloc data >anywhere in the document". > >More abstractly, and in the context of Graham's note, I believe there is >an underling data model which has "raw" presence data, and then this data >gets encoded into presence documents using PIDF. I believe filters are >ultimately useful only in their application to this raw data. Since there >is a gap between the raw data and its encoding into a PIDF document, the >usage of Xpath expressions on the PIDF document doesnt seem right to me. > >Thanks, >Jonathan R. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Sep 2 10:55:02 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 KAA03918 for ; Tue, 2 Sep 2003 10:55:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uCYI-0007Nn-Bm for simple-archive@odin.ietf.org; Tue, 02 Sep 2003 10:54:38 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h82Escuq028377 for simple-archive@odin.ietf.org; Tue, 2 Sep 2003 10:54:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uCYH-0007Nb-TV for simple-web-archive@optimus.ietf.org; Tue, 02 Sep 2003 10: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 KAA03713; Tue, 2 Sep 2003 10:54:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uCYE-0003F2-00; Tue, 02 Sep 2003 10:54:34 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19uCWm-000316-00; Tue, 02 Sep 2003 10:53:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uCWk-00073i-B4; Tue, 02 Sep 2003 10:53:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uCWU-00071t-Gx for simple@optimus.ietf.org; Tue, 02 Sep 2003 10:52: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 KAA03146 for ; Tue, 2 Sep 2003 10:52:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uCWS-0002vh-00 for simple@ietf.org; Tue, 02 Sep 2003 10:52:44 -0400 Received: from ns.execdsl.net ([208.184.15.238] helo=EXECDSL.COM) by ietf-mx with esmtp (Exim 4.12) id 19uCTG-0002sJ-00 for simple@ietf.org; Tue, 02 Sep 2003 10:49:27 -0400 Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 5330697 for simple@ietf.org; Tue, 02 Sep 2003 10:49:21 -0400 Message-Id: <5.1.0.14.0.20030902104201.018b0700@mail.stevecrocker.com> X-Sender: joel@stevecrocker.com@mail.stevecrocker.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 To: simple@ietf.org From: "Joel M. Halpern" Subject: Re: [Simple] [Fwd: Re: NETCONF WG meeting minutes for IETF #57] In-Reply-To: <3F542CB5.7040006@dynamicsoft.com> References: <2038BCC78B1AD641891A0D1AE133DBB70179703A@esebe019.ntc.nokia.com> <2038BCC78B1AD641891A0D1AE133DBB70179703A@esebe019.ntc.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 02 Sep 2003 10:48:39 -0400 While I can understand why one would want to apply filters to the underlying "raw" data, I am not sure that this is achievable. To be blunt, the representation used by the filter is a specific representation in some specific implementatation model and not the raw underlying data model. To communicate a filter against the data, we will be defining a representation. That representation may not be the PIDF XML representation. It may not be the "tuple" representation. But it is a representation. And in fact, if that representation is the one best suited to defining filters, it would seem that it is also the one that you want to use to communicate the data itself in. (After all, if the logical abstraction for the filtering is not the same as for any given tuple assembly, why is that tuple assembly right for the receiver of the tuple.) To phrase this differently, if the prsence filters are not going to be against the PIDF tuples, then it would seem that the presence data ought not be against the PIDF tuples. If PIDF presence tuples are the right representation, then it would seem that the filters ought to be against that. And if they are, it would seem that XPATH is suitable. Yours, Joel PS: Looking at a different part of the puzzle, xpath reference for the buddy list update looks lie a very good match to the problem and the representation. At 01:37 AM 9/2/2003 -0400, Jonathan Rosenberg wrote: >It ties back into our ongoing debate about "what is a tuple". Its not that >the PIDF XML has no semantics, its that the underlying "presence" of a >user can map into a variety of different XML documents, depending on the >underlying policy of the PA and presentity. Thus, if the desire is to >have a filter that restricts geolocation inforamtion, the appropriate >XPath expressions depend a lot on how the PA chooses to place the presence >information into the presence document. As an example, the PA may use it >to compute the "placetype" RPID attribute. Or, it may appear in some >tuples, but not others. It may appear as a textual piece of a note, i.e., >"at work". Xpath cannot be used to tell a PA "don't put geoloc data >anywhere in the document". > >More abstractly, and in the context of Graham's note, I believe there is >an underling data model which has "raw" presence data, and then this data >gets encoded into presence documents using PIDF. I believe filters are >ultimately useful only in their application to this raw data. Since there >is a gap between the raw data and its encoding into a PIDF document, the >usage of Xpath expressions on the PIDF document doesnt seem right to me. > >Thanks, >Jonathan R. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Sep 2 11:46:59 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09601; Tue, 2 Sep 2003 11:46:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uDN1-0005xP-00; Tue, 02 Sep 2003 11:47:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19uDN0-0005xM-00; Tue, 02 Sep 2003 11:47:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uDMz-0003j5-0S; Tue, 02 Sep 2003 11:47:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uDMD-0003hD-HZ for simple@optimus.ietf.org; Tue, 02 Sep 2003 11:46: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 LAA09524 for ; Tue, 2 Sep 2003 11:46:07 -0400 (EDT) From: Markus.Isomaki@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uDMC-0005vD-00 for simple@ietf.org; Tue, 02 Sep 2003 11:46:12 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19uDMA-0005us-00 for simple@ietf.org; Tue, 02 Sep 2003 11:46:10 -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 h82Fk4B21684 for ; Tue, 2 Sep 2003 18:46:07 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 2 Sep 2003 18:46:02 +0300 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 2 Sep 2003 18:46:03 +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] [Fwd: Re: NETCONF WG meeting minutes for IETF #57] Message-ID: Thread-Topic: [Simple] [Fwd: Re: NETCONF WG meeting minutes for IETF #57] Thread-Index: AcNxWl77qQrZd/YvRPK4ueRQsDfvRAADiWew To: , , , X-OriginalArrivalTime: 02 Sep 2003 15:46:03.0030 (UTC) FILETIME=[505D4360:01C37169] 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, 2 Sep 2003 18:46:02 +0300 Content-Transfer-Encoding: quoted-printable Hi,=20 See inline: > -----Original Message----- > From: ext Graham Klyne [mailto:gk@ninebynine.org] > Sent: 01 September, 2003 17:40 > To: Khartabil Hisham (NMP/Helsinki); jdrosen@dynamicsoft.com; > simple@ietf.org > Subject: RE: [Simple] [Fwd: Re: NETCONF WG meeting minutes=20 > for IETF #57] >=20 >=20 > At 12:17 01/09/03 +0300, hisham.khartabil@nokia.com wrote: > >I don't buy it. Why would you define an XML schema who's=20 > syntax does not=20 > >match the semantics? >=20 > However you define an XML schema, you're still constrained to=20 > use XML's=20 > underlying annotated-tree syntax. It is possible to encode different=20 > (non-tree) data models using this syntax, but the standard=20 > XML tools may=20 > not be so useful in these cases. >=20 > If your application data fits this model, then fine. >=20 The concrete problem that SIMPLE WG is trying to solve is related to = presence information. As far as I've seen, nobody has had any issues why = XML would not be good enough for that. For this reason I would conclude = that the problems related to XPath are not relevant to the problem at = hand. Markus=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Sep 2 11:47:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09673 for ; Tue, 2 Sep 2003 11:47: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 19uDN3-0003kK-Ok for simple-archive@odin.ietf.org; Tue, 02 Sep 2003 11:47:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h82Fl5rw014394 for simple-archive@odin.ietf.org; Tue, 2 Sep 2003 11:47:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uDN3-0003k5-Ki for simple-web-archive@optimus.ietf.org; Tue, 02 Sep 2003 11:47: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 LAA09601; Tue, 2 Sep 2003 11:46:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uDN1-0005xP-00; Tue, 02 Sep 2003 11:47:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19uDN0-0005xM-00; Tue, 02 Sep 2003 11:47:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uDMz-0003j5-0S; Tue, 02 Sep 2003 11:47:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uDMD-0003hD-HZ for simple@optimus.ietf.org; Tue, 02 Sep 2003 11:46: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 LAA09524 for ; Tue, 2 Sep 2003 11:46:07 -0400 (EDT) From: Markus.Isomaki@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uDMC-0005vD-00 for simple@ietf.org; Tue, 02 Sep 2003 11:46:12 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19uDMA-0005us-00 for simple@ietf.org; Tue, 02 Sep 2003 11:46:10 -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 h82Fk4B21684 for ; Tue, 2 Sep 2003 18:46:07 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 2 Sep 2003 18:46:02 +0300 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 2 Sep 2003 18:46:03 +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] [Fwd: Re: NETCONF WG meeting minutes for IETF #57] Message-ID: Thread-Topic: [Simple] [Fwd: Re: NETCONF WG meeting minutes for IETF #57] Thread-Index: AcNxWl77qQrZd/YvRPK4ueRQsDfvRAADiWew To: , , , X-OriginalArrivalTime: 02 Sep 2003 15:46:03.0030 (UTC) FILETIME=[505D4360:01C37169] 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, 2 Sep 2003 18:46:02 +0300 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi,=20 See inline: > -----Original Message----- > From: ext Graham Klyne [mailto:gk@ninebynine.org] > Sent: 01 September, 2003 17:40 > To: Khartabil Hisham (NMP/Helsinki); jdrosen@dynamicsoft.com; > simple@ietf.org > Subject: RE: [Simple] [Fwd: Re: NETCONF WG meeting minutes=20 > for IETF #57] >=20 >=20 > At 12:17 01/09/03 +0300, hisham.khartabil@nokia.com wrote: > >I don't buy it. Why would you define an XML schema who's=20 > syntax does not=20 > >match the semantics? >=20 > However you define an XML schema, you're still constrained to=20 > use XML's=20 > underlying annotated-tree syntax. It is possible to encode different=20 > (non-tree) data models using this syntax, but the standard=20 > XML tools may=20 > not be so useful in these cases. >=20 > If your application data fits this model, then fine. >=20 The concrete problem that SIMPLE WG is trying to solve is related to = presence information. As far as I've seen, nobody has had any issues why = XML would not be good enough for that. For this reason I would conclude = that the problems related to XPath are not relevant to the problem at = hand. Markus=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Sep 2 12:35: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 MAA12938; Tue, 2 Sep 2003 12:35:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uE7h-0007EC-00; Tue, 02 Sep 2003 12:35:17 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19uE7h-0007E9-00; Tue, 02 Sep 2003 12: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 19uE7S-0006Yy-6v; Tue, 02 Sep 2003 12:35:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uE6X-0006YE-Da for simple@optimus.ietf.org; Tue, 02 Sep 2003 12:34:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12893 for ; Tue, 2 Sep 2003 12:33:58 -0400 (EDT) From: aki.niemi@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uE6V-0007D3-00 for simple@ietf.org; Tue, 02 Sep 2003 12:34:03 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19uE6T-0007Cp-00 for simple@ietf.org; Tue, 02 Sep 2003 12:34:02 -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 h82GXa412101 for ; Tue, 2 Sep 2003 19:33:45 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 2 Sep 2003 19:33:36 +0300 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 2 Sep 2003 19:33:36 +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] Comments on draft-ietf-simple-publish Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD90194535D@esebe013.ntc.nokia.com> Thread-Topic: [Simple] Comments on draft-ietf-simple-publish Thread-Index: AcNxbHs+romuMX79Rsqe0OEi1xbhLgAAEIhg To: Cc: , X-OriginalArrivalTime: 02 Sep 2003 16:33:36.0651 (UTC) FILETIME=[F54145B0:01C3716F] 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, 2 Sep 2003 19:33:36 +0300 Content-Transfer-Encoding: quoted-printable Hi Jonathan, Seems like I never responded to this email, so here goes - inline. Jonathan Rosenberg wrote: > Some comments: >=20 > * Section 4 sounds like it is trying to impose guidelines=20 > for some kind of registration procedure that event packages=20 > need to follow. But, it doesn't explicitly state that. If=20 > the intent is to do that (and I think it is), you should=20 > follow the basic structure of rfc3265 in terms of how its done. It certainly tries to do just that. The next version will try to be more = closely aligned with the way RFC 3265 puts it. =20 > * Section 4 introduces requirements that an event package=20 > has to satisfy in order to make use of publish. In some=20 > places, it does that by referencing the publish requirements=20 > doc. That doc is informational, but you effectively=20 > promoting those requirements to normative in your usage.=20 > That will be a problem. I recommend that you instead include=20 > the specific requirements from the publish requirements doc=20 > into publish that define things an event package has to declare. Good point. The normative nature of the requirements doc is removed. >=20 > * section 5 - subscribing to the AOR will not likely give=20 > you the same information that was published. Will add a note to that effect. The problem is that this is as close we = can get with the current PUBLISH to fulfilling requirement 14 of the = publish requirements. Of course, adding such a mechanism should be = possible later on if needed. >=20 > * section 5 says: >=20 > > Expires: PUBLISH requests SHOULD contain a single Expires header > > field. This value indicates the lifetime of the event=20 > state being > > published by this request. A special value of "0"=20 > indicates the > > removal of any prior soft state established by a prior PUBLISH > > request from this EPA. >=20 > I don't think its "any prior soft state" - its the specific=20 > soft-state identified by an etag, no? True, fixed that. =20 > Section 5.5 doesnt say anything about this either. For=20 > deletion, when there is not body (and thus no tuple id),=20 > there needs to be a way to identify the tuple being deleted. All of chapters 5.3, 5.4 and 5.5 will have some text to clarify the = etags usage in the next rev. =20 > * The numbered steps in section 6 repeat the UA processing=20 > in rfc3261. They shouldn't be there. You should just=20 > reference rfc3261, and augment the steps there with=20 > publish-specific operations. Fixed in the next rev. =20 > * Bullet 9 of section 6: >=20 > >the source of the publication (From > > URI), and the version of the publication. >=20 > why is the From needed? Not needed, so removed. > * also in step 9: >=20 >=20 > >For new publications, i.e., publications without a version > > precondition, the ESC MUST generate a locally unique > > entity-tag, and store it, replacing any existing=20 > entity-tags > > stored for that particular event state. The new=20 > entity-tag >=20 >=20 > I don't like this usage of "new". To me, new means that=20 > there is no published data for this tuple. But, you are=20 > using new to mean that the publication doesnt' have a=20 > precondition. That doesnt seem to fit the meaning of "new". This will also be reworded. > * Table 3 - need to indiate its applicability to other methods. Will add that.=20 =20 > * security considerations section: you should discuss=20 > specific threats that PUBLISH introduces, and then from=20 > these make recommendations (such as SHOULD authenticate).=20 > YOu probably want to talk about sensitivity of published=20 > data, and say something about sips. I will try to add text to this effect, but this section may need to be = revisited by someone more security-savvy later on. >=20 > On this open issue: >=20 > >o Atomicity of publication. Should the segments of event state > > (presence tuples) be sent in separate PUBLISH=20 > requests or is it > > enough to treat these as implicitly separate=20 > publication requests? >=20 >=20 > I vaguely recall at the interim meeting that the idea was=20 > floated that for presence, there were two separate things=20 > one could publish. One was a full presence document, in=20 > which case there is no "partial publication". The other was=20 > just a tuple, representing the partial publication case. In=20 > the case where just a tuple is published, I think that each=20 > PUBLISH should contain just one tuple. If you want to=20 > publish an entire document (in which case you are saying=20 > "this is the whole presence state for user X"), you can do that too. This issue has basically gone away now that segmentation and collision = detection among the segments has been removed. Cheers, Aki =20 >=20 > -Jonathan R. >=20 >=20 >=20 >=20 > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com >=20 >=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 Sep 2 12:35:45 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 MAA12983 for ; Tue, 2 Sep 2003 12:35:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uE7k-0006a1-DU for simple-archive@odin.ietf.org; Tue, 02 Sep 2003 12:35:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h82GZKBA025293 for simple-archive@odin.ietf.org; Tue, 2 Sep 2003 12:35:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uE7j-0006Zs-Ss for simple-web-archive@optimus.ietf.org; Tue, 02 Sep 2003 12:35: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 MAA12938; Tue, 2 Sep 2003 12:35:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uE7h-0007EC-00; Tue, 02 Sep 2003 12:35:17 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19uE7h-0007E9-00; Tue, 02 Sep 2003 12: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 19uE7S-0006Yy-6v; Tue, 02 Sep 2003 12:35:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uE6X-0006YE-Da for simple@optimus.ietf.org; Tue, 02 Sep 2003 12:34:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12893 for ; Tue, 2 Sep 2003 12:33:58 -0400 (EDT) From: aki.niemi@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uE6V-0007D3-00 for simple@ietf.org; Tue, 02 Sep 2003 12:34:03 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19uE6T-0007Cp-00 for simple@ietf.org; Tue, 02 Sep 2003 12:34:02 -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 h82GXa412101 for ; Tue, 2 Sep 2003 19:33:45 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 2 Sep 2003 19:33:36 +0300 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 2 Sep 2003 19:33:36 +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] Comments on draft-ietf-simple-publish Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD90194535D@esebe013.ntc.nokia.com> Thread-Topic: [Simple] Comments on draft-ietf-simple-publish Thread-Index: AcNxbHs+romuMX79Rsqe0OEi1xbhLgAAEIhg To: Cc: , X-OriginalArrivalTime: 02 Sep 2003 16:33:36.0651 (UTC) FILETIME=[F54145B0:01C3716F] 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, 2 Sep 2003 19:33:36 +0300 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Jonathan, Seems like I never responded to this email, so here goes - inline. Jonathan Rosenberg wrote: > Some comments: >=20 > * Section 4 sounds like it is trying to impose guidelines=20 > for some kind of registration procedure that event packages=20 > need to follow. But, it doesn't explicitly state that. If=20 > the intent is to do that (and I think it is), you should=20 > follow the basic structure of rfc3265 in terms of how its done. It certainly tries to do just that. The next version will try to be more = closely aligned with the way RFC 3265 puts it. =20 > * Section 4 introduces requirements that an event package=20 > has to satisfy in order to make use of publish. In some=20 > places, it does that by referencing the publish requirements=20 > doc. That doc is informational, but you effectively=20 > promoting those requirements to normative in your usage.=20 > That will be a problem. I recommend that you instead include=20 > the specific requirements from the publish requirements doc=20 > into publish that define things an event package has to declare. Good point. The normative nature of the requirements doc is removed. >=20 > * section 5 - subscribing to the AOR will not likely give=20 > you the same information that was published. Will add a note to that effect. The problem is that this is as close we = can get with the current PUBLISH to fulfilling requirement 14 of the = publish requirements. Of course, adding such a mechanism should be = possible later on if needed. >=20 > * section 5 says: >=20 > > Expires: PUBLISH requests SHOULD contain a single Expires header > > field. This value indicates the lifetime of the event=20 > state being > > published by this request. A special value of "0"=20 > indicates the > > removal of any prior soft state established by a prior PUBLISH > > request from this EPA. >=20 > I don't think its "any prior soft state" - its the specific=20 > soft-state identified by an etag, no? True, fixed that. =20 > Section 5.5 doesnt say anything about this either. For=20 > deletion, when there is not body (and thus no tuple id),=20 > there needs to be a way to identify the tuple being deleted. All of chapters 5.3, 5.4 and 5.5 will have some text to clarify the = etags usage in the next rev. =20 > * The numbered steps in section 6 repeat the UA processing=20 > in rfc3261. They shouldn't be there. You should just=20 > reference rfc3261, and augment the steps there with=20 > publish-specific operations. Fixed in the next rev. =20 > * Bullet 9 of section 6: >=20 > >the source of the publication (From > > URI), and the version of the publication. >=20 > why is the From needed? Not needed, so removed. > * also in step 9: >=20 >=20 > >For new publications, i.e., publications without a version > > precondition, the ESC MUST generate a locally unique > > entity-tag, and store it, replacing any existing=20 > entity-tags > > stored for that particular event state. The new=20 > entity-tag >=20 >=20 > I don't like this usage of "new". To me, new means that=20 > there is no published data for this tuple. But, you are=20 > using new to mean that the publication doesnt' have a=20 > precondition. That doesnt seem to fit the meaning of "new". This will also be reworded. > * Table 3 - need to indiate its applicability to other methods. Will add that.=20 =20 > * security considerations section: you should discuss=20 > specific threats that PUBLISH introduces, and then from=20 > these make recommendations (such as SHOULD authenticate).=20 > YOu probably want to talk about sensitivity of published=20 > data, and say something about sips. I will try to add text to this effect, but this section may need to be = revisited by someone more security-savvy later on. >=20 > On this open issue: >=20 > >o Atomicity of publication. Should the segments of event state > > (presence tuples) be sent in separate PUBLISH=20 > requests or is it > > enough to treat these as implicitly separate=20 > publication requests? >=20 >=20 > I vaguely recall at the interim meeting that the idea was=20 > floated that for presence, there were two separate things=20 > one could publish. One was a full presence document, in=20 > which case there is no "partial publication". The other was=20 > just a tuple, representing the partial publication case. In=20 > the case where just a tuple is published, I think that each=20 > PUBLISH should contain just one tuple. If you want to=20 > publish an entire document (in which case you are saying=20 > "this is the whole presence state for user X"), you can do that too. This issue has basically gone away now that segmentation and collision = detection among the segments has been removed. Cheers, Aki =20 >=20 > -Jonathan R. >=20 >=20 >=20 >=20 > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com >=20 >=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 Sep 2 13:23: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 NAA17984; Tue, 2 Sep 2003 13:23: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 19uErt-0003Y8-17; Tue, 02 Sep 2003 13: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 19uEqx-0003WO-K7 for simple@optimus.ietf.org; Tue, 02 Sep 2003 13:22: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 NAA17783 for ; Tue, 2 Sep 2003 13:21:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uEqv-0000tm-00 for simple@ietf.org; Tue, 02 Sep 2003 13:22:01 -0400 Received: from web41510.mail.yahoo.com ([66.218.93.93]) by ietf-mx with smtp (Exim 4.12) id 19uEqu-0000sr-00 for simple@ietf.org; Tue, 02 Sep 2003 13:22:00 -0400 Message-ID: <20030902172128.6706.qmail@web41510.mail.yahoo.com> Received: from [131.107.3.83] by web41510.mail.yahoo.com via HTTP; Tue, 02 Sep 2003 10:21:28 PDT From: Sean Olson Subject: Re: [Simple] [Fwd: Re: NETCONF WG meeting minutes for IETF #57] To: Jonathan Rosenberg , hisham.khartabil@nokia.com Cc: simple@ietf.org, gk@ninebynine.org In-Reply-To: <3F542CB5.7040006@dynamicsoft.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: Tue, 2 Sep 2003 10:21:28 -0700 (PDT) If you are saying that a piece of software can't figure out how to parse the presence doc to find geolocation info (regardless of whether an XPath expression is used or not), then I think there is something seriously wrong with the PIDF doc format. This is one area where a standardized mechanism should be chosen over flexibility. --- Jonathan Rosenberg wrote: > It ties back into our ongoing debate about "what is > a tuple". Its not > that the PIDF XML has no semantics, its that the > underlying "presence" > of a user can map into a variety of different XML > documents, depending > on the underlying policy of the PA and presentity. > Thus, if the desire > is to have a filter that restricts geolocation > inforamtion, the > appropriate XPath expressions depend a lot on how > the PA chooses to > place the presence information into the presence > document. As an > example, the PA may use it to compute the > "placetype" RPID attribute. > Or, it may appear in some tuples, but not others. It > may appear as a > textual piece of a note, i.e., "at work". Xpath > cannot be used to tell > a PA "don't put geoloc data anywhere in the > document". > > More abstractly, and in the context of Graham's > note, I believe there > is an underling data model which has "raw" presence > data, and then > this data gets encoded into presence documents using > PIDF. I believe > filters are ultimately useful only in their > application to this raw > data. Since there is a gap between the raw data and > its encoding into > a PIDF document, the usage of Xpath expressions on > the PIDF document > doesnt seem right to me. > > Thanks, > Jonathan R. > > hisham.khartabil@nokia.com wrote: > > > I don't buy it. Why would you define an XML schema > who's syntax > > does not match the semantics? > > > > I earlier bought the argument that XPath is too > complicated to > > implement for a simple use case of just wanting to > identify an > > element in an XML document, and thereafter agreed > to provide some > > text in the I-D pointing to this issue and > explaining the limited > > use of XPath in filtering. > > > > /Hisham > > > > > >> -----Original Message----- From: ext Jonathan > Rosenberg > >> [mailto:jdrosen@dynamicsoft.com] Sent: Friday, > August 29, 2003 > >> 5:36 PM To: Simple WG; gk@ninebynine.org Subject: > [Simple] [Fwd: > >> Re: NETCONF WG meeting minutes for IETF #57] > >> > >> > >> Graham Klyne posted this note on netconf that has > some insights > >> which I think can benefit us. Pay attention to > this statement: > >> > >> Graham writes: > >> > >>> I would be very wary about using XPath as the > basis for > >>> selective access to XMLConf data. XPath, by > design, provides > >>> selection on the syntactic structure of XML: it > has been > >>> suggested elsewhere (e.g. in the netconf > protocol document, > >>> IIRC) that the data model is separate from the > protocol > >>> framework (which I think is a good approach). > But the > >>> query/selection syntax should be related to the > data model, not > >>> to the carrier syntax. I have seen difficulties > arise with > >>> different XML-based applications where people > tried to use > >>> XPath selection for an XML format used to carry > a data model > >>> that was somewhat different from the XML carrier > syntax. If > >>> the data model does not map directly onto the > XML syntax, then > >>> XPath selection may well prove inadequate to > make appropriate > >>> selection in the configuration data. > >> > >> I think this summarizes nicely the concerns I > have had about > >> using xpath for filtering. I am also going to be > removing it from > >> element identification in the next xcap-auth rev. > >> > >> -Jonathan R. > >> > >> -- Jonathan D. Rosenberg, Ph.D. > 600 Lanidex Plaza > >> Chief Technology Officer > Parsippany, NJ > >> 07054-2711 dynamicsoft jdrosen@dynamicsoft.com > >> FAX: (973) 952-5050 http://www.jdrosen.net > >> PHONE: (973) 952-5000 http://www.dynamicsoft.com > >> > > > > > > -- > Jonathan D. Rosenberg, Ph.D. 600 > Lanidex Plaza > Chief Technology Officer > Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: > (973) 952-5050 > http://www.jdrosen.net PHONE: > (973) 952-5000 > http://www.dynamicsoft.com > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Sep 2 13:24:09 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18120 for ; Tue, 2 Sep 2003 13:24:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uEsW-0003bq-9n for simple-archive@odin.ietf.org; Tue, 02 Sep 2003 13:23:43 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h82HNedW013868 for simple-archive@odin.ietf.org; Tue, 2 Sep 2003 13:23:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uEsW-0003bb-67 for simple-web-archive@optimus.ietf.org; Tue, 02 Sep 2003 13:23:40 -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 NAA17984; Tue, 2 Sep 2003 13:23: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 19uErt-0003Y8-17; Tue, 02 Sep 2003 13: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 19uEqx-0003WO-K7 for simple@optimus.ietf.org; Tue, 02 Sep 2003 13:22: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 NAA17783 for ; Tue, 2 Sep 2003 13:21:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uEqv-0000tm-00 for simple@ietf.org; Tue, 02 Sep 2003 13:22:01 -0400 Received: from web41510.mail.yahoo.com ([66.218.93.93]) by ietf-mx with smtp (Exim 4.12) id 19uEqu-0000sr-00 for simple@ietf.org; Tue, 02 Sep 2003 13:22:00 -0400 Message-ID: <20030902172128.6706.qmail@web41510.mail.yahoo.com> Received: from [131.107.3.83] by web41510.mail.yahoo.com via HTTP; Tue, 02 Sep 2003 10:21:28 PDT From: Sean Olson Subject: Re: [Simple] [Fwd: Re: NETCONF WG meeting minutes for IETF #57] To: Jonathan Rosenberg , hisham.khartabil@nokia.com Cc: simple@ietf.org, gk@ninebynine.org In-Reply-To: <3F542CB5.7040006@dynamicsoft.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: Tue, 2 Sep 2003 10:21:28 -0700 (PDT) If you are saying that a piece of software can't figure out how to parse the presence doc to find geolocation info (regardless of whether an XPath expression is used or not), then I think there is something seriously wrong with the PIDF doc format. This is one area where a standardized mechanism should be chosen over flexibility. --- Jonathan Rosenberg wrote: > It ties back into our ongoing debate about "what is > a tuple". Its not > that the PIDF XML has no semantics, its that the > underlying "presence" > of a user can map into a variety of different XML > documents, depending > on the underlying policy of the PA and presentity. > Thus, if the desire > is to have a filter that restricts geolocation > inforamtion, the > appropriate XPath expressions depend a lot on how > the PA chooses to > place the presence information into the presence > document. As an > example, the PA may use it to compute the > "placetype" RPID attribute. > Or, it may appear in some tuples, but not others. It > may appear as a > textual piece of a note, i.e., "at work". Xpath > cannot be used to tell > a PA "don't put geoloc data anywhere in the > document". > > More abstractly, and in the context of Graham's > note, I believe there > is an underling data model which has "raw" presence > data, and then > this data gets encoded into presence documents using > PIDF. I believe > filters are ultimately useful only in their > application to this raw > data. Since there is a gap between the raw data and > its encoding into > a PIDF document, the usage of Xpath expressions on > the PIDF document > doesnt seem right to me. > > Thanks, > Jonathan R. > > hisham.khartabil@nokia.com wrote: > > > I don't buy it. Why would you define an XML schema > who's syntax > > does not match the semantics? > > > > I earlier bought the argument that XPath is too > complicated to > > implement for a simple use case of just wanting to > identify an > > element in an XML document, and thereafter agreed > to provide some > > text in the I-D pointing to this issue and > explaining the limited > > use of XPath in filtering. > > > > /Hisham > > > > > >> -----Original Message----- From: ext Jonathan > Rosenberg > >> [mailto:jdrosen@dynamicsoft.com] Sent: Friday, > August 29, 2003 > >> 5:36 PM To: Simple WG; gk@ninebynine.org Subject: > [Simple] [Fwd: > >> Re: NETCONF WG meeting minutes for IETF #57] > >> > >> > >> Graham Klyne posted this note on netconf that has > some insights > >> which I think can benefit us. Pay attention to > this statement: > >> > >> Graham writes: > >> > >>> I would be very wary about using XPath as the > basis for > >>> selective access to XMLConf data. XPath, by > design, provides > >>> selection on the syntactic structure of XML: it > has been > >>> suggested elsewhere (e.g. in the netconf > protocol document, > >>> IIRC) that the data model is separate from the > protocol > >>> framework (which I think is a good approach). > But the > >>> query/selection syntax should be related to the > data model, not > >>> to the carrier syntax. I have seen difficulties > arise with > >>> different XML-based applications where people > tried to use > >>> XPath selection for an XML format used to carry > a data model > >>> that was somewhat different from the XML carrier > syntax. If > >>> the data model does not map directly onto the > XML syntax, then > >>> XPath selection may well prove inadequate to > make appropriate > >>> selection in the configuration data. > >> > >> I think this summarizes nicely the concerns I > have had about > >> using xpath for filtering. I am also going to be > removing it from > >> element identification in the next xcap-auth rev. > >> > >> -Jonathan R. > >> > >> -- Jonathan D. Rosenberg, Ph.D. > 600 Lanidex Plaza > >> Chief Technology Officer > Parsippany, NJ > >> 07054-2711 dynamicsoft jdrosen@dynamicsoft.com > >> FAX: (973) 952-5050 http://www.jdrosen.net > >> PHONE: (973) 952-5000 http://www.dynamicsoft.com > >> > > > > > > -- > Jonathan D. Rosenberg, Ph.D. 600 > Lanidex Plaza > Chief Technology Officer > Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: > (973) 952-5050 > http://www.jdrosen.net PHONE: > (973) 952-5000 > http://www.dynamicsoft.com > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Sep 3 09:34:25 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 JAA03158; Wed, 3 Sep 2003 09:34:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uXlp-0000RX-4G; Wed, 03 Sep 2003 09: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 19uXlA-0000QY-JW for simple@optimus.ietf.org; Wed, 03 Sep 2003 09:33: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 JAA03085 for ; Wed, 3 Sep 2003 09:33:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uXl8-0005Bl-00 for simple@ietf.org; Wed, 03 Sep 2003 09:33:18 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19uXl8-0005Aq-00 for simple@ietf.org; Wed, 03 Sep 2003 09:33:18 -0400 Received: from dynamicsoft.com ([63.113.46.14]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h83DWmUg008729; Wed, 3 Sep 2003 09:32:49 -0400 (EDT) Message-ID: <3F55ED7D.4030004@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: aki.niemi@nokia.com CC: simple@ietf.org Subject: Re: [Simple] Comments on draft-ietf-simple-publish References: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD90194535D@esebe013.ntc.nokia.com> In-Reply-To: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD90194535D@esebe013.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: Wed, 03 Sep 2003 09:32:45 -0400 Content-Transfer-Encoding: 7bit Aki, Thanks for your resposne. Everything looks good. I am looking forward to seeing a rev of this doc. Hopefully we have finally settled on the mechanism here! Thanks, Jonathan R. aki.niemi@nokia.com wrote: > Jonathan Rosenberg wrote: >> Some comments: >> >> * Section 4 sounds like it is trying to impose guidelines for >> some kind of registration procedure that event packages need to >> follow. But, it doesn't explicitly state that. If the intent is >> to do that (and I think it is), you should follow the basic >> structure of rfc3265 in terms of how its done. > > It certainly tries to do just that. The next version will try to be > more closely aligned with the way RFC 3265 puts it. > >> * Section 4 introduces requirements that an event package has to >> satisfy in order to make use of publish. In some places, it does >> that by referencing the publish requirements doc. That doc is >> informational, but you effectively promoting those requirements >> to normative in your usage. That will be a problem. I recommend >> that you instead include the specific requirements from the >> publish requirements doc into publish that define things an event >> package has to declare. > > Good point. The normative nature of the requirements doc is > removed. > >> >> * section 5 - subscribing to the AOR will not likely give you the >> same information that was published. > > Will add a note to that effect. The problem is that this is as > close we can get with the current PUBLISH to fulfilling requirement > 14 of the publish requirements. Of course, adding such a mechanism > should be possible later on if needed. > >> >> * section 5 says: >> >>> Expires: PUBLISH requests SHOULD contain a single Expires >>> header field. This value indicates the lifetime of the event >> state being >>> published by this request. A special value of "0" >> indicates the >>> removal of any prior soft state established by a prior PUBLISH >>> request from this EPA. >> >> I don't think its "any prior soft state" - its the specific >> soft-state identified by an etag, no? > > True, fixed that. > >> Section 5.5 doesnt say anything about this either. For deletion, >> when there is not body (and thus no tuple id), there needs to be >> a way to identify the tuple being deleted. > > All of chapters 5.3, 5.4 and 5.5 will have some text to clarify the > etags usage in the next rev. > >> * The numbered steps in section 6 repeat the UA processing in >> rfc3261. They shouldn't be there. You should just reference >> rfc3261, and augment the steps there with publish-specific >> operations. > > Fixed in the next rev. > >> * Bullet 9 of section 6: >> >>> the source of the publication (From URI), and the version of >>> the publication. >> >> why is the From needed? > > Not needed, so removed. > >> * also in step 9: >> >> >>> For new publications, i.e., publications without a version >>> precondition, the ESC MUST generate a locally unique >>> entity-tag, and store it, replacing any existing >> entity-tags >>> stored for that particular event state. The new >> entity-tag >> >> >> I don't like this usage of "new". To me, new means that there is >> no published data for this tuple. But, you are using new to mean >> that the publication doesnt' have a precondition. That doesnt >> seem to fit the meaning of "new". > > This will also be reworded. > >> * Table 3 - need to indiate its applicability to other methods. > > Will add that. > >> * security considerations section: you should discuss specific >> threats that PUBLISH introduces, and then from these make >> recommendations (such as SHOULD authenticate). YOu probably want >> to talk about sensitivity of published data, and say something >> about sips. > > I will try to add text to this effect, but this section may need to > be revisited by someone more security-savvy later on. > >> >> On this open issue: >> >>> o Atomicity of publication. Should the segments of event state >>> (presence tuples) be sent in separate PUBLISH >> requests or is it >>> enough to treat these as implicitly separate >> publication requests? >> >> >> I vaguely recall at the interim meeting that the idea was floated >> that for presence, there were two separate things one could >> publish. One was a full presence document, in which case there is >> no "partial publication". The other was just a tuple, >> representing the partial publication case. In the case where just >> a tuple is published, I think that each PUBLISH should contain >> just one tuple. If you want to publish an entire document (in >> which case you are saying "this is the whole presence state for >> user X"), you can do that too. > > This issue has basically gone away now that segmentation and > collision detection among the segments has been removed. > > Cheers, Aki > >> >> -Jonathan R. >> >> >> >> >> -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief >> Technology Officer Parsippany, NJ 07054-2711 dynamicsoft >> jdrosen@dynamicsoft.com FAX: (973) 952-5050 >> http://www.jdrosen.net PHONE: (973) 952-5000 >> http://www.dynamicsoft.com >> >> >> >> >> _______________________________________________ Simple mailing >> list Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple >> > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Sep 3 09:34:58 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 JAA03227 for ; Wed, 3 Sep 2003 09:34:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uXmL-0000W9-FL for simple-archive@odin.ietf.org; Wed, 03 Sep 2003 09:34:33 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h83DYX0K001988 for simple-archive@odin.ietf.org; Wed, 3 Sep 2003 09:34:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uXmL-0000Vz-BZ for simple-web-archive@optimus.ietf.org; Wed, 03 Sep 2003 09:34:33 -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 JAA03158; Wed, 3 Sep 2003 09:34:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uXlp-0000RX-4G; Wed, 03 Sep 2003 09: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 19uXlA-0000QY-JW for simple@optimus.ietf.org; Wed, 03 Sep 2003 09:33: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 JAA03085 for ; Wed, 3 Sep 2003 09:33:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uXl8-0005Bl-00 for simple@ietf.org; Wed, 03 Sep 2003 09:33:18 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19uXl8-0005Aq-00 for simple@ietf.org; Wed, 03 Sep 2003 09:33:18 -0400 Received: from dynamicsoft.com ([63.113.46.14]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h83DWmUg008729; Wed, 3 Sep 2003 09:32:49 -0400 (EDT) Message-ID: <3F55ED7D.4030004@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: aki.niemi@nokia.com CC: simple@ietf.org Subject: Re: [Simple] Comments on draft-ietf-simple-publish References: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD90194535D@esebe013.ntc.nokia.com> In-Reply-To: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD90194535D@esebe013.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: Wed, 03 Sep 2003 09:32:45 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Aki, Thanks for your resposne. Everything looks good. I am looking forward to seeing a rev of this doc. Hopefully we have finally settled on the mechanism here! Thanks, Jonathan R. aki.niemi@nokia.com wrote: > Jonathan Rosenberg wrote: >> Some comments: >> >> * Section 4 sounds like it is trying to impose guidelines for >> some kind of registration procedure that event packages need to >> follow. But, it doesn't explicitly state that. If the intent is >> to do that (and I think it is), you should follow the basic >> structure of rfc3265 in terms of how its done. > > It certainly tries to do just that. The next version will try to be > more closely aligned with the way RFC 3265 puts it. > >> * Section 4 introduces requirements that an event package has to >> satisfy in order to make use of publish. In some places, it does >> that by referencing the publish requirements doc. That doc is >> informational, but you effectively promoting those requirements >> to normative in your usage. That will be a problem. I recommend >> that you instead include the specific requirements from the >> publish requirements doc into publish that define things an event >> package has to declare. > > Good point. The normative nature of the requirements doc is > removed. > >> >> * section 5 - subscribing to the AOR will not likely give you the >> same information that was published. > > Will add a note to that effect. The problem is that this is as > close we can get with the current PUBLISH to fulfilling requirement > 14 of the publish requirements. Of course, adding such a mechanism > should be possible later on if needed. > >> >> * section 5 says: >> >>> Expires: PUBLISH requests SHOULD contain a single Expires >>> header field. This value indicates the lifetime of the event >> state being >>> published by this request. A special value of "0" >> indicates the >>> removal of any prior soft state established by a prior PUBLISH >>> request from this EPA. >> >> I don't think its "any prior soft state" - its the specific >> soft-state identified by an etag, no? > > True, fixed that. > >> Section 5.5 doesnt say anything about this either. For deletion, >> when there is not body (and thus no tuple id), there needs to be >> a way to identify the tuple being deleted. > > All of chapters 5.3, 5.4 and 5.5 will have some text to clarify the > etags usage in the next rev. > >> * The numbered steps in section 6 repeat the UA processing in >> rfc3261. They shouldn't be there. You should just reference >> rfc3261, and augment the steps there with publish-specific >> operations. > > Fixed in the next rev. > >> * Bullet 9 of section 6: >> >>> the source of the publication (From URI), and the version of >>> the publication. >> >> why is the From needed? > > Not needed, so removed. > >> * also in step 9: >> >> >>> For new publications, i.e., publications without a version >>> precondition, the ESC MUST generate a locally unique >>> entity-tag, and store it, replacing any existing >> entity-tags >>> stored for that particular event state. The new >> entity-tag >> >> >> I don't like this usage of "new". To me, new means that there is >> no published data for this tuple. But, you are using new to mean >> that the publication doesnt' have a precondition. That doesnt >> seem to fit the meaning of "new". > > This will also be reworded. > >> * Table 3 - need to indiate its applicability to other methods. > > Will add that. > >> * security considerations section: you should discuss specific >> threats that PUBLISH introduces, and then from these make >> recommendations (such as SHOULD authenticate). YOu probably want >> to talk about sensitivity of published data, and say something >> about sips. > > I will try to add text to this effect, but this section may need to > be revisited by someone more security-savvy later on. > >> >> On this open issue: >> >>> o Atomicity of publication. Should the segments of event state >>> (presence tuples) be sent in separate PUBLISH >> requests or is it >>> enough to treat these as implicitly separate >> publication requests? >> >> >> I vaguely recall at the interim meeting that the idea was floated >> that for presence, there were two separate things one could >> publish. One was a full presence document, in which case there is >> no "partial publication". The other was just a tuple, >> representing the partial publication case. In the case where just >> a tuple is published, I think that each PUBLISH should contain >> just one tuple. If you want to publish an entire document (in >> which case you are saying "this is the whole presence state for >> user X"), you can do that too. > > This issue has basically gone away now that segmentation and > collision detection among the segments has been removed. > > Cheers, Aki > >> >> -Jonathan R. >> >> >> >> >> -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief >> Technology Officer Parsippany, NJ 07054-2711 dynamicsoft >> jdrosen@dynamicsoft.com FAX: (973) 952-5050 >> http://www.jdrosen.net PHONE: (973) 952-5000 >> http://www.dynamicsoft.com >> >> >> >> >> _______________________________________________ Simple mailing >> list Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple >> > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Sep 3 10:23: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 KAA08315; Wed, 3 Sep 2003 10:23:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uYYE-0006uj-00; Wed, 03 Sep 2003 10:24:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19uYYD-0006ue-00; Wed, 03 Sep 2003 10:24:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uYYD-000336-LS; Wed, 03 Sep 2003 10:24:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uYXc-00032F-6m for simple@optimus.ietf.org; Wed, 03 Sep 2003 10:23: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 KAA08252 for ; Wed, 3 Sep 2003 10:23:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uYXZ-0006t9-00 for simple@ietf.org; Wed, 03 Sep 2003 10:23:22 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19uYXZ-0006sS-00 for simple@ietf.org; Wed, 03 Sep 2003 10:23:21 -0400 Received: from dynamicsoft.com ([63.113.46.14]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h83EMmUg008772; Wed, 3 Sep 2003 10:22:48 -0400 (EDT) Message-ID: <3F55F933.2080308@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne CC: hisham.khartabil@nokia.com, simple@ietf.org, gk@ninebynine.org Subject: Re: [Simple] [Fwd: Re: NETCONF WG meeting minutes for IETF #57] References: <2038BCC78B1AD641891A0D1AE133DBB70179703A@esebe019.ntc.nokia.com> <3F542CB5.7040006@dynamicsoft.com> <3F54A341.2080004@cs.columbia.edu> In-Reply-To: <3F54A341.2080004@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 03 Sep 2003 10:22:43 -0400 Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: >> It ties back into our ongoing debate about "what is a tuple". Its not >> that the PIDF XML has no semantics, its that the underlying "presence" >> of a user can map into a variety of different XML documents, depending >> on the underlying policy of the PA and presentity. Thus, if the desire >> is to have a filter that restricts geolocation inforamtion, the >> appropriate XPath expressions depend a lot on how the PA chooses to >> place the presence information into the presence document. As an >> example, the PA may use it to compute the "placetype" RPID attribute. >> Or, it may appear in some tuples, but not others. It may appear as a >> textual piece of a note, i.e., "at work". Xpath cannot be used to tell >> a PA "don't put geoloc data anywhere in the document". > > > I'm not convinced by this example. > > Realistically, how would you propose to address this issue? I don't > think we can build filters that just say "if there's location > information somewhere, filter it" unless we want to have a natural > language processor in the loop that tries to guess that "123 Main > Street" in the note is location information. I agree you can't solve this when the user puts information into the note manually. What I am worried about are PA which receive location information, and in order to "maximize compatibility" with the broadest set of watchers possible, automatically places such information into the note in some way. Preventing that is easily solvable - you would simply need to standardize a filter/auth policy that is associated with a token, say "no-geoloc", and this would instruct the PA not to place geolocation information anywhere in the message, whether its the note, separate geoloc objects, or the placetype attribute. Another issue I have is that an xpath expression would only allow you to block information from appearing in places where you are aware it can be placed. Let me give a concrete example. A user, Joe, doesn't want the PA to reveal to anyone his placetype information. Assuming an xpath based mechanism in xcap, he would tell the server to block out information that matched the expression "presence/tuple/status/placetype", which will stop all placetype elements from being sent in any tuple. Now, the next week, the PA is upgraded to support a new "future-status" capability, which conveys information on where the presentity will be in the future. This future-status appears as a peer element to status, and can contain anything status can. The PA, now upgraded, extracts information from the user's calendar and now places the placetype attribute there. This information is NOT blocked by the previous expression. The user's client would need to know that it has to add another xpath expression, "presence/tuple/future-status/placetype", to block this information. But, the client hasn't been upgraded, so it never knows. So, I am not saying that PIDF is the wrong way to represent presence; I am merely saying that the atomic pieces of information that users will wish to filter or block can appear in sufficiently different places (all with well defined semantics), to make xpath based filtering potentially problematic. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Sep 3 10:24:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08356 for ; Wed, 3 Sep 2003 10:24:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uYYI-00034e-Dw for simple-archive@odin.ietf.org; Wed, 03 Sep 2003 10:24:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h83EO6ju011764 for simple-archive@odin.ietf.org; Wed, 3 Sep 2003 10:24:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uYYH-00033f-QD for simple-web-archive@optimus.ietf.org; Wed, 03 Sep 2003 10:24: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 KAA08315; Wed, 3 Sep 2003 10:23:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uYYE-0006uj-00; Wed, 03 Sep 2003 10:24:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19uYYD-0006ue-00; Wed, 03 Sep 2003 10:24:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uYYD-000336-LS; Wed, 03 Sep 2003 10:24:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uYXc-00032F-6m for simple@optimus.ietf.org; Wed, 03 Sep 2003 10:23: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 KAA08252 for ; Wed, 3 Sep 2003 10:23:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uYXZ-0006t9-00 for simple@ietf.org; Wed, 03 Sep 2003 10:23:22 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19uYXZ-0006sS-00 for simple@ietf.org; Wed, 03 Sep 2003 10:23:21 -0400 Received: from dynamicsoft.com ([63.113.46.14]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h83EMmUg008772; Wed, 3 Sep 2003 10:22:48 -0400 (EDT) Message-ID: <3F55F933.2080308@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne CC: hisham.khartabil@nokia.com, simple@ietf.org, gk@ninebynine.org Subject: Re: [Simple] [Fwd: Re: NETCONF WG meeting minutes for IETF #57] References: <2038BCC78B1AD641891A0D1AE133DBB70179703A@esebe019.ntc.nokia.com> <3F542CB5.7040006@dynamicsoft.com> <3F54A341.2080004@cs.columbia.edu> In-Reply-To: <3F54A341.2080004@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 03 Sep 2003 10:22:43 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: >> It ties back into our ongoing debate about "what is a tuple". Its not >> that the PIDF XML has no semantics, its that the underlying "presence" >> of a user can map into a variety of different XML documents, depending >> on the underlying policy of the PA and presentity. Thus, if the desire >> is to have a filter that restricts geolocation inforamtion, the >> appropriate XPath expressions depend a lot on how the PA chooses to >> place the presence information into the presence document. As an >> example, the PA may use it to compute the "placetype" RPID attribute. >> Or, it may appear in some tuples, but not others. It may appear as a >> textual piece of a note, i.e., "at work". Xpath cannot be used to tell >> a PA "don't put geoloc data anywhere in the document". > > > I'm not convinced by this example. > > Realistically, how would you propose to address this issue? I don't > think we can build filters that just say "if there's location > information somewhere, filter it" unless we want to have a natural > language processor in the loop that tries to guess that "123 Main > Street" in the note is location information. I agree you can't solve this when the user puts information into the note manually. What I am worried about are PA which receive location information, and in order to "maximize compatibility" with the broadest set of watchers possible, automatically places such information into the note in some way. Preventing that is easily solvable - you would simply need to standardize a filter/auth policy that is associated with a token, say "no-geoloc", and this would instruct the PA not to place geolocation information anywhere in the message, whether its the note, separate geoloc objects, or the placetype attribute. Another issue I have is that an xpath expression would only allow you to block information from appearing in places where you are aware it can be placed. Let me give a concrete example. A user, Joe, doesn't want the PA to reveal to anyone his placetype information. Assuming an xpath based mechanism in xcap, he would tell the server to block out information that matched the expression "presence/tuple/status/placetype", which will stop all placetype elements from being sent in any tuple. Now, the next week, the PA is upgraded to support a new "future-status" capability, which conveys information on where the presentity will be in the future. This future-status appears as a peer element to status, and can contain anything status can. The PA, now upgraded, extracts information from the user's calendar and now places the placetype attribute there. This information is NOT blocked by the previous expression. The user's client would need to know that it has to add another xpath expression, "presence/tuple/future-status/placetype", to block this information. But, the client hasn't been upgraded, so it never knows. So, I am not saying that PIDF is the wrong way to represent presence; I am merely saying that the atomic pieces of information that users will wish to filter or block can appear in sufficiently different places (all with well defined semantics), to make xpath based filtering potentially problematic. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Sep 3 14:21:58 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27334; Wed, 3 Sep 2003 14:21:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ucGY-0006gj-00; Wed, 03 Sep 2003 14:22:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ucGX-0006gf-00; Wed, 03 Sep 2003 14:22:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ucGY-0006mi-1Y; Wed, 03 Sep 2003 14:22:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ucFw-0006hS-Tu for simple@optimus.ietf.org; Wed, 03 Sep 2003 14:21: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 OAA27277 for ; Wed, 3 Sep 2003 14:21:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ucFu-0006fp-00 for simple@ietf.org; Wed, 03 Sep 2003 14:21:22 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 19ucFs-0006fl-00 for simple@ietf.org; Wed, 03 Sep 2003 14:21:21 -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 h83IJuMK006518; Wed, 3 Sep 2003 14:19:57 -0400 (EDT) Received: from cs.columbia.edu (path.cs.columbia.edu [128.59.19.143]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h83IJtG01806; Wed, 3 Sep 2003 14:19:56 -0400 Message-ID: <3F5630CB.5060400@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: hisham.khartabil@nokia.com, simple@ietf.org, gk@ninebynine.org Subject: Re: [Simple] [Fwd: Re: NETCONF WG meeting minutes for IETF #57] References: <2038BCC78B1AD641891A0D1AE133DBB70179703A@esebe019.ntc.nokia.com> <3F542CB5.7040006@dynamicsoft.com> <3F54A341.2080004@cs.columbia.edu> <3F55F933.2080308@dynamicsoft.com> In-Reply-To: <3F55F933.2080308@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: Wed, 03 Sep 2003 14:19:55 -0400 Content-Transfer-Encoding: 7bit I agree that we seem to need to ways of identifying information: (1) syntactically, for fine-grained control; after all, someone may well be prepared to reveal the type of place they are in, but not the actual location. (2) semantically, where we label each piece of information as being part of one or more broader classes, such as "where am I" and "what am I doing" or "what device capabilities do I have" or, as another axis, "present" and "future". Beyond the obvious location identification, it might be useful to go through the set of PIDF and RPID (and related document) items to see if they are amenable to such a grouping. If each group has one element, this approach isn't too helpful. Another approach (3) is to have a scale of privacy concern or 'presence resolution', i.e., establish some default ordering, from "OPEN/CLOSED" at the low end to "every new item that I publish" at the high end, with no more than half a dozen levels. Each new element would then be labeled as falling into one of these groupings. I think both (2) and (3) have the distinct advantage that they are far easier to explain to users than dozens of checkboxes for each RPID/geoloc/PIDF element. (3) is roughly similar to the privacy slider in the Internet Options menu for IE, for example. There is no requirement that everybody agrees with an ordering, just that it is plausible for the majority of use cases. Advanced users can click through to the per-element include/exclude list. > I agree you can't solve this when the user puts information into the > note manually. > > What I am worried about are PA which receive location information, and > in order to "maximize compatibility" with the broadest set of watchers > possible, automatically places such information into the note in some way. > > Preventing that is easily solvable - you would simply need to > standardize a filter/auth policy that is associated with a token, say > "no-geoloc", and this would instruct the PA not to place geolocation > information anywhere in the message, whether its the note, separate > geoloc objects, or the placetype attribute. > > Another issue I have is that an xpath expression would only allow you to > block information from appearing in places where you are aware it can be > placed. Let me give a concrete example. A user, Joe, doesn't want the PA > to reveal to anyone his placetype information. Assuming an xpath based > mechanism in xcap, he would tell the server to block out information > that matched the expression "presence/tuple/status/placetype", which > will stop all placetype elements from being sent in any tuple. Now, the > next week, the PA is upgraded to support a new "future-status" > capability, which conveys information on where the presentity will be in > the future. This future-status appears as a peer element to status, and > can contain anything status can. The PA, now upgraded, extracts > information from the user's calendar and now places the placetype > attribute there. This information is NOT blocked by the previous > expression. The user's client would need to know that it has to add > another xpath expression, "presence/tuple/future-status/placetype", to > block this information. But, the client hasn't been upgraded, so it > never knows. > > So, I am not saying that PIDF is the wrong way to represent presence; I > am merely saying that the atomic pieces of information that users will > wish to filter or block can appear in sufficiently different places (all > with well defined semantics), to make xpath based filtering potentially > problematic. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Sep 3 14:22: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 OAA27407 for ; Wed, 3 Sep 2003 14:22: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 19ucGb-0006ob-Pr for simple-archive@odin.ietf.org; Wed, 03 Sep 2003 14:22:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h83IM5hN026193 for simple-archive@odin.ietf.org; Wed, 3 Sep 2003 14:22:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ucGb-0006oO-LW for simple-web-archive@optimus.ietf.org; Wed, 03 Sep 2003 14:22: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 OAA27334; Wed, 3 Sep 2003 14:21:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ucGY-0006gj-00; Wed, 03 Sep 2003 14:22:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ucGX-0006gf-00; Wed, 03 Sep 2003 14:22:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ucGY-0006mi-1Y; Wed, 03 Sep 2003 14:22:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ucFw-0006hS-Tu for simple@optimus.ietf.org; Wed, 03 Sep 2003 14:21: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 OAA27277 for ; Wed, 3 Sep 2003 14:21:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ucFu-0006fp-00 for simple@ietf.org; Wed, 03 Sep 2003 14:21:22 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 19ucFs-0006fl-00 for simple@ietf.org; Wed, 03 Sep 2003 14:21:21 -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 h83IJuMK006518; Wed, 3 Sep 2003 14:19:57 -0400 (EDT) Received: from cs.columbia.edu (path.cs.columbia.edu [128.59.19.143]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h83IJtG01806; Wed, 3 Sep 2003 14:19:56 -0400 Message-ID: <3F5630CB.5060400@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: hisham.khartabil@nokia.com, simple@ietf.org, gk@ninebynine.org Subject: Re: [Simple] [Fwd: Re: NETCONF WG meeting minutes for IETF #57] References: <2038BCC78B1AD641891A0D1AE133DBB70179703A@esebe019.ntc.nokia.com> <3F542CB5.7040006@dynamicsoft.com> <3F54A341.2080004@cs.columbia.edu> <3F55F933.2080308@dynamicsoft.com> In-Reply-To: <3F55F933.2080308@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: Wed, 03 Sep 2003 14:19:55 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I agree that we seem to need to ways of identifying information: (1) syntactically, for fine-grained control; after all, someone may well be prepared to reveal the type of place they are in, but not the actual location. (2) semantically, where we label each piece of information as being part of one or more broader classes, such as "where am I" and "what am I doing" or "what device capabilities do I have" or, as another axis, "present" and "future". Beyond the obvious location identification, it might be useful to go through the set of PIDF and RPID (and related document) items to see if they are amenable to such a grouping. If each group has one element, this approach isn't too helpful. Another approach (3) is to have a scale of privacy concern or 'presence resolution', i.e., establish some default ordering, from "OPEN/CLOSED" at the low end to "every new item that I publish" at the high end, with no more than half a dozen levels. Each new element would then be labeled as falling into one of these groupings. I think both (2) and (3) have the distinct advantage that they are far easier to explain to users than dozens of checkboxes for each RPID/geoloc/PIDF element. (3) is roughly similar to the privacy slider in the Internet Options menu for IE, for example. There is no requirement that everybody agrees with an ordering, just that it is plausible for the majority of use cases. Advanced users can click through to the per-element include/exclude list. > I agree you can't solve this when the user puts information into the > note manually. > > What I am worried about are PA which receive location information, and > in order to "maximize compatibility" with the broadest set of watchers > possible, automatically places such information into the note in some way. > > Preventing that is easily solvable - you would simply need to > standardize a filter/auth policy that is associated with a token, say > "no-geoloc", and this would instruct the PA not to place geolocation > information anywhere in the message, whether its the note, separate > geoloc objects, or the placetype attribute. > > Another issue I have is that an xpath expression would only allow you to > block information from appearing in places where you are aware it can be > placed. Let me give a concrete example. A user, Joe, doesn't want the PA > to reveal to anyone his placetype information. Assuming an xpath based > mechanism in xcap, he would tell the server to block out information > that matched the expression "presence/tuple/status/placetype", which > will stop all placetype elements from being sent in any tuple. Now, the > next week, the PA is upgraded to support a new "future-status" > capability, which conveys information on where the presentity will be in > the future. This future-status appears as a peer element to status, and > can contain anything status can. The PA, now upgraded, extracts > information from the user's calendar and now places the placetype > attribute there. This information is NOT blocked by the previous > expression. The user's client would need to know that it has to add > another xpath expression, "presence/tuple/future-status/placetype", to > block this information. But, the client hasn't been upgraded, so it > never knows. > > So, I am not saying that PIDF is the wrong way to represent presence; I > am merely saying that the atomic pieces of information that users will > wish to filter or block can appear in sufficiently different places (all > with well defined semantics), to make xpath based filtering potentially > problematic. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Sep 4 08:18:59 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16141; Thu, 4 Sep 2003 08:18:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ut4p-0005yD-00; Thu, 04 Sep 2003 08:19:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ut4p-0005yA-00; Thu, 04 Sep 2003 08:19:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ut4o-0005VZ-CA; Thu, 04 Sep 2003 08:19:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ut3w-0005H3-FW for simple@optimus.ietf.org; Thu, 04 Sep 2003 08:18: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 IAA16057 for ; Thu, 4 Sep 2003 08:18:01 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ut3u-0005mN-00 for simple@ietf.org; Thu, 04 Sep 2003 08:18:06 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19ut3s-0005ks-00 for simple@ietf.org; Thu, 04 Sep 2003 08:18:05 -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 h84CHk428975 for ; Thu, 4 Sep 2003 15:17:58 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 4 Sep 2003 15:17:46 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 4 Sep 2003 15:17:46 +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] [Fwd: Re: NETCONF WG meeting minutes for IETF #57] Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797080@esebe019.ntc.nokia.com> Thread-Topic: [Simple] [Fwd: Re: NETCONF WG meeting minutes for IETF #57] Thread-Index: AcNyJvgF69FAP2CiRUaFIYTExx2vSQAtgATg To: , Cc: , X-OriginalArrivalTime: 04 Sep 2003 12:17:46.0246 (UTC) FILETIME=[8C86DA60:01C372DE] 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, 4 Sep 2003 15:17:45 +0300 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Wednesday, September 03, 2003 5:23 PM > To: Henning Schulzrinne > Cc: Khartabil Hisham (NMP/Helsinki); simple@ietf.org;=20 > gk@ninebynine.org > Subject: Re: [Simple] [Fwd: Re: NETCONF WG meeting minutes=20 > for IETF #57] >=20 >=20 >=20 >=20 > Henning Schulzrinne wrote: >=20 > >> It ties back into our ongoing debate about "what is a=20 > tuple". Its not=20 > >> that the PIDF XML has no semantics, its that the=20 > underlying "presence"=20 > >> of a user can map into a variety of different XML=20 > documents, depending=20 > >> on the underlying policy of the PA and presentity. Thus,=20 > if the desire=20 > >> is to have a filter that restricts geolocation inforamtion, the=20 > >> appropriate XPath expressions depend a lot on how the PA=20 > chooses to=20 > >> place the presence information into the presence document. As an=20 > >> example, the PA may use it to compute the "placetype" RPID=20 > attribute.=20 > >> Or, it may appear in some tuples, but not others. It may=20 > appear as a=20 > >> textual piece of a note, i.e., "at work". Xpath cannot be=20 > used to tell=20 > >> a PA "don't put geoloc data anywhere in the document". > >=20 > >=20 > > I'm not convinced by this example. > >=20 > > Realistically, how would you propose to address this issue? I don't=20 > > think we can build filters that just say "if there's location=20 > > information somewhere, filter it" unless we want to have a natural=20 > > language processor in the loop that tries to guess that "123 Main=20 > > Street" in the note is location information. >=20 > I agree you can't solve this when the user puts information into the=20 > note manually. >=20 > What I am worried about are PA which receive location=20 > information, and=20 > in order to "maximize compatibility" with the broadest set of=20 > watchers=20 > possible, automatically places such information into the note in some=20 > way. >=20 > Preventing that is easily solvable - you would simply need to=20 > standardize a filter/auth policy that is associated with a token, say=20 > "no-geoloc", and this would instruct the PA not to place geolocation=20 > information anywhere in the message, whether its the note, separate=20 > geoloc objects, or the placetype attribute. >=20 > Another issue I have is that an xpath expression would only allow you=20 > to block information from appearing in places where you are aware it=20 > can be placed. Let me give a concrete example. A user, Joe, doesn't=20 > want the PA to reveal to anyone his placetype information.=20 > Assuming an=20 > xpath based mechanism in xcap, he would tell the server to block out=20 > information that matched the expression=20 > "presence/tuple/status/placetype", which will stop all placetype=20 > elements from being sent in any tuple. Now, the next week, the PA is=20 > upgraded to support a new "future-status" capability, which conveys=20 > information on where the presentity will be in the future. This=20 > future-status appears as a peer element to status, and can contain=20 > anything status can. The PA, now upgraded, extracts information from=20 > the user's calendar and now places the placetype attribute=20 > there. This=20 > information is NOT blocked by the previous expression. The user's=20 > client would need to know that it has to add another xpath=20 > expression,=20 > "presence/tuple/future-status/placetype", to block this information.=20 > But, the client hasn't been upgraded, so it never knows. This might be true to authorisation where the presentity wants to block = certain information from being unwillingly delivered to watchers = (keeping requirements issues aside for now). But with filtering, the = watcher selects information it wants to see, not block. In this case, = the implementation at the watcher side better know how to render this = presence information, delivered by the PA, to the watcher (end user). = Therefore it can only ask for presence info in an xml document it = understands.=20 I would say it is expected from the PA to place presence info in a = format that the watcher requested (taking a hint from the filter). I = quote you saying: > What I am worried about are PA which receive location=20 > information, and=20 > in order to "maximize compatibility" with the broadest set of=20 > watchers=20 > possible ... /Hisham >=20 > So, I am not saying that PIDF is the wrong way to represent presence;=20 > I am merely saying that the atomic pieces of information that users=20 > will wish to filter or block can appear in sufficiently different=20 > places (all with well defined semantics), to make xpath based=20 > filtering potentially problematic. >=20 > -Jonathan R. >=20 >=20 >=20 > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Sep 4 08:19:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16197 for ; Thu, 4 Sep 2003 08:19:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ut4r-0005XE-TD for simple-archive@odin.ietf.org; Thu, 04 Sep 2003 08:19:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h84CJ5sY021275 for simple-archive@odin.ietf.org; Thu, 4 Sep 2003 08:19:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ut4r-0005X4-N4 for simple-web-archive@optimus.ietf.org; Thu, 04 Sep 2003 08:19: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 IAA16141; Thu, 4 Sep 2003 08:18:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ut4p-0005yD-00; Thu, 04 Sep 2003 08:19:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ut4p-0005yA-00; Thu, 04 Sep 2003 08:19:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ut4o-0005VZ-CA; Thu, 04 Sep 2003 08:19:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ut3w-0005H3-FW for simple@optimus.ietf.org; Thu, 04 Sep 2003 08:18: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 IAA16057 for ; Thu, 4 Sep 2003 08:18:01 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ut3u-0005mN-00 for simple@ietf.org; Thu, 04 Sep 2003 08:18:06 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19ut3s-0005ks-00 for simple@ietf.org; Thu, 04 Sep 2003 08:18:05 -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 h84CHk428975 for ; Thu, 4 Sep 2003 15:17:58 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 4 Sep 2003 15:17:46 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 4 Sep 2003 15:17:46 +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] [Fwd: Re: NETCONF WG meeting minutes for IETF #57] Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797080@esebe019.ntc.nokia.com> Thread-Topic: [Simple] [Fwd: Re: NETCONF WG meeting minutes for IETF #57] Thread-Index: AcNyJvgF69FAP2CiRUaFIYTExx2vSQAtgATg To: , Cc: , X-OriginalArrivalTime: 04 Sep 2003 12:17:46.0246 (UTC) FILETIME=[8C86DA60:01C372DE] 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, 4 Sep 2003 15:17:45 +0300 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Wednesday, September 03, 2003 5:23 PM > To: Henning Schulzrinne > Cc: Khartabil Hisham (NMP/Helsinki); simple@ietf.org;=20 > gk@ninebynine.org > Subject: Re: [Simple] [Fwd: Re: NETCONF WG meeting minutes=20 > for IETF #57] >=20 >=20 >=20 >=20 > Henning Schulzrinne wrote: >=20 > >> It ties back into our ongoing debate about "what is a=20 > tuple". Its not=20 > >> that the PIDF XML has no semantics, its that the=20 > underlying "presence"=20 > >> of a user can map into a variety of different XML=20 > documents, depending=20 > >> on the underlying policy of the PA and presentity. Thus,=20 > if the desire=20 > >> is to have a filter that restricts geolocation inforamtion, the=20 > >> appropriate XPath expressions depend a lot on how the PA=20 > chooses to=20 > >> place the presence information into the presence document. As an=20 > >> example, the PA may use it to compute the "placetype" RPID=20 > attribute.=20 > >> Or, it may appear in some tuples, but not others. It may=20 > appear as a=20 > >> textual piece of a note, i.e., "at work". Xpath cannot be=20 > used to tell=20 > >> a PA "don't put geoloc data anywhere in the document". > >=20 > >=20 > > I'm not convinced by this example. > >=20 > > Realistically, how would you propose to address this issue? I don't=20 > > think we can build filters that just say "if there's location=20 > > information somewhere, filter it" unless we want to have a natural=20 > > language processor in the loop that tries to guess that "123 Main=20 > > Street" in the note is location information. >=20 > I agree you can't solve this when the user puts information into the=20 > note manually. >=20 > What I am worried about are PA which receive location=20 > information, and=20 > in order to "maximize compatibility" with the broadest set of=20 > watchers=20 > possible, automatically places such information into the note in some=20 > way. >=20 > Preventing that is easily solvable - you would simply need to=20 > standardize a filter/auth policy that is associated with a token, say=20 > "no-geoloc", and this would instruct the PA not to place geolocation=20 > information anywhere in the message, whether its the note, separate=20 > geoloc objects, or the placetype attribute. >=20 > Another issue I have is that an xpath expression would only allow you=20 > to block information from appearing in places where you are aware it=20 > can be placed. Let me give a concrete example. A user, Joe, doesn't=20 > want the PA to reveal to anyone his placetype information.=20 > Assuming an=20 > xpath based mechanism in xcap, he would tell the server to block out=20 > information that matched the expression=20 > "presence/tuple/status/placetype", which will stop all placetype=20 > elements from being sent in any tuple. Now, the next week, the PA is=20 > upgraded to support a new "future-status" capability, which conveys=20 > information on where the presentity will be in the future. This=20 > future-status appears as a peer element to status, and can contain=20 > anything status can. The PA, now upgraded, extracts information from=20 > the user's calendar and now places the placetype attribute=20 > there. This=20 > information is NOT blocked by the previous expression. The user's=20 > client would need to know that it has to add another xpath=20 > expression,=20 > "presence/tuple/future-status/placetype", to block this information.=20 > But, the client hasn't been upgraded, so it never knows. This might be true to authorisation where the presentity wants to block = certain information from being unwillingly delivered to watchers = (keeping requirements issues aside for now). But with filtering, the = watcher selects information it wants to see, not block. In this case, = the implementation at the watcher side better know how to render this = presence information, delivered by the PA, to the watcher (end user). = Therefore it can only ask for presence info in an xml document it = understands.=20 I would say it is expected from the PA to place presence info in a = format that the watcher requested (taking a hint from the filter). I = quote you saying: > What I am worried about are PA which receive location=20 > information, and=20 > in order to "maximize compatibility" with the broadest set of=20 > watchers=20 > possible ... /Hisham >=20 > So, I am not saying that PIDF is the wrong way to represent presence;=20 > I am merely saying that the atomic pieces of information that users=20 > will wish to filter or block can appear in sufficiently different=20 > places (all with well defined semantics), to make xpath based=20 > filtering potentially problematic. >=20 > -Jonathan R. >=20 >=20 >=20 > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Sep 5 04:13:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08980; Fri, 5 Sep 2003 04:13:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19vBiH-0001cW-NT; Fri, 05 Sep 2003 04:13:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19vBhI-0001b4-Nh for simple@optimus.ietf.org; Fri, 05 Sep 2003 04:12: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 EAA08939 for ; Fri, 5 Sep 2003 04:11:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19vBh5-00060p-00 for simple@ietf.org; Fri, 05 Sep 2003 04:11:47 -0400 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 19vBgf-0005zd-00 for simple@ietf.org; Fri, 05 Sep 2003 04:11:22 -0400 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by albatross-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.7) with ESMTP id h8584wDN029919 for ; Fri, 5 Sep 2003 10:09:10 +0200 (MEST) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id SJV4QADQ; Fri, 5 Sep 2003 09:41:36 +0200 Received: from ericsson.com (EFQ240013L1IJOG.lmf.ericsson.se [131.160.31.13]) by hendrix.lmf.ericsson.se (8.12.8/8.12.8/lmf-2.1-jcs) with ESMTP id h857brSZ024270 for ; Fri, 5 Sep 2003 10:37:53 +0300 (EET DST) Message-ID: <3F583D50.6070100@ericsson.com> From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en, es 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] Default 1 minute inactivity timer in MSRP Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.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, 05 Sep 2003 10:37:52 +0300 Content-Transfer-Encoding: 7bit Hi: Just by reading the message session draft, I have found the description of a 1 minute session inactivity timer (see section 7.4.5) I am a bit shocked with this requirement. So does it mean that if I establish an MSRP session to a chat room that is in dormant state, I will have to send empty SEND primitives every minute just to refresh the state??? Sounds weird... Specially if I am paying for the bytes that I send and if I have to seize resources for sending this timer... it sounds completely unefficient. If I understand correctly (correct me if I am wrong), MSRP provides two timers: the session timer negotiated in the Exp header and the inactivity timer harcoded to 1 minute. The question is do we really need both timers??? Why isn't the session timer enough for the purpose of supervising the session??? /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 514 0002 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Sep 5 04:14:05 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 EAA09013 for ; Fri, 5 Sep 2003 04:14:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19vBiu-0001hm-2q for simple-archive@odin.ietf.org; Fri, 05 Sep 2003 04:13:40 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h858Dedi006553 for simple-archive@odin.ietf.org; Fri, 5 Sep 2003 04:13:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19vBit-0001hc-8s for simple-web-archive@optimus.ietf.org; Fri, 05 Sep 2003 04:13: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 EAA08980; Fri, 5 Sep 2003 04:13:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19vBiH-0001cW-NT; Fri, 05 Sep 2003 04:13:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19vBhI-0001b4-Nh for simple@optimus.ietf.org; Fri, 05 Sep 2003 04:12: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 EAA08939 for ; Fri, 5 Sep 2003 04:11:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19vBh5-00060p-00 for simple@ietf.org; Fri, 05 Sep 2003 04:11:47 -0400 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 19vBgf-0005zd-00 for simple@ietf.org; Fri, 05 Sep 2003 04:11:22 -0400 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by albatross-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.7) with ESMTP id h8584wDN029919 for ; Fri, 5 Sep 2003 10:09:10 +0200 (MEST) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id SJV4QADQ; Fri, 5 Sep 2003 09:41:36 +0200 Received: from ericsson.com (EFQ240013L1IJOG.lmf.ericsson.se [131.160.31.13]) by hendrix.lmf.ericsson.se (8.12.8/8.12.8/lmf-2.1-jcs) with ESMTP id h857brSZ024270 for ; Fri, 5 Sep 2003 10:37:53 +0300 (EET DST) Message-ID: <3F583D50.6070100@ericsson.com> From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en, es 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] Default 1 minute inactivity timer in MSRP Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.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, 05 Sep 2003 10:37:52 +0300 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi: Just by reading the message session draft, I have found the description of a 1 minute session inactivity timer (see section 7.4.5) I am a bit shocked with this requirement. So does it mean that if I establish an MSRP session to a chat room that is in dormant state, I will have to send empty SEND primitives every minute just to refresh the state??? Sounds weird... Specially if I am paying for the bytes that I send and if I have to seize resources for sending this timer... it sounds completely unefficient. If I understand correctly (correct me if I am wrong), MSRP provides two timers: the session timer negotiated in the Exp header and the inactivity timer harcoded to 1 minute. The question is do we really need both timers??? Why isn't the session timer enough for the purpose of supervising the session??? /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 514 0002 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Sun Sep 7 00:55: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 AAA06819; Sun, 7 Sep 2003 00:55:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19vrZu-00039t-00; Sun, 07 Sep 2003 00:55:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19vrZt-00039l-00; Sun, 07 Sep 2003 00:55:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19vrZn-0003mC-DX; Sun, 07 Sep 2003 00:55:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19vrZV-0003jw-NC for simple@optimus.ietf.org; Sun, 07 Sep 2003 00:54: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 AAA06782 for ; Sun, 7 Sep 2003 00:54:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19vrZS-00036i-00 for simple@ietf.org; Sun, 07 Sep 2003 00:54:42 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19vrZR-00032y-00 for simple@ietf.org; Sun, 07 Sep 2003 00:54:41 -0400 Received: from dynamicsoft.com (dyn-tx-app-004.dfw.dynamicsoft.com [63.110.3.2]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h874rHUg010901; Sun, 7 Sep 2003 00:53:18 -0400 (EDT) Message-ID: <3F5AB9B7.4050300@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne CC: hisham.khartabil@nokia.com, simple@ietf.org, gk@ninebynine.org Subject: Re: [Simple] [Fwd: Re: NETCONF WG meeting minutes for IETF #57] References: <2038BCC78B1AD641891A0D1AE133DBB70179703A@esebe019.ntc.nokia.com> <3F542CB5.7040006@dynamicsoft.com> <3F54A341.2080004@cs.columbia.edu> <3F55F933.2080308@dynamicsoft.com> <3F5630CB.5060400@cs.columbia.edu> In-Reply-To: <3F5630CB.5060400@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: Sun, 07 Sep 2003 00:53:11 -0400 Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > I agree that we seem to need to ways of identifying information: > > (1) syntactically, for fine-grained control; after all, someone may well > be prepared to reveal the type of place they are in, but not the actual > location. Fair enough, thought I don't think I would call this "syntactic". > > (2) semantically, where we label each piece of information as being part > of one or more broader classes, such as "where am I" and "what am I > doing" or "what device capabilities do I have" or, as another axis, > "present" and "future". > > Beyond the obvious location identification, it might be useful to go > through the set of PIDF and RPID (and related document) items to see if > they are amenable to such a grouping. If each group has one element, > this approach isn't too helpful. I thought about this a bunch. The conclusion I came to is that, in many cases, the types of authorization policies that users will want are those which block the ability of a watcher to deduce a specific fact. For example, if I take a day off, and don't want my boss or colleauges to know it, I will want my presence to be structured so that no one can figure out that I am not working. This would mean, for example, that if I am sleeping, this activity value should not be shown to watchers. My geolocation concerns were similar. I think what users may want is the ability to say "I don't want people to know where I am". Many possible presence elements can reveal this - including ones like activity and privacy, which reveal indirect clues about location. Unfortunately, I don't think its practical to have authorization mechanisms which require the server to figure out what rpid elements are needed to deduce a specific fact. As such, the best we can do is avoid dependencies on encoding details (such as whether placetype is put in a status or future-status element). I would suggest that the best way to do this is to allow filters and authorization policies to point at rpids and pidf elements by element name, no matter where that element appears in an XML document. So, if I don't want people to know my geoloc, I would specify an auth policy that blocks "placetype". > > Another approach (3) is to have a scale of privacy concern or 'presence > resolution', i.e., establish some default ordering, from "OPEN/CLOSED" > at the low end to "every new item that I publish" at the high end, with > no more than half a dozen levels. Each new element would then be labeled > as falling into one of these groupings. I agree this is a great idea. In fact, I had exactly this kind of thing in mind for the compound permissions. > > I think both (2) and (3) have the distinct advantage that they are far > easier to explain to users than dozens of checkboxes for each > RPID/geoloc/PIDF element. (3) is roughly similar to the privacy slider > in the Internet Options menu for IE, for example. There is no > requirement that everybody agrees with an ordering, just that it is > plausible for the majority of use cases. Advanced users can click > through to the per-element include/exclude list. I agree that we don't want users to click on checkboxes for each rpid type. I think you might have a checkbox for "don't reveal my location", and when its selected, the client generates an xcap-auth document which blocks a whole bunch of elements, each listed by name. This may require us to produce a use case document that helps folks figure out what types of facts users might want to control, and what elements are involved in computing such facts. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Sun Sep 7 00:55:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06869 for ; Sun, 7 Sep 2003 00:55:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19vrZy-0003oI-PO for simple-archive@odin.ietf.org; Sun, 07 Sep 2003 00:55:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h874tEY7014643 for simple-archive@odin.ietf.org; Sun, 7 Sep 2003 00:55:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19vrZy-0003o6-Jk for simple-web-archive@optimus.ietf.org; Sun, 07 Sep 2003 00: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 AAA06819; Sun, 7 Sep 2003 00:55:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19vrZu-00039t-00; Sun, 07 Sep 2003 00:55:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19vrZt-00039l-00; Sun, 07 Sep 2003 00:55:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19vrZn-0003mC-DX; Sun, 07 Sep 2003 00:55:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19vrZV-0003jw-NC for simple@optimus.ietf.org; Sun, 07 Sep 2003 00:54: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 AAA06782 for ; Sun, 7 Sep 2003 00:54:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19vrZS-00036i-00 for simple@ietf.org; Sun, 07 Sep 2003 00:54:42 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19vrZR-00032y-00 for simple@ietf.org; Sun, 07 Sep 2003 00:54:41 -0400 Received: from dynamicsoft.com (dyn-tx-app-004.dfw.dynamicsoft.com [63.110.3.2]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h874rHUg010901; Sun, 7 Sep 2003 00:53:18 -0400 (EDT) Message-ID: <3F5AB9B7.4050300@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne CC: hisham.khartabil@nokia.com, simple@ietf.org, gk@ninebynine.org Subject: Re: [Simple] [Fwd: Re: NETCONF WG meeting minutes for IETF #57] References: <2038BCC78B1AD641891A0D1AE133DBB70179703A@esebe019.ntc.nokia.com> <3F542CB5.7040006@dynamicsoft.com> <3F54A341.2080004@cs.columbia.edu> <3F55F933.2080308@dynamicsoft.com> <3F5630CB.5060400@cs.columbia.edu> In-Reply-To: <3F5630CB.5060400@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: Sun, 07 Sep 2003 00:53:11 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > I agree that we seem to need to ways of identifying information: > > (1) syntactically, for fine-grained control; after all, someone may well > be prepared to reveal the type of place they are in, but not the actual > location. Fair enough, thought I don't think I would call this "syntactic". > > (2) semantically, where we label each piece of information as being part > of one or more broader classes, such as "where am I" and "what am I > doing" or "what device capabilities do I have" or, as another axis, > "present" and "future". > > Beyond the obvious location identification, it might be useful to go > through the set of PIDF and RPID (and related document) items to see if > they are amenable to such a grouping. If each group has one element, > this approach isn't too helpful. I thought about this a bunch. The conclusion I came to is that, in many cases, the types of authorization policies that users will want are those which block the ability of a watcher to deduce a specific fact. For example, if I take a day off, and don't want my boss or colleauges to know it, I will want my presence to be structured so that no one can figure out that I am not working. This would mean, for example, that if I am sleeping, this activity value should not be shown to watchers. My geolocation concerns were similar. I think what users may want is the ability to say "I don't want people to know where I am". Many possible presence elements can reveal this - including ones like activity and privacy, which reveal indirect clues about location. Unfortunately, I don't think its practical to have authorization mechanisms which require the server to figure out what rpid elements are needed to deduce a specific fact. As such, the best we can do is avoid dependencies on encoding details (such as whether placetype is put in a status or future-status element). I would suggest that the best way to do this is to allow filters and authorization policies to point at rpids and pidf elements by element name, no matter where that element appears in an XML document. So, if I don't want people to know my geoloc, I would specify an auth policy that blocks "placetype". > > Another approach (3) is to have a scale of privacy concern or 'presence > resolution', i.e., establish some default ordering, from "OPEN/CLOSED" > at the low end to "every new item that I publish" at the high end, with > no more than half a dozen levels. Each new element would then be labeled > as falling into one of these groupings. I agree this is a great idea. In fact, I had exactly this kind of thing in mind for the compound permissions. > > I think both (2) and (3) have the distinct advantage that they are far > easier to explain to users than dozens of checkboxes for each > RPID/geoloc/PIDF element. (3) is roughly similar to the privacy slider > in the Internet Options menu for IE, for example. There is no > requirement that everybody agrees with an ordering, just that it is > plausible for the majority of use cases. Advanced users can click > through to the per-element include/exclude list. I agree that we don't want users to click on checkboxes for each rpid type. I think you might have a checkbox for "don't reveal my location", and when its selected, the client generates an xcap-auth document which blocks a whole bunch of elements, each listed by name. This may require us to produce a use case document that helps folks figure out what types of facts users might want to control, and what elements are involved in computing such facts. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Sun Sep 7 13:32: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 NAA20624; Sun, 7 Sep 2003 13:32:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19w3OR-0007MA-00; Sun, 07 Sep 2003 13:32:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19w3OQ-0007M1-00; Sun, 07 Sep 2003 13:32:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19w3OL-0003LQ-K4; Sun, 07 Sep 2003 13:32:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19w3NX-0003AO-9t for simple@optimus.ietf.org; Sun, 07 Sep 2003 13:31: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 NAA20341 for ; Sun, 7 Sep 2003 13:31:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19w08M-0003Lc-00 for simple@ietf.org; Sun, 07 Sep 2003 10:03:18 -0400 Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx with esmtp (Exim 4.12) id 19w08L-0003LU-00 for simple@ietf.org; Sun, 07 Sep 2003 10:03:17 -0400 Received: from bart.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 h87E35rq024345 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Sun, 7 Sep 2003 10:03:16 -0400 (EDT) Received: from cs.columbia.edu (localhost [127.0.0.1]) by bart.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h87E2w9s025127; Sun, 7 Sep 2003 10:02:59 -0400 (EDT) Message-ID: <3F5B3A92.2070908@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: simple@ietf.org, gk@ninebynine.org Subject: Re: [Simple] [Fwd: Re: NETCONF WG meeting minutes for IETF #57] References: <2038BCC78B1AD641891A0D1AE133DBB70179703A@esebe019.ntc.nokia.com> <3F542CB5.7040006@dynamicsoft.com> <3F54A341.2080004@cs.columbia.edu> <3F55F933.2080308@dynamicsoft.com> <3F5630CB.5060400@cs.columbia.edu> <3F5AB9B7.4050300@dynamicsoft.com> In-Reply-To: <3F5AB9B7.4050300@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: Sun, 07 Sep 2003 10:02:58 -0400 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > Fair enough, thought I don't think I would call this "syntactic". Document-oriented? Presumably it would use > My geolocation concerns were similar. I think what users may want is the > ability to say "I don't want people to know where I am". Many possible > presence elements can reveal this - including ones like activity and > privacy, which reveal indirect clues about location. I don't think this is necessarily binary. For example, I might be ok with letting others know what timezone I'm in, although this may hint that I'm traveling or on vacation. > > Unfortunately, I don't think its practical to have authorization > mechanisms which require the server to figure out what rpid elements are > needed to deduce a specific fact. Particularly if this is meant to be more than a binary yes/no decision. Different elements reveal different amounts of information depending on context, depending on what the watcher knows about me, etc. (For example, if the watcher knows that my employer has a branch office in Tokyo, even something as vague as timezone=Japan will provide a good hint as to what I'm doing right now.) > > As such, the best we can do is avoid dependencies on encoding details > (such as whether placetype is put in a status or future-status element). > I would suggest that the best way to do this is to allow filters and > authorization policies to point at rpids and pidf elements by element > name, no matter where that element appears in an XML document. So, if I > don't want people to know my geoloc, I would specify an auth policy that > blocks "placetype". Agreed. As a side-effect, this essentially makes the namespace flat, i.e., we can't have two PIDF-and-related namespaces use the same term for something different. I don't think this is a significant restriction in practice. One possibility to formalize this is to indeed have a single IANA registry for presence attributes. Each entry would point to one or more namespace/element-name combinations. > I agree this is a great idea. In fact, I had exactly this kind of thing > in mind for the compound permissions. The proof of feasibility will be whether we can arrive at such a list, across PIDF, RPID + related, and the emerging GEOPRIV items. I would suggest that these levels should be motivated by the likely use and audience. For example, for two mid-levels: (1) "Can I visit this person": this would be useful for intra-company coordination Would need information about my campus-level whereabouts. (2) "Is this person amenable to business (or private) communication?" This would include timezone, possibly country and open/closed. Possibly a 'private/business' coarse-grain activity (rather than a placetype). Are there others? > I agree that we don't want users to click on checkboxes for each rpid > type. I think you might have a checkbox for "don't reveal my location", > and when its selected, the client generates an xcap-auth document which > blocks a whole bunch of elements, each listed by name. This may require > us to produce a use case document that helps folks figure out what types > of facts users might want to control, and what elements are involved in > computing such facts. There was a long discussion on this topic at the GEOPRIV interim meeting that took place Friday and Saturday. Two approaches were identified: (1) a tool presents a high-level interface to the user, but the on-the-wire ruleset (XCAP-AUTH, etc.) identifies lower-level elements (either at the document-oriented level or, probably better, by content type). (2) the authorization policy itself contains a high-level description that then is translated by the policy enforcement entity into filtering actions. (2) has fewer things to test and thus may reach interoperability sooner, but requires that the policy enforcement point be upgraded each time a new element is added. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Sun Sep 7 14:12: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 OAA25321; Sun, 7 Sep 2003 14:12:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19w415-0003wJ-00; Sun, 07 Sep 2003 14:12:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19w415-0003w5-00; Sun, 07 Sep 2003 14:12:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19w413-0005X0-Ef; Sun, 07 Sep 2003 14:12:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19w40x-0005W2-5S for simple@optimus.ietf.org; Sun, 07 Sep 2003 14:11: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 OAA25306; Sun, 7 Sep 2003 14:11:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19w40u-0003uI-00; Sun, 07 Sep 2003 14:11:52 -0400 Received: from ober.cs.columbia.edu ([128.59.18.100]) by ietf-mx with esmtp (Exim 4.12) id 19w40u-0003uD-00; Sun, 07 Sep 2003 14:11:52 -0400 Received: from bart.cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by ober.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h87IBpoC000119 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Sun, 7 Sep 2003 14:11:52 -0400 (EDT) Received: from cs.columbia.edu (localhost [127.0.0.1]) by bart.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h87I4f9s025753; Sun, 7 Sep 2003 14:04:41 -0400 (EDT) Message-ID: <3F5B7339.5060207@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: geopriv@ietf.org, simple@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Individuals, hats and spheres Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.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, 07 Sep 2003 14:04:41 -0400 Content-Transfer-Encoding: 7bit For access control to presence and geo data, there seem to be two use cases that almost all discussions circle back to: spheres and individuals. By spheres I mean the various parts that most of us divide our life into, the different 'hats' that we wear, as member of a family, as an employee, as a member of various voluntary organizations ranging from the professional assocations like the IEEE and IETF to religious organizations and social organizations like the Boy Scouts or bowling league. Many of the use cases can be boiled down to "if I'm in one sphere, I don't people in another sphere to see what I'm doing". (Here, I think is what I'm doing is mostly the important aspect if you exclude total strangers that could do me physical harm, where simple knowledge of location matters. For privacy, it is mostly that location is a good indication of activity and interests.) The discussion so far always seems to make the work/home distinction, but before "Bowling Alone", people also had many other spheres in what I gather is commonly called "civil society". If somebody is with the scout group on an outing, the may want the other scout masters to be able to find where they are, but they probably don't want them to track them the rest of the week. The rules discussion in GEOPRIV and, to a lesser extent, in SIMPLE, have tried to approximate these spheres, by location, time or other hints, but for a variety of reasons, this doesn't always work well. (Time-of-day fails when people have schedules more complicated than factory workers; location fails for road warriors and placetype fails for people working at home.) Thus, my proposal: RPID adds a element that has a few standard labels, such as 'home' and 'work', with other labels that can be added. The primary purpose of this information is not so much in the NOTIFY, but in the PUBLISH phase. The idea is that I can publish my 'sphere' and this will automatically switch between different modes of visibility, different sets of rules. In the rule language being discussed in GEOPRIV, this might take the form Person sphere access ------------------------------------------------------- boss@work work location,activity friend home busy/idle spouse home,work location bowling buddy bowling location Note that this is not a group as traditionally understood - the same person may well share multiple spheres with me. Also, unlike groups, the visibility depends on my activity, not just a membership in a list. While the sphere information would often have to be derived manually, it is plausible that external hints can be used. Sometimes location will do, but only in the narrowest sense ("at work site"). Time will only be useful if users are meticulous about keeping calendars and have very regular schedules. Other hints are probably better, such as being logged into a VPN for work, or wearing a work badge. The current RPID and come close, but are not quite the same. I'd appreciate comments. Henning _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Sun Sep 7 14:12:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25426 for ; Sun, 7 Sep 2003 14:12:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19w418-0005Yj-PM for simple-archive@odin.ietf.org; Sun, 07 Sep 2003 14:12:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h87IC6ik021363 for simple-archive@odin.ietf.org; Sun, 7 Sep 2003 14:12:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19w418-0005YU-M7 for simple-web-archive@optimus.ietf.org; Sun, 07 Sep 2003 14:12: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 OAA25321; Sun, 7 Sep 2003 14:12:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19w415-0003wJ-00; Sun, 07 Sep 2003 14:12:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19w415-0003w5-00; Sun, 07 Sep 2003 14:12:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19w413-0005X0-Ef; Sun, 07 Sep 2003 14:12:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19w40x-0005W2-5S for simple@optimus.ietf.org; Sun, 07 Sep 2003 14:11: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 OAA25306; Sun, 7 Sep 2003 14:11:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19w40u-0003uI-00; Sun, 07 Sep 2003 14:11:52 -0400 Received: from ober.cs.columbia.edu ([128.59.18.100]) by ietf-mx with esmtp (Exim 4.12) id 19w40u-0003uD-00; Sun, 07 Sep 2003 14:11:52 -0400 Received: from bart.cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by ober.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h87IBpoC000119 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Sun, 7 Sep 2003 14:11:52 -0400 (EDT) Received: from cs.columbia.edu (localhost [127.0.0.1]) by bart.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h87I4f9s025753; Sun, 7 Sep 2003 14:04:41 -0400 (EDT) Message-ID: <3F5B7339.5060207@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: geopriv@ietf.org, simple@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Individuals, hats and spheres Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.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, 07 Sep 2003 14:04:41 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit For access control to presence and geo data, there seem to be two use cases that almost all discussions circle back to: spheres and individuals. By spheres I mean the various parts that most of us divide our life into, the different 'hats' that we wear, as member of a family, as an employee, as a member of various voluntary organizations ranging from the professional assocations like the IEEE and IETF to religious organizations and social organizations like the Boy Scouts or bowling league. Many of the use cases can be boiled down to "if I'm in one sphere, I don't people in another sphere to see what I'm doing". (Here, I think is what I'm doing is mostly the important aspect if you exclude total strangers that could do me physical harm, where simple knowledge of location matters. For privacy, it is mostly that location is a good indication of activity and interests.) The discussion so far always seems to make the work/home distinction, but before "Bowling Alone", people also had many other spheres in what I gather is commonly called "civil society". If somebody is with the scout group on an outing, the may want the other scout masters to be able to find where they are, but they probably don't want them to track them the rest of the week. The rules discussion in GEOPRIV and, to a lesser extent, in SIMPLE, have tried to approximate these spheres, by location, time or other hints, but for a variety of reasons, this doesn't always work well. (Time-of-day fails when people have schedules more complicated than factory workers; location fails for road warriors and placetype fails for people working at home.) Thus, my proposal: RPID adds a element that has a few standard labels, such as 'home' and 'work', with other labels that can be added. The primary purpose of this information is not so much in the NOTIFY, but in the PUBLISH phase. The idea is that I can publish my 'sphere' and this will automatically switch between different modes of visibility, different sets of rules. In the rule language being discussed in GEOPRIV, this might take the form Person sphere access ------------------------------------------------------- boss@work work location,activity friend home busy/idle spouse home,work location bowling buddy bowling location Note that this is not a group as traditionally understood - the same person may well share multiple spheres with me. Also, unlike groups, the visibility depends on my activity, not just a membership in a list. While the sphere information would often have to be derived manually, it is plausible that external hints can be used. Sometimes location will do, but only in the narrowest sense ("at work site"). Time will only be useful if users are meticulous about keeping calendars and have very regular schedules. Other hints are probably better, such as being logged into a VPN for work, or wearing a work badge. The current RPID and come close, but are not quite the same. I'd appreciate comments. Henning _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Sep 8 13:45:01 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10476; Mon, 8 Sep 2003 13:45:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19wQ4Y-0004KF-00; Mon, 08 Sep 2003 13:45:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19wQ4X-0004KA-00; Mon, 08 Sep 2003 13:45:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wQ4U-0006ZV-In; Mon, 08 Sep 2003 13:45:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wQ3t-0006YM-AJ for simple@optimus.ietf.org; Mon, 08 Sep 2003 13:44: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 NAA10439; Mon, 8 Sep 2003 13:44:17 -0400 (EDT) From: Dirk.Trossen@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19wQ3q-0004JR-00; Mon, 08 Sep 2003 13:44:22 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19wQ3p-0004JN-00; Mon, 08 Sep 2003 13:44: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 h88HiGB23950; Mon, 8 Sep 2003 20:44:19 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 8 Sep 2003 20:44:16 +0300 Received: from daebh001.NOE.Nokia.com ([172.18.242.231]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 8 Sep 2003 20:44:16 +0300 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 8 Sep 2003 10:44:05 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: Thread-Topic: [Geopriv] Individuals, hats and spheres Thread-Index: AcN1a40BQpNCJz/2Rl+6sa2yh+VtNAAxDrmw To: , , X-OriginalArrivalTime: 08 Sep 2003 17:44:05.0495 (UTC) FILETIME=[CC522870:01C37630] Content-Transfer-Encoding: quoted-printable Subject: [Simple] RE: [Geopriv] Individuals, hats and spheres Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.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, 8 Sep 2003 13:44:04 -0400 Content-Transfer-Encoding: quoted-printable >Thus, my proposal: RPID adds a element that has a few=20 >standard=20 >labels, such as 'home' and 'work', with other labels that can=20 >be added.=20 >The primary purpose of this information is not so much in the NOTIFY,=20 >but in the PUBLISH phase. The idea is that I can publish my=20 >'sphere' and=20 >this will automatically switch between different modes of visibility,=20 >different sets of rules. In the rule language being discussed in=20 >GEOPRIV, this might take the form > >Person sphere access >------------------------------------------------------- >boss@work work location,activity >friend home busy/idle >spouse home,work location >bowling buddy bowling location > >Note that this is not a group as traditionally understood - the same=20 >person may well share multiple spheres with me. Also, unlike=20 >groups, the=20 >visibility depends on my activity, not just a membership in a list. > >While the sphere information would often have to be derived=20 >manually, it=20 >is plausible that external hints can be used. Sometimes location will=20 >do, but only in the narrowest sense ("at work site"). Time=20 >will only be=20 >useful if users are meticulous about keeping calendars and have very=20 >regular schedules. Other hints are probably better, such as=20 >being logged=20 >into a VPN for work, or wearing a work badge. > >The current RPID and come close, but are not=20 >quite the same. > I like the idea of enabling a certain set of rules (as opposed to have = conditional single rules, the condition being e.g., the identity of the watcher) based on a = certain condition.=20 However, I was wondering whether this is intended to be bound to the = element?=20 Let me try to describe the underlying, general method that I understood = from your proposal: Allow for enabling a defined set of rules based on a certain = condition, in which the condition would be a certain value/range of an RPID element.=20 Hence, with this understanding of your proposal in mind, would it be = possible/desirable to use other RPID elements? In this, I could define a set of rules that is = enabled when=20 is "work" or is "meeting".=20 Dirk _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Sep 8 13:45:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10526 for ; Mon, 8 Sep 2003 13:45:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wQ4b-0006bM-10 for simple-archive@odin.ietf.org; Mon, 08 Sep 2003 13:45:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h88Hj8le025370 for simple-archive@odin.ietf.org; Mon, 8 Sep 2003 13:45:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wQ4a-0006b7-Sc for simple-web-archive@optimus.ietf.org; Mon, 08 Sep 2003 13:45: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 NAA10476; Mon, 8 Sep 2003 13:45:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19wQ4Y-0004KF-00; Mon, 08 Sep 2003 13:45:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19wQ4X-0004KA-00; Mon, 08 Sep 2003 13:45:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wQ4U-0006ZV-In; Mon, 08 Sep 2003 13:45:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wQ3t-0006YM-AJ for simple@optimus.ietf.org; Mon, 08 Sep 2003 13:44: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 NAA10439; Mon, 8 Sep 2003 13:44:17 -0400 (EDT) From: Dirk.Trossen@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19wQ3q-0004JR-00; Mon, 08 Sep 2003 13:44:22 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19wQ3p-0004JN-00; Mon, 08 Sep 2003 13:44: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 h88HiGB23950; Mon, 8 Sep 2003 20:44:19 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 8 Sep 2003 20:44:16 +0300 Received: from daebh001.NOE.Nokia.com ([172.18.242.231]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 8 Sep 2003 20:44:16 +0300 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 8 Sep 2003 10:44:05 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: Thread-Topic: [Geopriv] Individuals, hats and spheres Thread-Index: AcN1a40BQpNCJz/2Rl+6sa2yh+VtNAAxDrmw To: , , X-OriginalArrivalTime: 08 Sep 2003 17:44:05.0495 (UTC) FILETIME=[CC522870:01C37630] Content-Transfer-Encoding: quoted-printable Subject: [Simple] RE: [Geopriv] Individuals, hats and spheres Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.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, 8 Sep 2003 13:44:04 -0400 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable >Thus, my proposal: RPID adds a element that has a few=20 >standard=20 >labels, such as 'home' and 'work', with other labels that can=20 >be added.=20 >The primary purpose of this information is not so much in the NOTIFY,=20 >but in the PUBLISH phase. The idea is that I can publish my=20 >'sphere' and=20 >this will automatically switch between different modes of visibility,=20 >different sets of rules. In the rule language being discussed in=20 >GEOPRIV, this might take the form > >Person sphere access >------------------------------------------------------- >boss@work work location,activity >friend home busy/idle >spouse home,work location >bowling buddy bowling location > >Note that this is not a group as traditionally understood - the same=20 >person may well share multiple spheres with me. Also, unlike=20 >groups, the=20 >visibility depends on my activity, not just a membership in a list. > >While the sphere information would often have to be derived=20 >manually, it=20 >is plausible that external hints can be used. Sometimes location will=20 >do, but only in the narrowest sense ("at work site"). Time=20 >will only be=20 >useful if users are meticulous about keeping calendars and have very=20 >regular schedules. Other hints are probably better, such as=20 >being logged=20 >into a VPN for work, or wearing a work badge. > >The current RPID and come close, but are not=20 >quite the same. > I like the idea of enabling a certain set of rules (as opposed to have = conditional single rules, the condition being e.g., the identity of the watcher) based on a = certain condition.=20 However, I was wondering whether this is intended to be bound to the = element?=20 Let me try to describe the underlying, general method that I understood = from your proposal: Allow for enabling a defined set of rules based on a certain = condition, in which the condition would be a certain value/range of an RPID element.=20 Hence, with this understanding of your proposal in mind, would it be = possible/desirable to use other RPID elements? In this, I could define a set of rules that is = enabled when=20 is "work" or is "meeting".=20 Dirk _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Sep 8 16:25: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 QAA19105; Mon, 8 Sep 2003 16:25:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19wSZg-0007Kb-00; Mon, 08 Sep 2003 16:25:24 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19wSYp-0007G4-00; Mon, 08 Sep 2003 16:24:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wSYN-0004Hk-Qn; Mon, 08 Sep 2003 16: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 19wRXC-0002im-H1 for simple@optimus.ietf.org; Mon, 08 Sep 2003 15:18: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 PAA16507; Mon, 8 Sep 2003 15:18:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19wRXA-0006Fj-00; Mon, 08 Sep 2003 15:18:44 -0400 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 19wRXA-0006FW-00; Mon, 08 Sep 2003 15:18:44 -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 PAA03685; Mon, 8 Sep 2003 15:18:11 -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 PAA02416; Mon, 8 Sep 2003 15:18:13 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Mon, 8 Sep 2003 15:18:12 -0400 Message-ID: <313680C9A886D511A06000204840E1CF070B5E05@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Henning Schulzrinne'" , geopriv@ietf.org, simple@ietf.org Subject: RE: [Simple] Individuals, hats and spheres 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, 8 Sep 2003 15:18:12 -0400 There are lots of ways to categorize watchers. "Sphere" is one of them. Categorizing the PRESENTITY in a sphere is pretty strange to my way of thinking. If I publish my location, then it's my location, and that is independent of my sphere. I can be at home, and still be working. If I am, I'll probably take calls, and reveal location, to my friends. If I'm working at home, then presumably I'm in the work sphere as you propose it. The only thing the sphere could do on the watcher is to somehow change visibility to, say, office team-mates, when I'm working from home, as opposed to working in my office. While I would agree there is some value in that, it seems pretty small. What I want to do is to have different rules for different categories of watchers. I don't see how this proposal helps me categorize watchers. Brian > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Sunday, September 07, 2003 2:05 PM > To: geopriv@ietf.org; simple@ietf.org > Subject: [Simple] Individuals, hats and spheres > > > For access control to presence and geo data, there seem to be two use > cases that almost all discussions circle back to: spheres and > individuals. > > By spheres I mean the various parts that most of us divide our life > into, the different 'hats' that we wear, as member of a family, as an > employee, as a member of various voluntary organizations ranging from > the professional assocations like the IEEE and IETF to religious > organizations and social organizations like the Boy Scouts or bowling > league. > > Many of the use cases can be boiled down to "if I'm in one sphere, I > don't people in another sphere to see what I'm doing". (Here, > I think is > what I'm doing is mostly the important aspect if you exclude total > strangers that could do me physical harm, where simple knowledge of > location matters. For privacy, it is mostly that location is a good > indication of activity and interests.) > > The discussion so far always seems to make the work/home distinction, > but before "Bowling Alone", people also had many other > spheres in what I > gather is commonly called "civil society". If somebody is > with the scout > group on an outing, the may want the other scout masters to > be able to > find where they are, but they probably don't want them to > track them the > rest of the week. > > The rules discussion in GEOPRIV and, to a lesser extent, in > SIMPLE, have > tried to approximate these spheres, by location, time or other hints, > but for a variety of reasons, this doesn't always work well. > (Time-of-day fails when people have schedules more complicated than > factory workers; location fails for road warriors and placetype fails > for people working at home.) > > Thus, my proposal: RPID adds a element that has a > few standard > labels, such as 'home' and 'work', with other labels that can > be added. > The primary purpose of this information is not so much in the NOTIFY, > but in the PUBLISH phase. The idea is that I can publish my > 'sphere' and > this will automatically switch between different modes of visibility, > different sets of rules. In the rule language being discussed in > GEOPRIV, this might take the form > > Person sphere access > ------------------------------------------------------- > boss@work work location,activity > friend home busy/idle > spouse home,work location > bowling buddy bowling location > > Note that this is not a group as traditionally understood - the same > person may well share multiple spheres with me. Also, unlike > groups, the > visibility depends on my activity, not just a membership in a list. > > While the sphere information would often have to be derived > manually, it > is plausible that external hints can be used. Sometimes location will > do, but only in the narrowest sense ("at work site"). Time > will only be > useful if users are meticulous about keeping calendars and have very > regular schedules. Other hints are probably better, such as > being logged > into a VPN for work, or wearing a work badge. > > The current RPID and come close, but are not > quite the same. > > I'd appreciate comments. > > Henning > > > > > > > > > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Sep 8 16:25:52 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 QAA19295 for ; Mon, 8 Sep 2003 16:25:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wSZl-0004xn-0O for simple-archive@odin.ietf.org; Mon, 08 Sep 2003 16:25:29 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h88KPSix019073 for simple-archive@odin.ietf.org; Mon, 8 Sep 2003 16:25:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wSZk-0004xY-Sy for simple-web-archive@optimus.ietf.org; Mon, 08 Sep 2003 16:25:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19105; Mon, 8 Sep 2003 16:25:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19wSZg-0007Kb-00; Mon, 08 Sep 2003 16:25:24 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19wSYp-0007G4-00; Mon, 08 Sep 2003 16:24:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wSYN-0004Hk-Qn; Mon, 08 Sep 2003 16: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 19wRXC-0002im-H1 for simple@optimus.ietf.org; Mon, 08 Sep 2003 15:18: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 PAA16507; Mon, 8 Sep 2003 15:18:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19wRXA-0006Fj-00; Mon, 08 Sep 2003 15:18:44 -0400 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 19wRXA-0006FW-00; Mon, 08 Sep 2003 15:18:44 -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 PAA03685; Mon, 8 Sep 2003 15:18:11 -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 PAA02416; Mon, 8 Sep 2003 15:18:13 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Mon, 8 Sep 2003 15:18:12 -0400 Message-ID: <313680C9A886D511A06000204840E1CF070B5E05@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Henning Schulzrinne'" , geopriv@ietf.org, simple@ietf.org Subject: RE: [Simple] Individuals, hats and spheres 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, 8 Sep 2003 15:18:12 -0400 There are lots of ways to categorize watchers. "Sphere" is one of them. Categorizing the PRESENTITY in a sphere is pretty strange to my way of thinking. If I publish my location, then it's my location, and that is independent of my sphere. I can be at home, and still be working. If I am, I'll probably take calls, and reveal location, to my friends. If I'm working at home, then presumably I'm in the work sphere as you propose it. The only thing the sphere could do on the watcher is to somehow change visibility to, say, office team-mates, when I'm working from home, as opposed to working in my office. While I would agree there is some value in that, it seems pretty small. What I want to do is to have different rules for different categories of watchers. I don't see how this proposal helps me categorize watchers. Brian > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Sunday, September 07, 2003 2:05 PM > To: geopriv@ietf.org; simple@ietf.org > Subject: [Simple] Individuals, hats and spheres > > > For access control to presence and geo data, there seem to be two use > cases that almost all discussions circle back to: spheres and > individuals. > > By spheres I mean the various parts that most of us divide our life > into, the different 'hats' that we wear, as member of a family, as an > employee, as a member of various voluntary organizations ranging from > the professional assocations like the IEEE and IETF to religious > organizations and social organizations like the Boy Scouts or bowling > league. > > Many of the use cases can be boiled down to "if I'm in one sphere, I > don't people in another sphere to see what I'm doing". (Here, > I think is > what I'm doing is mostly the important aspect if you exclude total > strangers that could do me physical harm, where simple knowledge of > location matters. For privacy, it is mostly that location is a good > indication of activity and interests.) > > The discussion so far always seems to make the work/home distinction, > but before "Bowling Alone", people also had many other > spheres in what I > gather is commonly called "civil society". If somebody is > with the scout > group on an outing, the may want the other scout masters to > be able to > find where they are, but they probably don't want them to > track them the > rest of the week. > > The rules discussion in GEOPRIV and, to a lesser extent, in > SIMPLE, have > tried to approximate these spheres, by location, time or other hints, > but for a variety of reasons, this doesn't always work well. > (Time-of-day fails when people have schedules more complicated than > factory workers; location fails for road warriors and placetype fails > for people working at home.) > > Thus, my proposal: RPID adds a element that has a > few standard > labels, such as 'home' and 'work', with other labels that can > be added. > The primary purpose of this information is not so much in the NOTIFY, > but in the PUBLISH phase. The idea is that I can publish my > 'sphere' and > this will automatically switch between different modes of visibility, > different sets of rules. In the rule language being discussed in > GEOPRIV, this might take the form > > Person sphere access > ------------------------------------------------------- > boss@work work location,activity > friend home busy/idle > spouse home,work location > bowling buddy bowling location > > Note that this is not a group as traditionally understood - the same > person may well share multiple spheres with me. Also, unlike > groups, the > visibility depends on my activity, not just a membership in a list. > > While the sphere information would often have to be derived > manually, it > is plausible that external hints can be used. Sometimes location will > do, but only in the narrowest sense ("at work site"). Time > will only be > useful if users are meticulous about keeping calendars and have very > regular schedules. Other hints are probably better, such as > being logged > into a VPN for work, or wearing a work badge. > > The current RPID and come close, but are not > quite the same. > > I'd appreciate comments. > > Henning > > > > > > > > > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Sep 8 17:12: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 RAA21750; Mon, 8 Sep 2003 17:12:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19wTJm-0000Tk-00; Mon, 08 Sep 2003 17:13:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19wTJm-0000Tg-00; Mon, 08 Sep 2003 17:13:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wTJl-0007BP-GJ; Mon, 08 Sep 2003 17:13:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wTJD-0007AV-QW for simple@optimus.ietf.org; Mon, 08 Sep 2003 17: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 RAA21733 for ; Mon, 8 Sep 2003 17:12:19 -0400 (EDT) From: Markus.Isomaki@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19wTJB-0000QM-00 for simple@ietf.org; Mon, 08 Sep 2003 17:12:25 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19wTJA-0000QJ-00 for simple@ietf.org; Mon, 08 Sep 2003 17:12:24 -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 h88LCN417214 for ; Tue, 9 Sep 2003 00:12:24 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 9 Sep 2003 00:12:23 +0300 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 9 Sep 2003 00:12:23 +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] [Fwd: Re: NETCONF WG meeting minutes for IETF #57] Message-ID: Thread-Topic: [Simple] [Fwd: Re: NETCONF WG meeting minutes for IETF #57] Thread-Index: AcN0/E1ngp7o6GexSSqEtlzdko16DQBUEdtA To: , Cc: , , X-OriginalArrivalTime: 08 Sep 2003 21:12:23.0145 (UTC) FILETIME=[E5803590:01C3764D] 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, 9 Sep 2003 00:12:22 +0300 Content-Transfer-Encoding: quoted-printable Hi, Jonathan Rosenberg wrote: > As such, the best we can do is avoid dependencies on encoding details=20 > (such as whether placetype is put in a status or future-status=20 > element). I would suggest that the best way to do this is to allow=20 > filters and authorization policies to point at rpids and pidf=20 > elements=20 > by element name, no matter where that element appears in an XML=20 > document. So, if I don't want people to know my geoloc, I would=20 > specify an auth policy that blocks "placetype". I completely agree with this. Element-level control is sometimes = necessary. It would also be good if the presence server doing the = authorization/filtering did not have to understand the meaning of the = elements, but it could just do dumb comparisons. What I've heard from people is that XPath allows you to do also this = kind of "multi-level" matching, so you would not have to know exactly = where "placetype" can occur. If this is really true, is there any reason = why not to take it as the solution. It is not a major problem to define = something just for this purpose, but if XPath works, why not use it.=20 Markus=20 > -----Original Message----- > From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: 07 September, 2003 07:53 > To: Henning Schulzrinne > Cc: Khartabil Hisham (NMP/Helsinki); simple@ietf.org;=20 > gk@ninebynine.org > Subject: Re: [Simple] [Fwd: Re: NETCONF WG meeting minutes=20 > for IETF #57] >=20 >=20 >=20 >=20 > Henning Schulzrinne wrote: >=20 > > I agree that we seem to need to ways of identifying information: > >=20 > > (1) syntactically, for fine-grained control; after all,=20 > someone may well=20 > > be prepared to reveal the type of place they are in, but=20 > not the actual=20 > > location. >=20 > Fair enough, thought I don't think I would call this "syntactic". >=20 > >=20 > > (2) semantically, where we label each piece of information=20 > as being part=20 > > of one or more broader classes, such as "where am I" and "what am I=20 > > doing" or "what device capabilities do I have" or, as another axis,=20 > > "present" and "future". > >=20 > > Beyond the obvious location identification, it might be=20 > useful to go=20 > > through the set of PIDF and RPID (and related document)=20 > items to see if=20 > > they are amenable to such a grouping. If each group has one=20 > element,=20 > > this approach isn't too helpful. >=20 > I thought about this a bunch. >=20 > The conclusion I came to is that, in many cases, the types of=20 > authorization policies that users will want are those which block the=20 > ability of a watcher to deduce a specific fact. For example,=20 > if I take=20 > a day off, and don't want my boss or colleauges to know it, I will=20 > want my presence to be structured so that no one can figure=20 > out that I=20 > am not working. This would mean, for example, that if I am sleeping,=20 > this activity value should not be shown to watchers. >=20 > My geolocation concerns were similar. I think what users may want is=20 > the ability to say "I don't want people to know where I am". Many=20 > possible presence elements can reveal this - including ones like=20 > activity and privacy, which reveal indirect clues about location. >=20 > Unfortunately, I don't think its practical to have authorization=20 > mechanisms which require the server to figure out what rpid elements=20 > are needed to deduce a specific fact. >=20 > As such, the best we can do is avoid dependencies on encoding details=20 > (such as whether placetype is put in a status or future-status=20 > element). I would suggest that the best way to do this is to allow=20 > filters and authorization policies to point at rpids and pidf=20 > elements=20 > by element name, no matter where that element appears in an XML=20 > document. So, if I don't want people to know my geoloc, I would=20 > specify an auth policy that blocks "placetype". >=20 >=20 > >=20 > > Another approach (3) is to have a scale of privacy concern=20 > or 'presence=20 > > resolution', i.e., establish some default ordering, from=20 > "OPEN/CLOSED"=20 > > at the low end to "every new item that I publish" at the=20 > high end, with=20 > > no more than half a dozen levels. Each new element would=20 > then be labeled=20 > > as falling into one of these groupings. >=20 > I agree this is a great idea. In fact, I had exactly this kind of=20 > thing in mind for the compound permissions. >=20 > >=20 > > I think both (2) and (3) have the distinct advantage that=20 > they are far=20 > > easier to explain to users than dozens of checkboxes for each=20 > > RPID/geoloc/PIDF element. (3) is roughly similar to the=20 > privacy slider=20 > > in the Internet Options menu for IE, for example. There is no=20 > > requirement that everybody agrees with an ordering, just that it is=20 > > plausible for the majority of use cases. Advanced users can click=20 > > through to the per-element include/exclude list. >=20 > I agree that we don't want users to click on checkboxes for each rpid=20 > type. I think you might have a checkbox for "don't reveal my=20 > location", and when its selected, the client generates an xcap-auth=20 > document which blocks a whole bunch of elements, each listed by name.=20 > This may require us to produce a use case document that helps folks=20 > figure out what types of facts users might want to control, and what=20 > elements are involved in computing such facts. >=20 > -Jonathan R. >=20 > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Sep 8 17:13:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21789 for ; Mon, 8 Sep 2003 17:13:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wTJp-0007CS-KA for simple-archive@odin.ietf.org; Mon, 08 Sep 2003 17:13:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h88LD5WP027670 for simple-archive@odin.ietf.org; Mon, 8 Sep 2003 17:13:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wTJp-0007CD-Gi for simple-web-archive@optimus.ietf.org; Mon, 08 Sep 2003 17:13: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 RAA21750; Mon, 8 Sep 2003 17:12:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19wTJm-0000Tk-00; Mon, 08 Sep 2003 17:13:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19wTJm-0000Tg-00; Mon, 08 Sep 2003 17:13:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wTJl-0007BP-GJ; Mon, 08 Sep 2003 17:13:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wTJD-0007AV-QW for simple@optimus.ietf.org; Mon, 08 Sep 2003 17: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 RAA21733 for ; Mon, 8 Sep 2003 17:12:19 -0400 (EDT) From: Markus.Isomaki@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19wTJB-0000QM-00 for simple@ietf.org; Mon, 08 Sep 2003 17:12:25 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19wTJA-0000QJ-00 for simple@ietf.org; Mon, 08 Sep 2003 17:12:24 -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 h88LCN417214 for ; Tue, 9 Sep 2003 00:12:24 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 9 Sep 2003 00:12:23 +0300 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 9 Sep 2003 00:12:23 +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] [Fwd: Re: NETCONF WG meeting minutes for IETF #57] Message-ID: Thread-Topic: [Simple] [Fwd: Re: NETCONF WG meeting minutes for IETF #57] Thread-Index: AcN0/E1ngp7o6GexSSqEtlzdko16DQBUEdtA To: , Cc: , , X-OriginalArrivalTime: 08 Sep 2003 21:12:23.0145 (UTC) FILETIME=[E5803590:01C3764D] 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, 9 Sep 2003 00:12:22 +0300 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi, Jonathan Rosenberg wrote: > As such, the best we can do is avoid dependencies on encoding details=20 > (such as whether placetype is put in a status or future-status=20 > element). I would suggest that the best way to do this is to allow=20 > filters and authorization policies to point at rpids and pidf=20 > elements=20 > by element name, no matter where that element appears in an XML=20 > document. So, if I don't want people to know my geoloc, I would=20 > specify an auth policy that blocks "placetype". I completely agree with this. Element-level control is sometimes = necessary. It would also be good if the presence server doing the = authorization/filtering did not have to understand the meaning of the = elements, but it could just do dumb comparisons. What I've heard from people is that XPath allows you to do also this = kind of "multi-level" matching, so you would not have to know exactly = where "placetype" can occur. If this is really true, is there any reason = why not to take it as the solution. It is not a major problem to define = something just for this purpose, but if XPath works, why not use it.=20 Markus=20 > -----Original Message----- > From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: 07 September, 2003 07:53 > To: Henning Schulzrinne > Cc: Khartabil Hisham (NMP/Helsinki); simple@ietf.org;=20 > gk@ninebynine.org > Subject: Re: [Simple] [Fwd: Re: NETCONF WG meeting minutes=20 > for IETF #57] >=20 >=20 >=20 >=20 > Henning Schulzrinne wrote: >=20 > > I agree that we seem to need to ways of identifying information: > >=20 > > (1) syntactically, for fine-grained control; after all,=20 > someone may well=20 > > be prepared to reveal the type of place they are in, but=20 > not the actual=20 > > location. >=20 > Fair enough, thought I don't think I would call this "syntactic". >=20 > >=20 > > (2) semantically, where we label each piece of information=20 > as being part=20 > > of one or more broader classes, such as "where am I" and "what am I=20 > > doing" or "what device capabilities do I have" or, as another axis,=20 > > "present" and "future". > >=20 > > Beyond the obvious location identification, it might be=20 > useful to go=20 > > through the set of PIDF and RPID (and related document)=20 > items to see if=20 > > they are amenable to such a grouping. If each group has one=20 > element,=20 > > this approach isn't too helpful. >=20 > I thought about this a bunch. >=20 > The conclusion I came to is that, in many cases, the types of=20 > authorization policies that users will want are those which block the=20 > ability of a watcher to deduce a specific fact. For example,=20 > if I take=20 > a day off, and don't want my boss or colleauges to know it, I will=20 > want my presence to be structured so that no one can figure=20 > out that I=20 > am not working. This would mean, for example, that if I am sleeping,=20 > this activity value should not be shown to watchers. >=20 > My geolocation concerns were similar. I think what users may want is=20 > the ability to say "I don't want people to know where I am". Many=20 > possible presence elements can reveal this - including ones like=20 > activity and privacy, which reveal indirect clues about location. >=20 > Unfortunately, I don't think its practical to have authorization=20 > mechanisms which require the server to figure out what rpid elements=20 > are needed to deduce a specific fact. >=20 > As such, the best we can do is avoid dependencies on encoding details=20 > (such as whether placetype is put in a status or future-status=20 > element). I would suggest that the best way to do this is to allow=20 > filters and authorization policies to point at rpids and pidf=20 > elements=20 > by element name, no matter where that element appears in an XML=20 > document. So, if I don't want people to know my geoloc, I would=20 > specify an auth policy that blocks "placetype". >=20 >=20 > >=20 > > Another approach (3) is to have a scale of privacy concern=20 > or 'presence=20 > > resolution', i.e., establish some default ordering, from=20 > "OPEN/CLOSED"=20 > > at the low end to "every new item that I publish" at the=20 > high end, with=20 > > no more than half a dozen levels. Each new element would=20 > then be labeled=20 > > as falling into one of these groupings. >=20 > I agree this is a great idea. In fact, I had exactly this kind of=20 > thing in mind for the compound permissions. >=20 > >=20 > > I think both (2) and (3) have the distinct advantage that=20 > they are far=20 > > easier to explain to users than dozens of checkboxes for each=20 > > RPID/geoloc/PIDF element. (3) is roughly similar to the=20 > privacy slider=20 > > in the Internet Options menu for IE, for example. There is no=20 > > requirement that everybody agrees with an ordering, just that it is=20 > > plausible for the majority of use cases. Advanced users can click=20 > > through to the per-element include/exclude list. >=20 > I agree that we don't want users to click on checkboxes for each rpid=20 > type. I think you might have a checkbox for "don't reveal my=20 > location", and when its selected, the client generates an xcap-auth=20 > document which blocks a whole bunch of elements, each listed by name.=20 > This may require us to produce a use case document that helps folks=20 > figure out what types of facts users might want to control, and what=20 > elements are involved in computing such facts. >=20 > -Jonathan R. >=20 > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Sep 8 22:36: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 WAA02600; Mon, 8 Sep 2003 22:36: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 19wYMM-0007fe-Cn; Mon, 08 Sep 2003 22: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 19wYLu-0007eh-VW for simple@optimus.ietf.org; Mon, 08 Sep 2003 22:35: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 WAA02559; Mon, 8 Sep 2003 22:35:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19wYLm-0004Te-00; Mon, 08 Sep 2003 22:35:26 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 19wYLW-0004SX-00; Mon, 08 Sep 2003 22:35:10 -0400 Received: from bart.cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h892XEoI016409 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Mon, 8 Sep 2003 22:33:15 -0400 (EDT) Received: from cs.columbia.edu (localhost [127.0.0.1]) by bart.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h892XC9s003560; Mon, 8 Sep 2003 22:33:13 -0400 (EDT) Message-ID: <3F5D3BE6.4010504@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Rosen, Brian" CC: geopriv@ietf.org, simple@ietf.org Subject: Re: [Simple] Individuals, hats and spheres References: <313680C9A886D511A06000204840E1CF070B5E05@whq-msgusr-02.pit.comms.marconi.com> In-Reply-To: <313680C9A886D511A06000204840E1CF070B5E05@whq-msgusr-02.pit.comms.marconi.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, 08 Sep 2003 22:33:10 -0400 Content-Transfer-Encoding: 7bit Rosen, Brian wrote: > SIMPLE terminology> > There are lots of ways to categorize watchers. "Sphere" is one > of them. Categorizing the PRESENTITY in a sphere is pretty strange > to my way of thinking. This categorization is, in my view, useful in two ways: - If this information reaches the watcher, it is a good indication as to whether I should communicate with you about private or work matters. - If this information is used only in PUBLISH, it in turn governs disclosure of other information. > > If I publish my location, then it's my location, and that is independent > of my sphere. I can be at home, and still be working. If I am, I'll Correct. That's why placetype, for example, is insufficient. > probably take calls, and reveal location, to my friends. If I'm working If you're willing to be found by friends, you're actually in two spheres at once. Not uncommon. > at home, then presumably I'm in the work sphere as you propose it. > The only thing the sphere could do on the watcher is to somehow change > visibility to, say, office team-mates, when I'm working from home, > as opposed to working in my office. While I would agree there is > some value in that, it seems pretty small. Almost all of the geopriv discussion seems to have focused on variations on that theme... > > What I want to do is to have different rules for different categories > of watchers. I don't see how this proposal helps me categorize > watchers. The sphere is such a categorization, by assigning rights to a sphere: sphere work boss@work can see location work friend1 cannot see location home friend1 can see location work colleague-friend can see location home colleague-friend can see location I'm not sure how else you propose to categorize watchers. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Sep 8 22:38:04 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02691 for ; Mon, 8 Sep 2003 22:38:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wYNy-00081S-84 for simple-archive@odin.ietf.org; Mon, 08 Sep 2003 22:37:42 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h892bgsC030832 for simple-archive@odin.ietf.org; Mon, 8 Sep 2003 22:37:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wYNx-000815-Tb for simple-web-archive@optimus.ietf.org; Mon, 08 Sep 2003 22:37:41 -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 WAA02600; Mon, 8 Sep 2003 22:36: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 19wYMM-0007fe-Cn; Mon, 08 Sep 2003 22: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 19wYLu-0007eh-VW for simple@optimus.ietf.org; Mon, 08 Sep 2003 22:35: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 WAA02559; Mon, 8 Sep 2003 22:35:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19wYLm-0004Te-00; Mon, 08 Sep 2003 22:35:26 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 19wYLW-0004SX-00; Mon, 08 Sep 2003 22:35:10 -0400 Received: from bart.cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h892XEoI016409 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Mon, 8 Sep 2003 22:33:15 -0400 (EDT) Received: from cs.columbia.edu (localhost [127.0.0.1]) by bart.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h892XC9s003560; Mon, 8 Sep 2003 22:33:13 -0400 (EDT) Message-ID: <3F5D3BE6.4010504@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Rosen, Brian" CC: geopriv@ietf.org, simple@ietf.org Subject: Re: [Simple] Individuals, hats and spheres References: <313680C9A886D511A06000204840E1CF070B5E05@whq-msgusr-02.pit.comms.marconi.com> In-Reply-To: <313680C9A886D511A06000204840E1CF070B5E05@whq-msgusr-02.pit.comms.marconi.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, 08 Sep 2003 22:33:10 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Rosen, Brian wrote: > SIMPLE terminology> > There are lots of ways to categorize watchers. "Sphere" is one > of them. Categorizing the PRESENTITY in a sphere is pretty strange > to my way of thinking. This categorization is, in my view, useful in two ways: - If this information reaches the watcher, it is a good indication as to whether I should communicate with you about private or work matters. - If this information is used only in PUBLISH, it in turn governs disclosure of other information. > > If I publish my location, then it's my location, and that is independent > of my sphere. I can be at home, and still be working. If I am, I'll Correct. That's why placetype, for example, is insufficient. > probably take calls, and reveal location, to my friends. If I'm working If you're willing to be found by friends, you're actually in two spheres at once. Not uncommon. > at home, then presumably I'm in the work sphere as you propose it. > The only thing the sphere could do on the watcher is to somehow change > visibility to, say, office team-mates, when I'm working from home, > as opposed to working in my office. While I would agree there is > some value in that, it seems pretty small. Almost all of the geopriv discussion seems to have focused on variations on that theme... > > What I want to do is to have different rules for different categories > of watchers. I don't see how this proposal helps me categorize > watchers. The sphere is such a categorization, by assigning rights to a sphere: sphere work boss@work can see location work friend1 cannot see location home friend1 can see location work colleague-friend can see location home colleague-friend can see location I'm not sure how else you propose to categorize watchers. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Sep 8 23:53: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 XAA05103; Mon, 8 Sep 2003 23:53: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 19wZYr-0001Mt-IT; Mon, 08 Sep 2003 23: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 19wZYo-0001MD-2C for simple@optimus.ietf.org; Mon, 08 Sep 2003 23:52:58 -0400 Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05059; Mon, 8 Sep 2003 23:52:44 -0400 (EDT) Received: from bart.cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h893qpoI005242 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Mon, 8 Sep 2003 23:52:51 -0400 (EDT) Received: from cs.columbia.edu (localhost [127.0.0.1]) by bart.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h893qn9s003756; Mon, 8 Sep 2003 23:52:50 -0400 (EDT) Message-ID: <3F5D4E8E.1060608@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dirk.Trossen@nokia.com CC: geopriv@ietf.org, simple@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Re: [Geopriv] Individuals, hats and spheres Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.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, 08 Sep 2003 23:52:46 -0400 Content-Transfer-Encoding: 7bit Dirk.Trossen@nokia.com wrote: > I like the idea of enabling a certain set of rules (as opposed to have conditional single > rules, the condition being e.g., the identity of the watcher) based on a certain condition. > However, I was wondering whether this is intended to be bound to the element? > Let me try to describe the underlying, general method that I understood from your proposal: > Allow for enabling a defined set of rules based on a certain condition, in which the > condition would be a certain value/range of an RPID element. That is indeed the general problem. However, here, my objective is far narrower. I'm trying to capture one aspect of the condition/context/state of the presentity, namely its role-based interaction with other humans. There are many other variables, such as time, space, other physical measurements ("it's hot, so don't bother me") - all of which may be combined to select a certain set of permissions. Indeed, the core ruleset discussed in GEOPRIV contains some of these conditions (time, space). I just happen to believe that for access to information about human activities, our relationship to humans and how we divide our life is one of the more important items. > > Hence, with this understanding of your proposal in mind, would it be possible/desirable to > use other RPID elements? In this, I could define a set of rules that is enabled when > is "work" or is "meeting". That is certainly possible and useful, in my view. I wanted to start small, with a broad brush. It might again be helpful to enumerate some plausible examples of privacy policies that real people are likely to use. I found that in many cases, the or is really just a stand-in for "a part of my world that has distinct assumptions, expectations, obligations and conventions". I'm not a sociologist, so maybe there's a better term for this than sphere. > > Dirk _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Sep 8 23:53:57 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 XAA05139 for ; Mon, 8 Sep 2003 23:53:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wZZP-0001RV-19 for simple-archive@odin.ietf.org; Mon, 08 Sep 2003 23:53:35 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h893rYvA005539 for simple-archive@odin.ietf.org; Mon, 8 Sep 2003 23:53:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wZZO-0001RG-UJ for simple-web-archive@optimus.ietf.org; Mon, 08 Sep 2003 23:53:34 -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 XAA05103; Mon, 8 Sep 2003 23:53: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 19wZYr-0001Mt-IT; Mon, 08 Sep 2003 23: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 19wZYo-0001MD-2C for simple@optimus.ietf.org; Mon, 08 Sep 2003 23:52:58 -0400 Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05059; Mon, 8 Sep 2003 23:52:44 -0400 (EDT) Received: from bart.cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h893qpoI005242 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Mon, 8 Sep 2003 23:52:51 -0400 (EDT) Received: from cs.columbia.edu (localhost [127.0.0.1]) by bart.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h893qn9s003756; Mon, 8 Sep 2003 23:52:50 -0400 (EDT) Message-ID: <3F5D4E8E.1060608@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dirk.Trossen@nokia.com CC: geopriv@ietf.org, simple@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Re: [Geopriv] Individuals, hats and spheres Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.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, 08 Sep 2003 23:52:46 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Dirk.Trossen@nokia.com wrote: > I like the idea of enabling a certain set of rules (as opposed to have conditional single > rules, the condition being e.g., the identity of the watcher) based on a certain condition. > However, I was wondering whether this is intended to be bound to the element? > Let me try to describe the underlying, general method that I understood from your proposal: > Allow for enabling a defined set of rules based on a certain condition, in which the > condition would be a certain value/range of an RPID element. That is indeed the general problem. However, here, my objective is far narrower. I'm trying to capture one aspect of the condition/context/state of the presentity, namely its role-based interaction with other humans. There are many other variables, such as time, space, other physical measurements ("it's hot, so don't bother me") - all of which may be combined to select a certain set of permissions. Indeed, the core ruleset discussed in GEOPRIV contains some of these conditions (time, space). I just happen to believe that for access to information about human activities, our relationship to humans and how we divide our life is one of the more important items. > > Hence, with this understanding of your proposal in mind, would it be possible/desirable to > use other RPID elements? In this, I could define a set of rules that is enabled when > is "work" or is "meeting". That is certainly possible and useful, in my view. I wanted to start small, with a broad brush. It might again be helpful to enumerate some plausible examples of privacy policies that real people are likely to use. I found that in many cases, the or is really just a stand-in for "a part of my world that has distinct assumptions, expectations, obligations and conventions". I'm not a sociologist, so maybe there's a better term for this than sphere. > > Dirk _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Sep 9 03:08: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 DAA23343; Tue, 9 Sep 2003 03:08: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 19wcba-0000Lq-IB; Tue, 09 Sep 2003 03:08:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wcbA-0000Ev-DQ for simple@optimus.ietf.org; Tue, 09 Sep 2003 03:07:36 -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 DAA23309; Tue, 9 Sep 2003 03:07:12 -0400 (EDT) From: hisham.khartabil@nokia.com 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 h8976SB01124; Tue, 9 Sep 2003 10:06:31 +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, 9 Sep 2003 10:06:26 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 9 Sep 2003 10:06: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" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Re: [Geopriv] Individuals, hats and spheres Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017970B0@esebe019.ntc.nokia.com> Thread-Topic: [Simple] Re: [Geopriv] Individuals, hats and spheres Thread-Index: AcN2hewXMFZEsZeoRcCmnsukh7o+kAAGht5w To: , Cc: , X-OriginalArrivalTime: 09 Sep 2003 07:06:25.0622 (UTC) FILETIME=[E2129760:01C376A0] 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, 9 Sep 2003 10:06:24 +0300 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Tuesday, September 09, 2003 6:53 AM > To: Trossen Dirk (NRC/Boston) > Cc: geopriv@ietf.org; simple@ietf.org > Subject: [Simple] Re: [Geopriv] Individuals, hats and spheres >=20 >=20 > Dirk.Trossen@nokia.com wrote: >=20 >=20 > > I like the idea of enabling a certain set of rules (as=20 > opposed to have conditional single > > rules, the condition being e.g., the identity of the=20 > watcher) based on a certain condition.=20 > > However, I was wondering whether this is intended to be=20 > bound to the element?=20 > > Let me try to describe the underlying, general method that=20 > I understood from your proposal: > > Allow for enabling a defined set of rules based on a=20 > certain condition, in which the > > condition would be a certain value/range of an RPID element.=20 >=20 > That is indeed the general problem. However, here, my=20 > objective is far=20 > narrower. I'm trying to capture one aspect of the=20 > condition/context/state of the presentity, namely its role-based=20 > interaction with other humans. There are many other=20 > variables, such as=20 > time, space, other physical measurements ("it's hot, so don't bother=20 > me") - all of which may be combined to select a certain set of=20 > permissions. Indeed, the core ruleset discussed in GEOPRIV=20 > contains some=20 > of these conditions (time, space). >=20 > I just happen to believe that for access to information about human=20 > activities, our relationship to humans and how we divide our=20 > life is one=20 > of the more important items. >=20 > >=20 > > Hence, with this understanding of your proposal in mind,=20 > would it be possible/desirable to > > use other RPID elements? In this, I could define a set of=20 > rules that is enabled when=20 > > is "work" or is "meeting".=20 >=20 > That is certainly possible and useful, in my view. I wanted to start=20 > small, with a broad brush. It might again be helpful to=20 > enumerate some=20 > plausible examples of privacy policies that real people are likely to=20 > use. I found that in many cases, the or=20 > is really=20 > just a stand-in for "a part of my world that has distinct=20 > assumptions,=20 > expectations, obligations and conventions". I'm not a sociologist, so=20 > maybe there's a better term for this than sphere. Dimension, perhaps. Just a few questions: - Why is a sphere different than a group? - Why this type of analogy is limited to geoloc?=20 - How this is different from the stream-header we had in PUBLISH? /Hisham >=20 >=20 > >=20 > > Dirk >=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 Sep 9 03:09:03 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 DAA23367 for ; Tue, 9 Sep 2003 03:09:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wccB-0000SV-UX for simple-archive@odin.ietf.org; Tue, 09 Sep 2003 03:08:40 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8978drB001753 for simple-archive@odin.ietf.org; Tue, 9 Sep 2003 03:08:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wccA-0000SC-Rr for simple-web-archive@optimus.ietf.org; Tue, 09 Sep 2003 03:08:38 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23343; Tue, 9 Sep 2003 03:08: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 19wcba-0000Lq-IB; Tue, 09 Sep 2003 03:08:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wcbA-0000Ev-DQ for simple@optimus.ietf.org; Tue, 09 Sep 2003 03:07:36 -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 DAA23309; Tue, 9 Sep 2003 03:07:12 -0400 (EDT) From: hisham.khartabil@nokia.com 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 h8976SB01124; Tue, 9 Sep 2003 10:06:31 +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, 9 Sep 2003 10:06:26 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 9 Sep 2003 10:06: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" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Re: [Geopriv] Individuals, hats and spheres Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017970B0@esebe019.ntc.nokia.com> Thread-Topic: [Simple] Re: [Geopriv] Individuals, hats and spheres Thread-Index: AcN2hewXMFZEsZeoRcCmnsukh7o+kAAGht5w To: , Cc: , X-OriginalArrivalTime: 09 Sep 2003 07:06:25.0622 (UTC) FILETIME=[E2129760:01C376A0] 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, 9 Sep 2003 10:06:24 +0300 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Tuesday, September 09, 2003 6:53 AM > To: Trossen Dirk (NRC/Boston) > Cc: geopriv@ietf.org; simple@ietf.org > Subject: [Simple] Re: [Geopriv] Individuals, hats and spheres >=20 >=20 > Dirk.Trossen@nokia.com wrote: >=20 >=20 > > I like the idea of enabling a certain set of rules (as=20 > opposed to have conditional single > > rules, the condition being e.g., the identity of the=20 > watcher) based on a certain condition.=20 > > However, I was wondering whether this is intended to be=20 > bound to the element?=20 > > Let me try to describe the underlying, general method that=20 > I understood from your proposal: > > Allow for enabling a defined set of rules based on a=20 > certain condition, in which the > > condition would be a certain value/range of an RPID element.=20 >=20 > That is indeed the general problem. However, here, my=20 > objective is far=20 > narrower. I'm trying to capture one aspect of the=20 > condition/context/state of the presentity, namely its role-based=20 > interaction with other humans. There are many other=20 > variables, such as=20 > time, space, other physical measurements ("it's hot, so don't bother=20 > me") - all of which may be combined to select a certain set of=20 > permissions. Indeed, the core ruleset discussed in GEOPRIV=20 > contains some=20 > of these conditions (time, space). >=20 > I just happen to believe that for access to information about human=20 > activities, our relationship to humans and how we divide our=20 > life is one=20 > of the more important items. >=20 > >=20 > > Hence, with this understanding of your proposal in mind,=20 > would it be possible/desirable to > > use other RPID elements? In this, I could define a set of=20 > rules that is enabled when=20 > > is "work" or is "meeting".=20 >=20 > That is certainly possible and useful, in my view. I wanted to start=20 > small, with a broad brush. It might again be helpful to=20 > enumerate some=20 > plausible examples of privacy policies that real people are likely to=20 > use. I found that in many cases, the or=20 > is really=20 > just a stand-in for "a part of my world that has distinct=20 > assumptions,=20 > expectations, obligations and conventions". I'm not a sociologist, so=20 > maybe there's a better term for this than sphere. Dimension, perhaps. Just a few questions: - Why is a sphere different than a group? - Why this type of analogy is limited to geoloc?=20 - How this is different from the stream-header we had in PUBLISH? /Hisham >=20 >=20 > >=20 > > Dirk >=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 Sep 9 03:36:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24137; Tue, 9 Sep 2003 03:36:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wd2g-00016p-UE; Tue, 09 Sep 2003 03: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 19wd2W-00016X-Fe for simple@optimus.ietf.org; Tue, 09 Sep 2003 03:35:57 -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 DAA24117 for ; Tue, 9 Sep 2003 03:35:45 -0400 (EDT) From: hisham.khartabil@nokia.com 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 h897ZnB07851 for ; Tue, 9 Sep 2003 10:35: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 ; Tue, 9 Sep 2003 10:35:49 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 9 Sep 2003 10:35:49 +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] [Fwd: Re: NETCONF WG meeting minutes for IETF #57] Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017970B1@esebe019.ntc.nokia.com> Thread-Topic: [Simple] [Fwd: Re: NETCONF WG meeting minutes for IETF #57] Thread-Index: AcN1ZgZqYU7HVCMUQ9WTe/Mdy33qQgBPFwqg To: , Cc: , X-OriginalArrivalTime: 09 Sep 2003 07:35:49.0108 (UTC) FILETIME=[FD313340:01C376A4] 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, 9 Sep 2003 10:35:48 +0300 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Sunday, September 07, 2003 5:03 PM > To: Jonathan Rosenberg > Cc: simple@ietf.org; gk@ninebynine.org > Subject: Re: [Simple] [Fwd: Re: NETCONF WG meeting minutes=20 > for IETF #57] >=20 >=20 > Jonathan Rosenberg wrote: >=20 >=20 > > Fair enough, thought I don't think I would call this "syntactic". >=20 > Document-oriented? Presumably it would use >=20 > > My geolocation concerns were similar. I think what users=20 > may want is the=20 > > ability to say "I don't want people to know where I am".=20 > Many possible=20 > > presence elements can reveal this - including ones like=20 > activity and=20 > > privacy, which reveal indirect clues about location. >=20 > I don't think this is necessarily binary. For example, I might be ok=20 > with letting others know what timezone I'm in, although this may hint=20 > that I'm traveling or on vacation. >=20 > >=20 > > Unfortunately, I don't think its practical to have authorization=20 > > mechanisms which require the server to figure out what rpid=20 > elements are=20 > > needed to deduce a specific fact. >=20 > Particularly if this is meant to be more than a binary yes/no=20 > decision.=20 > Different elements reveal different amounts of information=20 > depending on=20 > context, depending on what the watcher knows about me, etc. (For=20 > example, if the watcher knows that my employer has a branch office in=20 > Tokyo, even something as vague as timezone=3DJapan will provide a good = > hint as to what I'm doing right now.) >=20 > >=20 > > As such, the best we can do is avoid dependencies on=20 > encoding details=20 > > (such as whether placetype is put in a status or=20 > future-status element).=20 > > I would suggest that the best way to do this is to allow=20 > filters and=20 > > authorization policies to point at rpids and pidf elements=20 > by element=20 > > name, no matter where that element appears in an XML=20 > document. So, if I=20 > > don't want people to know my geoloc, I would specify an=20 > auth policy that=20 > > blocks "placetype". >=20 > Agreed. As a side-effect, this essentially makes the namespace flat,=20 > i.e., we can't have two PIDF-and-related namespaces use the same term=20 > for something different. I don't think this is a significant=20 > restriction=20 > in practice. One possibility to formalize this is to indeed have a=20 > single IANA registry for presence attributes. Each entry=20 > would point to=20 > one or more namespace/element-name combinations. Well, with XPath, you don't even need that. Let me expand the example I = gave in an earlier email: //*[placetype] >=20 >=20 >=20 > > I agree this is a great idea. In fact, I had exactly this=20 > kind of thing=20 > > in mind for the compound permissions. >=20 > The proof of feasibility will be whether we can arrive at=20 > such a list,=20 > across PIDF, RPID + related, and the emerging GEOPRIV items. I would=20 > suggest that these levels should be motivated by the likely use and=20 > audience. For example, for two mid-levels: >=20 > (1) "Can I visit this person": this would be useful for intra-company=20 > coordination >=20 > Would need information about my campus-level whereabouts. >=20 > (2) "Is this person amenable to business (or private) communication?" >=20 > This would include timezone, possibly country and=20 > open/closed. Possibly=20 > a 'private/business' coarse-grain activity (rather than a placetype). >=20 > Are there others? >=20 > > I agree that we don't want users to click on checkboxes for=20 > each rpid=20 > > type. I think you might have a checkbox for "don't reveal=20 > my location",=20 > > and when its selected, the client generates an xcap-auth=20 > document which=20 > > blocks a whole bunch of elements, each listed by name. This=20 > may require=20 > > us to produce a use case document that helps folks figure=20 > out what types=20 > > of facts users might want to control, and what elements are=20 > involved in=20 > > computing such facts. >=20 > There was a long discussion on this topic at the GEOPRIV=20 > interim meeting=20 > that took place Friday and Saturday. Two approaches were identified: >=20 > (1) a tool presents a high-level interface to the user, but the=20 > on-the-wire ruleset (XCAP-AUTH, etc.) identifies lower-level elements=20 > (either at the document-oriented level or, probably better,=20 > by content=20 > type). >=20 > (2) the authorization policy itself contains a high-level description=20 > that then is translated by the policy enforcement entity into=20 > filtering=20 > actions. >=20 > (2) has fewer things to test and thus may reach=20 > interoperability sooner,=20 > but requires that the policy enforcement point be upgraded=20 > each time a=20 > new element is added. >=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 Sep 9 03:37:03 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 DAA24164 for ; Tue, 9 Sep 2003 03:37:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wd3H-0001BJ-8D for simple-archive@odin.ietf.org; Tue, 09 Sep 2003 03:36:39 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h897adLX004540 for simple-archive@odin.ietf.org; Tue, 9 Sep 2003 03:36:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wd3G-0001B9-0P for simple-web-archive@optimus.ietf.org; Tue, 09 Sep 2003 03:36:38 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24137; Tue, 9 Sep 2003 03:36:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wd2g-00016p-UE; Tue, 09 Sep 2003 03: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 19wd2W-00016X-Fe for simple@optimus.ietf.org; Tue, 09 Sep 2003 03:35:57 -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 DAA24117 for ; Tue, 9 Sep 2003 03:35:45 -0400 (EDT) From: hisham.khartabil@nokia.com 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 h897ZnB07851 for ; Tue, 9 Sep 2003 10:35: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 ; Tue, 9 Sep 2003 10:35:49 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 9 Sep 2003 10:35:49 +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] [Fwd: Re: NETCONF WG meeting minutes for IETF #57] Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017970B1@esebe019.ntc.nokia.com> Thread-Topic: [Simple] [Fwd: Re: NETCONF WG meeting minutes for IETF #57] Thread-Index: AcN1ZgZqYU7HVCMUQ9WTe/Mdy33qQgBPFwqg To: , Cc: , X-OriginalArrivalTime: 09 Sep 2003 07:35:49.0108 (UTC) FILETIME=[FD313340:01C376A4] 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, 9 Sep 2003 10:35:48 +0300 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Sunday, September 07, 2003 5:03 PM > To: Jonathan Rosenberg > Cc: simple@ietf.org; gk@ninebynine.org > Subject: Re: [Simple] [Fwd: Re: NETCONF WG meeting minutes=20 > for IETF #57] >=20 >=20 > Jonathan Rosenberg wrote: >=20 >=20 > > Fair enough, thought I don't think I would call this "syntactic". >=20 > Document-oriented? Presumably it would use >=20 > > My geolocation concerns were similar. I think what users=20 > may want is the=20 > > ability to say "I don't want people to know where I am".=20 > Many possible=20 > > presence elements can reveal this - including ones like=20 > activity and=20 > > privacy, which reveal indirect clues about location. >=20 > I don't think this is necessarily binary. For example, I might be ok=20 > with letting others know what timezone I'm in, although this may hint=20 > that I'm traveling or on vacation. >=20 > >=20 > > Unfortunately, I don't think its practical to have authorization=20 > > mechanisms which require the server to figure out what rpid=20 > elements are=20 > > needed to deduce a specific fact. >=20 > Particularly if this is meant to be more than a binary yes/no=20 > decision.=20 > Different elements reveal different amounts of information=20 > depending on=20 > context, depending on what the watcher knows about me, etc. (For=20 > example, if the watcher knows that my employer has a branch office in=20 > Tokyo, even something as vague as timezone=3DJapan will provide a good = > hint as to what I'm doing right now.) >=20 > >=20 > > As such, the best we can do is avoid dependencies on=20 > encoding details=20 > > (such as whether placetype is put in a status or=20 > future-status element).=20 > > I would suggest that the best way to do this is to allow=20 > filters and=20 > > authorization policies to point at rpids and pidf elements=20 > by element=20 > > name, no matter where that element appears in an XML=20 > document. So, if I=20 > > don't want people to know my geoloc, I would specify an=20 > auth policy that=20 > > blocks "placetype". >=20 > Agreed. As a side-effect, this essentially makes the namespace flat,=20 > i.e., we can't have two PIDF-and-related namespaces use the same term=20 > for something different. I don't think this is a significant=20 > restriction=20 > in practice. One possibility to formalize this is to indeed have a=20 > single IANA registry for presence attributes. Each entry=20 > would point to=20 > one or more namespace/element-name combinations. Well, with XPath, you don't even need that. Let me expand the example I = gave in an earlier email: //*[placetype] >=20 >=20 >=20 > > I agree this is a great idea. In fact, I had exactly this=20 > kind of thing=20 > > in mind for the compound permissions. >=20 > The proof of feasibility will be whether we can arrive at=20 > such a list,=20 > across PIDF, RPID + related, and the emerging GEOPRIV items. I would=20 > suggest that these levels should be motivated by the likely use and=20 > audience. For example, for two mid-levels: >=20 > (1) "Can I visit this person": this would be useful for intra-company=20 > coordination >=20 > Would need information about my campus-level whereabouts. >=20 > (2) "Is this person amenable to business (or private) communication?" >=20 > This would include timezone, possibly country and=20 > open/closed. Possibly=20 > a 'private/business' coarse-grain activity (rather than a placetype). >=20 > Are there others? >=20 > > I agree that we don't want users to click on checkboxes for=20 > each rpid=20 > > type. I think you might have a checkbox for "don't reveal=20 > my location",=20 > > and when its selected, the client generates an xcap-auth=20 > document which=20 > > blocks a whole bunch of elements, each listed by name. This=20 > may require=20 > > us to produce a use case document that helps folks figure=20 > out what types=20 > > of facts users might want to control, and what elements are=20 > involved in=20 > > computing such facts. >=20 > There was a long discussion on this topic at the GEOPRIV=20 > interim meeting=20 > that took place Friday and Saturday. Two approaches were identified: >=20 > (1) a tool presents a high-level interface to the user, but the=20 > on-the-wire ruleset (XCAP-AUTH, etc.) identifies lower-level elements=20 > (either at the document-oriented level or, probably better,=20 > by content=20 > type). >=20 > (2) the authorization policy itself contains a high-level description=20 > that then is translated by the policy enforcement entity into=20 > filtering=20 > actions. >=20 > (2) has fewer things to test and thus may reach=20 > interoperability sooner,=20 > but requires that the policy enforcement point be upgraded=20 > each time a=20 > new element is added. >=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 Sep 9 03:40:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24246; Tue, 9 Sep 2003 03:40: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 19wd6Y-0001X2-FU; Tue, 09 Sep 2003 03:40:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wd5g-0001Ud-5m for simple@optimus.ietf.org; Tue, 09 Sep 2003 03:39: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 DAA24219 for ; Tue, 9 Sep 2003 03:39:01 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19wd5d-00075E-00 for simple@ietf.org; Tue, 09 Sep 2003 03:39:05 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19wd5S-00074Z-00 for simple@ietf.org; Tue, 09 Sep 2003 03:38:54 -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 h897acB08940 for ; Tue, 9 Sep 2003 10:36:41 +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, 9 Sep 2003 10:36:38 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 9 Sep 2003 10:36:38 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 9 Sep 2003 10:36:37 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:recallmessage MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Recall: [Simple] [Fwd: Re: NETCONF WG meeting minutes for IETF #57] Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017970B2@esebe019.ntc.nokia.com> Thread-Topic: [Simple] [Fwd: Re: NETCONF WG meeting minutes for IETF #57] Thread-Index: AcN2pRnBb9PF/qybT366BF5S6ah+Tw== Priority: Urgent Expiry-Date: Thu, 11 Sep 2003 10:36:35 +0300 To: , Cc: , X-OriginalArrivalTime: 09 Sep 2003 07:36:37.0670 (UTC) FILETIME=[1A232C60:01C376A5] 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, 9 Sep 2003 10:36:37 +0300 Content-Transfer-Encoding: quoted-printable Khartabil Hisham (NMP/Helsinki) would like to recall the message, = "[Simple] [Fwd: Re: NETCONF WG meeting minutes for IETF #57]". _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Sep 9 03:40:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24253; Tue, 9 Sep 2003 03:40:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wd6c-0001ZY-Hb; Tue, 09 Sep 2003 03:40:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wd5g-0001Uc-5M for simple@optimus.ietf.org; Tue, 09 Sep 2003 03:39: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 DAA24218 for ; Tue, 9 Sep 2003 03:39:01 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19wd5d-00075F-00 for simple@ietf.org; Tue, 09 Sep 2003 03:39:05 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19wd5S-00074f-00 for simple@ietf.org; Tue, 09 Sep 2003 03:38:54 -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 h897bHB09740 for ; Tue, 9 Sep 2003 10:37:19 +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, 9 Sep 2003 10:37:16 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 9 Sep 2003 10:37:16 +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] [Fwd: Re: NETCONF WG meeting minutes for IETF #57] Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017970B3@esebe019.ntc.nokia.com> Thread-Topic: [Simple] [Fwd: Re: NETCONF WG meeting minutes for IETF #57] Thread-Index: AcN0/DL647QxFyCeRxSZOOq8YFgdywBpUBbA To: , Cc: , X-OriginalArrivalTime: 09 Sep 2003 07:37:16.0657 (UTC) FILETIME=[31601E10:01C376A5] 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, 9 Sep 2003 10:37:16 +0300 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Sunday, September 07, 2003 7:53 AM > To: Henning Schulzrinne > Cc: Khartabil Hisham (NMP/Helsinki); simple@ietf.org;=20 > gk@ninebynine.org > Subject: Re: [Simple] [Fwd: Re: NETCONF WG meeting minutes=20 > for IETF #57] >=20 >=20 >=20 >=20 > Henning Schulzrinne wrote: >=20 > > I agree that we seem to need to ways of identifying information: > >=20 > > (1) syntactically, for fine-grained control; after all,=20 > someone may well=20 > > be prepared to reveal the type of place they are in, but=20 > not the actual=20 > > location. >=20 > Fair enough, thought I don't think I would call this "syntactic". >=20 > >=20 > > (2) semantically, where we label each piece of information=20 > as being part=20 > > of one or more broader classes, such as "where am I" and "what am I=20 > > doing" or "what device capabilities do I have" or, as another axis,=20 > > "present" and "future". > >=20 > > Beyond the obvious location identification, it might be=20 > useful to go=20 > > through the set of PIDF and RPID (and related document)=20 > items to see if=20 > > they are amenable to such a grouping. If each group has one=20 > element,=20 > > this approach isn't too helpful. >=20 > I thought about this a bunch. >=20 > The conclusion I came to is that, in many cases, the types of=20 > authorization policies that users will want are those which block the=20 > ability of a watcher to deduce a specific fact. For example,=20 > if I take=20 > a day off, and don't want my boss or colleauges to know it, I will=20 > want my presence to be structured so that no one can figure=20 > out that I=20 > am not working. This would mean, for example, that if I am sleeping,=20 > this activity value should not be shown to watchers. >=20 > My geolocation concerns were similar. I think what users may want is=20 > the ability to say "I don't want people to know where I am". Many=20 > possible presence elements can reveal this - including ones like=20 > activity and privacy, which reveal indirect clues about location. >=20 > Unfortunately, I don't think its practical to have authorization=20 > mechanisms which require the server to figure out what rpid elements=20 > are needed to deduce a specific fact. >=20 > As such, the best we can do is avoid dependencies on encoding details=20 > (such as whether placetype is put in a status or future-status=20 > element). I would suggest that the best way to do this is to allow=20 > filters and authorization policies to point at rpids and pidf=20 > elements=20 > by element name, no matter where that element appears in an XML=20 > document. So, if I don't want people to know my geoloc, I would=20 > specify an auth policy that blocks "placetype". Welcomme on board :) And I think XPath is the exact tool you need for = this, especially wen you say "no matter where that element appears in an = XML document". The following XPath expression selects the element no matter = where it appears in the XML document: //*[placetype] >=20 >=20 > >=20 > > Another approach (3) is to have a scale of privacy concern=20 > or 'presence=20 > > resolution', i.e., establish some default ordering, from=20 > "OPEN/CLOSED"=20 > > at the low end to "every new item that I publish" at the=20 > high end, with=20 > > no more than half a dozen levels. Each new element would=20 > then be labeled=20 > > as falling into one of these groupings. >=20 > I agree this is a great idea. In fact, I had exactly this kind of=20 > thing in mind for the compound permissions. >=20 > >=20 > > I think both (2) and (3) have the distinct advantage that=20 > they are far=20 > > easier to explain to users than dozens of checkboxes for each=20 > > RPID/geoloc/PIDF element. (3) is roughly similar to the=20 > privacy slider=20 > > in the Internet Options menu for IE, for example. There is no=20 > > requirement that everybody agrees with an ordering, just that it is=20 > > plausible for the majority of use cases. Advanced users can click=20 > > through to the per-element include/exclude list. >=20 > I agree that we don't want users to click on checkboxes for each rpid=20 > type. I think you might have a checkbox for "don't reveal my=20 > location", and when its selected, the client generates an xcap-auth=20 > document which blocks a whole bunch of elements, each listed by name.=20 > This may require us to produce a use case document that helps folks=20 > figure out what types of facts users might want to control, and what=20 > elements are involved in computing such facts. I agree. This sound like a plan. Regards, Hisham >=20 > -Jonathan R. >=20 > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Sep 9 03:41:02 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 DAA24302 for ; Tue, 9 Sep 2003 03:41:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wd78-0001f4-1y for simple-archive@odin.ietf.org; Tue, 09 Sep 2003 03:40:38 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h897ec5Q006380 for simple-archive@odin.ietf.org; Tue, 9 Sep 2003 03:40:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wd77-0001ep-Rk for simple-web-archive@optimus.ietf.org; Tue, 09 Sep 2003 03:40:37 -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 DAA24246; Tue, 9 Sep 2003 03:40: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 19wd6Y-0001X2-FU; Tue, 09 Sep 2003 03:40:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wd5g-0001Ud-5m for simple@optimus.ietf.org; Tue, 09 Sep 2003 03:39: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 DAA24219 for ; Tue, 9 Sep 2003 03:39:01 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19wd5d-00075E-00 for simple@ietf.org; Tue, 09 Sep 2003 03:39:05 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19wd5S-00074Z-00 for simple@ietf.org; Tue, 09 Sep 2003 03:38:54 -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 h897acB08940 for ; Tue, 9 Sep 2003 10:36:41 +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, 9 Sep 2003 10:36:38 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 9 Sep 2003 10:36:38 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 9 Sep 2003 10:36:37 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:recallmessage MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Recall: [Simple] [Fwd: Re: NETCONF WG meeting minutes for IETF #57] Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017970B2@esebe019.ntc.nokia.com> Thread-Topic: [Simple] [Fwd: Re: NETCONF WG meeting minutes for IETF #57] Thread-Index: AcN2pRnBb9PF/qybT366BF5S6ah+Tw== Priority: Urgent Expiry-Date: Thu, 11 Sep 2003 10:36:35 +0300 To: , Cc: , X-OriginalArrivalTime: 09 Sep 2003 07:36:37.0670 (UTC) FILETIME=[1A232C60:01C376A5] 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, 9 Sep 2003 10:36:37 +0300 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Khartabil Hisham (NMP/Helsinki) would like to recall the message, = "[Simple] [Fwd: Re: NETCONF WG meeting minutes for IETF #57]". _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Sep 9 03:41:03 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 DAA24314 for ; Tue, 9 Sep 2003 03:41:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wd78-0001fM-MX for simple-archive@odin.ietf.org; Tue, 09 Sep 2003 03:40:38 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h897ecra006398 for simple-archive@odin.ietf.org; Tue, 9 Sep 2003 03:40:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wd78-0001f7-HW for simple-web-archive@optimus.ietf.org; Tue, 09 Sep 2003 03:40:38 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24253; Tue, 9 Sep 2003 03:40:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wd6c-0001ZY-Hb; Tue, 09 Sep 2003 03:40:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wd5g-0001Uc-5M for simple@optimus.ietf.org; Tue, 09 Sep 2003 03:39: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 DAA24218 for ; Tue, 9 Sep 2003 03:39:01 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19wd5d-00075F-00 for simple@ietf.org; Tue, 09 Sep 2003 03:39:05 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19wd5S-00074f-00 for simple@ietf.org; Tue, 09 Sep 2003 03:38:54 -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 h897bHB09740 for ; Tue, 9 Sep 2003 10:37:19 +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, 9 Sep 2003 10:37:16 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 9 Sep 2003 10:37:16 +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] [Fwd: Re: NETCONF WG meeting minutes for IETF #57] Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017970B3@esebe019.ntc.nokia.com> Thread-Topic: [Simple] [Fwd: Re: NETCONF WG meeting minutes for IETF #57] Thread-Index: AcN0/DL647QxFyCeRxSZOOq8YFgdywBpUBbA To: , Cc: , X-OriginalArrivalTime: 09 Sep 2003 07:37:16.0657 (UTC) FILETIME=[31601E10:01C376A5] 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, 9 Sep 2003 10:37:16 +0300 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Sunday, September 07, 2003 7:53 AM > To: Henning Schulzrinne > Cc: Khartabil Hisham (NMP/Helsinki); simple@ietf.org;=20 > gk@ninebynine.org > Subject: Re: [Simple] [Fwd: Re: NETCONF WG meeting minutes=20 > for IETF #57] >=20 >=20 >=20 >=20 > Henning Schulzrinne wrote: >=20 > > I agree that we seem to need to ways of identifying information: > >=20 > > (1) syntactically, for fine-grained control; after all,=20 > someone may well=20 > > be prepared to reveal the type of place they are in, but=20 > not the actual=20 > > location. >=20 > Fair enough, thought I don't think I would call this "syntactic". >=20 > >=20 > > (2) semantically, where we label each piece of information=20 > as being part=20 > > of one or more broader classes, such as "where am I" and "what am I=20 > > doing" or "what device capabilities do I have" or, as another axis,=20 > > "present" and "future". > >=20 > > Beyond the obvious location identification, it might be=20 > useful to go=20 > > through the set of PIDF and RPID (and related document)=20 > items to see if=20 > > they are amenable to such a grouping. If each group has one=20 > element,=20 > > this approach isn't too helpful. >=20 > I thought about this a bunch. >=20 > The conclusion I came to is that, in many cases, the types of=20 > authorization policies that users will want are those which block the=20 > ability of a watcher to deduce a specific fact. For example,=20 > if I take=20 > a day off, and don't want my boss or colleauges to know it, I will=20 > want my presence to be structured so that no one can figure=20 > out that I=20 > am not working. This would mean, for example, that if I am sleeping,=20 > this activity value should not be shown to watchers. >=20 > My geolocation concerns were similar. I think what users may want is=20 > the ability to say "I don't want people to know where I am". Many=20 > possible presence elements can reveal this - including ones like=20 > activity and privacy, which reveal indirect clues about location. >=20 > Unfortunately, I don't think its practical to have authorization=20 > mechanisms which require the server to figure out what rpid elements=20 > are needed to deduce a specific fact. >=20 > As such, the best we can do is avoid dependencies on encoding details=20 > (such as whether placetype is put in a status or future-status=20 > element). I would suggest that the best way to do this is to allow=20 > filters and authorization policies to point at rpids and pidf=20 > elements=20 > by element name, no matter where that element appears in an XML=20 > document. So, if I don't want people to know my geoloc, I would=20 > specify an auth policy that blocks "placetype". Welcomme on board :) And I think XPath is the exact tool you need for = this, especially wen you say "no matter where that element appears in an = XML document". The following XPath expression selects the element no matter = where it appears in the XML document: //*[placetype] >=20 >=20 > >=20 > > Another approach (3) is to have a scale of privacy concern=20 > or 'presence=20 > > resolution', i.e., establish some default ordering, from=20 > "OPEN/CLOSED"=20 > > at the low end to "every new item that I publish" at the=20 > high end, with=20 > > no more than half a dozen levels. Each new element would=20 > then be labeled=20 > > as falling into one of these groupings. >=20 > I agree this is a great idea. In fact, I had exactly this kind of=20 > thing in mind for the compound permissions. >=20 > >=20 > > I think both (2) and (3) have the distinct advantage that=20 > they are far=20 > > easier to explain to users than dozens of checkboxes for each=20 > > RPID/geoloc/PIDF element. (3) is roughly similar to the=20 > privacy slider=20 > > in the Internet Options menu for IE, for example. There is no=20 > > requirement that everybody agrees with an ordering, just that it is=20 > > plausible for the majority of use cases. Advanced users can click=20 > > through to the per-element include/exclude list. >=20 > I agree that we don't want users to click on checkboxes for each rpid=20 > type. I think you might have a checkbox for "don't reveal my=20 > location", and when its selected, the client generates an xcap-auth=20 > document which blocks a whole bunch of elements, each listed by name.=20 > This may require us to produce a use case document that helps folks=20 > figure out what types of facts users might want to control, and what=20 > elements are involved in computing such facts. I agree. This sound like a plan. Regards, Hisham >=20 > -Jonathan R. >=20 > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Sep 9 03:44: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 DAA24433; Tue, 9 Sep 2003 03:44:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wdAO-0001io-NN; Tue, 09 Sep 2003 03:44:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wd9a-0001iF-3t for simple@optimus.ietf.org; Tue, 09 Sep 2003 03:43: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 DAA24396 for ; Tue, 9 Sep 2003 03:42:58 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19wd9S-00077o-00 for simple@ietf.org; Tue, 09 Sep 2003 03:43:02 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19wd9H-000764-00 for simple@ietf.org; Tue, 09 Sep 2003 03:42:51 -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 h897g2415447 for ; Tue, 9 Sep 2003 10:42:05 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 9 Sep 2003 10:42:02 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 9 Sep 2003 10:42:01 +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] [Fwd: Re: NETCONF WG meeting minutes for IETF #57] Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017970B4@esebe019.ntc.nokia.com> Thread-Topic: [Simple] [Fwd: Re: NETCONF WG meeting minutes for IETF #57] Thread-Index: AcN1ZgZqYU7HVCMUQ9WTe/Mdy33qQgBP0YRA To: , Cc: , X-OriginalArrivalTime: 09 Sep 2003 07:42:01.0266 (UTC) FILETIME=[DB040120:01C376A5] 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, 9 Sep 2003 10:42:00 +0300 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Sunday, September 07, 2003 5:03 PM > To: Jonathan Rosenberg > Cc: simple@ietf.org; gk@ninebynine.org > Subject: Re: [Simple] [Fwd: Re: NETCONF WG meeting minutes=20 > for IETF #57] >=20 >=20 > Jonathan Rosenberg wrote: >=20 >=20 > > Fair enough, thought I don't think I would call this "syntactic". >=20 > Document-oriented? Presumably it would use >=20 > > My geolocation concerns were similar. I think what users=20 > may want is the=20 > > ability to say "I don't want people to know where I am".=20 > Many possible=20 > > presence elements can reveal this - including ones like=20 > activity and=20 > > privacy, which reveal indirect clues about location. >=20 > I don't think this is necessarily binary. For example, I might be ok=20 > with letting others know what timezone I'm in, although this may hint=20 > that I'm traveling or on vacation. >=20 > >=20 > > Unfortunately, I don't think its practical to have authorization=20 > > mechanisms which require the server to figure out what rpid=20 > elements are=20 > > needed to deduce a specific fact. >=20 > Particularly if this is meant to be more than a binary yes/no=20 > decision.=20 > Different elements reveal different amounts of information=20 > depending on=20 > context, depending on what the watcher knows about me, etc. (For=20 > example, if the watcher knows that my employer has a branch office in=20 > Tokyo, even something as vague as timezone=3DJapan will provide a good = > hint as to what I'm doing right now.) >=20 > >=20 > > As such, the best we can do is avoid dependencies on=20 > encoding details=20 > > (such as whether placetype is put in a status or=20 > future-status element).=20 > > I would suggest that the best way to do this is to allow=20 > filters and=20 > > authorization policies to point at rpids and pidf elements=20 > by element=20 > > name, no matter where that element appears in an XML=20 > document. So, if I=20 > > don't want people to know my geoloc, I would specify an=20 > auth policy that=20 > > blocks "placetype". >=20 > Agreed. As a side-effect, this essentially makes the namespace flat,=20 > i.e., we can't have two PIDF-and-related namespaces use the same term=20 > for something different. I don't think this is a significant=20 > restriction=20 > in practice. One possibility to formalize this is to indeed have a=20 > single IANA registry for presence attributes. Each entry=20 > would point to=20 > one or more namespace/element-name combinations. Well, with XPath, you don't even need that. Let me expand the example I = gave in an earlier email: //*[rpid:placetype] I believe you can include the namespace in you element selection. Note that I'm not advocating the need to implement the whole XPATH = technology, just a subset of it. /Hisham >=20 >=20 >=20 > > I agree this is a great idea. In fact, I had exactly this=20 > kind of thing=20 > > in mind for the compound permissions. >=20 > The proof of feasibility will be whether we can arrive at=20 > such a list,=20 > across PIDF, RPID + related, and the emerging GEOPRIV items. I would=20 > suggest that these levels should be motivated by the likely use and=20 > audience. For example, for two mid-levels: >=20 > (1) "Can I visit this person": this would be useful for intra-company=20 > coordination >=20 > Would need information about my campus-level whereabouts. >=20 > (2) "Is this person amenable to business (or private) communication?" >=20 > This would include timezone, possibly country and=20 > open/closed. Possibly=20 > a 'private/business' coarse-grain activity (rather than a placetype). >=20 > Are there others? >=20 > > I agree that we don't want users to click on checkboxes for=20 > each rpid=20 > > type. I think you might have a checkbox for "don't reveal=20 > my location",=20 > > and when its selected, the client generates an xcap-auth=20 > document which=20 > > blocks a whole bunch of elements, each listed by name. This=20 > may require=20 > > us to produce a use case document that helps folks figure=20 > out what types=20 > > of facts users might want to control, and what elements are=20 > involved in=20 > > computing such facts. >=20 > There was a long discussion on this topic at the GEOPRIV=20 > interim meeting=20 > that took place Friday and Saturday. Two approaches were identified: >=20 > (1) a tool presents a high-level interface to the user, but the=20 > on-the-wire ruleset (XCAP-AUTH, etc.) identifies lower-level elements=20 > (either at the document-oriented level or, probably better,=20 > by content=20 > type). >=20 > (2) the authorization policy itself contains a high-level description=20 > that then is translated by the policy enforcement entity into=20 > filtering=20 > actions. >=20 > (2) has fewer things to test and thus may reach=20 > interoperability sooner,=20 > but requires that the policy enforcement point be upgraded=20 > each time a=20 > new element is added. >=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 Sep 9 03:44:57 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 DAA24454 for ; Tue, 9 Sep 2003 03:44:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wdAv-0001mr-09 for simple-archive@odin.ietf.org; Tue, 09 Sep 2003 03:44:33 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h897iWv4006863 for simple-archive@odin.ietf.org; Tue, 9 Sep 2003 03:44:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wdAu-0001mc-OP for simple-web-archive@optimus.ietf.org; Tue, 09 Sep 2003 03:44:32 -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 DAA24433; Tue, 9 Sep 2003 03:44:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wdAO-0001io-NN; Tue, 09 Sep 2003 03:44:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wd9a-0001iF-3t for simple@optimus.ietf.org; Tue, 09 Sep 2003 03:43: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 DAA24396 for ; Tue, 9 Sep 2003 03:42:58 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19wd9S-00077o-00 for simple@ietf.org; Tue, 09 Sep 2003 03:43:02 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19wd9H-000764-00 for simple@ietf.org; Tue, 09 Sep 2003 03:42:51 -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 h897g2415447 for ; Tue, 9 Sep 2003 10:42:05 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 9 Sep 2003 10:42:02 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 9 Sep 2003 10:42:01 +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] [Fwd: Re: NETCONF WG meeting minutes for IETF #57] Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017970B4@esebe019.ntc.nokia.com> Thread-Topic: [Simple] [Fwd: Re: NETCONF WG meeting minutes for IETF #57] Thread-Index: AcN1ZgZqYU7HVCMUQ9WTe/Mdy33qQgBP0YRA To: , Cc: , X-OriginalArrivalTime: 09 Sep 2003 07:42:01.0266 (UTC) FILETIME=[DB040120:01C376A5] 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, 9 Sep 2003 10:42:00 +0300 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Sunday, September 07, 2003 5:03 PM > To: Jonathan Rosenberg > Cc: simple@ietf.org; gk@ninebynine.org > Subject: Re: [Simple] [Fwd: Re: NETCONF WG meeting minutes=20 > for IETF #57] >=20 >=20 > Jonathan Rosenberg wrote: >=20 >=20 > > Fair enough, thought I don't think I would call this "syntactic". >=20 > Document-oriented? Presumably it would use >=20 > > My geolocation concerns were similar. I think what users=20 > may want is the=20 > > ability to say "I don't want people to know where I am".=20 > Many possible=20 > > presence elements can reveal this - including ones like=20 > activity and=20 > > privacy, which reveal indirect clues about location. >=20 > I don't think this is necessarily binary. For example, I might be ok=20 > with letting others know what timezone I'm in, although this may hint=20 > that I'm traveling or on vacation. >=20 > >=20 > > Unfortunately, I don't think its practical to have authorization=20 > > mechanisms which require the server to figure out what rpid=20 > elements are=20 > > needed to deduce a specific fact. >=20 > Particularly if this is meant to be more than a binary yes/no=20 > decision.=20 > Different elements reveal different amounts of information=20 > depending on=20 > context, depending on what the watcher knows about me, etc. (For=20 > example, if the watcher knows that my employer has a branch office in=20 > Tokyo, even something as vague as timezone=3DJapan will provide a good = > hint as to what I'm doing right now.) >=20 > >=20 > > As such, the best we can do is avoid dependencies on=20 > encoding details=20 > > (such as whether placetype is put in a status or=20 > future-status element).=20 > > I would suggest that the best way to do this is to allow=20 > filters and=20 > > authorization policies to point at rpids and pidf elements=20 > by element=20 > > name, no matter where that element appears in an XML=20 > document. So, if I=20 > > don't want people to know my geoloc, I would specify an=20 > auth policy that=20 > > blocks "placetype". >=20 > Agreed. As a side-effect, this essentially makes the namespace flat,=20 > i.e., we can't have two PIDF-and-related namespaces use the same term=20 > for something different. I don't think this is a significant=20 > restriction=20 > in practice. One possibility to formalize this is to indeed have a=20 > single IANA registry for presence attributes. Each entry=20 > would point to=20 > one or more namespace/element-name combinations. Well, with XPath, you don't even need that. Let me expand the example I = gave in an earlier email: //*[rpid:placetype] I believe you can include the namespace in you element selection. Note that I'm not advocating the need to implement the whole XPATH = technology, just a subset of it. /Hisham >=20 >=20 >=20 > > I agree this is a great idea. In fact, I had exactly this=20 > kind of thing=20 > > in mind for the compound permissions. >=20 > The proof of feasibility will be whether we can arrive at=20 > such a list,=20 > across PIDF, RPID + related, and the emerging GEOPRIV items. I would=20 > suggest that these levels should be motivated by the likely use and=20 > audience. For example, for two mid-levels: >=20 > (1) "Can I visit this person": this would be useful for intra-company=20 > coordination >=20 > Would need information about my campus-level whereabouts. >=20 > (2) "Is this person amenable to business (or private) communication?" >=20 > This would include timezone, possibly country and=20 > open/closed. Possibly=20 > a 'private/business' coarse-grain activity (rather than a placetype). >=20 > Are there others? >=20 > > I agree that we don't want users to click on checkboxes for=20 > each rpid=20 > > type. I think you might have a checkbox for "don't reveal=20 > my location",=20 > > and when its selected, the client generates an xcap-auth=20 > document which=20 > > blocks a whole bunch of elements, each listed by name. This=20 > may require=20 > > us to produce a use case document that helps folks figure=20 > out what types=20 > > of facts users might want to control, and what elements are=20 > involved in=20 > > computing such facts. >=20 > There was a long discussion on this topic at the GEOPRIV=20 > interim meeting=20 > that took place Friday and Saturday. Two approaches were identified: >=20 > (1) a tool presents a high-level interface to the user, but the=20 > on-the-wire ruleset (XCAP-AUTH, etc.) identifies lower-level elements=20 > (either at the document-oriented level or, probably better,=20 > by content=20 > type). >=20 > (2) the authorization policy itself contains a high-level description=20 > that then is translated by the policy enforcement entity into=20 > filtering=20 > actions. >=20 > (2) has fewer things to test and thus may reach=20 > interoperability sooner,=20 > but requires that the policy enforcement point be upgraded=20 > each time a=20 > new element is added. >=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 Sep 9 07:06: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 HAA00578; Tue, 9 Sep 2003 07:06: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 19wgJs-0000Lm-21; Tue, 09 Sep 2003 07:06:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wgJq-0000LV-Bc for simple@optimus.ietf.org; Tue, 09 Sep 2003 07:05: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 HAA00549 for ; Tue, 9 Sep 2003 07:05:43 -0400 (EDT) From: Markus.Isomaki@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19wgJg-00018m-00 for simple@ietf.org; Tue, 09 Sep 2003 07:05:48 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19wgJV-00017a-00 for simple@ietf.org; Tue, 09 Sep 2003 07:05:38 -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 h89AHdB15317 for ; Tue, 9 Sep 2003 13:17:49 +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, 9 Sep 2003 13:17:39 +0300 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 9 Sep 2003 13:17: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" Content-Transfer-Encoding: quoted-printable Message-ID: Thread-Topic: [Simple] [Fwd: Re: NETCONF WG meeting minutes for IETF #57] Thread-Index: AcN1ZgZqYU7HVCMUQ9WTe/Mdy33qQgBP0YRAAAOIBxA= To: , , Cc: X-OriginalArrivalTime: 09 Sep 2003 10:17:38.0478 (UTC) FILETIME=[986D7CE0:01C376BB] Content-Transfer-Encoding: quoted-printable Subject: [Simple] Presence authorization conclusion? Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.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, 9 Sep 2003 13:17:37 +0300 Content-Transfer-Encoding: quoted-printable Hi, I try to summarize the discussion on presence authorization (mainly = participated by Jonathan Rosenberg and Henning Schulzrinne) in order to = see if we have reached any conclusions. There seem to be three different paradigms for doing the authorization. = To my understanding they are actually more complementary than competing. = Here's a list: 1.) Pointing to presence document elements by element name. This would = allow the policy to basically select any elements (and XML subtrees) = without the server needing to know the semantics of the element, and the = client needing to know a priori where the element may appear in the = document. Jonathan Rosenberg wrote: > I would suggest that the best way to do this is to allow=20 > filters and authorization policies to point at rpids and pidf=20 > elements by element name, no matter where that element appears in=20 > an XML document. I think this alone would satisfy most if not all of the requirements = that are included in the "data manipulation requirements" draft. There has been further discussion whether (a subset of) XPath would be a = good solution for this. It seems that it can express the needed = statements. However, making a separate definition just for this need = would at least make the rules more human-readable than the raw XPath = expressions. 2.) Establishing some grouping of presence document elements.=20 Henning Schulzrinne wrote: > Another approach [...] is to have a scale of privacy concern or=20 > 'presence resolution', i.e., establish some default ordering, from=20 > "OPEN/CLOSED" at the low end to "every new item that I publish" at=20 > the high end, with no more than half a dozen levels. Each new element=20 > would then be labeled as falling into one of these groupings. It seems that this is similar to what can be done with the "compound = rules" in the current presence authorization XCAP proposal.=20 3.) Defining a new "sphere" element to act as a switch defining which = authorization rules apply, e.g. it would be easy to have distinct rules = for "work" and "home". Henning Schulzrinne wrote: > Thus, my proposal: RPID adds a element that has a=20 > few standard labels, such as 'home' and 'work', with other labels that = can=20 > be added. The primary purpose of this information is not so much in=20 > the NOTIFY, but in the PUBLISH phase. The idea is that I can publish = my=20 > 'sphere' and this will automatically switch between different modes of = > visibility, different sets of rules. This seems to be a rather sensible approach when thinking how presence = authorization could be used daily. Having just one element for this = would probably be sufficient for usability point of view. Proposal: My proposal is basically adapt all these three approaches to the = standardized XCAP solution: - Define a way how to point to elements in = presence doc., be this XPath or a just-for-the-purpose definition. The = same one should be used in presence filtering too. - Have the possibility to do compound rules to allow flexible grouping = of elements. - Define a element for RPID to act as a switch between = different sets of rules. =20 Please comment. Regards, Markus _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Sep 9 07:07:01 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00603 for ; Tue, 9 Sep 2003 07:07:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wgKV-0000Q9-Jv for simple-archive@odin.ietf.org; Tue, 09 Sep 2003 07:06:40 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h89B6dVx001611 for simple-archive@odin.ietf.org; Tue, 9 Sep 2003 07:06:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wgKV-0000Pu-Gh for simple-web-archive@optimus.ietf.org; Tue, 09 Sep 2003 07:06: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 HAA00578; Tue, 9 Sep 2003 07:06: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 19wgJs-0000Lm-21; Tue, 09 Sep 2003 07:06:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wgJq-0000LV-Bc for simple@optimus.ietf.org; Tue, 09 Sep 2003 07:05: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 HAA00549 for ; Tue, 9 Sep 2003 07:05:43 -0400 (EDT) From: Markus.Isomaki@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19wgJg-00018m-00 for simple@ietf.org; Tue, 09 Sep 2003 07:05:48 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19wgJV-00017a-00 for simple@ietf.org; Tue, 09 Sep 2003 07:05:38 -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 h89AHdB15317 for ; Tue, 9 Sep 2003 13:17:49 +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, 9 Sep 2003 13:17:39 +0300 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 9 Sep 2003 13:17: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" Content-Transfer-Encoding: quoted-printable Message-ID: Thread-Topic: [Simple] [Fwd: Re: NETCONF WG meeting minutes for IETF #57] Thread-Index: AcN1ZgZqYU7HVCMUQ9WTe/Mdy33qQgBP0YRAAAOIBxA= To: , , Cc: X-OriginalArrivalTime: 09 Sep 2003 10:17:38.0478 (UTC) FILETIME=[986D7CE0:01C376BB] Content-Transfer-Encoding: quoted-printable Subject: [Simple] Presence authorization conclusion? Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.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, 9 Sep 2003 13:17:37 +0300 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi, I try to summarize the discussion on presence authorization (mainly = participated by Jonathan Rosenberg and Henning Schulzrinne) in order to = see if we have reached any conclusions. There seem to be three different paradigms for doing the authorization. = To my understanding they are actually more complementary than competing. = Here's a list: 1.) Pointing to presence document elements by element name. This would = allow the policy to basically select any elements (and XML subtrees) = without the server needing to know the semantics of the element, and the = client needing to know a priori where the element may appear in the = document. Jonathan Rosenberg wrote: > I would suggest that the best way to do this is to allow=20 > filters and authorization policies to point at rpids and pidf=20 > elements by element name, no matter where that element appears in=20 > an XML document. I think this alone would satisfy most if not all of the requirements = that are included in the "data manipulation requirements" draft. There has been further discussion whether (a subset of) XPath would be a = good solution for this. It seems that it can express the needed = statements. However, making a separate definition just for this need = would at least make the rules more human-readable than the raw XPath = expressions. 2.) Establishing some grouping of presence document elements.=20 Henning Schulzrinne wrote: > Another approach [...] is to have a scale of privacy concern or=20 > 'presence resolution', i.e., establish some default ordering, from=20 > "OPEN/CLOSED" at the low end to "every new item that I publish" at=20 > the high end, with no more than half a dozen levels. Each new element=20 > would then be labeled as falling into one of these groupings. It seems that this is similar to what can be done with the "compound = rules" in the current presence authorization XCAP proposal.=20 3.) Defining a new "sphere" element to act as a switch defining which = authorization rules apply, e.g. it would be easy to have distinct rules = for "work" and "home". Henning Schulzrinne wrote: > Thus, my proposal: RPID adds a element that has a=20 > few standard labels, such as 'home' and 'work', with other labels that = can=20 > be added. The primary purpose of this information is not so much in=20 > the NOTIFY, but in the PUBLISH phase. The idea is that I can publish = my=20 > 'sphere' and this will automatically switch between different modes of = > visibility, different sets of rules. This seems to be a rather sensible approach when thinking how presence = authorization could be used daily. Having just one element for this = would probably be sufficient for usability point of view. Proposal: My proposal is basically adapt all these three approaches to the = standardized XCAP solution: - Define a way how to point to elements in = presence doc., be this XPath or a just-for-the-purpose definition. The = same one should be used in presence filtering too. - Have the possibility to do compound rules to allow flexible grouping = of elements. - Define a element for RPID to act as a switch between = different sets of rules. =20 Please comment. Regards, Markus _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Sep 9 07:46: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 HAA01883; Tue, 9 Sep 2003 07:46: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 19wgwb-0001eN-7h; Tue, 09 Sep 2003 07:46:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wgw6-0001dR-LS for simple@optimus.ietf.org; Tue, 09 Sep 2003 07:45: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 HAA01807; Tue, 9 Sep 2003 07:45:19 -0400 (EDT) From: aki.niemi@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19wgw0-0001Wb-00; Tue, 09 Sep 2003 07:45:24 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19wgvp-0001RS-00; Tue, 09 Sep 2003 07:45:13 -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 h89BfT401034; Tue, 9 Sep 2003 14:41:32 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 9 Sep 2003 14:41:29 +0300 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 9 Sep 2003 14:41: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" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Re: [Geopriv] Individuals, hats and spheres Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9027D8F7B@esebe013.ntc.nokia.com> Thread-Topic: [Simple] Re: [Geopriv] Individuals, hats and spheres Thread-Index: AcN2hewXMFZEsZeoRcCmnsukh7o+kAAGht5wAAm5JbA= To: , , Cc: , X-OriginalArrivalTime: 09 Sep 2003 11:41:28.0126 (UTC) FILETIME=[4E54DDE0:01C376C7] 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, 9 Sep 2003 14:41:27 +0300 Content-Transfer-Encoding: quoted-printable Quick answer below. > -----Original Message----- > From: ext hisham.khartabil@nokia.com=20 > [mailto:hisham.khartabil@nokia.com] > Sent: 09 September, 2003 10:06 > To: hgs@cs.columbia.edu; Trossen Dirk (NRC/Boston) > Cc: geopriv@ietf.org; simple@ietf.org > Subject: RE: [Simple] Re: [Geopriv] Individuals, hats and spheres >=20 [snip] >=20 > Dimension, perhaps. >=20 > Just a few questions: >=20 > - Why is a sphere different than a group? >=20 > - Why this type of analogy is limited to geoloc?=20 >=20 > - How this is different from the stream-header we had in PUBLISH? I think you mean the Facet header, with which the problem is that we're = not limited to publishing presence only. Spheres make sense for presence = but have little meaning when publishing, say, MWI state information. Cheers, Aki >=20 > /Hisham >=20 > >=20 > >=20 > > >=20 > > > Dirk > >=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 Sep 9 07:47:02 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 HAA01913 for ; Tue, 9 Sep 2003 07:47:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wgxA-0001ip-C5 for simple-archive@odin.ietf.org; Tue, 09 Sep 2003 07:46:36 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h89BkagX006613 for simple-archive@odin.ietf.org; Tue, 9 Sep 2003 07:46:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wgxA-0001ia-8l for simple-web-archive@optimus.ietf.org; Tue, 09 Sep 2003 07:46: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 HAA01883; Tue, 9 Sep 2003 07:46: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 19wgwb-0001eN-7h; Tue, 09 Sep 2003 07:46:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wgw6-0001dR-LS for simple@optimus.ietf.org; Tue, 09 Sep 2003 07:45: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 HAA01807; Tue, 9 Sep 2003 07:45:19 -0400 (EDT) From: aki.niemi@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19wgw0-0001Wb-00; Tue, 09 Sep 2003 07:45:24 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19wgvp-0001RS-00; Tue, 09 Sep 2003 07:45:13 -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 h89BfT401034; Tue, 9 Sep 2003 14:41:32 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 9 Sep 2003 14:41:29 +0300 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 9 Sep 2003 14:41: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" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Re: [Geopriv] Individuals, hats and spheres Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9027D8F7B@esebe013.ntc.nokia.com> Thread-Topic: [Simple] Re: [Geopriv] Individuals, hats and spheres Thread-Index: AcN2hewXMFZEsZeoRcCmnsukh7o+kAAGht5wAAm5JbA= To: , , Cc: , X-OriginalArrivalTime: 09 Sep 2003 11:41:28.0126 (UTC) FILETIME=[4E54DDE0:01C376C7] 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, 9 Sep 2003 14:41:27 +0300 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Quick answer below. > -----Original Message----- > From: ext hisham.khartabil@nokia.com=20 > [mailto:hisham.khartabil@nokia.com] > Sent: 09 September, 2003 10:06 > To: hgs@cs.columbia.edu; Trossen Dirk (NRC/Boston) > Cc: geopriv@ietf.org; simple@ietf.org > Subject: RE: [Simple] Re: [Geopriv] Individuals, hats and spheres >=20 [snip] >=20 > Dimension, perhaps. >=20 > Just a few questions: >=20 > - Why is a sphere different than a group? >=20 > - Why this type of analogy is limited to geoloc?=20 >=20 > - How this is different from the stream-header we had in PUBLISH? I think you mean the Facet header, with which the problem is that we're = not limited to publishing presence only. Spheres make sense for presence = but have little meaning when publishing, say, MWI state information. Cheers, Aki >=20 > /Hisham >=20 > >=20 > >=20 > > >=20 > > > Dirk > >=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 Sep 9 09:19: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 JAA05280; Tue, 9 Sep 2003 09:19:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19wiOi-0002Ye-00; Tue, 09 Sep 2003 09:19:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19wiOc-0002Yb-00; Tue, 09 Sep 2003 09:19:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wiOb-00053B-3T; Tue, 09 Sep 2003 09:19:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wiOH-00051C-Io for simple@optimus.ietf.org; Tue, 09 Sep 2003 09:18: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 JAA05248; Tue, 9 Sep 2003 09:18:29 -0400 (EDT) From: Dirk.Trossen@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19wiNF-0002Xe-00; Tue, 09 Sep 2003 09:17:37 -0400 Received: from [63.78.179.216] (helo=mgw-dax1.ext.nokia.com) by ietf-mx with esmtp (Exim 4.12) id 19wiN4-0002Wc-00; Tue, 09 Sep 2003 09:17:26 -0400 Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h89DFD108814; Tue, 9 Sep 2003 08:15:13 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 9 Sep 2003 08:15:13 -0500 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 9 Sep 2003 06:14:59 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: Thread-Topic: [Geopriv] Individuals, hats and spheres Thread-Index: AcN2heBk6Dxx8Q8QQcydb25baAR4WAAThzRw To: Cc: , X-OriginalArrivalTime: 09 Sep 2003 13:14:59.0170 (UTC) FILETIME=[5EC63C20:01C376D4] Content-Transfer-Encoding: quoted-printable Subject: [Simple] RE: [Geopriv] Individuals, hats and spheres Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.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, 9 Sep 2003 09:14:57 -0400 Content-Transfer-Encoding: quoted-printable >> I like the idea of enabling a certain set of rules (as=20 >opposed to have conditional single >> rules, the condition being e.g., the identity of the=20 >watcher) based on a certain condition.=20 >> However, I was wondering whether this is intended to be=20 >bound to the element?=20 >> Let me try to describe the underlying, general method that I=20 >understood from your proposal: >> Allow for enabling a defined set of rules based on a=20 >certain condition, in which the >> condition would be a certain value/range of an RPID element.=20 > >That is indeed the general problem. However, here, my objective is far=20 >narrower. I'm trying to capture one aspect of the=20 >condition/context/state of the presentity, namely its role-based=20 >interaction with other humans. There are many other variables, such as=20 >time, space, other physical measurements ("it's hot, so don't bother=20 >me") - all of which may be combined to select a certain set of=20 >permissions. Indeed, the core ruleset discussed in GEOPRIV=20 >contains some=20 >of these conditions (time, space). > >I just happen to believe that for access to information about human=20 >activities, our relationship to humans and how we divide our=20 >life is one=20 >of the more important items. Agree. > >>=20 >> Hence, with this understanding of your proposal in mind,=20 >would it be possible/desirable to >> use other RPID elements? In this, I could define a set of=20 >rules that is enabled when=20 >> is "work" or is "meeting".=20 > >That is certainly possible and useful, in my view. I wanted to start=20 >small, with a broad brush. It might again be helpful to enumerate some=20 >plausible examples of privacy policies that real people are likely to=20 >use. I found that in many cases, the or =20 >is really=20 >just a stand-in for "a part of my world that has distinct assumptions,=20 >expectations, obligations and conventions". I'm not a sociologist, so=20 >maybe there's a better term for this than sphere. I do see as a starting point for such division of rule sets. = The actual mechanism though should not be limited to this one entry. It is then up = to further studies what other elements would make sense to be used for such rule = division. These elements could be existing ones or even ones to be defined in the = future.=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Sep 9 09:19:42 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 JAA05343 for ; Tue, 9 Sep 2003 09:19:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wiOq-000568-5h for simple-archive@odin.ietf.org; Tue, 09 Sep 2003 09:19:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h89DJGCL019590 for simple-archive@odin.ietf.org; Tue, 9 Sep 2003 09:19:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wiOq-00055t-1a for simple-web-archive@optimus.ietf.org; Tue, 09 Sep 2003 09: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 JAA05280; Tue, 9 Sep 2003 09:19:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19wiOi-0002Ye-00; Tue, 09 Sep 2003 09:19:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19wiOc-0002Yb-00; Tue, 09 Sep 2003 09:19:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wiOb-00053B-3T; Tue, 09 Sep 2003 09:19:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wiOH-00051C-Io for simple@optimus.ietf.org; Tue, 09 Sep 2003 09:18: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 JAA05248; Tue, 9 Sep 2003 09:18:29 -0400 (EDT) From: Dirk.Trossen@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19wiNF-0002Xe-00; Tue, 09 Sep 2003 09:17:37 -0400 Received: from [63.78.179.216] (helo=mgw-dax1.ext.nokia.com) by ietf-mx with esmtp (Exim 4.12) id 19wiN4-0002Wc-00; Tue, 09 Sep 2003 09:17:26 -0400 Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h89DFD108814; Tue, 9 Sep 2003 08:15:13 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 9 Sep 2003 08:15:13 -0500 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 9 Sep 2003 06:14:59 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: Thread-Topic: [Geopriv] Individuals, hats and spheres Thread-Index: AcN2heBk6Dxx8Q8QQcydb25baAR4WAAThzRw To: Cc: , X-OriginalArrivalTime: 09 Sep 2003 13:14:59.0170 (UTC) FILETIME=[5EC63C20:01C376D4] Content-Transfer-Encoding: quoted-printable Subject: [Simple] RE: [Geopriv] Individuals, hats and spheres Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.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, 9 Sep 2003 09:14:57 -0400 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable >> I like the idea of enabling a certain set of rules (as=20 >opposed to have conditional single >> rules, the condition being e.g., the identity of the=20 >watcher) based on a certain condition.=20 >> However, I was wondering whether this is intended to be=20 >bound to the element?=20 >> Let me try to describe the underlying, general method that I=20 >understood from your proposal: >> Allow for enabling a defined set of rules based on a=20 >certain condition, in which the >> condition would be a certain value/range of an RPID element.=20 > >That is indeed the general problem. However, here, my objective is far=20 >narrower. I'm trying to capture one aspect of the=20 >condition/context/state of the presentity, namely its role-based=20 >interaction with other humans. There are many other variables, such as=20 >time, space, other physical measurements ("it's hot, so don't bother=20 >me") - all of which may be combined to select a certain set of=20 >permissions. Indeed, the core ruleset discussed in GEOPRIV=20 >contains some=20 >of these conditions (time, space). > >I just happen to believe that for access to information about human=20 >activities, our relationship to humans and how we divide our=20 >life is one=20 >of the more important items. Agree. > >>=20 >> Hence, with this understanding of your proposal in mind,=20 >would it be possible/desirable to >> use other RPID elements? In this, I could define a set of=20 >rules that is enabled when=20 >> is "work" or is "meeting".=20 > >That is certainly possible and useful, in my view. I wanted to start=20 >small, with a broad brush. It might again be helpful to enumerate some=20 >plausible examples of privacy policies that real people are likely to=20 >use. I found that in many cases, the or =20 >is really=20 >just a stand-in for "a part of my world that has distinct assumptions,=20 >expectations, obligations and conventions". I'm not a sociologist, so=20 >maybe there's a better term for this than sphere. I do see as a starting point for such division of rule sets. = The actual mechanism though should not be limited to this one entry. It is then up = to further studies what other elements would make sense to be used for such rule = division. These elements could be existing ones or even ones to be defined in the = future.=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Sep 9 10:27:58 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12897; Tue, 9 Sep 2003 10:27:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19wjTQ-0004FV-00; Tue, 09 Sep 2003 10:28:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19wjTP-0004FS-00; Tue, 09 Sep 2003 10:28:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wjTN-0000XV-LD; Tue, 09 Sep 2003 10:28:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wjTG-0000Wg-C6 for simple@optimus.ietf.org; Tue, 09 Sep 2003 10:27:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12876 for ; Tue, 9 Sep 2003 10:27:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19wjTE-0004F0-00 for simple@ietf.org; Tue, 09 Sep 2003 10:27:52 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 19wjTD-0004Ex-00 for simple@ietf.org; Tue, 09 Sep 2003 10:27:51 -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 h89EReoH000441; Tue, 9 Sep 2003 10:27:40 -0400 (EDT) Received: from cs.columbia.edu (path.cs.columbia.edu [128.59.19.143]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h89EReG00632; Tue, 9 Sep 2003 10:27:40 -0400 Message-ID: <3F5DE35C.2020803@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Markus.Isomaki@nokia.com CC: hisham.khartabil@nokia.com, jdrosen@dynamicsoft.com, simple@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Re: Presence authorization conclusion? Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.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, 09 Sep 2003 10:27:40 -0400 Content-Transfer-Encoding: 7bit Markus.Isomaki@nokia.com wrote: > There has been further discussion whether (a subset of) XPath would > be a good solution for this. It seems that it can express the needed > statements. However, making a separate definition just for this need > would at least make the rules more human-readable than the raw XPath > expressions. However, somebody soon has to step forward with such a proposal. So far, I've seen variations on (1) any element named namespace:element, regardless of its position in the document tree (2) specific element identified by parents, with namespace, but without dealing with things like "3rd instance of element X" (so far, none of the presence documents seem to allow repeats of the same element at the same level of the tree) or "element having value Y" or "element with attribute Z". If these are the only cases needed, something as simple as (1) *placetype (2) tuple/status/placetype would do. It is unclear to me how to refer to namespaces since urn:ietf:params:xml:ns:pidf:tuple/ urn:ietf:params:xml:ns:pidf:status/ urn:ietf:params:xml:ns:pidf:rpid-tuple:placetype doesn't cut it. > It seems that this is similar to what can be done with the "compound > rules" in the current presence authorization XCAP proposal. My concern about the compound rules is that they make implementation rather hard. In particular, they make a database row selection implementation impossible. I see the compound rules approach as the dynamic, user-created version of what I had in mind, namely something static, pre-defined that cannot be changed by a ruleset. > > 3.) Defining a new "sphere" element to act as a switch defining which > authorization rules apply, e.g. it would be easy to have distinct > rules for "work" and "home". > Proposal: My proposal is basically adapt all these three approaches > to the standardized XCAP solution: - Define a way how to point to > elements in presence doc., be this XPath or a just-for-the-purpose > definition. The same one should be used in presence filtering too. - > Have the possibility to do compound rules to allow flexible grouping > of elements. - Define a element for RPID to act as a switch > between different sets of rules. > > Please comment. > > Regards, Markus _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Sep 9 10:28: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 KAA12947 for ; Tue, 9 Sep 2003 10:28: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 19wjTT-0000ZB-Dr for simple-archive@odin.ietf.org; Tue, 09 Sep 2003 10:28:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h89ES74B002171 for simple-archive@odin.ietf.org; Tue, 9 Sep 2003 10:28:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wjTT-0000Yw-9N for simple-web-archive@optimus.ietf.org; Tue, 09 Sep 2003 10:28:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12897; Tue, 9 Sep 2003 10:27:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19wjTQ-0004FV-00; Tue, 09 Sep 2003 10:28:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19wjTP-0004FS-00; Tue, 09 Sep 2003 10:28:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wjTN-0000XV-LD; Tue, 09 Sep 2003 10:28:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wjTG-0000Wg-C6 for simple@optimus.ietf.org; Tue, 09 Sep 2003 10:27:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12876 for ; Tue, 9 Sep 2003 10:27:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19wjTE-0004F0-00 for simple@ietf.org; Tue, 09 Sep 2003 10:27:52 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 19wjTD-0004Ex-00 for simple@ietf.org; Tue, 09 Sep 2003 10:27:51 -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 h89EReoH000441; Tue, 9 Sep 2003 10:27:40 -0400 (EDT) Received: from cs.columbia.edu (path.cs.columbia.edu [128.59.19.143]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h89EReG00632; Tue, 9 Sep 2003 10:27:40 -0400 Message-ID: <3F5DE35C.2020803@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Markus.Isomaki@nokia.com CC: hisham.khartabil@nokia.com, jdrosen@dynamicsoft.com, simple@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Re: Presence authorization conclusion? Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.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, 09 Sep 2003 10:27:40 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Markus.Isomaki@nokia.com wrote: > There has been further discussion whether (a subset of) XPath would > be a good solution for this. It seems that it can express the needed > statements. However, making a separate definition just for this need > would at least make the rules more human-readable than the raw XPath > expressions. However, somebody soon has to step forward with such a proposal. So far, I've seen variations on (1) any element named namespace:element, regardless of its position in the document tree (2) specific element identified by parents, with namespace, but without dealing with things like "3rd instance of element X" (so far, none of the presence documents seem to allow repeats of the same element at the same level of the tree) or "element having value Y" or "element with attribute Z". If these are the only cases needed, something as simple as (1) *placetype (2) tuple/status/placetype would do. It is unclear to me how to refer to namespaces since urn:ietf:params:xml:ns:pidf:tuple/ urn:ietf:params:xml:ns:pidf:status/ urn:ietf:params:xml:ns:pidf:rpid-tuple:placetype doesn't cut it. > It seems that this is similar to what can be done with the "compound > rules" in the current presence authorization XCAP proposal. My concern about the compound rules is that they make implementation rather hard. In particular, they make a database row selection implementation impossible. I see the compound rules approach as the dynamic, user-created version of what I had in mind, namely something static, pre-defined that cannot be changed by a ruleset. > > 3.) Defining a new "sphere" element to act as a switch defining which > authorization rules apply, e.g. it would be easy to have distinct > rules for "work" and "home". > Proposal: My proposal is basically adapt all these three approaches > to the standardized XCAP solution: - Define a way how to point to > elements in presence doc., be this XPath or a just-for-the-purpose > definition. The same one should be used in presence filtering too. - > Have the possibility to do compound rules to allow flexible grouping > of elements. - Define a element for RPID to act as a switch > between different sets of rules. > > Please comment. > > Regards, Markus _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Sep 9 10:40: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 KAA13725; Tue, 9 Sep 2003 10:40:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19wjfx-0004WH-00; Tue, 09 Sep 2003 10:41:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19wjfw-0004WE-00; Tue, 09 Sep 2003 10:41:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wjfw-0001NT-F7; Tue, 09 Sep 2003 10:41:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wjfD-0001Lf-68 for simple@optimus.ietf.org; Tue, 09 Sep 2003 10:40: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 KAA13673; Tue, 9 Sep 2003 10:40:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19wjfA-0004V1-00; Tue, 09 Sep 2003 10:40:12 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 19wjf9-0004Uy-00; Tue, 09 Sep 2003 10:40:11 -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 h89EeBoH023197; Tue, 9 Sep 2003 10:40:11 -0400 (EDT) Received: from cs.columbia.edu (path.cs.columbia.edu [128.59.19.143]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h89EeAG03384; Tue, 9 Sep 2003 10:40:10 -0400 Message-ID: <3F5DE64A.6020305@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: Dirk.Trossen@nokia.com, geopriv@ietf.org, simple@ietf.org Subject: Re: [Simple] Re: [Geopriv] Individuals, hats and spheres References: <2038BCC78B1AD641891A0D1AE133DBB7017970B0@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB7017970B0@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, 09 Sep 2003 10:40:10 -0400 Content-Transfer-Encoding: 7bit > Dimension, perhaps. > > Just a few questions: > > - Why is a sphere different than a group? This is not a group as it defines a matching parameter that is (or could be) used alongside other context information, such as the person, a time range and a place. In many cases, this will correspond to "allow {group of people} access to me when I'm working/at home", but the semantics is slightly different. The model is "I have declared myself to be in state/sphere X. Please apply the rules that apply to that state." In the end, all rules boil down to {set of people} can do {set of things}, but the number of such sets may be very large. > > - Why this type of analogy is limited to geoloc? It isn't. It's just that some of the discussion on privacy-related issues has taken place there and that many of those involving location tended to be of the "I'm at work" vs. "I'm off work" flavor. (Mistresses also seem to be popular in that working group :-)) I have argued before that I see no principal difference in most cases (stalkers excepted) between the privacy considerations for what I'm currently doing and where I am, particularly since they are often derivable from each other with high probability. In some cases, activity information is more sensitive (knowing that I'm in state 'sleeping' during work hours is more revealing than that I'm not moving in my office), in others it's not ("driving" vs. "vectored to the drug treatment center"). > > - How this is different from the stream-header we had in PUBLISH? I fail to see the connection. This is much closer to and and in some cases, there will be a high correlation between (,) and , but since the correlation is less than perfect, it seemed better to make the real intent explicit. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Sep 9 10:41: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 KAA13787 for ; Tue, 9 Sep 2003 10:41: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 19wjg0-0001QE-Bf for simple-archive@odin.ietf.org; Tue, 09 Sep 2003 10:41:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h89Ef4As005460 for simple-archive@odin.ietf.org; Tue, 9 Sep 2003 10:41:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wjg0-0001Pz-8D for simple-web-archive@optimus.ietf.org; Tue, 09 Sep 2003 10:41: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 KAA13725; Tue, 9 Sep 2003 10:40:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19wjfx-0004WH-00; Tue, 09 Sep 2003 10:41:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19wjfw-0004WE-00; Tue, 09 Sep 2003 10:41:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wjfw-0001NT-F7; Tue, 09 Sep 2003 10:41:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wjfD-0001Lf-68 for simple@optimus.ietf.org; Tue, 09 Sep 2003 10:40: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 KAA13673; Tue, 9 Sep 2003 10:40:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19wjfA-0004V1-00; Tue, 09 Sep 2003 10:40:12 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 19wjf9-0004Uy-00; Tue, 09 Sep 2003 10:40:11 -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 h89EeBoH023197; Tue, 9 Sep 2003 10:40:11 -0400 (EDT) Received: from cs.columbia.edu (path.cs.columbia.edu [128.59.19.143]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h89EeAG03384; Tue, 9 Sep 2003 10:40:10 -0400 Message-ID: <3F5DE64A.6020305@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: Dirk.Trossen@nokia.com, geopriv@ietf.org, simple@ietf.org Subject: Re: [Simple] Re: [Geopriv] Individuals, hats and spheres References: <2038BCC78B1AD641891A0D1AE133DBB7017970B0@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB7017970B0@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, 09 Sep 2003 10:40:10 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > Dimension, perhaps. > > Just a few questions: > > - Why is a sphere different than a group? This is not a group as it defines a matching parameter that is (or could be) used alongside other context information, such as the person, a time range and a place. In many cases, this will correspond to "allow {group of people} access to me when I'm working/at home", but the semantics is slightly different. The model is "I have declared myself to be in state/sphere X. Please apply the rules that apply to that state." In the end, all rules boil down to {set of people} can do {set of things}, but the number of such sets may be very large. > > - Why this type of analogy is limited to geoloc? It isn't. It's just that some of the discussion on privacy-related issues has taken place there and that many of those involving location tended to be of the "I'm at work" vs. "I'm off work" flavor. (Mistresses also seem to be popular in that working group :-)) I have argued before that I see no principal difference in most cases (stalkers excepted) between the privacy considerations for what I'm currently doing and where I am, particularly since they are often derivable from each other with high probability. In some cases, activity information is more sensitive (knowing that I'm in state 'sleeping' during work hours is more revealing than that I'm not moving in my office), in others it's not ("driving" vs. "vectored to the drug treatment center"). > > - How this is different from the stream-header we had in PUBLISH? I fail to see the connection. This is much closer to and and in some cases, there will be a high correlation between (,) and , but since the correlation is less than perfect, it seemed better to make the real intent explicit. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Sep 9 11:15:59 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16426; Tue, 9 Sep 2003 11:15:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19wkDr-0005NQ-00; Tue, 09 Sep 2003 11:16:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19wkDq-0005NN-00; Tue, 09 Sep 2003 11:16:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wkDp-0003QJ-8T; Tue, 09 Sep 2003 11:16:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wkDL-0003Od-Kc for simple@optimus.ietf.org; Tue, 09 Sep 2003 11:15: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 LAA16402; Tue, 9 Sep 2003 11:15:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19wkDK-0005MV-00; Tue, 09 Sep 2003 11:15:30 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 19wkD5-0005M3-00; Tue, 09 Sep 2003 11:15:16 -0400 Received: from magnum.cs.columbia.edu (IDENT:root@magnum.cs.columbia.edu [128.59.16.117]) by cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h89FEeoH028874; Tue, 9 Sep 2003 11:14:40 -0400 (EDT) Received: from cs.columbia.edu (path.cs.columbia.edu [128.59.19.143]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h89FEdG09737; Tue, 9 Sep 2003 11:14:39 -0400 Message-ID: <3F5DEE5F.9020200@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Schnizlein CC: geopriv@ietf.org, simple@ietf.org Subject: Re: [Simple] Re: [Geopriv] Individuals, hats and spheres References: <2038BCC78B1AD641891A0D1AE133DBB7017970B0@esebe019.ntc.nokia.com> <2038BCC78B1AD641891A0D1AE133DBB7017970B0@esebe019.ntc.nokia.com> <4.3.2.7.2.20030909105254.0221cda0@wells.cisco.com> In-Reply-To: <4.3.2.7.2.20030909105254.0221cda0@wells.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: Tue, 09 Sep 2003 11:14:39 -0400 Content-Transfer-Encoding: 7bit I myself am less than happy with the term sphere. "Role" has been suggested and may be less overloaded, however, it doesn't quite work. I would say that I play the role of 'father' or 'teacher', but I wouldn't say that I'm in a work role or private role. Amateur and professional sociologists may want to step in here... John Schnizlein wrote: > My impression is that the spherical shape of the earth's geography > is an unintended analogy to the "spheres of interest" Henning meant. > This might be sufficient reason to change the word, but the concept > of many-to-many categories of individuals is important. Allowing > watchers in the same category to get my location is the concept. > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Sep 9 11:16:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16493 for ; Tue, 9 Sep 2003 11:16: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 19wkDv-0003SY-9E for simple-archive@odin.ietf.org; Tue, 09 Sep 2003 11:16:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h89FG7o0013297 for simple-archive@odin.ietf.org; Tue, 9 Sep 2003 11:16:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wkDv-0003SO-51 for simple-web-archive@optimus.ietf.org; Tue, 09 Sep 2003 11:16: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 LAA16426; Tue, 9 Sep 2003 11:15:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19wkDr-0005NQ-00; Tue, 09 Sep 2003 11:16:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19wkDq-0005NN-00; Tue, 09 Sep 2003 11:16:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wkDp-0003QJ-8T; Tue, 09 Sep 2003 11:16:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wkDL-0003Od-Kc for simple@optimus.ietf.org; Tue, 09 Sep 2003 11:15: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 LAA16402; Tue, 9 Sep 2003 11:15:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19wkDK-0005MV-00; Tue, 09 Sep 2003 11:15:30 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 19wkD5-0005M3-00; Tue, 09 Sep 2003 11:15:16 -0400 Received: from magnum.cs.columbia.edu (IDENT:root@magnum.cs.columbia.edu [128.59.16.117]) by cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h89FEeoH028874; Tue, 9 Sep 2003 11:14:40 -0400 (EDT) Received: from cs.columbia.edu (path.cs.columbia.edu [128.59.19.143]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h89FEdG09737; Tue, 9 Sep 2003 11:14:39 -0400 Message-ID: <3F5DEE5F.9020200@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Schnizlein CC: geopriv@ietf.org, simple@ietf.org Subject: Re: [Simple] Re: [Geopriv] Individuals, hats and spheres References: <2038BCC78B1AD641891A0D1AE133DBB7017970B0@esebe019.ntc.nokia.com> <2038BCC78B1AD641891A0D1AE133DBB7017970B0@esebe019.ntc.nokia.com> <4.3.2.7.2.20030909105254.0221cda0@wells.cisco.com> In-Reply-To: <4.3.2.7.2.20030909105254.0221cda0@wells.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: Tue, 09 Sep 2003 11:14:39 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I myself am less than happy with the term sphere. "Role" has been suggested and may be less overloaded, however, it doesn't quite work. I would say that I play the role of 'father' or 'teacher', but I wouldn't say that I'm in a work role or private role. Amateur and professional sociologists may want to step in here... John Schnizlein wrote: > My impression is that the spherical shape of the earth's geography > is an unintended analogy to the "spheres of interest" Henning meant. > This might be sufficient reason to change the word, but the concept > of many-to-many categories of individuals is important. Allowing > watchers in the same category to get my location is the concept. > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Sep 9 11:21: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 LAA16846; Tue, 9 Sep 2003 11:21:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19wkJf-0005Vj-00; Tue, 09 Sep 2003 11:22:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19wkJf-0005Vg-00; Tue, 09 Sep 2003 11:22:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wkJd-0003kQ-4U; Tue, 09 Sep 2003 11:22:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wk1K-0002St-5z for simple@optimus.ietf.org; Tue, 09 Sep 2003 11:03:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15530; Tue, 9 Sep 2003 11:02:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19wk1H-00053z-00; Tue, 09 Sep 2003 11:03:03 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19wk1G-00053P-00; Tue, 09 Sep 2003 11:03:03 -0400 Received: from cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 09 Sep 2003 08:02:33 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h89F2TdP001262; Tue, 9 Sep 2003 08:02:30 -0700 (PDT) Received: from jschnizl-w2k.cisco.com (rtp-vpn2-536.cisco.com [10.82.242.24]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ACF51990; Tue, 9 Sep 2003 11:02:28 -0400 (EDT) Message-Id: <4.3.2.7.2.20030909105254.0221cda0@wells.cisco.com> X-Sender: jschnizl@wells.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Henning Schulzrinne From: John Schnizlein Subject: Re: [Simple] Re: [Geopriv] Individuals, hats and spheres Cc: hisham.khartabil@nokia.com, Dirk.Trossen@nokia.com, geopriv@ietf.org, simple@ietf.org In-Reply-To: <3F5DE64A.6020305@cs.columbia.edu> References: <2038BCC78B1AD641891A0D1AE133DBB7017970B0@esebe019.ntc.nokia.com> <2038BCC78B1AD641891A0D1AE133DBB7017970B0@esebe019.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: Tue, 09 Sep 2003 10:57:37 -0400 My impression is that the spherical shape of the earth's geography is an unintended analogy to the "spheres of interest" Henning meant. This might be sufficient reason to change the word, but the concept of many-to-many categories of individuals is important. Allowing watchers in the same category to get my location is the concept. John At 10:40 AM 9/9/2003, Henning Schulzrinne wrote: >>- Why this type of analogy is limited to geoloc? > >It isn't. It's just that some of the discussion on privacy-related issues has taken place there and that many of those involving location tended to be of the "I'm at work" vs. "I'm off work" flavor. (Mistresses also seem to be popular in that working group :-)) _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Sep 9 11:22:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16906 for ; Tue, 9 Sep 2003 11:22:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wkJh-0003mM-3q for simple-archive@odin.ietf.org; Tue, 09 Sep 2003 11:22:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h89FM5dM014520 for simple-archive@odin.ietf.org; Tue, 9 Sep 2003 11:22:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wkJg-0003m7-Ve for simple-web-archive@optimus.ietf.org; Tue, 09 Sep 2003 11:22: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 LAA16846; Tue, 9 Sep 2003 11:21:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19wkJf-0005Vj-00; Tue, 09 Sep 2003 11:22:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19wkJf-0005Vg-00; Tue, 09 Sep 2003 11:22:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wkJd-0003kQ-4U; Tue, 09 Sep 2003 11:22:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wk1K-0002St-5z for simple@optimus.ietf.org; Tue, 09 Sep 2003 11:03:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15530; Tue, 9 Sep 2003 11:02:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19wk1H-00053z-00; Tue, 09 Sep 2003 11:03:03 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19wk1G-00053P-00; Tue, 09 Sep 2003 11:03:03 -0400 Received: from cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 09 Sep 2003 08:02:33 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h89F2TdP001262; Tue, 9 Sep 2003 08:02:30 -0700 (PDT) Received: from jschnizl-w2k.cisco.com (rtp-vpn2-536.cisco.com [10.82.242.24]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ACF51990; Tue, 9 Sep 2003 11:02:28 -0400 (EDT) Message-Id: <4.3.2.7.2.20030909105254.0221cda0@wells.cisco.com> X-Sender: jschnizl@wells.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Henning Schulzrinne From: John Schnizlein Subject: Re: [Simple] Re: [Geopriv] Individuals, hats and spheres Cc: hisham.khartabil@nokia.com, Dirk.Trossen@nokia.com, geopriv@ietf.org, simple@ietf.org In-Reply-To: <3F5DE64A.6020305@cs.columbia.edu> References: <2038BCC78B1AD641891A0D1AE133DBB7017970B0@esebe019.ntc.nokia.com> <2038BCC78B1AD641891A0D1AE133DBB7017970B0@esebe019.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: Tue, 09 Sep 2003 10:57:37 -0400 My impression is that the spherical shape of the earth's geography is an unintended analogy to the "spheres of interest" Henning meant. This might be sufficient reason to change the word, but the concept of many-to-many categories of individuals is important. Allowing watchers in the same category to get my location is the concept. John At 10:40 AM 9/9/2003, Henning Schulzrinne wrote: >>- Why this type of analogy is limited to geoloc? > >It isn't. It's just that some of the discussion on privacy-related issues has taken place there and that many of those involving location tended to be of the "I'm at work" vs. "I'm off work" flavor. (Mistresses also seem to be popular in that working group :-)) _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Sep 9 13:51:59 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25556; Tue, 9 Sep 2003 13:51:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19wmep-0000RH-00; Tue, 09 Sep 2003 13:52:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19wmep-0000RC-00; Tue, 09 Sep 2003 13:52:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wmen-0002N6-Dl; Tue, 09 Sep 2003 13:52:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wme9-0002Kn-Cp for simple@optimus.ietf.org; Tue, 09 Sep 2003 13:51: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 NAA25454 for ; Tue, 9 Sep 2003 13:51:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19wme7-0000Op-00 for simple@ietf.org; Tue, 09 Sep 2003 13:51:19 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 19wme6-0000O7-00 for simple@ietf.org; Tue, 09 Sep 2003 13:51:18 -0400 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id h89HoKVW019371; Tue, 9 Sep 2003 12:50:22 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3F5E12D4.1060407@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030723 Thunderbird/0.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Miguel A. Garcia" CC: simple@ietf.org Subject: Re: [Simple] Default 1 minute inactivity timer in MSRP References: <3F583D50.6070100@ericsson.com> In-Reply-To: <3F583D50.6070100@ericsson.com> X-Enigmail-Version: 0.81.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.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, 09 Sep 2003 12:50:12 -0500 Content-Transfer-Encoding: 7bit The value of 1 minute was intended to be a strawman to get people to start talking about a reasonable value that balances bandwidth concerns against the desire to minimize state kept at a relay. So far, that has not occured. I am very open to any better approached to selecting the value. I do note that a keepalive message can be quite small (less than 25 bytes + lower layer overhead, depending on how you select your message ID value.) This means that if you stayed connected to a dormant chat room for 24 hours, you would only be using < 100k, or around 2 cents at SprintPCS's rate for "additional" data of $0.002 per kilobyte. (I make no claims to whether this is a representative rate.) The idea of a non-negotiable value came out of the room consensus at the intermim meeting, and has been around for a while now. Negotiating the timer would add a lot of complexity in the 2 relay use case. The EXP time is used for a completely different purpose, and its value is never communicated to the visitor. Miguel A. Garcia wrote: > Hi: > > Just by reading the message session draft, I have found the description > of a 1 minute session inactivity timer (see section 7.4.5) > > I am a bit shocked with this requirement. So does it mean that if I > establish an MSRP session to a chat room that is in dormant state, I > will have to send empty SEND primitives every minute just to refresh the > state??? Sounds weird... Specially if I am paying for the bytes that I > send and if I have to seize resources for sending this timer... it > sounds completely unefficient. > > If I understand correctly (correct me if I am wrong), MSRP provides two > timers: the session timer negotiated in the Exp header and the > inactivity timer harcoded to 1 minute. > > The question is do we really need both timers??? Why isn't the session > timer enough for the purpose of supervising the session??? > > /Miguel > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Sep 9 13:52: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 NAA25635 for ; Tue, 9 Sep 2003 13:52: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 19wmes-0002O9-PP for simple-archive@odin.ietf.org; Tue, 09 Sep 2003 13:52:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h89Hq63D009175 for simple-archive@odin.ietf.org; Tue, 9 Sep 2003 13:52:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wmes-0002Nu-LR for simple-web-archive@optimus.ietf.org; Tue, 09 Sep 2003 13:52: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 NAA25556; Tue, 9 Sep 2003 13:51:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19wmep-0000RH-00; Tue, 09 Sep 2003 13:52:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19wmep-0000RC-00; Tue, 09 Sep 2003 13:52:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wmen-0002N6-Dl; Tue, 09 Sep 2003 13:52:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wme9-0002Kn-Cp for simple@optimus.ietf.org; Tue, 09 Sep 2003 13:51: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 NAA25454 for ; Tue, 9 Sep 2003 13:51:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19wme7-0000Op-00 for simple@ietf.org; Tue, 09 Sep 2003 13:51:19 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 19wme6-0000O7-00 for simple@ietf.org; Tue, 09 Sep 2003 13:51:18 -0400 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id h89HoKVW019371; Tue, 9 Sep 2003 12:50:22 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3F5E12D4.1060407@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030723 Thunderbird/0.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Miguel A. Garcia" CC: simple@ietf.org Subject: Re: [Simple] Default 1 minute inactivity timer in MSRP References: <3F583D50.6070100@ericsson.com> In-Reply-To: <3F583D50.6070100@ericsson.com> X-Enigmail-Version: 0.81.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.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, 09 Sep 2003 12:50:12 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit The value of 1 minute was intended to be a strawman to get people to start talking about a reasonable value that balances bandwidth concerns against the desire to minimize state kept at a relay. So far, that has not occured. I am very open to any better approached to selecting the value. I do note that a keepalive message can be quite small (less than 25 bytes + lower layer overhead, depending on how you select your message ID value.) This means that if you stayed connected to a dormant chat room for 24 hours, you would only be using < 100k, or around 2 cents at SprintPCS's rate for "additional" data of $0.002 per kilobyte. (I make no claims to whether this is a representative rate.) The idea of a non-negotiable value came out of the room consensus at the intermim meeting, and has been around for a while now. Negotiating the timer would add a lot of complexity in the 2 relay use case. The EXP time is used for a completely different purpose, and its value is never communicated to the visitor. Miguel A. Garcia wrote: > Hi: > > Just by reading the message session draft, I have found the description > of a 1 minute session inactivity timer (see section 7.4.5) > > I am a bit shocked with this requirement. So does it mean that if I > establish an MSRP session to a chat room that is in dormant state, I > will have to send empty SEND primitives every minute just to refresh the > state??? Sounds weird... Specially if I am paying for the bytes that I > send and if I have to seize resources for sending this timer... it > sounds completely unefficient. > > If I understand correctly (correct me if I am wrong), MSRP provides two > timers: the session timer negotiated in the Exp header and the > inactivity timer harcoded to 1 minute. > > The question is do we really need both timers??? Why isn't the session > timer enough for the purpose of supervising the session??? > > /Miguel > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Sep 10 04: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 EAA22968; Wed, 10 Sep 2003 04:49:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19x0f1-0001yq-00; Wed, 10 Sep 2003 04:49:11 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19x0f1-0001yl-00; Wed, 10 Sep 2003 04:49:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19x0et-0005HF-77; Wed, 10 Sep 2003 04:49:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19x0eB-0005GY-Nb for simple@optimus.ietf.org; Wed, 10 Sep 2003 04:48: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 EAA22950 for ; Wed, 10 Sep 2003 04:48:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19x0e8-0001yN-00 for simple@ietf.org; Wed, 10 Sep 2003 04:48:16 -0400 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 19x0e7-0001yK-00 for simple@ietf.org; Wed, 10 Sep 2003 04:48:16 -0400 Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by penguin-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.7) with ESMTP id h8A8mC31014613; Wed, 10 Sep 2003 10:48:12 +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 SKNRC7NC; Wed, 10 Sep 2003 10:49:36 +0200 Received: from ericsson.com (fijowa02m25.sw.ericsson.se [136.225.183.89]) by hendrix.lmf.ericsson.se (8.12.8/8.12.8/lmf-2.1-jcs) with ESMTP id h8A8m9SZ008468; Wed, 10 Sep 2003 11:48:10 +0300 (EET DST) Message-ID: <3F5EE548.4030008@ericsson.com> X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en, es MIME-Version: 1.0 To: Ben Campbell CC: simple@ietf.org Subject: Re: [Simple] Default 1 minute inactivity timer in MSRP References: <3F583D50.6070100@ericsson.com> <3F5E12D4.1060407@dynamicsoft.com> In-Reply-To: <3F5E12D4.1060407@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: Wed, 10 Sep 2003 11:48:08 +0300 Content-Transfer-Encoding: 7bit Ben: I mostly disagree with your analysis. First, you say that the session timer value is never communicated to the visitor. This is not what the draft says, at least I can see in the examples that the EXP time is conveyed in the 200 OK answer for the VISIT method (see section 8.2 in the draft, steps 4 and 5). And I believe this is the right thing to do. Second, I still don't find a difference between the session timer and the inactivity timer. You just mentioned that the session timer is used for a completely different purpose, without mention what the purposes of both timers are. IMHO having a session timer in place solves all the timing issues. If not, please, clarify what timing issue is the inactivity timer trying to solve. Third, paying some cents for the inactivity timer is something we want to avoid. But depending on the network technology and the previous state, sizing resources to send this inactivity timer might be expensive for the network, not necessarily for the user. It may take some time, and use resources somewhere else. Certainly this is something we should try to avoid. /Miguel Ben Campbell wrote: > > The value of 1 minute was intended to be a strawman to get people to > start talking about a reasonable value that balances bandwidth concerns > against the desire to minimize state kept at a relay. So far, that has > not occured. I am very open to any better approached to selecting the > value. > > I do note that a keepalive message can be quite small (less than 25 > bytes + lower layer overhead, depending on how you select your message > ID value.) This means that if you stayed connected to a dormant chat > room for 24 hours, you would only be using < 100k, or around 2 cents at > SprintPCS's rate for "additional" data of $0.002 per kilobyte. (I make > no claims to whether this is a representative rate.) > > The idea of a non-negotiable value came out of the room consensus at the > intermim meeting, and has been around for a while now. Negotiating the > timer would add a lot of complexity in the 2 relay use case. The EXP > time is used for a completely different purpose, and its value is never > communicated to the visitor. > > Miguel A. Garcia wrote: > >> Hi: >> >> Just by reading the message session draft, I have found the >> description of a 1 minute session inactivity timer (see section 7.4.5) >> >> I am a bit shocked with this requirement. So does it mean that if I >> establish an MSRP session to a chat room that is in dormant state, I >> will have to send empty SEND primitives every minute just to refresh >> the state??? Sounds weird... Specially if I am paying for the bytes >> that I send and if I have to seize resources for sending this timer... >> it sounds completely unefficient. >> >> If I understand correctly (correct me if I am wrong), MSRP provides >> two timers: the session timer negotiated in the Exp header and the >> inactivity timer harcoded to 1 minute. >> >> The question is do we really need both timers??? Why isn't the session >> timer enough for the purpose of supervising the session??? >> >> /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 514 0002 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Sep 10 04:49:41 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 EAA22990 for ; Wed, 10 Sep 2003 04:49:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19x0f7-0005IA-Ug for simple-archive@odin.ietf.org; Wed, 10 Sep 2003 04:49:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8A8nH2Y020335 for simple-archive@odin.ietf.org; Wed, 10 Sep 2003 04:49:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19x0f5-0005Hu-3p for simple-web-archive@optimus.ietf.org; Wed, 10 Sep 2003 04:49: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 EAA22968; Wed, 10 Sep 2003 04:49:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19x0f1-0001yq-00; Wed, 10 Sep 2003 04:49:11 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19x0f1-0001yl-00; Wed, 10 Sep 2003 04:49:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19x0et-0005HF-77; Wed, 10 Sep 2003 04:49:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19x0eB-0005GY-Nb for simple@optimus.ietf.org; Wed, 10 Sep 2003 04:48: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 EAA22950 for ; Wed, 10 Sep 2003 04:48:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19x0e8-0001yN-00 for simple@ietf.org; Wed, 10 Sep 2003 04:48:16 -0400 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 19x0e7-0001yK-00 for simple@ietf.org; Wed, 10 Sep 2003 04:48:16 -0400 Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by penguin-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.7) with ESMTP id h8A8mC31014613; Wed, 10 Sep 2003 10:48:12 +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 SKNRC7NC; Wed, 10 Sep 2003 10:49:36 +0200 Received: from ericsson.com (fijowa02m25.sw.ericsson.se [136.225.183.89]) by hendrix.lmf.ericsson.se (8.12.8/8.12.8/lmf-2.1-jcs) with ESMTP id h8A8m9SZ008468; Wed, 10 Sep 2003 11:48:10 +0300 (EET DST) Message-ID: <3F5EE548.4030008@ericsson.com> X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en, es MIME-Version: 1.0 To: Ben Campbell CC: simple@ietf.org Subject: Re: [Simple] Default 1 minute inactivity timer in MSRP References: <3F583D50.6070100@ericsson.com> <3F5E12D4.1060407@dynamicsoft.com> In-Reply-To: <3F5E12D4.1060407@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: Wed, 10 Sep 2003 11:48:08 +0300 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Ben: I mostly disagree with your analysis. First, you say that the session timer value is never communicated to the visitor. This is not what the draft says, at least I can see in the examples that the EXP time is conveyed in the 200 OK answer for the VISIT method (see section 8.2 in the draft, steps 4 and 5). And I believe this is the right thing to do. Second, I still don't find a difference between the session timer and the inactivity timer. You just mentioned that the session timer is used for a completely different purpose, without mention what the purposes of both timers are. IMHO having a session timer in place solves all the timing issues. If not, please, clarify what timing issue is the inactivity timer trying to solve. Third, paying some cents for the inactivity timer is something we want to avoid. But depending on the network technology and the previous state, sizing resources to send this inactivity timer might be expensive for the network, not necessarily for the user. It may take some time, and use resources somewhere else. Certainly this is something we should try to avoid. /Miguel Ben Campbell wrote: > > The value of 1 minute was intended to be a strawman to get people to > start talking about a reasonable value that balances bandwidth concerns > against the desire to minimize state kept at a relay. So far, that has > not occured. I am very open to any better approached to selecting the > value. > > I do note that a keepalive message can be quite small (less than 25 > bytes + lower layer overhead, depending on how you select your message > ID value.) This means that if you stayed connected to a dormant chat > room for 24 hours, you would only be using < 100k, or around 2 cents at > SprintPCS's rate for "additional" data of $0.002 per kilobyte. (I make > no claims to whether this is a representative rate.) > > The idea of a non-negotiable value came out of the room consensus at the > intermim meeting, and has been around for a while now. Negotiating the > timer would add a lot of complexity in the 2 relay use case. The EXP > time is used for a completely different purpose, and its value is never > communicated to the visitor. > > Miguel A. Garcia wrote: > >> Hi: >> >> Just by reading the message session draft, I have found the >> description of a 1 minute session inactivity timer (see section 7.4.5) >> >> I am a bit shocked with this requirement. So does it mean that if I >> establish an MSRP session to a chat room that is in dormant state, I >> will have to send empty SEND primitives every minute just to refresh >> the state??? Sounds weird... Specially if I am paying for the bytes >> that I send and if I have to seize resources for sending this timer... >> it sounds completely unefficient. >> >> If I understand correctly (correct me if I am wrong), MSRP provides >> two timers: the session timer negotiated in the Exp header and the >> inactivity timer harcoded to 1 minute. >> >> The question is do we really need both timers??? Why isn't the session >> timer enough for the purpose of supervising the session??? >> >> /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 514 0002 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Sep 10 09:37: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 JAA28954; Wed, 10 Sep 2003 09:37:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19x59d-0003pP-00; Wed, 10 Sep 2003 09:37:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19x59d-0003pM-00; Wed, 10 Sep 2003 09:37:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19x59Z-0004rH-MD; Wed, 10 Sep 2003 09:37:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19x592-0004q8-7m for simple@optimus.ietf.org; Wed, 10 Sep 2003 09:36: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 JAA28944; Wed, 10 Sep 2003 09:36:20 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19x590-0003pD-00; Wed, 10 Sep 2003 09:36:26 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19x58y-0003p9-00; Wed, 10 Sep 2003 09:36:25 -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 h8ADZw424275; Wed, 10 Sep 2003 16:36:11 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 10 Sep 2003 16:35:57 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 10 Sep 2003 16:35:57 +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] Re: [Geopriv] Individuals, hats and spheres Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017970C3@esebe019.ntc.nokia.com> Thread-Topic: [Simple] Re: [Geopriv] Individuals, hats and spheres Thread-Index: AcN25VQIERAIql9vT4eq78gatVRMaQAusWlw To: , Cc: , X-OriginalArrivalTime: 10 Sep 2003 13:35:57.0881 (UTC) FILETIME=[77700A90:01C377A0] 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, 10 Sep 2003 16:35:56 +0300 Content-Transfer-Encoding: quoted-printable I did suggest Dimension. Also, how about Facet? /Hisham > -----Original Message----- > From: ext Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Tuesday, September 09, 2003 6:15 PM > To: John Schnizlein > Cc: geopriv@ietf.org; simple@ietf.org > Subject: Re: [Simple] Re: [Geopriv] Individuals, hats and spheres >=20 >=20 > I myself am less than happy with the term sphere. "Role" has been=20 > suggested and may be less overloaded, however, it doesn't quite work. >=20 > I would say that I play the role of 'father' or 'teacher', but I=20 > wouldn't say that I'm in a work role or private role. >=20 > Amateur and professional sociologists may want to step in here... >=20 > John Schnizlein wrote: > > My impression is that the spherical shape of the earth's geography > > is an unintended analogy to the "spheres of interest" Henning meant. > > This might be sufficient reason to change the word, but the concept > > of many-to-many categories of individuals is important. Allowing > > watchers in the same category to get my location is the concept. > >=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 Wed Sep 10 09:37:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28973 for ; Wed, 10 Sep 2003 09:37:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19x59f-0004t6-Te for simple-archive@odin.ietf.org; Wed, 10 Sep 2003 09:37:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8ADb77p018784 for simple-archive@odin.ietf.org; Wed, 10 Sep 2003 09:37:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19x59f-0004st-M1 for simple-web-archive@optimus.ietf.org; Wed, 10 Sep 2003 09:37: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 JAA28954; Wed, 10 Sep 2003 09:37:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19x59d-0003pP-00; Wed, 10 Sep 2003 09:37:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19x59d-0003pM-00; Wed, 10 Sep 2003 09:37:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19x59Z-0004rH-MD; Wed, 10 Sep 2003 09:37:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19x592-0004q8-7m for simple@optimus.ietf.org; Wed, 10 Sep 2003 09:36: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 JAA28944; Wed, 10 Sep 2003 09:36:20 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19x590-0003pD-00; Wed, 10 Sep 2003 09:36:26 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19x58y-0003p9-00; Wed, 10 Sep 2003 09:36:25 -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 h8ADZw424275; Wed, 10 Sep 2003 16:36:11 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 10 Sep 2003 16:35:57 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 10 Sep 2003 16:35:57 +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] Re: [Geopriv] Individuals, hats and spheres Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017970C3@esebe019.ntc.nokia.com> Thread-Topic: [Simple] Re: [Geopriv] Individuals, hats and spheres Thread-Index: AcN25VQIERAIql9vT4eq78gatVRMaQAusWlw To: , Cc: , X-OriginalArrivalTime: 10 Sep 2003 13:35:57.0881 (UTC) FILETIME=[77700A90:01C377A0] 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, 10 Sep 2003 16:35:56 +0300 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I did suggest Dimension. Also, how about Facet? /Hisham > -----Original Message----- > From: ext Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Tuesday, September 09, 2003 6:15 PM > To: John Schnizlein > Cc: geopriv@ietf.org; simple@ietf.org > Subject: Re: [Simple] Re: [Geopriv] Individuals, hats and spheres >=20 >=20 > I myself am less than happy with the term sphere. "Role" has been=20 > suggested and may be less overloaded, however, it doesn't quite work. >=20 > I would say that I play the role of 'father' or 'teacher', but I=20 > wouldn't say that I'm in a work role or private role. >=20 > Amateur and professional sociologists may want to step in here... >=20 > John Schnizlein wrote: > > My impression is that the spherical shape of the earth's geography > > is an unintended analogy to the "spheres of interest" Henning meant. > > This might be sufficient reason to change the word, but the concept > > of many-to-many categories of individuals is important. Allowing > > watchers in the same category to get my location is the concept. > >=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 Wed Sep 10 09:42:58 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29134; Wed, 10 Sep 2003 09:42:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19x5FQ-0003rl-00; Wed, 10 Sep 2003 09:43:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19x5FP-0003ri-00; Wed, 10 Sep 2003 09:43:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19x5FN-0005JE-Hy; Wed, 10 Sep 2003 09:43:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19x5FF-0005If-7O for simple@optimus.ietf.org; Wed, 10 Sep 2003 09:42: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 JAA29108; Wed, 10 Sep 2003 09:42:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19x5FD-0003rE-00; Wed, 10 Sep 2003 09:42:51 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 19x5FC-0003rB-00; Wed, 10 Sep 2003 09:42:50 -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 h8ADgooH025120; Wed, 10 Sep 2003 09:42:50 -0400 (EDT) Received: from cs.columbia.edu (path.cs.columbia.edu [128.59.19.143]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h8ADgnG28227; Wed, 10 Sep 2003 09:42:50 -0400 Message-ID: <3F5F2A59.3050600@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: geopriv@ietf.org, simple@ietf.org Subject: Re: [Simple] Re: [Geopriv] Individuals, hats and spheres References: <2038BCC78B1AD641891A0D1AE133DBB7017970C3@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB7017970C3@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: Wed, 10 Sep 2003 09:42:49 -0400 Content-Transfer-Encoding: 7bit Facet, in particular, is being used (in the IETF, by John Klensin's drafts) in a completely generic way, describing any attribute of a resource. hisham.khartabil@nokia.com wrote: > I did suggest Dimension. Also, how about Facet? > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Sep 10 09:43:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29190 for ; Wed, 10 Sep 2003 09:43:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19x5FS-0005Lw-Im for simple-archive@odin.ietf.org; Wed, 10 Sep 2003 09:43:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8ADh6Zg020570 for simple-archive@odin.ietf.org; Wed, 10 Sep 2003 09:43:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19x5FS-0005Lh-C9 for simple-web-archive@optimus.ietf.org; Wed, 10 Sep 2003 09:43: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 JAA29134; Wed, 10 Sep 2003 09:42:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19x5FQ-0003rl-00; Wed, 10 Sep 2003 09:43:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19x5FP-0003ri-00; Wed, 10 Sep 2003 09:43:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19x5FN-0005JE-Hy; Wed, 10 Sep 2003 09:43:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19x5FF-0005If-7O for simple@optimus.ietf.org; Wed, 10 Sep 2003 09:42: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 JAA29108; Wed, 10 Sep 2003 09:42:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19x5FD-0003rE-00; Wed, 10 Sep 2003 09:42:51 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 19x5FC-0003rB-00; Wed, 10 Sep 2003 09:42:50 -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 h8ADgooH025120; Wed, 10 Sep 2003 09:42:50 -0400 (EDT) Received: from cs.columbia.edu (path.cs.columbia.edu [128.59.19.143]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h8ADgnG28227; Wed, 10 Sep 2003 09:42:50 -0400 Message-ID: <3F5F2A59.3050600@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: geopriv@ietf.org, simple@ietf.org Subject: Re: [Simple] Re: [Geopriv] Individuals, hats and spheres References: <2038BCC78B1AD641891A0D1AE133DBB7017970C3@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB7017970C3@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: Wed, 10 Sep 2003 09:42:49 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Facet, in particular, is being used (in the IETF, by John Klensin's drafts) in a completely generic way, describing any attribute of a resource. hisham.khartabil@nokia.com wrote: > I did suggest Dimension. Also, how about Facet? > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Sep 10 10:35: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 KAA02005; Wed, 10 Sep 2003 10:35:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19x63t-0004Hq-00; Wed, 10 Sep 2003 10:35:13 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19x63s-0004Hn-00; Wed, 10 Sep 2003 10:35:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19x63j-0006hE-Kk; Wed, 10 Sep 2003 10:35:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19x63W-0006ge-I0 for simple@optimus.ietf.org; Wed, 10 Sep 2003 10:34:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01987 for ; Wed, 10 Sep 2003 10:34:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19x63T-0004Hj-00 for simple@ietf.org; Wed, 10 Sep 2003 10:34:47 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19x63T-0004HV-00 for simple@ietf.org; Wed, 10 Sep 2003 10:34:47 -0400 Received: from dynamicsoft.com (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h8AEY6d18876; Wed, 10 Sep 2003 09:34:06 -0500 Message-ID: <3F5F3655.7060508@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030723 Thunderbird/0.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Miguel A. Garcia" CC: simple@ietf.org Subject: Re: [Simple] Default 1 minute inactivity timer in MSRP References: <3F583D50.6070100@ericsson.com> <3F5E12D4.1060407@dynamicsoft.com> <3F5EE548.4030008@ericsson.com> In-Reply-To: <3F5EE548.4030008@ericsson.com> X-Enigmail-Version: 0.81.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.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, 10 Sep 2003 09:33:57 -0500 Content-Transfer-Encoding: 7bit Miguel A. Garcia wrote: > Ben: > > I mostly disagree with your analysis. > > First, you say that the session timer value is never communicated to the > visitor. This is not what the draft says, at least I can see in the > examples that the EXP time is conveyed in the 200 OK answer for the > VISIT method (see section 8.2 in the draft, steps 4 and 5). And I > believe this is the right thing to do. > The draft actually forbids this in the normative text. The presence Exp in the example VISIT responses is an error in the draft. > Second, I still don't find a difference between the session timer and > the inactivity timer. You just mentioned that the session timer is used > for a completely different purpose, without mention what the purposes of > both timers are. IMHO having a session timer in place solves all the > timing issues. If not, please, clarify what timing issue is the > inactivity timer trying to solve. The Exp timer (refered to as the pre-visit timer in the draft) is only used to control how long a hosting relay will wait for a visit to occur. For historical background, earlier versions of the draft required refreshing of BIND and VISIT, and Exp acted much like the Expires header in SIP. When we moved to an inactivity timeout, we demoted this to its present purpose. We discussed removing it entirely, but enough people thought it was useful in its current role. > > Third, paying some cents for the inactivity timer is something we want > to avoid. But depending on the network technology and the previous > state, sizing resources to send this inactivity timer might be expensive > for the network, not necessarily for the user. It may take some time, > and use resources somewhere else. Certainly this is something we should > try to avoid. This point was discussed extensively in the interim meeting, and the consensus of the room was that alternatives to this approach either required more resources, or added significant complexity. I still consider the 1 minute value as an open issue, though. So, this brings up a couple of questions for the list in general: 1) Do others agree with Miguel that we should make the inactivity timeout negotiable? 2) If not, can anyone suggest a better way to choose the standard value? Thanks! Ben. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Sep 10 10:35:41 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 KAA02040 for ; Wed, 10 Sep 2003 10:35:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19x63y-0006i0-IP for simple-archive@odin.ietf.org; Wed, 10 Sep 2003 10:35:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8AEZIlv025787 for simple-archive@odin.ietf.org; Wed, 10 Sep 2003 10:35:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19x63y-0006hq-9k for simple-web-archive@optimus.ietf.org; Wed, 10 Sep 2003 10:35: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 KAA02005; Wed, 10 Sep 2003 10:35:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19x63t-0004Hq-00; Wed, 10 Sep 2003 10:35:13 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19x63s-0004Hn-00; Wed, 10 Sep 2003 10:35:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19x63j-0006hE-Kk; Wed, 10 Sep 2003 10:35:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19x63W-0006ge-I0 for simple@optimus.ietf.org; Wed, 10 Sep 2003 10:34:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01987 for ; Wed, 10 Sep 2003 10:34:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19x63T-0004Hj-00 for simple@ietf.org; Wed, 10 Sep 2003 10:34:47 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19x63T-0004HV-00 for simple@ietf.org; Wed, 10 Sep 2003 10:34:47 -0400 Received: from dynamicsoft.com (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h8AEY6d18876; Wed, 10 Sep 2003 09:34:06 -0500 Message-ID: <3F5F3655.7060508@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030723 Thunderbird/0.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Miguel A. Garcia" CC: simple@ietf.org Subject: Re: [Simple] Default 1 minute inactivity timer in MSRP References: <3F583D50.6070100@ericsson.com> <3F5E12D4.1060407@dynamicsoft.com> <3F5EE548.4030008@ericsson.com> In-Reply-To: <3F5EE548.4030008@ericsson.com> X-Enigmail-Version: 0.81.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.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, 10 Sep 2003 09:33:57 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Miguel A. Garcia wrote: > Ben: > > I mostly disagree with your analysis. > > First, you say that the session timer value is never communicated to the > visitor. This is not what the draft says, at least I can see in the > examples that the EXP time is conveyed in the 200 OK answer for the > VISIT method (see section 8.2 in the draft, steps 4 and 5). And I > believe this is the right thing to do. > The draft actually forbids this in the normative text. The presence Exp in the example VISIT responses is an error in the draft. > Second, I still don't find a difference between the session timer and > the inactivity timer. You just mentioned that the session timer is used > for a completely different purpose, without mention what the purposes of > both timers are. IMHO having a session timer in place solves all the > timing issues. If not, please, clarify what timing issue is the > inactivity timer trying to solve. The Exp timer (refered to as the pre-visit timer in the draft) is only used to control how long a hosting relay will wait for a visit to occur. For historical background, earlier versions of the draft required refreshing of BIND and VISIT, and Exp acted much like the Expires header in SIP. When we moved to an inactivity timeout, we demoted this to its present purpose. We discussed removing it entirely, but enough people thought it was useful in its current role. > > Third, paying some cents for the inactivity timer is something we want > to avoid. But depending on the network technology and the previous > state, sizing resources to send this inactivity timer might be expensive > for the network, not necessarily for the user. It may take some time, > and use resources somewhere else. Certainly this is something we should > try to avoid. This point was discussed extensively in the interim meeting, and the consensus of the room was that alternatives to this approach either required more resources, or added significant complexity. I still consider the 1 minute value as an open issue, though. So, this brings up a couple of questions for the list in general: 1) Do others agree with Miguel that we should make the inactivity timeout negotiable? 2) If not, can anyone suggest a better way to choose the standard value? Thanks! Ben. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Sep 10 11:11:56 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 LAA03288; Wed, 10 Sep 2003 11:11:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19x6dW-0004bq-00; Wed, 10 Sep 2003 11:12:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19x6dV-0004bn-00; Wed, 10 Sep 2003 11:12:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19x6dV-0008Tk-VH; Wed, 10 Sep 2003 11:12:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19x6dT-0008TX-Dy for simple@optimus.ietf.org; Wed, 10 Sep 2003 11:11: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 LAA03283 for ; Wed, 10 Sep 2003 11:11:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19x6dQ-0004bj-00 for simple@ietf.org; Wed, 10 Sep 2003 11:11:56 -0400 Received: from news.ubiquity.net ([194.202.146.92] helo=gbnewp0186s1.eu.ubiquity.net) by ietf-mx with smtp (Exim 4.12) id 19x6dP-0004bg-00 for simple@ietf.org; Wed, 10 Sep 2003 11:11:56 -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; Wed, 10 Sep 2003 16:14:38 +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] Default 1 minute inactivity timer in MSRP Message-ID: <45730E094814E44488F789C1CDED27AE0219B09E@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [Simple] Default 1 minute inactivity timer in MSRP Thread-Index: AcN3qLHdWBsHzH5FSQWZkW/73EhF4wAAdAhg From: "Chris Boulton" To: "Ben Campbell" , "Miguel A. Garcia" Cc: 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, 10 Sep 2003 16:11:30 +0100 Content-Transfer-Encoding: quoted-printable <> > >So, this brings up a couple of questions for the list in general: > >1) Do others agree with Miguel that we should make the inactivity >timeout negotiable? [Chris Boulton] I must admit that I do have reservations regarding a one minute session timer. Yes, this may only produce a minimal amount of extra chargeable bytes BUT it does indicate a slight deficiency in the solution. =20 > >2) If not, can anyone suggest a better way to choose the standard value? [Chris Boulton] As mentioned earlier, negotiation maybe increase complexity BUT I will throw this into the pot as a potential solution. On receiving the 200 OK to the SIP INVITE the initiator of the session will send a SIP ACK - It will also send an MSRP SEND which contains a new header 'sess-timer' (*Note - it can use this header at any time during the session). This new header has a default value so that if this method is not used, the default will apply (e.g. 1 minute). On receiving the SEND (whether it be at the start of the session or mid session), the receiving MSRP client can either respond positively to the MSRP SEND request, indicating that it accepts the timer OR it rejects with a new MSRP error response code. The new response code will indicate the range of seconds that the client is willing to accept (max + min values in a header). If the initiator does not like this range it terminates the session, sending a SIP BYE ELSE it retransmits the send request with an alternative value in the 'ses-timer' header which falls into the range. There probably should be a limit on the number of times the client retries to avoid DOS attacks. =20 >Thanks! > >Ben. > > > > >_______________________________________________ >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 Sep 10 11:12:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03318 for ; Wed, 10 Sep 2003 11:12:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19x6dX-0008Uf-IM for simple-archive@odin.ietf.org; Wed, 10 Sep 2003 11:12:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8AFC3Cv032643 for simple-archive@odin.ietf.org; Wed, 10 Sep 2003 11:12:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19x6dX-0008UQ-FC for simple-web-archive@optimus.ietf.org; Wed, 10 Sep 2003 11:12: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 LAA03288; Wed, 10 Sep 2003 11:11:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19x6dW-0004bq-00; Wed, 10 Sep 2003 11:12:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19x6dV-0004bn-00; Wed, 10 Sep 2003 11:12:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19x6dV-0008Tk-VH; Wed, 10 Sep 2003 11:12:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19x6dT-0008TX-Dy for simple@optimus.ietf.org; Wed, 10 Sep 2003 11:11: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 LAA03283 for ; Wed, 10 Sep 2003 11:11:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19x6dQ-0004bj-00 for simple@ietf.org; Wed, 10 Sep 2003 11:11:56 -0400 Received: from news.ubiquity.net ([194.202.146.92] helo=gbnewp0186s1.eu.ubiquity.net) by ietf-mx with smtp (Exim 4.12) id 19x6dP-0004bg-00 for simple@ietf.org; Wed, 10 Sep 2003 11:11:56 -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; Wed, 10 Sep 2003 16:14:38 +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] Default 1 minute inactivity timer in MSRP Message-ID: <45730E094814E44488F789C1CDED27AE0219B09E@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [Simple] Default 1 minute inactivity timer in MSRP Thread-Index: AcN3qLHdWBsHzH5FSQWZkW/73EhF4wAAdAhg From: "Chris Boulton" To: "Ben Campbell" , "Miguel A. Garcia" Cc: 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, 10 Sep 2003 16:11:30 +0100 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable <> > >So, this brings up a couple of questions for the list in general: > >1) Do others agree with Miguel that we should make the inactivity >timeout negotiable? [Chris Boulton] I must admit that I do have reservations regarding a one minute session timer. Yes, this may only produce a minimal amount of extra chargeable bytes BUT it does indicate a slight deficiency in the solution. =20 > >2) If not, can anyone suggest a better way to choose the standard value? [Chris Boulton] As mentioned earlier, negotiation maybe increase complexity BUT I will throw this into the pot as a potential solution. On receiving the 200 OK to the SIP INVITE the initiator of the session will send a SIP ACK - It will also send an MSRP SEND which contains a new header 'sess-timer' (*Note - it can use this header at any time during the session). This new header has a default value so that if this method is not used, the default will apply (e.g. 1 minute). On receiving the SEND (whether it be at the start of the session or mid session), the receiving MSRP client can either respond positively to the MSRP SEND request, indicating that it accepts the timer OR it rejects with a new MSRP error response code. The new response code will indicate the range of seconds that the client is willing to accept (max + min values in a header). If the initiator does not like this range it terminates the session, sending a SIP BYE ELSE it retransmits the send request with an alternative value in the 'ses-timer' header which falls into the range. There probably should be a limit on the number of times the client retries to avoid DOS attacks. =20 >Thanks! > >Ben. > > > > >_______________________________________________ >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 Sep 10 11:42: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 LAA05401; Wed, 10 Sep 2003 11:42:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19x76c-0004xA-00; Wed, 10 Sep 2003 11:42:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19x76b-0004x4-00; Wed, 10 Sep 2003 11:42:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19x76X-000156-9F; Wed, 10 Sep 2003 11:42:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19x76B-00014U-G6 for simple@optimus.ietf.org; Wed, 10 Sep 2003 11:41: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 LAA05357 for ; Wed, 10 Sep 2003 11:41:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19x76A-0004w0-00 for simple@ietf.org; Wed, 10 Sep 2003 11:41:38 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19x769-0004vd-00 for simple@ietf.org; Wed, 10 Sep 2003 11:41:37 -0400 Received: from dynamicsoft.com (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h8AFetd20086; Wed, 10 Sep 2003 10:40:55 -0500 Message-ID: <3F5F45FE.6060508@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030723 Thunderbird/0.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chris Boulton CC: "Miguel A. Garcia" , simple@ietf.org Subject: Re: [Simple] Default 1 minute inactivity timer in MSRP References: <45730E094814E44488F789C1CDED27AE0219B09E@gbnewp0758m.eu.ubiquity.net> In-Reply-To: <45730E094814E44488F789C1CDED27AE0219B09E@gbnewp0758m.eu.ubiquity.net> X-Enigmail-Version: 0.81.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.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, 10 Sep 2003 10:40:46 -0500 Content-Transfer-Encoding: 7bit This appears to be an e2e negotiation that would work fine if the endpoints are the only stakeholders. However, I think that any relays would want a say in this as well. In order to do that, we would need to negotiate someting in the BIND request. That value could be sent to the visitor in the sdp, or as the return code from the visit request. It gets more complicated if you have 2 relays, that _each_ want to select a value. That could work something like the following: 1) Host proposes a value in a BIND request. 2) Hosting relay selects a value less than or equal to the proposed value. 3) (optional) Host communicates value to visitor in SDP 4) Visitor proposes a value in the VISIT request. (If we used step 3, we might say this must be equal or less than the value in the sdp) 5) Visiting relay forwards request to hosting relay. It MAY reduce the value if it chooses. (I expect objections to having the relay modify the request. I admit it makes me nervous.) 6) Hosting relay puts final value in VISIT response. Visiting relay and visiting endpoint set timers based on this value. It was after we had worked through an example similar to this that the people at the interim meeting chose to punt on making this negotiable. I personally have no strong opinion on the matter, and was working based on group consensus. If that consensus is not real, I am happy to change it--but I think we need substantial evidence of that before we change things at this point. Chris Boulton wrote: > <> > >>So, this brings up a couple of questions for the list in general: >> >>1) Do others agree with Miguel that we should make the inactivity >>timeout negotiable? > > > [Chris Boulton] I must admit that I do have reservations regarding a one > minute session timer. Yes, this may only produce a minimal amount of > extra chargeable bytes BUT it does indicate a slight deficiency in the > solution. > > >>2) If not, can anyone suggest a better way to choose the standard > > value? > > [Chris Boulton] As mentioned earlier, negotiation maybe increase > complexity BUT I will throw this into the pot as a potential solution. > On receiving the 200 OK to the SIP INVITE the initiator of the session > will send a SIP ACK - It will also send an MSRP SEND which contains a > new header 'sess-timer' (*Note - it can use this header at any time > during the session). This new header has a default value so that if > this method is not used, the default will apply (e.g. 1 minute). On > receiving the SEND (whether it be at the start of the session or mid > session), the receiving MSRP client can either respond positively to the > MSRP SEND request, indicating that it accepts the timer OR it rejects > with a new MSRP error response code. The new response code will > indicate the range of seconds that the client is willing to accept (max > + min values in a header). If the initiator does not like this range it > terminates the session, sending a SIP BYE ELSE it retransmits the send > request with an alternative value in the 'ses-timer' header which falls > into the range. There probably should be a limit on the number of times > the client retries to avoid DOS attacks. > > >>Thanks! >> >>Ben. >> >> >> >> >>_______________________________________________ >>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 Sep 10 11:42:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05436 for ; Wed, 10 Sep 2003 11:42:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19x76d-000162-Ue for simple-archive@odin.ietf.org; Wed, 10 Sep 2003 11:42:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8AFg7nM004208 for simple-archive@odin.ietf.org; Wed, 10 Sep 2003 11:42:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19x76d-00015n-RI for simple-web-archive@optimus.ietf.org; Wed, 10 Sep 2003 11:42: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 LAA05401; Wed, 10 Sep 2003 11:42:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19x76c-0004xA-00; Wed, 10 Sep 2003 11:42:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19x76b-0004x4-00; Wed, 10 Sep 2003 11:42:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19x76X-000156-9F; Wed, 10 Sep 2003 11:42:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19x76B-00014U-G6 for simple@optimus.ietf.org; Wed, 10 Sep 2003 11:41: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 LAA05357 for ; Wed, 10 Sep 2003 11:41:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19x76A-0004w0-00 for simple@ietf.org; Wed, 10 Sep 2003 11:41:38 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19x769-0004vd-00 for simple@ietf.org; Wed, 10 Sep 2003 11:41:37 -0400 Received: from dynamicsoft.com (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h8AFetd20086; Wed, 10 Sep 2003 10:40:55 -0500 Message-ID: <3F5F45FE.6060508@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030723 Thunderbird/0.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chris Boulton CC: "Miguel A. Garcia" , simple@ietf.org Subject: Re: [Simple] Default 1 minute inactivity timer in MSRP References: <45730E094814E44488F789C1CDED27AE0219B09E@gbnewp0758m.eu.ubiquity.net> In-Reply-To: <45730E094814E44488F789C1CDED27AE0219B09E@gbnewp0758m.eu.ubiquity.net> X-Enigmail-Version: 0.81.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.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, 10 Sep 2003 10:40:46 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit This appears to be an e2e negotiation that would work fine if the endpoints are the only stakeholders. However, I think that any relays would want a say in this as well. In order to do that, we would need to negotiate someting in the BIND request. That value could be sent to the visitor in the sdp, or as the return code from the visit request. It gets more complicated if you have 2 relays, that _each_ want to select a value. That could work something like the following: 1) Host proposes a value in a BIND request. 2) Hosting relay selects a value less than or equal to the proposed value. 3) (optional) Host communicates value to visitor in SDP 4) Visitor proposes a value in the VISIT request. (If we used step 3, we might say this must be equal or less than the value in the sdp) 5) Visiting relay forwards request to hosting relay. It MAY reduce the value if it chooses. (I expect objections to having the relay modify the request. I admit it makes me nervous.) 6) Hosting relay puts final value in VISIT response. Visiting relay and visiting endpoint set timers based on this value. It was after we had worked through an example similar to this that the people at the interim meeting chose to punt on making this negotiable. I personally have no strong opinion on the matter, and was working based on group consensus. If that consensus is not real, I am happy to change it--but I think we need substantial evidence of that before we change things at this point. Chris Boulton wrote: > <> > >>So, this brings up a couple of questions for the list in general: >> >>1) Do others agree with Miguel that we should make the inactivity >>timeout negotiable? > > > [Chris Boulton] I must admit that I do have reservations regarding a one > minute session timer. Yes, this may only produce a minimal amount of > extra chargeable bytes BUT it does indicate a slight deficiency in the > solution. > > >>2) If not, can anyone suggest a better way to choose the standard > > value? > > [Chris Boulton] As mentioned earlier, negotiation maybe increase > complexity BUT I will throw this into the pot as a potential solution. > On receiving the 200 OK to the SIP INVITE the initiator of the session > will send a SIP ACK - It will also send an MSRP SEND which contains a > new header 'sess-timer' (*Note - it can use this header at any time > during the session). This new header has a default value so that if > this method is not used, the default will apply (e.g. 1 minute). On > receiving the SEND (whether it be at the start of the session or mid > session), the receiving MSRP client can either respond positively to the > MSRP SEND request, indicating that it accepts the timer OR it rejects > with a new MSRP error response code. The new response code will > indicate the range of seconds that the client is willing to accept (max > + min values in a header). If the initiator does not like this range it > terminates the session, sending a SIP BYE ELSE it retransmits the send > request with an alternative value in the 'ses-timer' header which falls > into the range. There probably should be a limit on the number of times > the client retries to avoid DOS attacks. > > >>Thanks! >> >>Ben. >> >> >> >> >>_______________________________________________ >>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 Sep 10 15:18: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 PAA14413; Wed, 10 Sep 2003 15:18:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xATf-0002ZR-00; Wed, 10 Sep 2003 15:18:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19xATf-0002ZO-00; Wed, 10 Sep 2003 15:18:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xATZ-0001vV-Cb; Wed, 10 Sep 2003 15:18:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xATN-0001uF-BO for simple@optimus.ietf.org; Wed, 10 Sep 2003 15:17: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 PAA14395 for ; Wed, 10 Sep 2003 15:17:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xATM-0002XY-00 for simple@ietf.org; Wed, 10 Sep 2003 15:17:48 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19xATL-0002UZ-00 for simple@ietf.org; Wed, 10 Sep 2003 15:17:47 -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 h8AJHEd23414; Wed, 10 Sep 2003 14:17:14 -0500 From: Robert Sparks To: simple@ietf.org, sip-implementors@cs.columbia.edu Content-Type: text/plain Message-Id: <1063221430.882.190.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] SIMPLEt 2 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 10 Sep 2003 14:17:10 -0500 Content-Transfer-Encoding: 7bit As requested at the last SIPIT, we're going to hold a second SIMPLEt before SIPIT 14. Jasomi Networks has graciously agreed to host this event again. It will be in the same venue as SIMPLEt 1: the Banff Springs Hotel. The event will take place December 3-5, 2003. I'll send another note when the registration/information website goes online (in about a week). If you have questions before then, please send them to me. See you there! RjS _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Sep 10 15:18: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 PAA14441 for ; Wed, 10 Sep 2003 15:18: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 19xATi-0001xK-7U for simple-archive@odin.ietf.org; Wed, 10 Sep 2003 15:18:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8AJIAaH007507 for simple-archive@odin.ietf.org; Wed, 10 Sep 2003 15:18:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xATh-0001wz-Tj for simple-web-archive@optimus.ietf.org; Wed, 10 Sep 2003 15:18: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 PAA14413; Wed, 10 Sep 2003 15:18:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xATf-0002ZR-00; Wed, 10 Sep 2003 15:18:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19xATf-0002ZO-00; Wed, 10 Sep 2003 15:18:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xATZ-0001vV-Cb; Wed, 10 Sep 2003 15:18:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xATN-0001uF-BO for simple@optimus.ietf.org; Wed, 10 Sep 2003 15:17: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 PAA14395 for ; Wed, 10 Sep 2003 15:17:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xATM-0002XY-00 for simple@ietf.org; Wed, 10 Sep 2003 15:17:48 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19xATL-0002UZ-00 for simple@ietf.org; Wed, 10 Sep 2003 15:17:47 -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 h8AJHEd23414; Wed, 10 Sep 2003 14:17:14 -0500 From: Robert Sparks To: simple@ietf.org, sip-implementors@cs.columbia.edu Content-Type: text/plain Message-Id: <1063221430.882.190.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] SIMPLEt 2 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 10 Sep 2003 14:17:10 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit As requested at the last SIPIT, we're going to hold a second SIMPLEt before SIPIT 14. Jasomi Networks has graciously agreed to host this event again. It will be in the same venue as SIMPLEt 1: the Banff Springs Hotel. The event will take place December 3-5, 2003. I'll send another note when the registration/information website goes online (in about a week). If you have questions before then, please send them to me. See you there! RjS _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Sep 11 05:45:58 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16521; Thu, 11 Sep 2003 05:45:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xO1a-0007P1-00; Thu, 11 Sep 2003 05:46:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19xO1Z-0007Ow-00; Thu, 11 Sep 2003 05:46:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xO1Y-0007mv-NL; Thu, 11 Sep 2003 05:46:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xO1M-0007mV-Mk for simple@optimus.ietf.org; Thu, 11 Sep 2003 05:45: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 FAA16510 for ; Thu, 11 Sep 2003 05:45:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xO1J-0007On-00 for simple@ietf.org; Thu, 11 Sep 2003 05:45:45 -0400 Received: from news.ubiquity.net ([194.202.146.92] helo=gbnewp0186s1.eu.ubiquity.net) by ietf-mx with smtp (Exim 4.12) id 19xO1I-0007Ok-00 for simple@ietf.org; Thu, 11 Sep 2003 05:45: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; Thu, 11 Sep 2003 10:48:28 +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] Default 1 minute inactivity timer in MSRP Message-ID: <45730E094814E44488F789C1CDED27AE0219B0A2@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [Simple] Default 1 minute inactivity timer in MSRP Thread-Index: AcN3seE1jJ9MzhjaQk6sY2aYk87nAwAliY+g From: "Chris Boulton" To: "Ben Campbell" 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, 11 Sep 2003 10:45:21 +0100 Content-Transfer-Encoding: quoted-printable <> >-----Original Message----- >From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] >Sent: 10 September 2003 16:41 >To: Chris Boulton >Cc: Miguel A. Garcia; simple@ietf.org >Subject: Re: [Simple] Default 1 minute inactivity timer in MSRP > >This appears to be an e2e negotiation that would work fine if the >endpoints are the only stakeholders. However, I think that any relays >would want a say in this as well. In order to do that, we would need to >negotiate someting in the BIND request. That value could be sent to the >visitor in the sdp, or as the return code from the visit request. [Chris Boulton] Ben, I might be missing something here so feel free to SHOUT. I personally don't see why relays should be a stakeholder in a predominantly e2e solution. The only reason for the introduction of relays was to overcome the case where clients could not connect TCP sockets. As it stands, the client currently is responsible for refreshing + terminating state using BIND requests at a relay unless the 'Exp' header expires. I don't see anything wrong with allowing the end client to be responsible, as I proposed. If an implementer wishes to restrict a MAX time that a state can be alive at a relay, then it could introduce a local policy to terminate once the threshold is reached THEN respond with a 481 response.=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Sep 11 05:46: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 FAA16558 for ; Thu, 11 Sep 2003 05:46:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xO1e-0007oC-9H for simple-archive@odin.ietf.org; Thu, 11 Sep 2003 05:46:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8B9k6PF030012 for simple-archive@odin.ietf.org; Thu, 11 Sep 2003 05:46:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xO1e-0007nz-4d for simple-web-archive@optimus.ietf.org; Thu, 11 Sep 2003 05:46: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 FAA16521; Thu, 11 Sep 2003 05:45:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xO1a-0007P1-00; Thu, 11 Sep 2003 05:46:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19xO1Z-0007Ow-00; Thu, 11 Sep 2003 05:46:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xO1Y-0007mv-NL; Thu, 11 Sep 2003 05:46:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xO1M-0007mV-Mk for simple@optimus.ietf.org; Thu, 11 Sep 2003 05:45: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 FAA16510 for ; Thu, 11 Sep 2003 05:45:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xO1J-0007On-00 for simple@ietf.org; Thu, 11 Sep 2003 05:45:45 -0400 Received: from news.ubiquity.net ([194.202.146.92] helo=gbnewp0186s1.eu.ubiquity.net) by ietf-mx with smtp (Exim 4.12) id 19xO1I-0007Ok-00 for simple@ietf.org; Thu, 11 Sep 2003 05:45: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; Thu, 11 Sep 2003 10:48:28 +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] Default 1 minute inactivity timer in MSRP Message-ID: <45730E094814E44488F789C1CDED27AE0219B0A2@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [Simple] Default 1 minute inactivity timer in MSRP Thread-Index: AcN3seE1jJ9MzhjaQk6sY2aYk87nAwAliY+g From: "Chris Boulton" To: "Ben Campbell" 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, 11 Sep 2003 10:45:21 +0100 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable <> >-----Original Message----- >From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] >Sent: 10 September 2003 16:41 >To: Chris Boulton >Cc: Miguel A. Garcia; simple@ietf.org >Subject: Re: [Simple] Default 1 minute inactivity timer in MSRP > >This appears to be an e2e negotiation that would work fine if the >endpoints are the only stakeholders. However, I think that any relays >would want a say in this as well. In order to do that, we would need to >negotiate someting in the BIND request. That value could be sent to the >visitor in the sdp, or as the return code from the visit request. [Chris Boulton] Ben, I might be missing something here so feel free to SHOUT. I personally don't see why relays should be a stakeholder in a predominantly e2e solution. The only reason for the introduction of relays was to overcome the case where clients could not connect TCP sockets. As it stands, the client currently is responsible for refreshing + terminating state using BIND requests at a relay unless the 'Exp' header expires. I don't see anything wrong with allowing the end client to be responsible, as I proposed. If an implementer wishes to restrict a MAX time that a state can be alive at a relay, then it could introduce a local policy to terminate once the threshold is reached THEN respond with a 481 response.=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Sep 11 09:56: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 JAA22851; Thu, 11 Sep 2003 09:56:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xRve-0001WQ-00; Thu, 11 Sep 2003 09:56:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19xRvY-0001WN-00; Thu, 11 Sep 2003 09:56:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xRvV-0007Re-9W; Thu, 11 Sep 2003 09:56:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xRvM-0007RP-8q for simple@optimus.ietf.org; Thu, 11 Sep 2003 09:55: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 JAA22845 for ; Thu, 11 Sep 2003 09:55:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xRvK-0001WF-00 for simple@ietf.org; Thu, 11 Sep 2003 09:55:50 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 19xRv9-0001W9-00 for simple@ietf.org; Thu, 11 Sep 2003 09:55:39 -0400 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id h8BDtCVW029868; Thu, 11 Sep 2003 08:55:15 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3F607EB5.5000303@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030723 Thunderbird/0.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chris Boulton CC: "Miguel A. Garcia" , simple@ietf.org Subject: Re: [Simple] Default 1 minute inactivity timer in MSRP References: <45730E094814E44488F789C1CDED27AE0219B0A2@gbnewp0758m.eu.ubiquity.net> In-Reply-To: <45730E094814E44488F789C1CDED27AE0219B0A2@gbnewp0758m.eu.ubiquity.net> X-Enigmail-Version: 0.81.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.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, 11 Sep 2003 08:55:01 -0500 Content-Transfer-Encoding: 7bit Chris Boulton wrote: > <> > >>-----Original Message----- >>From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] >>Sent: 10 September 2003 16:41 >>To: Chris Boulton >>Cc: Miguel A. Garcia; simple@ietf.org >>Subject: Re: [Simple] Default 1 minute inactivity timer in MSRP >> >>This appears to be an e2e negotiation that would work fine if the >>endpoints are the only stakeholders. However, I think that any relays >>would want a say in this as well. In order to do that, we would need to >>negotiate someting in the BIND request. That value could be sent to the >>visitor in the sdp, or as the return code from the visit request. > > > [Chris Boulton] Ben, I might be missing something here so feel free to > SHOUT. I personally don't see why relays should be a stakeholder in a > predominantly e2e solution. The only reason for the introduction of > relays was to overcome the case where clients could not connect TCP > sockets. Obviously, the relay is not a stakeholder in an e2e case, where it does not exist :-) But any existing relay is going to consume resources for each open session. This includes TCP connections, space in a state table, etc. This gives it a definite interest in managing session lifetimes. Considering that a relay is probably handling many more sessions than any given endpoint, one can argue that it has an even greater interest. As it stands, the client currently is responsible for > refreshing + terminating state using BIND requests at a relay unless the > 'Exp' header expires. I don't see anything wrong with allowing the end > client to be responsible, as I proposed. If an implementer wishes to > restrict a MAX time that a state can be alive at a relay, then it could > introduce a local policy to terminate once the threshold is reached THEN > respond with a 481 response. Keep in mind, in the current draft version, we no longer have a concept of refreshing state using BIND requests. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Sep 11 09:56:37 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 JAA22874 for ; Thu, 11 Sep 2003 09:56:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xRvg-0007SN-P9 for simple-archive@odin.ietf.org; Thu, 11 Sep 2003 09:56:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8BDuCDI028660 for simple-archive@odin.ietf.org; Thu, 11 Sep 2003 09:56:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xRvg-0007SB-KC for simple-web-archive@optimus.ietf.org; Thu, 11 Sep 2003 09:56: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 JAA22851; Thu, 11 Sep 2003 09:56:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xRve-0001WQ-00; Thu, 11 Sep 2003 09:56:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19xRvY-0001WN-00; Thu, 11 Sep 2003 09:56:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xRvV-0007Re-9W; Thu, 11 Sep 2003 09:56:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xRvM-0007RP-8q for simple@optimus.ietf.org; Thu, 11 Sep 2003 09:55: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 JAA22845 for ; Thu, 11 Sep 2003 09:55:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xRvK-0001WF-00 for simple@ietf.org; Thu, 11 Sep 2003 09:55:50 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 19xRv9-0001W9-00 for simple@ietf.org; Thu, 11 Sep 2003 09:55:39 -0400 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id h8BDtCVW029868; Thu, 11 Sep 2003 08:55:15 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3F607EB5.5000303@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030723 Thunderbird/0.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chris Boulton CC: "Miguel A. Garcia" , simple@ietf.org Subject: Re: [Simple] Default 1 minute inactivity timer in MSRP References: <45730E094814E44488F789C1CDED27AE0219B0A2@gbnewp0758m.eu.ubiquity.net> In-Reply-To: <45730E094814E44488F789C1CDED27AE0219B0A2@gbnewp0758m.eu.ubiquity.net> X-Enigmail-Version: 0.81.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.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, 11 Sep 2003 08:55:01 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Chris Boulton wrote: > <> > >>-----Original Message----- >>From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] >>Sent: 10 September 2003 16:41 >>To: Chris Boulton >>Cc: Miguel A. Garcia; simple@ietf.org >>Subject: Re: [Simple] Default 1 minute inactivity timer in MSRP >> >>This appears to be an e2e negotiation that would work fine if the >>endpoints are the only stakeholders. However, I think that any relays >>would want a say in this as well. In order to do that, we would need to >>negotiate someting in the BIND request. That value could be sent to the >>visitor in the sdp, or as the return code from the visit request. > > > [Chris Boulton] Ben, I might be missing something here so feel free to > SHOUT. I personally don't see why relays should be a stakeholder in a > predominantly e2e solution. The only reason for the introduction of > relays was to overcome the case where clients could not connect TCP > sockets. Obviously, the relay is not a stakeholder in an e2e case, where it does not exist :-) But any existing relay is going to consume resources for each open session. This includes TCP connections, space in a state table, etc. This gives it a definite interest in managing session lifetimes. Considering that a relay is probably handling many more sessions than any given endpoint, one can argue that it has an even greater interest. As it stands, the client currently is responsible for > refreshing + terminating state using BIND requests at a relay unless the > 'Exp' header expires. I don't see anything wrong with allowing the end > client to be responsible, as I proposed. If an implementer wishes to > restrict a MAX time that a state can be alive at a relay, then it could > introduce a local policy to terminate once the threshold is reached THEN > respond with a 481 response. Keep in mind, in the current draft version, we no longer have a concept of refreshing state using BIND requests. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Sep 11 12:32:58 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00112; Thu, 11 Sep 2003 12:32:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xUNT-00037K-00; Thu, 11 Sep 2003 12:33:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19xUNT-00037F-00; Thu, 11 Sep 2003 12:33:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xUNR-00061P-D5; Thu, 11 Sep 2003 12:33:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xUMm-0005zt-9f for simple@optimus.ietf.org; Thu, 11 Sep 2003 12:32: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 MAA00085 for ; Thu, 11 Sep 2003 12:32:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xUMk-00036u-00 for simple@ietf.org; Thu, 11 Sep 2003 12:32:18 -0400 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 19xUMk-00036g-00 for simple@ietf.org; Thu, 11 Sep 2003 12:32:18 -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 h8BGVaLb027760; Thu, 11 Sep 2003 12:31:36 -0400 (EDT) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Thu, 11 Sep 2003 11:31:37 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E86434@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: Ben Campbell , "Miguel A. Garcia" Cc: simple@ietf.org Subject: RE: [Simple] Default 1 minute inactivity timer in MSRP 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, 11 Sep 2003 11:31:35 -0500 Ben Campbell [mailto:bcampbell@dynamicsoft.com] writes: > 1) Do others agree with Miguel that we should make the inactivity > timeout negotiable? Having tried to go down this path several times, I want to emphasize that I am very strongly opposed to any mechanism for negotiation of this timeout. > 2) If not, can anyone suggest a better way to choose the > standard value? Nope. One minute sounds good. One hour sounds good. I don't think I'd want to go much outside that range. However, it sounds like there's some objection to something as small as one minute, so we need to negotiate an arbitrary value here on the list. I'll start the bidding at twelve minutes. /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Sep 11 12:33:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00143 for ; Thu, 11 Sep 2003 12:33:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xUNV-00062G-IJ for simple-archive@odin.ietf.org; Thu, 11 Sep 2003 12:33:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8BGX5tU023194 for simple-archive@odin.ietf.org; Thu, 11 Sep 2003 12:33:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xUNV-000621-Dg for simple-web-archive@optimus.ietf.org; Thu, 11 Sep 2003 12:33: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 MAA00112; Thu, 11 Sep 2003 12:32:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xUNT-00037K-00; Thu, 11 Sep 2003 12:33:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19xUNT-00037F-00; Thu, 11 Sep 2003 12:33:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xUNR-00061P-D5; Thu, 11 Sep 2003 12:33:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xUMm-0005zt-9f for simple@optimus.ietf.org; Thu, 11 Sep 2003 12:32: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 MAA00085 for ; Thu, 11 Sep 2003 12:32:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xUMk-00036u-00 for simple@ietf.org; Thu, 11 Sep 2003 12:32:18 -0400 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 19xUMk-00036g-00 for simple@ietf.org; Thu, 11 Sep 2003 12:32:18 -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 h8BGVaLb027760; Thu, 11 Sep 2003 12:31:36 -0400 (EDT) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Thu, 11 Sep 2003 11:31:37 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E86434@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: Ben Campbell , "Miguel A. Garcia" Cc: simple@ietf.org Subject: RE: [Simple] Default 1 minute inactivity timer in MSRP 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, 11 Sep 2003 11:31:35 -0500 Ben Campbell [mailto:bcampbell@dynamicsoft.com] writes: > 1) Do others agree with Miguel that we should make the inactivity > timeout negotiable? Having tried to go down this path several times, I want to emphasize that I am very strongly opposed to any mechanism for negotiation of this timeout. > 2) If not, can anyone suggest a better way to choose the > standard value? Nope. One minute sounds good. One hour sounds good. I don't think I'd want to go much outside that range. However, it sounds like there's some objection to something as small as one minute, so we need to negotiate an arbitrary value here on the list. I'll start the bidding at twelve minutes. /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Sep 11 13:17:59 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01931; Thu, 11 Sep 2003 13:17:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xV52-0003Zk-00; Thu, 11 Sep 2003 13:18:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19xV52-0003Zh-00; Thu, 11 Sep 2003 13: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 19xV4z-0007fa-60; Thu, 11 Sep 2003 13:18:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xV4M-0007es-MK for simple@optimus.ietf.org; Thu, 11 Sep 2003 13:17: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 NAA01918 for ; Thu, 11 Sep 2003 13:17:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xV4K-0003ZM-00 for simple@ietf.org; Thu, 11 Sep 2003 13:17:20 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 19xV4K-0003ZJ-00 for simple@ietf.org; Thu, 11 Sep 2003 13:17:20 -0400 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id h8BHGhVW046080; Thu, 11 Sep 2003 12:16:56 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3F60ADEF.9070204@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030723 Thunderbird/0.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adam Roach CC: "Miguel A. Garcia" , simple@ietf.org Subject: Re: [Simple] Default 1 minute inactivity timer in MSRP References: <9BF66EBF6BEFD942915B4D4D45C051F3E86434@dyn-tx-exch-001.dynamicsoft.com> In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3E86434@dyn-tx-exch-001.dynamicsoft.com> X-Enigmail-Version: 0.81.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.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, 11 Sep 2003 12:16:31 -0500 Content-Transfer-Encoding: 7bit On reflection, I think I agree that a higher value than 1 minute makes sense. One use case I expect to see a lot for message sessions is the chat room, or text conference, where it will be common for one participant to receive a lot more than they send. Of course, at the same time, larger numbers reduce the ability of a relay to prune dead sessions. So I bid 5 minutes. Adam Roach wrote: > Ben Campbell [mailto:bcampbell@dynamicsoft.com] writes: > > >>1) Do others agree with Miguel that we should make the inactivity >>timeout negotiable? > > > Having tried to go down this path several times, I want to > emphasize that I am very strongly opposed to any mechanism > for negotiation of this timeout. > > >>2) If not, can anyone suggest a better way to choose the >>standard value? > > > Nope. One minute sounds good. One hour sounds good. I don't > think I'd want to go much outside that range. > > However, it sounds like there's some objection to something > as small as one minute, so we need to negotiate an arbitrary > value here on the list. I'll start the bidding at twelve > minutes. > > /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Sep 11 13:18: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 NAA01952 for ; Thu, 11 Sep 2003 13:18: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 19xV55-0007gP-4F for simple-archive@odin.ietf.org; Thu, 11 Sep 2003 13:18:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8BHI7Ji029527 for simple-archive@odin.ietf.org; Thu, 11 Sep 2003 13:18:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xV54-0007gA-U9 for simple-web-archive@optimus.ietf.org; Thu, 11 Sep 2003 13:18: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 NAA01931; Thu, 11 Sep 2003 13:17:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xV52-0003Zk-00; Thu, 11 Sep 2003 13:18:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19xV52-0003Zh-00; Thu, 11 Sep 2003 13: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 19xV4z-0007fa-60; Thu, 11 Sep 2003 13:18:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xV4M-0007es-MK for simple@optimus.ietf.org; Thu, 11 Sep 2003 13:17: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 NAA01918 for ; Thu, 11 Sep 2003 13:17:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xV4K-0003ZM-00 for simple@ietf.org; Thu, 11 Sep 2003 13:17:20 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 19xV4K-0003ZJ-00 for simple@ietf.org; Thu, 11 Sep 2003 13:17:20 -0400 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id h8BHGhVW046080; Thu, 11 Sep 2003 12:16:56 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3F60ADEF.9070204@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030723 Thunderbird/0.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adam Roach CC: "Miguel A. Garcia" , simple@ietf.org Subject: Re: [Simple] Default 1 minute inactivity timer in MSRP References: <9BF66EBF6BEFD942915B4D4D45C051F3E86434@dyn-tx-exch-001.dynamicsoft.com> In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3E86434@dyn-tx-exch-001.dynamicsoft.com> X-Enigmail-Version: 0.81.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.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, 11 Sep 2003 12:16:31 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On reflection, I think I agree that a higher value than 1 minute makes sense. One use case I expect to see a lot for message sessions is the chat room, or text conference, where it will be common for one participant to receive a lot more than they send. Of course, at the same time, larger numbers reduce the ability of a relay to prune dead sessions. So I bid 5 minutes. Adam Roach wrote: > Ben Campbell [mailto:bcampbell@dynamicsoft.com] writes: > > >>1) Do others agree with Miguel that we should make the inactivity >>timeout negotiable? > > > Having tried to go down this path several times, I want to > emphasize that I am very strongly opposed to any mechanism > for negotiation of this timeout. > > >>2) If not, can anyone suggest a better way to choose the >>standard value? > > > Nope. One minute sounds good. One hour sounds good. I don't > think I'd want to go much outside that range. > > However, it sounds like there's some objection to something > as small as one minute, so we need to negotiate an arbitrary > value here on the list. I'll start the bidding at twelve > minutes. > > /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Sep 11 14:09: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 OAA03596; Thu, 11 Sep 2003 14:09:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xVsN-0003xo-00; Thu, 11 Sep 2003 14:09:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19xVsN-0003xl-00; Thu, 11 Sep 2003 14:09:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xVsL-0000ke-IA; Thu, 11 Sep 2003 14: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 19xVsF-0000kT-2Y for simple@optimus.ietf.org; Thu, 11 Sep 2003 14:08: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 OAA03592 for ; Thu, 11 Sep 2003 14:08:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xVsC-0003xh-00 for simple@ietf.org; Thu, 11 Sep 2003 14:08:52 -0400 Received: from news.ubiquity.net ([194.202.146.92] helo=gbnewp0186s1.eu.ubiquity.net) by ietf-mx with smtp (Exim 4.12) id 19xVsC-0003xe-00 for simple@ietf.org; Thu, 11 Sep 2003 14:08:52 -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, 11 Sep 2003 19:11:34 +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="utf-8" Content-Transfer-Encoding: base64 Subject: RE: [Simple] Default 1 minute inactivity timer in MSRP Message-ID: <45730E094814E44488F789C1CDED27AE0219B0A7@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [Simple] Default 1 minute inactivity timer in MSRP Thread-Index: AcN4iJtuOmrU1UuaRS+kcDoRG2G0VwABnwI8 From: "Chris Boulton" To: "Ben Campbell" , "Adam Roach" Cc: "Miguel A. Garcia" , Content-Transfer-Encoding: base64 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.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, 11 Sep 2003 19:08:25 +0100 Content-Transfer-Encoding: base64 b2sgLSBJZiBpdCBtdXN0IGJlIGhpcyBtZXRob2QgSSdsbCBzZWUgQWRhbXMgYmlkIG9mIDEyIChh bmQgbWF5YmUgZXZlbiByYWlzZSBpdCA7LSkgLiAgSSB0aGluayB0aGF0IGl0IGlzIGEgZ29vZCBj b21wcm9taXNlIG9mIHRyYWZmaWMgdnMgc2Vzc2lvbiBjbGVhbiB1cC4NCiANCkNocmlzLg0KIA0K DQoJLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0gDQoJRnJvbTogQmVuIENhbXBiZWxsIFttYWls dG86YmNhbXBiZWxsQGR5bmFtaWNzb2Z0LmNvbV0gDQoJU2VudDogVGh1IDExLzA5LzIwMDMgMTg6 MTYgDQoJVG86IEFkYW0gUm9hY2ggDQoJQ2M6IE1pZ3VlbCBBLiBHYXJjaWE7IHNpbXBsZUBpZXRm Lm9yZyANCglTdWJqZWN0OiBSZTogW1NpbXBsZV0gRGVmYXVsdCAxIG1pbnV0ZSBpbmFjdGl2aXR5 IHRpbWVyIGluIE1TUlANCgkNCgkNCg0KCU9uIHJlZmxlY3Rpb24sIEkgdGhpbmsgSSBhZ3JlZSB0 aGF0IGEgaGlnaGVyIHZhbHVlIHRoYW4gMSBtaW51dGUgbWFrZXMNCglzZW5zZS4gT25lIHVzZSBj YXNlIEkgZXhwZWN0IHRvIHNlZSBhIGxvdCBmb3IgbWVzc2FnZSBzZXNzaW9ucyBpcyB0aGUNCglj aGF0IHJvb20sIG9yIHRleHQgY29uZmVyZW5jZSwgd2hlcmUgaXQgd2lsbCBiZSBjb21tb24gZm9y IG9uZQ0KCXBhcnRpY2lwYW50IHRvIHJlY2VpdmUgYSBsb3QgbW9yZSB0aGFuIHRoZXkgc2VuZC4N CgkNCglPZiBjb3Vyc2UsIGF0IHRoZSBzYW1lIHRpbWUsIGxhcmdlciBudW1iZXJzIHJlZHVjZSB0 aGUgYWJpbGl0eSBvZiBhDQoJcmVsYXkgdG8gcHJ1bmUgZGVhZCBzZXNzaW9ucy4NCgkNCglTbyBJ IGJpZCA1IG1pbnV0ZXMuDQoJDQoJQWRhbSBSb2FjaCB3cm90ZToNCgk+IEJlbiBDYW1wYmVsbCBb bWFpbHRvOmJjYW1wYmVsbEBkeW5hbWljc29mdC5jb21dIHdyaXRlczoNCgk+DQoJPg0KCT4+MSkg RG8gb3RoZXJzIGFncmVlIHdpdGggTWlndWVsIHRoYXQgd2Ugc2hvdWxkIG1ha2UgdGhlIGluYWN0 aXZpdHkNCgk+PnRpbWVvdXQgbmVnb3RpYWJsZT8NCgk+DQoJPg0KCT4gSGF2aW5nIHRyaWVkIHRv IGdvIGRvd24gdGhpcyBwYXRoIHNldmVyYWwgdGltZXMsIEkgd2FudCB0bw0KCT4gZW1waGFzaXpl IHRoYXQgSSBhbSB2ZXJ5IHN0cm9uZ2x5IG9wcG9zZWQgdG8gYW55IG1lY2hhbmlzbQ0KCT4gZm9y IG5lZ290aWF0aW9uIG9mIHRoaXMgdGltZW91dC4NCgk+DQoJPg0KCT4+MikgSWYgbm90LCBjYW4g YW55b25lIHN1Z2dlc3QgYSBiZXR0ZXIgd2F5IHRvIGNob29zZSB0aGUNCgk+PnN0YW5kYXJkIHZh bHVlPw0KCT4NCgk+DQoJPiBOb3BlLiBPbmUgbWludXRlIHNvdW5kcyBnb29kLiBPbmUgaG91ciBz b3VuZHMgZ29vZC4gSSBkb24ndA0KCT4gdGhpbmsgSSdkIHdhbnQgdG8gZ28gbXVjaCBvdXRzaWRl IHRoYXQgcmFuZ2UuDQoJPg0KCT4gSG93ZXZlciwgaXQgc291bmRzIGxpa2UgdGhlcmUncyBzb21l IG9iamVjdGlvbiB0byBzb21ldGhpbmcNCgk+IGFzIHNtYWxsIGFzIG9uZSBtaW51dGUsIHNvIHdl IG5lZWQgdG8gbmVnb3RpYXRlIGFuIGFyYml0cmFyeQ0KCT4gdmFsdWUgaGVyZSBvbiB0aGUgbGlz dC4gSSdsbCBzdGFydCB0aGUgYmlkZGluZyBhdCB0d2VsdmUNCgk+IG1pbnV0ZXMuDQoJPg0KCT4g L2ENCgkNCgkNCglfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KCVNpbXBsZSBtYWlsaW5nIGxpc3QNCglTaW1wbGVAaWV0Zi5vcmcNCglodHRwczovL3d3dzEu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaW1wbGUNCgkNCg0K _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Sep 11 14:09:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03616 for ; Thu, 11 Sep 2003 14:09:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xVsQ-0000lT-P8 for simple-archive@odin.ietf.org; Thu, 11 Sep 2003 14:09:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8BI961I002933 for simple-archive@odin.ietf.org; Thu, 11 Sep 2003 14:09:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xVsQ-0000lE-Lz for simple-web-archive@optimus.ietf.org; Thu, 11 Sep 2003 14:09: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 OAA03596; Thu, 11 Sep 2003 14:09:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xVsN-0003xo-00; Thu, 11 Sep 2003 14:09:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19xVsN-0003xl-00; Thu, 11 Sep 2003 14:09:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xVsL-0000ke-IA; Thu, 11 Sep 2003 14: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 19xVsF-0000kT-2Y for simple@optimus.ietf.org; Thu, 11 Sep 2003 14:08: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 OAA03592 for ; Thu, 11 Sep 2003 14:08:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xVsC-0003xh-00 for simple@ietf.org; Thu, 11 Sep 2003 14:08:52 -0400 Received: from news.ubiquity.net ([194.202.146.92] helo=gbnewp0186s1.eu.ubiquity.net) by ietf-mx with smtp (Exim 4.12) id 19xVsC-0003xe-00 for simple@ietf.org; Thu, 11 Sep 2003 14:08:52 -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, 11 Sep 2003 19:11:34 +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="utf-8" Content-Transfer-Encoding: base64 Subject: RE: [Simple] Default 1 minute inactivity timer in MSRP Message-ID: <45730E094814E44488F789C1CDED27AE0219B0A7@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [Simple] Default 1 minute inactivity timer in MSRP Thread-Index: AcN4iJtuOmrU1UuaRS+kcDoRG2G0VwABnwI8 From: "Chris Boulton" To: "Ben Campbell" , "Adam Roach" Cc: "Miguel A. Garcia" , Content-Transfer-Encoding: base64 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.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, 11 Sep 2003 19:08:25 +0100 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 b2sgLSBJZiBpdCBtdXN0IGJlIGhpcyBtZXRob2QgSSdsbCBzZWUgQWRhbXMgYmlkIG9mIDEyIChh bmQgbWF5YmUgZXZlbiByYWlzZSBpdCA7LSkgLiAgSSB0aGluayB0aGF0IGl0IGlzIGEgZ29vZCBj b21wcm9taXNlIG9mIHRyYWZmaWMgdnMgc2Vzc2lvbiBjbGVhbiB1cC4NCiANCkNocmlzLg0KIA0K DQoJLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0gDQoJRnJvbTogQmVuIENhbXBiZWxsIFttYWls dG86YmNhbXBiZWxsQGR5bmFtaWNzb2Z0LmNvbV0gDQoJU2VudDogVGh1IDExLzA5LzIwMDMgMTg6 MTYgDQoJVG86IEFkYW0gUm9hY2ggDQoJQ2M6IE1pZ3VlbCBBLiBHYXJjaWE7IHNpbXBsZUBpZXRm Lm9yZyANCglTdWJqZWN0OiBSZTogW1NpbXBsZV0gRGVmYXVsdCAxIG1pbnV0ZSBpbmFjdGl2aXR5 IHRpbWVyIGluIE1TUlANCgkNCgkNCg0KCU9uIHJlZmxlY3Rpb24sIEkgdGhpbmsgSSBhZ3JlZSB0 aGF0IGEgaGlnaGVyIHZhbHVlIHRoYW4gMSBtaW51dGUgbWFrZXMNCglzZW5zZS4gT25lIHVzZSBj YXNlIEkgZXhwZWN0IHRvIHNlZSBhIGxvdCBmb3IgbWVzc2FnZSBzZXNzaW9ucyBpcyB0aGUNCglj aGF0IHJvb20sIG9yIHRleHQgY29uZmVyZW5jZSwgd2hlcmUgaXQgd2lsbCBiZSBjb21tb24gZm9y IG9uZQ0KCXBhcnRpY2lwYW50IHRvIHJlY2VpdmUgYSBsb3QgbW9yZSB0aGFuIHRoZXkgc2VuZC4N CgkNCglPZiBjb3Vyc2UsIGF0IHRoZSBzYW1lIHRpbWUsIGxhcmdlciBudW1iZXJzIHJlZHVjZSB0 aGUgYWJpbGl0eSBvZiBhDQoJcmVsYXkgdG8gcHJ1bmUgZGVhZCBzZXNzaW9ucy4NCgkNCglTbyBJ IGJpZCA1IG1pbnV0ZXMuDQoJDQoJQWRhbSBSb2FjaCB3cm90ZToNCgk+IEJlbiBDYW1wYmVsbCBb bWFpbHRvOmJjYW1wYmVsbEBkeW5hbWljc29mdC5jb21dIHdyaXRlczoNCgk+DQoJPg0KCT4+MSkg RG8gb3RoZXJzIGFncmVlIHdpdGggTWlndWVsIHRoYXQgd2Ugc2hvdWxkIG1ha2UgdGhlIGluYWN0 aXZpdHkNCgk+PnRpbWVvdXQgbmVnb3RpYWJsZT8NCgk+DQoJPg0KCT4gSGF2aW5nIHRyaWVkIHRv IGdvIGRvd24gdGhpcyBwYXRoIHNldmVyYWwgdGltZXMsIEkgd2FudCB0bw0KCT4gZW1waGFzaXpl IHRoYXQgSSBhbSB2ZXJ5IHN0cm9uZ2x5IG9wcG9zZWQgdG8gYW55IG1lY2hhbmlzbQ0KCT4gZm9y IG5lZ290aWF0aW9uIG9mIHRoaXMgdGltZW91dC4NCgk+DQoJPg0KCT4+MikgSWYgbm90LCBjYW4g YW55b25lIHN1Z2dlc3QgYSBiZXR0ZXIgd2F5IHRvIGNob29zZSB0aGUNCgk+PnN0YW5kYXJkIHZh bHVlPw0KCT4NCgk+DQoJPiBOb3BlLiBPbmUgbWludXRlIHNvdW5kcyBnb29kLiBPbmUgaG91ciBz b3VuZHMgZ29vZC4gSSBkb24ndA0KCT4gdGhpbmsgSSdkIHdhbnQgdG8gZ28gbXVjaCBvdXRzaWRl IHRoYXQgcmFuZ2UuDQoJPg0KCT4gSG93ZXZlciwgaXQgc291bmRzIGxpa2UgdGhlcmUncyBzb21l IG9iamVjdGlvbiB0byBzb21ldGhpbmcNCgk+IGFzIHNtYWxsIGFzIG9uZSBtaW51dGUsIHNvIHdl IG5lZWQgdG8gbmVnb3RpYXRlIGFuIGFyYml0cmFyeQ0KCT4gdmFsdWUgaGVyZSBvbiB0aGUgbGlz dC4gSSdsbCBzdGFydCB0aGUgYmlkZGluZyBhdCB0d2VsdmUNCgk+IG1pbnV0ZXMuDQoJPg0KCT4g L2ENCgkNCgkNCglfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KCVNpbXBsZSBtYWlsaW5nIGxpc3QNCglTaW1wbGVAaWV0Zi5vcmcNCglodHRwczovL3d3dzEu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaW1wbGUNCgkNCg0K _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Sep 11 14:59:59 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05874; Thu, 11 Sep 2003 14:59:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xWfj-0004Qz-00; Thu, 11 Sep 2003 15:00:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19xWfj-0004Qw-00; Thu, 11 Sep 2003 15:00:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xWfi-00038l-1b; Thu, 11 Sep 2003 15:00:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xWf7-00034B-5S for simple@optimus.ietf.org; Thu, 11 Sep 2003 14:59: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 OAA05821 for ; Thu, 11 Sep 2003 14:59:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xWf4-0004QJ-00 for simple@ietf.org; Thu, 11 Sep 2003 14:59: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 19xWf3-0004Px-00 for simple@ietf.org; Thu, 11 Sep 2003 14:59: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 h8BIwld12781 for ; Thu, 11 Sep 2003 13:58:47 -0500 From: Robert Sparks To: simple@ietf.org Content-Type: multipart/mixed; boundary="=-gECjiyX6h9IPIn5/Oqm0" Message-Id: <1063306723.884.62.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Subject: [Simple] [Fwd: [Sip] I-D ACTION:draft-ietf-sip-publish-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: Thu, 11 Sep 2003 13:58:43 -0500 --=-gECjiyX6h9IPIn5/Oqm0 Content-Type: text/plain Content-Transfer-Encoding: 7bit At the SIMPLE and SIP chairs request, Aki moved the PUBLISH draft into SIP. Any discussion of that draft should now take place on sip@ietf.org. Thanks, RjS -----Forwarded Message----- > From: Internet-Drafts@ietf.org > Cc: sip@ietf.org > Subject: [Sip] I-D ACTION:draft-ietf-sip-publish-00.txt > Date: Thu, 11 Sep 2003 14:50:17 -0400 > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Session Initiation Protocol Working Group of the IETF. > > Title : Session Initiation Protocol (SIP) Extension for Event > State Publication > Author(s) : A. Niemi > Filename : draft-ietf-sip-publish-00.txt > Pages : 32 > Date : 2003-9-11 > > This document describes an extension to the Session Initiation > Protocol (SIP) for publishing event state used within the framework > for SIP Event Notification. The first application of this extension > is targeted at the publication of presence information. > The mechanism described in this document can be extended to support > publication of any event state, for which there exists an appropriate > event package. It is not intended to be a general-purpose mechanism > for transport of arbitrary data, as there are better-suited > mechanisms for this purpose (FTP, HTTP, etc.) > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-sip-publish-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-sip-publish-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-sip-publish-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. > --=-gECjiyX6h9IPIn5/Oqm0 Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2003-9-11123340.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-publish-00.txt --=-gECjiyX6h9IPIn5/Oqm0 Content-Type: Message/External-body; name="draft-ietf-sip-publish-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Transfer-Encoding: 7bit --=-gECjiyX6h9IPIn5/Oqm0-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Sep 11 15:00:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05946 for ; Thu, 11 Sep 2003 15:00:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xWfq-0003B3-9y for simple-archive@odin.ietf.org; Thu, 11 Sep 2003 15:00:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8BJ09fW012200 for simple-archive@odin.ietf.org; Thu, 11 Sep 2003 15:00:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xWfn-0003Ah-U9 for simple-web-archive@optimus.ietf.org; Thu, 11 Sep 2003 15:00: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 OAA05874; Thu, 11 Sep 2003 14:59:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xWfj-0004Qz-00; Thu, 11 Sep 2003 15:00:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19xWfj-0004Qw-00; Thu, 11 Sep 2003 15:00:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xWfi-00038l-1b; Thu, 11 Sep 2003 15:00:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xWf7-00034B-5S for simple@optimus.ietf.org; Thu, 11 Sep 2003 14:59: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 OAA05821 for ; Thu, 11 Sep 2003 14:59:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xWf4-0004QJ-00 for simple@ietf.org; Thu, 11 Sep 2003 14:59: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 19xWf3-0004Px-00 for simple@ietf.org; Thu, 11 Sep 2003 14:59: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 h8BIwld12781 for ; Thu, 11 Sep 2003 13:58:47 -0500 From: Robert Sparks To: simple@ietf.org Content-Type: multipart/mixed; boundary="=-gECjiyX6h9IPIn5/Oqm0" Message-Id: <1063306723.884.62.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Subject: [Simple] [Fwd: [Sip] I-D ACTION:draft-ietf-sip-publish-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: Thu, 11 Sep 2003 13:58:43 -0500 --=-gECjiyX6h9IPIn5/Oqm0 Content-Type: text/plain Content-Transfer-Encoding: 7bit At the SIMPLE and SIP chairs request, Aki moved the PUBLISH draft into SIP. Any discussion of that draft should now take place on sip@ietf.org. Thanks, RjS -----Forwarded Message----- > From: Internet-Drafts@ietf.org > Cc: sip@ietf.org > Subject: [Sip] I-D ACTION:draft-ietf-sip-publish-00.txt > Date: Thu, 11 Sep 2003 14:50:17 -0400 > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Session Initiation Protocol Working Group of the IETF. > > Title : Session Initiation Protocol (SIP) Extension for Event > State Publication > Author(s) : A. Niemi > Filename : draft-ietf-sip-publish-00.txt > Pages : 32 > Date : 2003-9-11 > > This document describes an extension to the Session Initiation > Protocol (SIP) for publishing event state used within the framework > for SIP Event Notification. The first application of this extension > is targeted at the publication of presence information. > The mechanism described in this document can be extended to support > publication of any event state, for which there exists an appropriate > event package. It is not intended to be a general-purpose mechanism > for transport of arbitrary data, as there are better-suited > mechanisms for this purpose (FTP, HTTP, etc.) > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-sip-publish-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-sip-publish-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-sip-publish-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. > --=-gECjiyX6h9IPIn5/Oqm0 Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2003-9-11123340.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-publish-00.txt --=-gECjiyX6h9IPIn5/Oqm0 Content-Type: Message/External-body; name="draft-ietf-sip-publish-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Transfer-Encoding: 7bit --=-gECjiyX6h9IPIn5/Oqm0-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Sep 12 03:15:01 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11409; Fri, 12 Sep 2003 03:15:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xi94-00033M-00; Fri, 12 Sep 2003 03:15:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19xi94-00033J-00; Fri, 12 Sep 2003 03:15:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xi90-0001NA-Kj; Fri, 12 Sep 2003 03:15:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xi8h-0001MT-5N for simple@optimus.ietf.org; Fri, 12 Sep 2003 03:14: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 DAA11386; Fri, 12 Sep 2003 03:14:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xi8e-00032z-00; Fri, 12 Sep 2003 03:14:40 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19xi8e-00032o-00; Fri, 12 Sep 2003 03:14:40 -0400 Received: from dynamicsoft.com ([63.113.46.48]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h8C7E9Ug013709; Fri, 12 Sep 2003 03:14:10 -0400 (EDT) Message-ID: <3F61723B.401@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne CC: hisham.khartabil@nokia.com, geopriv@ietf.org, simple@ietf.org Subject: Re: [Simple] Re: [Geopriv] Individuals, hats and spheres References: <2038BCC78B1AD641891A0D1AE133DBB7017970C3@esebe019.ntc.nokia.com> <3F5F2A59.3050600@cs.columbia.edu> In-Reply-To: <3F5F2A59.3050600@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: Fri, 12 Sep 2003 03:14:03 -0400 Content-Transfer-Encoding: 7bit Facet has also been used already as a concept in the publication work in SIMPLE, and there it had a related function. It allowed a publisher to declare a presence document to be associated to a specific facet, and then specify watchers that were associated with the facet. The result was that different watchers could get different views of the presence data. Thats almost the same thing, but different in that "sphere" is saying something about the state of the presentity, and then use that to determine which information is distributed to different watchers. Indeed, this begs the question of which approach is the desired approach for sphere. If its only use is to define a state which is then used to make authorization decisions at the presence server, there is no need to have any meaning for the value of sphere at all. I could publish a document with: 1 and have corresponding authorization rules which give out different information depending on whether sphere is 1 or 2. Having enumerated values with defined meanings is useful if the information is also published to watchers, and I think that does make sense to do that. I frequently set my yahoo status to "working at home, call cell" to basically convey my "sphere" and the associated contact information for me when I am in that sphere (my cell). If you add a presence status like this, it also makes sense to add corresponding capabilities in the authorization policies, which allow you to say "if presence element X has value Y, please do[n't] distribute presence element Z". XCAP-auth at the moment has no such capability. AS has been pointed out, such a capability would also be useful to make decisions based on other elements besides sphere. Thanks, Jonathan R. Henning Schulzrinne wrote: > Facet, in particular, is being used (in the IETF, by John Klensin's > drafts) in a completely generic way, describing any attribute of a > resource. > > hisham.khartabil@nokia.com wrote: > >> I did suggest Dimension. Also, how about Facet? >> > > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Sep 12 03:15: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 DAA11443 for ; Fri, 12 Sep 2003 03:15: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 19xi97-0001Ok-P0 for simple-archive@odin.ietf.org; Fri, 12 Sep 2003 03:15:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8C7F9Ql005370 for simple-archive@odin.ietf.org; Fri, 12 Sep 2003 03:15:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xi97-0001OX-Ab for simple-web-archive@optimus.ietf.org; Fri, 12 Sep 2003 03:15: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 DAA11409; Fri, 12 Sep 2003 03:15:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xi94-00033M-00; Fri, 12 Sep 2003 03:15:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19xi94-00033J-00; Fri, 12 Sep 2003 03:15:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xi90-0001NA-Kj; Fri, 12 Sep 2003 03:15:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xi8h-0001MT-5N for simple@optimus.ietf.org; Fri, 12 Sep 2003 03:14: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 DAA11386; Fri, 12 Sep 2003 03:14:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xi8e-00032z-00; Fri, 12 Sep 2003 03:14:40 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19xi8e-00032o-00; Fri, 12 Sep 2003 03:14:40 -0400 Received: from dynamicsoft.com ([63.113.46.48]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h8C7E9Ug013709; Fri, 12 Sep 2003 03:14:10 -0400 (EDT) Message-ID: <3F61723B.401@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne CC: hisham.khartabil@nokia.com, geopriv@ietf.org, simple@ietf.org Subject: Re: [Simple] Re: [Geopriv] Individuals, hats and spheres References: <2038BCC78B1AD641891A0D1AE133DBB7017970C3@esebe019.ntc.nokia.com> <3F5F2A59.3050600@cs.columbia.edu> In-Reply-To: <3F5F2A59.3050600@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: Fri, 12 Sep 2003 03:14:03 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Facet has also been used already as a concept in the publication work in SIMPLE, and there it had a related function. It allowed a publisher to declare a presence document to be associated to a specific facet, and then specify watchers that were associated with the facet. The result was that different watchers could get different views of the presence data. Thats almost the same thing, but different in that "sphere" is saying something about the state of the presentity, and then use that to determine which information is distributed to different watchers. Indeed, this begs the question of which approach is the desired approach for sphere. If its only use is to define a state which is then used to make authorization decisions at the presence server, there is no need to have any meaning for the value of sphere at all. I could publish a document with: 1 and have corresponding authorization rules which give out different information depending on whether sphere is 1 or 2. Having enumerated values with defined meanings is useful if the information is also published to watchers, and I think that does make sense to do that. I frequently set my yahoo status to "working at home, call cell" to basically convey my "sphere" and the associated contact information for me when I am in that sphere (my cell). If you add a presence status like this, it also makes sense to add corresponding capabilities in the authorization policies, which allow you to say "if presence element X has value Y, please do[n't] distribute presence element Z". XCAP-auth at the moment has no such capability. AS has been pointed out, such a capability would also be useful to make decisions based on other elements besides sphere. Thanks, Jonathan R. Henning Schulzrinne wrote: > Facet, in particular, is being used (in the IETF, by John Klensin's > drafts) in a completely generic way, describing any attribute of a > resource. > > hisham.khartabil@nokia.com wrote: > >> I did suggest Dimension. Also, how about Facet? >> > > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Sep 12 12:25:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01965; Fri, 12 Sep 2003 12:25:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xqjG-00015H-Rh; Fri, 12 Sep 2003 12:25:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xqiU-0000xD-Sg for simple@optimus.ietf.org; Fri, 12 Sep 2003 12:24: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 MAA01780 for ; Fri, 12 Sep 2003 12:24:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xqiT-0001Nk-00 for simple@ietf.org; Fri, 12 Sep 2003 12:24:13 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 19xqiS-0001NB-00 for simple@ietf.org; Fri, 12 Sep 2003 12:24:12 -0400 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id h8CGNYVW053057; Fri, 12 Sep 2003 11:23:34 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3F61F2F9.1060308@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Henning Schulzrinne , hisham.khartabil@nokia.com, simple@ietf.org Subject: Re: [Simple] Re: [Geopriv] Individuals, hats and spheres References: <2038BCC78B1AD641891A0D1AE133DBB7017970C3@esebe019.ntc.nokia.com> <3F5F2A59.3050600@cs.columbia.edu> <3F61723B.401@dynamicsoft.com> In-Reply-To: <3F61723B.401@dynamicsoft.com> X-Enigmail-Version: 0.81.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.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, 12 Sep 2003 11:23:21 -0500 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > Facet has also been used already as a concept in the publication work in > SIMPLE, and there it had a related function. It allowed a publisher to > declare a presence document to be associated to a specific facet, and > then specify watchers that were associated with the facet. The result > was that different watchers could get different views of the presence > data. Thats almost the same thing, but different in that "sphere" is > saying something about the state of the presentity, and then use that to > determine which information is distributed to different watchers. > > Indeed, this begs the question of which approach is the desired approach > for sphere. If its only use is to define a state which is then used to > make authorization decisions at the presence server, there is no need to > have any meaning for the value of sphere at all. I could publish a > document with: > > 1 > > and have corresponding authorization rules which give out different > information depending on whether sphere is 1 or 2. I was thinking the same thing. This makes the concept of sphere really become a concept of what authorization profile I want to have active at any given time. If we are willing to strip any other semantic meaning from sphere, then I would propose the term "profile" or "authorization-profile". > > Having enumerated values with defined meanings is useful if the > information is also published to watchers, and I think that does make > sense to do that. I frequently set my yahoo status to "working at home, > call cell" to basically convey my "sphere" and the associated contact > information for me when I am in that sphere (my cell). Doing this _does_ require some agreement between presentity and watcher as to what a given value means, i.e. a value of "home" is more useful than a value of "1". Or at least we would need to standardize the enumeration. I don't think this agreement is necessary between presentity and presence agent. > > If you add a presence status like this, it also makes sense to add > corresponding capabilities in the authorization policies, which allow > you to say "if presence element X has value Y, please do[n't] distribute > presence element Z". XCAP-auth at the moment has no such capability. AS > has been pointed out, such a capability would also be useful to make > decisions based on other elements besides sphere. > > Thanks, > Jonathan R. > > Henning Schulzrinne wrote: > >> Facet, in particular, is being used (in the IETF, by John Klensin's >> drafts) in a completely generic way, describing any attribute of a >> resource. >> >> hisham.khartabil@nokia.com wrote: >> >>> I did suggest Dimension. Also, how about Facet? >>> >> >> >> >> _______________________________________________ >> Geopriv mailing list >> Geopriv@ietf.org >> https://www1.ietf.org/mailman/listinfo/geopriv >> > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Sep 12 12:26:01 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02010 for ; Fri, 12 Sep 2003 12:26:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xqjq-0001Bn-BP for simple-archive@odin.ietf.org; Fri, 12 Sep 2003 12:25:39 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8CGPc45004567 for simple-archive@odin.ietf.org; Fri, 12 Sep 2003 12:25:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xqjq-0001Ba-8G for simple-web-archive@optimus.ietf.org; Fri, 12 Sep 2003 12:25:38 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01965; Fri, 12 Sep 2003 12:25:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xqjG-00015H-Rh; Fri, 12 Sep 2003 12:25:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xqiU-0000xD-Sg for simple@optimus.ietf.org; Fri, 12 Sep 2003 12:24: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 MAA01780 for ; Fri, 12 Sep 2003 12:24:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xqiT-0001Nk-00 for simple@ietf.org; Fri, 12 Sep 2003 12:24:13 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 19xqiS-0001NB-00 for simple@ietf.org; Fri, 12 Sep 2003 12:24:12 -0400 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id h8CGNYVW053057; Fri, 12 Sep 2003 11:23:34 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3F61F2F9.1060308@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Henning Schulzrinne , hisham.khartabil@nokia.com, simple@ietf.org Subject: Re: [Simple] Re: [Geopriv] Individuals, hats and spheres References: <2038BCC78B1AD641891A0D1AE133DBB7017970C3@esebe019.ntc.nokia.com> <3F5F2A59.3050600@cs.columbia.edu> <3F61723B.401@dynamicsoft.com> In-Reply-To: <3F61723B.401@dynamicsoft.com> X-Enigmail-Version: 0.81.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.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, 12 Sep 2003 11:23:21 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > Facet has also been used already as a concept in the publication work in > SIMPLE, and there it had a related function. It allowed a publisher to > declare a presence document to be associated to a specific facet, and > then specify watchers that were associated with the facet. The result > was that different watchers could get different views of the presence > data. Thats almost the same thing, but different in that "sphere" is > saying something about the state of the presentity, and then use that to > determine which information is distributed to different watchers. > > Indeed, this begs the question of which approach is the desired approach > for sphere. If its only use is to define a state which is then used to > make authorization decisions at the presence server, there is no need to > have any meaning for the value of sphere at all. I could publish a > document with: > > 1 > > and have corresponding authorization rules which give out different > information depending on whether sphere is 1 or 2. I was thinking the same thing. This makes the concept of sphere really become a concept of what authorization profile I want to have active at any given time. If we are willing to strip any other semantic meaning from sphere, then I would propose the term "profile" or "authorization-profile". > > Having enumerated values with defined meanings is useful if the > information is also published to watchers, and I think that does make > sense to do that. I frequently set my yahoo status to "working at home, > call cell" to basically convey my "sphere" and the associated contact > information for me when I am in that sphere (my cell). Doing this _does_ require some agreement between presentity and watcher as to what a given value means, i.e. a value of "home" is more useful than a value of "1". Or at least we would need to standardize the enumeration. I don't think this agreement is necessary between presentity and presence agent. > > If you add a presence status like this, it also makes sense to add > corresponding capabilities in the authorization policies, which allow > you to say "if presence element X has value Y, please do[n't] distribute > presence element Z". XCAP-auth at the moment has no such capability. AS > has been pointed out, such a capability would also be useful to make > decisions based on other elements besides sphere. > > Thanks, > Jonathan R. > > Henning Schulzrinne wrote: > >> Facet, in particular, is being used (in the IETF, by John Klensin's >> drafts) in a completely generic way, describing any attribute of a >> resource. >> >> hisham.khartabil@nokia.com wrote: >> >>> I did suggest Dimension. Also, how about Facet? >>> >> >> >> >> _______________________________________________ >> Geopriv mailing list >> Geopriv@ietf.org >> https://www1.ietf.org/mailman/listinfo/geopriv >> > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Sep 12 12:54:58 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04235; Fri, 12 Sep 2003 12:54:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xrCK-00029n-00; Fri, 12 Sep 2003 12:55:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19xrCK-00029i-00; Fri, 12 Sep 2003 12:55:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xrCJ-00042G-3M; Fri, 12 Sep 2003 12:55:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xrBK-0003tG-AR for simple@optimus.ietf.org; Fri, 12 Sep 2003 12:54: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 MAA04068 for ; Fri, 12 Sep 2003 12:53:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xrBH-00025S-00 for simple@ietf.org; Fri, 12 Sep 2003 12:54:00 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 19xrBG-00024z-00 for simple@ietf.org; Fri, 12 Sep 2003 12:53:58 -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 h8CGrq4m004014; Fri, 12 Sep 2003 12:53:52 -0400 (EDT) Received: from cs.columbia.edu (path.cs.columbia.edu [128.59.19.143]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h8CGrpG10415; Fri, 12 Sep 2003 12:53:51 -0400 Message-ID: <3F61FA1F.7040705@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030827 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Campbell CC: Jonathan Rosenberg , hisham.khartabil@nokia.com, simple@ietf.org Subject: Re: [Simple] Re: [Geopriv] Individuals, hats and spheres References: <2038BCC78B1AD641891A0D1AE133DBB7017970C3@esebe019.ntc.nokia.com> <3F5F2A59.3050600@cs.columbia.edu> <3F61723B.401@dynamicsoft.com> <3F61F2F9.1060308@dynamicsoft.com> In-Reply-To: <3F61F2F9.1060308@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 12 Sep 2003 12:53:51 -0400 Content-Transfer-Encoding: 7bit Ben Campbell wrote: >> >> 1 >> >> and have corresponding authorization rules which give out different >> information depending on whether sphere is 1 or 2. > > > I was thinking the same thing. This makes the concept of sphere really > become a concept of what authorization profile I want to have active at > any given time. If we are willing to strip any other semantic meaning > from sphere, then I would propose the term "profile" or > "authorization-profile". I agree that there is no need to have a fixed set of labels for that, unless you want to also convey this to watchers. This could occur, for example, if I want to tell my work buddies that I'm in private mode (implying that any attempt to contact me better be an emergency that can't wait until the next morning). Even in that case, one could argue that this is best handled by labels that I choose and that are meaningful to my life. > >> >> Having enumerated values with defined meanings is useful if the >> information is also published to watchers, and I think that does make >> sense to do that. I frequently set my yahoo status to "working at >> home, call cell" to basically convey my "sphere" and the associated >> contact information for me when I am in that sphere (my cell). > > > Doing this _does_ require some agreement between presentity and watcher > as to what a given value means, i.e. a value of "home" is more useful > than a value of "1". Or at least we would need to standardize the > enumeration. I don't think this agreement is necessary between > presentity and presence agent. I'm not sure it needs to be standardized, although suggesting a few standard terms ('work', 'off work', for example) may well be helpful and does not interfere with the ability to define tokens that make sense locally. We have taken this approach for almost all the enumerations in RPID: there's a set of tokens that are enumerated in the document to reduce gratuitous variations ('work', 'at work', 'on company time', 'counting the days to retirement', 'watching the clock', 'slaving away', 'on the clock', etc.), while not constraining users to that list. > >> >> If you add a presence status like this, it also makes sense to add >> corresponding capabilities in the authorization policies, which allow >> you to say "if presence element X has value Y, please do[n't] >> distribute presence element Z". XCAP-auth at the moment has no such >> capability. AS has been pointed out, such a capability would also be >> useful to make decisions based on other elements besides sphere. The geopriv work (published and in-progress) allows some such matching, based on time and geographic location of the target/presentity. For simplicity, I suspect that only equality matches based on tokens should be supported, rather than generic expressions or, say, lists. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Sep 12 12:55: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 MAA04264 for ; Fri, 12 Sep 2003 12:55:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xrCO-000444-LS for simple-archive@odin.ietf.org; Fri, 12 Sep 2003 12:55:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8CGt8Bu015623 for simple-archive@odin.ietf.org; Fri, 12 Sep 2003 12:55:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xrCO-00043u-IX for simple-web-archive@optimus.ietf.org; Fri, 12 Sep 2003 12:55:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04235; Fri, 12 Sep 2003 12:54:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xrCK-00029n-00; Fri, 12 Sep 2003 12:55:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19xrCK-00029i-00; Fri, 12 Sep 2003 12:55:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xrCJ-00042G-3M; Fri, 12 Sep 2003 12:55:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xrBK-0003tG-AR for simple@optimus.ietf.org; Fri, 12 Sep 2003 12:54: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 MAA04068 for ; Fri, 12 Sep 2003 12:53:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xrBH-00025S-00 for simple@ietf.org; Fri, 12 Sep 2003 12:54:00 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 19xrBG-00024z-00 for simple@ietf.org; Fri, 12 Sep 2003 12:53:58 -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 h8CGrq4m004014; Fri, 12 Sep 2003 12:53:52 -0400 (EDT) Received: from cs.columbia.edu (path.cs.columbia.edu [128.59.19.143]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h8CGrpG10415; Fri, 12 Sep 2003 12:53:51 -0400 Message-ID: <3F61FA1F.7040705@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030827 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Campbell CC: Jonathan Rosenberg , hisham.khartabil@nokia.com, simple@ietf.org Subject: Re: [Simple] Re: [Geopriv] Individuals, hats and spheres References: <2038BCC78B1AD641891A0D1AE133DBB7017970C3@esebe019.ntc.nokia.com> <3F5F2A59.3050600@cs.columbia.edu> <3F61723B.401@dynamicsoft.com> <3F61F2F9.1060308@dynamicsoft.com> In-Reply-To: <3F61F2F9.1060308@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 12 Sep 2003 12:53:51 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Ben Campbell wrote: >> >> 1 >> >> and have corresponding authorization rules which give out different >> information depending on whether sphere is 1 or 2. > > > I was thinking the same thing. This makes the concept of sphere really > become a concept of what authorization profile I want to have active at > any given time. If we are willing to strip any other semantic meaning > from sphere, then I would propose the term "profile" or > "authorization-profile". I agree that there is no need to have a fixed set of labels for that, unless you want to also convey this to watchers. This could occur, for example, if I want to tell my work buddies that I'm in private mode (implying that any attempt to contact me better be an emergency that can't wait until the next morning). Even in that case, one could argue that this is best handled by labels that I choose and that are meaningful to my life. > >> >> Having enumerated values with defined meanings is useful if the >> information is also published to watchers, and I think that does make >> sense to do that. I frequently set my yahoo status to "working at >> home, call cell" to basically convey my "sphere" and the associated >> contact information for me when I am in that sphere (my cell). > > > Doing this _does_ require some agreement between presentity and watcher > as to what a given value means, i.e. a value of "home" is more useful > than a value of "1". Or at least we would need to standardize the > enumeration. I don't think this agreement is necessary between > presentity and presence agent. I'm not sure it needs to be standardized, although suggesting a few standard terms ('work', 'off work', for example) may well be helpful and does not interfere with the ability to define tokens that make sense locally. We have taken this approach for almost all the enumerations in RPID: there's a set of tokens that are enumerated in the document to reduce gratuitous variations ('work', 'at work', 'on company time', 'counting the days to retirement', 'watching the clock', 'slaving away', 'on the clock', etc.), while not constraining users to that list. > >> >> If you add a presence status like this, it also makes sense to add >> corresponding capabilities in the authorization policies, which allow >> you to say "if presence element X has value Y, please do[n't] >> distribute presence element Z". XCAP-auth at the moment has no such >> capability. AS has been pointed out, such a capability would also be >> useful to make decisions based on other elements besides sphere. The geopriv work (published and in-progress) allows some such matching, based on time and geographic location of the target/presentity. For simplicity, I suspect that only equality matches based on tokens should be supported, rather than generic expressions or, say, lists. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Sep 12 15:06: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 PAA10588; Fri, 12 Sep 2003 15:06:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xtFF-0004BS-00; Fri, 12 Sep 2003 15:06:13 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19xtFE-0004BP-00; Fri, 12 Sep 2003 15:06:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xtF3-0003L3-U7; Fri, 12 Sep 2003 15:06:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xtET-00039f-Vk for simple@optimus.ietf.org; Fri, 12 Sep 2003 15:05:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10390 for ; Fri, 12 Sep 2003 15:05:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xtEP-00048H-00 for simple@ietf.org; Fri, 12 Sep 2003 15:05:21 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19xtEO-00046J-00 for simple@ietf.org; Fri, 12 Sep 2003 15:05:20 -0400 Received: from dynamicsoft.com ([63.113.46.48]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h8CJ4hUg014022; Fri, 12 Sep 2003 15:04:43 -0400 (EDT) Message-ID: <3F6218C4.6000503@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne CC: Ben Campbell , hisham.khartabil@nokia.com, simple@ietf.org Subject: Re: [Simple] Re: [Geopriv] Individuals, hats and spheres References: <2038BCC78B1AD641891A0D1AE133DBB7017970C3@esebe019.ntc.nokia.com> <3F5F2A59.3050600@cs.columbia.edu> <3F61723B.401@dynamicsoft.com> <3F61F2F9.1060308@dynamicsoft.com> <3F61FA1F.7040705@cs.columbia.edu> In-Reply-To: <3F61FA1F.7040705@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: Fri, 12 Sep 2003 15:04:36 -0400 Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > Ben Campbell wrote: > > >>> >>> 1 >>> >>> and have corresponding authorization rules which give out different >>> information depending on whether sphere is 1 or 2. >> >> >> >> I was thinking the same thing. This makes the concept of sphere really >> become a concept of what authorization profile I want to have active >> at any given time. If we are willing to strip any other semantic >> meaning from sphere, then I would propose the term "profile" or >> "authorization-profile". > > > I agree that there is no need to have a fixed set of labels for that, > unless you want to also convey this to watchers. This could occur, for > example, if I want to tell my work buddies that I'm in private mode > (implying that any attempt to contact me better be an emergency that > can't wait until the next morning). Even in that case, one could argue > that this is best handled by labels that I choose and that are > meaningful to my life. If you want to communicate this to watchers, you need defined labels with clear semantics. Thats important for watchers that are automata, that wish to summarize, render, or do some kind of processing based on the information. > > >> >>> >>> Having enumerated values with defined meanings is useful if the >>> information is also published to watchers, and I think that does make >>> sense to do that. I frequently set my yahoo status to "working at >>> home, call cell" to basically convey my "sphere" and the associated >>> contact information for me when I am in that sphere (my cell). >> >> >> >> Doing this _does_ require some agreement between presentity and >> watcher as to what a given value means, i.e. a value of "home" is more >> useful than a value of "1". Or at least we would need to standardize >> the enumeration. I don't think this agreement is necessary between >> presentity and presence agent. > > > I'm not sure it needs to be standardized, although suggesting a few > standard terms ('work', 'off work', for example) may well be helpful and > does not interfere with the ability to define tokens that make sense > locally. See above - if we don't standardize them, the only thing you can do at a watcher is present them to the user, in which case you may as well use a note. > > We have taken this approach for almost all the enumerations in RPID: > there's a set of tokens that are enumerated in the document to reduce > gratuitous variations ('work', 'at work', 'on company time', 'counting > the days to retirement', 'watching the clock', 'slaving away', 'on the > clock', etc.), while not constraining users to that list. Well, to be clear, it creates iana registries for those where new ones can be added. > > >> >>> >>> If you add a presence status like this, it also makes sense to add >>> corresponding capabilities in the authorization policies, which allow >>> you to say "if presence element X has value Y, please do[n't] >>> distribute presence element Z". XCAP-auth at the moment has no such >>> capability. AS has been pointed out, such a capability would also be >>> useful to make decisions based on other elements besides sphere. > > > The geopriv work (published and in-progress) allows some such matching, > based on time and geographic location of the target/presentity. For > simplicity, I suspect that only equality matches based on tokens should > be supported, rather than generic expressions or, say, lists. I'm not sure what you mean here - how do lists come into play? -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Sep 12 15:06:39 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 PAA10665 for ; Fri, 12 Sep 2003 15:06:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xtFJ-0003NK-Ai for simple-archive@odin.ietf.org; Fri, 12 Sep 2003 15:06:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8CJ6HgE012974 for simple-archive@odin.ietf.org; Fri, 12 Sep 2003 15:06:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xtFJ-0003NB-7f for simple-web-archive@optimus.ietf.org; Fri, 12 Sep 2003 15:06: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 PAA10588; Fri, 12 Sep 2003 15:06:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xtFF-0004BS-00; Fri, 12 Sep 2003 15:06:13 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19xtFE-0004BP-00; Fri, 12 Sep 2003 15:06:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xtF3-0003L3-U7; Fri, 12 Sep 2003 15:06:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xtET-00039f-Vk for simple@optimus.ietf.org; Fri, 12 Sep 2003 15:05:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10390 for ; Fri, 12 Sep 2003 15:05:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xtEP-00048H-00 for simple@ietf.org; Fri, 12 Sep 2003 15:05:21 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19xtEO-00046J-00 for simple@ietf.org; Fri, 12 Sep 2003 15:05:20 -0400 Received: from dynamicsoft.com ([63.113.46.48]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h8CJ4hUg014022; Fri, 12 Sep 2003 15:04:43 -0400 (EDT) Message-ID: <3F6218C4.6000503@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne CC: Ben Campbell , hisham.khartabil@nokia.com, simple@ietf.org Subject: Re: [Simple] Re: [Geopriv] Individuals, hats and spheres References: <2038BCC78B1AD641891A0D1AE133DBB7017970C3@esebe019.ntc.nokia.com> <3F5F2A59.3050600@cs.columbia.edu> <3F61723B.401@dynamicsoft.com> <3F61F2F9.1060308@dynamicsoft.com> <3F61FA1F.7040705@cs.columbia.edu> In-Reply-To: <3F61FA1F.7040705@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: Fri, 12 Sep 2003 15:04:36 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > Ben Campbell wrote: > > >>> >>> 1 >>> >>> and have corresponding authorization rules which give out different >>> information depending on whether sphere is 1 or 2. >> >> >> >> I was thinking the same thing. This makes the concept of sphere really >> become a concept of what authorization profile I want to have active >> at any given time. If we are willing to strip any other semantic >> meaning from sphere, then I would propose the term "profile" or >> "authorization-profile". > > > I agree that there is no need to have a fixed set of labels for that, > unless you want to also convey this to watchers. This could occur, for > example, if I want to tell my work buddies that I'm in private mode > (implying that any attempt to contact me better be an emergency that > can't wait until the next morning). Even in that case, one could argue > that this is best handled by labels that I choose and that are > meaningful to my life. If you want to communicate this to watchers, you need defined labels with clear semantics. Thats important for watchers that are automata, that wish to summarize, render, or do some kind of processing based on the information. > > >> >>> >>> Having enumerated values with defined meanings is useful if the >>> information is also published to watchers, and I think that does make >>> sense to do that. I frequently set my yahoo status to "working at >>> home, call cell" to basically convey my "sphere" and the associated >>> contact information for me when I am in that sphere (my cell). >> >> >> >> Doing this _does_ require some agreement between presentity and >> watcher as to what a given value means, i.e. a value of "home" is more >> useful than a value of "1". Or at least we would need to standardize >> the enumeration. I don't think this agreement is necessary between >> presentity and presence agent. > > > I'm not sure it needs to be standardized, although suggesting a few > standard terms ('work', 'off work', for example) may well be helpful and > does not interfere with the ability to define tokens that make sense > locally. See above - if we don't standardize them, the only thing you can do at a watcher is present them to the user, in which case you may as well use a note. > > We have taken this approach for almost all the enumerations in RPID: > there's a set of tokens that are enumerated in the document to reduce > gratuitous variations ('work', 'at work', 'on company time', 'counting > the days to retirement', 'watching the clock', 'slaving away', 'on the > clock', etc.), while not constraining users to that list. Well, to be clear, it creates iana registries for those where new ones can be added. > > >> >>> >>> If you add a presence status like this, it also makes sense to add >>> corresponding capabilities in the authorization policies, which allow >>> you to say "if presence element X has value Y, please do[n't] >>> distribute presence element Z". XCAP-auth at the moment has no such >>> capability. AS has been pointed out, such a capability would also be >>> useful to make decisions based on other elements besides sphere. > > > The geopriv work (published and in-progress) allows some such matching, > based on time and geographic location of the target/presentity. For > simplicity, I suspect that only equality matches based on tokens should > be supported, rather than generic expressions or, say, lists. I'm not sure what you mean here - how do lists come into play? -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Sep 12 15:34: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 PAA12216; Fri, 12 Sep 2003 15:34:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xtgG-0004Of-00; Fri, 12 Sep 2003 15:34:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19xtgG-0004Oc-00; Fri, 12 Sep 2003 15:34:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xtg9-000402-Da; Fri, 12 Sep 2003 15: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 19xtfp-0003zo-9n for simple@optimus.ietf.org; Fri, 12 Sep 2003 15:33:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12206 for ; Fri, 12 Sep 2003 15:33:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xtfn-0004OP-00 for simple@ietf.org; Fri, 12 Sep 2003 15:33:40 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 19xtfn-0004OM-00 for simple@ietf.org; Fri, 12 Sep 2003 15:33:39 -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 h8CJXP4m020325; Fri, 12 Sep 2003 15:33:25 -0400 (EDT) Received: from cs.columbia.edu (path.cs.columbia.edu [128.59.19.143]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h8CJXOG27985; Fri, 12 Sep 2003 15:33:25 -0400 Message-ID: <3F621F84.7090308@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030827 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Ben Campbell , hisham.khartabil@nokia.com, simple@ietf.org Subject: Re: [Simple] Re: [Geopriv] Individuals, hats and spheres References: <2038BCC78B1AD641891A0D1AE133DBB7017970C3@esebe019.ntc.nokia.com> <3F5F2A59.3050600@cs.columbia.edu> <3F61723B.401@dynamicsoft.com> <3F61F2F9.1060308@dynamicsoft.com> <3F61FA1F.7040705@cs.columbia.edu> <3F6218C4.6000503@dynamicsoft.com> In-Reply-To: <3F6218C4.6000503@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 12 Sep 2003 15:33:24 -0400 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > If you want to communicate this to watchers, you need defined labels > with clear semantics. Thats important for watchers that are automata, > that wish to summarize, render, or do some kind of processing based on > the information. No disagreement. I just think that in some cases, we can't anticipate the useful labels and so should allow for private-use labels. They may well be informally defined within a user community, e.g., within a group of friends or colleagues, just not registered with some central authority. For example, in a different context, I think we discussed that a hospital may well define a set of activity labels such as "performing operation", "bedside", "on call", etc. These are neither IANA-registered nor complete note-like free-for-alls. >> The geopriv work (published and in-progress) allows some such >> matching, based on time and geographic location of the >> target/presentity. For simplicity, I suspect that only equality >> matches based on tokens should be supported, rather than generic >> expressions or, say, lists. > > > I'm not sure what you mean here - how do lists come into play? One could imagine a restriction such as "if parameter X has a set of values drawn from set {A,B,C}" this can always be decomposed into multiple rules, so this adds no expressiveness, just reduces the number of rules, but makes the matching messier. > > -Jonathan R. > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Sep 12 15:34: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 PAA12243 for ; Fri, 12 Sep 2003 15:34: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 19xtgJ-00040l-13 for simple-archive@odin.ietf.org; Fri, 12 Sep 2003 15:34:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8CJYAce015413 for simple-archive@odin.ietf.org; Fri, 12 Sep 2003 15: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 19xtgI-00040W-Sx for simple-web-archive@optimus.ietf.org; Fri, 12 Sep 2003 15: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 PAA12216; Fri, 12 Sep 2003 15:34:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xtgG-0004Of-00; Fri, 12 Sep 2003 15:34:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19xtgG-0004Oc-00; Fri, 12 Sep 2003 15:34:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xtg9-000402-Da; Fri, 12 Sep 2003 15: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 19xtfp-0003zo-9n for simple@optimus.ietf.org; Fri, 12 Sep 2003 15:33:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12206 for ; Fri, 12 Sep 2003 15:33:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xtfn-0004OP-00 for simple@ietf.org; Fri, 12 Sep 2003 15:33:40 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 19xtfn-0004OM-00 for simple@ietf.org; Fri, 12 Sep 2003 15:33:39 -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 h8CJXP4m020325; Fri, 12 Sep 2003 15:33:25 -0400 (EDT) Received: from cs.columbia.edu (path.cs.columbia.edu [128.59.19.143]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h8CJXOG27985; Fri, 12 Sep 2003 15:33:25 -0400 Message-ID: <3F621F84.7090308@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030827 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Ben Campbell , hisham.khartabil@nokia.com, simple@ietf.org Subject: Re: [Simple] Re: [Geopriv] Individuals, hats and spheres References: <2038BCC78B1AD641891A0D1AE133DBB7017970C3@esebe019.ntc.nokia.com> <3F5F2A59.3050600@cs.columbia.edu> <3F61723B.401@dynamicsoft.com> <3F61F2F9.1060308@dynamicsoft.com> <3F61FA1F.7040705@cs.columbia.edu> <3F6218C4.6000503@dynamicsoft.com> In-Reply-To: <3F6218C4.6000503@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 12 Sep 2003 15:33:24 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > If you want to communicate this to watchers, you need defined labels > with clear semantics. Thats important for watchers that are automata, > that wish to summarize, render, or do some kind of processing based on > the information. No disagreement. I just think that in some cases, we can't anticipate the useful labels and so should allow for private-use labels. They may well be informally defined within a user community, e.g., within a group of friends or colleagues, just not registered with some central authority. For example, in a different context, I think we discussed that a hospital may well define a set of activity labels such as "performing operation", "bedside", "on call", etc. These are neither IANA-registered nor complete note-like free-for-alls. >> The geopriv work (published and in-progress) allows some such >> matching, based on time and geographic location of the >> target/presentity. For simplicity, I suspect that only equality >> matches based on tokens should be supported, rather than generic >> expressions or, say, lists. > > > I'm not sure what you mean here - how do lists come into play? One could imagine a restriction such as "if parameter X has a set of values drawn from set {A,B,C}" this can always be decomposed into multiple rules, so this adds no expressiveness, just reduces the number of rules, but makes the matching messier. > > -Jonathan R. > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Sep 15 10:09: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 KAA01234; Mon, 15 Sep 2003 10:09:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19yu2Q-0002ZX-00; Mon, 15 Sep 2003 10:09:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19yu2Q-0002Yd-00; Mon, 15 Sep 2003 10:09:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yu2G-0005g1-Us; Mon, 15 Sep 2003 10:09:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yu1a-0005bU-Fy for simple@optimus.ietf.org; Mon, 15 Sep 2003 10:08: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 KAA00968 for ; Mon, 15 Sep 2003 10:08:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19yu1Y-0002QT-00 for simple@ietf.org; Mon, 15 Sep 2003 10:08:16 -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 19yu1X-0002MX-00 for simple@ietf.org; Mon, 15 Sep 2003 10:08:15 -0400 Received: from cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 15 Sep 2003 07:22:03 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h8FE7dbu026203; Mon, 15 Sep 2003 07:07:42 -0700 (PDT) Received: from cisco.com ([161.44.79.51]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ACJ87372; Mon, 15 Sep 2003 10:07:38 -0400 (EDT) Message-ID: <3F65C7A9.1030501@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: Henning Schulzrinne CC: Jonathan Rosenberg , Ben Campbell , hisham.khartabil@nokia.com, simple@ietf.org Subject: Re: [Simple] Re: [Geopriv] Individuals, hats and spheres References: <2038BCC78B1AD641891A0D1AE133DBB7017970C3@esebe019.ntc.nokia.com> <3F5F2A59.3050600@cs.columbia.edu> <3F61723B.401@dynamicsoft.com> <3F61F2F9.1060308@dynamicsoft.com> <3F61FA1F.7040705@cs.columbia.edu> <3F6218C4.6000503@dynamicsoft.com> <3F621F84.7090308@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, 15 Sep 2003 10:07:37 -0400 Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > Jonathan Rosenberg wrote: > > >> If you want to communicate this to watchers, you need defined labels >> with clear semantics. Thats important for watchers that are automata, >> that wish to summarize, render, or do some kind of processing based on >> the information. > > > No disagreement. I just think that in some cases, we can't anticipate > the useful labels and so should allow for private-use labels. They may > well be informally defined within a user community, e.g., within a group > of friends or colleagues, just not registered with some central authority. > > For example, in a different context, I think we discussed that a > hospital may well define a set of activity labels such as "performing > operation", "bedside", "on call", etc. These are neither IANA-registered > nor complete note-like free-for-alls. Why isn't this orthogonal to the concept of sphere? The sphere could be an arbitrary tag shared between the publisher and presence server, but not communicated to subscribers. The attribute that is communicated to the subscriber is simply some element in the doc carried by the notify. It could be an existing item (e.g. note), or if need be it could be something new. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Sep 15 10:09:41 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 KAA01427 for ; Mon, 15 Sep 2003 10:09:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yu2W-0005sX-9D for simple-archive@odin.ietf.org; Mon, 15 Sep 2003 10:09:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8FE9GNo022589 for simple-archive@odin.ietf.org; Mon, 15 Sep 2003 10:09:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yu2W-0005s8-02 for simple-web-archive@optimus.ietf.org; Mon, 15 Sep 2003 10:09: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 KAA01234; Mon, 15 Sep 2003 10:09:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19yu2Q-0002ZX-00; Mon, 15 Sep 2003 10:09:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19yu2Q-0002Yd-00; Mon, 15 Sep 2003 10:09:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yu2G-0005g1-Us; Mon, 15 Sep 2003 10:09:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yu1a-0005bU-Fy for simple@optimus.ietf.org; Mon, 15 Sep 2003 10:08: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 KAA00968 for ; Mon, 15 Sep 2003 10:08:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19yu1Y-0002QT-00 for simple@ietf.org; Mon, 15 Sep 2003 10:08:16 -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 19yu1X-0002MX-00 for simple@ietf.org; Mon, 15 Sep 2003 10:08:15 -0400 Received: from cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 15 Sep 2003 07:22:03 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h8FE7dbu026203; Mon, 15 Sep 2003 07:07:42 -0700 (PDT) Received: from cisco.com ([161.44.79.51]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ACJ87372; Mon, 15 Sep 2003 10:07:38 -0400 (EDT) Message-ID: <3F65C7A9.1030501@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: Henning Schulzrinne CC: Jonathan Rosenberg , Ben Campbell , hisham.khartabil@nokia.com, simple@ietf.org Subject: Re: [Simple] Re: [Geopriv] Individuals, hats and spheres References: <2038BCC78B1AD641891A0D1AE133DBB7017970C3@esebe019.ntc.nokia.com> <3F5F2A59.3050600@cs.columbia.edu> <3F61723B.401@dynamicsoft.com> <3F61F2F9.1060308@dynamicsoft.com> <3F61FA1F.7040705@cs.columbia.edu> <3F6218C4.6000503@dynamicsoft.com> <3F621F84.7090308@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, 15 Sep 2003 10:07:37 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > Jonathan Rosenberg wrote: > > >> If you want to communicate this to watchers, you need defined labels >> with clear semantics. Thats important for watchers that are automata, >> that wish to summarize, render, or do some kind of processing based on >> the information. > > > No disagreement. I just think that in some cases, we can't anticipate > the useful labels and so should allow for private-use labels. They may > well be informally defined within a user community, e.g., within a group > of friends or colleagues, just not registered with some central authority. > > For example, in a different context, I think we discussed that a > hospital may well define a set of activity labels such as "performing > operation", "bedside", "on call", etc. These are neither IANA-registered > nor complete note-like free-for-alls. Why isn't this orthogonal to the concept of sphere? The sphere could be an arbitrary tag shared between the publisher and presence server, but not communicated to subscribers. The attribute that is communicated to the subscriber is simply some element in the doc carried by the notify. It could be an existing item (e.g. note), or if need be it could be something new. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Sep 15 10:11:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01907; Mon, 15 Sep 2003 10:11:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yu4E-00065y-EO; Mon, 15 Sep 2003 10:11:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yu3m-00062v-By for simple@optimus.ietf.org; Mon, 15 Sep 2003 10:10:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01619 for ; Mon, 15 Sep 2003 10:10:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19yu3g-0002lN-00 for simple@ietf.org; Mon, 15 Sep 2003 10:10:29 -0400 Received: from pecan.cc.columbia.edu ([128.59.59.178] ident=cu41754) by ietf-mx with esmtp (Exim 4.12) id 19yu3g-0002lF-00 for simple@ietf.org; Mon, 15 Sep 2003 10:10:28 -0400 Received: from cs.columbia.edu (path.cs.columbia.edu [128.59.19.143]) (user=hgs10 mech=PLAIN bits=0) by pecan.cc.columbia.edu (8.12.8p1/8.12.8) with ESMTP id h8FEAKWw026875 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 15 Sep 2003 10:10:20 -0400 (EDT) Message-ID: <3F65C84C.40202@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030826 Mozilla Thunderbird/0.2a X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: Jonathan Rosenberg , Ben Campbell , hisham.khartabil@nokia.com, simple@ietf.org Subject: Re: [Simple] Re: [Geopriv] Individuals, hats and spheres References: <2038BCC78B1AD641891A0D1AE133DBB7017970C3@esebe019.ntc.nokia.com> <3F5F2A59.3050600@cs.columbia.edu> <3F61723B.401@dynamicsoft.com> <3F61F2F9.1060308@dynamicsoft.com> <3F61FA1F.7040705@cs.columbia.edu> <3F6218C4.6000503@dynamicsoft.com> <3F621F84.7090308@cs.columbia.edu> <3F65C7A9.1030501@cisco.com> In-Reply-To: <3F65C7A9.1030501@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.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, 15 Sep 2003 10:10:20 -0400 Content-Transfer-Encoding: 7bit Paul Kyzivat wrote: > Why isn't this orthogonal to the concept of sphere? The sphere could be > an arbitrary tag shared between the publisher and presence server, but > not communicated to subscribers. I don't see why we need to distinguish PUBLISH tags and NOTIFY tags. I should have the ability to exclude or include any tag in NOTIFY, without some artificial distinction between tags. > > The attribute that is communicated to the subscriber is simply some > element in the doc carried by the notify. It could be an existing item > (e.g. note), or if need be it could be something new. > > Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Sep 15 10:12:05 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 KAA02080 for ; Mon, 15 Sep 2003 10:12:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yu4s-0006Dh-J7 for simple-archive@odin.ietf.org; Mon, 15 Sep 2003 10:11:42 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8FEBg2Y023903 for simple-archive@odin.ietf.org; Mon, 15 Sep 2003 10:11:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yu4s-0006DS-Eq for simple-web-archive@optimus.ietf.org; Mon, 15 Sep 2003 10:11:42 -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 KAA01907; Mon, 15 Sep 2003 10:11:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yu4E-00065y-EO; Mon, 15 Sep 2003 10:11:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yu3m-00062v-By for simple@optimus.ietf.org; Mon, 15 Sep 2003 10:10:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01619 for ; Mon, 15 Sep 2003 10:10:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19yu3g-0002lN-00 for simple@ietf.org; Mon, 15 Sep 2003 10:10:29 -0400 Received: from pecan.cc.columbia.edu ([128.59.59.178] ident=cu41754) by ietf-mx with esmtp (Exim 4.12) id 19yu3g-0002lF-00 for simple@ietf.org; Mon, 15 Sep 2003 10:10:28 -0400 Received: from cs.columbia.edu (path.cs.columbia.edu [128.59.19.143]) (user=hgs10 mech=PLAIN bits=0) by pecan.cc.columbia.edu (8.12.8p1/8.12.8) with ESMTP id h8FEAKWw026875 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 15 Sep 2003 10:10:20 -0400 (EDT) Message-ID: <3F65C84C.40202@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030826 Mozilla Thunderbird/0.2a X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: Jonathan Rosenberg , Ben Campbell , hisham.khartabil@nokia.com, simple@ietf.org Subject: Re: [Simple] Re: [Geopriv] Individuals, hats and spheres References: <2038BCC78B1AD641891A0D1AE133DBB7017970C3@esebe019.ntc.nokia.com> <3F5F2A59.3050600@cs.columbia.edu> <3F61723B.401@dynamicsoft.com> <3F61F2F9.1060308@dynamicsoft.com> <3F61FA1F.7040705@cs.columbia.edu> <3F6218C4.6000503@dynamicsoft.com> <3F621F84.7090308@cs.columbia.edu> <3F65C7A9.1030501@cisco.com> In-Reply-To: <3F65C7A9.1030501@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.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, 15 Sep 2003 10:10:20 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Paul Kyzivat wrote: > Why isn't this orthogonal to the concept of sphere? The sphere could be > an arbitrary tag shared between the publisher and presence server, but > not communicated to subscribers. I don't see why we need to distinguish PUBLISH tags and NOTIFY tags. I should have the ability to exclude or include any tag in NOTIFY, without some artificial distinction between tags. > > The attribute that is communicated to the subscriber is simply some > element in the doc carried by the notify. It could be an existing item > (e.g. note), or if need be it could be something new. > > Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Sep 15 15:45:59 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22914; Mon, 15 Sep 2003 15:45:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19yzIS-0005MC-00; Mon, 15 Sep 2003 15:46:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19yzIS-0005M9-00; Mon, 15 Sep 2003 15:46:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yzIQ-0000rK-5f; Mon, 15 Sep 2003 15:46:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ypRP-0002gT-LT for simple@optimus.ietf.org; Mon, 15 Sep 2003 05:14: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 FAA19147 for ; Mon, 15 Sep 2003 05:14:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ypRM-0005za-00 for simple@ietf.org; Mon, 15 Sep 2003 05:14:36 -0400 Received: from web41008.mail.yahoo.com ([66.218.93.7]) by ietf-mx with smtp (Exim 4.12) id 19ypRL-0005wN-00 for simple@ietf.org; Mon, 15 Sep 2003 05:14:35 -0400 Message-ID: <20030915091406.94452.qmail@web41008.mail.yahoo.com> Received: from [68.36.62.252] by web41008.mail.yahoo.com via HTTP; Mon, 15 Sep 2003 02:14:06 PDT From: youngsun song To: simple@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-443835746-1063617246=:91872" Subject: [Simple] general questions on presence information format Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.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, 15 Sep 2003 02:14:06 -0700 (PDT) --0-443835746-1063617246=:91872 Content-Type: text/plain; charset=us-ascii Hi, I just started looking at documents related to presence information and have a few questions. The draft-ietf-impp-cpim-pidf document seems to define a baseline presence format that is to be extended for use by various presence applications. The documents that extend the pidf seem to be: draft-ietf-simple-rpids-01.txt, draft-rosenberg-peterson-simple-pidf-phone-00.txt, draft-lonnfors-simple-prescaps-ext-01.txt, etc. Are these extensions considered fairly stable? If not, are there any timeframes by when these are expected to become stable? Also, for the SIP-based presence applications currently implemented, are they then using private extensions of the pidf (or private presence formats)? Thanks for any help you can provide. YoungSun --------------------------------- Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software --0-443835746-1063617246=:91872 Content-Type: text/html; charset=us-ascii
Hi,
I just started looking at documents related to presence information and have a few questions.
 
The draft-ietf-impp-cpim-pidf document seems to define a baseline presence format that is to be extended for use by various presence applications. The documents that extend the pidf seem to be: draft-ietf-simple-rpids-01.txt, draft-rosenberg-peterson-simple-pidf-phone-00.txt, draft-lonnfors-simple-prescaps-ext-01.txt, etc.
Are these extensions considered fairly stable? If not, are there any timeframes by when these are expected to become stable?
Also, for the SIP-based presence applications currently implemented, are they then using private extensions of the pidf (or private presence formats)?
 
Thanks for any help you can provide.
YoungSun

Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software --0-443835746-1063617246=:91872-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Sep 15 15:46:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22947 for ; Mon, 15 Sep 2003 15:46: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 19yzIV-0000s7-3Z for simple-archive@odin.ietf.org; Mon, 15 Sep 2003 15:46:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8FJk7ga003345 for simple-archive@odin.ietf.org; Mon, 15 Sep 2003 15:46:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yzIV-0000rs-0K for simple-web-archive@optimus.ietf.org; Mon, 15 Sep 2003 15:46:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22914; Mon, 15 Sep 2003 15:45:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19yzIS-0005MC-00; Mon, 15 Sep 2003 15:46:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19yzIS-0005M9-00; Mon, 15 Sep 2003 15:46:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yzIQ-0000rK-5f; Mon, 15 Sep 2003 15:46:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ypRP-0002gT-LT for simple@optimus.ietf.org; Mon, 15 Sep 2003 05:14: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 FAA19147 for ; Mon, 15 Sep 2003 05:14:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ypRM-0005za-00 for simple@ietf.org; Mon, 15 Sep 2003 05:14:36 -0400 Received: from web41008.mail.yahoo.com ([66.218.93.7]) by ietf-mx with smtp (Exim 4.12) id 19ypRL-0005wN-00 for simple@ietf.org; Mon, 15 Sep 2003 05:14:35 -0400 Message-ID: <20030915091406.94452.qmail@web41008.mail.yahoo.com> Received: from [68.36.62.252] by web41008.mail.yahoo.com via HTTP; Mon, 15 Sep 2003 02:14:06 PDT From: youngsun song To: simple@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-443835746-1063617246=:91872" Subject: [Simple] general questions on presence information format Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.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, 15 Sep 2003 02:14:06 -0700 (PDT) --0-443835746-1063617246=:91872 Content-Type: text/plain; charset=us-ascii Hi, I just started looking at documents related to presence information and have a few questions. The draft-ietf-impp-cpim-pidf document seems to define a baseline presence format that is to be extended for use by various presence applications. The documents that extend the pidf seem to be: draft-ietf-simple-rpids-01.txt, draft-rosenberg-peterson-simple-pidf-phone-00.txt, draft-lonnfors-simple-prescaps-ext-01.txt, etc. Are these extensions considered fairly stable? If not, are there any timeframes by when these are expected to become stable? Also, for the SIP-based presence applications currently implemented, are they then using private extensions of the pidf (or private presence formats)? Thanks for any help you can provide. YoungSun --------------------------------- Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software --0-443835746-1063617246=:91872 Content-Type: text/html; charset=us-ascii
Hi,
I just started looking at documents related to presence information and have a few questions.
 
The draft-ietf-impp-cpim-pidf document seems to define a baseline presence format that is to be extended for use by various presence applications. The documents that extend the pidf seem to be: draft-ietf-simple-rpids-01.txt, draft-rosenberg-peterson-simple-pidf-phone-00.txt, draft-lonnfors-simple-prescaps-ext-01.txt, etc.
Are these extensions considered fairly stable? If not, are there any timeframes by when these are expected to become stable?
Also, for the SIP-based presence applications currently implemented, are they then using private extensions of the pidf (or private presence formats)?
 
Thanks for any help you can provide.
YoungSun

Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software --0-443835746-1063617246=:91872-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Sep 16 15: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 PAA02149; Tue, 16 Sep 2003 15:03:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zL6R-0007jM-00; Tue, 16 Sep 2003 15:03:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19zL6Q-0007jH-00; Tue, 16 Sep 2003 15:03:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zL6L-00044W-Bb; Tue, 16 Sep 2003 15:03:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zL68-00044J-Tj for simple@optimus.ietf.org; Tue, 16 Sep 2003 15:02: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 PAA02136 for ; Tue, 16 Sep 2003 15:02:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zL65-0007iW-00 for simple@ietf.org; Tue, 16 Sep 2003 15:02:46 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19zL65-0007iL-00 for simple@ietf.org; Tue, 16 Sep 2003 15:02:45 -0400 Received: from cisco.com (171.68.223.138) by sj-iport-2.cisco.com with ESMTP; 16 Sep 2003 11:58:43 -0700 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h8GJ2CBo028469; Tue, 16 Sep 2003 12:02:13 -0700 (PDT) Received: from [128.107.171.228] ([128.107.171.228]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AIE63999; Tue, 16 Sep 2003 12:02:09 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.1.2418 Subject: Re: [Simple] Default 1 minute inactivity timer in MSRP From: Cullen Jennings To: Chris Boulton , Ben Campbell , Adam Roach CC: "Miguel A. Garcia" , Message-ID: In-Reply-To: <45730E094814E44488F789C1CDED27AE0219B0A7@gbnewp0758m.eu.ubiquity.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 16 Sep 2003 12:02:12 -0700 Content-Transfer-Encoding: 7bit I think things between 1 and 60 sound pretty good but ... What we really need here is an argument why some number x is a good number. Cullen On 9/11/03 11:08, "Chris Boulton" wrote: > ok - If it must be his method I'll see Adams bid of 12 (and maybe even raise > it ;-) . I think that it is a good compromise of traffic vs session clean up. > > Chris. > > > -----Original Message----- > From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] > Sent: Thu 11/09/2003 18:16 > To: Adam Roach > Cc: Miguel A. Garcia; simple@ietf.org > Subject: Re: [Simple] Default 1 minute inactivity timer in MSRP > > > > On reflection, I think I agree that a higher value than 1 minute makes > sense. One use case I expect to see a lot for message sessions is the > chat room, or text conference, where it will be common for one > participant to receive a lot more than they send. > > Of course, at the same time, larger numbers reduce the ability of a > relay to prune dead sessions. > > So I bid 5 minutes. > > Adam Roach wrote: >> Ben Campbell [mailto:bcampbell@dynamicsoft.com] writes: >> >> >>> 1) Do others agree with Miguel that we should make the inactivity >>> timeout negotiable? >> >> >> Having tried to go down this path several times, I want to >> emphasize that I am very strongly opposed to any mechanism >> for negotiation of this timeout. >> >> >>> 2) If not, can anyone suggest a better way to choose the >>> standard value? >> >> >> Nope. One minute sounds good. One hour sounds good. I don't >> think I'd want to go much outside that range. >> >> However, it sounds like there's some objection to something >> as small as one minute, so we need to negotiate an arbitrary >> value here on the list. I'll start the bidding at twelve >> minutes. >> >> /a > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > > > J) _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Sep 16 15:03:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02277 for ; Tue, 16 Sep 2003 15:03:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zL6Y-00045L-Ql for simple-archive@odin.ietf.org; Tue, 16 Sep 2003 15:03:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8GJ3EW3015702 for simple-archive@odin.ietf.org; Tue, 16 Sep 2003 15:03:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zL6Y-00045B-Mm for simple-web-archive@optimus.ietf.org; Tue, 16 Sep 2003 15:03: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 PAA02149; Tue, 16 Sep 2003 15:03:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zL6R-0007jM-00; Tue, 16 Sep 2003 15:03:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19zL6Q-0007jH-00; Tue, 16 Sep 2003 15:03:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zL6L-00044W-Bb; Tue, 16 Sep 2003 15:03:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zL68-00044J-Tj for simple@optimus.ietf.org; Tue, 16 Sep 2003 15:02: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 PAA02136 for ; Tue, 16 Sep 2003 15:02:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zL65-0007iW-00 for simple@ietf.org; Tue, 16 Sep 2003 15:02:46 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19zL65-0007iL-00 for simple@ietf.org; Tue, 16 Sep 2003 15:02:45 -0400 Received: from cisco.com (171.68.223.138) by sj-iport-2.cisco.com with ESMTP; 16 Sep 2003 11:58:43 -0700 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h8GJ2CBo028469; Tue, 16 Sep 2003 12:02:13 -0700 (PDT) Received: from [128.107.171.228] ([128.107.171.228]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AIE63999; Tue, 16 Sep 2003 12:02:09 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.1.2418 Subject: Re: [Simple] Default 1 minute inactivity timer in MSRP From: Cullen Jennings To: Chris Boulton , Ben Campbell , Adam Roach CC: "Miguel A. Garcia" , Message-ID: In-Reply-To: <45730E094814E44488F789C1CDED27AE0219B0A7@gbnewp0758m.eu.ubiquity.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 16 Sep 2003 12:02:12 -0700 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I think things between 1 and 60 sound pretty good but ... What we really need here is an argument why some number x is a good number. Cullen On 9/11/03 11:08, "Chris Boulton" wrote: > ok - If it must be his method I'll see Adams bid of 12 (and maybe even raise > it ;-) . I think that it is a good compromise of traffic vs session clean up. > > Chris. > > > -----Original Message----- > From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] > Sent: Thu 11/09/2003 18:16 > To: Adam Roach > Cc: Miguel A. Garcia; simple@ietf.org > Subject: Re: [Simple] Default 1 minute inactivity timer in MSRP > > > > On reflection, I think I agree that a higher value than 1 minute makes > sense. One use case I expect to see a lot for message sessions is the > chat room, or text conference, where it will be common for one > participant to receive a lot more than they send. > > Of course, at the same time, larger numbers reduce the ability of a > relay to prune dead sessions. > > So I bid 5 minutes. > > Adam Roach wrote: >> Ben Campbell [mailto:bcampbell@dynamicsoft.com] writes: >> >> >>> 1) Do others agree with Miguel that we should make the inactivity >>> timeout negotiable? >> >> >> Having tried to go down this path several times, I want to >> emphasize that I am very strongly opposed to any mechanism >> for negotiation of this timeout. >> >> >>> 2) If not, can anyone suggest a better way to choose the >>> standard value? >> >> >> Nope. One minute sounds good. One hour sounds good. I don't >> think I'd want to go much outside that range. >> >> However, it sounds like there's some objection to something >> as small as one minute, so we need to negotiate an arbitrary >> value here on the list. I'll start the bidding at twelve >> minutes. >> >> /a > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > > > J) _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Sep 17 01:52:01 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00878; Wed, 17 Sep 2003 01:52:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zVEU-00018j-00; Wed, 17 Sep 2003 01:52:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19zVEU-00018g-00; Wed, 17 Sep 2003 01:52:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zVEQ-0002FX-Ce; Wed, 17 Sep 2003 01:52:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zVDU-0002Ec-S8 for simple@optimus.ietf.org; Wed, 17 Sep 2003 01:51: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 BAA00852 for ; Wed, 17 Sep 2003 01:50:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zVDR-00017v-00 for simple@ietf.org; Wed, 17 Sep 2003 01:51:01 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19zVDR-00017M-00 for simple@ietf.org; Wed, 17 Sep 2003 01:51:01 -0400 Received: from dynamicsoft.com ([63.113.46.68]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h8H5obUg015856; Wed, 17 Sep 2003 01:50:38 -0400 (EDT) Message-ID: <3F67F626.9090303@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: youngsun song CC: simple@ietf.org Subject: Re: [Simple] general questions on presence information format References: <20030915091406.94452.qmail@web41008.mail.yahoo.com> In-Reply-To: <20030915091406.94452.qmail@web41008.mail.yahoo.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, 17 Sep 2003 01:50:30 -0400 Content-Transfer-Encoding: 7bit youngsun song wrote: > Hi, > I just started looking at documents related to presence information and > have a few questions. > > The draft-ietf-impp-cpim-pidf document seems to define a baseline > presence format that is to be extended for use by various presence > applications. The documents that extend the pidf seem to be: > draft-ietf-simple-rpids-01.txt, > draft-rosenberg-peterson-simple-pidf-phone-00.txt, > draft-lonnfors-simple-prescaps-ext-01.txt, etc. > Are these extensions considered fairly stable? rpids is somewhat stable; I expect some more changes but its been through the ringer quite a bit already. pidf-phone is very unstable - that was just the first proposal, and the scope will be substantially reduced in the next rev. I think prescaps-ext also has some work to do, hasn't gotten a lot of air time yet really. > If not, are there any > timeframes by when these are expected to become stable? I'll let the chairs comment on that... > Also, for the SIP-based presence applications currently implemented, are > they then using private extensions of the pidf (or private presence > formats)? I think there are some private extensions. I know of deployments that use the baseline pidf though. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Sep 17 01:52: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 BAA00899 for ; Wed, 17 Sep 2003 01:52: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 19zVEY-0002GQ-Le for simple-archive@odin.ietf.org; Wed, 17 Sep 2003 01:52:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8H5qAsX008703 for simple-archive@odin.ietf.org; Wed, 17 Sep 2003 01:52:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zVEY-0002GI-HR for simple-web-archive@optimus.ietf.org; Wed, 17 Sep 2003 01: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 BAA00878; Wed, 17 Sep 2003 01:52:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zVEU-00018j-00; Wed, 17 Sep 2003 01:52:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19zVEU-00018g-00; Wed, 17 Sep 2003 01:52:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zVEQ-0002FX-Ce; Wed, 17 Sep 2003 01:52:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zVDU-0002Ec-S8 for simple@optimus.ietf.org; Wed, 17 Sep 2003 01:51: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 BAA00852 for ; Wed, 17 Sep 2003 01:50:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zVDR-00017v-00 for simple@ietf.org; Wed, 17 Sep 2003 01:51:01 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19zVDR-00017M-00 for simple@ietf.org; Wed, 17 Sep 2003 01:51:01 -0400 Received: from dynamicsoft.com ([63.113.46.68]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h8H5obUg015856; Wed, 17 Sep 2003 01:50:38 -0400 (EDT) Message-ID: <3F67F626.9090303@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: youngsun song CC: simple@ietf.org Subject: Re: [Simple] general questions on presence information format References: <20030915091406.94452.qmail@web41008.mail.yahoo.com> In-Reply-To: <20030915091406.94452.qmail@web41008.mail.yahoo.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, 17 Sep 2003 01:50:30 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit youngsun song wrote: > Hi, > I just started looking at documents related to presence information and > have a few questions. > > The draft-ietf-impp-cpim-pidf document seems to define a baseline > presence format that is to be extended for use by various presence > applications. The documents that extend the pidf seem to be: > draft-ietf-simple-rpids-01.txt, > draft-rosenberg-peterson-simple-pidf-phone-00.txt, > draft-lonnfors-simple-prescaps-ext-01.txt, etc. > Are these extensions considered fairly stable? rpids is somewhat stable; I expect some more changes but its been through the ringer quite a bit already. pidf-phone is very unstable - that was just the first proposal, and the scope will be substantially reduced in the next rev. I think prescaps-ext also has some work to do, hasn't gotten a lot of air time yet really. > If not, are there any > timeframes by when these are expected to become stable? I'll let the chairs comment on that... > Also, for the SIP-based presence applications currently implemented, are > they then using private extensions of the pidf (or private presence > formats)? I think there are some private extensions. I know of deployments that use the baseline pidf though. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Sep 17 02:47: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 CAA28821; Wed, 17 Sep 2003 02:47:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zW6a-0001lM-00; Wed, 17 Sep 2003 02:48:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19zW6a-0001lJ-00; Wed, 17 Sep 2003 02:48:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zW6b-0006Fl-NH; Wed, 17 Sep 2003 02: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 19zW60-0006Eq-NR for simple@optimus.ietf.org; Wed, 17 Sep 2003 02:47: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 CAA28795 for ; Wed, 17 Sep 2003 02:47:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zW5w-0001kr-00 for simple@ietf.org; Wed, 17 Sep 2003 02:47:21 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19zW5w-0001kR-00 for simple@ietf.org; Wed, 17 Sep 2003 02:47:20 -0400 Received: from dynamicsoft.com ([63.113.46.68]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h8H6knUg015887; Wed, 17 Sep 2003 02:46:50 -0400 (EDT) Message-ID: <3F680353.5020601@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne CC: Ben Campbell , hisham.khartabil@nokia.com, simple@ietf.org Subject: Re: [Simple] Re: [Geopriv] Individuals, hats and spheres References: <2038BCC78B1AD641891A0D1AE133DBB7017970C3@esebe019.ntc.nokia.com> <3F5F2A59.3050600@cs.columbia.edu> <3F61723B.401@dynamicsoft.com> <3F61F2F9.1060308@dynamicsoft.com> <3F61FA1F.7040705@cs.columbia.edu> <3F6218C4.6000503@dynamicsoft.com> <3F621F84.7090308@cs.columbia.edu> In-Reply-To: <3F621F84.7090308@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 17 Sep 2003 02:46:43 -0400 Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > Jonathan Rosenberg wrote: > > >> If you want to communicate this to watchers, you need defined labels >> with clear semantics. Thats important for watchers that are automata, >> that wish to summarize, render, or do some kind of processing based on >> the information. > > > No disagreement. I just think that in some cases, we can't anticipate > the useful labels and so should allow for private-use labels. They may > well be informally defined within a user community, e.g., within a group > of friends or colleagues, just not registered with some central authority. Thats fine. There is precendent for processes where other namespaces can be used, and someone else can be the central point of definition for those namespaces. See rfc2506 for example. > > For example, in a different context, I think we discussed that a > hospital may well define a set of activity labels such as "performing > operation", "bedside", "on call", etc. These are neither IANA-registered > nor complete note-like free-for-alls. > > >>> The geopriv work (published and in-progress) allows some such >>> matching, based on time and geographic location of the >>> target/presentity. For simplicity, I suspect that only equality >>> matches based on tokens should be supported, rather than generic >>> expressions or, say, lists. >> >> >> >> I'm not sure what you mean here - how do lists come into play? > > > One could imagine a restriction such as > > "if parameter X has a set of values drawn from set {A,B,C}" > > this can always be decomposed into multiple rules, so this adds no > expressiveness, just reduces the number of rules, but makes the matching > messier. OK, makes sense. Do we have any kind of consensus that this sphere is good to have, and that is is both published->presence server and presence server-> watcher? -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Sep 17 02:48: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 CAA28853 for ; Wed, 17 Sep 2003 02:48: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 19zW6f-0006Gd-Ja for simple-archive@odin.ietf.org; Wed, 17 Sep 2003 02:48:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8H6m5oN024092 for simple-archive@odin.ietf.org; Wed, 17 Sep 2003 02:48:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zW6e-0006GV-Ty for simple-web-archive@optimus.ietf.org; Wed, 17 Sep 2003 02:48: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 CAA28821; Wed, 17 Sep 2003 02:47:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zW6a-0001lM-00; Wed, 17 Sep 2003 02:48:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19zW6a-0001lJ-00; Wed, 17 Sep 2003 02:48:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zW6b-0006Fl-NH; Wed, 17 Sep 2003 02: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 19zW60-0006Eq-NR for simple@optimus.ietf.org; Wed, 17 Sep 2003 02:47: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 CAA28795 for ; Wed, 17 Sep 2003 02:47:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zW5w-0001kr-00 for simple@ietf.org; Wed, 17 Sep 2003 02:47:21 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19zW5w-0001kR-00 for simple@ietf.org; Wed, 17 Sep 2003 02:47:20 -0400 Received: from dynamicsoft.com ([63.113.46.68]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h8H6knUg015887; Wed, 17 Sep 2003 02:46:50 -0400 (EDT) Message-ID: <3F680353.5020601@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne CC: Ben Campbell , hisham.khartabil@nokia.com, simple@ietf.org Subject: Re: [Simple] Re: [Geopriv] Individuals, hats and spheres References: <2038BCC78B1AD641891A0D1AE133DBB7017970C3@esebe019.ntc.nokia.com> <3F5F2A59.3050600@cs.columbia.edu> <3F61723B.401@dynamicsoft.com> <3F61F2F9.1060308@dynamicsoft.com> <3F61FA1F.7040705@cs.columbia.edu> <3F6218C4.6000503@dynamicsoft.com> <3F621F84.7090308@cs.columbia.edu> In-Reply-To: <3F621F84.7090308@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 17 Sep 2003 02:46:43 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > Jonathan Rosenberg wrote: > > >> If you want to communicate this to watchers, you need defined labels >> with clear semantics. Thats important for watchers that are automata, >> that wish to summarize, render, or do some kind of processing based on >> the information. > > > No disagreement. I just think that in some cases, we can't anticipate > the useful labels and so should allow for private-use labels. They may > well be informally defined within a user community, e.g., within a group > of friends or colleagues, just not registered with some central authority. Thats fine. There is precendent for processes where other namespaces can be used, and someone else can be the central point of definition for those namespaces. See rfc2506 for example. > > For example, in a different context, I think we discussed that a > hospital may well define a set of activity labels such as "performing > operation", "bedside", "on call", etc. These are neither IANA-registered > nor complete note-like free-for-alls. > > >>> The geopriv work (published and in-progress) allows some such >>> matching, based on time and geographic location of the >>> target/presentity. For simplicity, I suspect that only equality >>> matches based on tokens should be supported, rather than generic >>> expressions or, say, lists. >> >> >> >> I'm not sure what you mean here - how do lists come into play? > > > One could imagine a restriction such as > > "if parameter X has a set of values drawn from set {A,B,C}" > > this can always be decomposed into multiple rules, so this adds no > expressiveness, just reduces the number of rules, but makes the matching > messier. OK, makes sense. Do we have any kind of consensus that this sphere is good to have, and that is is both published->presence server and presence server-> watcher? -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Sep 17 03:03: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 DAA29328; Wed, 17 Sep 2003 03:03:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zWM6-0001wN-00; Wed, 17 Sep 2003 03:04:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19zWM6-0001wK-00; Wed, 17 Sep 2003 03:04:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zWM6-0006kV-Fm; Wed, 17 Sep 2003 03:04:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zWLW-0006js-De for simple@optimus.ietf.org; Wed, 17 Sep 2003 03:03:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29316 for ; Wed, 17 Sep 2003 03:03:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zWLS-0001vw-00 for simple@ietf.org; Wed, 17 Sep 2003 03:03:22 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19zWLR-0001vb-00 for simple@ietf.org; Wed, 17 Sep 2003 03:03:21 -0400 Received: from dynamicsoft.com ([63.113.46.68]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h8H72mUg015894; Wed, 17 Sep 2003 03:02:48 -0400 (EDT) Message-ID: <3F680711.8020708@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne CC: Markus.Isomaki@nokia.com, hisham.khartabil@nokia.com, simple@ietf.org References: <3F5DE35C.2020803@cs.columbia.edu> In-Reply-To: <3F5DE35C.2020803@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Re: Presence authorization conclusion? Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.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, 17 Sep 2003 03:02:41 -0400 Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > > > Markus.Isomaki@nokia.com wrote: > >> There has been further discussion whether (a subset of) XPath >> would be a good solution for this. It seems that it can express >> the needed statements. However, making a separate definition just >> for this need would at least make the rules more human-readable >> than the raw XPath expressions. Human readability is a red-herring IMHO. I have concerns about using *all* of xpath here, primarily centered around performance. Achieving xpath filtering operations at the scale required for presence is extremely challenging, and I do not think the generality justifies the cost in performance we would probably suffer. I honestly have not looked at performance of xpath implementations, but just from my own experiences with presence manipulation generally at large scale this seems like its going to be a real challenge. I would support a suitable subset, such that I could limit the set of things I could restrict in a reasonable fashion. > > > However, somebody soon has to step forward with such a proposal. So > far, I've seen variations on > > (1) any element named namespace:element, regardless of its position > in the document tree > > (2) specific element identified by parents, with namespace, but > without dealing with things like "3rd instance of element X" (so > far, none of the presence documents seem to allow repeats of the > same element at the same level of the tree) or "element having > value Y" or "element with attribute Z". > > If these are the only cases needed, something as simple as > > (1) *placetype (2) tuple/status/placetype > > would do. The only thing you can't do with that is to eliminate an entire tuple. Thats because tuples themselves are an example of a repeat of an element at the same level of tree. I would be comfortable deferring that capability though, and rather focus on the information in a tuple. If the authorization/filtering results in a tuple having no data, then the tuple is not sent. That said, it sounds like you just made a proposal above, and it works for me :) It is unclear to me how to refer to namespaces since > > urn:ietf:params:xml:ns:pidf:tuple/ > urn:ietf:params:xml:ns:pidf:status/ > urn:ietf:params:xml:ns:pidf:rpid-tuple:placetype > > doesn't cut it. I dug into xpath a bit. Its admittedly vague on this. I found this text in section 2.3: > A QName in the node test is expanded into an expanded-name using > the namespace declarations from the expression context. This is the > same way expansion is done for element type names in start and > end-tags except that the default namespace declared with xmlns is > not used: if the QName does not have a prefix, then the namespace > URI is null (this is the same way attribute names are expanded). It > is an error if the QName has a prefix for which there is no > namespace declaration in the expression context. THe key words here are "expression context". It seems that the assumption in xpath is that an xpath expression appears within an xml document, and so the normal xml mechanisms would be used to define context. For example: for us, that means that any usage where an xpath expression is provided has to be part of an xml document. For filters, its not a problem, since those are xml. For xcap, also not a problem, since the xcap is also xml and can provide namespace declarations. > > >> It seems that this is similar to what can be done with the >> "compound rules" in the current presence authorization XCAP >> proposal. > > > My concern about the compound rules is that they make > implementation rather hard. In particular, they make a database row > selection implementation impossible. I see the compound rules > approach as the dynamic, user-created version of what I had in > mind, namely something static, pre-defined that cannot be changed > by a ruleset. Right. I had also thought about that. Another bit of xcap is the ability for the server to declare "these are the permissions i support", and include a note, useful for a human, to define them. The server could advertise things like "friend", "colleague", etc. What is absent in the current proposal is a way of determining the specific presence data associated with that. However, I thought the idea with these is that they could handle more complex cases where the decisions werent just black/white on a specific element. For example, a "colleague" permission might permit the watcher to see select snipits of geoloc - whether I am physically at the office, and if not, if I am on a busines trip, THEN my location, but not otherwise. Those are fundamentally more complex than just database selection. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Sep 17 03:04:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29348 for ; Wed, 17 Sep 2003 03:04:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zWMB-0006lD-QC for simple-archive@odin.ietf.org; Wed, 17 Sep 2003 03:04:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8H747p1025987 for simple-archive@odin.ietf.org; Wed, 17 Sep 2003 03:04:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zWMB-0006l4-Aw for simple-web-archive@optimus.ietf.org; Wed, 17 Sep 2003 03:04: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 DAA29328; Wed, 17 Sep 2003 03:03:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zWM6-0001wN-00; Wed, 17 Sep 2003 03:04:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19zWM6-0001wK-00; Wed, 17 Sep 2003 03:04:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zWM6-0006kV-Fm; Wed, 17 Sep 2003 03:04:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zWLW-0006js-De for simple@optimus.ietf.org; Wed, 17 Sep 2003 03:03:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29316 for ; Wed, 17 Sep 2003 03:03:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zWLS-0001vw-00 for simple@ietf.org; Wed, 17 Sep 2003 03:03:22 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19zWLR-0001vb-00 for simple@ietf.org; Wed, 17 Sep 2003 03:03:21 -0400 Received: from dynamicsoft.com ([63.113.46.68]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h8H72mUg015894; Wed, 17 Sep 2003 03:02:48 -0400 (EDT) Message-ID: <3F680711.8020708@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne CC: Markus.Isomaki@nokia.com, hisham.khartabil@nokia.com, simple@ietf.org References: <3F5DE35C.2020803@cs.columbia.edu> In-Reply-To: <3F5DE35C.2020803@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Re: Presence authorization conclusion? Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.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, 17 Sep 2003 03:02:41 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > > > Markus.Isomaki@nokia.com wrote: > >> There has been further discussion whether (a subset of) XPath >> would be a good solution for this. It seems that it can express >> the needed statements. However, making a separate definition just >> for this need would at least make the rules more human-readable >> than the raw XPath expressions. Human readability is a red-herring IMHO. I have concerns about using *all* of xpath here, primarily centered around performance. Achieving xpath filtering operations at the scale required for presence is extremely challenging, and I do not think the generality justifies the cost in performance we would probably suffer. I honestly have not looked at performance of xpath implementations, but just from my own experiences with presence manipulation generally at large scale this seems like its going to be a real challenge. I would support a suitable subset, such that I could limit the set of things I could restrict in a reasonable fashion. > > > However, somebody soon has to step forward with such a proposal. So > far, I've seen variations on > > (1) any element named namespace:element, regardless of its position > in the document tree > > (2) specific element identified by parents, with namespace, but > without dealing with things like "3rd instance of element X" (so > far, none of the presence documents seem to allow repeats of the > same element at the same level of the tree) or "element having > value Y" or "element with attribute Z". > > If these are the only cases needed, something as simple as > > (1) *placetype (2) tuple/status/placetype > > would do. The only thing you can't do with that is to eliminate an entire tuple. Thats because tuples themselves are an example of a repeat of an element at the same level of tree. I would be comfortable deferring that capability though, and rather focus on the information in a tuple. If the authorization/filtering results in a tuple having no data, then the tuple is not sent. That said, it sounds like you just made a proposal above, and it works for me :) It is unclear to me how to refer to namespaces since > > urn:ietf:params:xml:ns:pidf:tuple/ > urn:ietf:params:xml:ns:pidf:status/ > urn:ietf:params:xml:ns:pidf:rpid-tuple:placetype > > doesn't cut it. I dug into xpath a bit. Its admittedly vague on this. I found this text in section 2.3: > A QName in the node test is expanded into an expanded-name using > the namespace declarations from the expression context. This is the > same way expansion is done for element type names in start and > end-tags except that the default namespace declared with xmlns is > not used: if the QName does not have a prefix, then the namespace > URI is null (this is the same way attribute names are expanded). It > is an error if the QName has a prefix for which there is no > namespace declaration in the expression context. THe key words here are "expression context". It seems that the assumption in xpath is that an xpath expression appears within an xml document, and so the normal xml mechanisms would be used to define context. For example: for us, that means that any usage where an xpath expression is provided has to be part of an xml document. For filters, its not a problem, since those are xml. For xcap, also not a problem, since the xcap is also xml and can provide namespace declarations. > > >> It seems that this is similar to what can be done with the >> "compound rules" in the current presence authorization XCAP >> proposal. > > > My concern about the compound rules is that they make > implementation rather hard. In particular, they make a database row > selection implementation impossible. I see the compound rules > approach as the dynamic, user-created version of what I had in > mind, namely something static, pre-defined that cannot be changed > by a ruleset. Right. I had also thought about that. Another bit of xcap is the ability for the server to declare "these are the permissions i support", and include a note, useful for a human, to define them. The server could advertise things like "friend", "colleague", etc. What is absent in the current proposal is a way of determining the specific presence data associated with that. However, I thought the idea with these is that they could handle more complex cases where the decisions werent just black/white on a specific element. For example, a "colleague" permission might permit the watcher to see select snipits of geoloc - whether I am physically at the office, and if not, if I am on a busines trip, THEN my location, but not otherwise. Those are fundamentally more complex than just database selection. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Sep 17 03:36:58 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29948; Wed, 17 Sep 2003 03:36:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zWs4-0002AE-00; Wed, 17 Sep 2003 03:37:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19zWs3-0002AA-00; Wed, 17 Sep 2003 03:37:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zWs3-00081Q-IF; Wed, 17 Sep 2003 03:37:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zWri-00080b-LZ for simple@optimus.ietf.org; Wed, 17 Sep 2003 03:36: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 DAA29931; Wed, 17 Sep 2003 03:36:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zWrf-00029o-00; Wed, 17 Sep 2003 03:36:39 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19zWrf-00029T-00; Wed, 17 Sep 2003 03:36:39 -0400 Received: from dynamicsoft.com ([63.113.46.68]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h8H7aGUg015911; Wed, 17 Sep 2003 03:36:16 -0400 (EDT) Message-ID: <3F680EE9.1040604@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hardie@qualcomm.com CC: geopriv@ietf.org, Simple WG References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Re: [Geopriv] A description of the relationship of permissions and rules. Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.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, 17 Sep 2003 03:36:09 -0400 Content-Transfer-Encoding: 7bit Ted, cc'ing SIMPLE since this is relevant to it. I was not at the interim, so I do not know the extent to which xcap was discussed. However, the model you propose below is EXACTLY, and I mean exactly, the model that is currently documented in http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-auth-usage-00.txt. Quoting from my document: > Structuring Presence Authorization > > This specification defines three application usages (each with their > own XML schema) that, put together, present a comprehensive solution > for allowing clients to specify authorization policies that a PA can > use when processing a subscription. The first of these application > usages has the AUID of permission-statements. This usage allows a > client to make statements about which permissions are granted to > which watchers. Each statement contains a definition of the watchers > to whom it applies, and then contains a list of permissions which are > granted to those watchers. The concept of a permission is central to > this specification. A permission is an atomic statement of consent or > denial. A permission can indicate a condition under which a > subscription is accepted or rejected, a condition under which a > notification is or is not sent, or a piece of information which is or > is not revealed in a presence document. The overall authorization for > a watcher is represented by the union of the permissions granted to > that watcher. I believe this is exactly what you are talking about. For presence, I have classified these permissions as: whether it is accepted or not (a binary permission) what the watcher can see when the watcher gets a notification transformations that get applied to the watcher To specify, for example, that Ted can subscribe to me and see my contact URI, basic presence, and rpid information: sip:joe@example.com urn:ietf:params:xml:ns:pidf urn:ietf:params:xml:ns:sip-rpids I explicitly chose this model because it had the crispest and easiest to process composition model. That was important since, for presence, the information sent to a watcher is going to be the combination of rules specified by the watcher and by the presentity (the source of the data in our terminology). This combination rule is most easily done when, as you say, its a basic set operation. If watcher asks for information X and the presentity has granted Y, the watcher will receive the intersection of X and Y. more inline: hardie@qualcomm.com wrote: > During the recent GeoPriv meeting Henning and Hannes presented > a model for understanding the application of the rules to location objects; > as part of that discussion, I agreed to write up a view of that > model seen through a very simple form of set theory (think elementary > Venn diagrams). Below is a first attempt to capture that view. > > In this conceptualization, the starting point is that the privacy > work of geopriv can be seen as populating a set of permissions > associated with a particular location object. That set of > permissions starts out empty. It is populated when the location > object contains statements which add permissions. From a logical > perspective, each location object contains 4 statements: > > 1) A statement granting permission to retain the object for some time. > > 2) A statement granting permission to distribute the object. > > 3) A statement granting a granularity of accuracy for the object. > > 4) A statement containing a URI at which further rules may be found. > > > One of the keys to this model is that any statement or rule must be > additive of permissions. An object may omit a particular statement, > but doing so means that no permission is granted or that the > protocol-defined > minimum is granted (for 3, as an example, the defined minimum for civil > location might be timezone, where the absence of the statement granting > permission to distribute means the object must not be distributed). An > object > may, of course, choose to contain a statement that means "no permission to > distribute" or "no permission to retain"; the ability to leave out the > bytes > carrying the assertion is an optimization, as the statement is logically > present. > > If there is a statement containing a URI at which further rules may > be found, those rules may add permissions to the statements asserted with > the location object, but they may never take permissions away. In > our Venn diagram set theory, in other words, when the conditions in > those rules are met (the right identity is presented or the right > time constraints are met, etc.), a new a set of permissions is granted, > and that set is unioned with the set carried in the object. > Note that this means if the statement containing the URI at which further > rules may be found cannot be dereferenced, then it is still safe to behave > according to the statements contained in the object, as these are the > baseline permissions. In cases where the dereferencing of this URI is > required for correct operation, these baselines are set to grant no > permissions, > so that the location object is not distributed or retained when the > dereferencing has not occurred. I had not considered this aspect; definitely a benefit of the model. > > Of those in the original formulation, then, a, b, c, and g are treated as > assertions. All of the other "rules" are actually mechanisms for > describing > specific conditions which modify the assertions of permitted retention, > distribution, > and granularity by unioning new permissions to those in the original > object. > > I believe this model has some advantages, particularly in that it makes the > default behavior relatively easy to explain ("anything not permitted is > denied, > and what has been permitted may not be later be denied"). There are some > potential gotchas, though, in that there is a risk of the model forcing the > number of assertions beyond the bounds of practical implementation. To > take > one of Jim Polk's examples: If an employee wishes to grant permission > beyond the baseline to all of her co-workers, a single assertion can work > by associating a specific identity to that pool. If she wants to grant > permission to all of her co-workers except one individual, for whom she > has taken out a restraining order, to achieve her goal she might need > to assert individual permissions for each of her remaining co-workers. > This > gets to the point of absurdity pretty quickly. The group at the interim > meeting agreed to think more about the use cases in which "except"-type > exclusions are required, and it also agreed that it might be the camels > nose for regex-type processing ("allow anyone who is presenting an identity > containing @example.com"), which we strongly felt to be beyond the scope > of work we can do quickly. We had this exact same discussion in SIMPLE. Our conclusion was the same - I would add except clauses to applies-to, so you could do things like: qualcomm.com hardie@qualcomm.com The basic processing is to compute the union of the identities defined by the inclusive applies-top operators (we defined them as , , and ) and then remove those specific by . > > The good news is that if we believe in the soundness of the fundamental > model, > we can publish documents describing the statements for retention, > distribution, > granularity, and naming of URIs without having completed the work on the > rules, > as we will be sure that the presence of the un-dereferenced URI will not > constitute > a privacy violation. I encountered one big snag in this model which I havent quite worked out. THe snag is what we are calling "transformational permissions". These are cases where I want to say "if my activity is 'busy', change it to 'idle'". Simply put - lying. I believe that lying will play a far more important role than omission of information, both in presence and geolocation. I don't know if this was discussed at the interim or not. Lying doesnt really fit into the model. Its not a permission in that it doesnt grant access to a piece of information fundamentally in the data. Rather, it asks for a change in that data. I could think of no other solution than to include explicitly defined ordering values that tell the server how to compose the information. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Sep 17 03:37:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29979 for ; Wed, 17 Sep 2003 03:37:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zWs8-00083s-I8 for simple-archive@odin.ietf.org; Wed, 17 Sep 2003 03:37:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8H7b8MS030969 for simple-archive@odin.ietf.org; Wed, 17 Sep 2003 03:37:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zWs7-000834-7p for simple-web-archive@optimus.ietf.org; Wed, 17 Sep 2003 03:37: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 DAA29948; Wed, 17 Sep 2003 03:36:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zWs4-0002AE-00; Wed, 17 Sep 2003 03:37:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19zWs3-0002AA-00; Wed, 17 Sep 2003 03:37:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zWs3-00081Q-IF; Wed, 17 Sep 2003 03:37:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zWri-00080b-LZ for simple@optimus.ietf.org; Wed, 17 Sep 2003 03:36: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 DAA29931; Wed, 17 Sep 2003 03:36:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zWrf-00029o-00; Wed, 17 Sep 2003 03:36:39 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19zWrf-00029T-00; Wed, 17 Sep 2003 03:36:39 -0400 Received: from dynamicsoft.com ([63.113.46.68]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h8H7aGUg015911; Wed, 17 Sep 2003 03:36:16 -0400 (EDT) Message-ID: <3F680EE9.1040604@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hardie@qualcomm.com CC: geopriv@ietf.org, Simple WG References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Re: [Geopriv] A description of the relationship of permissions and rules. Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.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, 17 Sep 2003 03:36:09 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Ted, cc'ing SIMPLE since this is relevant to it. I was not at the interim, so I do not know the extent to which xcap was discussed. However, the model you propose below is EXACTLY, and I mean exactly, the model that is currently documented in http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-auth-usage-00.txt. Quoting from my document: > Structuring Presence Authorization > > This specification defines three application usages (each with their > own XML schema) that, put together, present a comprehensive solution > for allowing clients to specify authorization policies that a PA can > use when processing a subscription. The first of these application > usages has the AUID of permission-statements. This usage allows a > client to make statements about which permissions are granted to > which watchers. Each statement contains a definition of the watchers > to whom it applies, and then contains a list of permissions which are > granted to those watchers. The concept of a permission is central to > this specification. A permission is an atomic statement of consent or > denial. A permission can indicate a condition under which a > subscription is accepted or rejected, a condition under which a > notification is or is not sent, or a piece of information which is or > is not revealed in a presence document. The overall authorization for > a watcher is represented by the union of the permissions granted to > that watcher. I believe this is exactly what you are talking about. For presence, I have classified these permissions as: whether it is accepted or not (a binary permission) what the watcher can see when the watcher gets a notification transformations that get applied to the watcher To specify, for example, that Ted can subscribe to me and see my contact URI, basic presence, and rpid information: sip:joe@example.com urn:ietf:params:xml:ns:pidf urn:ietf:params:xml:ns:sip-rpids I explicitly chose this model because it had the crispest and easiest to process composition model. That was important since, for presence, the information sent to a watcher is going to be the combination of rules specified by the watcher and by the presentity (the source of the data in our terminology). This combination rule is most easily done when, as you say, its a basic set operation. If watcher asks for information X and the presentity has granted Y, the watcher will receive the intersection of X and Y. more inline: hardie@qualcomm.com wrote: > During the recent GeoPriv meeting Henning and Hannes presented > a model for understanding the application of the rules to location objects; > as part of that discussion, I agreed to write up a view of that > model seen through a very simple form of set theory (think elementary > Venn diagrams). Below is a first attempt to capture that view. > > In this conceptualization, the starting point is that the privacy > work of geopriv can be seen as populating a set of permissions > associated with a particular location object. That set of > permissions starts out empty. It is populated when the location > object contains statements which add permissions. From a logical > perspective, each location object contains 4 statements: > > 1) A statement granting permission to retain the object for some time. > > 2) A statement granting permission to distribute the object. > > 3) A statement granting a granularity of accuracy for the object. > > 4) A statement containing a URI at which further rules may be found. > > > One of the keys to this model is that any statement or rule must be > additive of permissions. An object may omit a particular statement, > but doing so means that no permission is granted or that the > protocol-defined > minimum is granted (for 3, as an example, the defined minimum for civil > location might be timezone, where the absence of the statement granting > permission to distribute means the object must not be distributed). An > object > may, of course, choose to contain a statement that means "no permission to > distribute" or "no permission to retain"; the ability to leave out the > bytes > carrying the assertion is an optimization, as the statement is logically > present. > > If there is a statement containing a URI at which further rules may > be found, those rules may add permissions to the statements asserted with > the location object, but they may never take permissions away. In > our Venn diagram set theory, in other words, when the conditions in > those rules are met (the right identity is presented or the right > time constraints are met, etc.), a new a set of permissions is granted, > and that set is unioned with the set carried in the object. > Note that this means if the statement containing the URI at which further > rules may be found cannot be dereferenced, then it is still safe to behave > according to the statements contained in the object, as these are the > baseline permissions. In cases where the dereferencing of this URI is > required for correct operation, these baselines are set to grant no > permissions, > so that the location object is not distributed or retained when the > dereferencing has not occurred. I had not considered this aspect; definitely a benefit of the model. > > Of those in the original formulation, then, a, b, c, and g are treated as > assertions. All of the other "rules" are actually mechanisms for > describing > specific conditions which modify the assertions of permitted retention, > distribution, > and granularity by unioning new permissions to those in the original > object. > > I believe this model has some advantages, particularly in that it makes the > default behavior relatively easy to explain ("anything not permitted is > denied, > and what has been permitted may not be later be denied"). There are some > potential gotchas, though, in that there is a risk of the model forcing the > number of assertions beyond the bounds of practical implementation. To > take > one of Jim Polk's examples: If an employee wishes to grant permission > beyond the baseline to all of her co-workers, a single assertion can work > by associating a specific identity to that pool. If she wants to grant > permission to all of her co-workers except one individual, for whom she > has taken out a restraining order, to achieve her goal she might need > to assert individual permissions for each of her remaining co-workers. > This > gets to the point of absurdity pretty quickly. The group at the interim > meeting agreed to think more about the use cases in which "except"-type > exclusions are required, and it also agreed that it might be the camels > nose for regex-type processing ("allow anyone who is presenting an identity > containing @example.com"), which we strongly felt to be beyond the scope > of work we can do quickly. We had this exact same discussion in SIMPLE. Our conclusion was the same - I would add except clauses to applies-to, so you could do things like: qualcomm.com hardie@qualcomm.com The basic processing is to compute the union of the identities defined by the inclusive applies-top operators (we defined them as , , and ) and then remove those specific by . > > The good news is that if we believe in the soundness of the fundamental > model, > we can publish documents describing the statements for retention, > distribution, > granularity, and naming of URIs without having completed the work on the > rules, > as we will be sure that the presence of the un-dereferenced URI will not > constitute > a privacy violation. I encountered one big snag in this model which I havent quite worked out. THe snag is what we are calling "transformational permissions". These are cases where I want to say "if my activity is 'busy', change it to 'idle'". Simply put - lying. I believe that lying will play a far more important role than omission of information, both in presence and geolocation. I don't know if this was discussed at the interim or not. Lying doesnt really fit into the model. Its not a permission in that it doesnt grant access to a piece of information fundamentally in the data. Rather, it asks for a change in that data. I could think of no other solution than to include explicitly defined ordering values that tell the server how to compose the information. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Sep 17 04:11:56 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 EAA00819; Wed, 17 Sep 2003 04:11:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zXPu-0002Sg-00; Wed, 17 Sep 2003 04:12:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19zXPu-0002Sd-00; Wed, 17 Sep 2003 04: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 19zXPt-00017t-LB; Wed, 17 Sep 2003 04:12:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zXOv-00016d-VT for simple@optimus.ietf.org; Wed, 17 Sep 2003 04:11:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00784 for ; Wed, 17 Sep 2003 04:10:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zXOt-0002S8-00 for simple@ietf.org; Wed, 17 Sep 2003 04:10:59 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19zXOs-0002Rn-00 for simple@ietf.org; Wed, 17 Sep 2003 04:10:58 -0400 Received: from dynamicsoft.com ([63.113.46.68]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h8H8ATUg015947; Wed, 17 Sep 2003 04:10:29 -0400 (EDT) Message-ID: <3F6816EE.8050700@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: hgs@cs.columbia.edu, simple@ietf.org, gk@ninebynine.org Subject: Re: [Simple] [Fwd: Re: NETCONF WG meeting minutes for IETF #57] References: <2038BCC78B1AD641891A0D1AE133DBB701797080@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701797080@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: Wed, 17 Sep 2003 04:10:22 -0400 Content-Transfer-Encoding: 7bit One comment inline: hisham.khartabil@nokia.com wrote: >> Another issue I have is that an xpath expression would only allow >> you to block information from appearing in places where you are >> aware it can be placed. Let me give a concrete example. A user, >> Joe, doesn't want the PA to reveal to anyone his placetype >> information. Assuming an xpath based mechanism in xcap, he would >> tell the server to block out information that matched the >> expression "presence/tuple/status/placetype", which will stop all >> placetype elements from being sent in any tuple. Now, the next >> week, the PA is upgraded to support a new "future-status" >> capability, which conveys information on where the presentity >> will be in the future. This future-status appears as a peer >> element to status, and can contain anything status can. The PA, >> now upgraded, extracts information from the user's calendar and >> now places the placetype attribute there. This information is NOT >> blocked by the previous expression. The user's client would need >> to know that it has to add another xpath expression, >> "presence/tuple/future-status/placetype", to block this >> information. But, the client hasn't been upgraded, so it never >> knows. > > > This might be true to authorisation where the presentity wants to > block certain information from being unwillingly delivered to > watchers (keeping requirements issues aside for now). But with > filtering, the watcher selects information it wants to see, not > block. In this case, the implementation at the watcher side better > know how to render this presence information, delivered by the PA, > to the watcher (end user). Therefore it can only ask for presence > info in an xml document it understands. I dont agree that filters are only about watchers asking for things they want. It seems perfectly reasonable to me for a watcher to say "give me everything but geolocation information", because it does in fact understand geoloc (and other things too), but just doesnt want that information. That said, I'm now convinced (and already indicated in other emails) that it is appropriate to base filters and authorization policiies on xpath style addressing (though a subset for performance reasons). However I view it as incomplete, as it doesnt adequately address more complex permissions or filters that are more than just blocking/permitting elements. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Sep 17 04:12:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00838 for ; Wed, 17 Sep 2003 04:12:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zXPy-0001B1-SW for simple-archive@odin.ietf.org; Wed, 17 Sep 2003 04:12:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8H8C6Ao004496 for simple-archive@odin.ietf.org; Wed, 17 Sep 2003 04:12:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zXPx-0001AB-Lw for simple-web-archive@optimus.ietf.org; Wed, 17 Sep 2003 04:12:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00819; Wed, 17 Sep 2003 04:11:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zXPu-0002Sg-00; Wed, 17 Sep 2003 04:12:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19zXPu-0002Sd-00; Wed, 17 Sep 2003 04: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 19zXPt-00017t-LB; Wed, 17 Sep 2003 04:12:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zXOv-00016d-VT for simple@optimus.ietf.org; Wed, 17 Sep 2003 04:11:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00784 for ; Wed, 17 Sep 2003 04:10:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zXOt-0002S8-00 for simple@ietf.org; Wed, 17 Sep 2003 04:10:59 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19zXOs-0002Rn-00 for simple@ietf.org; Wed, 17 Sep 2003 04:10:58 -0400 Received: from dynamicsoft.com ([63.113.46.68]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h8H8ATUg015947; Wed, 17 Sep 2003 04:10:29 -0400 (EDT) Message-ID: <3F6816EE.8050700@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: hgs@cs.columbia.edu, simple@ietf.org, gk@ninebynine.org Subject: Re: [Simple] [Fwd: Re: NETCONF WG meeting minutes for IETF #57] References: <2038BCC78B1AD641891A0D1AE133DBB701797080@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701797080@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: Wed, 17 Sep 2003 04:10:22 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit One comment inline: hisham.khartabil@nokia.com wrote: >> Another issue I have is that an xpath expression would only allow >> you to block information from appearing in places where you are >> aware it can be placed. Let me give a concrete example. A user, >> Joe, doesn't want the PA to reveal to anyone his placetype >> information. Assuming an xpath based mechanism in xcap, he would >> tell the server to block out information that matched the >> expression "presence/tuple/status/placetype", which will stop all >> placetype elements from being sent in any tuple. Now, the next >> week, the PA is upgraded to support a new "future-status" >> capability, which conveys information on where the presentity >> will be in the future. This future-status appears as a peer >> element to status, and can contain anything status can. The PA, >> now upgraded, extracts information from the user's calendar and >> now places the placetype attribute there. This information is NOT >> blocked by the previous expression. The user's client would need >> to know that it has to add another xpath expression, >> "presence/tuple/future-status/placetype", to block this >> information. But, the client hasn't been upgraded, so it never >> knows. > > > This might be true to authorisation where the presentity wants to > block certain information from being unwillingly delivered to > watchers (keeping requirements issues aside for now). But with > filtering, the watcher selects information it wants to see, not > block. In this case, the implementation at the watcher side better > know how to render this presence information, delivered by the PA, > to the watcher (end user). Therefore it can only ask for presence > info in an xml document it understands. I dont agree that filters are only about watchers asking for things they want. It seems perfectly reasonable to me for a watcher to say "give me everything but geolocation information", because it does in fact understand geoloc (and other things too), but just doesnt want that information. That said, I'm now convinced (and already indicated in other emails) that it is appropriate to base filters and authorization policiies on xpath style addressing (though a subset for performance reasons). However I view it as incomplete, as it doesnt adequately address more complex permissions or filters that are more than just blocking/permitting elements. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Sep 17 04:35: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 EAA01445; Wed, 17 Sep 2003 04:35:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zXmD-0002fD-00; Wed, 17 Sep 2003 04:35:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19zXmD-0002fA-00; Wed, 17 Sep 2003 04:35:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zXmE-0001sA-Gb; Wed, 17 Sep 2003 04:35:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zXlH-0001rB-Il for simple@optimus.ietf.org; Wed, 17 Sep 2003 04:34:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01441 for ; Wed, 17 Sep 2003 04:33:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zXlE-0002ez-00 for simple@ietf.org; Wed, 17 Sep 2003 04:34:04 -0400 Received: from news.ubiquity.net ([194.202.146.92] helo=gbnewp0186s1.eu.ubiquity.net) by ietf-mx with smtp (Exim 4.12) id 19zXlE-0002eu-00 for simple@ietf.org; Wed, 17 Sep 2003 04:34:04 -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; Wed, 17 Sep 2003 09:36:48 +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="utf-8" Content-Transfer-Encoding: base64 Subject: RE: [Simple] Default 1 minute inactivity timer in MSRP Message-ID: <45730E094814E44488F789C1CDED27AE0219B0B1@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [Simple] Default 1 minute inactivity timer in MSRP Thread-Index: AcN8hPhP5VfcPy09QZy9gQlL3zmHfAAcSAO3 From: "Chris Boulton" To: "Cullen Jennings" , "Ben Campbell" , "Adam Roach" Cc: "Miguel A. Garcia" , Content-Transfer-Encoding: base64 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.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, 17 Sep 2003 09:33:29 +0100 Content-Transfer-Encoding: base64 SSB0aG91Z2h0IHRoZSBtYWluIGRyaXZlciBmb3QgdGhpcyB3ZXJlIG5ldHdvcmtzIHdoZXJlIGNh cnJpZXJzIGFyZSBjaGFyZ2luZyBvbiBhICdwZXItYnl0ZScgYmFzaXMuICBZZXMgSSBhZ3JlZSB0 aGUgaW1wYWN0IHdvdWxkIGJlIG1pbmltYWwgQlVUIHRoZXJlIHNob3VsZCBiZSBubyByZWFsIGNo YXJnaW5nIGltcGFjdC4NCiANCkNocmlzLg0KIA0KDQoJLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0gDQoJRnJvbTogQ3VsbGVuIEplbm5pbmdzIFttYWlsdG86Zmx1ZmZ5QGNpc2NvLmNvbV0gDQoJ U2VudDogVHVlIDE2LzA5LzIwMDMgMjA6MDIgDQoJVG86IENocmlzIEJvdWx0b247IEJlbiBDYW1w YmVsbDsgQWRhbSBSb2FjaCANCglDYzogTWlndWVsIEEuIEdhcmNpYTsgc2ltcGxlQGlldGYub3Jn IA0KCVN1YmplY3Q6IFJlOiBbU2ltcGxlXSBEZWZhdWx0IDEgbWludXRlIGluYWN0aXZpdHkgdGlt ZXIgaW4gTVNSUA0KCQ0KCQ0KDQoNCglJIHRoaW5rIHRoaW5ncyBiZXR3ZWVuIDEgYW5kIDYwIHNv dW5kIHByZXR0eSBnb29kIGJ1dCAuLi4NCgkNCglXaGF0IHdlIHJlYWxseSBuZWVkIGhlcmUgaXMg YW4gYXJndW1lbnQgd2h5IHNvbWUgbnVtYmVyIHggaXMgYSBnb29kIG51bWJlci4NCgkNCglDdWxs ZW4NCgkNCgkNCglPbiA5LzExLzAzIDExOjA4LCAiQ2hyaXMgQm91bHRvbiIgPGNib3VsdG9uQHVi aXF1aXR5Lm5ldD4gd3JvdGU6DQoJDQoJPiBvayAtIElmIGl0IG11c3QgYmUgaGlzIG1ldGhvZCBJ J2xsIHNlZSBBZGFtcyBiaWQgb2YgMTIgKGFuZCBtYXliZSBldmVuIHJhaXNlDQoJPiBpdCA7LSkg LiAgSSB0aGluayB0aGF0IGl0IGlzIGEgZ29vZCBjb21wcm9taXNlIG9mIHRyYWZmaWMgdnMgc2Vz c2lvbiBjbGVhbiB1cC4NCgk+DQoJPiBDaHJpcy4NCgk+DQoJPg0KCT4gLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCgk+IEZyb206IEJlbiBDYW1wYmVsbCBbbWFpbHRvOmJjYW1wYmVsbEBkeW5h bWljc29mdC5jb21dDQoJPiBTZW50OiBUaHUgMTEvMDkvMjAwMyAxODoxNg0KCT4gVG86IEFkYW0g Um9hY2gNCgk+IENjOiBNaWd1ZWwgQS4gR2FyY2lhOyBzaW1wbGVAaWV0Zi5vcmcNCgk+IFN1Ympl Y3Q6IFJlOiBbU2ltcGxlXSBEZWZhdWx0IDEgbWludXRlIGluYWN0aXZpdHkgdGltZXIgaW4gTVNS UA0KCT4NCgk+DQoJPg0KCT4gT24gcmVmbGVjdGlvbiwgSSB0aGluayBJIGFncmVlIHRoYXQgYSBo aWdoZXIgdmFsdWUgdGhhbiAxIG1pbnV0ZSBtYWtlcw0KCT4gc2Vuc2UuIE9uZSB1c2UgY2FzZSBJ IGV4cGVjdCB0byBzZWUgYSBsb3QgZm9yIG1lc3NhZ2Ugc2Vzc2lvbnMgaXMgdGhlDQoJPiBjaGF0 IHJvb20sIG9yIHRleHQgY29uZmVyZW5jZSwgd2hlcmUgaXQgd2lsbCBiZSBjb21tb24gZm9yIG9u ZQ0KCT4gcGFydGljaXBhbnQgdG8gcmVjZWl2ZSBhIGxvdCBtb3JlIHRoYW4gdGhleSBzZW5kLg0K CT4NCgk+IE9mIGNvdXJzZSwgYXQgdGhlIHNhbWUgdGltZSwgbGFyZ2VyIG51bWJlcnMgcmVkdWNl IHRoZSBhYmlsaXR5IG9mIGENCgk+IHJlbGF5IHRvIHBydW5lIGRlYWQgc2Vzc2lvbnMuDQoJPg0K CT4gU28gSSBiaWQgNSBtaW51dGVzLg0KCT4NCgk+IEFkYW0gUm9hY2ggd3JvdGU6DQoJPj4gQmVu IENhbXBiZWxsIFttYWlsdG86YmNhbXBiZWxsQGR5bmFtaWNzb2Z0LmNvbV0gd3JpdGVzOg0KCT4+ DQoJPj4NCgk+Pj4gMSkgRG8gb3RoZXJzIGFncmVlIHdpdGggTWlndWVsIHRoYXQgd2Ugc2hvdWxk IG1ha2UgdGhlIGluYWN0aXZpdHkNCgk+Pj4gdGltZW91dCBuZWdvdGlhYmxlPw0KCT4+DQoJPj4N Cgk+PiBIYXZpbmcgdHJpZWQgdG8gZ28gZG93biB0aGlzIHBhdGggc2V2ZXJhbCB0aW1lcywgSSB3 YW50IHRvDQoJPj4gZW1waGFzaXplIHRoYXQgSSBhbSB2ZXJ5IHN0cm9uZ2x5IG9wcG9zZWQgdG8g YW55IG1lY2hhbmlzbQ0KCT4+IGZvciBuZWdvdGlhdGlvbiBvZiB0aGlzIHRpbWVvdXQuDQoJPj4N Cgk+Pg0KCT4+PiAyKSBJZiBub3QsIGNhbiBhbnlvbmUgc3VnZ2VzdCBhIGJldHRlciB3YXkgdG8g Y2hvb3NlIHRoZQ0KCT4+PiBzdGFuZGFyZCB2YWx1ZT8NCgk+Pg0KCT4+DQoJPj4gTm9wZS4gT25l IG1pbnV0ZSBzb3VuZHMgZ29vZC4gT25lIGhvdXIgc291bmRzIGdvb2QuIEkgZG9uJ3QNCgk+PiB0 aGluayBJJ2Qgd2FudCB0byBnbyBtdWNoIG91dHNpZGUgdGhhdCByYW5nZS4NCgk+Pg0KCT4+IEhv d2V2ZXIsIGl0IHNvdW5kcyBsaWtlIHRoZXJlJ3Mgc29tZSBvYmplY3Rpb24gdG8gc29tZXRoaW5n DQoJPj4gYXMgc21hbGwgYXMgb25lIG1pbnV0ZSwgc28gd2UgbmVlZCB0byBuZWdvdGlhdGUgYW4g YXJiaXRyYXJ5DQoJPj4gdmFsdWUgaGVyZSBvbiB0aGUgbGlzdC4gSSdsbCBzdGFydCB0aGUgYmlk ZGluZyBhdCB0d2VsdmUNCgk+PiBtaW51dGVzLg0KCT4+DQoJPj4gL2ENCgk+DQoJPg0KCT4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCgk+IFNpbXBsZSBt YWlsaW5nIGxpc3QNCgk+IFNpbXBsZUBpZXRmLm9yZw0KCT4gaHR0cHM6Ly93d3cxLmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vc2ltcGxlDQoJPg0KCT4NCgk+IEopDQoJDQoJDQoNCg== _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Sep 17 04:35:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01472 for ; Wed, 17 Sep 2003 04:35:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zXmH-0001tr-Nj for simple-archive@odin.ietf.org; Wed, 17 Sep 2003 04:35:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8H8Z9OL007302 for simple-archive@odin.ietf.org; Wed, 17 Sep 2003 04:35:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zXmH-0001th-92 for simple-web-archive@optimus.ietf.org; Wed, 17 Sep 2003 04:35: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 EAA01445; Wed, 17 Sep 2003 04:35:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zXmD-0002fD-00; Wed, 17 Sep 2003 04:35:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19zXmD-0002fA-00; Wed, 17 Sep 2003 04:35:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zXmE-0001sA-Gb; Wed, 17 Sep 2003 04:35:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zXlH-0001rB-Il for simple@optimus.ietf.org; Wed, 17 Sep 2003 04:34:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01441 for ; Wed, 17 Sep 2003 04:33:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zXlE-0002ez-00 for simple@ietf.org; Wed, 17 Sep 2003 04:34:04 -0400 Received: from news.ubiquity.net ([194.202.146.92] helo=gbnewp0186s1.eu.ubiquity.net) by ietf-mx with smtp (Exim 4.12) id 19zXlE-0002eu-00 for simple@ietf.org; Wed, 17 Sep 2003 04:34:04 -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; Wed, 17 Sep 2003 09:36:48 +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="utf-8" Content-Transfer-Encoding: base64 Subject: RE: [Simple] Default 1 minute inactivity timer in MSRP Message-ID: <45730E094814E44488F789C1CDED27AE0219B0B1@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [Simple] Default 1 minute inactivity timer in MSRP Thread-Index: AcN8hPhP5VfcPy09QZy9gQlL3zmHfAAcSAO3 From: "Chris Boulton" To: "Cullen Jennings" , "Ben Campbell" , "Adam Roach" Cc: "Miguel A. Garcia" , Content-Transfer-Encoding: base64 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.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, 17 Sep 2003 09:33:29 +0100 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 SSB0aG91Z2h0IHRoZSBtYWluIGRyaXZlciBmb3QgdGhpcyB3ZXJlIG5ldHdvcmtzIHdoZXJlIGNh cnJpZXJzIGFyZSBjaGFyZ2luZyBvbiBhICdwZXItYnl0ZScgYmFzaXMuICBZZXMgSSBhZ3JlZSB0 aGUgaW1wYWN0IHdvdWxkIGJlIG1pbmltYWwgQlVUIHRoZXJlIHNob3VsZCBiZSBubyByZWFsIGNo YXJnaW5nIGltcGFjdC4NCiANCkNocmlzLg0KIA0KDQoJLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0gDQoJRnJvbTogQ3VsbGVuIEplbm5pbmdzIFttYWlsdG86Zmx1ZmZ5QGNpc2NvLmNvbV0gDQoJ U2VudDogVHVlIDE2LzA5LzIwMDMgMjA6MDIgDQoJVG86IENocmlzIEJvdWx0b247IEJlbiBDYW1w YmVsbDsgQWRhbSBSb2FjaCANCglDYzogTWlndWVsIEEuIEdhcmNpYTsgc2ltcGxlQGlldGYub3Jn IA0KCVN1YmplY3Q6IFJlOiBbU2ltcGxlXSBEZWZhdWx0IDEgbWludXRlIGluYWN0aXZpdHkgdGlt ZXIgaW4gTVNSUA0KCQ0KCQ0KDQoNCglJIHRoaW5rIHRoaW5ncyBiZXR3ZWVuIDEgYW5kIDYwIHNv dW5kIHByZXR0eSBnb29kIGJ1dCAuLi4NCgkNCglXaGF0IHdlIHJlYWxseSBuZWVkIGhlcmUgaXMg YW4gYXJndW1lbnQgd2h5IHNvbWUgbnVtYmVyIHggaXMgYSBnb29kIG51bWJlci4NCgkNCglDdWxs ZW4NCgkNCgkNCglPbiA5LzExLzAzIDExOjA4LCAiQ2hyaXMgQm91bHRvbiIgPGNib3VsdG9uQHVi aXF1aXR5Lm5ldD4gd3JvdGU6DQoJDQoJPiBvayAtIElmIGl0IG11c3QgYmUgaGlzIG1ldGhvZCBJ J2xsIHNlZSBBZGFtcyBiaWQgb2YgMTIgKGFuZCBtYXliZSBldmVuIHJhaXNlDQoJPiBpdCA7LSkg LiAgSSB0aGluayB0aGF0IGl0IGlzIGEgZ29vZCBjb21wcm9taXNlIG9mIHRyYWZmaWMgdnMgc2Vz c2lvbiBjbGVhbiB1cC4NCgk+DQoJPiBDaHJpcy4NCgk+DQoJPg0KCT4gLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCgk+IEZyb206IEJlbiBDYW1wYmVsbCBbbWFpbHRvOmJjYW1wYmVsbEBkeW5h bWljc29mdC5jb21dDQoJPiBTZW50OiBUaHUgMTEvMDkvMjAwMyAxODoxNg0KCT4gVG86IEFkYW0g Um9hY2gNCgk+IENjOiBNaWd1ZWwgQS4gR2FyY2lhOyBzaW1wbGVAaWV0Zi5vcmcNCgk+IFN1Ympl Y3Q6IFJlOiBbU2ltcGxlXSBEZWZhdWx0IDEgbWludXRlIGluYWN0aXZpdHkgdGltZXIgaW4gTVNS UA0KCT4NCgk+DQoJPg0KCT4gT24gcmVmbGVjdGlvbiwgSSB0aGluayBJIGFncmVlIHRoYXQgYSBo aWdoZXIgdmFsdWUgdGhhbiAxIG1pbnV0ZSBtYWtlcw0KCT4gc2Vuc2UuIE9uZSB1c2UgY2FzZSBJ IGV4cGVjdCB0byBzZWUgYSBsb3QgZm9yIG1lc3NhZ2Ugc2Vzc2lvbnMgaXMgdGhlDQoJPiBjaGF0 IHJvb20sIG9yIHRleHQgY29uZmVyZW5jZSwgd2hlcmUgaXQgd2lsbCBiZSBjb21tb24gZm9yIG9u ZQ0KCT4gcGFydGljaXBhbnQgdG8gcmVjZWl2ZSBhIGxvdCBtb3JlIHRoYW4gdGhleSBzZW5kLg0K CT4NCgk+IE9mIGNvdXJzZSwgYXQgdGhlIHNhbWUgdGltZSwgbGFyZ2VyIG51bWJlcnMgcmVkdWNl IHRoZSBhYmlsaXR5IG9mIGENCgk+IHJlbGF5IHRvIHBydW5lIGRlYWQgc2Vzc2lvbnMuDQoJPg0K CT4gU28gSSBiaWQgNSBtaW51dGVzLg0KCT4NCgk+IEFkYW0gUm9hY2ggd3JvdGU6DQoJPj4gQmVu IENhbXBiZWxsIFttYWlsdG86YmNhbXBiZWxsQGR5bmFtaWNzb2Z0LmNvbV0gd3JpdGVzOg0KCT4+ DQoJPj4NCgk+Pj4gMSkgRG8gb3RoZXJzIGFncmVlIHdpdGggTWlndWVsIHRoYXQgd2Ugc2hvdWxk IG1ha2UgdGhlIGluYWN0aXZpdHkNCgk+Pj4gdGltZW91dCBuZWdvdGlhYmxlPw0KCT4+DQoJPj4N Cgk+PiBIYXZpbmcgdHJpZWQgdG8gZ28gZG93biB0aGlzIHBhdGggc2V2ZXJhbCB0aW1lcywgSSB3 YW50IHRvDQoJPj4gZW1waGFzaXplIHRoYXQgSSBhbSB2ZXJ5IHN0cm9uZ2x5IG9wcG9zZWQgdG8g YW55IG1lY2hhbmlzbQ0KCT4+IGZvciBuZWdvdGlhdGlvbiBvZiB0aGlzIHRpbWVvdXQuDQoJPj4N Cgk+Pg0KCT4+PiAyKSBJZiBub3QsIGNhbiBhbnlvbmUgc3VnZ2VzdCBhIGJldHRlciB3YXkgdG8g Y2hvb3NlIHRoZQ0KCT4+PiBzdGFuZGFyZCB2YWx1ZT8NCgk+Pg0KCT4+DQoJPj4gTm9wZS4gT25l IG1pbnV0ZSBzb3VuZHMgZ29vZC4gT25lIGhvdXIgc291bmRzIGdvb2QuIEkgZG9uJ3QNCgk+PiB0 aGluayBJJ2Qgd2FudCB0byBnbyBtdWNoIG91dHNpZGUgdGhhdCByYW5nZS4NCgk+Pg0KCT4+IEhv d2V2ZXIsIGl0IHNvdW5kcyBsaWtlIHRoZXJlJ3Mgc29tZSBvYmplY3Rpb24gdG8gc29tZXRoaW5n DQoJPj4gYXMgc21hbGwgYXMgb25lIG1pbnV0ZSwgc28gd2UgbmVlZCB0byBuZWdvdGlhdGUgYW4g YXJiaXRyYXJ5DQoJPj4gdmFsdWUgaGVyZSBvbiB0aGUgbGlzdC4gSSdsbCBzdGFydCB0aGUgYmlk ZGluZyBhdCB0d2VsdmUNCgk+PiBtaW51dGVzLg0KCT4+DQoJPj4gL2ENCgk+DQoJPg0KCT4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCgk+IFNpbXBsZSBt YWlsaW5nIGxpc3QNCgk+IFNpbXBsZUBpZXRmLm9yZw0KCT4gaHR0cHM6Ly93d3cxLmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vc2ltcGxlDQoJPg0KCT4NCgk+IEopDQoJDQoJDQoNCg== _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Sep 17 06:18:57 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04081; Wed, 17 Sep 2003 06:18:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zZOp-0003hK-00; Wed, 17 Sep 2003 06:19:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19zZOp-0003hH-00; Wed, 17 Sep 2003 06:19:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zZOo-0005iM-Ko; Wed, 17 Sep 2003 06:19:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zZOb-0005hk-Mz for simple@optimus.ietf.org; Wed, 17 Sep 2003 06:18: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 GAA04059 for ; Wed, 17 Sep 2003 06:18:39 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zZOX-0003go-00 for simple@ietf.org; Wed, 17 Sep 2003 06:18:45 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19zZOW-0003gk-00 for simple@ietf.org; Wed, 17 Sep 2003 06:18:45 -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 h8HAIh404407 for ; Wed, 17 Sep 2003 13:18:44 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 17 Sep 2003 13:18:42 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 17 Sep 2003 13:18: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] [Fwd: Re: NETCONF WG meeting minutes for IETF #57] Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017970FD@esebe019.ntc.nokia.com> Thread-Topic: [Simple] [Fwd: Re: NETCONF WG meeting minutes for IETF #57] Thread-Index: AcN880oie6UDDhLmTV6bNtmR0VU2GAADSadw To: Cc: , , X-OriginalArrivalTime: 17 Sep 2003 10:18:42.0571 (UTC) FILETIME=[11EF4DB0:01C37D05] 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, 17 Sep 2003 13:13:48 +0300 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Wednesday, September 17, 2003 11:10 AM > To: Khartabil Hisham (NMP-MSW/Helsinki) > Cc: hgs@cs.columbia.edu; simple@ietf.org; gk@ninebynine.org > Subject: Re: [Simple] [Fwd: Re: NETCONF WG meeting minutes=20 > for IETF #57] >=20 > > This might be true to authorisation where the presentity wants to > > block certain information from being unwillingly delivered to > > watchers (keeping requirements issues aside for now). But with > > filtering, the watcher selects information it wants to see, not > > block. In this case, the implementation at the watcher side better > > know how to render this presence information, delivered by the PA, > > to the watcher (end user). Therefore it can only ask for presence > > info in an xml document it understands. >=20 > I dont agree that filters are only about watchers asking for things=20 > they want. It seems perfectly reasonable to me for a watcher to say=20 > "give me everything but geolocation information", because it does in=20 > fact understand geoloc (and other things too), but just doesnt want=20 > that information. Ok, I was thinking that this could be done by listing all the wanted = elements, which it turn eliminates the unwanted ones. But we can add = explicit support for excluding elements. >=20 > That said, I'm now convinced (and already indicated in other emails)=20 > that it is appropriate to base filters and authorization policiies on=20 > xpath style addressing (though a subset for performance reasons).=20 Here is a list of xpath style element/attribute addressing that I = propose to be supported, along with some negotiable ones that need = discussion. I also include a list of addressing styles that I think are = not needed. If all agreed (after some discussion, of course) I can = create and I-D summarising those and providing examples. Supported --------- Note: any combination of these is possible - selecting root element: / - selecting all elements: // - selecting all enclosed elements: * - selecting attributes: @ - selecting elements using attributes as keys: [@x] - selecting element using attribute and its value as key: [@x=3D'y'] - selecting descendents: descendent:: , descendent-or-self:: - selecting ancestors: ancestor:: , ancestor or self:: - selecting siblings: following-sibling:: , preceding-sibling:: - selecting following and preceding elements: following:: , preceding:: Probable support ---------------- - using the 'and' operator ('|' in xpath) to combine rules - selecting first element: [1] - selecting last element: [last()] - selecting elements that don't have attributes [not(@*)] Not needed ------------ - selecting elements with x number of children elements: count() - selecting element using an attribute value and ignoring leading spaces = in the value: normalise-space() - selecting elements according to length of element name - selecting elements in a certain position in a document (using = mathematical expressions). Regards, Hisham _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Sep 17 06:19:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04157 for ; Wed, 17 Sep 2003 06:19:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zZOu-0005jC-Ce for simple-archive@odin.ietf.org; Wed, 17 Sep 2003 06:19:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8HAJ8oC022015 for simple-archive@odin.ietf.org; Wed, 17 Sep 2003 06:19:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zZOu-0005j0-4u for simple-web-archive@optimus.ietf.org; Wed, 17 Sep 2003 06:19: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 GAA04081; Wed, 17 Sep 2003 06:18:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zZOp-0003hK-00; Wed, 17 Sep 2003 06:19:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19zZOp-0003hH-00; Wed, 17 Sep 2003 06:19:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zZOo-0005iM-Ko; Wed, 17 Sep 2003 06:19:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zZOb-0005hk-Mz for simple@optimus.ietf.org; Wed, 17 Sep 2003 06:18: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 GAA04059 for ; Wed, 17 Sep 2003 06:18:39 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zZOX-0003go-00 for simple@ietf.org; Wed, 17 Sep 2003 06:18:45 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19zZOW-0003gk-00 for simple@ietf.org; Wed, 17 Sep 2003 06:18:45 -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 h8HAIh404407 for ; Wed, 17 Sep 2003 13:18:44 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 17 Sep 2003 13:18:42 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 17 Sep 2003 13:18: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] [Fwd: Re: NETCONF WG meeting minutes for IETF #57] Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017970FD@esebe019.ntc.nokia.com> Thread-Topic: [Simple] [Fwd: Re: NETCONF WG meeting minutes for IETF #57] Thread-Index: AcN880oie6UDDhLmTV6bNtmR0VU2GAADSadw To: Cc: , , X-OriginalArrivalTime: 17 Sep 2003 10:18:42.0571 (UTC) FILETIME=[11EF4DB0:01C37D05] 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, 17 Sep 2003 13:13:48 +0300 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Wednesday, September 17, 2003 11:10 AM > To: Khartabil Hisham (NMP-MSW/Helsinki) > Cc: hgs@cs.columbia.edu; simple@ietf.org; gk@ninebynine.org > Subject: Re: [Simple] [Fwd: Re: NETCONF WG meeting minutes=20 > for IETF #57] >=20 > > This might be true to authorisation where the presentity wants to > > block certain information from being unwillingly delivered to > > watchers (keeping requirements issues aside for now). But with > > filtering, the watcher selects information it wants to see, not > > block. In this case, the implementation at the watcher side better > > know how to render this presence information, delivered by the PA, > > to the watcher (end user). Therefore it can only ask for presence > > info in an xml document it understands. >=20 > I dont agree that filters are only about watchers asking for things=20 > they want. It seems perfectly reasonable to me for a watcher to say=20 > "give me everything but geolocation information", because it does in=20 > fact understand geoloc (and other things too), but just doesnt want=20 > that information. Ok, I was thinking that this could be done by listing all the wanted = elements, which it turn eliminates the unwanted ones. But we can add = explicit support for excluding elements. >=20 > That said, I'm now convinced (and already indicated in other emails)=20 > that it is appropriate to base filters and authorization policiies on=20 > xpath style addressing (though a subset for performance reasons).=20 Here is a list of xpath style element/attribute addressing that I = propose to be supported, along with some negotiable ones that need = discussion. I also include a list of addressing styles that I think are = not needed. If all agreed (after some discussion, of course) I can = create and I-D summarising those and providing examples. Supported --------- Note: any combination of these is possible - selecting root element: / - selecting all elements: // - selecting all enclosed elements: * - selecting attributes: @ - selecting elements using attributes as keys: [@x] - selecting element using attribute and its value as key: [@x=3D'y'] - selecting descendents: descendent:: , descendent-or-self:: - selecting ancestors: ancestor:: , ancestor or self:: - selecting siblings: following-sibling:: , preceding-sibling:: - selecting following and preceding elements: following:: , preceding:: Probable support ---------------- - using the 'and' operator ('|' in xpath) to combine rules - selecting first element: [1] - selecting last element: [last()] - selecting elements that don't have attributes [not(@*)] Not needed ------------ - selecting elements with x number of children elements: count() - selecting element using an attribute value and ignoring leading spaces = in the value: normalise-space() - selecting elements according to length of element name - selecting elements in a certain position in a document (using = mathematical expressions). Regards, Hisham _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Sep 17 10:07: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 KAA12184; Wed, 17 Sep 2003 10:07:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zcxc-0006Jl-00; Wed, 17 Sep 2003 10:07:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19zcxb-0006Ji-00; Wed, 17 Sep 2003 10:07:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zcxS-0007pT-Bo; Wed, 17 Sep 2003 10:07:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zcxA-0007oe-05 for simple@optimus.ietf.org; Wed, 17 Sep 2003 10:06: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 KAA12123; Wed, 17 Sep 2003 10:06:34 -0400 (EDT) From: Dirk.Trossen@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zcx7-0006JK-00; Wed, 17 Sep 2003 10:06:41 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19zcx6-0006JH-00; Wed, 17 Sep 2003 10:06: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 h8HE6dk28858; Wed, 17 Sep 2003 17:06:39 +0300 (EET DST) Received: from daebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 17 Sep 2003 17:06:39 +0300 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 17 Sep 2003 09:06:36 -0500 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 Message-ID: Thread-Topic: [Geopriv] A description of the relationship of permissions and rules. Thread-Index: AcN87o25vIQiNx3AQZy20Z/YTkYvRAANJRGw To: , Cc: , X-OriginalArrivalTime: 17 Sep 2003 14:06:36.0802 (UTC) FILETIME=[E8695E20:01C37D24] Content-Transfer-Encoding: quoted-printable Subject: [Simple] RE: [Geopriv] A description of the relationship of permissions and rules. Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.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, 17 Sep 2003 10:06:32 -0400 Content-Transfer-Encoding: quoted-printable Hi Jonathan, >>=20 >> The good news is that if we believe in the soundness of the=20 >fundamental=20 >> model, >> we can publish documents describing the statements for retention,=20 >> distribution, >> granularity, and naming of URIs without having completed the=20 >work on the=20 >> rules, >> as we will be sure that the presence of the un-dereferenced=20 >URI will not=20 >> constitute >> a privacy violation. > >I encountered one big snag in this model which I havent quite worked=20 >out. THe snag is what we are calling "transformational permissions".=20 >These are cases where I want to say "if my activity is 'busy', change=20 >it to 'idle'". Simply put - lying. I believe that lying will play a=20 >far more important role than omission of information, both in presence=20 >and geolocation. I don't know if this was discussed at the=20 >interim or not. > >Lying doesnt really fit into the model. Its not a permission in that=20 >it doesnt grant access to a piece of information fundamentally in the=20 >data. Rather, it asks for a change in that data. I could think of no=20 >other solution than to include explicitly defined ordering values that=20 >tell the server how to compose the information. Wouldn't "transformational permissions" be also useful for cases in = which I want to=20 grant permission to, let's say, geoloc location but with less = granularity for the particular watcher,=20 i.e., even though the location information exists with 95% confidence, I = would like to "blur" it before providing to the particular watcher, e.g., provide it with 70% = confidence only? This is probably the=20 case of "lying" for non-discrete presence items!?=20 But this would make the authorization description quite complex since = explicit ordering wouldn't do, right?=20 Hence, it might be useful to describe the scope of such = "transformational permissions" with respect to=20 supported transformations. Dirk _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Sep 17 10:07:37 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 KAA12268 for ; Wed, 17 Sep 2003 10:07:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zcxf-0007ux-G7 for simple-archive@odin.ietf.org; Wed, 17 Sep 2003 10:07:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8HE7FPw030421 for simple-archive@odin.ietf.org; Wed, 17 Sep 2003 10:07:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zcxe-0007uS-Vc for simple-web-archive@optimus.ietf.org; Wed, 17 Sep 2003 10:07: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 KAA12184; Wed, 17 Sep 2003 10:07:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zcxc-0006Jl-00; Wed, 17 Sep 2003 10:07:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19zcxb-0006Ji-00; Wed, 17 Sep 2003 10:07:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zcxS-0007pT-Bo; Wed, 17 Sep 2003 10:07:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zcxA-0007oe-05 for simple@optimus.ietf.org; Wed, 17 Sep 2003 10:06: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 KAA12123; Wed, 17 Sep 2003 10:06:34 -0400 (EDT) From: Dirk.Trossen@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zcx7-0006JK-00; Wed, 17 Sep 2003 10:06:41 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19zcx6-0006JH-00; Wed, 17 Sep 2003 10:06: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 h8HE6dk28858; Wed, 17 Sep 2003 17:06:39 +0300 (EET DST) Received: from daebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 17 Sep 2003 17:06:39 +0300 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 17 Sep 2003 09:06:36 -0500 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 Message-ID: Thread-Topic: [Geopriv] A description of the relationship of permissions and rules. Thread-Index: AcN87o25vIQiNx3AQZy20Z/YTkYvRAANJRGw To: , Cc: , X-OriginalArrivalTime: 17 Sep 2003 14:06:36.0802 (UTC) FILETIME=[E8695E20:01C37D24] Content-Transfer-Encoding: quoted-printable Subject: [Simple] RE: [Geopriv] A description of the relationship of permissions and rules. Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.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, 17 Sep 2003 10:06:32 -0400 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Jonathan, >>=20 >> The good news is that if we believe in the soundness of the=20 >fundamental=20 >> model, >> we can publish documents describing the statements for retention,=20 >> distribution, >> granularity, and naming of URIs without having completed the=20 >work on the=20 >> rules, >> as we will be sure that the presence of the un-dereferenced=20 >URI will not=20 >> constitute >> a privacy violation. > >I encountered one big snag in this model which I havent quite worked=20 >out. THe snag is what we are calling "transformational permissions".=20 >These are cases where I want to say "if my activity is 'busy', change=20 >it to 'idle'". Simply put - lying. I believe that lying will play a=20 >far more important role than omission of information, both in presence=20 >and geolocation. I don't know if this was discussed at the=20 >interim or not. > >Lying doesnt really fit into the model. Its not a permission in that=20 >it doesnt grant access to a piece of information fundamentally in the=20 >data. Rather, it asks for a change in that data. I could think of no=20 >other solution than to include explicitly defined ordering values that=20 >tell the server how to compose the information. Wouldn't "transformational permissions" be also useful for cases in = which I want to=20 grant permission to, let's say, geoloc location but with less = granularity for the particular watcher,=20 i.e., even though the location information exists with 95% confidence, I = would like to "blur" it before providing to the particular watcher, e.g., provide it with 70% = confidence only? This is probably the=20 case of "lying" for non-discrete presence items!?=20 But this would make the authorization description quite complex since = explicit ordering wouldn't do, right?=20 Hence, it might be useful to describe the scope of such = "transformational permissions" with respect to=20 supported transformations. Dirk _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Sep 17 13:28:56 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 NAA20922; Wed, 17 Sep 2003 13:28:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zg6z-0001IV-00; Wed, 17 Sep 2003 13:29:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19zg6y-0001IQ-00; Wed, 17 Sep 2003 13:29:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zg6v-0007Qe-7O; Wed, 17 Sep 2003 13:29:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zg6i-0007QO-Lg for simple@optimus.ietf.org; Wed, 17 Sep 2003 13:28:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20903 for ; Wed, 17 Sep 2003 13:28:38 -0400 (EDT) From: mikko.lonnfors@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zg6g-0001I8-00 for simple@ietf.org; Wed, 17 Sep 2003 13:28:46 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19zg6f-0001I4-00 for simple@ietf.org; Wed, 17 Sep 2003 13:28:45 -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 h8HHSg424154 for ; Wed, 17 Sep 2003 20:28:44 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 17 Sep 2003 20:28:41 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 17 Sep 2003 20:28: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="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] general questions on presence information format Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF01C1DB25@esebe004.ntc.nokia.com> Thread-Topic: [Simple] general questions on presence information format Thread-Index: AcN83+wqnIEafBT4TY2opVui+/qZJQAK2Cfw To: , Cc: X-OriginalArrivalTime: 17 Sep 2003 17:28:41.0041 (UTC) FILETIME=[23056C10:01C37D41] 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, 17 Sep 2003 20:28:40 +0300 Content-Transfer-Encoding: quoted-printable Hi, > youngsun song wrote: >=20 > > Hi, > > I just started looking at documents related to presence information > > and > > have a few questions. > > =20 > > The draft-ietf-impp-cpim-pidf document seems to define a baseline=20 > > presence format that is to be extended for use by various presence=20 > > applications. The documents that extend the pidf seem to be:=20 > > draft-ietf-simple-rpids-01.txt,=20 > > draft-rosenberg-peterson-simple-pidf-phone-00.txt, > > draft-lonnfors-simple-prescaps-ext-01.txt, etc. > > Are these extensions considered fairly stable? >=20 > rpids is somewhat stable; I expect some more changes but its been > through the ringer quite a bit already. >=20 > pidf-phone is very unstable - that was just the first proposal, and > the scope will be substantially reduced in the next rev. >=20 > I think prescaps-ext also has some work to do, hasn't gotten a lot of > air time yet really. Yes, draft is currently being rewritten and there will be some changes. At least XML schema will look very different compared to what is currently in the draft. Hopefully -02 draft will be more stable. - Mikko >=20 > > If not, are there any > > timeframes by when these are expected to become stable? >=20 > I'll let the chairs comment on that... >=20 > > Also, for the SIP-based presence applications currently > implemented, > > are > > they then using private extensions of the pidf (or private presence > > formats)? >=20 > I think there are some private extensions. I know of deployments that > use the baseline pidf though. >=20 > -Jonathan R. >=20 >=20 > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com >=20 >=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 Sep 17 13:29:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20944 for ; Wed, 17 Sep 2003 13:29:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zg71-0007SN-Uy for simple-archive@odin.ietf.org; Wed, 17 Sep 2003 13:29:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8HHT7QH028664 for simple-archive@odin.ietf.org; Wed, 17 Sep 2003 13:29:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zg71-0007SF-QU for simple-web-archive@optimus.ietf.org; Wed, 17 Sep 2003 13: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 NAA20922; Wed, 17 Sep 2003 13:28:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zg6z-0001IV-00; Wed, 17 Sep 2003 13:29:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19zg6y-0001IQ-00; Wed, 17 Sep 2003 13:29:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zg6v-0007Qe-7O; Wed, 17 Sep 2003 13:29:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zg6i-0007QO-Lg for simple@optimus.ietf.org; Wed, 17 Sep 2003 13:28:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20903 for ; Wed, 17 Sep 2003 13:28:38 -0400 (EDT) From: mikko.lonnfors@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zg6g-0001I8-00 for simple@ietf.org; Wed, 17 Sep 2003 13:28:46 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19zg6f-0001I4-00 for simple@ietf.org; Wed, 17 Sep 2003 13:28:45 -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 h8HHSg424154 for ; Wed, 17 Sep 2003 20:28:44 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 17 Sep 2003 20:28:41 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 17 Sep 2003 20:28: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="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] general questions on presence information format Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF01C1DB25@esebe004.ntc.nokia.com> Thread-Topic: [Simple] general questions on presence information format Thread-Index: AcN83+wqnIEafBT4TY2opVui+/qZJQAK2Cfw To: , Cc: X-OriginalArrivalTime: 17 Sep 2003 17:28:41.0041 (UTC) FILETIME=[23056C10:01C37D41] 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, 17 Sep 2003 20:28:40 +0300 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi, > youngsun song wrote: >=20 > > Hi, > > I just started looking at documents related to presence information > > and > > have a few questions. > > =20 > > The draft-ietf-impp-cpim-pidf document seems to define a baseline=20 > > presence format that is to be extended for use by various presence=20 > > applications. The documents that extend the pidf seem to be:=20 > > draft-ietf-simple-rpids-01.txt,=20 > > draft-rosenberg-peterson-simple-pidf-phone-00.txt, > > draft-lonnfors-simple-prescaps-ext-01.txt, etc. > > Are these extensions considered fairly stable? >=20 > rpids is somewhat stable; I expect some more changes but its been > through the ringer quite a bit already. >=20 > pidf-phone is very unstable - that was just the first proposal, and > the scope will be substantially reduced in the next rev. >=20 > I think prescaps-ext also has some work to do, hasn't gotten a lot of > air time yet really. Yes, draft is currently being rewritten and there will be some changes. At least XML schema will look very different compared to what is currently in the draft. Hopefully -02 draft will be more stable. - Mikko >=20 > > If not, are there any > > timeframes by when these are expected to become stable? >=20 > I'll let the chairs comment on that... >=20 > > Also, for the SIP-based presence applications currently > implemented, > > are > > they then using private extensions of the pidf (or private presence > > formats)? >=20 > I think there are some private extensions. I know of deployments that > use the baseline pidf though. >=20 > -Jonathan R. >=20 >=20 > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com >=20 >=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 Sep 17 16:06: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 QAA27121; Wed, 17 Sep 2003 16:06:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ziZC-0002p4-00; Wed, 17 Sep 2003 16:06:23 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ziZC-0002ox-00; Wed, 17 Sep 2003 16:06:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ziYt-00045H-7T; Wed, 17 Sep 2003 16:06:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ziXt-00042U-MJ for simple@optimus.ietf.org; Wed, 17 Sep 2003 16:05: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 QAA26980 for ; Wed, 17 Sep 2003 16:04:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ziXq-0002mG-00 for simple@ietf.org; Wed, 17 Sep 2003 16:04:58 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 19ziXp-0002mB-00 for simple@ietf.org; Wed, 17 Sep 2003 16:04:58 -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 h8HK4orl003588; Wed, 17 Sep 2003 16:04:51 -0400 (EDT) Received: from cs.columbia.edu (path.cs.columbia.edu [128.59.19.143]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h8HK4nG05031; Wed, 17 Sep 2003 16:04:49 -0400 Message-ID: <3F68BE61.5050000@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030827 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: jdrosen@dynamicsoft.com, simple@ietf.org, gk@ninebynine.org Subject: Re: [Simple] [Fwd: Re: NETCONF WG meeting minutes for IETF #57] References: <2038BCC78B1AD641891A0D1AE133DBB7017970FD@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB7017970FD@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: Wed, 17 Sep 2003 16:04:49 -0400 Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: >>I dont agree that filters are only about watchers asking for things >>they want. It seems perfectly reasonable to me for a watcher to say >>"give me everything but geolocation information", because it does in >>fact understand geoloc (and other things too), but just doesnt want >>that information. > > hisham.khartabil@nokia.com wrote: >> I dont agree that filters are only about watchers asking for things >> they want. It seems perfectly reasonable to me for a watcher to >> say "give me everything but geolocation information", because it >> does in fact understand geoloc (and other things too), but just >> doesnt want that information. > > > Ok, I was thinking that this could be done by listing all the wanted > elements, which it turn eliminates the unwanted ones. But we can add > explicit support for excluding elements. This seems only an optimization to reduce the size of filters. It does not seem to add any significant value, except possibly in cases where the recipient of the filtered material is 'passing through' things to somebody else without having to understand them. > Supported > --------- > Note: any combination of these is possible > - selecting root element: / > - selecting all elements: // Does this include things like 'element named '? > - selecting all enclosed elements: * > - selecting attributes: @ > - selecting elements using attributes as keys: [@x] > - selecting element using attribute and its value as key: [@x='y'] Can you give a use case for the ones below? > - selecting descendents: descendent:: , descendent-or-self:: > - selecting ancestors: ancestor:: , ancestor or self:: > - selecting siblings: following-sibling:: , preceding-sibling:: > - selecting following and preceding elements: following:: , preceding:: _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Sep 17 16:06:47 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 QAA27162 for ; Wed, 17 Sep 2003 16:06:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ziZF-00049I-5i for simple-archive@odin.ietf.org; Wed, 17 Sep 2003 16:06:25 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8HK6PmN015948 for simple-archive@odin.ietf.org; Wed, 17 Sep 2003 16:06:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ziZF-000499-2v for simple-web-archive@optimus.ietf.org; Wed, 17 Sep 2003 16:06: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 QAA27121; Wed, 17 Sep 2003 16:06:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ziZC-0002p4-00; Wed, 17 Sep 2003 16:06:23 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ziZC-0002ox-00; Wed, 17 Sep 2003 16:06:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ziYt-00045H-7T; Wed, 17 Sep 2003 16:06:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ziXt-00042U-MJ for simple@optimus.ietf.org; Wed, 17 Sep 2003 16:05: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 QAA26980 for ; Wed, 17 Sep 2003 16:04:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ziXq-0002mG-00 for simple@ietf.org; Wed, 17 Sep 2003 16:04:58 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 19ziXp-0002mB-00 for simple@ietf.org; Wed, 17 Sep 2003 16:04:58 -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 h8HK4orl003588; Wed, 17 Sep 2003 16:04:51 -0400 (EDT) Received: from cs.columbia.edu (path.cs.columbia.edu [128.59.19.143]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h8HK4nG05031; Wed, 17 Sep 2003 16:04:49 -0400 Message-ID: <3F68BE61.5050000@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030827 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: jdrosen@dynamicsoft.com, simple@ietf.org, gk@ninebynine.org Subject: Re: [Simple] [Fwd: Re: NETCONF WG meeting minutes for IETF #57] References: <2038BCC78B1AD641891A0D1AE133DBB7017970FD@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB7017970FD@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: Wed, 17 Sep 2003 16:04:49 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: >>I dont agree that filters are only about watchers asking for things >>they want. It seems perfectly reasonable to me for a watcher to say >>"give me everything but geolocation information", because it does in >>fact understand geoloc (and other things too), but just doesnt want >>that information. > > hisham.khartabil@nokia.com wrote: >> I dont agree that filters are only about watchers asking for things >> they want. It seems perfectly reasonable to me for a watcher to >> say "give me everything but geolocation information", because it >> does in fact understand geoloc (and other things too), but just >> doesnt want that information. > > > Ok, I was thinking that this could be done by listing all the wanted > elements, which it turn eliminates the unwanted ones. But we can add > explicit support for excluding elements. This seems only an optimization to reduce the size of filters. It does not seem to add any significant value, except possibly in cases where the recipient of the filtered material is 'passing through' things to somebody else without having to understand them. > Supported > --------- > Note: any combination of these is possible > - selecting root element: / > - selecting all elements: // Does this include things like 'element named '? > - selecting all enclosed elements: * > - selecting attributes: @ > - selecting elements using attributes as keys: [@x] > - selecting element using attribute and its value as key: [@x='y'] Can you give a use case for the ones below? > - selecting descendents: descendent:: , descendent-or-self:: > - selecting ancestors: ancestor:: , ancestor or self:: > - selecting siblings: following-sibling:: , preceding-sibling:: > - selecting following and preceding elements: following:: , preceding:: _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Sep 17 18:09: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 SAA02576; Wed, 17 Sep 2003 18:09:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zkUK-0004R7-00; Wed, 17 Sep 2003 18:09:28 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19zkUK-0004R4-00; Wed, 17 Sep 2003 18:09:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zkTu-000103-6d; Wed, 17 Sep 2003 18:09:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zkTN-0000zN-Rn for simple@optimus.ietf.org; Wed, 17 Sep 2003 18:08:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02494 for ; Wed, 17 Sep 2003 18:08:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zkTL-0004Qy-00 for simple@ietf.org; Wed, 17 Sep 2003 18:08:27 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19zkTK-0004Qu-00 for simple@ietf.org; Wed, 17 Sep 2003 18:08:26 -0400 Received: from dynamicsoft.com ([63.113.46.140]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h8HM7tUg016259; Wed, 17 Sep 2003 18:07:55 -0400 (EDT) Message-ID: <3F68DB34.6080008@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne CC: hisham.khartabil@nokia.com, simple@ietf.org, gk@ninebynine.org Subject: Re: [Simple] [Fwd: Re: NETCONF WG meeting minutes for IETF #57] References: <2038BCC78B1AD641891A0D1AE133DBB7017970FD@esebe019.ntc.nokia.com> <3F68BE61.5050000@cs.columbia.edu> In-Reply-To: <3F68BE61.5050000@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 17 Sep 2003 18:07:48 -0400 Content-Transfer-Encoding: 7bit inline. Henning Schulzrinne wrote: > hisham.khartabil@nokia.com wrote: > >>> I dont agree that filters are only about watchers asking for things >>> they want. It seems perfectly reasonable to me for a watcher to say >>> "give me everything but geolocation information", because it does in >>> fact understand geoloc (and other things too), but just doesnt want >>> that information. >> >> >> > hisham.khartabil@nokia.com wrote: > >>> I dont agree that filters are only about watchers asking for things >>> they want. It seems perfectly reasonable to me for a watcher to >>> say "give me everything but geolocation information", because it >>> does in fact understand geoloc (and other things too), but just >>> doesnt want that information. >> >> >> >> Ok, I was thinking that this could be done by listing all the wanted >> elements, which it turn eliminates the unwanted ones. But we can add >> explicit support for excluding elements. > > > This seems only an optimization to reduce the size of filters. It does > not seem to add any significant value, except possibly in cases where > the recipient of the filtered material is 'passing through' things to > somebody else without having to understand them. Right. That would include cases where status information can be rendered without understanding. An example would be placetype, where a client can render "placetype:" and the value, and it would still make sense. Perhaps this is pushing it and not a real need. Overall I think we need some good uses cases for the various filter applications to understand the scope. In particular, I don't understand the application for a lot of the xpath rules you have asked for below. I still believe we can unify this between authorization and filtering, and you have listed, below, far more than we seem to think is needed for authorization. I would think that any filter use case that would motivate the need could be turned into an authorization use case too... > >> Supported >> --------- >> Note: any combination of these is possible >> - selecting root element: / >> - selecting all elements: // > > > Does this include things like 'element named '? > >> - selecting all enclosed elements: * >> - selecting attributes: @ >> - selecting elements using attributes as keys: [@x] >> - selecting element using attribute and its value as key: [@x='y'] > > > Can you give a use case for the ones below? > >> - selecting descendents: descendent:: , descendent-or-self:: >> - selecting ancestors: ancestor:: , ancestor or self:: >> - selecting siblings: following-sibling:: , preceding-sibling:: >> - selecting following and preceding elements: following:: , preceding:: > > > > > -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Sep 17 18:09:53 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 SAA02616 for ; Wed, 17 Sep 2003 18:09:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zkUO-00011x-Gb for simple-archive@odin.ietf.org; Wed, 17 Sep 2003 18:09:32 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8HM9Wlf003962 for simple-archive@odin.ietf.org; Wed, 17 Sep 2003 18:09:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zkUO-00011p-8M for simple-web-archive@optimus.ietf.org; Wed, 17 Sep 2003 18:09: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 SAA02576; Wed, 17 Sep 2003 18:09:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zkUK-0004R7-00; Wed, 17 Sep 2003 18:09:28 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19zkUK-0004R4-00; Wed, 17 Sep 2003 18:09:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zkTu-000103-6d; Wed, 17 Sep 2003 18:09:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zkTN-0000zN-Rn for simple@optimus.ietf.org; Wed, 17 Sep 2003 18:08:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02494 for ; Wed, 17 Sep 2003 18:08:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zkTL-0004Qy-00 for simple@ietf.org; Wed, 17 Sep 2003 18:08:27 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19zkTK-0004Qu-00 for simple@ietf.org; Wed, 17 Sep 2003 18:08:26 -0400 Received: from dynamicsoft.com ([63.113.46.140]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h8HM7tUg016259; Wed, 17 Sep 2003 18:07:55 -0400 (EDT) Message-ID: <3F68DB34.6080008@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne CC: hisham.khartabil@nokia.com, simple@ietf.org, gk@ninebynine.org Subject: Re: [Simple] [Fwd: Re: NETCONF WG meeting minutes for IETF #57] References: <2038BCC78B1AD641891A0D1AE133DBB7017970FD@esebe019.ntc.nokia.com> <3F68BE61.5050000@cs.columbia.edu> In-Reply-To: <3F68BE61.5050000@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 17 Sep 2003 18:07:48 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit inline. Henning Schulzrinne wrote: > hisham.khartabil@nokia.com wrote: > >>> I dont agree that filters are only about watchers asking for things >>> they want. It seems perfectly reasonable to me for a watcher to say >>> "give me everything but geolocation information", because it does in >>> fact understand geoloc (and other things too), but just doesnt want >>> that information. >> >> >> > hisham.khartabil@nokia.com wrote: > >>> I dont agree that filters are only about watchers asking for things >>> they want. It seems perfectly reasonable to me for a watcher to >>> say "give me everything but geolocation information", because it >>> does in fact understand geoloc (and other things too), but just >>> doesnt want that information. >> >> >> >> Ok, I was thinking that this could be done by listing all the wanted >> elements, which it turn eliminates the unwanted ones. But we can add >> explicit support for excluding elements. > > > This seems only an optimization to reduce the size of filters. It does > not seem to add any significant value, except possibly in cases where > the recipient of the filtered material is 'passing through' things to > somebody else without having to understand them. Right. That would include cases where status information can be rendered without understanding. An example would be placetype, where a client can render "placetype:" and the value, and it would still make sense. Perhaps this is pushing it and not a real need. Overall I think we need some good uses cases for the various filter applications to understand the scope. In particular, I don't understand the application for a lot of the xpath rules you have asked for below. I still believe we can unify this between authorization and filtering, and you have listed, below, far more than we seem to think is needed for authorization. I would think that any filter use case that would motivate the need could be turned into an authorization use case too... > >> Supported >> --------- >> Note: any combination of these is possible >> - selecting root element: / >> - selecting all elements: // > > > Does this include things like 'element named '? > >> - selecting all enclosed elements: * >> - selecting attributes: @ >> - selecting elements using attributes as keys: [@x] >> - selecting element using attribute and its value as key: [@x='y'] > > > Can you give a use case for the ones below? > >> - selecting descendents: descendent:: , descendent-or-self:: >> - selecting ancestors: ancestor:: , ancestor or self:: >> - selecting siblings: following-sibling:: , preceding-sibling:: >> - selecting following and preceding elements: following:: , preceding:: > > > > > -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Sep 18 03:16: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 DAA00305; Thu, 18 Sep 2003 03:16:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zt1M-0001xK-00; Thu, 18 Sep 2003 03:16:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19zt1M-0001xH-00; Thu, 18 Sep 2003 03:16:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zt1H-0000cs-OL; Thu, 18 Sep 2003 03:16:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zt19-0000c5-6N for simple@optimus.ietf.org; Thu, 18 Sep 2003 03: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 DAA00285; Thu, 18 Sep 2003 03:15:48 -0400 (EDT) From: aki.niemi@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zt16-0001wi-00; Thu, 18 Sep 2003 03:15:52 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19zt16-0001we-00; Thu, 18 Sep 2003 03:15:52 -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 h8I7Fqk27119; Thu, 18 Sep 2003 10:15:52 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 18 Sep 2003 10:15:51 +0300 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 18 Sep 2003 10:15:51 +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] Re: [Geopriv] A description of the relationship of permissions and rules. Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9027D8FB7@esebe013.ntc.nokia.com> Thread-Topic: [Simple] Re: [Geopriv] A description of the relationship of permissions and rules. Thread-Index: AcN87o6AicVyL8MZTTuiVx5FEtf7YQAEAybQ To: , Cc: , X-OriginalArrivalTime: 18 Sep 2003 07:15:51.0241 (UTC) FILETIME=[B0ECF390:01C37DB4] 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, 18 Sep 2003 10:15:50 +0300 Content-Transfer-Encoding: quoted-printable Hi All, One comment inline. > -----Original Message----- > From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: 17 September, 2003 10:36 > To: hardie@qualcomm.com > Cc: geopriv@ietf.org; Simple WG > Subject: [Simple] Re: [Geopriv] A description of the relationship of > permissions and rules. [snip] > > The good news is that if we believe in the soundness of=20 > the fundamental=20 > > model, > > we can publish documents describing the statements for retention,=20 > > distribution, > > granularity, and naming of URIs without having completed=20 > the work on the=20 > > rules, > > as we will be sure that the presence of the=20 > un-dereferenced URI will not=20 > > constitute > > a privacy violation. >=20 > I encountered one big snag in this model which I havent quite worked=20 > out. THe snag is what we are calling "transformational permissions".=20 > These are cases where I want to say "if my activity is=20 > 'busy', change=20 > it to 'idle'". Simply put - lying. I believe that lying will play a=20 > far more important role than omission of information, both=20 > in presence=20 > and geolocation. I don't know if this was discussed at the=20 > interim or not. >=20 > Lying doesnt really fit into the model. Its not a permission in that=20 > it doesnt grant access to a piece of information=20 > fundamentally in the=20 > data. Rather, it asks for a change in that data. I could think of no=20 > other solution than to include explicitly defined ordering=20 > values that=20 > tell the server how to compose the information. I think one way to make 'lying' part of the model is to explicitly = include this false information in the data.=20 For presence, this would mean publishing two pieces of information - the = true information as well as the false. Granted that this would not be = efficient in terms of the amount of publication traffic it would = generate, I think it would reduce the 'lying' into a set of ordinary = permissions instead of the transformational permissions. Cheers, Aki >=20 > -Jonathan R. >=20 >=20 > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com >=20 >=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 Thu Sep 18 03:16:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00340 for ; Thu, 18 Sep 2003 03:16:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zt1P-0000fh-Nq for simple-archive@odin.ietf.org; Thu, 18 Sep 2003 03:16:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8I7GBc0002579 for simple-archive@odin.ietf.org; Thu, 18 Sep 2003 03:16:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zt1P-0000fV-Cf for simple-web-archive@optimus.ietf.org; Thu, 18 Sep 2003 03:16: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 DAA00305; Thu, 18 Sep 2003 03:16:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zt1M-0001xK-00; Thu, 18 Sep 2003 03:16:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19zt1M-0001xH-00; Thu, 18 Sep 2003 03:16:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zt1H-0000cs-OL; Thu, 18 Sep 2003 03:16:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zt19-0000c5-6N for simple@optimus.ietf.org; Thu, 18 Sep 2003 03: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 DAA00285; Thu, 18 Sep 2003 03:15:48 -0400 (EDT) From: aki.niemi@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zt16-0001wi-00; Thu, 18 Sep 2003 03:15:52 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19zt16-0001we-00; Thu, 18 Sep 2003 03:15:52 -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 h8I7Fqk27119; Thu, 18 Sep 2003 10:15:52 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 18 Sep 2003 10:15:51 +0300 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 18 Sep 2003 10:15:51 +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] Re: [Geopriv] A description of the relationship of permissions and rules. Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9027D8FB7@esebe013.ntc.nokia.com> Thread-Topic: [Simple] Re: [Geopriv] A description of the relationship of permissions and rules. Thread-Index: AcN87o6AicVyL8MZTTuiVx5FEtf7YQAEAybQ To: , Cc: , X-OriginalArrivalTime: 18 Sep 2003 07:15:51.0241 (UTC) FILETIME=[B0ECF390:01C37DB4] 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, 18 Sep 2003 10:15:50 +0300 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi All, One comment inline. > -----Original Message----- > From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: 17 September, 2003 10:36 > To: hardie@qualcomm.com > Cc: geopriv@ietf.org; Simple WG > Subject: [Simple] Re: [Geopriv] A description of the relationship of > permissions and rules. [snip] > > The good news is that if we believe in the soundness of=20 > the fundamental=20 > > model, > > we can publish documents describing the statements for retention,=20 > > distribution, > > granularity, and naming of URIs without having completed=20 > the work on the=20 > > rules, > > as we will be sure that the presence of the=20 > un-dereferenced URI will not=20 > > constitute > > a privacy violation. >=20 > I encountered one big snag in this model which I havent quite worked=20 > out. THe snag is what we are calling "transformational permissions".=20 > These are cases where I want to say "if my activity is=20 > 'busy', change=20 > it to 'idle'". Simply put - lying. I believe that lying will play a=20 > far more important role than omission of information, both=20 > in presence=20 > and geolocation. I don't know if this was discussed at the=20 > interim or not. >=20 > Lying doesnt really fit into the model. Its not a permission in that=20 > it doesnt grant access to a piece of information=20 > fundamentally in the=20 > data. Rather, it asks for a change in that data. I could think of no=20 > other solution than to include explicitly defined ordering=20 > values that=20 > tell the server how to compose the information. I think one way to make 'lying' part of the model is to explicitly = include this false information in the data.=20 For presence, this would mean publishing two pieces of information - the = true information as well as the false. Granted that this would not be = efficient in terms of the amount of publication traffic it would = generate, I think it would reduce the 'lying' into a set of ordinary = permissions instead of the transformational permissions. Cheers, Aki >=20 > -Jonathan R. >=20 >=20 > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com >=20 >=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 Thu Sep 18 10:45:01 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15902; Thu, 18 Sep 2003 10:45:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A001s-0006yh-00; Thu, 18 Sep 2003 10:45:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A001r-0006ye-00; Thu, 18 Sep 2003 10:45:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A001n-0007Ud-AU; Thu, 18 Sep 2003 10:45:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0019-0007U0-LJ for simple@optimus.ietf.org; Thu, 18 Sep 2003 10:44: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 KAA15858 for ; Thu, 18 Sep 2003 10:44:14 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0017-0006xy-00 for simple@ietf.org; Thu, 18 Sep 2003 10:44:21 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1A0016-0006xv-00 for simple@ietf.org; Thu, 18 Sep 2003 10:44:20 -0400 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.6) with ESMTP id h8IEiJt15820 for ; Thu, 18 Sep 2003 17:44:19 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 18 Sep 2003 17:44:19 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 18 Sep 2003 17:44:18 +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] [Fwd: Re: NETCONF WG meeting minutes for IETF #57] Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70179710A@esebe019.ntc.nokia.com> Thread-Topic: [Simple] [Fwd: Re: NETCONF WG meeting minutes for IETF #57] Thread-Index: AcN9Vv4quRgrZJ45SW2AV6O7l7Q+zAAj75FQ To: Cc: , , X-OriginalArrivalTime: 18 Sep 2003 14:44:18.0232 (UTC) FILETIME=[56BDF380:01C37DF3] 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, 18 Sep 2003 17:44:17 +0300 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Wednesday, September 17, 2003 11:05 PM > To: Khartabil Hisham (NMP-MSW/Helsinki) > Cc: jdrosen@dynamicsoft.com; simple@ietf.org; gk@ninebynine.org > Subject: Re: [Simple] [Fwd: Re: NETCONF WG meeting minutes=20 > for IETF #57] >=20 >=20 >=20 > > Supported > > --------- > > Note: any combination of these is possible > > - selecting root element: / > > - selecting all elements: // >=20 > Does this include things like 'element named '? >=20 > > - selecting all enclosed elements: * > > - selecting attributes: @ > > - selecting elements using attributes as keys: [@x] > > - selecting element using attribute and its value as key: [@x=3D'y'] >=20 > Can you give a use case for the ones below? Let me give you some examples: - A watcher wishes to get the tuple that has a element with = value "IM". The watcher has to either explicitly list all the elements = that can appear in a tuple that it wants to receive, or alternatively, = it tells the PA to deliver the tuple that has element IM = with all the other elements that appear in that tuple. Its like using a = key for selecting a whole tuple. The latter can be achieved using the = following expression: //*[rpid:class=3D"IM"]/descendant-or-self::* This actually selects the whole tuple only. if the watcher wants to = select the tuple and the root element , you would do something = like: //*[rpid:class=3D"IM"]/descendant-or-self::* | = //*[rpids:label=3D"im"]/ancestor::* - The following is an example of how you can ask a PA to include all = tuples that are not of IM: //*[rpid:class=3D"IM"]/following::* | = //*[rpid:class=3D"IM"]/preceding::* - A watcher asks the PA to deliver a tuple that has a status of = "closed", but it only wants the elements that are not //*[basic=3D"closed"]/following-sibling::* | = //*[basic=3D"closed"]/preceding-sibling::* | = //*[basic=3D"closed"]/ancestor::tuple Again, this is if you don't want to indicate explicitly all the elements = that you want. /Hisham >=20 > > - selecting descendents: descendent:: , descendent-or-self:: > > - selecting ancestors: ancestor:: , ancestor or self:: > > - selecting siblings: following-sibling:: , preceding-sibling:: > > - selecting following and preceding elements: following:: ,=20 > preceding:: >=20 >=20 >=20 >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Sep 18 10:45: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 KAA15924 for ; Thu, 18 Sep 2003 10:45: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 1A001v-0007Vh-1N for simple-archive@odin.ietf.org; Thu, 18 Sep 2003 10:45:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8IEjBrT028865 for simple-archive@odin.ietf.org; Thu, 18 Sep 2003 10:45:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A001u-0007VU-St for simple-web-archive@optimus.ietf.org; Thu, 18 Sep 2003 10:45: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 KAA15902; Thu, 18 Sep 2003 10:45:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A001s-0006yh-00; Thu, 18 Sep 2003 10:45:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A001r-0006ye-00; Thu, 18 Sep 2003 10:45:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A001n-0007Ud-AU; Thu, 18 Sep 2003 10:45:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0019-0007U0-LJ for simple@optimus.ietf.org; Thu, 18 Sep 2003 10:44: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 KAA15858 for ; Thu, 18 Sep 2003 10:44:14 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0017-0006xy-00 for simple@ietf.org; Thu, 18 Sep 2003 10:44:21 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1A0016-0006xv-00 for simple@ietf.org; Thu, 18 Sep 2003 10:44:20 -0400 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.6) with ESMTP id h8IEiJt15820 for ; Thu, 18 Sep 2003 17:44:19 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 18 Sep 2003 17:44:19 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 18 Sep 2003 17:44:18 +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] [Fwd: Re: NETCONF WG meeting minutes for IETF #57] Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70179710A@esebe019.ntc.nokia.com> Thread-Topic: [Simple] [Fwd: Re: NETCONF WG meeting minutes for IETF #57] Thread-Index: AcN9Vv4quRgrZJ45SW2AV6O7l7Q+zAAj75FQ To: Cc: , , X-OriginalArrivalTime: 18 Sep 2003 14:44:18.0232 (UTC) FILETIME=[56BDF380:01C37DF3] 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, 18 Sep 2003 17:44:17 +0300 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Wednesday, September 17, 2003 11:05 PM > To: Khartabil Hisham (NMP-MSW/Helsinki) > Cc: jdrosen@dynamicsoft.com; simple@ietf.org; gk@ninebynine.org > Subject: Re: [Simple] [Fwd: Re: NETCONF WG meeting minutes=20 > for IETF #57] >=20 >=20 >=20 > > Supported > > --------- > > Note: any combination of these is possible > > - selecting root element: / > > - selecting all elements: // >=20 > Does this include things like 'element named '? >=20 > > - selecting all enclosed elements: * > > - selecting attributes: @ > > - selecting elements using attributes as keys: [@x] > > - selecting element using attribute and its value as key: [@x=3D'y'] >=20 > Can you give a use case for the ones below? Let me give you some examples: - A watcher wishes to get the tuple that has a element with = value "IM". The watcher has to either explicitly list all the elements = that can appear in a tuple that it wants to receive, or alternatively, = it tells the PA to deliver the tuple that has element IM = with all the other elements that appear in that tuple. Its like using a = key for selecting a whole tuple. The latter can be achieved using the = following expression: //*[rpid:class=3D"IM"]/descendant-or-self::* This actually selects the whole tuple only. if the watcher wants to = select the tuple and the root element , you would do something = like: //*[rpid:class=3D"IM"]/descendant-or-self::* | = //*[rpids:label=3D"im"]/ancestor::* - The following is an example of how you can ask a PA to include all = tuples that are not of IM: //*[rpid:class=3D"IM"]/following::* | = //*[rpid:class=3D"IM"]/preceding::* - A watcher asks the PA to deliver a tuple that has a status of = "closed", but it only wants the elements that are not //*[basic=3D"closed"]/following-sibling::* | = //*[basic=3D"closed"]/preceding-sibling::* | = //*[basic=3D"closed"]/ancestor::tuple Again, this is if you don't want to indicate explicitly all the elements = that you want. /Hisham >=20 > > - selecting descendents: descendent:: , descendent-or-self:: > > - selecting ancestors: ancestor:: , ancestor or self:: > > - selecting siblings: following-sibling:: , preceding-sibling:: > > - selecting following and preceding elements: following:: ,=20 > preceding:: >=20 >=20 >=20 >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Sep 19 12:29: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 MAA11227; Fri, 19 Sep 2003 12:29:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0O8N-0005cg-00; Fri, 19 Sep 2003 12:29:27 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A0O8H-0005bN-00; Fri, 19 Sep 2003 12:29:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0Nmx-0001dJ-1J; Fri, 19 Sep 2003 12:07:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0Nlu-0001OT-8V for simple@optimus.ietf.org; Fri, 19 Sep 2003 12:06: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 MAA06742 for ; Fri, 19 Sep 2003 12:05:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0C7y-0001U2-00 for simple@ietf.org; Thu, 18 Sep 2003 23:40:14 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1A0BtS-0007VT-00 for simple@ietf.org; Thu, 18 Sep 2003 23:25:14 -0400 Received: from bart.cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h8J3PErm021407 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Thu, 18 Sep 2003 23:25:14 -0400 (EDT) Received: from cs.columbia.edu (localhost [127.0.0.1]) by bart.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h8J3P29s007511; Thu, 18 Sep 2003 23:25:03 -0400 (EDT) Message-ID: <3F6A770E.6070905@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: simple@ietf.org, gk@ninebynine.org Subject: Re: [Simple] [Fwd: Re: NETCONF WG meeting minutes for IETF #57] References: <2038BCC78B1AD641891A0D1AE133DBB70179710A@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB70179710A@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 18 Sep 2003 23:25:02 -0400 Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: Thanks for the examples. The expressions are clearly far from obvious. I wonder if we can constrain the type of operations that we want to perform with presence tuples and express those operations more directly. The operations seem to be: - create a presence document that consists of tuples where attribute X has value Y - create a presence document that consists only of elements A, B, and C within (and combinations thereof) Are there others that make sense? I can see that for filtering random event documents, the Xpath model may be unavoidable in its proposed generality, but there seems to be a large danger of having filter specs create invalid presence documents by providing access to 'raw' Xpath. Thus, I wonder if a simpler description that is restricted to presence documents (and is guaranteed not to create invalid presence documents) wouldn't be helpful in practice. > Let me give you some examples: > > - A watcher wishes to get the tuple that has a element with value "IM". The watcher has to either explicitly list all the elements that can appear in a tuple that it wants to receive, or alternatively, it tells the PA to deliver the tuple that has element IM with all the other elements that appear in that tuple. Its like using a key for selecting a whole tuple. The latter can be achieved using the following expression: > > //*[rpid:class="IM"]/descendant-or-self::* > > > This actually selects the whole tuple only. if the watcher wants to select the tuple and the root element , you would do something like: > > //*[rpid:class="IM"]/descendant-or-self::* | //*[rpids:label="im"]/ancestor::* > > > - The following is an example of how you can ask a PA to include all tuples that are not of IM: > > //*[rpid:class="IM"]/following::* | //*[rpid:class="IM"]/preceding::* > > - A watcher asks the PA to deliver a tuple that has a status of "closed", but it only wants the elements that are not > > //*[basic="closed"]/following-sibling::* | //*[basic="closed"]/preceding-sibling::* | //*[basic="closed"]/ancestor::tuple > > > Again, this is if you don't want to indicate explicitly all the elements that you want. > > /Hisham > >>>- selecting descendents: descendent:: , descendent-or-self:: >>>- selecting ancestors: ancestor:: , ancestor or self:: >>>- selecting siblings: following-sibling:: , preceding-sibling:: >>>- selecting following and preceding elements: following:: , >> >>preceding:: >> >> >> >> >> _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Sep 19 22:37: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 WAA04766 for ; Fri, 19 Sep 2003 22:37:15 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.12.8/8.12.8) with ESMTP id h8K1VhGL020140 for ; Fri, 19 Sep 2003 21:37:55 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h82DgdZ7012901 for simple-archive@odin.ietf.org; Tue, 2 Sep 2003 09:42:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uBQd-0003M0-Jn for simple-web-archive@optimus.ietf.org; Tue, 02 Sep 2003 09:42: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 JAA25146; Tue, 2 Sep 2003 09:42: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 19uBQ6-0003Cq-7V; Tue, 02 Sep 2003 09:42:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19u8np-0003lm-Bh for simple@optimus.ietf.org; Tue, 02 Sep 2003 06:54: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 GAA09808 for ; Tue, 2 Sep 2003 06:54:17 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19u8nk-00016E-00 for simple@ietf.org; Tue, 02 Sep 2003 06:54:20 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19u8nj-000164-00 for simple@ietf.org; Tue, 02 Sep 2003 06:54:19 -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 h82As4B24139 for ; Tue, 2 Sep 2003 13:54:20 +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, 2 Sep 2003 13:54:04 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 2 Sep 2003 13:54:04 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 2 Sep 2003 13:54:03 +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] [Fwd: Re: NETCONF WG meeting minutes for IETF #57] Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797051@esebe019.ntc.nokia.com> Thread-Topic: [Simple] [Fwd: Re: NETCONF WG meeting minutes for IETF #57] Thread-Index: AcNxFH9T8L5f6yBRRp2LLAM5QHtxlQAKp4Ow To: Cc: , X-OriginalArrivalTime: 02 Sep 2003 10:54:03.0638 (UTC) FILETIME=[85FE3160:01C37140] 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, 2 Sep 2003 13:54:03 +0300 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable PIDF and tuple is just one example of where filtering would be used. The = filtering mechanism that we are building is generic for all event = notification packages. There is an open issue in the tuple design team, and that is how a = client can get information about the tuple construction at the server = side. Quoting Robert: "There are still questions around the use of tuples to be discussed. The one this design team was circling around whether a PA needs to expose the policy it used to create tuples to the watcher and whether a watcher needs to be able to request a certain policy. This discussion will move back to the SIMPLE list."=20 This is needed so that the watcher knows how to render the information = to the user using GUI to the like. Note, this is tuple specific issue. I don't think the filtering solution = should be complicated just to satisfy the tuple problem, the tuple = problem should be fixed instead. Regards, Hisham > -----Original Message----- > From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Tuesday, September 02, 2003 8:38 AM > To: Khartabil Hisham (NMP/Helsinki) > Cc: simple@ietf.org; gk@ninebynine.org > Subject: Re: [Simple] [Fwd: Re: NETCONF WG meeting minutes=20 > for IETF #57] >=20 >=20 > It ties back into our ongoing debate about "what is a tuple". Its not=20 > that the PIDF XML has no semantics, its that the underlying=20 > "presence"=20 > of a user can map into a variety of different XML documents,=20 > depending=20 > on the underlying policy of the PA and presentity. Thus, if=20 > the desire=20 > is to have a filter that restricts geolocation inforamtion, the=20 > appropriate XPath expressions depend a lot on how the PA chooses to=20 > place the presence information into the presence document. As an=20 > example, the PA may use it to compute the "placetype" RPID attribute.=20 > Or, it may appear in some tuples, but not others. It may appear as a=20 > textual piece of a note, i.e., "at work". Xpath cannot be=20 > used to tell=20 > a PA "don't put geoloc data anywhere in the document". >=20 > More abstractly, and in the context of Graham's note, I believe there=20 > is an underling data model which has "raw" presence data, and then=20 > this data gets encoded into presence documents using PIDF. I believe=20 > filters are ultimately useful only in their application to this raw=20 > data. Since there is a gap between the raw data and its encoding into=20 > a PIDF document, the usage of Xpath expressions on the PIDF document=20 > doesnt seem right to me. >=20 > Thanks, > Jonathan R. >=20 > hisham.khartabil@nokia.com wrote: >=20 > > I don't buy it. Why would you define an XML schema who's syntax > > does not match the semantics? > >=20 > > I earlier bought the argument that XPath is too complicated to > > implement for a simple use case of just wanting to identify an > > element in an XML document, and thereafter agreed to provide some > > text in the I-D pointing to this issue and explaining the limited > > use of XPath in filtering. > >=20 > > /Hisham > >=20 > >=20 > >> -----Original Message----- From: ext Jonathan Rosenberg > >> [mailto:jdrosen@dynamicsoft.com] Sent: Friday, August 29, 2003 > >> 5:36 PM To: Simple WG; gk@ninebynine.org Subject: [Simple] [Fwd: > >> Re: NETCONF WG meeting minutes for IETF #57] > >>=20 > >>=20 > >> Graham Klyne posted this note on netconf that has some insights > >> which I think can benefit us. Pay attention to this statement: > >>=20 > >> Graham writes: > >>=20 > >>> I would be very wary about using XPath as the basis for > >>> selective access to XMLConf data. XPath, by design, provides > >>> selection on the syntactic structure of XML: it has been > >>> suggested elsewhere (e.g. in the netconf protocol document, > >>> IIRC) that the data model is separate from the protocol > >>> framework (which I think is a good approach). But the > >>> query/selection syntax should be related to the data model, not > >>> to the carrier syntax. I have seen difficulties arise with > >>> different XML-based applications where people tried to use > >>> XPath selection for an XML format used to carry a data model=20 > >>> that was somewhat different from the XML carrier syntax. If > >>> the data model does not map directly onto the XML syntax, then > >>> XPath selection may well prove inadequate to make appropriate > >>> selection in the configuration data. > >>=20 > >> I think this summarizes nicely the concerns I have had about > >> using xpath for filtering. I am also going to be removing it from > >> element identification in the next xcap-auth rev. > >>=20 > >> -Jonathan R. > >>=20 > >> -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza=20 > >> Chief Technology Officer Parsippany, NJ > >> 07054-2711 dynamicsoft jdrosen@dynamicsoft.com > >> FAX: (973) 952-5050 http://www.jdrosen.net > >> PHONE: (973) 952-5000 http://www.dynamicsoft.com > >>=20 > >=20 > >=20 >=20 > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Sep 19 22:37: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 WAA04791 for ; Fri, 19 Sep 2003 22:37:16 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.12.8/8.12.8) with ESMTP id h8K1VhGP020140 for ; Fri, 19 Sep 2003 21:37:55 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h87HWAEr012977 for simple-archive@odin.ietf.org; Sun, 7 Sep 2003 13:32:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19w3OT-0003NE-UB for simple-web-archive@optimus.ietf.org; Sun, 07 Sep 2003 13:32:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20624; Sun, 7 Sep 2003 13:32:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19w3OR-0007MA-00; Sun, 07 Sep 2003 13:32:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19w3OQ-0007M1-00; Sun, 07 Sep 2003 13:32:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19w3OL-0003LQ-K4; Sun, 07 Sep 2003 13:32:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19w3NX-0003AO-9t for simple@optimus.ietf.org; Sun, 07 Sep 2003 13:31: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 NAA20341 for ; Sun, 7 Sep 2003 13:31:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19w08M-0003Lc-00 for simple@ietf.org; Sun, 07 Sep 2003 10:03:18 -0400 Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx with esmtp (Exim 4.12) id 19w08L-0003LU-00 for simple@ietf.org; Sun, 07 Sep 2003 10:03:17 -0400 Received: from bart.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 h87E35rq024345 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Sun, 7 Sep 2003 10:03:16 -0400 (EDT) Received: from cs.columbia.edu (localhost [127.0.0.1]) by bart.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h87E2w9s025127; Sun, 7 Sep 2003 10:02:59 -0400 (EDT) Message-ID: <3F5B3A92.2070908@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: simple@ietf.org, gk@ninebynine.org Subject: Re: [Simple] [Fwd: Re: NETCONF WG meeting minutes for IETF #57] References: <2038BCC78B1AD641891A0D1AE133DBB70179703A@esebe019.ntc.nokia.com> <3F542CB5.7040006@dynamicsoft.com> <3F54A341.2080004@cs.columbia.edu> <3F55F933.2080308@dynamicsoft.com> <3F5630CB.5060400@cs.columbia.edu> <3F5AB9B7.4050300@dynamicsoft.com> In-Reply-To: <3F5AB9B7.4050300@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: Sun, 07 Sep 2003 10:02:58 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > Fair enough, thought I don't think I would call this "syntactic". Document-oriented? Presumably it would use > My geolocation concerns were similar. I think what users may want is the > ability to say "I don't want people to know where I am". Many possible > presence elements can reveal this - including ones like activity and > privacy, which reveal indirect clues about location. I don't think this is necessarily binary. For example, I might be ok with letting others know what timezone I'm in, although this may hint that I'm traveling or on vacation. > > Unfortunately, I don't think its practical to have authorization > mechanisms which require the server to figure out what rpid elements are > needed to deduce a specific fact. Particularly if this is meant to be more than a binary yes/no decision. Different elements reveal different amounts of information depending on context, depending on what the watcher knows about me, etc. (For example, if the watcher knows that my employer has a branch office in Tokyo, even something as vague as timezone=Japan will provide a good hint as to what I'm doing right now.) > > As such, the best we can do is avoid dependencies on encoding details > (such as whether placetype is put in a status or future-status element). > I would suggest that the best way to do this is to allow filters and > authorization policies to point at rpids and pidf elements by element > name, no matter where that element appears in an XML document. So, if I > don't want people to know my geoloc, I would specify an auth policy that > blocks "placetype". Agreed. As a side-effect, this essentially makes the namespace flat, i.e., we can't have two PIDF-and-related namespaces use the same term for something different. I don't think this is a significant restriction in practice. One possibility to formalize this is to indeed have a single IANA registry for presence attributes. Each entry would point to one or more namespace/element-name combinations. > I agree this is a great idea. In fact, I had exactly this kind of thing > in mind for the compound permissions. The proof of feasibility will be whether we can arrive at such a list, across PIDF, RPID + related, and the emerging GEOPRIV items. I would suggest that these levels should be motivated by the likely use and audience. For example, for two mid-levels: (1) "Can I visit this person": this would be useful for intra-company coordination Would need information about my campus-level whereabouts. (2) "Is this person amenable to business (or private) communication?" This would include timezone, possibly country and open/closed. Possibly a 'private/business' coarse-grain activity (rather than a placetype). Are there others? > I agree that we don't want users to click on checkboxes for each rpid > type. I think you might have a checkbox for "don't reveal my location", > and when its selected, the client generates an xcap-auth document which > blocks a whole bunch of elements, each listed by name. This may require > us to produce a use case document that helps folks figure out what types > of facts users might want to control, and what elements are involved in > computing such facts. There was a long discussion on this topic at the GEOPRIV interim meeting that took place Friday and Saturday. Two approaches were identified: (1) a tool presents a high-level interface to the user, but the on-the-wire ruleset (XCAP-AUTH, etc.) identifies lower-level elements (either at the document-oriented level or, probably better, by content type). (2) the authorization policy itself contains a high-level description that then is translated by the policy enforcement entity into filtering actions. (2) has fewer things to test and thus may reach interoperability sooner, but requires that the policy enforcement point be upgraded each time a new element is added. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Sat Sep 20 09:54:37 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 JAA04893 for ; Sat, 20 Sep 2003 09:54:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0O8P-0007FX-5o for simple-archive@odin.ietf.org; Fri, 19 Sep 2003 12:29:29 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8JGTT4H027866 for simple-archive@odin.ietf.org; Fri, 19 Sep 2003 12:29:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0O8P-0007FN-2g for simple-web-archive@optimus.ietf.org; Fri, 19 Sep 2003 12:29: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 MAA11227; Fri, 19 Sep 2003 12:29:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0O8N-0005cg-00; Fri, 19 Sep 2003 12:29:27 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A0O8H-0005bN-00; Fri, 19 Sep 2003 12:29:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0Nmx-0001dJ-1J; Fri, 19 Sep 2003 12:07:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0Nlu-0001OT-8V for simple@optimus.ietf.org; Fri, 19 Sep 2003 12:06: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 MAA06742 for ; Fri, 19 Sep 2003 12:05:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0C7y-0001U2-00 for simple@ietf.org; Thu, 18 Sep 2003 23:40:14 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1A0BtS-0007VT-00 for simple@ietf.org; Thu, 18 Sep 2003 23:25:14 -0400 Received: from bart.cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h8J3PErm021407 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Thu, 18 Sep 2003 23:25:14 -0400 (EDT) Received: from cs.columbia.edu (localhost [127.0.0.1]) by bart.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h8J3P29s007511; Thu, 18 Sep 2003 23:25:03 -0400 (EDT) Message-ID: <3F6A770E.6070905@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: simple@ietf.org, gk@ninebynine.org Subject: Re: [Simple] [Fwd: Re: NETCONF WG meeting minutes for IETF #57] References: <2038BCC78B1AD641891A0D1AE133DBB70179710A@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB70179710A@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 18 Sep 2003 23:25:02 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: Thanks for the examples. The expressions are clearly far from obvious. I wonder if we can constrain the type of operations that we want to perform with presence tuples and express those operations more directly. The operations seem to be: - create a presence document that consists of tuples where attribute X has value Y - create a presence document that consists only of elements A, B, and C within (and combinations thereof) Are there others that make sense? I can see that for filtering random event documents, the Xpath model may be unavoidable in its proposed generality, but there seems to be a large danger of having filter specs create invalid presence documents by providing access to 'raw' Xpath. Thus, I wonder if a simpler description that is restricted to presence documents (and is guaranteed not to create invalid presence documents) wouldn't be helpful in practice. > Let me give you some examples: > > - A watcher wishes to get the tuple that has a element with value "IM". The watcher has to either explicitly list all the elements that can appear in a tuple that it wants to receive, or alternatively, it tells the PA to deliver the tuple that has element IM with all the other elements that appear in that tuple. Its like using a key for selecting a whole tuple. The latter can be achieved using the following expression: > > //*[rpid:class="IM"]/descendant-or-self::* > > > This actually selects the whole tuple only. if the watcher wants to select the tuple and the root element , you would do something like: > > //*[rpid:class="IM"]/descendant-or-self::* | //*[rpids:label="im"]/ancestor::* > > > - The following is an example of how you can ask a PA to include all tuples that are not of IM: > > //*[rpid:class="IM"]/following::* | //*[rpid:class="IM"]/preceding::* > > - A watcher asks the PA to deliver a tuple that has a status of "closed", but it only wants the elements that are not > > //*[basic="closed"]/following-sibling::* | //*[basic="closed"]/preceding-sibling::* | //*[basic="closed"]/ancestor::tuple > > > Again, this is if you don't want to indicate explicitly all the elements that you want. > > /Hisham > >>>- selecting descendents: descendent:: , descendent-or-self:: >>>- selecting ancestors: ancestor:: , ancestor or self:: >>>- selecting siblings: following-sibling:: , preceding-sibling:: >>>- selecting following and preceding elements: following:: , >> >>preceding:: >> >> >> >> >> _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Sat Sep 20 11:06: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 LAA09926; Sat, 20 Sep 2003 11:06:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0jJS-00058J-00; Sat, 20 Sep 2003 11:06:18 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A0jJN-00057c-00; Sat, 20 Sep 2003 11:06:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0jJC-00012o-4v; Sat, 20 Sep 2003 11: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 1A0jIr-00011g-K1 for simple@optimus.ietf.org; Sat, 20 Sep 2003 11:05: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 SAA24795; Fri, 19 Sep 2003 18:26:46 -0400 (EDT) From: hardie@qualcomm.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0TiH-0002IX-00; Fri, 19 Sep 2003 18:26:53 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx with esmtp (Exim 4.12) id 1A0Ti7-0002IE-00; Fri, 19 Sep 2003 18:26:43 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h8JMQ4uI003179; Fri, 19 Sep 2003 15:26:04 -0700 (PDT) Received: from [129.46.227.161] (carbuncle.qualcomm.com [129.46.227.161]) by crowley.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h8JMQ1ix026437; Fri, 19 Sep 2003 15:26:02 -0700 (PDT) Mime-Version: 1.0 X-Sender: hardie@mage.qualcomm.com Message-Id: In-Reply-To: <3F680EE9.1040604@dynamicsoft.com> References: <3F680EE9.1040604@dynamicsoft.com> To: Jonathan Rosenberg Cc: geopriv@ietf.org, Simple WG Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [Simple] Re: [Geopriv] A description of the relationship of permissions and rules. Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.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, 19 Sep 2003 15:26:10 -0700 Hi Jonathon, Response inline; sorry for the delay. At 3:36 AM -0400 09/17/2003, Jonathan Rosenberg wrote: >Ted, > >cc'ing SIMPLE since this is relevant to it. > >I was not at the interim, so I do not know the extent to which xcap >was discussed. It was discussed. Putting together the formulation in terms of Venn diagram level set theory was an action item of mine because some of the presentations used in interim used a RDBMs view and terminology which were not as familiar to some of the attendees. >However, the model you propose below is EXACTLY, and I mean exactly, >the model that is currently documented in >http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-auth-usage-00.txt. >Quoting from my document: > >>Structuring Presence Authorization >> >> This specification defines three application usages (each with their >> own XML schema) that, put together, present a comprehensive solution >> for allowing clients to specify authorization policies that a PA can >> use when processing a subscription. The first of these application >> usages has the AUID of permission-statements. This usage allows a >> client to make statements about which permissions are granted to >> which watchers. Each statement contains a definition of the watchers >> to whom it applies, and then contains a list of permissions which are >> granted to those watchers. The concept of a permission is central to >> this specification. A permission is an atomic statement of consent or >> denial. A permission can indicate a condition under which a >> subscription is accepted or rejected, a condition under which a >> notification is or is not sent, or a piece of information which is or >> is not revealed in a presence document. The overall authorization for >> a watcher is represented by the union of the permissions granted to >> that watcher. > > >I believe this is exactly what you are talking about. For presence, >I have classified these permissions as: > >whether it is accepted or not (a binary permission) >what the watcher can see >when the watcher gets a notification >transformations that get applied to the watcher > >To specify, for example, that Ted can subscribe to me and see my >contact URI, basic presence, and rpid information: > > > > sip:joe@example.com > > > > > urn:ietf:params:xml:ns:pidf > >urn:ietf:params:xml:ns:sip-rpids > > > > > >I explicitly chose this model because it had the crispest and >easiest to process composition model. That was important since, for >presence, the information sent to a watcher is going to be the >combination of rules specified by the watcher and by the presentity >(the source of the data in our terminology). This combination rule >is most easily done when, as you say, its a basic set operation. If >watcher asks for information X and the presentity has granted Y, the >watcher will receive the intersection of X and Y. > >more inline: > > > >hardie@qualcomm.com wrote: > >>During the recent GeoPriv meeting Henning and Hannes presented >>a model for understanding the application of the rules to location objects; >>as part of that discussion, I agreed to write up a view of that >>model seen through a very simple form of set theory (think elementary >>Venn diagrams). Below is a first attempt to capture that view. >> >>In this conceptualization, the starting point is that the privacy >>work of geopriv can be seen as populating a set of permissions >>associated with a particular location object. That set of >>permissions starts out empty. It is populated when the location >>object contains statements which add permissions. From a logical >>perspective, each location object contains 4 statements: >> >>1) A statement granting permission to retain the object for some time. >> >>2) A statement granting permission to distribute the object. >> >>3) A statement granting a granularity of accuracy for the object. >> >>4) A statement containing a URI at which further rules may be found. >> >> >>One of the keys to this model is that any statement or rule must be >>additive of permissions. An object may omit a particular statement, >>but doing so means that no permission is granted or that the protocol-defined >>minimum is granted (for 3, as an example, the defined minimum for civil >>location might be timezone, where the absence of the statement granting >>permission to distribute means the object must not be distributed). >>An object >>may, of course, choose to contain a statement that means "no permission to >>distribute" or "no permission to retain"; the ability to leave out the bytes >>carrying the assertion is an optimization, as the statement is >>logically present. >> >>If there is a statement containing a URI at which further rules may >>be found, those rules may add permissions to the statements asserted with >>the location object, but they may never take permissions away. In >>our Venn diagram set theory, in other words, when the conditions in >>those rules are met (the right identity is presented or the right >>time constraints are met, etc.), a new a set of permissions is granted, >>and that set is unioned with the set carried in the object. >>Note that this means if the statement containing the URI at which further >>rules may be found cannot be dereferenced, then it is still safe to behave >>according to the statements contained in the object, as these are the >>baseline permissions. In cases where the dereferencing of this URI is >>required for correct operation, these baselines are set to grant no >>permissions, >>so that the location object is not distributed or retained when the >>dereferencing has not occurred. > >I had not considered this aspect; definitely a benefit of the model. > >> >>Of those in the original formulation, then, a, b, c, and g are treated as >>assertions. All of the other "rules" are actually mechanisms for describing >>specific conditions which modify the assertions of permitted >>retention, distribution, >>and granularity by unioning new permissions to those in the original object. >> >>I believe this model has some advantages, particularly in that it makes the >>default behavior relatively easy to explain ("anything not >>permitted is denied, >>and what has been permitted may not be later be denied"). There are some >>potential gotchas, though, in that there is a risk of the model forcing the >>number of assertions beyond the bounds of practical implementation. To take >>one of Jim Polk's examples: If an employee wishes to grant permission >>beyond the baseline to all of her co-workers, a single assertion can work >>by associating a specific identity to that pool. If she wants to grant >>permission to all of her co-workers except one individual, for whom she >>has taken out a restraining order, to achieve her goal she might need >>to assert individual permissions for each of her remaining co-workers. This >>gets to the point of absurdity pretty quickly. The group at the interim >>meeting agreed to think more about the use cases in which "except"-type >>exclusions are required, and it also agreed that it might be the camels >>nose for regex-type processing ("allow anyone who is presenting an identity >>containing @example.com"), which we strongly felt to be beyond the scope >>of work we can do quickly. > >We had this exact same discussion in SIMPLE. Our conclusion was the >same - I would add except clauses to applies-to, so you could do >things like: > > > qualcomm.com > > hardie@qualcomm.com > > > >The basic processing is to compute the union of the identities >defined by the inclusive applies-top operators (we defined them as >, , and ) and then remove those specific by >. We discussed the except processing extensively, and I agree that it would be useful if it can avoid heavyweight processing. The group at the interim was very clear that regex-style processing was a serious problem. So something like: example.com t_*@example.com would be a no-no, even if it were a handy way to separate presentities for an example.com that prepends t_ to temporary worker account names. I am still not sure of the balance here, and more discussion is probably needed. In the short term, I hope we can develop base semantics which do not require it and do not prevent it. > >> >>The good news is that if we believe in the soundness of the >>fundamental model, >>we can publish documents describing the statements for retention, >>distribution, >>granularity, and naming of URIs without having completed the work >>on the rules, >>as we will be sure that the presence of the un-dereferenced URI >>will not constitute >>a privacy violation. > >I encountered one big snag in this model which I havent quite worked >out. THe snag is what we are calling "transformational permissions". >These are cases where I want to say "if my activity is 'busy', >change it to 'idle'". Simply put - lying. I believe that lying will >play a far more important role than omission of information, both in >presence and geolocation. I don't know if this was discussed at the >interim or not. It was, and we agreed that the current push to get the standard before the implementation and deployment of no-privacy systems is very widespread meant this was a feature that needed to be put on hold. That needs confirmation with the mailing list, of course, but I personally believe that the discussion was compelling. >Lying doesnt really fit into the model. Its not a permission in that >it doesnt grant access to a piece of information fundamentally in >the data. Rather, it asks for a change in that data. I could think >of no other solution than to include explicitly defined ordering >values that tell the server how to compose the information. Yes; this is a different model (referred to in the interim meeting as the "mistress model", for the shorthand case where you wanted to present a false geolocation to your spouse when you were with your mistress (and vice versa, no doubt)). One key thing here is that the rules sent with the data object are unaffected by the presence of this facility; you are obviously never going to send along the information that this data was made up. One restriction is, as above, if there is any case under which failing to apply the rules at a URI causes a problem, you must start out with a base case of no permissions granted (or the failure to dereference the URI means the mistress sees you're with your wife). regards, Ted Hardie _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Sat Sep 20 11:06:42 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 LAA09978 for ; Sat, 20 Sep 2003 11:06:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0jJV-00017o-Nj for simple-archive@odin.ietf.org; Sat, 20 Sep 2003 11:06:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8KF6L9v004323 for simple-archive@odin.ietf.org; Sat, 20 Sep 2003 11:06:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0jJV-00017e-Jc for simple-web-archive@optimus.ietf.org; Sat, 20 Sep 2003 11:06: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 LAA09926; Sat, 20 Sep 2003 11:06:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0jJS-00058J-00; Sat, 20 Sep 2003 11:06:18 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A0jJN-00057c-00; Sat, 20 Sep 2003 11:06:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0jJC-00012o-4v; Sat, 20 Sep 2003 11: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 1A0jIr-00011g-K1 for simple@optimus.ietf.org; Sat, 20 Sep 2003 11:05: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 SAA24795; Fri, 19 Sep 2003 18:26:46 -0400 (EDT) From: hardie@qualcomm.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0TiH-0002IX-00; Fri, 19 Sep 2003 18:26:53 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx with esmtp (Exim 4.12) id 1A0Ti7-0002IE-00; Fri, 19 Sep 2003 18:26:43 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h8JMQ4uI003179; Fri, 19 Sep 2003 15:26:04 -0700 (PDT) Received: from [129.46.227.161] (carbuncle.qualcomm.com [129.46.227.161]) by crowley.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h8JMQ1ix026437; Fri, 19 Sep 2003 15:26:02 -0700 (PDT) Mime-Version: 1.0 X-Sender: hardie@mage.qualcomm.com Message-Id: In-Reply-To: <3F680EE9.1040604@dynamicsoft.com> References: <3F680EE9.1040604@dynamicsoft.com> To: Jonathan Rosenberg Cc: geopriv@ietf.org, Simple WG Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [Simple] Re: [Geopriv] A description of the relationship of permissions and rules. Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.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, 19 Sep 2003 15:26:10 -0700 Hi Jonathon, Response inline; sorry for the delay. At 3:36 AM -0400 09/17/2003, Jonathan Rosenberg wrote: >Ted, > >cc'ing SIMPLE since this is relevant to it. > >I was not at the interim, so I do not know the extent to which xcap >was discussed. It was discussed. Putting together the formulation in terms of Venn diagram level set theory was an action item of mine because some of the presentations used in interim used a RDBMs view and terminology which were not as familiar to some of the attendees. >However, the model you propose below is EXACTLY, and I mean exactly, >the model that is currently documented in >http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-auth-usage-00.txt. >Quoting from my document: > >>Structuring Presence Authorization >> >> This specification defines three application usages (each with their >> own XML schema) that, put together, present a comprehensive solution >> for allowing clients to specify authorization policies that a PA can >> use when processing a subscription. The first of these application >> usages has the AUID of permission-statements. This usage allows a >> client to make statements about which permissions are granted to >> which watchers. Each statement contains a definition of the watchers >> to whom it applies, and then contains a list of permissions which are >> granted to those watchers. The concept of a permission is central to >> this specification. A permission is an atomic statement of consent or >> denial. A permission can indicate a condition under which a >> subscription is accepted or rejected, a condition under which a >> notification is or is not sent, or a piece of information which is or >> is not revealed in a presence document. The overall authorization for >> a watcher is represented by the union of the permissions granted to >> that watcher. > > >I believe this is exactly what you are talking about. For presence, >I have classified these permissions as: > >whether it is accepted or not (a binary permission) >what the watcher can see >when the watcher gets a notification >transformations that get applied to the watcher > >To specify, for example, that Ted can subscribe to me and see my >contact URI, basic presence, and rpid information: > > > > sip:joe@example.com > > > > > urn:ietf:params:xml:ns:pidf > >urn:ietf:params:xml:ns:sip-rpids > > > > > >I explicitly chose this model because it had the crispest and >easiest to process composition model. That was important since, for >presence, the information sent to a watcher is going to be the >combination of rules specified by the watcher and by the presentity >(the source of the data in our terminology). This combination rule >is most easily done when, as you say, its a basic set operation. If >watcher asks for information X and the presentity has granted Y, the >watcher will receive the intersection of X and Y. > >more inline: > > > >hardie@qualcomm.com wrote: > >>During the recent GeoPriv meeting Henning and Hannes presented >>a model for understanding the application of the rules to location objects; >>as part of that discussion, I agreed to write up a view of that >>model seen through a very simple form of set theory (think elementary >>Venn diagrams). Below is a first attempt to capture that view. >> >>In this conceptualization, the starting point is that the privacy >>work of geopriv can be seen as populating a set of permissions >>associated with a particular location object. That set of >>permissions starts out empty. It is populated when the location >>object contains statements which add permissions. From a logical >>perspective, each location object contains 4 statements: >> >>1) A statement granting permission to retain the object for some time. >> >>2) A statement granting permission to distribute the object. >> >>3) A statement granting a granularity of accuracy for the object. >> >>4) A statement containing a URI at which further rules may be found. >> >> >>One of the keys to this model is that any statement or rule must be >>additive of permissions. An object may omit a particular statement, >>but doing so means that no permission is granted or that the protocol-defined >>minimum is granted (for 3, as an example, the defined minimum for civil >>location might be timezone, where the absence of the statement granting >>permission to distribute means the object must not be distributed). >>An object >>may, of course, choose to contain a statement that means "no permission to >>distribute" or "no permission to retain"; the ability to leave out the bytes >>carrying the assertion is an optimization, as the statement is >>logically present. >> >>If there is a statement containing a URI at which further rules may >>be found, those rules may add permissions to the statements asserted with >>the location object, but they may never take permissions away. In >>our Venn diagram set theory, in other words, when the conditions in >>those rules are met (the right identity is presented or the right >>time constraints are met, etc.), a new a set of permissions is granted, >>and that set is unioned with the set carried in the object. >>Note that this means if the statement containing the URI at which further >>rules may be found cannot be dereferenced, then it is still safe to behave >>according to the statements contained in the object, as these are the >>baseline permissions. In cases where the dereferencing of this URI is >>required for correct operation, these baselines are set to grant no >>permissions, >>so that the location object is not distributed or retained when the >>dereferencing has not occurred. > >I had not considered this aspect; definitely a benefit of the model. > >> >>Of those in the original formulation, then, a, b, c, and g are treated as >>assertions. All of the other "rules" are actually mechanisms for describing >>specific conditions which modify the assertions of permitted >>retention, distribution, >>and granularity by unioning new permissions to those in the original object. >> >>I believe this model has some advantages, particularly in that it makes the >>default behavior relatively easy to explain ("anything not >>permitted is denied, >>and what has been permitted may not be later be denied"). There are some >>potential gotchas, though, in that there is a risk of the model forcing the >>number of assertions beyond the bounds of practical implementation. To take >>one of Jim Polk's examples: If an employee wishes to grant permission >>beyond the baseline to all of her co-workers, a single assertion can work >>by associating a specific identity to that pool. If she wants to grant >>permission to all of her co-workers except one individual, for whom she >>has taken out a restraining order, to achieve her goal she might need >>to assert individual permissions for each of her remaining co-workers. This >>gets to the point of absurdity pretty quickly. The group at the interim >>meeting agreed to think more about the use cases in which "except"-type >>exclusions are required, and it also agreed that it might be the camels >>nose for regex-type processing ("allow anyone who is presenting an identity >>containing @example.com"), which we strongly felt to be beyond the scope >>of work we can do quickly. > >We had this exact same discussion in SIMPLE. Our conclusion was the >same - I would add except clauses to applies-to, so you could do >things like: > > > qualcomm.com > > hardie@qualcomm.com > > > >The basic processing is to compute the union of the identities >defined by the inclusive applies-top operators (we defined them as >, , and ) and then remove those specific by >. We discussed the except processing extensively, and I agree that it would be useful if it can avoid heavyweight processing. The group at the interim was very clear that regex-style processing was a serious problem. So something like: example.com t_*@example.com would be a no-no, even if it were a handy way to separate presentities for an example.com that prepends t_ to temporary worker account names. I am still not sure of the balance here, and more discussion is probably needed. In the short term, I hope we can develop base semantics which do not require it and do not prevent it. > >> >>The good news is that if we believe in the soundness of the >>fundamental model, >>we can publish documents describing the statements for retention, >>distribution, >>granularity, and naming of URIs without having completed the work >>on the rules, >>as we will be sure that the presence of the un-dereferenced URI >>will not constitute >>a privacy violation. > >I encountered one big snag in this model which I havent quite worked >out. THe snag is what we are calling "transformational permissions". >These are cases where I want to say "if my activity is 'busy', >change it to 'idle'". Simply put - lying. I believe that lying will >play a far more important role than omission of information, both in >presence and geolocation. I don't know if this was discussed at the >interim or not. It was, and we agreed that the current push to get the standard before the implementation and deployment of no-privacy systems is very widespread meant this was a feature that needed to be put on hold. That needs confirmation with the mailing list, of course, but I personally believe that the discussion was compelling. >Lying doesnt really fit into the model. Its not a permission in that >it doesnt grant access to a piece of information fundamentally in >the data. Rather, it asks for a change in that data. I could think >of no other solution than to include explicitly defined ordering >values that tell the server how to compose the information. Yes; this is a different model (referred to in the interim meeting as the "mistress model", for the shorthand case where you wanted to present a false geolocation to your spouse when you were with your mistress (and vice versa, no doubt)). One key thing here is that the rules sent with the data object are unaffected by the presence of this facility; you are obviously never going to send along the information that this data was made up. One restriction is, as above, if there is any case under which failing to apply the rules at a URI causes a problem, you must start out with a base case of no permissions granted (or the failure to dereference the URI means the mistress sees you're with your wife). regards, Ted Hardie _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Sat Sep 20 11:16:40 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 LAA10616; Sat, 20 Sep 2003 11:16:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0jSs-0002P1-BI; Sat, 20 Sep 2003 11:16:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0ibz-0006f7-CP for simple@optimus.ietf.org; Sat, 20 Sep 2003 10:21: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 VAA02173 for ; Fri, 19 Sep 2003 21:50:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0Wt6-0005Q3-00 for simple@ietf.org; Fri, 19 Sep 2003 21:50:16 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1A0Wsq-0005Ps-00 for simple@ietf.org; Fri, 19 Sep 2003 21:50:00 -0400 Received: from razor.cs.columbia.edu (IDENT:root@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id h8K1nkfH018064; Fri, 19 Sep 2003 21:49:46 -0400 (EDT) Received: from cs.columbia.edu (IDENT:root@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h8K1njr20693; Fri, 19 Sep 2003 21:49:45 -0400 Message-ID: <3F6BB239.8080100@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: "James M. Polk" , Tschofenig Hannes , John Morris , geopriv@mail.apps.ietf.org, Simple WG References: <4.3.2.7.2.20030917115817.024b48f8@localhost> <3F5BF2E6.4010107@cs.columbia.edu> <3F5BF2E6.4010107@cs.columbia.edu> <4.3.2.7.2.20030917115817.024b48f8@localhost> <4.3.2.7.2.20030917165849.024ad9d0@localhost> <3F691CCF.7080002@cs.columbia.edu> <3F6B6C03.4070406@dynamicsoft.com> In-Reply-To: <3F6B6C03.4070406@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Re: Georpiv and actively lying Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.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, 19 Sep 2003 21:49:45 -0400 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > What happens if someone is associated with both home and work spheres? > They will now receive conflicting information. Is that the result we > want? You might argue thats ok, since a user in both spheres should be > allowed to see both perspectives. However, it reveals additional > information - namely, that the user is explicitly given out conflicting > information depending on the sphere - and this may not be desirable. In the 'class' model I mentioned earlier, the sphere input selects the class. Thus, you get to decide what happens: if (sphere = home) publish class=1 if (sphere = home,work) publish class=1 if (sphere = work) publish class=2 qualified as necessary by location, watcher/recipient (boss vs. friend), etc. Alternatively, you can use sphere as both condition and selector if (sphere = home) publish sphere=home if (sphere = home,work) publish sphere=home if (sphere = work) publish sphere=work This allows the rule maker to make an explicit decision to whatever granularity is desired. Here, 'publish X=Y' means "publish tuples/geo-elements where element X has value Y. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Sat Sep 20 11:16:40 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 LAA10617; Sat, 20 Sep 2003 11:16:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0jSq-0002O7-LN; Sat, 20 Sep 2003 11:16:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0ify-0006f7-8v for simple@optimus.ietf.org; Sat, 20 Sep 2003 10:25: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 RAA22112 for ; Fri, 19 Sep 2003 17:13:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0SZC-0001cB-00 for simple@ietf.org; Fri, 19 Sep 2003 17:13:26 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1A0SZ1-0001bm-00 for simple@ietf.org; Fri, 19 Sep 2003 17:13:15 -0400 Received: from dynamicsoft.com ([63.113.46.35]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h8JLCGUg017540; Fri, 19 Sep 2003 17:12:16 -0400 (EDT) Message-ID: <3F6B7129.7020303@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne CC: hisham.khartabil@nokia.com, simple@ietf.org, gk@ninebynine.org Subject: Re: [Simple] [Fwd: Re: NETCONF WG meeting minutes for IETF #57] References: <2038BCC78B1AD641891A0D1AE133DBB70179710A@esebe019.ntc.nokia.com> <3F6A770E.6070905@cs.columbia.edu> In-Reply-To: <3F6A770E.6070905@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: Fri, 19 Sep 2003 17:12:09 -0400 Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > hisham.khartabil@nokia.com wrote: > Thanks for the examples. The expressions are clearly far from obvious. I > wonder if we can constrain the type of operations that we want to > perform with presence tuples and express those operations more directly. I would also like to explore this avenue. It seems to me that fairly complex xpath expressions, like the ones Hisham posted, would be needed to cause filtering or auth policies to result in the desired document. My concern is not that the operation these perform isn't "obvious" to a person. Rather, its performance. We are going to be a big tax in XML manipulations in order to make a set of changes to a presence document, which could have been enumerated and explicitly supported ahead of time. I dont think that, at this point in time, the generality is worth the performance it will probably cost. > The operations seem to be: > > - create a presence document that consists of tuples where attribute X > has value Y > > - create a presence document that consists only of elements A, B, and C > within > > (and combinations thereof) > > Are there others that make sense? The current xcap auth document allows a few more: * create a presence document that has everything but the contact address (so users can see your status but can't contact you per se) * making the above two items conditional on the value of a specific element A within * create a presence document that consists only of elements A, B, C which come from the specified set of XML namespaces * create a presence document that has elements A, B, C only if they have the specified values > > I can see that for filtering random event documents, the Xpath model may > be unavoidable in its proposed generality, but there seems to be a large > danger of having filter specs create invalid presence documents by > providing access to 'raw' Xpath. Thus, I wonder if a simpler description > that is restricted to presence documents (and is guaranteed not to > create invalid presence documents) wouldn't be helpful in practice. There is also the performance issue with xml manipulations that I am really worried about. Practically speaking, I suspect many implementations will not actually STORE the presence data internally in XML format. Rather, they will have highly optimized internal representations commensurate with the set of supported manipulations on that data. If this is done, implementing a filter requires the encoding of that internal data into a full presence document, followed by Xpath processing, followed by a discard of the data that doesnt match. It would be much more efficient to discard data first while its still in the raw format, and THEN encode into XML. That can only be done when the authorization and filtering policies are expressed semantically, rather than as syntactic transformations on the final XML document. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Sat Sep 20 11:17:12 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10683 for ; Sat, 20 Sep 2003 11:17:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0jTd-0002eD-0y for simple-archive@odin.ietf.org; Sat, 20 Sep 2003 11:16:49 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8KFGnrr010177 for simple-archive@odin.ietf.org; Sat, 20 Sep 2003 11:16:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0jTc-0002e4-Rw for simple-web-archive@optimus.ietf.org; Sat, 20 Sep 2003 11:16:48 -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 LAA10616; Sat, 20 Sep 2003 11:16:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0jSs-0002P1-BI; Sat, 20 Sep 2003 11:16:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0ibz-0006f7-CP for simple@optimus.ietf.org; Sat, 20 Sep 2003 10:21: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 VAA02173 for ; Fri, 19 Sep 2003 21:50:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0Wt6-0005Q3-00 for simple@ietf.org; Fri, 19 Sep 2003 21:50:16 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1A0Wsq-0005Ps-00 for simple@ietf.org; Fri, 19 Sep 2003 21:50:00 -0400 Received: from razor.cs.columbia.edu (IDENT:root@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id h8K1nkfH018064; Fri, 19 Sep 2003 21:49:46 -0400 (EDT) Received: from cs.columbia.edu (IDENT:root@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h8K1njr20693; Fri, 19 Sep 2003 21:49:45 -0400 Message-ID: <3F6BB239.8080100@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: "James M. Polk" , Tschofenig Hannes , John Morris , geopriv@mail.apps.ietf.org, Simple WG References: <4.3.2.7.2.20030917115817.024b48f8@localhost> <3F5BF2E6.4010107@cs.columbia.edu> <3F5BF2E6.4010107@cs.columbia.edu> <4.3.2.7.2.20030917115817.024b48f8@localhost> <4.3.2.7.2.20030917165849.024ad9d0@localhost> <3F691CCF.7080002@cs.columbia.edu> <3F6B6C03.4070406@dynamicsoft.com> In-Reply-To: <3F6B6C03.4070406@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Re: Georpiv and actively lying Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.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, 19 Sep 2003 21:49:45 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > What happens if someone is associated with both home and work spheres? > They will now receive conflicting information. Is that the result we > want? You might argue thats ok, since a user in both spheres should be > allowed to see both perspectives. However, it reveals additional > information - namely, that the user is explicitly given out conflicting > information depending on the sphere - and this may not be desirable. In the 'class' model I mentioned earlier, the sphere input selects the class. Thus, you get to decide what happens: if (sphere = home) publish class=1 if (sphere = home,work) publish class=1 if (sphere = work) publish class=2 qualified as necessary by location, watcher/recipient (boss vs. friend), etc. Alternatively, you can use sphere as both condition and selector if (sphere = home) publish sphere=home if (sphere = home,work) publish sphere=home if (sphere = work) publish sphere=work This allows the rule maker to make an explicit decision to whatever granularity is desired. Here, 'publish X=Y' means "publish tuples/geo-elements where element X has value Y. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Sat Sep 20 11:17:16 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 LAA10707 for ; Sat, 20 Sep 2003 11:17:16 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0jTh-0002ec-U9 for simple-archive@odin.ietf.org; Sat, 20 Sep 2003 11:16:54 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8KFGroT010196 for simple-archive@odin.ietf.org; Sat, 20 Sep 2003 11:16:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0jTh-0002eN-Qw for simple-web-archive@optimus.ietf.org; Sat, 20 Sep 2003 11:16:53 -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 LAA10617; Sat, 20 Sep 2003 11:16:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0jSq-0002O7-LN; Sat, 20 Sep 2003 11:16:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0ify-0006f7-8v for simple@optimus.ietf.org; Sat, 20 Sep 2003 10:25: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 RAA22112 for ; Fri, 19 Sep 2003 17:13:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0SZC-0001cB-00 for simple@ietf.org; Fri, 19 Sep 2003 17:13:26 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1A0SZ1-0001bm-00 for simple@ietf.org; Fri, 19 Sep 2003 17:13:15 -0400 Received: from dynamicsoft.com ([63.113.46.35]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h8JLCGUg017540; Fri, 19 Sep 2003 17:12:16 -0400 (EDT) Message-ID: <3F6B7129.7020303@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne CC: hisham.khartabil@nokia.com, simple@ietf.org, gk@ninebynine.org Subject: Re: [Simple] [Fwd: Re: NETCONF WG meeting minutes for IETF #57] References: <2038BCC78B1AD641891A0D1AE133DBB70179710A@esebe019.ntc.nokia.com> <3F6A770E.6070905@cs.columbia.edu> In-Reply-To: <3F6A770E.6070905@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: Fri, 19 Sep 2003 17:12:09 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > hisham.khartabil@nokia.com wrote: > Thanks for the examples. The expressions are clearly far from obvious. I > wonder if we can constrain the type of operations that we want to > perform with presence tuples and express those operations more directly. I would also like to explore this avenue. It seems to me that fairly complex xpath expressions, like the ones Hisham posted, would be needed to cause filtering or auth policies to result in the desired document. My concern is not that the operation these perform isn't "obvious" to a person. Rather, its performance. We are going to be a big tax in XML manipulations in order to make a set of changes to a presence document, which could have been enumerated and explicitly supported ahead of time. I dont think that, at this point in time, the generality is worth the performance it will probably cost. > The operations seem to be: > > - create a presence document that consists of tuples where attribute X > has value Y > > - create a presence document that consists only of elements A, B, and C > within > > (and combinations thereof) > > Are there others that make sense? The current xcap auth document allows a few more: * create a presence document that has everything but the contact address (so users can see your status but can't contact you per se) * making the above two items conditional on the value of a specific element A within * create a presence document that consists only of elements A, B, C which come from the specified set of XML namespaces * create a presence document that has elements A, B, C only if they have the specified values > > I can see that for filtering random event documents, the Xpath model may > be unavoidable in its proposed generality, but there seems to be a large > danger of having filter specs create invalid presence documents by > providing access to 'raw' Xpath. Thus, I wonder if a simpler description > that is restricted to presence documents (and is guaranteed not to > create invalid presence documents) wouldn't be helpful in practice. There is also the performance issue with xml manipulations that I am really worried about. Practically speaking, I suspect many implementations will not actually STORE the presence data internally in XML format. Rather, they will have highly optimized internal representations commensurate with the set of supported manipulations on that data. If this is done, implementing a filter requires the encoding of that internal data into a full presence document, followed by Xpath processing, followed by a discard of the data that doesnt match. It would be much more efficient to discard data first while its still in the raw format, and THEN encode into XML. That can only be done when the authorization and filtering policies are expressed semantically, rather than as syntactic transformations on the final XML document. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Sat Sep 20 11:25:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11676; Sat, 20 Sep 2003 11:25:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0jbd-0004vZ-LT; Sat, 20 Sep 2003 11:25:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0jIL-0000sX-Ei for simple@optimus.ietf.org; Sat, 20 Sep 2003 11:05: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 SAA25118 for ; Fri, 19 Sep 2003 18:39:17 -0400 (EDT) From: hardie@qualcomm.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0TuO-0002Ra-00 for simple@ietf.org; Fri, 19 Sep 2003 18:39:24 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx with esmtp (Exim 4.12) id 1A0TuE-0002RP-00 for simple@ietf.org; Fri, 19 Sep 2003 18:39:14 -0400 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h8JMcQuI004343; Fri, 19 Sep 2003 15:38:26 -0700 (PDT) Received: from [129.46.227.161] (carbuncle.qualcomm.com [129.46.227.161]) by magus.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h8JMcNsh020009; Fri, 19 Sep 2003 15:38:23 -0700 (PDT) Mime-Version: 1.0 X-Sender: hardie@mage.qualcomm.com Message-Id: In-Reply-To: <3F6B6C03.4070406@dynamicsoft.com> References: <4.3.2.7.2.20030917115817.024b48f8@localhost> <3F5BF2E6.4010107@cs.columbia.edu> <3F5BF2E6.4010107@cs.columbia.edu> <4.3.2.7.2.20030917115817.024b48f8@localhost> <4.3.2.7.2.20030917165849.024ad9d0@localhost> <3F691CCF.7080002@cs.columbia.edu> <3F6B6C03.4070406@dynamicsoft.com> To: Jonathan Rosenberg , Henning Schulzrinne Cc: "James M. Polk" , Tschofenig Hannes , John Morris , geopriv@mail.apps.ietf.org, Simple WG Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [Simple] Re: Georpiv and actively lying Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.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, 19 Sep 2003 15:38:32 -0700 At 4:50 PM -0400 09/19/2003, Jonathan Rosenberg wrote: >Henning Schulzrinne wrote: > >>James M. Polk wrote: >> >>>Why should we design for permissible lying in an IETF effort? >>> >>>If your server or service is configured to give out >>>misinformation, that's one thing - but to build it into the >>>protocol as a requirement lacks technical justification at this >>>point. A compliant protocol implementation shouldn't be required >>>to be able to lie just to be compliant. A protocol that chooses >>>not to be compliant can always misbehave. >> >> >>No particular protocol effort is required to build a lying >>implementation. In a presence model, I can have my 'alibi >>publisher' publish any Munchhausen location information that I like >>and then select to only propagate that information, rather than my >>GPS information. (For example, using my earlier sphere proposal, >>designate myself in the "mistress" sphere, which automatically only >>selects data from that source, presumably without including the >>label.) This is functionally no different than considering my >>calendar as an approximate location source. I'm not sure I follow this. Does this imply that you use an "alibi publisher" to change your location under certain circumstances and that this location is held to be valid for all watchers? If so, this requires no special processing in the GeoPriv sense; it simply implies that you can adjust location provider by configuration. If you do intend it to apply only to certain watchers, then we're back to a serious set of issues, including how to do in-the-moment updates of the rules, how to apply transformative rules, and so on. >We have discussed this in the past as part of the facet header >discussion in Aki's publication work, and I believe Aki also suggest >it again somewhere in this thread. > >I believe it can work. It has the benefit that it can have lots of >flexibility. If this transformation is done on the server, you need >to specify particular transformations that are possible so that the >user can set them as it desires. THe drawback is that it now >requires two publishers for a single user just to support this >capability. It also introduces the need to coordination between >those publications, either by havign them co-resident, or through >some other means. When co-resident, say, on a wireless handset, it >may increase bandwidth usage by sending information which could have >been algorithmically derived at the server. This seems to me to be more flexibility than GeoPriv can handle at the moment. The bang for this buck seems awfully small, and the delay larger than is warranted. Just my opinion, of course, regards, Ted _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Sat Sep 20 11:26:06 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 LAA11802 for ; Sat, 20 Sep 2003 11:26:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0jcF-0005K6-Jv for simple-archive@odin.ietf.org; Sat, 20 Sep 2003 11:25:43 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8KFPhhw020451 for simple-archive@odin.ietf.org; Sat, 20 Sep 2003 11:25:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0jcF-0005Jf-62 for simple-web-archive@optimus.ietf.org; Sat, 20 Sep 2003 11:25:43 -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 LAA11676; Sat, 20 Sep 2003 11:25:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0jbd-0004vZ-LT; Sat, 20 Sep 2003 11:25:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0jIL-0000sX-Ei for simple@optimus.ietf.org; Sat, 20 Sep 2003 11:05: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 SAA25118 for ; Fri, 19 Sep 2003 18:39:17 -0400 (EDT) From: hardie@qualcomm.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0TuO-0002Ra-00 for simple@ietf.org; Fri, 19 Sep 2003 18:39:24 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx with esmtp (Exim 4.12) id 1A0TuE-0002RP-00 for simple@ietf.org; Fri, 19 Sep 2003 18:39:14 -0400 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h8JMcQuI004343; Fri, 19 Sep 2003 15:38:26 -0700 (PDT) Received: from [129.46.227.161] (carbuncle.qualcomm.com [129.46.227.161]) by magus.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h8JMcNsh020009; Fri, 19 Sep 2003 15:38:23 -0700 (PDT) Mime-Version: 1.0 X-Sender: hardie@mage.qualcomm.com Message-Id: In-Reply-To: <3F6B6C03.4070406@dynamicsoft.com> References: <4.3.2.7.2.20030917115817.024b48f8@localhost> <3F5BF2E6.4010107@cs.columbia.edu> <3F5BF2E6.4010107@cs.columbia.edu> <4.3.2.7.2.20030917115817.024b48f8@localhost> <4.3.2.7.2.20030917165849.024ad9d0@localhost> <3F691CCF.7080002@cs.columbia.edu> <3F6B6C03.4070406@dynamicsoft.com> To: Jonathan Rosenberg , Henning Schulzrinne Cc: "James M. Polk" , Tschofenig Hannes , John Morris , geopriv@mail.apps.ietf.org, Simple WG Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [Simple] Re: Georpiv and actively lying Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.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, 19 Sep 2003 15:38:32 -0700 At 4:50 PM -0400 09/19/2003, Jonathan Rosenberg wrote: >Henning Schulzrinne wrote: > >>James M. Polk wrote: >> >>>Why should we design for permissible lying in an IETF effort? >>> >>>If your server or service is configured to give out >>>misinformation, that's one thing - but to build it into the >>>protocol as a requirement lacks technical justification at this >>>point. A compliant protocol implementation shouldn't be required >>>to be able to lie just to be compliant. A protocol that chooses >>>not to be compliant can always misbehave. >> >> >>No particular protocol effort is required to build a lying >>implementation. In a presence model, I can have my 'alibi >>publisher' publish any Munchhausen location information that I like >>and then select to only propagate that information, rather than my >>GPS information. (For example, using my earlier sphere proposal, >>designate myself in the "mistress" sphere, which automatically only >>selects data from that source, presumably without including the >>label.) This is functionally no different than considering my >>calendar as an approximate location source. I'm not sure I follow this. Does this imply that you use an "alibi publisher" to change your location under certain circumstances and that this location is held to be valid for all watchers? If so, this requires no special processing in the GeoPriv sense; it simply implies that you can adjust location provider by configuration. If you do intend it to apply only to certain watchers, then we're back to a serious set of issues, including how to do in-the-moment updates of the rules, how to apply transformative rules, and so on. >We have discussed this in the past as part of the facet header >discussion in Aki's publication work, and I believe Aki also suggest >it again somewhere in this thread. > >I believe it can work. It has the benefit that it can have lots of >flexibility. If this transformation is done on the server, you need >to specify particular transformations that are possible so that the >user can set them as it desires. THe drawback is that it now >requires two publishers for a single user just to support this >capability. It also introduces the need to coordination between >those publications, either by havign them co-resident, or through >some other means. When co-resident, say, on a wireless handset, it >may increase bandwidth usage by sending information which could have >been algorithmically derived at the server. This seems to me to be more flexibility than GeoPriv can handle at the moment. The bang for this buck seems awfully small, and the delay larger than is warranted. Just my opinion, of course, regards, Ted _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Sat Sep 20 11:30:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12543; Sat, 20 Sep 2003 11:30:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0jgQ-0006hH-O3; Sat, 20 Sep 2003 11: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 1A0jFq-0000sX-NA for simple@optimus.ietf.org; Sat, 20 Sep 2003 11:02: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 VAA02360 for ; Fri, 19 Sep 2003 21:58:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0X0w-0005Vt-00 for simple@ietf.org; Fri, 19 Sep 2003 21:58:22 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1A0X0g-0005Vm-00 for simple@ietf.org; Fri, 19 Sep 2003 21:58:06 -0400 Received: from razor.cs.columbia.edu (IDENT:root@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id h8K1vufH018840; Fri, 19 Sep 2003 21:57:56 -0400 (EDT) Received: from cs.columbia.edu (IDENT:root@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h8K1vkr20717; Fri, 19 Sep 2003 21:57:46 -0400 Message-ID: <3F6BB419.8060108@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: hisham.khartabil@nokia.com, simple@ietf.org, gk@ninebynine.org Subject: Re: [Simple] [Fwd: Re: NETCONF WG meeting minutes for IETF #57] References: <2038BCC78B1AD641891A0D1AE133DBB70179710A@esebe019.ntc.nokia.com> <3F6A770E.6070905@cs.columbia.edu> <3F6B7129.7020303@dynamicsoft.com> In-Reply-To: <3F6B7129.7020303@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 19 Sep 2003 21:57:45 -0400 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: >> - create a presence document that consists of tuples where attribute X >> has value Y >> >> - create a presence document that consists only of elements A, B, and >> C within >> >> (and combinations thereof) >> >> Are there others that make sense? > > > The current xcap auth document allows a few more: > > * create a presence document that has everything but the contact address > (so users can see your status but can't contact you per se) This seems a special case of the 'everything-except' rule. This doesn't require xpath, just an element name (with name-space). > > * making the above two items conditional on the value of a specific > element A within That's part of the conditional part (see the geopriv discussions). > > * create a presence document that consists only of elements A, B, C > which come from the specified set of XML namespaces A generalization of the selection above. > > * create a presence document that has elements A, B, C only if they have > the specified values Again, separate issue - selection. > There is also the performance issue with xml manipulations that I am > really worried about. Practically speaking, I suspect many > implementations will not actually STORE the presence data internally in > XML format. Rather, they will have highly optimized internal > representations commensurate with the set of supported manipulations on > that data. I've tried to make this point at the GEOPRIV interim meeting and suggested that we test any rule language on whether an SQL-like language could be used to implement it. This doesn't mean that people will use SQL (although this is more reasonable than traversing and processing raw XML for each presence update), but it does mark a particular regimen of complexity that is well-understood and known to scale to large data sets and large transaction volumes. In particular, it implies a relatively flat rather than tree-shaped data model within each tuple. Another way of looking at this is that we should be able to write rules as a table, not as an arbitrarily nested program. > > If this is done, implementing a filter requires the encoding of that > internal data into a full presence document, followed by Xpath > processing, followed by a discard of the data that doesnt match. It > would be much more efficient to discard data first while its still in > the raw format, and THEN encode into XML. That can only be done when the > authorization and filtering policies are expressed semantically, rather > than as syntactic transformations on the final XML document. > > > -Jonathan R. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Sat Sep 20 11:31:06 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 LAA12593 for ; Sat, 20 Sep 2003 11:31:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0jh5-0006lc-If for simple-archive@odin.ietf.org; Sat, 20 Sep 2003 11:30:43 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8KFUhop026011 for simple-archive@odin.ietf.org; Sat, 20 Sep 2003 11:30:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0jh5-0006lS-DB for simple-web-archive@optimus.ietf.org; Sat, 20 Sep 2003 11:30:43 -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 LAA12543; Sat, 20 Sep 2003 11:30:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0jgQ-0006hH-O3; Sat, 20 Sep 2003 11: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 1A0jFq-0000sX-NA for simple@optimus.ietf.org; Sat, 20 Sep 2003 11:02: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 VAA02360 for ; Fri, 19 Sep 2003 21:58:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0X0w-0005Vt-00 for simple@ietf.org; Fri, 19 Sep 2003 21:58:22 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1A0X0g-0005Vm-00 for simple@ietf.org; Fri, 19 Sep 2003 21:58:06 -0400 Received: from razor.cs.columbia.edu (IDENT:root@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id h8K1vufH018840; Fri, 19 Sep 2003 21:57:56 -0400 (EDT) Received: from cs.columbia.edu (IDENT:root@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h8K1vkr20717; Fri, 19 Sep 2003 21:57:46 -0400 Message-ID: <3F6BB419.8060108@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: hisham.khartabil@nokia.com, simple@ietf.org, gk@ninebynine.org Subject: Re: [Simple] [Fwd: Re: NETCONF WG meeting minutes for IETF #57] References: <2038BCC78B1AD641891A0D1AE133DBB70179710A@esebe019.ntc.nokia.com> <3F6A770E.6070905@cs.columbia.edu> <3F6B7129.7020303@dynamicsoft.com> In-Reply-To: <3F6B7129.7020303@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 19 Sep 2003 21:57:45 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: >> - create a presence document that consists of tuples where attribute X >> has value Y >> >> - create a presence document that consists only of elements A, B, and >> C within >> >> (and combinations thereof) >> >> Are there others that make sense? > > > The current xcap auth document allows a few more: > > * create a presence document that has everything but the contact address > (so users can see your status but can't contact you per se) This seems a special case of the 'everything-except' rule. This doesn't require xpath, just an element name (with name-space). > > * making the above two items conditional on the value of a specific > element A within That's part of the conditional part (see the geopriv discussions). > > * create a presence document that consists only of elements A, B, C > which come from the specified set of XML namespaces A generalization of the selection above. > > * create a presence document that has elements A, B, C only if they have > the specified values Again, separate issue - selection. > There is also the performance issue with xml manipulations that I am > really worried about. Practically speaking, I suspect many > implementations will not actually STORE the presence data internally in > XML format. Rather, they will have highly optimized internal > representations commensurate with the set of supported manipulations on > that data. I've tried to make this point at the GEOPRIV interim meeting and suggested that we test any rule language on whether an SQL-like language could be used to implement it. This doesn't mean that people will use SQL (although this is more reasonable than traversing and processing raw XML for each presence update), but it does mark a particular regimen of complexity that is well-understood and known to scale to large data sets and large transaction volumes. In particular, it implies a relatively flat rather than tree-shaped data model within each tuple. Another way of looking at this is that we should be able to write rules as a table, not as an arbitrarily nested program. > > If this is done, implementing a filter requires the encoding of that > internal data into a full presence document, followed by Xpath > processing, followed by a discard of the data that doesnt match. It > would be much more efficient to discard data first while its still in > the raw format, and THEN encode into XML. That can only be done when the > authorization and filtering policies are expressed semantically, rather > than as syntactic transformations on the final XML document. > > > -Jonathan R. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Sat Sep 20 11:39:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13644; Sat, 20 Sep 2003 11:39:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0jpJ-0000iG-OA; Sat, 20 Sep 2003 11: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 1A0icA-0006f7-6T for simple@optimus.ietf.org; Sat, 20 Sep 2003 10:21: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 VAA02021 for ; Fri, 19 Sep 2003 21:43:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0WmG-0005MI-00 for simple@ietf.org; Fri, 19 Sep 2003 21:43:12 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1A0Wm0-0005LM-00 for simple@ietf.org; Fri, 19 Sep 2003 21:42:56 -0400 Received: from razor.cs.columbia.edu (IDENT:root@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id h8K1g6fH017532; Fri, 19 Sep 2003 21:42:07 -0400 (EDT) Received: from cs.columbia.edu (IDENT:root@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h8K1g5r20642; Fri, 19 Sep 2003 21:42:06 -0400 Message-ID: <3F6BB06D.5080800@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hardie@qualcomm.com CC: Jonathan Rosenberg , "James M. Polk" , Tschofenig Hannes , John Morris , geopriv@mail.apps.ietf.org, Simple WG References: <4.3.2.7.2.20030917115817.024b48f8@localhost> <3F5BF2E6.4010107@cs.columbia.edu> <3F5BF2E6.4010107@cs.columbia.edu> <4.3.2.7.2.20030917115817.024b48f8@localhost> <4.3.2.7.2.20030917165849.024ad9d0@localhost> <3F691CCF.7080002@cs.columbia.edu> <3F6B6C03.4070406@dynamicsoft.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Re: Georpiv and actively lying Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.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, 19 Sep 2003 21:42:05 -0400 Content-Transfer-Encoding: 7bit hardie@qualcomm.com wrote: > I'm not sure I follow this. Does this imply that you use an "alibi > publisher" to change > your location under certain circumstances and that this location is held > to be valid > for all watchers? If so, this requires no special processing in the The alibi data could be delivered to all watchers or only delivered to certain watchers (the spouse in the running example). This only requires a selection mechanism, as we already need the ability for a location server to select from different representations. (For a completely different example unrelated to lying, I might want to deliver my 802.11-derived location information indoors, but GPS outdoors.) > GeoPriv sense; it > simply implies that you can adjust location provider by configuration. > If you do intend > it to apply only to certain watchers, then we're back to a serious set > of issues, including > how to do in-the-moment updates of the rules, how to apply > transformative rules, > and so on. Not necessarily. All I need is to do labeling of data and a selector. Consider the following rule, expressed in the 'conditional statement' version of my rule model: if (observer=FBI) select class=alibi or if (area=indoors) select class=802-11 RPID, for example, has such a class attribute for tuples. >> I believe it can work. It has the benefit that it can have lots of >> flexibility. If this transformation is done on the server, you need to >> specify particular transformations that are possible so that the user >> can set them as it desires. THe drawback is that it now requires two >> publishers for a single user just to support this capability. It also >> introduces the need to coordination between those publications, either >> by havign them co-resident, or through some other means. When >> co-resident, say, on a wireless handset, it may increase bandwidth >> usage by sending information which could have been algorithmically >> derived at the server. As I point out elsewhere, any self-respecting liar (if there's such a thing) would need to have more than just constants in his lies. Thus, you either need to have a rulemaker that updates the lie or a publisher that publishes a new document. Both are roughly equivalent, except that the publisher mechanism does not require the cooperation of the location server (or PA, in the SIMPLE context) and thus is likely to be more flexible. > > > This seems to me to be more flexibility than GeoPriv can handle at the > moment. The bang for > this buck seems awfully small, and the delay larger than is warranted. Are you referring to the ability to lie in general, the ability for the LS to transform my location into a lie or the ability to publish two location object and allow for selection? I have to admit that I find adding complexity for willful misrepresentation a waste of resources (and hope that Ted's statement agrees with that...). > Just my opinion, of > course, > regards, > Ted > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Sat Sep 20 12:14: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 MAA14868; Sat, 20 Sep 2003 12:14:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0kNE-00068F-00; Sat, 20 Sep 2003 12:14:16 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A0kN9-00068C-00; Sat, 20 Sep 2003 12:14:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0kMz-0004OJ-Tu; Sat, 20 Sep 2003 12:14:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0k2R-0002Ar-3R for simple@optimus.ietf.org; Sat, 20 Sep 2003 11:52: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 QAA21641 for ; Fri, 19 Sep 2003 16:51:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0SEQ-0001OD-00 for simple@ietf.org; Fri, 19 Sep 2003 16:51:58 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1A0SEE-0001MQ-00 for simple@ietf.org; Fri, 19 Sep 2003 16:51:47 -0400 Received: from dynamicsoft.com ([63.113.46.35]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h8JKoJUg017517; Fri, 19 Sep 2003 16:50:21 -0400 (EDT) Message-ID: <3F6B6C03.4070406@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne CC: "James M. Polk" , Tschofenig Hannes , John Morris , geopriv@mail.apps.ietf.org, Simple WG References: <4.3.2.7.2.20030917115817.024b48f8@localhost> <3F5BF2E6.4010107@cs.columbia.edu> <3F5BF2E6.4010107@cs.columbia.edu> <4.3.2.7.2.20030917115817.024b48f8@localhost> <4.3.2.7.2.20030917165849.024ad9d0@localhost> <3F691CCF.7080002@cs.columbia.edu> In-Reply-To: <3F691CCF.7080002@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Re: Georpiv and actively lying Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.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, 19 Sep 2003 16:50:11 -0400 Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > James M. Polk wrote: > > >> Why should we design for permissible lying in an IETF effort? >> >> If your server or service is configured to give out misinformation, >> that's one thing - but to build it into the protocol as a requirement >> lacks technical justification at this point. A compliant protocol >> implementation shouldn't be required to be able to lie just to be >> compliant. A protocol that chooses not to be compliant can always >> misbehave. > > > No particular protocol effort is required to build a lying > implementation. In a presence model, I can have my 'alibi publisher' > publish any Munchhausen location information that I like and then select > to only propagate that information, rather than my GPS information. (For > example, using my earlier sphere proposal, designate myself in the > "mistress" sphere, which automatically only selects data from that > source, presumably without including the label.) This is functionally no > different than considering my calendar as an approximate location source. We have discussed this in the past as part of the facet header discussion in Aki's publication work, and I believe Aki also suggest it again somewhere in this thread. I believe it can work. It has the benefit that it can have lots of flexibility. If this transformation is done on the server, you need to specify particular transformations that are possible so that the user can set them as it desires. THe drawback is that it now requires two publishers for a single user just to support this capability. It also introduces the need to coordination between those publications, either by havign them co-resident, or through some other means. When co-resident, say, on a wireless handset, it may increase bandwidth usage by sending information which could have been algorithmically derived at the server. > > I would think that in most real implementation, the published location > information is actually an aggregate of various sources, as they all > have different strengths and applicability (GPS outdoor vs. 802.11 > indoors, etc.). The current model doesn't support this particularly > well, but I think it would be helpful to solve that, more generic, > problem and then treat lying as a special case that people can address > based on their needs. I think thats a great idea. In particular, the current diagram in the requirements document has only a single source of information. Is there a desire to change the model to allow multiple sources, and then introduce a composition concept in the location server? This is (for geopriv folks), exactly the presence model we have in simple. > > This has the great advantage that it is far more powerful than any > simple, static transformation could be. You can emulate a whole > schedule, with varying meetings, road trips and what have you, rather > than pretending to be in your office all day. > > To some extent, this functionality already exists with the 'class' > attribute in RPID. With appropriate selectors, as being discussed right > now, you can easily include just 'class=madeup-from-whole-cloth' elements. > > With this, there is no need to take a moral stand on whether the IETF > should endorse violation of truthfulness. This is another advantage of this approach, yes. The fundamental problem, however, has only been masked. Recall that, my original concern was that I didn't see how to apply Ted's "Venn diagram" style permission model to transformational policies. It seemed that you would need to assign a preference to them, so they would be applied in a speific order. It wasn't just set arithmetic. Now, what we have done here is basically take alternative versions of the presence/geolocation for a user, compose them together, and then allow the permissions to select which pieces go to various watchers. However, we are now faced with a case where the presence/geolocation object, after composition, contains conflicting information. Lets say it contains (now using simple terms) two tuples, one associated with my work sphere, and one associated with my home sphere. These tuples present conflicting information. The tuple for my home sphere says I am not available for calls on my cell, and the tuple on my work sphere says I am. What happens if someone is associated with both home and work spheres? They will now receive conflicting information. Is that the result we want? You might argue thats ok, since a user in both spheres should be allowed to see both perspectives. However, it reveals additional information - namely, that the user is explicitly given out conflicting information depending on the sphere - and this may not be desirable. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Sat Sep 20 12:14:45 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 MAA14929 for ; Sat, 20 Sep 2003 12:14:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0kNL-0004UF-KC for simple-archive@odin.ietf.org; Sat, 20 Sep 2003 12:14:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8KGENRN017246 for simple-archive@odin.ietf.org; Sat, 20 Sep 2003 12:14:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0kNL-0004U5-GX for simple-web-archive@optimus.ietf.org; Sat, 20 Sep 2003 12:14: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 MAA14868; Sat, 20 Sep 2003 12:14:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0kNE-00068F-00; Sat, 20 Sep 2003 12:14:16 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A0kN9-00068C-00; Sat, 20 Sep 2003 12:14:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0kMz-0004OJ-Tu; Sat, 20 Sep 2003 12:14:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0k2R-0002Ar-3R for simple@optimus.ietf.org; Sat, 20 Sep 2003 11:52: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 QAA21641 for ; Fri, 19 Sep 2003 16:51:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0SEQ-0001OD-00 for simple@ietf.org; Fri, 19 Sep 2003 16:51:58 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1A0SEE-0001MQ-00 for simple@ietf.org; Fri, 19 Sep 2003 16:51:47 -0400 Received: from dynamicsoft.com ([63.113.46.35]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h8JKoJUg017517; Fri, 19 Sep 2003 16:50:21 -0400 (EDT) Message-ID: <3F6B6C03.4070406@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne CC: "James M. Polk" , Tschofenig Hannes , John Morris , geopriv@mail.apps.ietf.org, Simple WG References: <4.3.2.7.2.20030917115817.024b48f8@localhost> <3F5BF2E6.4010107@cs.columbia.edu> <3F5BF2E6.4010107@cs.columbia.edu> <4.3.2.7.2.20030917115817.024b48f8@localhost> <4.3.2.7.2.20030917165849.024ad9d0@localhost> <3F691CCF.7080002@cs.columbia.edu> In-Reply-To: <3F691CCF.7080002@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Re: Georpiv and actively lying Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.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, 19 Sep 2003 16:50:11 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > James M. Polk wrote: > > >> Why should we design for permissible lying in an IETF effort? >> >> If your server or service is configured to give out misinformation, >> that's one thing - but to build it into the protocol as a requirement >> lacks technical justification at this point. A compliant protocol >> implementation shouldn't be required to be able to lie just to be >> compliant. A protocol that chooses not to be compliant can always >> misbehave. > > > No particular protocol effort is required to build a lying > implementation. In a presence model, I can have my 'alibi publisher' > publish any Munchhausen location information that I like and then select > to only propagate that information, rather than my GPS information. (For > example, using my earlier sphere proposal, designate myself in the > "mistress" sphere, which automatically only selects data from that > source, presumably without including the label.) This is functionally no > different than considering my calendar as an approximate location source. We have discussed this in the past as part of the facet header discussion in Aki's publication work, and I believe Aki also suggest it again somewhere in this thread. I believe it can work. It has the benefit that it can have lots of flexibility. If this transformation is done on the server, you need to specify particular transformations that are possible so that the user can set them as it desires. THe drawback is that it now requires two publishers for a single user just to support this capability. It also introduces the need to coordination between those publications, either by havign them co-resident, or through some other means. When co-resident, say, on a wireless handset, it may increase bandwidth usage by sending information which could have been algorithmically derived at the server. > > I would think that in most real implementation, the published location > information is actually an aggregate of various sources, as they all > have different strengths and applicability (GPS outdoor vs. 802.11 > indoors, etc.). The current model doesn't support this particularly > well, but I think it would be helpful to solve that, more generic, > problem and then treat lying as a special case that people can address > based on their needs. I think thats a great idea. In particular, the current diagram in the requirements document has only a single source of information. Is there a desire to change the model to allow multiple sources, and then introduce a composition concept in the location server? This is (for geopriv folks), exactly the presence model we have in simple. > > This has the great advantage that it is far more powerful than any > simple, static transformation could be. You can emulate a whole > schedule, with varying meetings, road trips and what have you, rather > than pretending to be in your office all day. > > To some extent, this functionality already exists with the 'class' > attribute in RPID. With appropriate selectors, as being discussed right > now, you can easily include just 'class=madeup-from-whole-cloth' elements. > > With this, there is no need to take a moral stand on whether the IETF > should endorse violation of truthfulness. This is another advantage of this approach, yes. The fundamental problem, however, has only been masked. Recall that, my original concern was that I didn't see how to apply Ted's "Venn diagram" style permission model to transformational policies. It seemed that you would need to assign a preference to them, so they would be applied in a speific order. It wasn't just set arithmetic. Now, what we have done here is basically take alternative versions of the presence/geolocation for a user, compose them together, and then allow the permissions to select which pieces go to various watchers. However, we are now faced with a case where the presence/geolocation object, after composition, contains conflicting information. Lets say it contains (now using simple terms) two tuples, one associated with my work sphere, and one associated with my home sphere. These tuples present conflicting information. The tuple for my home sphere says I am not available for calls on my cell, and the tuple on my work sphere says I am. What happens if someone is associated with both home and work spheres? They will now receive conflicting information. Is that the result we want? You might argue thats ok, since a user in both spheres should be allowed to see both perspectives. However, it reveals additional information - namely, that the user is explicitly given out conflicting information depending on the sphere - and this may not be desirable. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Sep 22 11:15:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19898; Mon, 22 Sep 2003 11:15:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1SP1-0000v1-4Y; Mon, 22 Sep 2003 11:15:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A013X-0002Oq-T9 for simple@optimus.ietf.org; Thu, 18 Sep 2003 11:50: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 LAA19060; Thu, 18 Sep 2003 11:50:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A013W-0000Cu-00; Thu, 18 Sep 2003 11:50:54 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1A013U-0000CI-00; Thu, 18 Sep 2003 11:50:54 -0400 Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h8IFoKfX005859; Thu, 18 Sep 2003 08:50:21 -0700 (PDT) Received: from jmpolk-w2k01.diablo.cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id IAA26718; Thu, 18 Sep 2003 08:50:19 -0700 (PDT) Message-Id: <4.3.2.7.2.20030918104755.0247ec38@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: From: "James M. Polk" Cc: geopriv@mail.apps.ietf.org, geopriv-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Simple] Fwd: Georpiv and actively lying Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.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, 18 Sep 2003 10:50:19 -0500 Forgive (simple) - I didn't include simple in my original response to Jonathan's email. Forgive (geopriv) - for sending a redundant message just trying to get everyone in sync >Date: Wed, 17 Sep 2003 17:29:25 -0500 >From: "James M. Polk" >Subject: Georpiv and actively lying >X-Sender: jmpolk@localhost >To: Jonathan Rosenberg >Cc: Henning Schulzrinne , > Tschofenig Hannes , > John Morris , geopriv@mail.apps.ietf.org, > geopriv-admin@ietf.org >X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 >List-Owner: >List-Subscribe: > >List-Unsubscribe: > >List-Id: >Spam-test: False ; -1.5 / 4.5 > >comments below > >** I've added the Geopriv list to this discussion because this thread has >whittled down to the one issue (lying) and it hasn't been commented on yet >there, and if a previous WG agreement is being called into question (which >is OK) - more people should see this discussion > >At 05:48 PM 9/17/2003 -0400, Jonathan Rosenberg wrote: > > >>James M. Polk wrote: >> >>>At 04:02 AM 9/17/2003 -0400, Jonathan Rosenberg wrote: >>> >>>>Henning, >>>> >>>>Also, how does this handle lying? I raised this question on the list as >>>>well. >>> >>>We had this discussion over two meetings last year and the consensus was >>>that in Geopriv, we shouldn't explicitly allow lying (as in, defining >>>how to do it - yet knowing we can't prevent it). That was resolved in >>>the POV that one can always give "less precise" location information >>>(replying that I'm in North America (only) when I know I'm at 123 Main >>>St., Dallas, TX, USA). >>>This is where permissions can be mapped to a template or table that >>>equates to the level of resolution of the target's location a particular >>>requester can learn. >> >>That works for geoloc, and can be mapped nicely into the model Henning is >>proposing. "resolution" can be considered an integer, such that the >>maximum resolution is the value that is communicated. >> >>It doesnt work for presence, and it won't work for geoloc later on when >>you do decide to lie. It seems lying is really crucial there too. THe >>classic "mistress" problem applies here - if your wife only sees "I'm in >>North America" as opposed to "I'm at the office in Parsippany, NJ", the >>mere fact that the information has been made less precise conveys that >>there is a problem. You need to be able to say "I'm in Parsippany" when >>you are really in Las Vegas. > >Why should we design for permissible lying in an IETF effort? > >If your server or service is configured to give out misinformation, that's >one thing - but to build it into the protocol as a requirement lacks >technical justification at this point. A compliant protocol implementation >shouldn't be required to be able to lie just to be compliant. A protocol >that chooses not to be compliant can always misbehave. > > >>As such, I am somewhat surprised this was dismissed. > >One argument for this dismissal was that if this were built into Geopriv, >the IETF would be actively, explicitly endorsing (through functionality of >the base protocol) the ability to lie. > >Doesn't seem like something to be proud of, when all is said and done > >>I understand its hard, but it seems crucial, no? > >There just hasn't been a good technical reason for allowing this into the >protocol as a requirement of compliance yet. What I believe you are >pointing to is a (debatable) societal reason for this > > >>-Jonathan R. >>-- >>Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >>Chief Technology Officer Parsippany, NJ 07054-2711 >>dynamicsoft >>jdrosen@dynamicsoft.com FAX: (973) 952-5050 >>http://www.jdrosen.net PHONE: (973) 952-5000 >>http://www.dynamicsoft.com > > >cheers, >James > > ******************* > Truth is not to be argued... it is to be presented > cheers, James ******************* Truth is not to be argued... it is to be presented _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Sep 22 11:16:05 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 LAA19925 for ; Mon, 22 Sep 2003 11:16:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1SPf-0000zq-Bi for simple-archive@odin.ietf.org; Mon, 22 Sep 2003 11:15:43 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8MFFh55003826 for simple-archive@odin.ietf.org; Mon, 22 Sep 2003 11:15:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1SPf-0000zd-8P for simple-web-archive@optimus.ietf.org; Mon, 22 Sep 2003 11:15:43 -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 LAA19898; Mon, 22 Sep 2003 11:15:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1SP1-0000v1-4Y; Mon, 22 Sep 2003 11:15:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A013X-0002Oq-T9 for simple@optimus.ietf.org; Thu, 18 Sep 2003 11:50: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 LAA19060; Thu, 18 Sep 2003 11:50:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A013W-0000Cu-00; Thu, 18 Sep 2003 11:50:54 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1A013U-0000CI-00; Thu, 18 Sep 2003 11:50:54 -0400 Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h8IFoKfX005859; Thu, 18 Sep 2003 08:50:21 -0700 (PDT) Received: from jmpolk-w2k01.diablo.cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id IAA26718; Thu, 18 Sep 2003 08:50:19 -0700 (PDT) Message-Id: <4.3.2.7.2.20030918104755.0247ec38@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: From: "James M. Polk" Cc: geopriv@mail.apps.ietf.org, geopriv-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Simple] Fwd: Georpiv and actively lying Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.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, 18 Sep 2003 10:50:19 -0500 Forgive (simple) - I didn't include simple in my original response to Jonathan's email. Forgive (geopriv) - for sending a redundant message just trying to get everyone in sync >Date: Wed, 17 Sep 2003 17:29:25 -0500 >From: "James M. Polk" >Subject: Georpiv and actively lying >X-Sender: jmpolk@localhost >To: Jonathan Rosenberg >Cc: Henning Schulzrinne , > Tschofenig Hannes , > John Morris , geopriv@mail.apps.ietf.org, > geopriv-admin@ietf.org >X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 >List-Owner: >List-Subscribe: > >List-Unsubscribe: > >List-Id: >Spam-test: False ; -1.5 / 4.5 > >comments below > >** I've added the Geopriv list to this discussion because this thread has >whittled down to the one issue (lying) and it hasn't been commented on yet >there, and if a previous WG agreement is being called into question (which >is OK) - more people should see this discussion > >At 05:48 PM 9/17/2003 -0400, Jonathan Rosenberg wrote: > > >>James M. Polk wrote: >> >>>At 04:02 AM 9/17/2003 -0400, Jonathan Rosenberg wrote: >>> >>>>Henning, >>>> >>>>Also, how does this handle lying? I raised this question on the list as >>>>well. >>> >>>We had this discussion over two meetings last year and the consensus was >>>that in Geopriv, we shouldn't explicitly allow lying (as in, defining >>>how to do it - yet knowing we can't prevent it). That was resolved in >>>the POV that one can always give "less precise" location information >>>(replying that I'm in North America (only) when I know I'm at 123 Main >>>St., Dallas, TX, USA). >>>This is where permissions can be mapped to a template or table that >>>equates to the level of resolution of the target's location a particular >>>requester can learn. >> >>That works for geoloc, and can be mapped nicely into the model Henning is >>proposing. "resolution" can be considered an integer, such that the >>maximum resolution is the value that is communicated. >> >>It doesnt work for presence, and it won't work for geoloc later on when >>you do decide to lie. It seems lying is really crucial there too. THe >>classic "mistress" problem applies here - if your wife only sees "I'm in >>North America" as opposed to "I'm at the office in Parsippany, NJ", the >>mere fact that the information has been made less precise conveys that >>there is a problem. You need to be able to say "I'm in Parsippany" when >>you are really in Las Vegas. > >Why should we design for permissible lying in an IETF effort? > >If your server or service is configured to give out misinformation, that's >one thing - but to build it into the protocol as a requirement lacks >technical justification at this point. A compliant protocol implementation >shouldn't be required to be able to lie just to be compliant. A protocol >that chooses not to be compliant can always misbehave. > > >>As such, I am somewhat surprised this was dismissed. > >One argument for this dismissal was that if this were built into Geopriv, >the IETF would be actively, explicitly endorsing (through functionality of >the base protocol) the ability to lie. > >Doesn't seem like something to be proud of, when all is said and done > >>I understand its hard, but it seems crucial, no? > >There just hasn't been a good technical reason for allowing this into the >protocol as a requirement of compliance yet. What I believe you are >pointing to is a (debatable) societal reason for this > > >>-Jonathan R. >>-- >>Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >>Chief Technology Officer Parsippany, NJ 07054-2711 >>dynamicsoft >>jdrosen@dynamicsoft.com FAX: (973) 952-5050 >>http://www.jdrosen.net PHONE: (973) 952-5000 >>http://www.dynamicsoft.com > > >cheers, >James > > ******************* > Truth is not to be argued... it is to be presented > cheers, James ******************* Truth is not to be argued... it is to be presented _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Sep 24 11:10: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 LAA21045; Wed, 24 Sep 2003 11:10:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2BHV-0005rO-00; Wed, 24 Sep 2003 11:10:17 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A2BHV-0005rJ-00; Wed, 24 Sep 2003 11:10:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2BHF-00018T-IE; Wed, 24 Sep 2003 11:10:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2BGk-00017u-Vc for simple@optimus.ietf.org; Wed, 24 Sep 2003 11:09: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 LAA20993 for ; Wed, 24 Sep 2003 11:09:21 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2BGi-0005qB-00 for simple@ietf.org; Wed, 24 Sep 2003 11:09:28 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1A2BGh-0005ph-00 for simple@ietf.org; Wed, 24 Sep 2003 11:09:27 -0400 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.6) with ESMTP id h8OF9Gt14641 for ; Wed, 24 Sep 2003 18:09:16 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 24 Sep 2003 18:09:16 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 24 Sep 2003 18:09:16 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 24 Sep 2003 18:09:16 +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] [Fwd: Re: NETCONF WG meeting minutes for IETF #57] Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797121@esebe019.ntc.nokia.com> Thread-Topic: [Simple] [Fwd: Re: NETCONF WG meeting minutes for IETF #57] Thread-Index: AcN+XaesMbGBd2SkTreVLTRE0VAH4ADNm4Uw To: Cc: , X-OriginalArrivalTime: 24 Sep 2003 15:09:16.0317 (UTC) FILETIME=[D22614D0:01C382AD] 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, 24 Sep 2003 18:09:15 +0300 Content-Transfer-Encoding: quoted-printable Lets try to simplify those xpath expressions a little more, see below > -----Original Message----- > From: ext Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Friday, September 19, 2003 6:25 AM > To: Khartabil Hisham (NMP-MSW/Helsinki) > Cc: simple@ietf.org; gk@ninebynine.org > Subject: Re: [Simple] [Fwd: Re: NETCONF WG meeting minutes=20 > for IETF #57] >=20 >=20 > hisham.khartabil@nokia.com wrote: > Thanks for the examples. The expressions are clearly far from=20 > obvious. I=20 > wonder if we can constrain the type of operations that we want to=20 > perform with presence tuples and express those operations=20 > more directly.=20 > The operations seem to be: >=20 > - create a presence document that consists of tuples where=20 > attribute X=20 > has value Y >=20 > - create a presence document that consists only of elements=20 > A, B, and C=20 > within >=20 > (and combinations thereof) >=20 > Are there others that make sense? >=20 > I can see that for filtering random event documents, the=20 > Xpath model may=20 > be unavoidable in its proposed generality, but there seems to=20 > be a large=20 > danger of having filter specs create invalid presence documents by=20 > providing access to 'raw' Xpath. Thus, I wonder if a simpler=20 > description=20 > that is restricted to presence documents (and is guaranteed not to=20 > create invalid presence documents) wouldn't be helpful in practice. >=20 >=20 > > Let me give you some examples: > >=20 > > - A watcher wishes to get the tuple that has a =20 > element with value "IM". The watcher has to either explicitly=20 > list all the elements that can appear in a tuple that it=20 > wants to receive, or alternatively, it tells the PA to=20 > deliver the tuple that has element IM with all=20 > the other elements that appear in that tuple. Its like using=20 > a key for selecting a whole tuple. The latter can be achieved=20 > using the following expression: > >=20 > > //*[rpid:class=3D"IM"]/descendant-or-self::* In the filter document, we can have something like this: //class=3D"IM" !!this is an simple xpath = expression, it returns true or false //class //class !!this says include tuple, = it does not include the root element. //class //class !! sibling also means = descendants of the siblings The combination of ancestor, descendant and sibling will give you the = whole tuple. > >=20 > >=20 > > This actually selects the whole tuple only. if the watcher=20 > wants to select the tuple and the root element ,=20 > you would do something like: > >=20 > > //*[rpid:class=3D"IM"]/descendant-or-self::* |=20 > //*[rpids:label=3D"im"]/ancestor::* > >=20 > >=20 > > - The following is an example of how you can ask a PA to=20 > include all tuples that are not of IM: > >=20 > > //*[rpid:class=3D"IM"]/following::* |=20 > //*[rpid:class=3D"IM"]/preceding::* //class=3D"IM" !!probably need a = better way to express a false condition than using the gate=3D"not" //class //class //class //class > >=20 > > - A watcher asks the PA to deliver a tuple that has a=20 > status of "closed", but it only wants the elements=20 > that are not > >=20 > > //*[basic=3D"closed"]/following-sibling::* |=20 > //*[basic=3D"closed"]/preceding-sibling::* |=20 > //*[basic=3D"closed"]/ancestor::tuple //basic=3D"closed" //class //basic !!this says include tuple = and presence elements //basic //basic //status I had to introduce here. You might be asking why do we have ancestor, descendant and sibling in = every filter example above? Can't we generalise all three in one? Well, = let me give you examples where I would only use one of them: //tuple[@id=3D"1234"] //tuple //tuple This chooses the tuple with id 1234 and its descendants Henning expressed the concern about producing an invalid xml document. I = think the PA should do the checking and either reject or terminate the = subscription. Regards, Hisham > >=20 > >=20 > > Again, this is if you don't want to indicate explicitly all=20 > the elements that you want. > >=20 > > /Hisham > >=20 > >>>- selecting descendents: descendent:: , descendent-or-self:: > >>>- selecting ancestors: ancestor:: , ancestor or self:: > >>>- selecting siblings: following-sibling:: , preceding-sibling:: > >>>- selecting following and preceding elements: following:: ,=20 > >> > >>preceding:: > >> > >> > >> > >> > >> >=20 >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Sep 24 11:10:43 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 LAA21134 for ; Wed, 24 Sep 2003 11:10:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2BHY-00019T-VC for simple-archive@odin.ietf.org; Wed, 24 Sep 2003 11:10:22 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8OFAK5H004423 for simple-archive@odin.ietf.org; Wed, 24 Sep 2003 11:10:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2BHY-00019G-RR for simple-web-archive@optimus.ietf.org; Wed, 24 Sep 2003 11:10: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 LAA21045; Wed, 24 Sep 2003 11:10:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2BHV-0005rO-00; Wed, 24 Sep 2003 11:10:17 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A2BHV-0005rJ-00; Wed, 24 Sep 2003 11:10:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2BHF-00018T-IE; Wed, 24 Sep 2003 11:10:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2BGk-00017u-Vc for simple@optimus.ietf.org; Wed, 24 Sep 2003 11:09: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 LAA20993 for ; Wed, 24 Sep 2003 11:09:21 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2BGi-0005qB-00 for simple@ietf.org; Wed, 24 Sep 2003 11:09:28 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1A2BGh-0005ph-00 for simple@ietf.org; Wed, 24 Sep 2003 11:09:27 -0400 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.6) with ESMTP id h8OF9Gt14641 for ; Wed, 24 Sep 2003 18:09:16 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 24 Sep 2003 18:09:16 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 24 Sep 2003 18:09:16 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 24 Sep 2003 18:09:16 +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] [Fwd: Re: NETCONF WG meeting minutes for IETF #57] Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797121@esebe019.ntc.nokia.com> Thread-Topic: [Simple] [Fwd: Re: NETCONF WG meeting minutes for IETF #57] Thread-Index: AcN+XaesMbGBd2SkTreVLTRE0VAH4ADNm4Uw To: Cc: , X-OriginalArrivalTime: 24 Sep 2003 15:09:16.0317 (UTC) FILETIME=[D22614D0:01C382AD] 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, 24 Sep 2003 18:09:15 +0300 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Lets try to simplify those xpath expressions a little more, see below > -----Original Message----- > From: ext Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Friday, September 19, 2003 6:25 AM > To: Khartabil Hisham (NMP-MSW/Helsinki) > Cc: simple@ietf.org; gk@ninebynine.org > Subject: Re: [Simple] [Fwd: Re: NETCONF WG meeting minutes=20 > for IETF #57] >=20 >=20 > hisham.khartabil@nokia.com wrote: > Thanks for the examples. The expressions are clearly far from=20 > obvious. I=20 > wonder if we can constrain the type of operations that we want to=20 > perform with presence tuples and express those operations=20 > more directly.=20 > The operations seem to be: >=20 > - create a presence document that consists of tuples where=20 > attribute X=20 > has value Y >=20 > - create a presence document that consists only of elements=20 > A, B, and C=20 > within >=20 > (and combinations thereof) >=20 > Are there others that make sense? >=20 > I can see that for filtering random event documents, the=20 > Xpath model may=20 > be unavoidable in its proposed generality, but there seems to=20 > be a large=20 > danger of having filter specs create invalid presence documents by=20 > providing access to 'raw' Xpath. Thus, I wonder if a simpler=20 > description=20 > that is restricted to presence documents (and is guaranteed not to=20 > create invalid presence documents) wouldn't be helpful in practice. >=20 >=20 > > Let me give you some examples: > >=20 > > - A watcher wishes to get the tuple that has a =20 > element with value "IM". The watcher has to either explicitly=20 > list all the elements that can appear in a tuple that it=20 > wants to receive, or alternatively, it tells the PA to=20 > deliver the tuple that has element IM with all=20 > the other elements that appear in that tuple. Its like using=20 > a key for selecting a whole tuple. The latter can be achieved=20 > using the following expression: > >=20 > > //*[rpid:class=3D"IM"]/descendant-or-self::* In the filter document, we can have something like this: //class=3D"IM" !!this is an simple xpath = expression, it returns true or false //class //class !!this says include tuple, = it does not include the root element. //class //class !! sibling also means = descendants of the siblings The combination of ancestor, descendant and sibling will give you the = whole tuple. > >=20 > >=20 > > This actually selects the whole tuple only. if the watcher=20 > wants to select the tuple and the root element ,=20 > you would do something like: > >=20 > > //*[rpid:class=3D"IM"]/descendant-or-self::* |=20 > //*[rpids:label=3D"im"]/ancestor::* > >=20 > >=20 > > - The following is an example of how you can ask a PA to=20 > include all tuples that are not of IM: > >=20 > > //*[rpid:class=3D"IM"]/following::* |=20 > //*[rpid:class=3D"IM"]/preceding::* //class=3D"IM" !!probably need a = better way to express a false condition than using the gate=3D"not" //class //class //class //class > >=20 > > - A watcher asks the PA to deliver a tuple that has a=20 > status of "closed", but it only wants the elements=20 > that are not > >=20 > > //*[basic=3D"closed"]/following-sibling::* |=20 > //*[basic=3D"closed"]/preceding-sibling::* |=20 > //*[basic=3D"closed"]/ancestor::tuple //basic=3D"closed" //class //basic !!this says include tuple = and presence elements //basic //basic //status I had to introduce here. You might be asking why do we have ancestor, descendant and sibling in = every filter example above? Can't we generalise all three in one? Well, = let me give you examples where I would only use one of them: //tuple[@id=3D"1234"] //tuple //tuple This chooses the tuple with id 1234 and its descendants Henning expressed the concern about producing an invalid xml document. I = think the PA should do the checking and either reject or terminate the = subscription. Regards, Hisham > >=20 > >=20 > > Again, this is if you don't want to indicate explicitly all=20 > the elements that you want. > >=20 > > /Hisham > >=20 > >>>- selecting descendents: descendent:: , descendent-or-self:: > >>>- selecting ancestors: ancestor:: , ancestor or self:: > >>>- selecting siblings: following-sibling:: , preceding-sibling:: > >>>- selecting following and preceding elements: following:: ,=20 > >> > >>preceding:: > >> > >> > >> > >> > >> >=20 >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Sep 24 13:40:59 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28069; Wed, 24 Sep 2003 13:40:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2DdQ-00009U-00; Wed, 24 Sep 2003 13:41:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A2DdQ-00009R-00; Wed, 24 Sep 2003 13:41:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2DdO-0004GG-Fh; Wed, 24 Sep 2003 13:41:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1zb0-0000KY-9I for simple@optimus.ietf.org; Tue, 23 Sep 2003 22:41: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 WAA19942; Tue, 23 Sep 2003 22:41:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1zaw-00036J-00; Tue, 23 Sep 2003 22:41:34 -0400 Received: from zak.ecotroph.net ([216.93.164.123]) by ietf-mx with esmtp (Exim 4.12) id 1A1zaw-00036G-00; Tue, 23 Sep 2003 22:41:34 -0400 Received: from ecotroph.net (64-83-8-178-nova-dsl.cavtel.net [::ffff:64.83.8.178]) (AUTH: LOGIN anewton, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by zak.ecotroph.net with esmtp; Tue, 23 Sep 2003 22:41:33 -0400 Message-ID: <3F71023D.6070001@ecotroph.net> From: Andrew Newton User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne CC: Carl Reed , John Pagonis , "James M. Polk" , Jonathan Rosenberg , Tschofenig Hannes , John Morris , geopriv@mail.apps.ietf.org, bmanning , simple@ietf.org, geopriv@ietf.org References: <4.3.2.7.2.20030917165849.024ad9d0@localhost> <4.3.2.7.2.20030917115817.024b48f8@localhost> <3F5BF2E6.4010107@cs.columbia.edu> <3F5BF2E6.4010107@cs.columbia.edu> <4.3.2.7.2.20030917115817.024b48f8@localhost> <4.3.2.7.2.20030917165849.024ad9d0@localhost> <4.3.2.7.2.20030919184340.02401cc8@localhost> <3F6BA86A.1010405@cs.columbia.edu> <3F6ECE57.2070901@symbian.com> <012b01c3811f$2dcbb500$ded6fea9@CarlReed> <3F6F41C5.50202@cs.columbia.edu> In-Reply-To: <3F6F41C5.50202@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] NEW GEOPRIV MAILING LIST ( was Re: Georpiv and actively lying ) Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.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, 23 Sep 2003 22:32:29 -0400 Content-Transfer-Encoding: 7bit Everyone, This was announced before, but it could probably need repeating: GEOPRIV has a new mailing list. It is geopriv@ietf.org. Please discontinue the use of the old list, geopriv@mail.apps.ietf.org. -andy _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Sep 24 13:41: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 NAA28093 for ; Wed, 24 Sep 2003 13:41: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 1A2DdU-0004H4-4t for simple-archive@odin.ietf.org; Wed, 24 Sep 2003 13:41:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8OHf8GK016424 for simple-archive@odin.ietf.org; Wed, 24 Sep 2003 13:41:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2DdT-0004Gp-W8 for simple-web-archive@optimus.ietf.org; Wed, 24 Sep 2003 13:41: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 NAA28069; Wed, 24 Sep 2003 13:40:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2DdQ-00009U-00; Wed, 24 Sep 2003 13:41:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A2DdQ-00009R-00; Wed, 24 Sep 2003 13:41:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2DdO-0004GG-Fh; Wed, 24 Sep 2003 13:41:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1zb0-0000KY-9I for simple@optimus.ietf.org; Tue, 23 Sep 2003 22:41: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 WAA19942; Tue, 23 Sep 2003 22:41:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1zaw-00036J-00; Tue, 23 Sep 2003 22:41:34 -0400 Received: from zak.ecotroph.net ([216.93.164.123]) by ietf-mx with esmtp (Exim 4.12) id 1A1zaw-00036G-00; Tue, 23 Sep 2003 22:41:34 -0400 Received: from ecotroph.net (64-83-8-178-nova-dsl.cavtel.net [::ffff:64.83.8.178]) (AUTH: LOGIN anewton, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by zak.ecotroph.net with esmtp; Tue, 23 Sep 2003 22:41:33 -0400 Message-ID: <3F71023D.6070001@ecotroph.net> From: Andrew Newton User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne CC: Carl Reed , John Pagonis , "James M. Polk" , Jonathan Rosenberg , Tschofenig Hannes , John Morris , geopriv@mail.apps.ietf.org, bmanning , simple@ietf.org, geopriv@ietf.org References: <4.3.2.7.2.20030917165849.024ad9d0@localhost> <4.3.2.7.2.20030917115817.024b48f8@localhost> <3F5BF2E6.4010107@cs.columbia.edu> <3F5BF2E6.4010107@cs.columbia.edu> <4.3.2.7.2.20030917115817.024b48f8@localhost> <4.3.2.7.2.20030917165849.024ad9d0@localhost> <4.3.2.7.2.20030919184340.02401cc8@localhost> <3F6BA86A.1010405@cs.columbia.edu> <3F6ECE57.2070901@symbian.com> <012b01c3811f$2dcbb500$ded6fea9@CarlReed> <3F6F41C5.50202@cs.columbia.edu> In-Reply-To: <3F6F41C5.50202@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] NEW GEOPRIV MAILING LIST ( was Re: Georpiv and actively lying ) Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.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, 23 Sep 2003 22:32:29 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Everyone, This was announced before, but it could probably need repeating: GEOPRIV has a new mailing list. It is geopriv@ietf.org. Please discontinue the use of the old list, geopriv@mail.apps.ietf.org. -andy _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Sep 25 11:04: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 LAA29254; Thu, 25 Sep 2003 11:04:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2Xfy-0007LV-00; Thu, 25 Sep 2003 11:05:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A2Xfy-0007LS-00; Thu, 25 Sep 2003 11:05:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2Xfx-0006KC-EY; Thu, 25 Sep 2003 11:05:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2Xfs-0006Jr-En for simple@optimus.ietf.org; Thu, 25 Sep 2003 11:04: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 LAA29245 for ; Thu, 25 Sep 2003 11:04:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2Xfp-0007LJ-00 for simple@ietf.org; Thu, 25 Sep 2003 11:04:53 -0400 Received: from [65.220.123.3] (helo=mail.pingtel.com) by ietf-mx with esmtp (Exim 4.12) id 1A2Xfp-0007LG-00 for simple@ietf.org; Thu, 25 Sep 2003 11:04:53 -0400 Received: from kathmandu.pingtel.com (kathmandu.pingtel.com [10.1.1.252]) by mail.pingtel.com (8.11.6/8.11.6) with ESMTP id h8PF4pL18630; Thu, 25 Sep 2003 11:04:51 -0400 To: simple@ietf.org Cc: Jonathan Rosenberg Organization: Pingtel Corp. http://www.pingtel.com/ From: Scott Lawrence Message-ID: User-Agent: Gnus/5.1001 (Gnus v5.10.1) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Simple] draft-ietf-simple-xcap-00 comments Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.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, 25 Sep 2003 11:04:51 -0400 I've started studying the XCAP proposals, and have a first couple of suggestions for the framwork draft: ==== In section 4, the Application Usage ID id defined using one of two namespaces, an implicit IETF namespace that controls all names not prefixed by 'vnd.' and the vendor namespace for all names that do have that prefix. I would suggest a single uniform naming convention, already familiar to any Java programmer: invert the order in a DNS domain name controlled by the entity defining the usage. All IETF-defined names would be prefixed by 'org.ietf' (and registered with IANA); any Pingtel-defined name would be prefixed 'com.pingtel'. I think that the intent in section 5 is that the Node-Selector be passed in the HTTP query string component of the URI (though it is not phrased that way). If so, the syntax from the draft: XCAP-URI = Document-URI ["?" Node-Selector] is redundant, since a URI may include a query string (incidentally, there is a bug in RFC 2616 with respect to this, which may be where this came from - see the errata list [1]). This syntax actually allows http://example.com/foo?query?node-selector, which I'm sure was not your intent. I think that a more appropriate mechanism for specifying a component would be to pass it as a fragment identifier (defined in RFC 2396 [URI Generic Syntax], section 4.1), which is appended to (but not a part of) the URI separated by the '#' character. This construction is a URI reference, so the suggested syntax would be: XCAP-URI-reference = Document-URI ["#" Node-Selector] this is exactly what fragment identifiers are for. In addition to the syntactic problem above, using a query string may interact poorly in some HTTP server implementations when the method is not GET. On the node-selector itself, did you consider using XPointer [2] rather than XPath? I'm still studying these myself, but on first look, XPointer (whose purpose is to provide an xml fragment identifier syntax) looks sufficient for XCAP and much simpler. ==== The draft suggests using the HTTP conditional request mechanisms based on date-time stamps, which were inherited from HTTP/1.0 by HTTP/1.1. I would suggest that using the HTTP/1.1 Etag mechanism would be a better choice. A conditional fetch uses an If-None-Match header, holding the Etag value returned with the cached version of the resource; a conditional PUT, POST, or DELETE uses a If-Match header holding the Etag value. There is some text in 2616 on the use of 'weak' etag values - in effect, this can be safely ignored (just don't use the explicit weak etag syntax and it all becomes a no-op). From the client side, Etags are used in the same way date-times _should_ be used - as opaque strings, but because the server is free to construct Etag values in any way that preserves the match/no-match semantics, rather than being limited to a particular time-value syntax, Etags allow the server freedom to do smarter things internally (the etag value could be a unique database key, or a document hash, for example). [1] HTTP Specification Errata http://purl.org/NET/http-errata -- Scott Lawrence Pingtel Corp. deprecated addresses: _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Sep 25 11:05:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29273 for ; Thu, 25 Sep 2003 11:05:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2Xg1-0006Ks-G2 for simple-archive@odin.ietf.org; Thu, 25 Sep 2003 11:05:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8PF55j7024353 for simple-archive@odin.ietf.org; Thu, 25 Sep 2003 11:05:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2Xg1-0006Ki-CI for simple-web-archive@optimus.ietf.org; Thu, 25 Sep 2003 11:05: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 LAA29254; Thu, 25 Sep 2003 11:04:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2Xfy-0007LV-00; Thu, 25 Sep 2003 11:05:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A2Xfy-0007LS-00; Thu, 25 Sep 2003 11:05:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2Xfx-0006KC-EY; Thu, 25 Sep 2003 11:05:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2Xfs-0006Jr-En for simple@optimus.ietf.org; Thu, 25 Sep 2003 11:04: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 LAA29245 for ; Thu, 25 Sep 2003 11:04:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2Xfp-0007LJ-00 for simple@ietf.org; Thu, 25 Sep 2003 11:04:53 -0400 Received: from [65.220.123.3] (helo=mail.pingtel.com) by ietf-mx with esmtp (Exim 4.12) id 1A2Xfp-0007LG-00 for simple@ietf.org; Thu, 25 Sep 2003 11:04:53 -0400 Received: from kathmandu.pingtel.com (kathmandu.pingtel.com [10.1.1.252]) by mail.pingtel.com (8.11.6/8.11.6) with ESMTP id h8PF4pL18630; Thu, 25 Sep 2003 11:04:51 -0400 To: simple@ietf.org Cc: Jonathan Rosenberg Organization: Pingtel Corp. http://www.pingtel.com/ From: Scott Lawrence Message-ID: User-Agent: Gnus/5.1001 (Gnus v5.10.1) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Simple] draft-ietf-simple-xcap-00 comments Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.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, 25 Sep 2003 11:04:51 -0400 I've started studying the XCAP proposals, and have a first couple of suggestions for the framwork draft: ==== In section 4, the Application Usage ID id defined using one of two namespaces, an implicit IETF namespace that controls all names not prefixed by 'vnd.' and the vendor namespace for all names that do have that prefix. I would suggest a single uniform naming convention, already familiar to any Java programmer: invert the order in a DNS domain name controlled by the entity defining the usage. All IETF-defined names would be prefixed by 'org.ietf' (and registered with IANA); any Pingtel-defined name would be prefixed 'com.pingtel'. I think that the intent in section 5 is that the Node-Selector be passed in the HTTP query string component of the URI (though it is not phrased that way). If so, the syntax from the draft: XCAP-URI = Document-URI ["?" Node-Selector] is redundant, since a URI may include a query string (incidentally, there is a bug in RFC 2616 with respect to this, which may be where this came from - see the errata list [1]). This syntax actually allows http://example.com/foo?query?node-selector, which I'm sure was not your intent. I think that a more appropriate mechanism for specifying a component would be to pass it as a fragment identifier (defined in RFC 2396 [URI Generic Syntax], section 4.1), which is appended to (but not a part of) the URI separated by the '#' character. This construction is a URI reference, so the suggested syntax would be: XCAP-URI-reference = Document-URI ["#" Node-Selector] this is exactly what fragment identifiers are for. In addition to the syntactic problem above, using a query string may interact poorly in some HTTP server implementations when the method is not GET. On the node-selector itself, did you consider using XPointer [2] rather than XPath? I'm still studying these myself, but on first look, XPointer (whose purpose is to provide an xml fragment identifier syntax) looks sufficient for XCAP and much simpler. ==== The draft suggests using the HTTP conditional request mechanisms based on date-time stamps, which were inherited from HTTP/1.0 by HTTP/1.1. I would suggest that using the HTTP/1.1 Etag mechanism would be a better choice. A conditional fetch uses an If-None-Match header, holding the Etag value returned with the cached version of the resource; a conditional PUT, POST, or DELETE uses a If-Match header holding the Etag value. There is some text in 2616 on the use of 'weak' etag values - in effect, this can be safely ignored (just don't use the explicit weak etag syntax and it all becomes a no-op). From the client side, Etags are used in the same way date-times _should_ be used - as opaque strings, but because the server is free to construct Etag values in any way that preserves the match/no-match semantics, rather than being limited to a particular time-value syntax, Etags allow the server freedom to do smarter things internally (the etag value could be a unique database key, or a document hash, for example). [1] HTTP Specification Errata http://purl.org/NET/http-errata -- Scott Lawrence Pingtel Corp. deprecated addresses: _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Sep 26 00:40:01 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07686; Fri, 26 Sep 2003 00:40:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2kOl-0003QZ-00; Fri, 26 Sep 2003 00:40:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A2kOl-0003QU-00; Fri, 26 Sep 2003 00:40:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2kOh-00046u-86; Fri, 26 Sep 2003 00:40:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2kOL-00046H-AV for simple@optimus.ietf.org; Fri, 26 Sep 2003 00:39: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 AAA07665 for ; Fri, 26 Sep 2003 00:39:32 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2kOI-0003Q4-00 for simple@ietf.org; Fri, 26 Sep 2003 00:39:38 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1A2kOH-0003Q1-00 for simple@ietf.org; Fri, 26 Sep 2003 00:39:38 -0400 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.6) with ESMTP id h8Q4dct29552 for ; Fri, 26 Sep 2003 07:39:38 +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, 26 Sep 2003 07:39:37 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 26 Sep 2003 07:39:37 +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 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797128@esebe019.ntc.nokia.com> Thread-Topic: Who can modify an XCAP usage XML document Thread-Index: AcOD6DAsobNIcRbITV+u6yrxsxnYAw== To: X-OriginalArrivalTime: 26 Sep 2003 04:39:37.0927 (UTC) FILETIME=[314CBD70:01C383E8] Content-Transfer-Encoding: quoted-printable Subject: [Simple] Who can modify an XCAP usage XML document Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.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, 26 Sep 2003 07:39:37 +0300 Content-Transfer-Encoding: quoted-printable Hi, In the current XCAP proposal (and I assume in the revised version to be = available soon), it is assumed that the creator of an XML usage document = is the sole member of a virtual access list. I.e. It is only the creator = who can modify the XML document. I believe this is a limitation and some changes need to be made to such = a problem. 2 solutions are possible 1. Require that each XCAP usage document define an ACL type of list. One = way of mandating this is by requiring XML documents in an XCAP usage to = have an element that carries URIs of resources that have read/write = access of a document. The syntax of that element can be left up to the = usage document. For example, a usage document can define something like: sip:*@nokia.com 2. Somehow generalise this in the base XCAP document using a HTTP header = or something in an multipart body. Regards, Hisham _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Sep 26 00:40: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 AAA07710 for ; Fri, 26 Sep 2003 00:40: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 1A2kOp-00048B-RW for simple-archive@odin.ietf.org; Fri, 26 Sep 2003 00:40:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8Q4eBBW015875 for simple-archive@odin.ietf.org; Fri, 26 Sep 2003 00: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 1A2kOp-00047u-5n for simple-web-archive@optimus.ietf.org; Fri, 26 Sep 2003 00: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 AAA07686; Fri, 26 Sep 2003 00:40:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2kOl-0003QZ-00; Fri, 26 Sep 2003 00:40:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A2kOl-0003QU-00; Fri, 26 Sep 2003 00:40:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2kOh-00046u-86; Fri, 26 Sep 2003 00:40:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2kOL-00046H-AV for simple@optimus.ietf.org; Fri, 26 Sep 2003 00:39: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 AAA07665 for ; Fri, 26 Sep 2003 00:39:32 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2kOI-0003Q4-00 for simple@ietf.org; Fri, 26 Sep 2003 00:39:38 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1A2kOH-0003Q1-00 for simple@ietf.org; Fri, 26 Sep 2003 00:39:38 -0400 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.6) with ESMTP id h8Q4dct29552 for ; Fri, 26 Sep 2003 07:39:38 +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, 26 Sep 2003 07:39:37 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 26 Sep 2003 07:39:37 +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 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797128@esebe019.ntc.nokia.com> Thread-Topic: Who can modify an XCAP usage XML document Thread-Index: AcOD6DAsobNIcRbITV+u6yrxsxnYAw== To: X-OriginalArrivalTime: 26 Sep 2003 04:39:37.0927 (UTC) FILETIME=[314CBD70:01C383E8] Content-Transfer-Encoding: quoted-printable Subject: [Simple] Who can modify an XCAP usage XML document Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.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, 26 Sep 2003 07:39:37 +0300 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi, In the current XCAP proposal (and I assume in the revised version to be = available soon), it is assumed that the creator of an XML usage document = is the sole member of a virtual access list. I.e. It is only the creator = who can modify the XML document. I believe this is a limitation and some changes need to be made to such = a problem. 2 solutions are possible 1. Require that each XCAP usage document define an ACL type of list. One = way of mandating this is by requiring XML documents in an XCAP usage to = have an element that carries URIs of resources that have read/write = access of a document. The syntax of that element can be left up to the = usage document. For example, a usage document can define something like: sip:*@nokia.com 2. Somehow generalise this in the base XCAP document using a HTTP header = or something in an multipart body. Regards, Hisham _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Sep 29 10:57:59 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19538; Mon, 29 Sep 2003 10:57:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A3zTS-0006wt-00; Mon, 29 Sep 2003 10:58:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A3zTS-0006wo-00; Mon, 29 Sep 2003 10:58:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3zTM-00070U-Nd; Mon, 29 Sep 2003 10:58:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3zTA-00070D-E8 for simple@optimus.ietf.org; Mon, 29 Sep 2003 10:57:48 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19499; Mon, 29 Sep 2003 10:57:38 -0400 (EDT) Message-Id: <200309291457.KAA19499@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-partial-notify-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, 29 Sep 2003 10:57:38 -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 : Partial Notification of Presence Information Author(s) : M. Lonnfors et al. Filename : draft-ietf-simple-partial-notify-00.txt Pages : 18 Date : 2003-9-29 A Presence service can have constraints for delivering presence information to devices with low data processing capabilities, small display, and limited battery power. Other limitations can be caused by the interface between the terminal and the network, i.e. over radio links with high latency and low bandwidth. This memo presents a solution that aids in reducing the impact of those constrains and to increase efficiency, by introducing a mechanism called partial notification. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-partial-notify-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-partial-notify-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-partial-notify-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-9-29110941.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-partial-notify-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-partial-notify-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-9-29110941.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Sep 29 10:58:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19581 for ; Mon, 29 Sep 2003 10:58:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3zTW-00073i-4l for simple-archive@odin.ietf.org; Mon, 29 Sep 2003 10:58:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8TEwABS027128 for simple-archive@odin.ietf.org; Mon, 29 Sep 2003 10:58:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3zTW-00072V-1H for simple-web-archive@optimus.ietf.org; Mon, 29 Sep 2003 10:58: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 KAA19538; Mon, 29 Sep 2003 10:57:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A3zTS-0006wt-00; Mon, 29 Sep 2003 10:58:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A3zTS-0006wo-00; Mon, 29 Sep 2003 10:58:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3zTM-00070U-Nd; Mon, 29 Sep 2003 10:58:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3zTA-00070D-E8 for simple@optimus.ietf.org; Mon, 29 Sep 2003 10:57:48 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19499; Mon, 29 Sep 2003 10:57:38 -0400 (EDT) Message-Id: <200309291457.KAA19499@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-partial-notify-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, 29 Sep 2003 10:57:38 -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 : Partial Notification of Presence Information Author(s) : M. Lonnfors et al. Filename : draft-ietf-simple-partial-notify-00.txt Pages : 18 Date : 2003-9-29 A Presence service can have constraints for delivering presence information to devices with low data processing capabilities, small display, and limited battery power. Other limitations can be caused by the interface between the terminal and the network, i.e. over radio links with high latency and low bandwidth. This memo presents a solution that aids in reducing the impact of those constrains and to increase efficiency, by introducing a mechanism called partial notification. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-partial-notify-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-partial-notify-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-partial-notify-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-9-29110941.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-partial-notify-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-partial-notify-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-9-29110941.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple