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

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 01 Jun 2004 01:22:55 -0400

Henning Schulzrinne wrote:

> 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

The problem here is that a device can host a multiplicity of services 
(my cell phone), each of which may have radically different URI, and 
that a device itself is not well described by a single contact address.

However, you say something important in your suggestion, which is 
"contact-equipped tuples can be either devices (which also is an
instance of a service)". My proposal for what "device view" means was 
that you have a tuple that represents all of the services available on a 
particular device, by doing a pivot operation on that device. In that 
way, the service tuple "represents" a device, in that I'm trying to have 
a single tuple for each device. However, the tuple is still 
fundamentally describing a service, NOT a device.

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

Which? What would it mean when I have devices that support multiple 
services, and a multiplicity of services that can run on a single device?

-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

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 01 Jun 2004 01:29:48 -0400

Paul Kyzivat wrote:

> Jonathan,
> 
> I'm having misgivings about this change now. Devices have somehow become 
> 2nd class citizens.

Thats a fair characterization.

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

A better solution would be to define <device> as a peer of tuple. PIDF 
allows the document to have things besides tuples. So, we could add 
<device> and then have each <tuple> (which represent services) refer to 
that <device>. I think this would work well with filtering.

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

In the case you are talking about, its still the device that has the 
property of location; its just that the device happens to host a single 
service. Whether or not a service is hosted on one device or many doesnt 
change the fact that location is a fundamental property of a device.

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

I think that introducing more options on how to represent things will 
only further worsen our current situation.

  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.

This is not far from what I am proposing above, excepting I'm using an 
explicitly named <device> element and not introducing the special case 
for 1-1 mappings. We've already said that contact-less tuples are 
presentities/in-person. How would we differentiate that from device?

Thanks,
Jonathan R.

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 01 Jun 2004 14:44:21 -0400

> that a device itself is not well described by a single contact address.

I've never been particularly enamored with the notion of devices being 
represented as tuples, in the sense of one device = one tuple. Maybe a 
better way to look at this is that tuples with contacts are *always* 
services. From a reachability perspective, as to whether I have three 
plastic gadgets on my belt connected by BlueTooth, or whether they are 
all in a single Treo-like device or whether they all have a separate 
network interfaces seems to matter very little, particularly since (as 
was discussed in the interim) it's hard to make very clear delineations 
as to what counts as a single device.

The only reason I can see that the notion of a device matters is to 
estimate whether two services are pretty much guaranteed to be available 
at the same time, by the same person. (As opposed to having one service 
be left on the dresser at home and one carried by the user.) A simple, 
unique and non-reachable identifier that indicates this reachability and 
locational unity, as the <device> token, does this.

> fundamentally describing a service, NOT a device.

We seem to be arriving at similar conclusions through slightly different 
paths. My disagreement is that I don't see the possibility of having a 
single tuple represent all services on a device, given that, as you say, 
they may not have a single reachable protocol URI (sip, mailto, etc.) 
that can represent them all. I don't see how

<tuple>
   <contact>urn:device:1234566</contact>
</tuple>

helps any, unless we assume that there is a URN resolution mechanism 
that actually translates this, ENUM-style, into a set of services.

> services, and a multiplicity of services that can run on a single device?

I'd like to determine first what the notion of device is meant to do.

The presence of RPID by itself wouldn't be able to distinguish a service 
from a device, thus, it could appear in tuples of both types. For a 
service, it could happen that all instances (devices) providing the 
service have the same RPID information.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 09 Jun 2004 18:19:21 -0400

inline.

Henning Schulzrinne wrote:

> services.

I've come to the conclusion that tuples are always services, period. See 
more below.

  From a reachability perspective, as to whether I have three
> as to what counts as a single device.

Just because we can't always be clear as to what's a device, and what's 
not, doesnt mean that its not useful to say that something is a device. 
Its useful from a correlation perspective, as you point out below, but I 
think it acts as a natural conduit for many pieces of information that 
are inherently about the *device*, and not the service or presentity. 
Geographic location and device capabilities (screen size, for example) 
are the most obvious ones.

> at the same time, by the same person. 

