Subject: [Simple] RPID: what does tuple-type really mean?

From: Aki Niemi <[email-masked]>
Date: Wed, 19 May 2004 19:23:09 +0300

Hi,

I have a really hard time understanding what different tuple-types mean, 
and how they are intended to be consumed by watchers. Say you have two 
tuples, each with a mailto URI and one that has a "device" type and 
another that has a "service" type - what is that supposed to mean?

Further more, aren't all tuples meant to describe the presentity, and if 
so, why do we need the "presentity" type at all? Isn't that the default 
type?

Same for "in-person" - what does an "in-person" tuple with a SIP contact 
mean? Are we to write each other SIP messages face-to-face with pen and 
paper? ;-)

Cheers,
Aki

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

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 19 May 2004 15:42:28 -0400

Aki Niemi wrote:
> and how they are intended to be consumed by watchers.

Me too. When it comes to consuming them, I can't see anything I would do 
differently according to tuple type.

 > Say you have two

I think it means somebody is confused. :-)

I too have problems with where to put a mailto: uri. I don't think it 
belongs in a device tuple, because I can't figure out how it is a device.

It could be in a presentity tuple, if it is descriptive of the 
presentity. But I suppose it could be in a service tuple, because I 
guess mail is a service the way people seem to talk about them.

> so, why do we need the "presentity" type at all? Isn't that the default 

I don't think there is a default. I think "presentity" is a way of 
telling the watcher "I'm not giving you device info".

> mean? Are we to write each other SIP messages face-to-face with pen and 

AFAIK in-person and a contact address are mutually exclusive. I once 
suggested (in gest) an in-person uri. That would solve the problem.

The tuple-type is there to resolve differences in world view by the 
contributors about how presence should be used. But because it doesn't 
seem to alter how you would interpret the document, I think its only 
practical effect is to make people feel better. (Or confused.)

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 19 May 2004 15:42:28 -0400

Paul

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 20 May 2004 15:06:43 -0400

Paul Kyzivat wrote:

> 
> 
> Aki Niemi wrote:
> 
>> Hi,
>>
>> I have a really hard time understanding what different tuple-types 
>> mean, and how they are intended to be consumed by watchers.
> 
> 

I think they're valuable in several cases:

(1) in rendering information to the user, to give a sense of what the 
tuple is representing,

(2) for consumption by automata, to determine if "this is the thing I 
want". For example, if I write an application that is interested in 
finding out whether or not you are available for a PTT call, then the 
application would look for a service tuple, and look for the appropriate 
attributes which identify PTT (namely, voice and half duplex 
communications).

> guess mail is a service the way people seem to talk about them.

Right, I think it only makes sense for service views.

> 
>> Further more, aren't all tuples meant to describe the presentity, and 
>> if so, why do we need the "presentity" type at all? Isn't that the 
>> default type?
> 
> 

Right - its for the case when there is a single tuple that talks about 
your availability as a union of the ways you can be contacted. It 
represents the model Brian Rosen had been advocating.

> 
>> Same for "in-person" - what does an "in-person" tuple with a SIP 
>> contact mean? Are we to write each other SIP messages face-to-face 
>> with pen and paper? ;-)
> 
> 

I still think its quite useful. But, clearly we're still not there yet 
in the "whats a tuple" morass.

I think that "service" is what most people would think of when they see 
a tuple - it represetns a means for communications, whether its 
telephony, PTT, MMS, SMS, email. In most cases the URI scheme says what 
the service is. For cases like SIP, attributes help qualify it. A 
specific service could span multiple devices.

