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