Subject: [Simple] Models for representing presence rules

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 25 Feb 2004 17:07:53 -0500

I wanted to make the group aware of an important implicit decision that 
has been made in the way presence authorization rules have been 
structured in:

http://www.ietf.org/internet-drafts/draft-rosenberg-simple-rules-00.txt

The model used in this document is that the transformation rules are 
syntactic in nature. That is, they define rules based on XML constructs, 
such as adding and removing elements, adding and removing namespaces, 
and so on. These kinds of rules have the benefit that they can be used 
for new presence extensions that havent even been defined yet. For 
example, if we defined a new extension that included contact information 
within a namespace urn:ietf:params:xml:ns:pidf:cipid, a presentity could 
define rules for giving out this information using the show-namespace 
construct in rosenberg-simple-rules, even though the cipid extension did 
not exist when simple-rules was defined.

The drawback is that the impact of a set of rules on a document could be 
non-obvious and have the wrong effect. Hisham has already pointed out 
some cases where, for example, if the same element appeared in several 
places in a document, the show-element transformation might have 
unintended consequences. It also complicates interactions between 
transformations that can affect the same data - for example, 
show-namespace and show-element can affect the same element in a 
presence document, and thus there is an interaction between them.

A different approach is a more semantic approach, which is actually what 
is done in the geopriv equivalent:

http://www.ietf.org/internet-drafts/draft-ietf-geopriv-policy-01.txt

For us, the analagous thing would be to define rules for each specific 
part of the presence document. For example, for the note, we could 
define three levels of privacy - to not send any notes, to send notes 
for tuples only, notes for the whole document, or all:

<note>tuples-only</note>

We would also need to define elements for various rpid pieces. For example:

<placetype>home-only</placetype>
<icon>black-and-white</icon>

would specify that the placetype element is included only if its value 
is home, and the icon that is sent (defined in cipid) should be 
converted to black and white first.

The semantic approach allows us to carefully construct our privacy 
policies so that there is no feature interaction (as we have the 
syntactic approach today); it would also allow us to specify 
transformations that are non-trivially represented via XML constructs, 
for example converting an image to black and white.

To be honest, I'm on the fence on this. I have gradually been coming 
over to the "semantic" side of the argument, because it allows us to be 
more concise. The cost is that new extensions to pidf would have to 
define their own authorization policies as well.

This is a major decision point we need to make. Please comment.

Thanks,
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: Paul Kyzivat <[email-masked]>
Date: Wed, 25 Feb 2004 17:36:41 -0500

> This is a major decision point we need to make. Please comment.

My first inclination would be for a semantically based approach, though 
it certainly has the drawbacks you mention.

There are other consequences to the syntactic approach as well, beyond 
what you mention: because it can have awkward interactions and 
consequences, there will be a tendency to constrain the syntax of pidf 
and extensions in order to minimize the consequences. But that will make 
creation of extensions difficult, and will likely contort the result.

At least with the semantic approach, it should be possible to spread the 
work. Each new extension should include its own set of rule notation.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 25 Feb 2004 17:36:41 -0500

Paul

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 25 Feb 2004 19:19:27 -0500

This should come as now surprise, but I'm in favor of semantic 
transformations. Beyond the reasons you mention, there is the one of 
representing and editing rules. With a syntactic model, it is possible 
for a user interface to translate a human-understandable policy into a 
show-element, but the reverse transformation is somewhat more difficult 
to make without exposing the user to fairly meaningless information that 
is often in a foreign language (unless your native language happens to 
be English).

It also seems easier to accidentally create an invalid PIDF extension 
document if a schema has a minOccurs > 0 in some nested element.

Clearly, restrictions on attributes will be difficult to express in the 
syntactic model, since we (correctly, I think) didn't want to go down 
the XPath. (As an example, would we want to restrict access to the 
since/until information in RPID, which is expressed as attributes?)

 From a practical perspective, all in-progress PIDF extensions (CIPID, 
RPID, etc.) could already provide filtering information, so 
backward-compatibility doesn't seem much of a problem.

Henning

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 25 Feb 2004 19:19:27 -0500

Henning