The "device" view would have a tuple for my cell phone, a tuple for my 
PC, and a tuple for my desktop phone. In some cases (like my desktop 
phone), there is a single service (telephony). For others, there are 
multiple (I can get sms, mms and voice on my cell phone). I would 
therefore think that a device view would have a contact which, as best 
as it can, identifies the device (the phone number is a device 
identifier, for example), and there would be attributes that make sense 
primarily for devices - things like location, idle. I think it would 
make sense to have a "service" field which says what services can be had 
on that device - mms, sms, telephony, for example, but no doubt that is 
a big can of worms. The basic status would indicate available across all 
services on that device. For a single service device, like a phone, its 
"closed" if its unplugged or in a call. For a cell phone, the status is 
"closed" when the phone is off, meaning that all services accessible 
through that device, like SMS, MMS and telephony, wouldn't reach that 
device.

The "presentity" type of tuple talks about the user generally. Many 
pieces of status, such as activity, placetype, location, privacy, 
relationship and sphere primarily describe the presentity, as opposed to 
a particular device (such as a cell phone) or a service (like MMS). As 
such, the idea is that you would have a tuple that represents the 
presentity overall, which would be the ideal place for such attributes. 
Indeed, if you think about it, it doesn't really make sense for such 
things to be associated with a tuple that represents anything but the 
presentity.

The "in-person" type of tuple talks about communications with a user the 
old fashioned way - an actual face to face conversation. A tuple 
representing a person can have attributes like location, privacy, 
sphere. The contact URI is meaningless. In one sense, "in-person" is a 
service, in that it represents a modality for communications. In another 
sense, its a device, in that there is a single physical instantiation of 
it (human cloning aside ;) ).

Having a clear definition of the type also assists in converstions from 
one view to the other. Lets say I want to compute a service view for PTT 
from a device view. I'd like to know which device tuples provide the PTT 
service, so I can combine them, using for exmaple Henning's pivoting 
operations. Indeed, one can think of the "service" as identifying a 
particular axis for pivot operations. It also helps solve the 
*correlation* problem, which is, when I do compose tuples, I need to 
understand how they relate to each other. I suspect that more work is 
needed to properly do that, but understanding what the tuple represents 
seems like a key first step.

-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: Jonathan Rosenberg <[email-masked]>
Date: Thu, 20 May 2004 15:06:43 -0400

-Jonathan R.

---

From: Aki Niemi <[email-masked]>
Date: Fri, 21 May 2004 12:06:39 +0300

Inline.

Jonathan Rosenberg wrote:
-snip-
> (1) in rendering information to the user, to give a sense of what the 

I agree with this, and to formalize I think we have exactly six cases of 
tuple-types to consider:

1) no <tuple-type>
2) <tuple-type>presentity</tuple-type>
3) <tuple-type>service</tuple-type>
4) <tuple-type>device</tuple-type>
5) <tuple-type>in-person</tuple-type>
6) <tuple-type> has an unknown value

Now, given a random tuple X, for each of 1-5 there seems to be very 
little I can deduce from the <tuple-type> alone. (I'm assuming an 
implementation SHOULD treat 6) and 1) alike.) To be able to render X 
differently in each case, I would need to look at the <contact> at 
least, and rely on other rules, e.g., that an in-person tuple has no 
contact.

However, the problem I see is that those rules are not specified, and we 
seem to have different views of what they are. For example, should a 
device tuple have a GRUU (or a contact address with a similöar property) 
in it?

Also, certain things, like indicating that a tuple describes the status 
of the presentity, and not any specific communications mean could 
equally well be indicated using a contact-less tuple, instead of using 
presentity/in-person types.

That would leave us with having to tell apart a service tuple and a 
device tuple. Personally, I have trouble seeing what else is different 
in such tuples than the <tuple-type> element... (more below).

