Subject: [Simple] What are tuples?

From: [email-masked]
Date: Tue, 6 Jul 2004 06:48:08 -0400 (EDT)

Trying to pick up and maybe summarize aspects of the discussion. There may
be some items of general consensus:

- [HUMAN] There didn't to be much enthusiasm for a separate tuple type for
the human itself. Rather, there might be some use for shared information
that reflects the presentity as a whole (see below). In general, if
different tuples represent complementary rather than conflicting
information about a presentity, there doesn't seem much need for a human
abstraction.

One use for a "human" is the ability to indicate whether the person is
reachable by visiting. Rather than designating some pseudo-URI (goto:
:-)), it might be sufficient to have a URI-less tuple. Having a label
seems to just introduce another error condition (in-person type with a
URI).

Proposal: treat non-URI tuple as personal interaction.

- [SERVICE] There seems to some consensus that all tuples are essentially
services. There are different granularities of service announcement, e.g.,
by unifying several URIs behind one externally visible URI, with a proxy
doing the detail routing, but there doesn't seem to be a fundamental
difference between a URI representing one and one hiding several.

Proposal: drop tuple classification.

- [DEVICE] Some tuples will share characteristics. For example, all
devices carried on the belt of a single user will share the same location
to within a few inches, while others might share device characteristics
such as screen size. While the concept of 'device' is fairly clear for
many classical devices such as cell phones, laptops, desk phones and the
like, there are also an increasing number of pseudo-devices tied together
by some kind of personal area network (PAN) such as BlueTooth.

A single physical device might offer many different services, but it is
unclear to me as to why the watcher benefits from knowing this.

There has been some discussion on providing some labeling or grouping that
ties together tuples as being part of some notion of a device.

There are several possible motivations for such labeling or grouping. At
the lowest level, it simply avoids repeating common information such as
location, presumably to make notifications shorter. This might also allow
the watcher to infer characteristics across tuples, although I'm less
clear what safe assumptions on such inference might be.

Question: I'd like to hear more about motivations and use cases.

Proposal: Can we punt?

- [INHERITANCE] There was discussion on some way of inheriting information
from the presentity (by putting common information at the presentity
level) or from other tuples (by reference to a tupe identifier).

Proposal: allow inheritance of location, CIPID (already there) and maybe
activity at presentity level.

Open issue: do they need to be wrapped?

Henning

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 12 Jul 2004 17:47:18 -0400

inline.

[email-masked] wrote:

> that reflects the presentity as a whole (see below). 

I think we need to be careful to think of the "human" as being two very 
different things. One is the "presentity", which is a model for the 
state of the user, separate from any devices or services that they may 
use, which have presnce implications. Most of RPID covers this kind of 
data - "in-a-meeting", geographic location, etc.

Then there is "human" as a mode of communications - i.e., 
person-to-person talking. I think the latter is really a communications 
service, where the "devices" are vocal cords/ears, and the "network" is 
the air.

I think we need to model both of these, though I don't think 
person-to-person communications should be treated as special or 
different from other forms of communications services.

 >In general, if
 > information about a presentity, there doesn't seem much need for a >human
 > abstraction.

I think we absolutely need to have a concrete understanding of what a 
presence attribute is characterizing.

> seems to just introduce another error condition (in-person type with a

I don't think you want to have a special label that says, "this is a 
person to person communications". After all, for other services 
(telephony, PTT, IM, SMS, etc.) we seem to have settled on the idea that 
either the URI scheme describes the service, or where the scheme is 
ambigous, characteristic information tells you what it is.

I actually think that, if we had a URI scheme for this, it would be 
ideal. In the absence of one, omitting the contact URI is probably 
reasonable. However, I think its a mistake to *equate* lack of a contact 
URI with "person to person communications". I think this is overloading 
things. The only think lack of a URI means is that the presentity 
elected not to tell me the URI for this service. I don't think that 
application of a privacy policy, which might strip the URI, should 
fundamentally change the meaning of the service.

> Proposal: treat non-URI tuple as personal interaction.

Disagree.

In the context of the presence data model draft I mentioned in a 
separate note, that:

1. in-person communications is modeled as a service. Postal 
communications is similar, and also a service.

2. Like other communications service, the service is identified by the 
scheme along with service characteristics

3. We don't at this time, define either a scheme or service 
characteristics for person-to-person communications or postal services

4. down the road, we can work on a URI scheme for representing this kind 
of interactions

> difference between a URI representing one and one hiding several.

I think that the most important piece of information about a user is 
their set of services, and thus services are the first class citizens we 
need to model. I agree that a service advertised in a document could map 
to a lot of actual services, and that there is no difference, from a 
modeling perspective, between a URI that represents a UA instance and a 
URI that represents a proxy that can fork there.

However, I do think we have a notion of devices and of presentity that 
are separate from services.

> Proposal: drop tuple classification.

I think that the first step is to agree about the underlying data model. 
That is, forget about tuples and entities and XML - what is the 
underlying information we want to convey, and how does that information 
relate. Once we know that, determining whether we represent things with 
<tuple type="device"> or <device> or <tuple><tuple-type="device"> is an 
exercise in syntactic encodings, and nearly anything will do.

I think that we have definitely been talking about three fundamentally 
different pieces of data - services (representing the means of 
communications), devices (representing the underlying shared resource in 
which services are hosted) and presentity (the actual user, whose 
characteristics and status are independent of the services or devices 
they are using. i.e., it is the *user* thats in a meeting, its the 
*user* thats on a phone).

> by some kind of personal area network (PAN) such as BlueTooth.

I think thats OK. As long as the model allows for modeling of virtual 
devices, you can cover these cases. I don't think we need to impose on a 
presentity how it chooses to map physical reality into the model. We 
just need to be clear about what information the presence data is conveying.

> unclear to me as to why the watcher benefits from knowing this.

The think the watcher benefits because it provides what I think is 
useful information for the watcher to make a choice. For example, "oh, i 
know bob is travelling and has his cell phone with him, look at that, he 
has sms on his phone, i will send him an sms".

I also think that people tend to think about communications in terms of 
devices. People say, "call me on my cell", such that the device is the 
center point for choice and preference.

Also keep in mind that watchers are not the only consumers of presence 
documents. I think that the device information is incredibly useful for 
presence servers in the process of composition.

> location, presumably to make notifications shorter.

No, its not just a compression operation. Its to allow me to correlate 
information I learned about a device from one publisher, with a service 
that runs on that device as indicated by another publisher.

> This might also allow

Right.

> Question: I'd like to hear more about motivations and use cases.

The whole notion of device has been a constant factor in our "what is a 
tuple" discussions all along. Indeed, rpid talks about devices and says 
a lot about what kind of information is associated with a device vs. a 
service. Thus, I think we should trying and bring clarity to the 
definition rather than remove all notion of device from rpid.

> level) or from other tuples (by reference to a tupe identifier).

