<?xml version='1.0' encoding='UTF-8'?>

<!DOCTYPE section PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" 

<title>SER presence basics</title>

<para>Presence is one of quite important components of SER. It allows users to
watch presence state of other users, process lists of them and manipulate one's 
own presence state.</para>

<para>Configuration data can be stored on a XCAP server <xref
linkend="pres_draft_xcap"/> by user's client software and processed by SER
automaticaly. This may be useful for lists of watched users (resource lists) and
for authorization rules.</para>

<para>There is a few of modules which serve as parts of "presence".
	<listitem><para><link linkend="pa">PA</link> This module acts as a presence
	server - its main function is processing of subscriptions to presence
	state and processing presence state publications.</para></listitem>
	<listitem><para><link linkend="pres_rls">RLS</link> Resource list server - this
	module processes subscriptions to lists of resources.</para></listitem>
	<listitem><para><emphasis>RPA </emphasis>Reg events server. Will be used by
	PA instead of direct callbacks into usrloc. Will be added

<para>All <quote>presence</quote> modules share common code stored in SER
libraries. Their interface is described in standalone documents.

<para>Modules can store their status (working data) into database. This data is
automatically reloaded on startup, so it is possible to restart SER and
clients don't note it. Established SIP dialogs are stored in database too.</para>
<para>Details about database storage are described for each module separately in
module documentation.

<para>Authorization is one of important things in presence services. The server
must take care about authorization rules defined by user about whom and
whom not allow access to user's presence status. More about common authorization
rules may be found in <xref linkend="pres_draft_common_auth"/> and 
<xref linkend="pres_draft_auth"/>.</para>

<!-- TODO: types of authorization common for all presence modules -->

<para>Only XCAP storage of authorization rules is supported at this moment. It is 
<emphasis>not fully implemented</emphasis> now - only basic rule conditions, no sphere 
and time conditions. Transformations defined in <xref linkend="pres_draft_auth"/> are 
May be, that in the
future will be possible other variants like webdav or storing
authorization rules in SER's own database.</para>

<!-- TODO: examples of authorization documents with description of processing ! -->

<para>Authorization settings may vary from module to module. It is in detail 
described in documentation of individual modules.</para>