[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Simple] Updated RPID



Markus.Isomaki at nokia.com 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
jdrosen at dynamicsoft.com                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

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