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

Re: [Simple] Updated RPID

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 want to wander into modeling availability 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.

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.


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.



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.



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