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: Mon, 5 Apr 2004 06:31:05 -0500

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Ben Campbell
> Sent: Friday, April 02, 2004 3:55 PM
> To: Jonathan Rosenberg
> Cc: [email-masked]; [email-masked]; George Foti
> (QA/EMC); [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)
> 
> 
> Jonathan Rosenberg wrote:
> [...]
> 
> >>>
> >>> 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.
> 
> 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.
> 

Indeed this is a very real scenario. Given that the interface between the XCAP server & the PS is proprietary, the XCAP server is a privilaged publisher, and does not require any refresh for a published state.

So the presence composer will have to have local policies and rules to handle status information for same devices/applications coming from multiple sources inorder to have a predictiable behavior.
> 
> 
> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/simple
> 

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 06 Apr 2004 01:22:18 -0400

inline.

George Foti (QA/EMC) wrote:

> 
>> -----Original Message----- From: [email-masked]
>> [mailto:[email-masked]]On Behalf Of Ben Campbell Sent:
>> Friday, April 02, 2004 3:55 PM To: Jonathan Rosenberg Cc:
>> [email-masked]; [email-masked]; George Foti 
>> (QA/EMC); [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)
>> 
>> 
>> Jonathan Rosenberg wrote: [...]
>> 
>> 
>>>>> 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.
>> 
>>>> 
>>>> 
>>>> 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.

My point was, there is no STANDARD way to do this, since reflecting the 
published documents into the xcap tree reqiures a well-known set of HTTP 
URIs for identifying those documents. There is no such standard, and 
therefore there could be no interop for this.

>> something to that effect.
>> 
> 
> 
> Indeed this is a very real scenario. Given that the interface between
> the XCAP server & the PS is proprietary, the XCAP server is a
> privilaged publisher, and does not require any refresh for a
> published state.
> 
> So the presence composer will have to have local policies and rules
> to handle status information for same devices/applications coming
> from multiple sources inorder to have a predictiable behavior.

I dont think this fact has anything to do with pidf-manipulation. 
Composition in general will require policies that tell the compositor 
how to handle multiple sources, potentially more than one for the same 
device.

-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, 06 Apr 2004 01:22:18 -0400

inline.

-Jonathan R.