Yes, correlation is a big part of the need. Its not the only one.

> (As opposed to having one service 

I'd take this one step further, and say that what we want is the ability 
for a tuple to indicate a multiplicity of <device-id>, indicating that 
it runs on those device(s). A device ID is a meaningful identifier, in 
that it represents an indentifier for that device that other components 
know about, and would choose to identify the same device. In the case of 
a cell phone, this might be the ESN for example.

>> that you have a tuple that represents all of the services available on 
>> a particular device, by doing a pivot operation on that device. In 
>> that way, the service tuple "represents" a device, in that I'm trying 
>> to have a single tuple for each device. However, the tuple is still 

It doesnt. However, if we believe that it should be OK to have a single 
tuple, and that tuple represents the union of my service characteristics 
(this is Brian's presentity view), then we have this problem 
irregardless of whether you like the <device-id> or not. I would propose 
that, if you want to indicate availability for communications across a 
variety of services, and those services can't be represented by a single 
URI, then you could omit the URI.

That is, I think we shouldn't use the presence or absence of the contact 
URI in the tuple to mean that the tuple is modeling something 
fundamentally different. Rather, the absence of the contact URI means 
that the presentity is unable or unwilling to disclose the URI for this 
service.

> I'd like to determine first what the notion of device is meant to do.

Its meant to (1) serve as a way of correlating data together, and (2) 
act as a container for data that is really about the device.

Here's an example of a real problem I have surrounding (1). Lets say I'm 
able to get some information from the PSTN about the status of a phone - 
whether its on hook, off-hook, etc. I want to correlate this information 
(which is associated with the device-ID for the phone), with information 
about services running on that phone that I learn from PUBLISH, 
REGISTER, and other means. I can't do this unless the published data 
from the phone about those services indicates what devices they are on.

> from a device, thus, it could appear in tuples of both types.

Where I'm at is that I think we should have an RPID element called 
<device-id> that appears in a tuple, which indicates a device the 
service runs on. Separately, as a sibling of tuple, the PIDF doc can 
have <device> elements, which contain the device-id, but also other 
device-specific data. SO, for example:

  <?xml version="1.0" encoding="UTF-8"?>
      <presence xmlns="urn:ietf:params:xml:ns:pidf"
          xmlns:local="urn:example-com:pidf-status-type"
          entity="pres:[email-masked]">
        <tuple id="ub93s3">
          <device-id>urn:esn:76533-233374</device-id>
          <status>
            <basic>open</basic>
          </status>
          <contact>im:[email-masked]</contact>
        </tuple>
        <device id="urn:esn:76533-233374">
          <location>Germany</location>
          <screen-size>large</screen-size>
          <power-remaining>little</power-remaining>
        </device>
      </presence>

With this, I can have a service that I can say runs on one device or 
many devices, and if I include the same <device-id> in multiple tuples, 
I can indicate that multiple services run on the same device.

You can have the <device-id> without the bigger <device>; in such a 
case, it ONLY serves as a correlation tool. This makes the above 
document play nice with filtering techniques. The "reference" here - the 
device-ID - has meaning even if the <device> element it talks about 
disappears from the document.

-Jonathan R.

---

From: Aki Niemi <[email-masked]>
Date: Fri, 11 Jun 2004 10:35:59 +0300

ext Jonathan Rosenberg wrote:
...snip...

> that the presentity is unable or unwilling to disclose the URI for this 

This definition is fuzzy and only leads to more confusion. I agree that
all tuples are services, but one without a <contact> lacks any real 
indication of what service it really represents. I mean, if the 
presentity is unwilling or unable to disclose the <contact>, then what 
purpose does showing the tuple have at all?

I would still propose we assign a well-defined meaning to a 
<contact>-less tuple, and that is, this is a tuple representing the 
presentity and absent of any particular means for communication.

I think we all agree there is a need to be able to represent presence 
information that only represents the presentity (iconic representation, 
mood, homepage etc.). This sort of attributes don't really belong to 
specific service tuples as such, because they apply across the 
presentity's offered services. There are three options to doing this 
sort of thing:

1) Wrap these attributes into a <tuple>, and omit the <contact> to 
indicate this is generic information about the presentity and not 
related to any particular communication channel.

2) Define a new "wrapper type", as a sibling to <tuple>, e.g., <info> 
that includes all presentity-related information not related to any service.

