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

From: "George Foti (QA/EMC)" <[email-masked]>
Date: Tue, 2 Mar 2004 21:02:42 -0600

Hi Markus,
I would like to adrress the following statement below that I cut from the original exchange:
 
1)  First, a presentity can publish several PIDF documents using SIP PUBLISH. Then, she can have a single "hard state" PIDF document manipulated with XCAP. All of these can contain any number of tuples. All this is fed into magic called "event state compositor", which produces a single consistent presence document. The fact that the compositor logic has been left as implementation specific is a feature (or a deficiency) in SIMPLE, and this draft makes it no worse. I agree that there will be interoperability issues with how things with the composition definition are at the moment, but this draft does not cause the problem.
 
/gf
There is no  stand alone "hard state" PIDF document that is defined today that can be solely managed by XCAP.
XCAP requires an XML document with an XML schema to be able to properly verify operations.
What you have in mind, I think, is a number of tuples from various defined presence documents (PIDF, RPID, etc..) that you want to manage using XCAP.
 
Unless you create such a *stand alone* XMP document for hard states, I dont beleive that you can do what you want with XCAP, without creating interoperability problems, or open the door for abuses that would require complexities to overcome.
gf/
2) Based on this I assume PIDF would still be OK for XCAP as it is now.
 
This is where I beleive that what you want can only be done with a *new stand-alone* XML  document. For example, the XCAP framework requires the inclusion of the mandatory-ns element, if you would include in the XML document managed by XCAP, elements from other name spaces.
That today is not part of PIDF.  The tuples you want XCAP to manage are not part of PIDF, rather other presence documents.
So how would that work then.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, March 02, 2004 9:23 PM
To: George Foti (QA/EMC); [email-masked]
Subject: RE: Comments on PIDF-Manipulation Usage-00draft (was RE: Comments on draft-isomaki-simple-xcap-publish-usage-00)

Hi,
 
OK, this time I understood your points much better.
 
Comments starting with [MI] inline:

-----Original Message-----
From: ext George Foti (QA/EMC) [mailto:[email-masked]]
Sent: 03 March, 2004 03:52
To: Isomaki Markus (Nokia-NRC/Helsinki); [email-masked]
Subject: Comments on PIDF-Manipulation Usage-00draft (was RE: Comments on draft-isomaki-simple-xcap-publish-usage-00)

Sorry, I had the wrong draft in the subject, but I meant the PIDF Manipulation draft.
Comments inline/gf

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, March 02, 2004 8:24 PM
To: George Foti (QA/EMC); [email-masked]
Subject: RE: Comments on draft-isomaki-simple-xcap-publish-usage-00

Hi George,
 
First of all, the document you are referring to has been updated with this one:
http://www.ietf.org/internet-drafts/draft-isomaki-simple-xcap-pidf-manipulation-usage-00.txt <http://www.ietf.org/internet-drafts/draft-isomaki-simple-xcap-pidf-manipulation-usage-00.txt> 
 
I'll submit the WG version shortly after the meeting. The changes compared to the version you read are mainly clarifications, so I think your comments would apply to the new draft as well. My anwers to each point below:
 
1) XCAP operations are hard state by nature, no refreshing is needed, so this is inherently hard state manipulation. 
/gf 
Agree, but how do you prevent users, from using XCAP from manipulating presence soft states.
I assume that all the presence tuples are part of the same presence document. 
Now you are advocating selective manipluation of some tuples and not others using XCAP.
Have I misunderstood something here ?
How will you enforce that ?
gf/
 
[MI] OK, I think I know what you mean. The model for how the final presence document is put together is shown in the draft in Chapter 3. First, a presentity can publish several PIDF documents using SIP PUBLISH. Then, she can have a single "hard state" PIDF document manipulated with XCAP. All of these can contain any number of tuples. All this is fed into magic called "event state compositor", which produces a single consistent presence document. The fact that the compositor logic has been left as implementation specific is a feature (or a deficiency) in SIMPLE, and this draft makes it no worse. I agree that there will be interoperability issues with how things with the composition definition are at the moment, but this draft does not cause the problem.
 
 2) The default model I have in mind is that each presentity would have exactly one persistent device-independent presence document that would be manipulated by XCAP. That would be fed to the composition logic to complement the PUA/device-specific documents published using SIP PUBLISH mechanism.  
XCAP is meant to be a generic XML-manipulation mechanism, so there should be nothing specific in this application usage. Once the base XCAP is finished, we'll see what the exact mechanisms to mandate supported namespaces are, and we'll adopt that convention in this draft too. This is probably still changing from xcap-02 draft, as was discussed in SIMPLE session.  
 
/gf
Not totally true
XCAP have a limited set of rules for HTTP URI creation.
So it is not meant for *any* XML document.
I think the XCAP framework is clear on that
You would need to expand those rules, which can complicate things quite a lot, not to mention slow things down, to make it more generic. 
gf/ 
 
