Subject: [Simple] Re: Comments on presence-rules-08

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 27 Feb 2007 09:45:59 -0500

I just noticed this; my apologies. Responses inline.

Vrancken, Johnny wrote:

> Dear Jonathan,
> 
> Here are a few  comments / questions on 
> draft-ietf-simple-presence-rules-08.txt:
> 
> §3.2.1 Subscription Handling, page 8
> In order to align with the terminology used in RFC 3857 / Figure 1 and 
> RFC 3858, the following changes are recommended:
> for block: subscriptions are placed in the "terminated" state 
> (authorization policy / decision ="reject")
> for polite-block & allow: subscriptions are placed in the "active" state 
> (authorization policy / decision ="accept")

fixed.

> 
> §3.2.1 Subscription Handling, page 9, last paragraph:
> "If the sub-handling permission changes value to "polite-block" or 
> "allow", this causes an "approved" event to be generated into the state 
> machine for all affected subscriptions. "
> 
> This is not completely true. If e.g. the sub-handling permission changes 
> from "allow" to "polite-block", or from "polite-block" to "allow", the 
> subscription is and remains in the "active" state and no event is generated.

fixed.

> 
> So if the sub-handling permission changes value to "polite-block" or 
> "allow", the processing depends on the state of the affected 
> subscriptions. Only if the subscription is in the "pending" state, the 
> subscription state changes and a NOTIFY is sent. There is no change in 
> state if the subscription is in the active, waiting or terminated state.

fixed.

> 
> §3.3 Transformations
> Considering the statements in §3.3.1 and §3.3.2, you need both a fine 
> gained access permission (§3.3.2) and a corresponding coarse grained 
> access permission (§3.3.1)to grant access to presence attributes.
> 
> So the most compact form of granting access of all presence attributes 
> to all watchers is the following rule:
> <rule id="GrantAll" >
>   <actions> <sub-handling>allow</sub-handling> </actions>
>   <transformations>
>     <provide-persons> <all-persons/> </provide-persons>
>     <provide-services> <all-services/> </provide-services>
>     <provide-devices> <all-devices/> </provide-devices>
>     <provide-all-attributes/>
>   </transformations>
> </rule>

correct.

> 
> Question: is it a correct statement that a "false" valued boolean 
> permission serves no purpose unless combined with a 
> <provide-all-attributes/> permission ?

Right. But if <provide-all-attributes/> is there, any other boolean 
permission has no further affect since you've basically already granted 
permission.

> 
> I.e. the following rule without a <provide-persons> or 
> <provide-all-attributes> statement doesn't grant anything.
> <rule id="GrantAllPersonsExceptMood" >
>   <actions> <sub-handling>allow</sub-handling> </actions>
>   <transformations>
>     <provide-persons> <all-persons/> </provide-persons>
>     <provide-all-attributes/>
>     <provide-mood> false </provide-mood>
>   </transformations>
> </rule>

You are correct, but I wouldn't say it this way. I'd say that if there 
is no permission granting access to <person> elements, and if there is 
no permission granting access to the mood (whether it is by 
<provide-mood>true</provide-mood> or <proviate-all-attributes/>), then 
mood will not appear.

> 
> Question: is the following transformation in a single matching rule
> <transformations>
>     <provide-persons> <all-persons/> </provide-persons>
>     <provide-status-icon> true </provide-status-icon>
>  </transformations>
> 
> semantically equivalent to the following 2 transformations in 2 matching 
> rules, or are these 2 transformations meaningless ?
> 
> In Rule 1: <transformations>
>     <provide-persons> <all-persons/> </provide-persons>
> </transformations>
> In Rule 2: <transformations>
>     <provide-status-icon> true </provide-status-icon>
> </transformations>

Assuming both rules match, yes.

> 
> ===========
> NITS:
> Page 8: … Strictly speaking, it is not necessary to every RULESET TO 
> include an explicit block action
> Page 9: … and the value of sub-handling that APPLIES to that 
> subscription is "CONFIRM", ... ("pending" to be replaced by "confirm" )
> 
> Page 17: … that used <provide-unknown-attribute> VALUED "TRUE" for some 
> attribute, say foo.
> Page  18: … will be granted access to THE PRESENCE DATA OF all services 
> whose contact URI ….

fixed.

Thanks,
Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

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