RE: [Simple] Updated RPID

[Markus.Isomaki at nokia.com]

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
Simple at ietf.org
https://www1.ietf.org/mailman/listinfo/simple