Subject: RE: [Simple] RE: Comments on PIDF-Manipulation Usage-00draft (wa s RE: Comment s on draft-isomaki-simple-xcap-publish-usage-00)

From: "George Foti (QA/EMC)" <[email-masked]>
Date: Tue, 9 Mar 2004 14:00:26 -0600

> What if a user changes other  soft tuples with XCAP.
> 
> It is my understanding that they cannot.
> 
> This is enforced because the presence documents published through 
> PUBLISH are simply not reflected into the xcap hierarchy.
> 
> >  
> > Will the server allow that?
> 
> No.

The current scope of the PIDF manipluation using XCAP is the entire PIDF XML document as well as presence extensions. There is nothing in the draft that says otherwise.
As far as PUBLISH is concerned, the draft 03 explitly says that the content type for a published presence event is the PIDF presence document.

Doesn't that imply that the indeed, per the current draft, published documents for presence events are indeed reflected in the xcap hierarchy, or have I missed something ?

And one more thing, all applications using XCAP should have the XML schema included in the usage draft for consistency and completness.
The list usage application had them there, the CPCP (XCON) were instructed to do. In this case they are not.

> 
> >  
> > Where in your draft you explain/discuss  how to handle those cases?
> >  
> > And what are the tuples in PIDF and other extensions that you 
> > consider *hard state* tuples.
> 
> That is a good question. I tend to think that a "hard state" document 
> would usually have a tuple representing the presentity 
> (contact-type = 
> presentity), and have rpid elements like <vacation> that apply to the 
> presentity and not a particular device.
> 
> Do we need to MANDATE that the hard state document is 
> constructed this 
> way? I dont think so, but thats certainly a point worth discussing.

If events that are published through PUBLISH, have an xcap hierarchy and can be changed through XCAP, then we will have further issues with versioning and the current usage of e-tags in XCAP and PUBLISH 
> 
> -Jonathan R.
> 
> 
> -- 
> Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
> Chief Technology Officer                    Parsippany, NJ 07054-2711
> dynamicsoft
> [email-masked]                     FAX:   (973) 952-5050
> http://www.jdrosen.net                      PHONE: (973) 952-5000
> http://www.dynamicsoft.com
> 

This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.

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

---

From: "George Foti (QA/EMC)" <[email-masked]>
Date: Tue, 9 Mar 2004 14:39:08 -0600

> Is this normative? Does xcap forbid this, are are we just 
> assuming that 
> servers will never do it?
> 

No it is not normative, and thats my problem, and thats why I started the thread to reflect that.
And if you now consider the E-tag usage within PUBLISH & XCAP for PIDF manipulation, you have a serious incomplete specification, and a serious alignment that needs to be undertaken.

---

From: [email-masked]
Date: Fri, 12 Mar 2004 12:17:34 +0200

Hi,

I think Jonathan already explained the relationship between the PIDF document that is manipulated with XCAP and the ones published using SIP PUBLISH. Actually the current draft already has a similar figure as Jonathan draw included:

---

               +---------------+         +------------+
               |   Event State |         |  Presence  |--> SIP SUBSCRIBE
               |   Compositor  +---------+  Agent     |<-- SIP NOTIFY
               |               |         |   (PA)     |
               +-------+-------+         +------------+
                 ^     ^     ^
                 |     |     |
                 |     |     |       +---------------+
        +--------+     |     +-------|  XCAP server  |
        |              |             +-------+-------+
        |              |                 ^         ^
        | SIP Publish  |                 |  XCAP   |
        |              |                 |         |
     +--+--+        +--+--+         +-------+   +-------+
     | PUA |        | PUA |         | XCAP  |   | XCAP  |
     |     |        |     |         | client|   | client|
     +-----+        +-----+         +-------+   +-------+

      Figure 1: Framework for Presence Publishing and Event State
                              Composition

---

So it should be explicit and normative that XCAP and PUBLISH work upon different documents, and it is the matter of the "event state compositor" to figure out how to consolidate those inputs.

I'm planning to submit the "WG-version" of the draft early next. Before that I'll check if it is still possible to improve the wording to make things more clear, although I think the current text should be quite clear already.

