[Devel] presence: xcap_xml table

Anca-Maria Vamanu anca at voice-system.ro
Mon Apr 30 10:06:20 CEST 2007


Hello,

As we did not tested with an xcap server these reqirements were not 
obvious.
I will analize them and make the changes soon.

Thanks,

Anca

Mircea Amarascu wrote:

> Hello,
>
> I have a few questions and proposals regarding the way XCAP documents 
> are stored and managed in
> the openser.xcap_xml table:
>
> 1. As stated in the XCAP specification 
> (http://www.jdrosen.net/papers/draft-ietf-simple-xcap-12.txt), every
> XCAP document must have an Etag associated to it, that uniquely 
> defines its state at a given time. So
> we should add a new column in the xcap_xml table to handle this, e.g. 
> `etag` varchar(64) NOT NULL
>
> Also, it would probably be more intuitive if the `xcap` column from 
> the forementioned table would be
> named `document`.
>
> 2. Regarding the way the Presence Server handles XCAP applications, I 
> see there's a mapping from the
> application ID to a numerical ID: 'pres-rules'->1, 'resource-lists'->2.
>   I understand that the Presence Server was tested with the eyeBeam 
> softphone. I'm using eyeBeam version
> 1.5.14 for the Mac OS, and I see it manages documents under the 
> org.openmobilealliance.pres-rules and
> resource-lists applications, e.g. GET 
> /xcap-root/org.openmobilealliance.pres-rules/users/joe/presrules.
>   The org.openmobilealliance.pres-rules application is defined here: 
> http://www.openmobilealliance.org/release_program/docs/PresenceSIMPLE/V1_0_1-20061128-A/OMA-TS-Presence_SIMPLE_XDM-V1_0_1-20061128-A.pdf 
>
>
> it is not an IETF standard, however it is a derivation of the 
> pres-rules application, and I think it is treated as
> such by the OpenSER. But technically it is a different application, so 
> it should have a different numeric ID
> in the xcap_xml table. What could be done about this? Maybe the 
> Presence Server could handle both
> pres-rules and org.openmobilealliance.pres-rules as pres-rules, but 
> under a different ID?
>
> 3. I think we should define an ID for the rls-services (probably the 
> next available, 3 or 4), even if this application
> is not currently handled by OpenSER.
>
> _______________________________________________
> Devel mailing list
> Devel at openser.org
> http://openser.org/cgi-bin/mailman/listinfo/devel
>




More information about the Devel mailing list