> attributes which identify PTT (namely, voice and half duplex 

A device can't have PTT? What if there's no <tuple-type> at all? Seems 
that at least in this case, availability for PTT and type of tuple are 
orthogonal properties.

-snip-
> represents the model Brian Rosen had been advocating.

Hmm... To accomplish this, why not simply take the union of all statuses 
that the tuples have?

I think the 3GPP are using the "presentity" tuple explicitly to state 
the status of the presentity (irrespective of any particular 
communication means). Seems like these usages are similar but not 
identical...

> specific service could span multiple devices.

Agreed.

> through that device, like SMS, MMS and telephony, wouldn't reach that 

Perhaps there is an intersection between these views that we haven't 
considered yet. What if all tuples (that have a contact address) are by 
definition representing "services". To be able to indicate such services 
reside on the same physical device, we would define an element that 
gives a unique identifier to that device.

Example:

<presence>
   <tuple id="hki23u"
     <status>
       <basic>OPEN</basic>
     </status>
     <device-id>bjksdf87489</device-id>
     <idle />
     <contact>tel:+1274998479</contact>
   </tuple>
   <tuple id="7834hhf"
     <status>
       <basic>OPEN</basic>
     </status>
     <device-id>bjksdf87489</device-id>
     <idle />
     <contact>smsto:+1274998479</contact>
   </tuple>
</presence>

With this, you get everything you need, and the main advantage is that 
this representation is compatible with both the "device" interpretation 
and the "service" interpretation - a service-view would discard the 
device-id element and treat these as separate services. The device-view 
would take the device-id, and use it to group device-specific 
information together. The device-id could be used in the pivoting as well.

After all, a user might have multiple devices, each offering multiple 
services (which might not all be representable using a single contact 
address). This would allow distinguishing different devices as well.

> it (human cloning aside ;) ).

Actually, "in-person" and "presentity" seem pretty similar to me. For 
each one, the contact address seems meaningless, and the attributes you 
put in each one would be interpreted the same way, i.e., representing 
the presentity (be it a person or something else, like a vending machine 
all call-center).

> seems like a key first step.

I'm not sure I completely agree with the "view" methodology any more. 
Seems we have several things that we want to represent using tuples:

a) attributes representing the presentity, and not any particular 
communication channel

b) attributes representing a specific device, and communication channel 
in that device

c) attributes representing a specific service not necessarily related to 
a single device

I think <tuple-type> is a way to do all of the above, but IMHO the 
current definition leaves too much room to different interpretation. I 
think we should look at each one separately, and try to specifically 
tailor for that. For example, specify that:

i) a tuple without a contact address indicates a);

ii) a <device-id> element identifies a specific device that the tuple is 
associated, fulfilling b);

iii) by default, a tuple represents a service, i.e., a tuple in the 
absence of either i) or ii) indicates c).

How does this sound?

Cheers,
AKi

---

From: Aki Niemi <[email-masked]>
Date: Fri, 21 May 2004 12:06:39 +0300

Inline.

1) no <tuple-type>

-snip-

Agreed.

Example:

<presence>
   <tuple id="hki23u"
     <status>
       <basic>OPEN</basic>
     </status>

How does this sound?

Cheers,
AKi

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 23 May 2004 18:41:29 -0400

inline.

> 6) <tuple-type> has an unknown value

Sounds right.

> least, and rely on other rules, e.g., that an in-person tuple has no 

I think that tuple type would tell you where else you need to look. For 
example, if the tupe-type is service, you would start to look for the 
various characteristics that define the services you know how to render 
an icon for. If its a device, you might look for information to help you 
decide what the device is.

> device tuple have a GRUU (or a contact address with a similöar property) 

I agree that, if we really want to model a device with a tuple, the 
meaning of the URI is really unclear. For example, with a cell phone 
that has MMS, SMS, traditional telephony and an IP-based PTT service, 
there isn't a single URI one can provide that tells you how to contact 
the device. The actual URI scheme would depend on the service you are 
trying to reach.

As such, for a device, I thin the contact URI should be something that 
is more of an identification function, from which one can deduce or 
otherwise discover URIs for particular services. In particular, I would 
imagine you'd want a URN of some sort, that you can look up (for example 
using ENUM) to find the service you want. In the case of a cell phone, I 
think the tel URI is the closest thing we've got. For a PC, to be 
honest, I have no idea what you'd put in there. If I have a PC with 
SIP-based VoIP, video, and IM, along with email, and jabber, AOL and 
Jabber based IM, there isn't a single URI that makes sense.

