Subject: RE: [Simple] Updated RPID

From: "Dag Ekengren" <[email-masked]>
Date: Tue, 12 Oct 2004 09:50:51 +0200

Henning Schulzrinne wrote:

>This is different. It simply includes the data with the source tuple
>that generated it.

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?

Let's say I would like to have a text note that describes the person and
another text note that describes the service. It feels natural to put
this information in two different elements because it is describing to
different entities.

I think it will be confusing to put the activity "busy" on a service
tuple if I mean that the person is "busy". One could say that the
activity element only applies to the person, and in the same way for
each element define if it applies to the person or to the service. But I
think that is more confusing than including the attribute in the element
to which it applies.

>This is no more complicated than the alternative
>approach, and in the absence of a defined composition operation, almost
>unavoidable. In practice, with all existing and plausible near-term
>composition operations (which will be effectively some form of union or
>concatenation), this will occur whether we allow for this or not. 

If the data is separated so that the presence document clearly describes
to which entities the data applies, presence composition will be easier.

If the service tuple actually describes the service, then composition of
the service tuples can be done quite easily. With the usage of GRUU:s
the service tuples will have different contact uri:s and composition is
a matter of including all the tuples.

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.

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.

/Dag

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 12 Oct 2004 17:05:52 -0400

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

> information, he probably wants that information to be visible to

This is one possible policy, but not necessarily ideal in circumstances 
where each publisher has pieces of the <person> information.

> the composed person tuple contain two text notes, one from the calendar

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.

---

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

inline.

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

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

> 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
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 13 Oct 2004 11:29:12 -0400

Jonathan Rosenberg wrote:
>> 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.
> 
> 
> modeled by presence.

I don't think anyone is disputing this.

 > I don't want to wander into modeling availability

Yup.

> context to resolve the conflicts.

It may be in a position to do it, but it may well not be capable of 
understanding or carrying out a suffiently complete policy to do so.

Given the choice between seeing the output of applying a naive policy, 
or seeing the raw data, even without all the context, I would prefer the 
raw data.

>>> information, he probably wants that information to be visible to

I don't know what "explicitly published by the user" means. I need to 
use applications as intermediaries in order to publish.

I am expecting that the presence client on my PC may have a dropdown 
list box where I can pick "in meeting". Then I would expect it to 
publish my activity as in-meeting.

I also expect that my phone, when I go off-hook, may also publish that 
my activity is "on-the-phone".

So, perhaps my activity had been in-meeting, and then was overridden to 
on-the-phone. What happens when I get off the phone? My phone 
republishes, but doesn't report my activity at all, since it no longer 
knows what it is. Does my activity revert to in-meeting, even though it 
hasn't been republished? What if it is republished?

Suppose I then go home and use a different PC to publish a new activity 
status with the intent to override what my office PC is saying?

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

Agreed. But I think we have different visions about what the minimal, 
default composition policy is. We need to ensure that something halfway 
reasonable results from that.

	Paul

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

---

From: Alex Audu <[email-masked]>
Date: Wed, 13 Oct 2004 17:15:46 -0500

What worries me is how many conflicting views can  be pushed to the 
watcher at a
time before we start running into serious perfromance 
problems,..especially in
bandwidth-sensitive environments?  What if  the presentity has 10,..20 
devices
publishing conflicting data?

Another thing I am not sure we have given enough thoughts to is the 
notion of
containment  relationship.  If a device A is contained in device B and B 
publishes
that it is unavailable, then what is the status of A? 

Regards,
Alex.

Jonathan Rosenberg wrote:

> 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 
> 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.
>
> 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.
>
> you to reconcile it. I think we should stick to a basic model with 
> basic features.
>
> 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 
> 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.
>
>
>
>
>
>>
>>
>>
> 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.
>
>>
>>>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 13 Oct 2004 19:07:13 -0400

> publishing conflicting data?

If you have 10 or 20 conflicting views being published, and if you can't 
afford to hear about all of them, then you *need* a composition 
algorithm that yields the result you want to see.

Until we have that maybe you should limit the number of publishers.

Or of course you can create a proprietary composition algorithm if you 
know how.

	Paul