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

From: [email-masked]
Date: Thu, 4 Sep 2003 15:17:45 +0300

> -----Original Message-----
> From: ext Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Wednesday, September 03, 2003 5:23 PM
> To: Henning Schulzrinne
> Cc: Khartabil Hisham (NMP/Helsinki); [email-masked]; 
> [email-masked]
> Subject: Re: [Simple] [Fwd: Re: NETCONF WG meeting minutes 
> for IETF #57]
> 
> 
> 
> 
> 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.

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 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 
> information, and 
> in order to "maximize compatibility" with the broadest set of 
> watchers 
> possible ...

/Hisham

> 
> 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
> [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: Wed, 17 Sep 2003 04:10:22 -0400

One comment inline:

[email-masked] 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.

---

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

One comment inline:

-Jonathan R.