I also think it's better to reference to the RFC defining the PIDF schema rather than copy-paste the definition within this draft. 

Markus

> -----Original Message-----
> From: ext Jonathan Rosenberg [mailto:[email-masked]]
> Sent: 11 March, 2004 06:58
> To: George Foti (QA/EMC)
> Cc: Isomaki Markus (Nokia-NRC/Helsinki); [email-masked]
> Subject: Re: [Simple] RE: Comments on PIDF-Manipulation Usage-00draft
> (wa s RE: Comment s on draft-isomaki-simple-xcap-publish-usage-00)
> 
> 
> 
> inline.
> 
> George Foti (QA/EMC) wrote:
> 
> > The current scope of the PIDF manipluation using XCAP is the entire
> > PIDF XML document as well as presence extensions.
> 
> 
> Right.
> 
> 
> > There is nothing in
> > the draft that says otherwise. As far as PUBLISH is concerned, the
> > draft 03 explitly says that the content type for a 
> published presence
> > event is the PIDF presence document.
> 
> Right.
> 
> > 
> > Doesn't that imply that the indeed, per the current draft, published
> > documents for presence events are indeed reflected in the xcap
> > hierarchy, or have I missed something ?
> 
> No. Just because the content type of publications is the same as the 
> type manipulated by xcap, it does not mean that you can manipulate 
> published documents with xcap.
> 
> The model which is implicit here (and perhaps needs to be explicit), 
> looks something like this:
> 
>    Please view in a fixed-width font such as Courier.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>                          +--------------+    SUB
>                          |              |<--------------
>                          |  Presence    |
>                          |  Server      |
>                          |              |    NOT
>                          |              |-------------->
>                          |              |
>                          +--------------+
>                            /        \
>                          //          \\
>                         /              \    publication
>                        /                \
>                      // SIP              \\
>                     /   PUBLISH            \
>                    /                        \
> 
>             +-----------+                 +-----------+
>             |           |                 |           |
>             |   PUA     |                 | XCAP Srvr |
>             +-----------+                 +-----------+
>                                                  ^
>                                                  |
>                                                  |
>                                                  |  xcap
>                                                  |
>                                                  |
>                                                  |
>                                                  |
>                                                  |
>                                                  |
>                                           +------------+
>                                           |            |
>                                           | XCAP Client|
>                                           +------------+
> 
> In this model, the presence server has many sources of presence data. 
> One is the SIP published documents. Another one is the xcap server, 
> which stores a presence document permananetly and makes it 
> available to 
> the presence serevr through some kind of "publication" mecahnism 
> (generally an internal interface). The client can manipulate this 
> permanent document using xcap.
> 
> In this model, the xcap server simply doesnt have access to 
> the presence 
> documents published through sip.
> 
> Even if it did, we have no way to address them. That is, lets 
> say I had 
> a PC and a phone, and both used SIP PUBLISH to publish presence 
> documents. What xcap URL corresponds to the PC's presence 
> doc, and which 
> xcap url points to that of the phone? You would need to define 
> conventions for addressing these SIP published documents with 
> xcap. The 
> pidf-manipulation document doesnt do that, so there is simply 
> no way to 
> even shake a url at one of those documents to modify it. In 
> that way, it 
> is disallowed by the spec.
> 
> 
> > 
> > And one more thing, all applications using XCAP should have the XML
> > schema included in the usage draft for consistency and completness. 
> > The list usage application had them there, the CPCP (XCON) were
> > instructed to do. In this case they are not.
> 
> The schema for pidf-manipulation is pidf, so I thought it defined the 
> schema by referencing the pidf document. What is wrong with 
> doing that?
> 
> Thanks,
> Jonathan R.
> 
> --

---

From: [email-masked]
Date: Fri, 12 Mar 2004 12:17:34 +0200

Hi,

---

---

Markus

---

From: "George Foti (QA/EMC)" <[email-masked]>
Date: Fri, 12 Mar 2004 07:35:55 -0600

So let me run an example to see how this would work:

I assume here that there is no *standard* definition of what tuples are "hard state" or "soft state".