We could include a URN like a UUID which does uniquely identify the PC, 
but thats not terribly useful for actually contacting it.

A different way to think about it is that, instead of trying to use 
tuples to model a device directly, we always have a tuple for each 
service. We can have some kind of device ID attribute that describes the 
device(s) that a service is available on. These device IDs could be used 
to correlated service availability across tuples. So, for example, if I 
have SIP-based voip and telephony on the same physical device, I could 
have two tuples, the first with a SIP URI and the second with a tel URI, 
and both would have a <device> element that has the same device identifier.

> presentity/in-person types.

Yes, that could work too. We could also include it outside of any 
specific tuple at all, as a direct child of <presence>.

A key question is - to we want/need to clearly differentiate between 
presence attributes that apply to a service tuple vs. a presentity 
tuple? Henning has indicated whether each attribute makes sense for each 
type of tuple. I mostly agree with whats there, but not all of it. 
Here's my view of the current set:

<activity> only makes sense for a presentity. The current draft says 
that it makes sense for device or service tuples, but I don't see what 
that means.

<class> is a tool used for auth permissions more than anything else. 
right now, its the main way to give different information to different 
watchers. Indeed, if we want to be able to give out different 
presentity-level information to different watchers, we really want to 
use class to do that, and this would argue for keeping presentity 
information in a tuple, so we can use class with it.

<idle> makes sense mostly for a device, and not so much for a service, 
not at all for a presentity

<placetype> mostly makes sense for a presentity; if could make sense for 
a device (if my devices are places where I am not), not really much 
sense for a service

<privacy> makes sense for a service, and could differ from service to 
service even on the same device (for example, on a PC, I could have 
headsets on, so a voice conversation can't be heard, but IM can be seen 
by people watching my screen)

<relationship> only makes sense for a presentity

<sphere> only makes sense for a presentity, though the current draft 
allows it anywhere.

> in such tuples than the <tuple-type> element... (more below).

I think they're very different.

>> application would look for a service tuple, and look for the 
>> appropriate attributes which identify PTT (namely, voice and half 
>> duplex communications).
> 
> 

A device has PTT because a device can offer multiple services, and I can 
have a PTT service. If you identify a tuple as a "device" and indicate 
that it has PTT, IMHO you are merely expressing a short hand for the 
fact that this device has a specific service.

> 
> -snip-
> 
>>>> Further more, aren't all tuples meant to describe the presentity, 
>>>> and if so, why do we need the "presentity" type at all? Isn't that 
>>>> the default type?
>>>
>>>
>>>
>>>

True. Another way to think about it is that I can have a presentity that 
I model as having a single "communications" service (thus two tuples - 
one for the presentity, one for their communications service). Whether 
the status for that communications service is a union of the statuses 
for the actual underlying service, is a matter of local policy, and thus 
normally something you'd want to compute on the presence server. Plus, 
you may want to hide any particular service.

>>> contributors about how presence should be used. But because it 
>>> doesn't seem to alter how you would interpret the document, I think 
>>> its only practical effect is to make people feel better. (Or confused.)
>>
>>
>>
>> I think that "service" is what most people would think of when they 
>> see a tuple - it represetns a means for communications, whether its 
>> telephony, PTT, MMS, SMS, email. In most cases the URI scheme says 
>> what the service is. For cases like SIP, attributes help qualify it. A 
>> identifier, for example), and there would be attributes that make 
>> sense primarily for devices - things like location, idle. I think it 
>> would make sense to have a "service" field which says what services 
>> can be had on that device - mms, sms, telephony, for example, but no 
>> doubt that is a big can of worms. The basic status would indicate 
>> available across all services on that device. For a single service 
>> device, like a phone, its "closed" if its unplugged or in a call. For 
>> a cell phone, the status is "closed" when the phone is off, meaning 
>> that all services accessible through that device, like SMS, MMS and 
>> telephony, wouldn't reach that device.
> 
> 

