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: Wed, 17 Mar 2004 06:34:36 -0600

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.

Another point in the draft that needs to be adequately addressed relates to the how the composer resolve conflicts between different PUAs.
Currently it is left to magic.

Jonathan alluded to the authorization policies in that regard, which I did not read yet, but is definitely the right place for this thing. So may be draft can refer to that and address the issue a bit more as opposed to saying, "the composer will have to figure out how to do that". 
> 
> Chris. 
> 
> 
> >-----Original Message-----
> >From: George Foti (QA/EMC) [mailto:[email-masked]]
> >Sent: 16 March 2004 18:07
> >To: '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)
> >
> >> Are you suggesting abandoning PUBLISH? Or just changing 
> the schema to
> >> restrict what you can set with xcap?
> >
> >I would like to change the schema to restrict what you can set with
> XCAP.
> >That way we minimize the potential misue of XCAP, both by 
> implementors
> >and/or end users
> >PUBLISH is OK. I see no problems with it.
> >The architecture is Ok as well. We need a way to set hard states.
> >
> >Thnx/gf
> >
> >>
> >> _______________________________________________
> >> Simple mailing list
> >> [email-masked]
> >> https://www1.ietf.org/mailman/listinfo/simple
> >>
> >
> >
> >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
> 
> 
> This message has been scanned for viruses by MailControl - 
www.mailcontrol.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: "Niemi Aki (Nokia-M/Espoo)" <[email-masked]>
Date: Wed, 17 Mar 2004 15:09:10 +0200

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.

> Another point in the draft that needs to be adequately addressed
> relates to the how the composer resolve conflicts between different
> PUAs. Currently it is left to magic.

At least I'm open to suggestions as to how you think it should be 
defined. For example, draft-roach-simple-service-features-00 descries 
some very good rules for determining what (service or communication 
means) a specific tuple is representing. I reckon resolving the 
conflicts becomes much easier if rules of comparison for detecting 
conflicts would be derived from those definitions, or something similar.

> Jonathan alluded to the authorization policies in that regard, which
> I did not read yet, but is definitely the right place for this thing.
> So may be draft can refer to that and address the issue a bit more as
> opposed to saying, "the composer will have to figure out how to do
> that".

That's exactly what PUBLISH does. Both PUBLISH and this XCAP usage are 
not meant to define the entire system, just the procedures for inserting 
state (hard or soft) into that system.

Cheers,
Aki

> 
>> Chris.
>> 
>> 
>> 
>>> -----Original Message----- From: George Foti (QA/EMC)
>>> [mailto:[email-masked]] Sent: 16 March 2004 18:07 To:
>>> 'Jonathan Rosenberg' Cc: [email-masked]';
>>> [email-masked] Subject: RE: [Simple] RE: Comments on
>>> PIDF-Manipulation Usage-00draft
>> 
>> (wa s
>> 
>>> and/or end users PUBLISH is OK. I see no problems with it. The
>>> architecture is Ok as well. We need a way to set hard states.
>>> 
>>> Thnx/gf
>>> 
>>> 
>>>> _______________________________________________ Simple mailing
>>>> list [email-masked] 
>> distribution is
>>> _______________________________________________ Simple mailing
>>> list [email-masked] 
> 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.
> 
> 
> 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: "Niemi Aki (Nokia-M/Espoo)" <[email-masked]>
Date: Wed, 17 Mar 2004 15:09:10 +0200

Inline.

Cheers,
Aki

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 17 Mar 2004 12:53:18 -0500

> of the corresponding publication etag.

I too am confused as to how it would even be possible to manipulate soft 
state. There is no way specified to even address -i.e., come up with an 
http URI - that identifies the published presence documents to 
manipulate them. I thought my prior note on the subject explained this 
more thoroughly.

-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: Wed, 17 Mar 2004 12:53:18 -0500

-Jonathan R.