2010/5/25 Klaus Darilion <[email protected]>: >> "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.
Of course, SIMPLE RFC's allow *anything*, you can create a XML in any way and most probably it will be correct, but let's see how interoperable it is :) > 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. If you find a UA clever enough to parse and render such presentity with multiple <person> and <activities from...> please let me know. I can be waiting 10 years. >> 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". Such field is not standarized so just a propietary implementation would understand the meaning you propose. > regards > klaus > -- Iñaki Baz Castillo <[email protected]> _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