Heh - I suggest the same above, before having read this part of the 
note.. perhaps we are gettign somewhere!

> information together. The device-id could be used in the pivoting as well.

Right, exactly.

> address). This would allow distinguishing different devices as well.

Yes. Indeed, I would take it a step further, and make device a proper 
element with the id as only one parameter. Other things I can indicate 
would be:

* device-type: PC, cell-phone, PDA, etc. (lines blurry I know!)
* device characteristics - indeed, one might argue that some of the 
callee-caps parameters are more of a device characteristic, others are 
service characteristics. For example, "mobility" is clearly a device 
characteristic, but "audio" is a service one. There are lots of 
potential device characteristics - screen sizes, battery power remaining 
(that might be cool to indicate to someone, to let them know that I 
can't talk long since I only have a little power left

So, lets take a relatively complicated case. I have a cell phone and a 
PC. My cell phone supports telephony, SIP-based voip, and SMS. My PC 
also supports SIP-based voip and IM. The SIP service is the same on both 
devices, that is, they share an AOR. Using service tuples and a new 
device parameter:

<presence>

   <tuple id="1">
     <status>
       <basic>open</basic>
     </status>
     <device anchor="A">
       <type>cell-phone</type>
       <id>tel:+17325551212</id>
     </device>
     <contact>tel:+17325551212</contact>
   </tuple>

   <tuple id="2">
     <status>
       <basic>open</basic>
     </status>
     <device ref="A">
     <contact>sip:[email-masked]</contact>
   </tuple>

   <tuple id="3">
     <status>
       <basic>open</basic>
     </status>
     <device ref="A">
     <contact>mms:+17325551212</contact>
   </tuple>

   <tuple id="4">
     <status>
       <basic>open</basic>
     </status>
     <device anchor="B">
       <id>SOME_KIND_OF_ID_HERE</id>
       <type>PC</type>
     </device>
     <contact>sip:[email-masked]</contact>
     <!-- CIPID information to say that this is voip -->
   </tuple>

  <tuple id="4">
     <status>
       <basic>open</basic>
     </status>
     <device ref="B"/>
     <contact>sip:[email-masked]</contact>
     <!-- CIPID information to say that this is IM -->
   </tuple>

  </presence>

I've added an anchor/reference feature which allows you to define the 
device once, and from there on, refer back to it for tuples on the other 
voice.

I think this adds a lot of clarity, and as you point out, allows for 
pivot operations which would allow us to render information that shows 
devices and the services within them.

>> relationship and sphere primarily describe the presentity, as opposed 
>> to a particular device (such as a cell phone) or a service (like MMS). 
>> As such, the idea is that you would have a tuple that represents the 
>> presentity overall, which would be the ideal place for such 
>> attributes. Indeed, if you think about it, it doesn't really make 
>> sense for such things to be associated with a tuple that represents 
>> anything but the presentity.
>>
>> The "in-person" type of tuple talks about communications with a user 
>> the old fashioned way - an actual face to face conversation. A tuple 
>> service, in that it represents a modality for communications. In 
>> another sense, its a device, in that there is a single physical 
>> instantiation of it (human cloning aside ;) ).
> 
> 

I agree its hard to see the difference.

> 
>> Having a clear definition of the type also assists in converstions 
>> from one view to the other. Lets say I want to compute a service view 
>> for PTT from a device view. I'd like to know which device tuples 
>> provide the PTT service, so I can combine them, using for exmaple 
>> Henning's pivoting operations. Indeed, one can think of the "service" 
>> as identifying a particular axis for pivot operations. It also helps 
>> solve the *correlation* problem, which is, when I do compose tuples, I 
>> need to understand how they relate to each other. I suspect that more 
>> work is needed to properly do that, but understanding what the tuple 
>> represents seems like a key first step.
> 
> 

I agree more clarity is needed; not clear that belongs in RPID per se. 
To date we've been trying to work rpid without having quite finalized 
the "whats a tuple" debate.

