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: Jonathan Rosenberg <[email-masked]>
Date: Wed, 10 Mar 2004 23:58:18 -0500

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: Jonathan Rosenberg <[email-masked]>
Date: Wed, 10 Mar 2004 23:58:18 -0500

inline.

Right.

Right.

                         +--------------+    SUB
                         |              |<--------------
                         |  Presence    |
                         |  Server      |
                         |              |    NOT
                         |              |-------------->
                         |              |
                         +--------------+
                           /        \
                         //          \\
                        /              \    publication
                       /                \
                     // SIP              \\
                    /   PUBLISH            \
                   /                        \

Thanks,
Jonathan R.