3) Include these attributes directly under the <presence> element

Out of these three, 1) seems the cleanest, because it plays well with 
other specifications like presence authorization and partial 
notifications. The others would require changes elsewhere were we to 
adopt either one of them.

Cheers,
Aki

>> The presence of RPID by itself wouldn't be able to distinguish a 
>> service from a device, thus, it could appear in tuples of both types.
> 
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 11 Jun 2004 04:44:46 -0400

Aki Niemi wrote:

>> That is, I think we shouldn't use the presence or absence of the 
>> contact URI in the tuple to mean that the tuple is modeling something 
>> that the presentity is unable or unwilling to disclose the URI for 
>> this service.
> 
> 
> This definition is fuzzy and only leads to more confusion. 

I think its confusing that the information that a tuple is modeling 
should change based on whether a contact is present or not.

> I agree that

Other things in the tuple, like RPID information, indicate the nature of 
the service. If you don't include that kind of information, then I agree 
the tuple is worthless.

> presentity and absent of any particular means for communication.

Whilst I agreed with this initially, I now think we'd be better served 
by having a <presentity> element.

> that includes all presentity-related information not related to any 

Right - this is the one I like. Its the most explicit.

> adopt either one of them.

I think we are going to need to make sure that the authorization stuff 
is aligned with the PIDF/RPID data models no matter what we do. Part of 
my difficulties in wrapping up the authorization spec is that we keep 
tripping on the "what is a tuple" issue in figuring out what kind of 
functions to include in the authorization policies.

You raise a good point on partial notifications. Using a separate 
<device> element also won't play well with that. I'd hate to force 
things into tuples when they don't belong, just because partial 
notifications doesnt know about anything but tuples.

-Jonathan R.

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 13 Jun 2004 20:53:18 -0400

Trying to catch up; since the original was already beyond one screen, 
I'll split the response.

> I've come to the conclusion that tuples are always services, period. See 

I gather we agree on that aspect.

> are the most obvious ones.

Rather than trying to make talmudic device distinctions that imply 
certain common characteristics, why can't we simply group tuples by 
properties, saying that certain groups of tuples happen to share a property?

This also avoids the problem that certain things that could be 
considered a device share on property (location), but not another 
(screen size). Picture a composite gadget that cables together plastic 
boxes with different displays - they have to be on one human body, but 
they each have their own display.

I think one of the fundamental design assumptions in SIP is that we want 
to be explicit, rather than implicit about protocol properties. Don't 
infer things by labeling, but rather label them as such.

> a cell phone, this might be the ESN for example.

Again, I don't see the need for transforming our eternal "what is a 
tuple" discussion into an equally entertaining, but probably best left 
to FCC lawyers, discussion of "what is a device". Like tuples, it's the 
80% that are easy and the 20% that yield interminable email discussions.

> URI, then you could omit the URI.

Indeed - no point distributing useless URIs that just insinuate that 
there might be a there there.

> act as a container for data that is really about the device.

Since we have difficulty defining clearly what a device is, I'm not sure 
this helps us along - this can easily become a circular definition.

> I can indicate that multiple services run on the same device.

Again, why not simply say "this set of services is at the same location" 
or (and independently) "this set of services shares a screen", etc.

Describing the location separately from the tuple means that I now have 
to be careful to remove the <device> if all of my corresponding tuples 
have been filtered out, as I may or may not want to reveal location 
information in that case. If I want to remove filtering service tuples 
from location information, it seems to make more sense to define a 
top-level location item that I can reference from each service tuple. 
After all, for location it doesn't matter whether I have a collection of 
BlueTooth-connected devices or a single piece of plastic.

For the other items, I'm not sure why replicating, say, battery 
information across services is a big deal. What harm is done if I have

<tuple>
   <screen>large</large>
   <battery>low</battery>
</tuple>

<tuple>
   <screen>large</large>
   <battery>low</battery>
</tuple>