> absence of either i) or ii) indicates c).

With my modification above on defining a device element instead of just 
device-id, I think that sounds pretty good.

We should discuss this at the interim, though I don't think there is any 
time for this topic allocated...

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 23 May 2004 18:41:29 -0400

inline.

Sounds right.

Right, exactly.

<presence>

   <tuple id="1">
     <status>
       <basic>open</basic>
     </status>
     <device anchor="A">
       <type>cell-phone</type>

   <tuple id="2">
     <status>
       <basic>open</basic>
     </status>
     <device ref="A">

   <tuple id="3">
     <status>
       <basic>open</basic>
     </status>
     <device ref="A">

   <tuple id="4">
     <status>
       <basic>open</basic>
     </status>
     <device anchor="B">

  <tuple id="4">
     <status>
       <basic>open</basic>
     </status>
     <device ref="B"/>

  </presence>

-Jonathan R.

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 24 May 2004 17:28:00 -0400

> that it makes sense for device or service tuples, but I don't see what 

If a tuple (representing a device or whatever) has a sensor that 
determines the current activity, it can be tuple-specific.

> not at all for a presentity

It may make sense if it is a composed quantity, e.g., the minimum 
idleness across all devices.

> a device (if my devices are places where I am not), not really much 

Same composition argument applies.

> <sphere> only makes sense for a presentity, though the current draft 

Same sensor issue - my office phone might report its sphere as 'work', 
while my home phone reports it as 'home'.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 24 May 2004 22:26:50 -0400

Henning Schulzrinne wrote:
>> tuple? Henning has indicated whether each attribute makes sense for 
>> each type of tuple. I mostly agree with whats there, but not all of 
>> it. Here's my view of the current set:
>>

The argument I made today in the interim was this. From a modeling 
perspective, activity really is something that describes the presentity. 
What you are talking about above is that, it may be that the way we 
determine this state is from the devices a user has. There might be a 
desire to indicate to the watcher the specific device on which the 
observation was made, so that they can make a determination about 
trustworthiness or accuracy of the data. Of course, there are other 
metrics one might use to determine accuracy or trustworthiness, which 
have nothing to do with the device on which the observation was made. 
For example, I might use information on how recently the state was 
determined.

Thus, I would prefer it strictly be used to describe a presentity, and 
if there was a desire to indicate some information to help a watcher 
determine the accuracy of the data, that be done through some kind of 
extension to the activity element (which we could define later).

-Jonathan R.

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 24 May 2004 22:58:33 -0400

Nice in principle, problematic in a world where devices publish. Listing 
all the different activities in one place and annotating them with the 
source is likely to be more complicated without being more illuminating. 
(Plus, it makes composition, filtering and privacy rules more 
complicated.) You would have to pull out essentially all the location 
elements as well, which are currently in tuples. In any event, with the 
model that we discussed today (contact-less tuple describes presentity), 
we can easily support both approaches, depending on whether the 
presentity has the ability to do annotation or whether it is really just 
re-publishing contributions by various presence sources.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 26 May 2004 01:08:06 -0400

> source is likely to be more complicated without being more illuminating. 

I think it could be useful as a tool for accuracy. In any case, my point 
is, that I think that the simplest and most useful thing for the present 
would be for the compositor to extract the data from wherever it was 
published, and in the notifications, include a single value for it in 
the tuple representing the presentity.

> elements as well, which are currently in tuples. 

Location makes sense for a device, but doesn't for a "service". As such, 
it wouldn't be in tuples with contacts, only in the presentity tuple, yes.

In any event, with the
> re-publishing contributions by various presence sources.

I'm concerned that allowing the information in either place is going to 
continue to lead to the confusion we have today.

-Jonathan R.

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 26 May 2004 08:23:05 -0400

> the tuple representing the presentity.

I'm not sure that this is always possible. If I have two device tuples 
with location sensors, one for my home PC and one for my cellphone, how 
is the compositor to know which one is currently correct?

