Subject: [Simple] Last Call: draft-ietf-simple-presence-rules (Presence Authorization Rules) to Proposed Standard

From: The IESG <[email-masked]>
Date: Fri, 02 Mar 2007 12:28:36 -0500

The IESG has received a request from the SIP for Instant Messaging and 
Presence Leveraging Extensions WG (simple) to consider the following
document:

- 'Presence Authorization Rules '
   <draft-ietf-simple-presence-rules-09.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
[email-masked] mailing lists by 2007-03-16. Exceptionally, 
comments may be sent to [email-masked] instead. In either case, please 
retain the beginning of the Subject line to allow automated sorting.

Note that the document includes a Normative Reference to RFC 3325 which
is Informational. This is a Downward Reference as per RFC 3967.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-simple-presence-rules-09.txt

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=11777&rfc_flag=0

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

---

From: "Vrancken, Johnny" <[email-masked]>
Date: Tue, 6 Mar 2007 14:40:39 +0100

Dear Jonathan,

I'd appreciate your opinion on the following issues:

Comment #1:
For completeness, it is recommended to add a statement on how to deal with the <note> child element of a <presence> document as defined in RFC 3863.
You may e.g. state that this <note> always is included (if available), or that it is never included unless a proper permission (e.g. a boolean valued <provide-presence-note>) is introduced for controlling the permission of this specific presence item. The <provide-note> permission as defined in section  3.3.2.13 only covers the <note> element within a <tuple>, <person> or <device>. 

Comment #2:
Extract from http://www1.ietf.org/mail-archive/web/simple/current/msg07059.html
===BEGIN===  
> §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.
===END===
It would be nice to have a more compact way of expressing that access is granted to all presence attributes in currently defined and new data components. Data components (like <tuple>, <person> and <device>) are defined as a grouped collection of presence attributes. In the current solution, you always have to enumerate the coarse grained permission controls for the data components (i.e. <provide-persons>, <provide-services>, <provide-devices>). In order to deal with the introduction of new (yet unknown) data components, one could define 2 new coarse grained permissions
*	<provide-all-data-components>, empty typed, as a short-hand for referencing all data components, and
*	<provide-unknown-data-component>, unknownBooleanPermission typed, to allow to include proprietary or new data components other than <tuple>, <person> and <device>. 
The syntax and the semantics of these new coarse grained permissions are straightforward.
At least the description of the <provide-all-attributes> fine grained permission in section 3.3.2.15 should slightly be adapted, so this fine grained permission also can be applied to data components other than <tuple>, <person> and <device>.

The most compact form of granting access of all presence attributes to all watchers then would look like (assuming that all presence attributes are grouped into data components):
 <rule id="GrantAll" >
   <actions> <sub-handling>allow</sub-handling> </actions>
   <transformations>
     <provide-all-data-components/>
     <provide-all-attributes/>
   </transformations>
 </rule>

This extension -if acknowledged as a meaningful extension- could be described in a new document but due to its basic nature, I'd prefer to include it in the simple presence rules document.

Kind regards,
Johnny Vrancken