I go to my PC, using XCAP create an XML document that sets my cell phone status to be off, say tuple 1.
The XCAP server, in turn, updates the composer & my presence status for susbription.
Then I turn my cell phone on, and launch the presence client in it, which  I probably can configure to use the same tuple id (as the one used in XCAP i.e tuple). The client will sets the presence status ON &  pulishes that  to the composer using PUBLISH.

So here is my cell phons status from each entity's point of view: 
1) The XCAP server has my cell phone turned OFF in its storage. 
2) My presence status has my cell phone turned ON.

Is that the way it should behave?
Can u please elaborate a bit on your answer here.

Thnx/gf

> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, March 12, 2004 5:18 AM
> To: [email-masked]; George Foti (QA/EMC)
> Cc: [email-masked]
> Subject: RE: [Simple] RE: Comments on PIDF-Manipulation Usage-00draft
> I think Jonathan already explained the relationship between 
> the PIDF document that is manipulated with XCAP and the ones 
> published using SIP PUBLISH. Actually the current draft 
> already has a similar figure as Jonathan draw included:
> 
> ---
> 
> 
> So it should be explicit and normative that XCAP and PUBLISH 
> work upon different documents, and it is the matter of the 
> "event state compositor" to figure out how to consolidate 
> those inputs.
> 
> I'm planning to submit the "WG-version" of the draft early 
> next. Before that I'll check if it is still possible to 
> improve the wording to make things more clear, although I 
> think the current text should be quite clear already.
> 
> I also think it's better to reference to the RFC defining the 
> PIDF schema rather than copy-paste the definition within this draft. 
> 
> Markus
>

---

From: "George Foti (QA/EMC)" <[email-masked]>
Date: Fri, 12 Mar 2004 07:35:55 -0600

Thnx/gf

---

From: [email-masked]
Date: Tue, 16 Mar 2004 00:38:08 +0200

Hi,

See inline.

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> ext George Foti (QA/EMC)
> Sent: 12 March, 2004 15:36
> To: Isomaki Markus (Nokia-NRC/Helsinki); [email-masked]
> Cc: [email-masked]

Right.

> I go to my PC, using XCAP create an XML document that sets my 
> cell phone status to be off, say tuple 1.

OK.

> Then I turn my cell phone on, and launch the presence client 
> in it, which  I probably can configure to use the same tuple 
> id (as the one used in XCAP i.e tuple). The client will sets 
> the presence status ON &  pulishes that  to the composer 
> using PUBLISH.
> 

Tuple ids have no significance beyond the scope of a single PIDF document, so what you describe above is not exactly how this would work. However, you can PUBLISH an "identical" tuple from your cell phone (what identical means may actually not be so clear...) to what you manipulated earlier using XCAP. 

> 2) My presence status has my cell phone turned ON.

OK.

> Is that the way it should behave?

Yes, it is now upto the composer to decide how to combine the two sources of presence information. Admittedly this is problematic if there is conflicting information. Typically the information obtained via SIP PUBLISH would override the information given by XCAP. However, there's no way to distinguish between two SIP PUBLISHes.

Currently SIMPLE has not defined anything about the composer, and it is not upto the pidf-manipulation XCAP usage to do so either.

Markus

> This communication is confidential and intended solely for 
> the addressee(s). Any unauthorized review, use, disclosure or 
> distribution is prohibited. If you believe this message has 
> been sent to you in error, please notify the sender by 
> replying to this transmission and delete the message without 
> disclosing it. Thank you.
> 
> E-mail including attachments is susceptible to data 
> corruption, interruption, unauthorized amendment, tampering 
> and viruses, and we only send and receive e-mails on the 
> basis that we are not liable for any such corruption, 
> interception, amendment, tampering or viruses or any 
> consequences thereof.
>

---

From: "George Foti (QA/EMC)" <[email-masked]>
Date: Tue, 16 Mar 2004 06:41:24 -0600

Hi Markus,

Comments inline
/gf

> > 2) My presence status has my cell phone turned ON.

This is extremely confusing for your average user, who would see through XCAP (through a normal document reading), that his phone is off, while his presence application should have set it on (and it did indeed).

> Yes, it is now upto the composer to decide how to combine the 
> two sources of presence information. Admittedly this is 
> problematic if there is conflicting information. Typically 
> the information obtained via SIP PUBLISH would override the 
> information given by XCAP. However, there's no way to 
> distinguish between two SIP PUBLISHes.
> 