This seems simpler, at a modest cost of replication.

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 13 Jun 2004 21:16:10 -0400

> purpose does showing the tuple have at all?

I guess you could call it a tease - I have the capability, but I won't 
tell you how to get to it :-)

> 3) Include these attributes directly under the <presence> element

And maybe another one:

(4) label a tuple with some "this applies to the presentity" label (and 
thereby have these apply to all other tuples), regardless of whether 
there is a contact URI or not

I'm not particularly fond of this one.

> adopt either one of them.

(2) still has the problem that per-tuple override isn't particularly 
clean, syntactically. Only (3) clearly indicates an inheritance 
relationship, i.e., a tuple could override the generic RPID information 
if it has contradictory information.

Henning

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 13 Jun 2004 21:19:19 -0400

> notifications doesnt know about anything but tuples.

The more separate "tables" we have (and this is essentially what we're 
doing), the more complicated maintaining referential consistency 
becomes, where either pointers point to non-existent descriptions or 
there are orphans, i.e., elements that aren't referenced by anything.

We had this discussion before, many moons ago: once we allow something 
like the <presence> element or a contact-less tuple, we'd have to decide 
whether a tuple could override all or part of that information.

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 14 Jun 2004 18:41:01 -0400

Trying to catch up. Won't try to respond to each message in the thread.

I have the sense (as Henning also seems to) that we are at risk of 
replacing "what is a tuple" with "what is a device".

Personally, I have always largely considered a device synonymous with a 
unique contact address. This of course doesn't always map to a physical 
device, but it maps to a "virtual device", which is the only thing that 
is helpful to the watcher in an operational way.

If we introduce explicit device ids, then we end up with the following 
possible situations:

1) a tuple, and the contact address it contains, is 1:1 with a device

2) several tuples, with distinct contact addresses, are associated with
    the same device

3) a tuple, and the contact address it contains, is associated with
    several devices

4) several tuples contain the same contact address

5) a tuple has no contact address

6) a tuple is associated with no device

Of those, 4-6 present issues I don't want to talk about right now. I'm 
only going to discuss 1-3.

Case (1) is pretty easy to understand. You can consider the address to 
represent either a service or a device.

In case (2) you know some additional information, but it isn't clear to 
me how valuable that information is. You would like to draw inferences, 
but most of them aren't safe. Physical location is probably safe by any 
reasonable definition of device. But that is easily dealt with by 
replicating location information.

Simultaneous availability is I think what people would like to infer. 
But that isn't always a good assumption. The nature of the device may 
prevent me from using both capabilities simultaneously. At best, I think 
device might be useful here in the PUBLISHed tuples so it could be used 
by aggregation rules that also know the nature of the device and can 
make the appropriate inferences. For instance the rules might decide to 
replicate location information from a tuple that had it to tuples for 
the same device that don't have it, and give precedence in some way when 
multiple tuples provide location for the same device. But device info in 
the resulting tuples that are delivered to subscribers would be much 
less interesting and perhaps should be suppressed.

Case (3) is just Brian's original approach, restated. I had problems 
with it then, and I have problems with it now. It just isn't very clear 
what this means operationally. Does it mean that the capabilities 
described by the tuple are partitioned among the devices, or replicated 
on each of the devices? Are requests presented to the address serviced 
by one device, or by a combination of the devices? Without knowing the 
answers to these questions, this kind of presence status is pretty 
useless. And even if the questions are answered, only some answers lead 
to useful results.

In particular, if the capabilities are partitioned among the devices, 
and requests are serviced by only a single device then the presence is 
pretty much useless.

If the capabilities are partitioned but all the devices may participate 
in servicing a request, then its useful but the device information 
itself is useless.

The the capabilities are replicated on all devices and a single device 
services a request, again I have useful presence information but knowing 
the device info isn't helpful.

And I just can't make any sense of the situation where capabilities are 
replicated and requests are serviced by a combination of devices.

So the bottom line is that I can't find any situation in which case (3) 
is useful.

So, I guess I can support including device id in PUBLISH, for use in 
aggregation, with restriction that there is at most one device id per tuple.

	Paul

