Subject: RE: [Simple] Tuple references and device coupling

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 2 Apr 2003 09:35:17 -0500

>  > If your watcher registers at my presence service, I'm going to
>  > send you ONE tuple, with ONE URI that tells you how available
>  > I am for voice, video and IM.  What is your watcher going to do?
>  > 
>  > If your presence service delivers my watcher a dozen tuples,
>  > each describing presence for one service on one device, how is
>  > my watcher supposed to figure out the relationships?
> 
> By device, do you mean that each one has a unique contact 
> address, some other unique identifier, or a specific device 
> type (phone, mobile, PDA)?
Yes

> 
> Also, can you elaborate a little bit on what the relationship 
> beyond belonging to the same presentity we need for those tuples?
It seems that some want to know either all the service on one device
or all the devices on one service.

> 
>  > Worse, if you as a user have six service providers each of which
>  > provide a few of these tuples, what do you suppose the chances
>  > that my watcher can provide a coherent display of your 
> presence are?
> 
> Isn't it just as likely for a user to be a principal of 
> several presentities, each provided by a different service 
> provider? In that case the chances are no better or worse.
If we make PDIF/RPIDS straightforward enough, then a compositor
can aggregate, and a watcher can produce a coherent picture of
the user.  If we have a zillion different ways of representing
the information, then there is no such hope.  Right now,
without more definition and more linkages, I think there is no
way to do that.  I'm already worried about Jonathan's URI
per device (actually I think he wants URI per service per device)
and my single URI being tough to reconcile between implementations.  
This adds yet more ways to have implementations non-interoperable.  
Just the one multiple device per service vs. multiple services per 
device is enough confusion.  Both clearly will occur.  The question 
is how to represent it so the relationships are obvious.

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

---

From: Ben Campbell <[email-masked]>
Date: 02 Apr 2003 16:09:23 -0600

> is how to represent it so the relationships are obvious.

