Subject: [Simple] Updating the XCAP PIDF manipulation draft

From: [email-masked]
Date: Fri, 23 Apr 2004 17:06:42 +0300

Hi,

Me and Eva are working on an update to the XCAP PIDF manipulation usage. Based on the earlier version there was some confusion on the relationship of the presence state set by SIP PUBLISH and XCAP PIDF manipulation. I've come up with the text below. I would like to get some feedback whether you think it is clear enough. At least George and Jonathan have commented the previous version, so I would especially like your comments.

Chapter 1 contains the motivation, I think no changes are needed for that. This is for Chapter 3 (the figure is unmodified):

---

The framework for publishing presence state is introduced in <xref target="draft_publish-reqs"/>. A central part of the framework is the event state compositor element whose function is to compose presence information received from serveral sources into a single coherent presence document.

The presence state manipulated with XCAP can be seen as one of the information sources for the compositor to be combined with the soft state information published using SIP PUBLISH. This is illustrated in Figure 1. It is expected that in the normal case there can be several PUAs publishing their separate views with SIP PUBLISH, but only single XCAP manipulated presence document. As shown in the figure, there can be multiple XCAP clients (for instance in different physical devices) manipulating the same document on the XCAP server, but this still creates only one input to the event state compositor.

As individual inputs the presence states set by XCAP and SIP PUBLISH are completely separated and it is not possible to directly manipulate the state set by one mechanism with the other. How the compositor treats XCAP based inputs with respect to SIP PUBLISH based inputs is a matter of compositor policy, which is beyond the scope of this specification. Since the SIP PUBLISH specification already mandates the compositor to be able to deal with multiple inputs, this XCAP usage does not impose any new requirements on the compositor functionality.  

---

Regards,
	Markus

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Alex Audu <[email-masked]>
Date: Fri, 23 Apr 2004 11:04:20 -0500

Would it add more clarity to also state that  XCAP state manipulation 
should be done
before SIP PUBLISH, since the XCAP process sets the policy rules that 
determine
which watcher gets  what published  information?  

Regards,
Alex.

---

From: Alex Audu <[email-masked]>
Date: Fri, 23 Apr 2004 11:04:20 -0500

Regards,
Alex.