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

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 31 Mar 2004 23:13:40 -0500

inline.

[email-masked] wrote:

> 
>>-----Original Message-----
>>From: [email-masked] [mailto:[email-masked]]On Behalf Of
>>ext Niemi Aki (Nokia-M/Espoo)
>>Sent: 17.March.2004 15:09
>>To: ext George Foti (QA/EMC)
>>Cc: [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.
>>
>>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?

I think its sufficient to say that there is simply no way, with this 
application usage, to point to such presence documents, making it out of 
scope.

-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

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 31 Mar 2004 23:13:40 -0500

inline.

-Jonathan R.

---

From: Ben Campbell <[email-masked]>
Date: Fri, 02 Apr 2004 14:54:54 -0600

Jonathan Rosenberg wrote:
[...]

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

I am a little confused by the statement "there is no way". I can imagine 
someone co-locating their XCAP service and a PA, and reflecting the 
current presence state into the XCAP tree. Any meta-data like 
expirations and entity tags could just be left out from the XCAP view.

The point is, doing this is a bad idea. Perhaps we should say something 
to that effect.

---

From: Ben Campbell <[email-masked]>
Date: Fri, 02 Apr 2004 14:54:54 -0600