[MI] I think you are right on this one, my previous statement was wrong. XCAP can have problems with handling *any* XML document, if the selector construction will be restricted to only limited number of possibilities. However, see Jonathan's mail attached to this mail. Based on this I assume PIDF would still be OK for XCAP as it is now.
 
3) I'm not sure if I understood the question. This is not a template for any applications that want to use XCAP, this is standardizing how XCAP is used to manipulate PIDF-formatted presence documents. As there is no computed data or anything, I guess an app usage for any XML doc would be quite similar to this one. 
 
/gf
For event packages we have a template that have to be filled by for anyone who wants to create a new event package.
So I am asking if your document presents a template, similar to the event package approach. (forget about the content for your application)
I am not sure if I am clear on that one. 
gf/ 
 
[MI] OK, I got the question, thanks. Yes, we tried to follow the structure/template how Jonathan has defined the other existing XCAP application usages. So it should be according to how XCAP AUs are ssupposed to be specified. 
 
4) Surely there are many ways to manipulate PIDF documents. However, in context of SIMPLE, XCAP is a natural choice since it's needed already in any advanced presence-capable device. Could you explain what kind of complexities you mean? This is as simple an XCAP usage as there can be. Are you saying that XCAP in itself is complex? A more simple way would be to use just normal HTTP PUT and DELETE, but since we have XCAP at our disposal, why not use it. 
 
/gf
The complexities will arise if we allow users to do selective manipulation, using XCAP, for certain tuples *only*, and using PUBLISH for the remaining tuples.
So I need to see your answer first to my response to your first  bullet before I go further
 gf/ 
 
[MI] As I explained above, you can already PUBLISH several documents and there has to be a way to do composition. So the complexity is already inbuilt in SIMPLE, it is not in this sense extended here.
 
Markus

-----Original Message-----
From: ext George Foti (QA/EMC) [mailto:[email-masked]]
Sent: 03 March, 2004 02:47
To: Isomaki Markus (Nokia-NRC/Helsinki); [email-masked]
Subject: Comments on draft-isomaki-simple-xcap-publish-usage-00

Hi Markus, 

I have some comments on your draft: 

1) Although you indicate that this should be used only for hard states, what is there to prevent users from manipulating other presence states in there through XCAP.

2) XCAP is meant to be used for documents that are created to take advantage of the defined XCAP rules for HTTP URI creation. Which XML presence documents in particular are you proposing that they get manipulated by XCAP.  

How do you ensure that the current XCAP rules are suffiicient for the purpose you have in mind. I also doubt that you can use the current XML presence documents (PIDF and extensions) for XCAP purposes as is. For example, should there not be the element mandatory-ns, in there, as per the XCAP framework.

3) Is this template meant to be a generic template to be used by all applications that want to use XCAP. 

4) Finally, I believe that there are other, out-of-band means, to accomplish your goals, i.e. manipulate hard states, without the unwarranted complexities that the draft creates. Thus, there must be explicit references in the draft to that fact.  

/gf 
Ericsson Canada 

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 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 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, 2 Mar 2004 21:02:42 -0600

Hi Markus,

/gf

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, March 02, 2004 9:23 PM
To: George Foti (QA/EMC); [email-masked]
Subject: RE: Comments on PIDF-Manipulation Usage-00draft (was RE: Comments on draft-isomaki-simple-xcap-publish-usage-00)

Hi,

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, March 02, 2004 8:24 PM
To: George Foti (QA/EMC); [email-masked]
Subject: RE: Comments on draft-isomaki-simple-xcap-publish-usage-00

Hi George,

 

 
/gf
Not totally true

 
/gf

 
/gf

Markus

-----Original Message-----
From: ext George Foti (QA/EMC) [mailto:[email-masked]]
Sent: 03 March, 2004 02:47
To: Isomaki Markus (Nokia-NRC/Helsinki); [email-masked]
Subject: Comments on draft-isomaki-simple-xcap-publish-usage-00

Hi Markus, 

/gf 
Ericsson Canada

---

From: "George Foti (QA/EMC)" <[email-masked]>
Date: Wed, 3 Mar 2004 15:47:43 -0600

Comments inline, but we would meet f2f/gf

> Sent: Wednesday, March 03, 2004 7:04 AM
> Subject: RE: Comments on PIDF-Manipulation Usage-00draft (was RE:
> Comments on draft-isomaki-simple-xcap-publish-usage-00)
> 
> 
> Hi George,
> 
> I think you may still missing the point that there is not 
> only one but several presence documents that can be published 
> by a presentity, and only at the event state compositor do 
> they get combined into a single document. 

