view release on metacpan or  search on metacpan

docs/rfcs/rfc5025.html  view on Meta::CPAN

   the <provide-unknown-attribute> element can change should the
   presence server be upgraded.  For example, consider a server that,
   prior to the upgrade, had an authorization document that used
   <provide-unknown-attribute> with a value of TRUE for some attribute,
   say foo.  This attribute was from a namespace and schema unknown to
   the server, and so the attribute was provided to watchers.  However,
   after upgrade, the server is now aware of a new namespace and schema
   for a permission that grants access to the foo attribute.  Now, the
   <provide-unknown-attribute> permission for the foo attribute will be
   ignored, resulting in a removal of those elements from presence
   documents sent to watchers.  The system remains privacy safe, but
   behavior might not be as expected.  Developers of systems that allow
   clients to set policies are advised to check the capabilities of the
   server (using the mechanism described in <a href="#section-8">Section 8</a>) before uploading
   a new authorization document, to make sure that the behavior will be
   as expected.

<span class="h5"><h5><a name="section-3.3.2.15">3.3.2.15</a>.  Provide All Attributes</h5></span>

   This permission grants access to all presence attributes in all of
   the person, device, and tuple elements that are present in the
   document (the ones present in the document are determined by the
   &lt;provide-persons&gt;, &lt;provide-devices&gt;, and &lt;provide-services&gt;
   permissions).  It is effectively a macro that expands into a set of
   provide-activities, provide-class, provide-deviceID, provide-mood,
   provide-place-is, provide-place-type, provide-privacy, provide-
   relationship, provide-sphere, provide-status-icon, provide-time-
   offset, provide-user-input, provide-note, and provide-unknown-
   attribute permissions such that each presence attribute in the
   document has a permission for it.  This implies that, so long as an
   entire person, service, or device occurrence is provided, every
   single presence attribute, including ones not known to the server
   and/or defined in future presence document extensions, is granted to
   the watcher.







<span class="grey">Rosenberg                   Standards Track                    [Page 16]</span>
</pre><pre class="newpage"><a name="page-17" id="page-17" href="#page-17" class="invisible"> </a>
<span class="grey"><a href="http://tools.ietf.org/html/rfc5025">RFC 5025</a>                 Presence Authorization            December 2007</span>


<span class="h2"><h2><a name="section-4">4</a>.  When to Apply the Authorization Policies</h2></span>

   This specification does not mandate at what point in the processing
   of presence data the privacy filtering aspects of the authorization
   policy are applied.  However, they must be applied such that the
   final presence document sent to the watcher is compliant to the
   privacy policy described in the authorization documents that apply to
   the user (there can be more than one; the rules for combining them
   are described in [<a href="#ref-8" title="&quot;Common Policy: A Document Format for Expressing Privacy Preferences&quot;">8</a>]).  More concretely, if the presence document
   sent to a watcher is D, and the privacy filtering operation applied
   do a presence document x is F(x), then D MUST have the property that
   D = F(D).  In other words, further applications of the privacy
   filtering operation would not result in any further changes of the
   presence document, making further application of the filtering
   operation a no-op.  A corollary of this is that F(F(D)) = D for all
   D.

   The subscription processing aspects of the document get applied by
   the server when it decides to accept or reject the subscription.

<span class="h2"><h2><a name="section-5">5</a>.  Implementation Requirements</h2></span>

   The rules defined by the document in this specification form a
   "contract" of sorts between a client that creates this document and
   the server that executes the policies it contains.  Consequently,
   presence servers implementing this specification MUST support all of
   the conditions, actions, and transformations defined in this
   specification.  If servers were to implement a subset of these,
   clients would need a mechanism to discover which subset is supported.
   No such mechanism is defined.

   It is RECOMMENDED that clients support all of the actions,
   transformations, and conditions defined in this specification.  If a
   client supports a subset, it is possible that a user might manipulate
   their authorization rules from a different client, supporting a
   different subset, and store those results on the server.  When the
   user goes back to the first client and views their presence
   authorization rules there, the client may not be able to properly
   render or manipulate the document retrieved from the server, since it
   may contain conditions, actions, or transformations not supported by
   the client.  The only reason that this normative requirement is not a
   MUST is that there are valid conditions in which a user manipulates
   their presence authorization rules from a single client, in which
   case this problem does not occur.

   This specification makes no normative recommendations on the
   mechanism used to transport presence authorization documents from




<span class="grey">Rosenberg                   Standards Track                    [Page 17]</span>
</pre><pre class="newpage"><a name="page-18" id="page-18" href="#page-18" class="invisible"> </a>
<span class="grey"><a href="http://tools.ietf.org/html/rfc5025">RFC 5025</a>                 Presence Authorization            December 2007</span>


   clients to their servers.  Although <a href="#section-9">Section 9</a> defines how to utilize
   XCAP, XCAP is not normatively required by this specification.

<span class="h2"><h2><a name="section-6">6</a>.  Example Document</h2></span>

   The following presence authorization document specifies permissions
   for the user "user@example.com".  The watcher is allowed to access
   presence information (the 'allow' value for &lt;sub-handling&gt;).  They
   will be granted access to the presence data of all services whose
   contact URI schemes are sip and mailto.  Person information is also
   provided.  However, since there is no &lt;provide-devices&gt;, no device
   information will be given to the watcher.  Within the service and
   person information provided to the watcher, the &lt;activities&gt; element
   will be shown, as will the &lt;user-input&gt; element.  However, any
   "idle-threshold" and "since" attributes in the &lt;user-input&gt; element
   will be removed.  Finally, the presence attribute &lt;foo&gt; will be shown
   to the watcher.  Any other presence attributes will be removed.

   &lt;?xml version="1.0" encoding="UTF-8"?&gt;