> it wouldn't be in tuples with contacts, only in the presentity tuple, yes.

Maybe still terminology confusion: Why can't a device tuple have a contact?

> continue to lead to the confusion we have today.

Not allowing it in both contact and contact-less tuples doesn't allow me 
to represent the ambiguity that naturally exists to the watcher and 
assumes a very smart compositor that we don't have today.

(As a minor issue, tuples with <relationship> would need their own 
RPID-style and location information in any event, even though they have 
a contact.)

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 27 May 2004 20:31:40 -0400

Jonathan,

I'm having misgivings about this change now. Devices have somehow become 
2nd class citizens. Representing location information now becomes 
incredibly complicated. Either you have to replicate it in each service 
that shares the device, or as you suggested to me, you put it in one 
service tuple and cross reference it from others. But the latter makes a 
mess of filtering - what if I filter out the tuple that holds the device 
attributes and keep the one that cross references them?

You say that a device has an address, a service doesn't. But from a 
practical perspective, a service that is hosted on only one device has a 
location too - it is only distributed services that don't have well 
defined locations.

If you want to make this kind of distinction, then I think we must still 
have both device and service tuples, with cross references between them. 
And while we are at it, it would then be convenient to permit a single 
tuple to represent both when they are 1:1. Then, service tuples would 
have contacts while device tuples wouldn't. And a device tuple would 
have a location while a service tuple doesn't. But a device with only 
one service can be represented with a combined tuple that both a contact 
and a location.

	Paul

Henning Schulzrinne wrote:
>> I think it could be useful as a tool for accuracy. In any case, my 
>> point is, that I think that the simplest and most useful thing for the 
>> present would be for the compositor to extract the data from wherever 
>> it was published, and in the notifications, include a single value for 
>> it in the tuple representing the presentity.
> 
> 
>> Location makes sense for a device, but doesn't for a "service". As 
>> such, it wouldn't be in tuples with contacts, only in the presentity 
>> tuple, yes.
> 
> 
>> I'm concerned that allowing the information in either place is going 
>> to continue to lead to the confusion we have today.
> 
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 27 May 2004 22:13:36 -0400

We had a related debate in other contexts before (rules?), about 
referencing XML entities from elsewhere. Generally, this seems to get 
messy quickly. I don't see what's wrong with the simple model:

(1) contact-less tuple represents the presentity (my best guess what the 
presentity as a person is doing)
(2) contact-equipped tuples can be either devices (which also is an 
instance of a service) or services (hiding several similar devices 
behind one URI), with a <device> label if that is helpful

Both (1) and (2) can contain RPID and CIPID information (the latter 
probably only for <relationship> tuples). If (2) contains RPID 
information, it means that it refers to the device or service. 
Naturally, for services representing multiple devices, it may not be 
possible to present a single piece of information, but this is just the 
standard combining operation at work. For example, my audio service can 
indicate an idle time of 10 minutes, measured across my desk and cell 
phone, while my video service can indicate a longer idle time if I 
haven't used it for a while.

This seems to fit our rules and filtering model well enough.

What am I missing?

Paul Kyzivat wrote:

>>> point is, that I think that the simplest and most useful thing for 
>>> the present would be for the compositor to extract the data from 
>>> wherever it was published, and in the notifications, include a single 
>>> value for it in the tuple representing the presentity.
>>
>>
>>
>> with location sensors, one for my home PC and one for my cellphone, 
>> how is the compositor to know which one is currently correct?
>>
>>
>>>
>>>
>>>> complicated.) You would have to pull out essentially all the 
>>>> location elements as well, which are currently in tuples. 
>>>
>>>
>>>
>>>
>> Not allowing it in both contact and contact-less tuples doesn't allow 
>> me to represent the ambiguity that naturally exists to the watcher and 
>> RPID-style and location information in any event, even though they 
>> have a contact.)
>>
>>>
>>> -Jonathan R.
>>
>>
>>