You are talking about implementation here.
Today, there is a singe PIDF XML document that can be managed by XCAP.
and it includes everything
The split you are discussing here is not formaized and unless there is an XML document with a defined 
XML schema defined, I dont see how you can XCAP the way you are suggesting.

For instance each 
> PUA publishing with SIP PUBLISH will have its own separate 
> PIDF-doc. The draft does not propose those documents to be 
> manipulated by XCAP, so there is clear separation between 
> "soft state PUA-specific" presence and "hard-state 
> device-independent" presence. What the draft proposes is that 
> there woud be a single device independent "hard-state" 
> presence document in addition to the PUA-specific ones. The 
> motivation is given in Chapter 1 and the model is illustrated 
> in Figure 1. 
> 
> So in short: The "hard-state" and "soft-state" tuples are 
> kept in separate documents, and the scenario you describe 
> below won't exist.
> 

Can you point me to the 2 XML documents that describe those.
 
> What exactly would go into the hard-state presence document 
> is not defined in the draft, and  is left for an implementor 
> or user to decide. Typically there could be things like 
> web-page address, e-mail specific tuple, or even some tuples 
> with the future-status, i.e. something that is not tied to a 
> single device and/or does not change very often. Also this 
> document would form the basis for the outgoing presence 
> information in the absense of any publishing PUAs.
> 
> Markus   
> 
> 
> Sent: 03 March, 2004 10:10
> Subject: RE: Comments on PIDF-Manipulation Usage-00draft (was 
> RE: Comments on draft-isomaki-simple-xcap-publish-usage-00)
> 
> 
> Hi Markus,
> 
> Lets leave the mandatory-ns element aside for the time being.
> You stated that one should use XCAP to control *hard state* 
> tuples only
> What if a user changes other  soft tuples with XCAP.
> 
> Will the server allow that?
> 
> 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.
> 
> Rgds/gf
>   
> 

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

---

From: "George Foti (QA/EMC)" <[email-masked]>
Date: Wed, 3 Mar 2004 15:47:43 -0600

For instance each

---

From: "George Foti (QA/EMC)" <[email-masked]>
Date: Wed, 3 Mar 2004 02:09:42 -0600

Hi Markus,
 
Lets leave the mandatory-ns element aside for the time being.
You stated that one should use XCAP to control *hard state* tuples only
What if a user changes other  soft tuples with XCAP.

 
And what are the tuples in PIDF and other extensions that you consider *hard state* tuples.
 
Rgds/gf

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, March 03, 2004 2:47 AM
To: George Foti (QA/EMC); [email-masked]
Subject: RE: Comments on PIDF-Manipulation Usage-00draft (was RE: Comments on draft-isomaki-simple-xcap-publish-usage-00)

Hi George,
 
Section 4.7 in XCAP defines the following:
 
   A server is required to understand the baseline schema defined
   by the application usage. However, those schemas can define points of
   extensibility where new content can be added from other namespaces
   and corresponding schemas. Sometimes, the server will understand
   those namespaces and therefore have access to their schemas.
   Sometimes, it will not.

   A server MUST allow for documents that contain elements from
   namespaces not known to the server. In such a case, the server cannot
   validate that such content is schema compliant; it will only verify
   that the XML is well-formed.
 
In this case the baseline schema is the one defined in PIDF soon-to-become RFC. RPID, CIPID etc. extend PIDF in the allowed points of extensibility. There is nothing in those namespaces that the server really needs to understand. This means that the mandatory-ns mechanism (which itself will probably change in the next rev of XCAP), would not be needed.
 
Does this clarify your concerns?
 
Markus 

-----Original Message-----
From: ext George Foti (QA/EMC) [mailto:[email-masked]]
Sent: 03 March, 2004 05:03
To: Isomaki Markus (Nokia-NRC/Helsinki); [email-masked]
Subject: RE: Comments on PIDF-Manipulation Usage-00draft (was RE: Comments on draft-isomaki-simple-xcap-publish-usage-00)

Hi Markus,

/gf

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, March 02, 2004 9:23 PM
To: George Foti (QA/EMC); [email-masked]
Subject: RE: Comments on PIDF-Manipulation Usage-00draft (was RE: Comments on draft-isomaki-simple-xcap-publish-usage-00)

Hi,

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, March 02, 2004 8:24 PM
To: George Foti (QA/EMC); [email-masked]
Subject: RE: Comments on draft-isomaki-simple-xcap-publish-usage-00

Hi George,

 

 
/gf
Not totally true

 
/gf

 
/gf

Markus

-----Original Message-----
From: ext George Foti (QA/EMC) [mailto:[email-masked]]
Sent: 03 March, 2004 02:47
To: Isomaki Markus (Nokia-NRC/Helsinki); [email-masked]
Subject: Comments on draft-isomaki-simple-xcap-publish-usage-00

Hi Markus, 

/gf 
Ericsson Canada