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

From: "Vrancken, Johnny" <[email-masked]>
Date: Mon, 13 Nov 2006 10:38:58 +0100

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")

§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.
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.

§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>

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

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>

===========
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 ....

Kind regards,
Johnny

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