|
|
@@ -24,16 +24,16 @@ data. From the SER's point of view are interesting:
|
|
|
<para>Definition of authorization documents and theirs usage is specified in <xref
|
|
|
linkend="pres_draft_common_auth"/> and especially for presence purposes in <xref
|
|
|
linkend="pres_draft_auth"/>. Both documents are quite common and in SER's
|
|
|
-presence modules implemented only partialy.
|
|
|
-</para>
|
|
|
+presence modules implemented only partialy. For more information about XCAP
|
|
|
+authorization see details in <xref linkend="pa.xcap"/>.</para>
|
|
|
</section> <!-- XCAP authorization -->
|
|
|
|
|
|
<section><title>Buddy lists</title>
|
|
|
<para>XCAP server may be used for storing lists of users too. These lists may be
|
|
|
used for presence subscriptions - subscription to such list means subscription
|
|
|
-to all users at once. This reduces number of created subscriptions and may
|
|
|
+to all users on it at once. This reduces number of created subscriptions and may
|
|
|
reduce data transfers between server and client too; but presence documents for
|
|
|
-lists of users may be very big.</para>
|
|
|
+lists of users may be very big and thus require TCP connection.</para>
|
|
|
|
|
|
<para>There may be not only lists for individual users with their contacts but
|
|
|
there may be other sort of lists representing some <quote>logical
|
|
|
@@ -48,7 +48,8 @@ there. Such customer may simply watch presence state of
|
|
|
linkend="pres_draft_rls"/> and their usage with SIP in <xref
|
|
|
linkend="pres_draft_rls_sip"/>. These lists are partialy implemented in <link
|
|
|
linkend="pres_rls">RLS module</link>.
|
|
|
-</para>
|
|
|
+For more information about resource lists see details in <xref
|
|
|
+linkend="rls.xcap"/>.</para>
|
|
|
</section> <!-- buddy lists -->
|
|
|
|
|
|
<section><title>Manipulation with XCAP documents</title>
|
|
|
@@ -62,118 +63,6 @@ not much client software supporting it.
|
|
|
|
|
|
</section> <!-- XCAP introduction -->
|
|
|
|
|
|
-<section><title>XCAP authorization and SER</title>
|
|
|
-
|
|
|
-<section><title>Authorization document URI</title>
|
|
|
-<para>Authorization documents are read for presentities according to their presentity
|
|
|
-URIs. Presentity URI is AOR of SUBSCRIBE request. Resulting URI will be:</para>
|
|
|
-<para>
|
|
|
-<filename><xcap-root>/pres-rules/users/<username>/presence-rules.xml</filename>
|
|
|
-where <parameter><xcap-root></parameter> is set in configuration and
|
|
|
-<parameter><username></parameter> is username from presentity URI.
|
|
|
-</para>
|
|
|
-
|
|
|
-<example><title>authorization document uri</title>
|
|
|
-<para>For example for presentity <literal>sip:[email protected]</literal> and
|
|
|
-<parameter>xcap-root</parameter> <literal>http://localhost/xcap-root</literal> will be
|
|
|
-the URI for the authorization document
|
|
|
-<filename>http://localhost/xcap-root/pres-rules/users/smith/presence-rules.xml</filename>
|
|
|
-</para>
|
|
|
-</example>
|
|
|
-
|
|
|
-</section>
|
|
|
-
|
|
|
-<section><title>Disadvantages</title>
|
|
|
-<para>One of the worst disadvantages of XCAP authorization is slowness of XCAP
|
|
|
-queries compared to - for example - data stored in local database. This is the
|
|
|
-reason for caching XCAP queries and responses, but there is a problem - how to
|
|
|
-detect changes in data stored on XCAP server. One of possible solutions is to
|
|
|
-implement client for <quote>XCAP change notifications</quote> described in <xref
|
|
|
-linkend="pres_draft_xcap_change"/> and <xref linkend="pres_draft_xcap_profiles"/>
|
|
|
-(planned in future versions).</para>
|
|
|
-</section>
|
|
|
-
|
|
|
-<section><title>Standard incompliances</title>
|
|
|
-<para>SER's XCAP authorization support is not finished yet, there are some standard
|
|
|
-incompliances now:
|
|
|
-<itemizedlist>
|
|
|
- <listitem><para>ignored sphere</para></listitem>
|
|
|
- <listitem><para>ignored date and time conditions</para></listitem>
|
|
|
- <listitem><para>ignored transformations</para></listitem>
|
|
|
-</itemizedlist>
|
|
|
-</para>
|
|
|
-</section>
|
|
|
-
|
|
|
-</section> <!-- XCAP authorization in SER -->
|
|
|
-
|
|
|
-<section><title>Resource lists and SER</title>
|
|
|
-<para>There is a problem of resource lists usage: The draft <xref
|
|
|
-linkend="pres_draft_rls"/> describes that a Resource Lists Server operates with
|
|
|
-<quote>rls-services</quote> document - NOT directly with the user's buddy list,
|
|
|
-but tested client software doesn't store <quote>rls-services</quote> documents,
|
|
|
-only <quote>resource list documents</quote> (buddy lists).</para>
|
|
|
-
|
|
|
-<para>It is possible now to change mode of processing subscriptions (see <link
|
|
|
-linkend="rls.parameters">RLS module parameters</link> so it works directly with
|
|
|
-resource list documents published by client instead of rls-services document.
|
|
|
-</para>
|
|
|
-
|
|
|
-<section><title>RLS document URI</title>
|
|
|
-<para>The construction of rls-services document URI is described in <xref
|
|
|
-linkend="pres_draft_rls"/>. Only in short: the AOR from SIP SUBSCRIBE request is
|
|
|
-combined with XCAP root given in configuration like this:</para>
|
|
|
-<para>
|
|
|
-<filename><xcap-root>/rls-services/global/index/~~/rls-services/service[@uri=%22<AOR>%22]</filename>.
|
|
|
-</para>
|
|
|
-<para><emphasis>
|
|
|
-This URI doesn't not specify namespaces as mentioned in definition, but this is
|
|
|
-due to problems with XCAP server used for tests (problems querying
|
|
|
-parts of documents with namespaces).</emphasis></para>
|
|
|
-<example><title>rls-services uri example</title>
|
|
|
-<itemizedlist>
|
|
|
- <listitem><para><varname>xcap-root</varname> = <literal>http://localhost/xcap-root</literal></para></listitem>
|
|
|
- <listitem><para><varname>AOR</varname> = <literal>sip:[email protected]</literal></para></listitem>
|
|
|
-</itemizedlist>
|
|
|
-<para>Resulting rls-services document describing the list will be get from URI:
|
|
|
-<filename>http://localhost/xcap-root/rls-services/global/index/~~/rls-services/service[@uri=%22<[email protected]>%22]</filename>,
|
|
|
-which means the <literal>service</literal> element with
|
|
|
-<parameter>uri</parameter> parameter value
|
|
|
-<literal>[email protected]</literal> stored in rls-services document named
|
|
|
-index.
|
|
|
-</para></example>
|
|
|
-
|
|
|
-<section><title>Disadvantages</title>
|
|
|
-<para>Working with URIs presented in this section have one big disadvantage - it
|
|
|
-needs full XCAP server which is able to work with partial documents and able to
|
|
|
-process XPointer expressions in XCAP queries.</para>
|
|
|
-
|
|
|
-<para>Due to unavailability of free XCAP servers is there a possibility to
|
|
|
-use SER's RLS server in mode of <emphasis>reduced XCAP server needs</emphasis>
|
|
|
-(see <link linkend="rls.parameters">RLS module parameters</link>). If operating
|
|
|
-in this mode, RLS requests full rls-service document from uri
|
|
|
-<filename><xcap-root>/rls-services/global/index</filename>, inspects it
|
|
|
-and finds requested resource list according to URI and AOR by itself.
|
|
|
-(Only if possible! There can't be links
|
|
|
-to partial documents in rls-services document.)
|
|
|
-</para>
|
|
|
-</section> <!-- disadvantages -->
|
|
|
-
|
|
|
-</section>
|
|
|
-
|
|
|
-<section><title>Standard incompliances</title>
|
|
|
-<para>SER's resource lists support is not finished yet, there are some standard
|
|
|
-incompliances now:
|
|
|
-<itemizedlist>
|
|
|
- <listitem><para>uri canonicalization not done yet according to definition</para></listitem>
|
|
|
- <listitem><para>no subscriptions made to external servers (subscriptions
|
|
|
- only within one SER instance)</para></listitem>
|
|
|
- <listitem><para>full status documents only</para></listitem>
|
|
|
-</itemizedlist>
|
|
|
-</para>
|
|
|
-</section>
|
|
|
-
|
|
|
-</section> <!-- resource lists and SER -->
|
|
|
-
|
|
|
<section id="xcap.examples"><title>XCAP examples</title>
|
|
|
<note><para>XCAP documents examples published there doesn't use correct XML
|
|
|
namespaces due to problems with XCAP server used for tests (probles querying
|
Vaclav Kubart