I think that inheritance is a bad idea. THe meanining of an attribute is 
tied to whether the attribute is about a device, service or presentity. 
"Idle", for example, means something entirely different in each case:

1. if a device is idle, like my PC, it means I have not accessed the 
device or any services on it for some time. This is the classic meaning 
of idle in todays IM systems

2. if a a service is idle, like my IM client, it means I havent used the 
service (i.e., havent sent/receive an IM) for some time

3. if a person is idle, it means that they are bored and not doing anything

Inheritance makes sense only when there is a is-a relationship between 
the thing that is inhertiting and the thing that is the source of the 
inheritance. Since services and devices and presentities are not the 
same thing, I dont think we should be inheriting amongst them.

I think that, the fewer places an attribute can appear (being associated 
with a service, device or tuple), the less confusion there is about what 
that attribute means. When it does appear in multiple places, it should 
be because it is truly meaningful for a devices, presentities and 
services. For example, location is meaningful for a device and for a 
presentity.

-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: Henning Schulzrinne <[email-masked]>
Date: Sat, 17 Jul 2004 14:03:24 -0400

[HUMAN]

> service, where the "devices" are vocal cords/ears, and the "network" is 

That's what I was referring to here.

> *user* thats on a phone).

I agree that services and presentity have a clear "has many" 
relationship. I still don't see devices as usefully distinct.

> has sms on his phone, i will send him an sms".

No different than a service.

> center point for choice and preference.

People buy cell phone service to be reached. The device is a necessary, 
but not particularly interesting, implementation detail. This will 
become more obvious as we start separating numbers from individual 
pieces of plastic.

> presence servers in the process of composition.

I disagree.

> definition rather than remove all notion of device from rpid.

The more I try, the less clear devices become :-)

> of idle in todays IM systems

Not really true. If I watch a video on my PC or have it cycle through a 
set of PPT slides, the IM will show "idle", although the PC is doing its 
job and I'm watching it. In practice, it seems to mean "haven't touched 
the mouse or keyboard"...

> services. For example, location is meaningful for a device and for a 

It is also useful for a human, for example (which is not the same as the 
presentity). Is the "human:" URI a service or a device?

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 19 Jul 2004 09:44:33 -0400

inline.

Henning Schulzrinne wrote:

>> useful information for the watcher to make a choice. For example, "oh, 
>> i know bob is travelling and has his cell phone with him, look at 
>> that, he has sms on his phone, i will send him an sms".
> 
> 

What is no different than a service?

> 
>>
>> I also think that people tend to think about communications in terms 
>> of devices. People say, "call me on my cell", such that the device is 
>> the center point for choice and preference.
> 
> 

I think we want solutions which model the concepts of interest that 
exist today. I don't see how one can deny that a "cell phone" doesnt 
exist or is meaningless as a concept in communications systems?

>> documents. I think that the device information is incredibly useful 
>> for presence servers in the process of composition.
> 
> 
> I disagree.

Henning, I have given several examples of how the device identity is an 
extremely useful correlator. Can you please explain why you disagree 
with each of those cases? Its hard to rebut against "I disagree".

>> device or any services on it for some time. This is the classic 
>> meaning of idle in todays IM systems
> 
> 

Thats fine. We can define "idle" for a device as not having touched the 
input sources of that device (keyboard, mouse). There is still clearly 
an "idle" for the device and an "idle" for the service that are distinct.

> 
>>
>> 2. if a a service is idle, like my IM client, it means I havent used 
>> the service (i.e., havent sent/receive an IM) for some time
>>
>> I think that, the fewer places an attribute can appear (being 
>> associated with a service, device or tuple), the less confusion there 
>> is about what that attribute means. When it does appear in multiple 
>> places, it should be because it is truly meaningful for a devices, 
>> presentities and services. For example, location is meaningful for a 
>> device and for a presentity.
> 
> 

In the presence data model I have suggested, the "presentity" models the 
human, and so location is a characteristic of the presentity.

-Jonathan R.