Subject: Re: [Simple] Models for representing presence rules

From: "Niemi Aki (Nokia-M/Espoo)" <[email-masked]>
Date: Tue, 02 Mar 2004 07:25:56 +0200

Hi Jonathan,

After the discussion in SIMPLE yesterday, I thought about this a bit more.

If the semantic model requires that the PA understands all of the 
presence information in order to be able to authorize it, this could 
really be a show-stopper for presence.

Presence information by definition needs to be extensible to support new 
innovative applications, and well-implemented UAs will probably have a 
presence API that allows other applications (perhaps downloadable as 
plug-ins) to publish their specific information.

The server side (the composer and PA) can't possibly keep up in this 
race, which will have a definite negative impact on innovation. This is 
analogous to requiring web servers to understand all of the content they 
offer.

I agree privacy issues come into play here, but I'd say privacy issues 
need to be considered on a per extension basis. For example, it isn't 
necessary for the PA to block delivery of unknown information, if that 
information contains no privacy-sensitive information in the first place.

So while the semantic model does sound appealing, it at least needs to 
be combined with some mechanism that allows for innovation in presence 
without requiring an update to the PA. Is it possible to have this kind 
of a hybrid model?

Cheers,
Aki

ext 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
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: "Niemi Aki (Nokia-M/Espoo)" <[email-masked]>
Date: Tue, 02 Mar 2004 07:25:56 +0200

Hi Jonathan,

Cheers,
Aki