Iñaki Baz Castillo wrote:
> 2010/5/25 Klaus Darilion <[email protected]>:
>> I think my RPID document is malformed, as <note> must be sub-element of
>> <person>, not of <activities>. Thus, I can not have a single person with
>> 2 activities with different note.
>
> Sorry, I didn't realize of that. Yes, AFAIK there is no "note" field
> for <activities>.
>
>
>> I think I have to use a dedicated <person> element for each <activities>
>> element to allow different <note> elements. Is my assumption correct?
>
> "Theorically" there can be just one <person>. The presence server
> should be clever enough to compose a definitive <person> section even
> if there are varios <person> sections published from different UA
> resources. This is specified, at least, in boring OMA specifications.
From RFC 4479:
However, there can be multiple occurrences of the person component.
This happens in cases where the state of the person component is
ambiguous, as discussed in Section 3.5.
So, I think it might be a valid scenario having multiple person
elements, even generated by the same presence agent. If the
corresponding activities contain from/until parameter and the activities
do not overlap the watcher can detect the currently relevant
activityies/person-element.
>
> NOTE: This stuff will never work as there is not a real way to
> determine which <person> to choose (imagine the road race condition
> when two devices are publishing a presentity with <person> section).
> In XMPP this is solved with the concept of "resource". Bad luck, this
> doesn't exist in SIMPLE. SIMPLE/XCAP specifications for SIP presence
> are just a toy or a joke, it's not a feasible solution.
What about using "classes". E.g. by specifying class=calendar for person
elements created by the calender presence user agent the watcher might
be smart enough to render the data as "this is what his calender says,
but of course he might be somewhere else".
regards
klaus
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors