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, 16 Mar 2004 06:41:24 -0600

Hi Markus,

Comments inline
/gf

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

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

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

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

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: Tue, 16 Mar 2004 12:52:32 -0500

George Foti (QA/EMC) wrote:

> Comments inline /gf
> 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).

Its only confusing if the UI couches this as "this is your presence 
status". Thats NOT what it is. Its "this is your DEFAULT information 
separate from anything your phone, PC, etc. will say". Indeed, it may 
never even look like that. It could be that a UI only allows a user to 
do something like set an indicator of whether they are on vacation, and 
this uses xcap in the back-end.

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

Why? PUBLISH can also contain user-generated information. I don't see 
how the protocol changes the possibility for conflict.

> 
> I cant imagine that anybody can implement the draft, as currently
> defined, as the example demonstrates the potential problems it can
> creates.

I'm still not sure I understand the problem. I thought you were 
concerned that the draft just wasnt clear enough on whether or not you 
manipulate hard or soft state. That can be fixed by wording. Now I think 
you are saying that this architectural approach is wrong. I don't 
understand that still.

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

So, what would you want to restrict?

> 
> Indeed, that draft allows me to set everything using XCAP.

Everything in a presence document, yes.

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

PUBLISH is for soft-state data. It is explicitly design to allow 
multiple clients to set data, and has etag facilities for managing that. 
because it uses sip routing, it can be used by applications outside of a 
user's home network and use sip routing to get to the right place.

XCAP is for managing the provisioned aspects of my presence data - my 
'default' presence document if you will. There is only ONE such presence 
document that is managed. Multiple clients can edit it, but its one 
document. Its hard state and NEVER expires. That makes it unsuitable for 
most of the states set by phones and other devices which need to expire.

So, though there is clearly a fine line, there are intended differences.

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

-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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 16 Mar 2004 12:52:32 -0500

-Jonathan R.