inline.
Henning Schulzrinne wrote:
I think this approach may make things less expressive. If I provide information about the person in the service tuple, how can I specify that this information is really about the person? How can I differentiate that information from information about the service?
I was unclear. With a bit more thinking (see last message), I think the better solution is to allow multiple <person> elements and have each service/device that actually derives this information include a <person> element in its publication.
You are combining two things here.
The data model states that, for any presence document we have, there can be only one <person> element in it. Thats because in our model of what presence means, there is a single user and they have devices and services. Presence documents need to be meaningful in a standalone fashion.
As such, it is perfectly fine for a PC to publish a document that says what it thinks the person's status is, and for the cell phone to do the same. What is NOT ok currently is for a compositor to take these and include both in the resulting notification.
As I mentioned, we most definitely went through this debate in the design team, and I argued strongly then, and will continue to do so now, that I think this is a bad idea.
The big problem that caused the "what is a tuple" mess is that we never managed to get concise or specific about anything. There were so many choices, so many ways of expression, that one couldn't look at a presence document outside of a context and usefully interpret it. Thus, the model document took the approach that presence is a well specified thing - it describes a single person and their devices and services.
I believe that, from a data model perspective, we absolutely, postiveily MUST MUST MUST keep the concept that there is a single person being modeled by presence.
I don't think anyone is disputing this.
for groups and collections of people. That is not what we are trying to do. What I believe you are proposing is that there is a single person, but you want to represent multiple values for all of its attributes, because there may actually be conflicting data that I want a recipient of a document to see.
Yup.
The view of the design team on this, and my view as well, is that this is fine in principle, but it is not a baseline feature by any stretch. No existing presence system today gives you conflicting data and asks you to reconcile it. I think we should stick to a basic model with basic features.
Indeed, there are lots of questions around conflicting data that would need to get resolved. What context is needed to provide the recipient of a document with enough information to meaningfully resolve it? Do we need timestamping information? How do we really authorize sources as being more or less authoritative for a particular piece of data? If you want to report conflicting attributes and have it be meaningfully processed, you need to answer these questions. Without that, we are back to a model of giving lots of data without the context in which to interpet it, and that is contrary to the very essence of what the data model is trying to say.
A compositor is in a position to resolve conflicting data across different documents (each document being self-consistent) because it HAS the context to do so - thats why its the compositor! You cannot just provide conflicting information to other watchers without giving them context to resolve the conflicts.
As for the person tuple, I think a simple policy like "the latest timestamp wins" will get you very far at least for information explicitly published by the user. If the user explicitly publishes information, he probably wants that information to be visible to watchers.
I think there are a lot of limitations to "latest timestamp".
This is one possible policy, but not necessarily ideal in circumstances where each publisher has pieces of the <person> information.
The data model does not specify the composition policy. It only suggests a default in absence of anything else.
We can spend eons debating the full breadth of what a composition policy should or could be, and we will - later. I don't think we need to figure all of that out to move forward on the data model and the privacy framework.
Paul
Automated publications are more complicated. For example, a calendar application that publishes <person> elements should not override the information the user explicitly has set. To solve this, some kind of source information may be necessary. The watcher should be able to see both the information published as well as the information published by the calendar. One shouldn't override the other. But that doesn't mean that they both can't publish person tuples. One could for example let the composed person tuple contain two text notes, one from the calendar and one from user.
I would rather have
<person source="calendar"> <e:mood>bored</e:mood> <e:activities> <e:activity>meeting</e:activity> </e:activities> <person>
<person sourceID="device17"> <e:mood>anxious</e:mood> <e:activities> <e:activity>on-the-phone</e:activity> </e:activities> </person>
That seems to reflect a "view" notion of the person, with each <person> representing one such view, better than collating all the items into one big bag of elements. That also makes it very easy for downstream elements to just ditch sources believed to be less reliable.
And what would make me decide that device17 is more or less reliable than the calendar??
-Jonathan R.
_______________________________________________ Simple mailing list Simple at ietf.org https://www1.ietf.org/mailman/listinfo/simple