Subject: RE: [Simple] [Fwd: Re: NETCONF WG meeting minutes for IETF #57]

From: [email-masked]
Date: Mon, 1 Sep 2003 12:17:48 +0300

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:[email-masked]]
> Sent: Friday, August 29, 2003 5:36 PM
> To: Simple WG; [email-masked]
> 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
> [email-masked]                     FAX:   (973) 952-5050
> http://www.jdrosen.net                      PHONE: (973) 952-5000
> http://www.dynamicsoft.com
> 

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 02 Sep 2003 01:37:57 -0400

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.

[email-masked] wrote:

> 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:[email-masked]] Sent: Friday, August 29, 2003
>> 5:36 PM To: Simple WG; [email-masked] 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 [email-masked]
>> FAX:   (973) 952-5050 http://www.jdrosen.net
>> PHONE: (973) 952-5000 http://www.dynamicsoft.com
>> 
> 
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 02 Sep 2003 01:37:57 -0400

Thanks,
Jonathan R.

---

From: "Joel M. Halpern" <[email-masked]>
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.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 02 Sep 2003 10:48:39 -0400

Yours,
Joel

---

From: Sean Olson <[email-masked]>
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 <[email-masked]>
wrote:
> > I don't buy it. Why would you define an XML schema
> who's syntax
> > does not match the semantics?
> > 

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

---

From: Sean Olson <[email-masked]>
Date: Tue, 2 Sep 2003 10:21:28 -0700 (PDT)

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 03 Sep 2003 10:22:43 -0400

Henning Schulzrinne wrote:

> 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.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 03 Sep 2003 10:22:43 -0400

-Jonathan R.

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 03 Sep 2003 14:19:55 -0400

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.

> possible, automatically places such information into the note in some way.
> 
> 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.

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 03 Sep 2003 14:19:55 -0400

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 07 Sep 2003 00:53:11 -0400

> be prepared to reveal the type of place they are in, but not the actual 

Fair enough, thought I don't think I would call this "syntactic".

> 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".

> 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.

> 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.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 07 Sep 2003 00:53:11 -0400

-Jonathan R.

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 07 Sep 2003 10:02:58 -0400

> 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.

> 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.)

> (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?

> 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.

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 07 Sep 2003 10:02:58 -0400

Are there others?