view release on metacpan or  search on metacpan

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

   First, a presence document has a concrete meaning independent of how
   it is transported or where it is found.  The semantics of a document
   are the same regardless of whether a document is published by a
   presence user agent to its compositor, or whether it is distributed
   from a presence agent to watchers.  There are no required or implied
   behaviors for a recipient of a document.  Rather, there are well-
   defined semantics for the document itself, and a recipient of a
   document can take whatever actions it chooses based on those
   semantics.

   A corollary of this property is that presence systems are infinitely
   composeable.  A presence user agent can publish a document to its
   presence server.  That presence server can compose it with other
   documents, and place the result in a notification to a watcher.  That
   watcher can actually be another presence agent, combining that
   document with others it has received, and placing those results in
   yet another notify.

   Yet another corollary of this property is that implied behaviors in
   reaction to the document cannot ever be assumed.  For example, just
   because a service indicates that it supports audio does not mean that
   a watcher will offer audio in a communications attempt to that
   service.  If doing so is necessary to reach the service, this must be
   indicated explicitly through reach information.

   It is also important to understand that the role of the presence
   document is to help a user make a choice amongst a set of services,
   and furthermore, to know ahead of time with as much certainty as
   possible whether a communications attempt will succeed or fail.

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

   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,