Well let me say that there is no magic way to combine conflicting information.
The potential of conflicting information originating from different between PUA using SIP PUBLISH, mostly generated by applications as opposed to human intervention, is much less likely, then with using XCAP, where human intervention is needed.

I cant imagine that anybody can implement the draft, as currently defined, as the example demonstrates the potential problems it can creates.
I dont question the need for a user to set hard states. 
But using XCAP as currenly defined, (i.e wide open for anything) for that purpose opens a pandora box that I'd rather avoid.

Indeed, that draft allows me to set everything using XCAP. I dont need to have any presence application in my different clients. I can simply use XCAP.
Of course, I dont get the benifits of PUBLISH. But so what.

Rgds/gf

---

From: "George Foti (QA/EMC)" <[email-masked]>
Date: Tue, 16 Mar 2004 12:07:03 -0600

> Are you suggesting abandoning PUBLISH? Or just changing the schema to 
> restrict what you can set with xcap?

I would like to change the schema to restrict what you can set with XCAP.
That way we minimize the potential misue of XCAP, both by implementors and/or end users
PUBLISH is OK. I see no problems with it.
The architecture is Ok as well. We need a way to set hard states.

Thnx/gf

---

From: "George Foti (QA/EMC)" <[email-masked]>
Date: Tue, 16 Mar 2004 12:07:03 -0600

Thnx/gf

---

From: "Chris Boulton" <[email-masked]>
Date: Wed, 17 Mar 2004 08:44:22 -0000

Hi George,
	I'm getting a little confused by this thread.  I don't see any
benefit of restricting what 'Hard State' data can be set.  The use of
XCAP and the use of PUBLISH have clearly defined roles.  If a presence
server requires 'Hard state', it goes away and grabs the latest copy
from the XCAP repository.  I can see your point that rogue clients might
use XCAP in a negative manner (e.g. for changing soft state), but this
can be true of many implementations that bend rules.  As long as it is
strongly defined that XCAP is used for Hard state and PUBLISH is used
for soft state, I see no real issue.

Chris. 

>From: George Foti (QA/EMC) [mailto:[email-masked]]
>Sent: 16 March 2004 18:07
>To: 'Jonathan Rosenberg'
>Cc: [email-masked]'; [email-masked]
(wa s
>RE: Comment s on draft-isomaki-simple-xcap-publish-usage-00)
>
>This communication is confidential and intended solely for the
>addressee(s). Any unauthorized review, use, disclosure or distribution
is
>prohibited. If you believe this message has been sent to you in error,
>please notify the sender by replying to this transmission and delete
the
>message without disclosing it. Thank you.
>
>E-mail including attachments is susceptible to data corruption,
>interruption, unauthorized amendment, tampering and viruses, and we
only
>send and receive e-mails on the basis that we are not liable for any
such
>corruption, interception, amendment, tampering or viruses or any
>consequences thereof.
>

This message has been scanned for viruses by MailControl - www.mailcontrol.com

---

From: "Chris Boulton" <[email-masked]>
Date: Wed, 17 Mar 2004 08:44:22 -0000

Hi George,

Chris. 