Jonathan Rosenberg wrote:
>> was discussed in the interim) it's hard to make very clear 
>> delineations as to what counts as a single device.
> 
> 
>> estimate whether two services are pretty much guaranteed to be 
>> available at the same time, by the same person. 
> 
> 
>> (As opposed to having one service be left on the dresser at home and 
>> one carried by the user.) A simple, unique and non-reachable 
>> identifier that indicates this reachability and locational unity, as 
>> the <device> token, does this.
> 
> 
>>> that you have a tuple that represents all of the services available 
>>> on a particular device, by doing a pivot operation on that device. In 
>> We seem to be arriving at similar conclusions through slightly 
>> different paths. My disagreement is that I don't see the possibility 
>> of having a single tuple represent all services on a device, given 
>> that, as you say, they may not have a single reachable protocol URI 
>> (sip, mailto, etc.) that can represent them all. I don't see how
>>
>> <tuple>

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 14 Jun 2004 20:19:58 -0400

> replicating location information.

Agreed; that's why I suggested that if we really need to save the cost 
of replicating information (a dubious saving in my mind, as a mechanical 
compression algorithm like LZW will do this without the conceptual 
hassles), that we should have explicit references to information blocks 
that are shared between tuples, rather than jumping from some rough 
notion of device to conclusions as to what's common and what's not.

> less interesting and perhaps should be suppressed.

Again, a 'location-id' identifier would seem more appropriate, which 
would explicitly indicate such replication. I'd rather not have to 
custom-program a PA, over which I'm unlikely to have any operational or 
programming control in many common settings.

The whole point of our overall design should be, I think, that users can 
do likely and common tuple operations (filtering, suppression, 
modification, merging, inheritance) without custom per-user programming.

> useless. And even if the questions are answered, only some answers lead 

I always thought that this was basically for the case where a server 
related to the presentity made the decision where to route messages and 
it was none of the watcher's business to guess or care as to whether a 
request to the URL (presumably directed to a proxy server for a SIP URL) 
would be parallel-forked to a bunch of my devices or whether the SIP URL 
refers to a B2BUA that magically assembles a bunch of boxes of plastic 
into a single logical service using 3pcc.

I see no need to prohibit or describe this further. If the underlying 
devices are currently all carried by one user or vehicle, they might 
even have location information associated with them. If they are powered 
from the same car battery, they might even have the same power 
information, etc.

> the device info isn't helpful.

Agreed. The whole point of this view, in my mind, is to hide, for 
whatever reason, the implementation of the service from the watcher.

> aggregation, with restriction that there is at most one device id per 

I would much prefer deciding where this is truly useful and necesary, 
beyond saving replicating location information across tuples.

What exactly would the watcher do differently if it has this 
information? What additional important services are enabled?

---

From: Aki Niemi <[email-masked]>
Date: Wed, 16 Jun 2004 16:06:58 +0300

On Mon, 2004-06-14 at 04:16, ext Henning Schulzrinne wrote:
...snip... 
> if it has contradictory information.

I don't think the inheritance relationship itself is particularly clear.
In fact most (if not all) RPID/CIPID elements are interpreted within a
different context depending on whether they are pertaining to the
presentity or the tuple (granted some of them only make sense in either
one).

So I'd rather define explicitly how overrides should occur, case-by-case
when there is an explicit inheritance relationship to a given element.
And in that sense, it doesn't seem to matter whether the element is
under <presence> or under a new <presentity> element.

Cheers,
Aki

---

From: Aki Niemi <[email-masked]>
Date: Wed, 16 Jun 2004 16:14:15 +0300

On Fri, 2004-06-11 at 11:44, ext Jonathan Rosenberg wrote: 
...snip...
> functions to include in the authorization policies.

This is true. So from this point of view, it would be good not to let
PIDF restrict us in making things explicit. 

> notifications doesnt know about anything but tuples.

I agree.

Mikko, what do you think about this?

Cheers,
Aki

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 24 Jun 2004 22:41:11 -0400

> under <presence> or under a new <presentity> element.

Can you give an example of where the value for the presentity, whether 
wrapped around or labeled as such, would not be overridden by a 
tuple-specific value?

Henning