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

From: [email-masked]
Date: Tue, 2 Mar 2004 03:14:32 +0200

Hi,

Does this really have to be an either or choice? Wouldn't it be possible to keep the syntactic approach as a baseline, since only this way the system would be future-proof without the need to upgrade presence agent to understand the semantics of each possible presence document extension that will be defined. I think this is important property, since we want anyway to provide presence about applications that are proprietary by nature, and thus their presence info would be proprietary as well. In this case it would not be feasible to upgrade presence agents to understand the semantics of such proprietary extensions. Still it would be important to be able to provide permissions to such information in standardized way.

On the other hand I think it would be OK to define semantic rules for the standard presence extensions, such as RPID, CIPID, or prescaps. And in the future any new extension could define its own semantic rules.

Would there be something that breaks if we allow both of these models at the same time? If we have to select one I would have to chooce the syntactic approach as a trade-off.

Markus

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> ext Jonathan Rosenberg
> Sent: 26 February, 2004 00:08
> To: Simple WG
> Subject: [Simple] Models for representing presence rules
> 
> 
> 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-rul
> es-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
> 

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