Subject: [Simple] Presence authorization conclusion?

From: [email-masked]
Date: Tue, 9 Sep 2003 13:17:37 +0300

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 
> filters and authorization policies to point at rpids and pidf 
> elements by element name, no matter where that element appears in 
> 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. 

Henning Schulzrinne wrote:
> Another approach [...] 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.

It seems that this is similar to what can be done with the "compound rules" in the current presence authorization XCAP proposal. 

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

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 <sphere> element for RPID to act as a switch between different sets of rules.    

Please comment.

Regards,
	Markus

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 09 Sep 2003 10:27:40 -0400

[email-masked] 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 <sphere> element for RPID to act as a switch
> between different sets of rules.
> 
> Please comment.
> 
> Regards, Markus

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 09 Sep 2003 10:27:40 -0400

(1) *placetype

doesn't cut it.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 17 Sep 2003 03:02:41 -0400

Henning Schulzrinne 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".
> 
> (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:rpid-tuple:placetype

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:

<context xmlns:rpid="urn:ietf:params:xml:ns:pidf:status:rpid-status">
   <xpath-expr expr="/presence/tuple/status/rpid:relationship"/>
</context>

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
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 17 Sep 2003 03:02:41 -0400

-Jonathan R.