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: "George Foti (QA/EMC)" <[email-masked]>
Date: Fri, 23 Apr 2004 10:09:16 -0500

Hi Markus,

Here are my comments:

Second paragraph:

Replace: "but only single XCAP manipulated presence document", by
"but only single XCAP publishing source"

Third paragraph: replace the following section 
"As individual inputs ................one mechanism with the other"

by the following:

"Although presence states set by XCAP, on behalf of XCAP clients, and SIP PUBLISH, on behalf of PUAs,  are completely separated, conflicting information may occur within the composer for a presence state"

Rgds/gf 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, April 23, 2004 10:07 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; George Foti
> (QA/EMC)
> Subject: Updating the XCAP PIDF manipulation draft
> 
> 
> 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
>

---

From: "George Foti (QA/EMC)" <[email-masked]>
Date: Fri, 23 Apr 2004 10:09:16 -0500

Hi Markus,

Here are my comments:

Second paragraph:

by the following:

Rgds/gf

---

From: [email-masked]
Date: Mon, 26 Apr 2004 10:44:15 +0300

Hi Alex,

There are two separate things that XCAP is (can be) used for:
1. Setting authorization policies, which at least to some extent also define policies how the event state compositor should handle the different presence inputs wrt. different watchers. (The current draft is here: http://www.ietf.org/internet-drafts/draft-rosenberg-simple-rules-00.txt)
2. Setting the "hard-state" device-independent default presence status.

I think you are referring to case 1. It's true that some policy settings are typically done before actually publishing presence information, or manipulating the default presence document with XCAP. It is obviously possible to change them at any point as you want your policy to change. 

>From protocol point of view the XCAP operations done to manipulate the PIDF document are independent from the XCAP operations done to set the policies. Also, there is nothing which mandates in which temporal order SIP PUBLISH and XCAP PIDF manipulation are used.

Markus

> From: ext Alex Audu [mailto:[email-masked]]
> Sent: 23 April, 2004 19:04
> To: Isomaki Markus (Nokia-NRC/Helsinki)
> Cc: [email-masked]; Leppanen Eva-Maria (Nokia-NET/Tampere);
> [email-masked]; [email-masked]
> Subject: Re: [Simple] Updating the XCAP PIDF manipulation draft
> 
> 
> 
> 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.
> 
> [email-masked] wrote:
> 
> >Hi,
> >

---

From: [email-masked]
Date: Mon, 26 Apr 2004 10:44:15 +0300

Hi Alex,

Markus

---

From: [email-masked]
Date: Wed, 28 Apr 2004 11:55:16 +0300

Hi George,

Thanks for the comments. See inline:

> From: ext George Foti (QA/EMC) [mailto:[email-masked]]
> Sent: 23 April, 2004 18:09
> To: Isomaki Markus (Nokia-NRC/Helsinki); [email-masked]
> Cc: Leppanen Eva-Maria (Nokia-NET/Tampere); [email-masked]
> Subject: RE: Updating the XCAP PIDF manipulation draft
> 
> 
> Hi Markus,
> 
> Here are my comments:
> 
> Second paragraph:
> 

I think this is strictly a terminology issue, and with respect to this spec, people have preferred to use "XCAP manipulated presence document" instead of "XCAP publishing" to avoid even further confusion with SIP PUBLISH. 

> "Although presence states set by XCAP, on behalf of XCAP 
> clients, and SIP PUBLISH, on behalf of PUAs,  are completely 
> separated, conflicting information may occur within the 
> composer for a presence state"
> 

The definition of "conflicting" information is quite vague and can be different depending on what the actual composition scheme is. So I believe the current text already captures the main idea, that there can be multiple inputs, and the ESC needs to be able to deal with that. This is pretty much what SIP PUBLISH spec says too.

(Note that the support for XCAP based presence state setting is obviously completely optional in presence systems. In some cases it could be useful, in some others it may not be needed at all. Some use cases are presented in the introdution chapter, but they are just informational. So if someone thinks that XCAP based manipulation causes more problems than what the benefits are in his particular presence system, it can be left out. The spec just gives an opportunity to use it for those vendors/presence providers who have good ideas how to use it and see that SIP PUBLISH does not solve the needs properly.)

Markus

---

From: [email-masked]
Date: Wed, 28 Apr 2004 11:55:16 +0300

Hi George,

Markus

---

From: "George Foti (QA/EMC)" <[email-masked]>
Date: Wed, 28 Apr 2004 07:13:08 -0500

Comments in line Markus/gf

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> [email-masked]
> Sent: Wednesday, April 28, 2004 4:55 AM
> To: George Foti (QA/EMC); [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: [Simple] RE: Updating the XCAP PIDF manipulation draft
> 
> 
> Hi George,
> 
> I think this is strictly a terminology issue, and with 
> respect to this spec, people have preferred to use "XCAP 
> manipulated presence document" instead of "XCAP publishing" 
> to avoid even further confusion with SIP PUBLISH. 
> 

What is the confusion created here.
The XCAP manipulated presence document will have to be published to the composer.
I am merely reflecting that.
If you are not happy with the wording, can you add your own words to *explicitly* reflect in the text the publishing aspects from the XCAP source for the XCAP manipulated presence document.

> The definition of "conflicting" information is quite vague 
> and can be different depending on what the actual composition 
> scheme is. So I believe the current text already captures the 
> main idea, that there can be multiple inputs, and the ESC 
> needs to be able to deal with that. This is pretty much what 
> SIP PUBLISH spec says too.

I find the statement "ESC needs to be able to deal with that" even more vague in a spec.
I was merely trying to give some examples on the potential things the ESC must deal with, rather than leaving it as is.

If you are not happy with my wording, can you expand the text to give some examples of what the ESC have to deal with, given the multiple source of publishing information using SIP publisg or XCAP.

I beleive this needs some more description/clarification.

> 
> (Note that the support for XCAP based presence state setting 
> is obviously completely optional in presence systems. In some 
> cases it could be useful, in some others it may not be needed 
> at all. Some use cases are presented in the introdution 
> chapter, but they are just informational. So if someone 
> thinks that XCAP based manipulation causes more problems than 
> what the benefits are in his particular presence system, it 
> can be left out. The spec just gives an opportunity to use it 
> for those vendors/presence providers who have good ideas how 
> to use it and see that SIP PUBLISH does not solve the needs properly.)
> 
> Markus 
> 
> > Rgds/gf 
> >

---

From: "George Foti (QA/EMC)" <[email-masked]>
Date: Wed, 28 Apr 2004 07:13:08 -0500

---

From: [email-masked]
Date: Fri, 30 Apr 2004 01:54:32 +0300

Hi George,

OK, I'll add short text that says that the information coming from the different sources can be "non-orthogonal (and in some ways even conflicting)" and I'll add as an example one compositor policy, whereby the XCAP manipulated presence state is the default state used in absence of any soft state inputs based on SIP PUBLISH, and that the soft state inputs then augment or override the default state.

I've also rewritten the security considerations section, updated the references and fixed some typos. Otherwise there won't be any changes compared to the previous version.

Markus

> Sent: 28 April, 2004 15:13
> Subject: RE: [Simple] RE: Updating the XCAP PIDF manipulation draft
> 
> 
> > From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of
> > [email-masked]
> If you are not happy with the wording, can you add your own 
> words to *explicitly* reflect in the text the publishing 
> aspects from the XCAP source for the XCAP manipulated 
> presence document.
> 
> I was merely trying to give some examples on the potential 
> things the ESC must deal with, rather than leaving it as is.
> 
> If you are not happy with my wording, can you expand the text 
> to give some examples of what the ESC have to deal with, 
> given the multiple source of publishing information using SIP 
> publisg or XCAP.
>

---

From: "George Foti (QA/EMC)" <[email-masked]>
Date: Thu, 29 Apr 2004 18:01:18 -0500

Thanks Markus.
That should be fine.
Rgds/gf

> Sent: Thursday, April 29, 2004 6:55 PM
> OK, I'll add short text that says that the information coming 
> from the different sources can be "non-orthogonal (and in 
> some ways even conflicting)" and I'll add as an example one 
> compositor policy, whereby the XCAP manipulated presence 
> state is the default state used in absence of any soft state 
> inputs based on SIP PUBLISH, and that the soft state inputs 
> then augment or override the default state.
> 
> I've also rewritten the security considerations section, 
> updated the references and fixed some typos. Otherwise there 
> won't be any changes compared to the previous version.
> 
> Markus
>

---

From: [email-masked]
Date: Fri, 30 Apr 2004 01:54:32 +0300

Hi George,

Markus

---

From: "George Foti (QA/EMC)" <[email-masked]>
Date: Thu, 29 Apr 2004 18:01:18 -0500

Thanks Markus.
That should be fine.
Rgds/gf