I think you _can_ make this interoperable without too much difficulty.
Say your (that is, Brian's) service returns a single tuple, with a
single contact URI. That tuple is valid for IM (among other things.). If
I want to IM you, I send an IM to the contact in the tuple. Presumably
your SIP routing mesh takes care of getting it to the right place.

 Jonathan's service returns a bunch of IM tuples, each one with a
different URI. Lets further assume, for the sake of example, that each
of these URIs represents a device contact for some device of his. I can
send an IM directly to that device without going through a proxy.

Now, lets assume _my_ watcher simply expects one _or_more_ tuples for
IM. It doesn't have any idea whether a given tuple represents a single
device, or a SIP proxy, or whatever. The only important thing is it can
assume that for an open IM tuple, it has a high chance of being able to
get an IM to the target user by sending it to the contact URI. It
_could_ present multiple choices to me, or it could simply tell me that
both Brian and Jonathan are available via IM, and automatically choose
the best tuple to use. If there is only one such tuple, that choice is
trivial. If there is a bunch of tuples, then it can pick the best one
based on some sense of "most present", explicit priority values, or some
local policy applied to the RPIDS attributes.

So, here I think I am proposing that a tuple represents a set of
availability and communication type attributes _associated_with_a_URI_.
Whether that URI represents a service, or a device, or whatever is not
relevant to the watcher.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 02 Apr 2003 19:59:14 -0500

I think I am on the same page with Ben.

Frankly I am mystified about what a "service" is. From the examples I 
see people using, it must be something like a medium, such as "voice", 
or IM.

But representing things this way causes trouble when a single device can 
support more than one medium or service. Suppose I have a device that 
supports voice and video. Do I have:
- one voice+video service represented as a single
   tuple with one contact
- one voice service and one video service,
   each with a tuple and each with identical contact addresses
- one voice service and one video service,
   each with a tuple, and with different contact addresses
- a voice service, a video service, and a voice+video service
- ...

I think of a tuple that has a contact as describing a device.
In RPIDS we have a way to describe a large number of attributes, 
including media type, about that device. A device is a tangible thing 
that is clearly distinguished by its contact address, so this makes 
sense to me.

Services seem much less tangible. I think different people will look at 
the same collection of stuff and view it as services in different ways. 
If all you care about is voice, then all the tuples that support voice 
represent the voice service of the presentity. If you are interested in 
video conferencing, then all the tuples supporting voice+video represent 
a useful service to you. If you are deaf then maybe all the tuples that 
support voice are of more interest to you as a service.

If we start imposing arbitrary mappings of capabilities into service 
groupings then I think we are sure to run into interoperability problems 
unless we also set out to standardize all the different kinds of 
services. I think this would be a bad thing.

	Paul

BTW - Sorry I haven't been participating more. I have been both busy 
with other things and struggling to catch up from the flood of email 
over the last month. I'm still 400 messages behind and just cherry 
picking what is there.

---

From: Sean Olson <[email-masked]>
Date: Wed, 2 Apr 2003 20:48:05 -0800 (PST)

> Whether that URI represents a service, or a device,

If the difference could matter to the compositor,
why wouldn't it matter to the watcher? I don't
quite understand. Everyone seems to agree that
there are services, users, and devices. What is 
wrong with making these concepts explicit in the
presence doc? 

Is everyone saying that CPIM-PIDF tuples are not
meaningful without the RPIDS extensions? 

__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more
http://tax.yahoo.com
_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 03 Apr 2003 11:24:39 -0500

> meaningful without the RPIDS extensions? 

They leave it up to the user to guess what each URL "means", while RPIDS 
provides detailed hints. Unless you are suggesting that we create a 
separate PIDF extension, I'm somewhat lost as to what we're trying to 
accomplish here, beyond what RPIDS already offers in terms of tuple 
labeling.

Given that PIDF is a constant and presumably beyond the change control 
of SIMPLE, what features are missing in *RPIDS* that would help the 
watcher make better sense of the tuple?

(Besides, I'm not really sure whether tuples are either a service, user 
or device. In many cases, a tuple can have aspects of all three, e.g., 
when you have a single tuple that describes the 'services' available for 
the user and happens to map to one device.)

Henning

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 03 Apr 2003 12:45:20 -0500

<reposting, since my original post never showed up>

> wrong with making these concepts explicit in the

I don't think Ben was saying that this information shouldn't (or
couldn't) be made explicit, but rather, that a tuple could be well
defined without requiring us to say whether its a device or a service.

To follow up on something Paul said:
> But representing things this way causes trouble when a single device can support more than one medium or service. Suppose I have a device that supports voice and video. Do I have:

I think you need to ask yourself why you want to have more than one
tuple. I believe that a tuple represents the finest granularity of
information you can convey about something. If you are trying to model
someting in such a way that you need to say two different things about
it, you need to break it into two tuples.

As a specific example, lets say I have two phones, both of which can do
IM. In a basic system, I can represent that with one tuple. It has a
contact address equal to my AOR, and it has a capability which indicates
that it supports MESSAGE. Its basic status is OPEN if either device is
registered. Now, if I wish to add geoloc, I now have additional
information I cannot represent in a single tuple, as it differs between
the two things I was formerly modeling with one tuple. So, I would now
have two tuples. Both could have my AOR as the contact address, both
indicate support for MESSAGE, both have a status of OPEN if either
device is registered, and now both have a geoloc attribute, indicating
the location of that specific device.

Now, the problem is that, on the publication side, the information
generated by a single source for a tuple can be applicable to other
tuples being published by other sources. As an example, a GGSN can
publish information on the connecvitity of a wireless device. This state
is encapsulated in a tuple. The information in that tuple can be applied
(meaning, its status values could be merged with those of another tuple)
to anything publishing tuples that contain status about something on
that same device.

> Whether that URI represents a service, or a device, or whatever is not

I dont think its true because we have sources of presence that have
nothing to do with a URI at all. Geolocation and IP connectivity are
good examples. That information can apply to any URI representing a
point of communications on that same device.

> meaningful without the RPIDS extensions? 

No, we are just saying that it is insufficient to model the more complex
systems we are talking about here.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Scientist                             Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: Ben Campbell <[email-masked]>
Date: 03 Apr 2003 12:41:26 -0600

On Wed, 2003-04-02 at 22:48, Sean Olson wrote:
> why wouldn't it matter to the watcher? 

It matters to the compositor because the compositor must decide what to
put in the presence doc. For example, in the single tuple per service vs
tuple-per-device argument, the compositor must decide which approach to
take.

But the watcher should be able to interpret the presence doc _either_
way. I think the tuple interpretation that I describe earlier allows
that. I could of course be mistaken, and welcome arguments to that
effect.

> I don't

Everyone seems to agree to that, except everyone has not agreed on what
the words mean. I am proposing a different taxonomy from the watchers
perspective. We have communication media, availability info, and
addressable entities. The watcher should not care whether an addressable
entity (which I will call URIs from here out) represents a service or a
device.

> meaningful without the RPIDS extensions?

I am not saying that. Without RPIDS, I can still tell some degree of
availability based on the basic status. I can make some inferences about
media based on the URI scheme. If the URI scheme is all-encompasing,
like in SIP, then then I use whatever mechanism that scheme affords me.
For SIP, that would be caller prefs. In the penultimate worst case where
I can tell nothing at all about media, I try whatever I like. If it
fails, I try something else. (I assume the ultimate worst case is when I
have no medium in common with the presentity)

Now, if RPIDS allows me to assign more granular availability and media
descriptions, that makes life easier.

---

From: Ben Campbell <[email-masked]>
Date: 03 Apr 2003 13:16:08 -0600

> point of communications on that same device.

OK, lets look at the geoloc example. The interesting question is, what
does the geoloc actually apply to? Would it be useful to have a presence
doc that only has a  single tuple with geoloc, and no contact? I suppose
it probably is, as I might carry a device that reports my geoloc, but is
not otherwise a communication device.

So should a tuple with no contact be considered a statement about the
presentity itself?

So, an extension to my previous assertion: A tuple with a contact
represents a set of attributes associated with a URI. A tuple without a
contact represents a set of attributes associated with the presentity. I
can imagine a situation where I might want to associate an attribute
with multiple contacts. Without building another level of hierarchy, I
could just repeat those attributes in the tuple for each contact to
which it applies.

So, lets say my watcher gets 2 tuples in a presence document. Both have
geoloc, but only one has a contact. My watcher can assume that the
presentity has some presence at both physical locations (which may or
may not be the same.) One of those "presences" is reachable via the URI.
The other is not meaningfully reachable, unless you count walking to
that location and shouting as a meaningful communication mechanism.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 03 Apr 2003 22:58:17 -0500

Jonathan Rosenberg wrote:
>> But representing things this way causes trouble when a single device 
>> can support more than one medium or service. Suppose I have a device 
>> that supports voice and video. Do I have:

It was a retorical question. I don't want to model these "service" 
thinks as more than one tuple. But I am trying to make sense of this 
notion of "service". I don't know what it means or why I would want to 
describe my presence in terms of it.

> the location of that specific device.

I have no problem with this. Under the given conditions this is a pretty 
reasonable way to represent things.

> point of communications on that same device.

To deal with that situation I think you must depart from use of the AOR 
for all contacts. You must now provide a device specific contact in the 
relevant tuples. Once that is done, a compositor can merge tuples from 
different sources that have the same contact address.

And as I mentioned in an earlier message, if you have a single device 
with two distinct addresses, then you need to treat it as if it was two 
devices, and publish all the information in association with whichever 
devices it belongs with.

	Paul

---

From: "Sean Olson" <[email-masked]>
Date: Thu, 3 Apr 2003 20:23:54 -0800

All the design arguments I have heard so far seem to point to treating a
tuple as a point of contact where that point of contact is typically a
device
interface. Presence without a way to act on that presence seems less than
useful.
In the simplest case, you have a single tuple with the AOR for the contact
and no
device specific information. In more interesting scenarios, you have
multiple tuples, 
each representing a device interface with the contact giving a device
specific contact
point and device-specific presence properties (such as geolocation).
Aggregation of presence
properties across devices is interesting but similar to aggregating presence
information for a list/group:
it's complex and not an immediate need. 

Also, in most cases we can treat device interface as synonymous with service
and in those cases where
a service spans multiple devices, I think we have a very long way to go to
be able to define routing
to such services. That is, we have a ways to go before we can do something
useful with this type of
information if it were presented to a watcher.

---

From: Ben Campbell <[email-masked]>
Date: 03 Apr 2003 23:44:29 -0600

> information if it were presented to a watcher.
I have trouble understanding why this is so hard. That usually means I
am missing something. Can you give a concrete example of a service
spanning multiple devices with which a watcher would have trouble doing
something useful?

---

From: Sean Olson <[email-masked]>
Date: Fri, 4 Apr 2003 15:07:44 -0800 (PST)

> spanning multiple devices with which a watcher would

I have trouble thinking of a concrete example of 
a service that spans multiple devices, but that is
a different issue. The problem I have in mind is
selection of which device to contact for a service
if multiple devices are advertising support of that
service. I will throw together some ideas in concrete
text. I would encourage others to do the same.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 07 Apr 2003 11:11:24 -0400

inline.

Sean Olson wrote:
> interface.

Brian and others want it to represent and AOR as well.

> Presence without a way to act on that presence seems less than
> useful.

I don't understand this. The contact URI in the tuple tells you how to 
"act on it". It says "use this URI to contact the thing defined by this 
tuple". IMHO, thats the "presence contract" - the URI in the contact 
header has to route you to something which matches the characteristics 
defined by the attributes in the tuple. If the tuple has a single URI, 
and indicates that IM is available there, the system need only guarantee 
that this URI routes to something that has IM. So, if the tuple 
represents the IM service on my cell phone, that URI can be a GRUU 
(http://www.jdrosen.net/papers/draft-rosenberg-sipping-lease-00.txt) for 
that device. Or, if the tuple represents my IM service in general, and 
that can go to my cell phone or PC, it can just be my AOR.

> it's complex and not an immediate need. 

I disagree. I think composition is inherent to presence.

> to such services.

My agument is that if the tuple represents a service on a specific 
device, then the URI you put in there, by definition, has to route to 
that service on that device.

I am beginning to think that our problem is NOT what a tuple represents, 
but rather, how to represent relationships between tuples. I think Ben's 
definition for a tuple is not far off; its a point of communication 
defined by the attributes, and available at the URI. The only issue is 
how to represent things where there is no communication, such as geoloc 

> could just repeat those attributes in the tuple for each contact to

I don't like that. I think a tuple without a contact is the same as one 
with, but it doesn't provide a concrete point of communications.

Nonetheless, the confusion is when multiple tuples are present. The 
question is - how do they relate? Tuples can relate in many ways:

* they can represent points of communications which reside on the same 
physical device,
* they can represent points of communications which represent the same 
"service" [I am concerned about defining service though]

So, one path forward is not to try and define what a tuple represents, 
but to add capabilities to rpids for representing the relationship 
between tuples. Information common across tuples because of this 
relationship can be repeated, I think. Linking for compactness is 
something we can add later.

-Jonathan R.