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

From: [email-masked]
Date: Tue, 16 Mar 2004 00:38:08 +0200

Hi,

See inline.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> ext George Foti (QA/EMC)
> Sent: 12 March, 2004 15:36
> To: Isomaki Markus (Nokia-NRC/Helsinki); [email-masked]
> 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)
> 
> 
> So let me run an example to see how this would work:
> 
> I assume here that there is no *standard* definition of what 
> tuples are "hard state" or "soft state".
> 

Right.

> I go to my PC, using XCAP create an XML document that sets my 
> cell phone status to be off, say tuple 1.
> The XCAP server, in turn, updates the composer & my presence 
> status for susbription.

OK.

> Then I turn my cell phone on, and launch the presence client 
> in it, which  I probably can configure to use the same tuple 
> id (as the one used in XCAP i.e tuple). The client will sets 
> the presence status ON &  pulishes that  to the composer 
> using PUBLISH.
> 

Tuple ids have no significance beyond the scope of a single PIDF document, so what you describe above is not exactly how this would work. However, you can PUBLISH an "identical" tuple from your cell phone (what identical means may actually not be so clear...) to what you manipulated earlier using XCAP. 

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

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

Currently SIMPLE has not defined anything about the composer, and it is not upto the pidf-manipulation XCAP usage to do so either.

> Can u please elaborate a bit on your answer here.
> 
> Thnx/gf
> 

Markus

> 
> 
> 
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]
> > Sent: Friday, March 12, 2004 5:18 AM
> > To: [email-masked]; 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)
> > 
> > 
> > Hi,
> > 
> > I think Jonathan already explained the relationship between 
> > the PIDF document that is manipulated with XCAP and the ones 
> > published using SIP PUBLISH. Actually the current draft 
> > already has a similar figure as Jonathan draw included:
> > 
> > ---
> > 
> > 
> >                +---------------+         +------------+
> >                |   Event State |         |  Presence  |--> 
> > SIP SUBSCRIBE
> >                |   Compositor  +---------+  Agent     |<-- 
> SIP NOTIFY
> >                |               |         |   (PA)     |
> >                +-------+-------+         +------------+
> >                  ^     ^     ^
> >                  |     |     |
> >                  |     |     |       +---------------+
> >         +--------+     |     +-------|  XCAP server  |
> >         |              |             +-------+-------+
> >         |              |                 ^         ^
> >         | SIP Publish  |                 |  XCAP   |
> >         |              |                 |         |
> >      +--+--+        +--+--+         +-------+   +-------+
> >      | PUA |        | PUA |         | XCAP  |   | XCAP  |
> >      |     |        |     |         | client|   | client|
> >      +-----+        +-----+         +-------+   +-------+
> > 
> > 
> >       Figure 1: Framework for Presence Publishing and Event State
> >                               Composition
> > 
> > ---
> > 
> > So it should be explicit and normative that XCAP and PUBLISH 
> > work upon different documents, and it is the matter of the 
> > "event state compositor" to figure out how to consolidate 
> > those inputs.
> > 
> > I'm planning to submit the "WG-version" of the draft early 
> > next. Before that I'll check if it is still possible to 
> > improve the wording to make things more clear, although I 
> > think the current text should be quite clear already.
> > 
> > I also think it's better to reference to the RFC defining the 
> > PIDF schema rather than copy-paste the definition within 
> this draft. 
> > 
> > Markus
> > 
> > > -----Original Message-----
> > > From: ext Jonathan Rosenberg [mailto:[email-masked]]
> > > Sent: 11 March, 2004 06:58
> > > To: George Foti (QA/EMC)
> > > Cc: Isomaki Markus (Nokia-NRC/Helsinki); [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.
> > > 
> > > George Foti (QA/EMC) wrote:
> > > 
> > > >> What if a user changes other  soft tuples with XCAP.
> > > >> 
> > > >> It is my understanding that they cannot.
> > > >> 
> > > >> This is enforced because the presence documents 
> > published through 
> > > >> PUBLISH are simply not reflected into the xcap hierarchy.
> > > >> 
> > > >> 
> > > >>> 
> > > >>> Will the server allow that?
> > > >> 
> > > >> No.
> > > > 
> > > > 
> > > > The current scope of the PIDF manipluation using XCAP is 
> > the entire
> > > > PIDF XML document as well as presence extensions.
> > > 
> > > 
> > > Right.
> > > 
> > > 
> > > > There is nothing in
> > > > the draft that says otherwise. As far as PUBLISH is 
> concerned, the
> > > > draft 03 explitly says that the content type for a 
> > > published presence
> > > > event is the PIDF presence document.
> > > 
> > > Right.
> > > 
> > > > 
> > > > Doesn't that imply that the indeed, per the current 
> > draft, published
> > > > documents for presence events are indeed reflected in the xcap
> > > > hierarchy, or have I missed something ?
> > > 
> > > No. Just because the content type of publications is the 
> > same as the 
> > > type manipulated by xcap, it does not mean that you can 
> manipulate 
> > > published documents with xcap.
> > > 
> > > The model which is implicit here (and perhaps needs to be 
> > explicit), 
> > > looks something like this:
> > > 
> > >    Please view in a fixed-width font such as Courier.
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > >                          +--------------+    SUB
> > >                          |              |<--------------
> > >                          |  Presence    |
> > >                          |  Server      |
> > >                          |              |    NOT
> > >                          |              |-------------->
> > >                          |              |
> > >                          +--------------+
> > >                            /        \
> > >                          //          \\
> > >                         /              \    publication
> > >                        /                \
> > >                      // SIP              \\
> > >                     /   PUBLISH            \
> > >                    /                        \
> > > 
> > >             +-----------+                 +-----------+
> > >             |           |                 |           |
> > >             |   PUA     |                 | XCAP Srvr |
> > >             +-----------+                 +-----------+
> > >                                                  ^
> > >                                                  |
> > >                                                  |
> > >                                                  |  xcap
> > >                                                  |
> > >                                                  |
> > >                                                  |
> > >                                                  |
> > >                                                  |
> > >                                                  |
> > >                                           +------------+
> > >                                           |            |
> > >                                           | XCAP Client|
> > >                                           +------------+
> > > 
> > > In this model, the presence server has many sources of 
> > presence data. 
> > > One is the SIP published documents. Another one is the 
> xcap server, 
> > > which stores a presence document permananetly and makes it 
> > > available to 
> > > the presence serevr through some kind of "publication" mecahnism 
> > > (generally an internal interface). The client can manipulate this 
> > > permanent document using xcap.
> > > 
> > > In this model, the xcap server simply doesnt have access to 
> > > the presence 
> > > documents published through sip.
> > > 
> > > Even if it did, we have no way to address them. That is, lets 
> > > say I had 
> > > a PC and a phone, and both used SIP PUBLISH to publish presence 
> > > documents. What xcap URL corresponds to the PC's presence 
> > > doc, and which 
> > > xcap url points to that of the phone? You would need to define 
> > > conventions for addressing these SIP published documents with 
> > > xcap. The 
> > > pidf-manipulation document doesnt do that, so there is simply 
> > > no way to 
> > > even shake a url at one of those documents to modify it. In 
> > > that way, it 
> > > is disallowed by the spec.
> > > 
> > > 
> > > > 
> > > > And one more thing, all applications using XCAP should 
> > have the XML
> > > > schema included in the usage draft for consistency and 
> > completness. 
> > > > The list usage application had them there, the CPCP (XCON) were
> > > > instructed to do. In this case they are not.
> > > 
> > > The schema for pidf-manipulation is pidf, so I thought it 
> > defined the 
> > > schema by referencing the pidf document. What is wrong with 
> > > doing that?
> > > 
> > > Thanks,
> > > 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
> > > 
> > 
>  
> 
> 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
> 

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 16 Mar 2004 10:15:01 -0500

inline.

[email-masked] wrote:

> Tuple ids have no significance beyond the scope of a single PIDF
> document, so what you describe above is not exactly how this would
> work. However, you can PUBLISH an "identical" tuple from your cell
> phone (what identical means may actually not be so clear...) to what
> you manipulated earlier using XCAP.
> 
> 
>> 1) The XCAP server has my cell phone turned OFF in its storage. 2)
>> My presence status has my cell phone turned ON.
>> 
> 
> 
> OK.
> 
> 
> 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.
> 
> Currently SIMPLE has not defined anything about the composer, and it
> is not upto the pidf-manipulation XCAP usage to do so either.

The presence authorization policies are meant to control this. In the 
proposal I sent out to the list last week, a user could use the policies 
to select between two different tuples, based on the class attribute.

-Jonathan R.

Chief Technology Officer                    Parsippany, NJ 07054-2711

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 16 Mar 2004 10:15:01 -0500

inline.

-Jonathan R.