Subject: RE: [Simple] Updated RPID

From: [email-masked]
Date: Tue, 12 Oct 2004 23:17:00 +0300

Hi,

I support the idea of restricting RPID elements to specifically apply to either person or service or device. If they apply to multiple categories, as e.g. idle, they must have a different meaning specific to the category. I don't like the idea of reporting person related information in service tuples, for instance in a way it is done for activities and placetype in the examples of the updated RPID draft.

This thread also had some discussion on conflict resolution. I'm particularly interested how this should be done for person element, since the data model explicitly states that there can be only one person element in each presence document. So what should the presence server do if it gets publications for multiple person elements from different sources. The data model draft proposes that the newest one is picked if there is no further information what to do. 

I believe we need to have some more information. As I have indicated in another thread, I would like to clearly distinguish between override and additional/parallel information. Actually this applies to person, service and device. I have a couple of concrete real-world use cases that must be supported before we have anything useful. 

1. A user has three PUAs that report something related to his person information. One is a PC that can report anything. The other one is a cell phone that can similarly report anything. The third one is a network based PUA who should report e.g. whether I'm on the phone (info obtained from the cell phone network), or whether I'm at the office (info obtained through the office entrance control system). Clearly the PC and cell phone PUAs are usually competing or exclusive, and if I have left my PC somewhere to report obsolited info, I should be able to override that from the cell phone (or vice versa). On the other hand the network based PUA(s) typically provide complementary information, i.e. the info given by them should be merged with the other information (unless I want to explicitly override that too!). 

If composition policy is completely proprietary, it is very hard to build the PUAs in a reasonable way so that the user would really know what is going on. For this reason I think we need at minimum, even for person, a way of saying either a) override your previous person info with identifier X with this information, or b) merge this person info with the rest of the person information you have. 

To me this is solvable so that we just define an identifier, whose semantics are as follows: "If two or more person elements are published with an identical identifier, the composer MUST take only the most recent of them to be part of the composition process. The composer MUST merge the information in person elements having different identifiers into a single person element using any heuristics it has at its disposal. The most natural way is to union them together".

2. User has a cell phone which updates its characteristics in device element. However, some information related to the device also comes from the network, such as its location. So here we have two sources publishing information about a device which are not exclusive but complementary.

The data model draft does not support this properly, since two sources publishing with a same device id are considered to be conflicting. Again, similar solution is needed as for person. Some identifier which tells explicitly whether the publication is intended to override some potentially existing info, or is it intended to be merged with the existing info.

Conclusion: Let's define the capability for distinguishing between override and append for person, tuple and device. In addition to the identifier we need a way for publication sources to access the other published information to learn about the identifier values.

Markus   

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 13 Oct 2004 05:58:24 -0400

[email-masked] wrote:

> Hi,
> 
> I support the idea of restricting RPID elements to specifically apply
> to either person or service or device. If they apply to multiple
> categories, as e.g. idle, they must have a different meaning specific
> to the category. I don't like the idea of reporting person related
> information in service tuples, for instance in a way it is done for
> activities and placetype in the examples of the updated RPID draft.

There appears to be general agreement on this point, so let us declare 
this part closed.

> 
> This thread also had some discussion on conflict resolution. I'm
> particularly interested how this should be done for person element,
> since the data model explicitly states that there can be only one
> person element in each presence document. So what should the presence
> server do if it gets publications for multiple person elements from
> different sources. The data model draft proposes that the newest one
> is picked if there is no further information what to do.
> 
> I believe we need to have some more information. As I have indicated
> in another thread, I would like to clearly distinguish between
> override and additional/parallel information. Actually this applies
> to person, service and device. I have a couple of concrete real-world
> use cases that must be supported before we have anything useful.
> 
> 1. A user has three PUAs that report something related to his person
> information. One is a PC that can report anything. The other one is a
> cell phone that can similarly report anything. The third one is a
> network based PUA who should report e.g. whether I'm on the phone
> (info obtained from the cell phone network), or whether I'm at the
> office (info obtained through the office entrance control system).
> Clearly the PC and cell phone PUAs are usually competing or
> exclusive, and if I have left my PC somewhere to report obsolited
> info, I should be able to override that from the cell phone (or vice
> versa). On the other hand the network based PUA(s) typically provide
> complementary information, i.e. the info given by them should be
> merged with the other information (unless I want to explicitly
> override that too!).
> 
> If composition policy is completely proprietary, it is very hard to
> build the PUAs in a reasonable way so that the user would really know
> what is going on. For this reason I think we need at minimum, even
> for person, a way of saying either a) override your previous person
> info with identifier X with this information, or b) merge this person
> info with the rest of the person information you have.

This is what composition policy defines. Its proprietary now in the 
sense that we have not written standards which allow its control. That 
doesnt mean we won't, it means we haven't yet. TO date, we haven't even 
had a firm grasp on what presence really meant in our systems, let alone 
how to override it.

So, I am not objecting to the requirement. I am saying, we have an 
approach in the data model which defines a default behavior in absence 
of explicit policy directing otherwise. That default behavior covers the 
cases that appear to be most pressing - changing my status from "in a 
meeting" to "available" when I get home and my work PC is publishing old 
information. It does not cover more complex cases where I need to accept 
partial information from some sources, and completely override from 
others. That is fine to solve, but it IS composition policy and we 
should not try to define it now.

Keep in mind also that a presence document is not a "command" - it's 
state. It makes no sense to include an identifier in a presence document 
whose meaning is "override existing state with this". What would happen 
if someone else published a document saying the same thing? Who wins? 
The most recent? Well, having the most recent override is exactly what 
is in there today, and has the same effect.

> 
> To me this is solvable so that we just define an identifier, whose
> semantics are as follows: "If two or more person elements are
> published with an identical identifier, the composer MUST take only
> the most recent of them to be part of the composition process. The
> composer MUST merge the information in person elements having
> different identifiers into a single person element using any
> heuristics it has at its disposal. The most natural way is to union
> them together".

We have a disconnect here in the model of how this works.

In the model described in the document, each source publishes the state 
of the universe as it knows it, period. The published documents do not 
themselves contain tidbits of composition policy. Composition policy is 
something specified totally separately, and it makes decisions based on 
information in the documents. What you are suggesting is that you can 
effectively insert directives to control composition in the presence 
document itself - special identifiers that have significance ONLY in the 
context of composition. This is contrary to the model; the document has 
meaning in absence of any other part of the system, and its one and only 
goal is to describe the presentity.

> 
> 2. User has a cell phone which updates its characteristics in device
> element. However, some information related to the device also comes
> from the network, such as its location. So here we have two sources
> publishing information about a device which are not exclusive but
> complementary.
> 
> The data model draft does not support this properly, since two
> sources publishing with a same device id are considered to be
> conflicting. 

Yes. However, the model does not say that you have to pick one winner. 
It talks about merging of information, and allows all kinds of things to 
happen. If you are finding text in the document that suggests that the 
composition policy always picks a winner when there are conflicting 
information about a service or device, let me know and I will correct it.

> Again, similar solution is needed as for person. Some
> identifier which tells explicitly whether the publication is intended
> to override some potentially existing info, or is it intended to be
> merged with the existing info.
> 
> Conclusion: Let's define the capability for distinguishing between
> override and append for person, tuple and device. In addition to the
> identifier we need a way for publication sources to access the other
> published information to learn about the identifier values.

As above, based on the model as defined, this falls into the realm of 
composition policies, not presence documents.

-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