Re: [Simple] Models for representing presence rules

[Henning Schulzrinne <hgs at cs.columbia.edu>]

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

Jonathan Rosenberg wrote:

> 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.
_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple