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:cboulton@ubiquity.com] Sent: Wednesday, March 17, 2004 3:44
>> AM To: George Foti (QA/EMC); Jonathan Rosenberg Cc:
>> Markus.Isomaki@nokia.com; simple@ietf.org 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:george.foti@ericsson.com] Sent: 16 March 2004 18:07 To:
>>> 'Jonathan Rosenberg' Cc: 'Markus.Isomaki@nokia.com';
>>> simple@ietf.org 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 Simple@ietf.org 
>>>> 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 Simple@ietf.org 
>>> 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 
> Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple

_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple