[OpenSIPS-Users] [OpenSIPS-Devel] New auids supported by OpenXCAP

Iñaki Baz Castillo ibc at aliax.net
Tue Dec 1 19:23:37 CET 2009


El Martes, 1 de Diciembre de 2009, Adrian Georgescu escribió:
> Hello,
> 
> In the trunk version of OpenXCAP there is support for some new
> applications
> useful for user agents the implement SIMPLE presence.
> 
> - XCAP directory (auid = xcap-directory, org.openmobilealliance.xcap-
> directory).
> Lists the documents stored in the XCAP server for a given user.
> 
> - icon (auid = icon, oma_status-icon). Manipulate user icon for a
> given user
> and provide icon download capability from HTTP clients.

Just a question. IETF doesn't specify the xcap-directory application, neither 
the icon application. Instead, both are OMA's specifications and their auid 
are "org.openmobilealliance.xcap-directory" and "oma_status-icon", and not 
"xcap-directory" and "icon".

Then, why do you allow these unknown auids? It just can create 
interoperability with real OMA clients. For example, imagine that a pure OMA 
client fetches its directory and gets from OpenXCAP:

<xcap-directory xmlns="urn:oma:xml:xdm:xcap-directory">
  <folder auid="icon">
    <entry 
uri="https://xcap.lalala.org/icon/users/sip:alice@lalala.org/my_icon.png"
     etag="513365397112009" />
  </floder>
</xcap-directory>

This pure OMA client would fail when inspecting the "folder" with auid="icon" 
as "icon" it's not recognized by him as a OMA application (however it 
WORKSFORBLINK).

So I don't understand why to invent two new auids when there are already 
defined auids for them. These applications are created by OMA so IMHO their 
auids must be respected rather than allowing other names just because OMA is 
the devil "and we prefer to hide its name".

If not, I suggest to rename these auids to "ag-xcap-directory" and "ag-icon" 
to avoid confusion.

A more relaxed approach could be allow "xcap-directory" and "icon" auids (even 
if they are not required at all) but use the OMA's auids in the xcap-directory 
documents.

However I strongly suggest to remove the not required auids.


> - Dialog rules (auid = dialog-rules). Dialog Rules application is a
> custom
> application modeled after Presence rules that uses authorization
> policies,
> to specify when dialog information can be given to which watchers.

As I already said, it would be more than great if a new propietary XCAP 
application came at least with open specifications.

Regards.


-- 
Iñaki Baz Castillo <ibc at aliax.net>



More information about the Users mailing list