(wa s
is
the
only
such

---

From: "George Foti (QA/EMC)" <[email-masked]>
Date: Wed, 17 Mar 2004 06:34:36 -0600

Comments inline Chris.
Rgds/gf
> From: Chris Boulton [mailto:[email-masked]]
> Sent: Wednesday, March 17, 2004 3:44 AM
> To: George Foti (QA/EMC); Jonathan Rosenberg
> Cc: [email-masked]; [email-masked]

Yes, thats my concern.
On the other hand there are *no rules* to bend in this case.
It is currently wide open to manipulate everything.
The language in the draft is very weak in that regard.
Changing the schema is one way to put in rules.
But I am opened to the alternative of strengthening the language in an updated version of the draft and to clearly disallow the usage of XCAP for changing soft states.

Another point in the draft that needs to be adequately addressed relates to the how the composer resolve conflicts between different PUAs.
Currently it is left to magic.

Jonathan alluded to the authorization policies in that regard, which I did not read yet, but is definitely the right place for this thing. So may be draft can refer to that and address the issue a bit more as opposed to saying, "the composer will have to figure out how to do that". 
> >That way we minimize the potential misue of XCAP, both by 
> implementors
> >and/or end users

---

From: [email-masked]
Date: Wed, 17 Mar 2004 15:12:29 +0200

Hi George,

See inline.

> From: ext George Foti (QA/EMC) [mailto:[email-masked]]
> Sent: 17 March, 2004 14:35
> To: 'Chris Boulton'; Jonathan Rosenberg

OK, please send your proposal text ASAP. My current idea is not to limit what information can be set with XCAP.

> Changing the schema is one way to put in rules.

Please make your proposal.

> But I am opened to the alternative of strengthening the 
> language in an updated version of the draft and to clearly 
> disallow the usage of XCAP for changing soft states.
> 

It is _impossible_ to set soft states with XCAP, since there is no expiration mechanism. Can you explain to me what YOU mean by soft state vs. hard state? How would you set soft state with XCAP?

> Another point in the draft that needs to be adequately 
> addressed relates to the how the composer resolve conflicts 
> between different PUAs.

This is beyond the scope of this draft.

> Jonathan alluded to the authorization policies in that 
> regard, which I did not read yet, but is definitely the right 
> place for this thing. So may be draft can refer to that and 
> address the issue a bit more as opposed to saying, "the 
> composer will have to figure out how to do that". 

Why do you think that we need to say anything more in this draft than in the PUBLISH draft?

---

From: [email-masked]
Date: Wed, 17 Mar 2004 15:12:29 +0200

Hi George,

See inline.

---

From: [email-masked]
Date: Thu, 1 Apr 2004 03:49:06 +0300

> ext Niemi Aki (Nokia-M/Espoo)
> Sent: 17.March.2004 15:09
> To: ext George Foti (QA/EMC)
> Cc: [email-masked]
> Inline.
> ext George Foti (QA/EMC) wrote:
> > Comments inline Chris. Rgds/gf
> > 
> >> -----Original Message----- From: Chris Boulton
> >> [mailto:[email-masked]] Sent: Wednesday, March 17, 2004 3:44
> >> AM To: George Foti (QA/EMC); Jonathan Rosenberg Cc:
> >> [email-masked]; [email-masked] Subject: RE: [Simple] RE:
> >> Comments on PIDF-Manipulation Usage-00draft (wa s RE: Comment s on
> >> draft-isomaki-simple-xcap-publish-usage-00)
> >> 
> >> 
> >> Hi George, I'm getting a little confused by this thread.  I don't
> >> see any benefit of restricting what 'Hard State' data can be set.
> >> The use of XCAP and the use of PUBLISH have clearly defined roles.
> >> If a presence server requires 'Hard state', it goes away and grabs
> >> the latest copy from the XCAP repository.  I can see your point
> >> that rogue clients might use XCAP in a negative manner (e.g. for
> >> changing soft state), but this can be true of many implementations
> >> that bend rules.  As long as it is strongly defined that XCAP is
> >> used for Hard state and PUBLISH is used for soft state, I see no
> >> real issue.
> > 
> > 
> > Yes, thats my concern. On the other hand there are *no 
> rules* to bend
> > in this case. It is currently wide open to manipulate 
> everything. The
> > language in the draft is very weak in that regard. Changing the
> > schema is one way to put in rules. But I am opened to the 
> alternative
> > of strengthening the language in an updated version of the draft and
> > to clearly disallow the usage of XCAP for changing soft states.
> 
> You make it sound like it was currently allowed. Well, it 
> isn't, and in 
> addition, it's not even possible. PUBLISH carries soft event 
> state. The 
> only way to manipulate that state is to use PUBLISH, and have 
> possession 
> of the corresponding publication etag.
> 
> I'm not aware of any text that suggests that the soft event state 
> manipulated with PUBLISH somehow also finds its way into the 
> XCAP tree.

George's point is that there is no text forbidding it, so in theory, it could find its way. But the question is: Do we really need to explicitly forbit such thing from happening by placing a MUST NOT text?

/Hisham

---

From: [email-masked]
Date: Thu, 1 Apr 2004 03:49:06 +0300

/Hisham