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

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

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/
 
 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/
 
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/
 
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/ 
 
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.