Subject: [Simple] presence data model: URI as an index

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 19 Oct 2004 22:25:50 -0400

The current data model proposes that, for services (aka tuples), the 
service URI (present in the <contact>) element, serves as the "key". It 
is the key in the sense that, per my previous posting, composition 
policies would determine whether to concatenate or replace two services 
based on whether they had the same or different URI.

The presence document already has a tuple ID, and its usage and 
relationship to the service URI were confusing.

Henning has proposed that we have a separate, non-URI ID that acts as an 
index for this composition policty, to avoid complexities on the server 
of understanding how to do URI equality comparisons.

I still think we want the URI to be used as the index in this 
composition computation. The reason is, and this is important to 
understand, is that this index is only used when something, be it a 
compsotior or watcher, is presented with two services or devices with 
the same value of the index and has to decide what to do. This presumes 
that there were two things that decided to publish services or devices 
with the same index. Presumably, this is to force an override (see other 
thread) when the data comes from PUA, and to represent conflicting 
information when the data comes from the compositor.

So, for this to even happen, this index has to eb "well-known" - 
something that is guessable or meaningful, and can potentially be found 
out by other services. If the index is the gruu, for example, it can be 
learned through reg-event (see Paul's recent proposal in sipping). If 
the index is the device ID, its construction is well known based on a 
specific device type.

The service URI as defined, and the device ID as defined, have these 
properites of being discoverable because they are meaningful outside of 
the presence document context. If you instead use some random ID, I 
don't have any clue how any one else will learn it.

Ultimately, two services are different if their service URIs are 
different, and the same if they rae the same, based on the definition of 
a service as being something you invoke in the network by hitting a URI. 
Thus, adding another index provides two ways of saying the same thing, 
and the resulting possibility of conflicting or confusing results.

Henning has also proposed that devices be allowed to have multiple 
device IDs, to help deal with the case where there is no single ID type 
that might make sense for a device. I think this sizeably complicates 
the whole overriding question, since know its almost impossible to say 
whether two devices are the same or not.

-Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                        FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

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

---

From: Aki Niemi <[email-masked]>
Date: Wed, 20 Oct 2004 15:09:06 +0300

On Wed, 2004-10-20 at 05:25, ext Jonathan Rosenberg wrote:
...snip...

> the index is the device ID, its construction is well known based on a 

I disagree, because this only works with SIP URIs -- others, like
mailto, while capable of providing some GRUUness (in some settings,
e.g., mailto:[email-masked]) won't have a comparable way of
discovering the used indexes.

I think tuple-id is a reasonable index, and if we really need a
discovery mechanism, then an event package (or template package) for
event-publications would do the trick.

> and the resulting possibility of conflicting or confusing results.

I don't see how if the SIP URI is an AoR. We've concluded earlier that
in such a case, there will be other markup (prescaps) that indicates the
capabilities of the service. So tuples with the same AoR can be
different services, e.g., one accepts MESSAGE only and the other accepts
INVITEs (and most importantly they can have different status).
Similarly, tuples with completely different URI schemes can in some
cases be the same service (im: URI and SIP URI supporting only MESSAGE).

> whether two devices are the same or not.

I tend to agree. However, it also seems that overriding a device would
be less common by a "third party" anyway. In fact, it would be natural
to only override a device by someone on the same device because the IDs
are usually based on some physical property (like MAC address). This is
in contrast to the other types, whose IDs are arbitrary and therefore
easier to fake.

Cheers,
Aki

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 21 Oct 2004 01:04:02 -0400

inline.

> discovering the used indexes.

I think we are talking past each other.

For email, its even easier. If one PUA publishes a tuple with my email 
service, and I want to override this from another PUA, its easy to 
construct the URI - it is going to be the email address (ie., 
mailto:[email-masked]).

> event-publications would do the trick.

If you want to override, and you use tuple ID as an index, you NEED a 
discovery mechanism. I'll also note that tuple IDs are not meant to have 
meaning outside of the presence document they were in.

> INVITEs (and most importantly they can have different status).

How can they be the same AOR if the responses to a request to that AOR 
depend on which "service" is listening? If there is truly different 
software agents (i.e., sip servers) for each, then there are two URIs 
(the gruu).

> cases be the same service (im: URI and SIP URI supporting only MESSAGE).

What is the point in including both?

> in contrast to the other types, whose IDs are arbitrary and therefore

I agree that devices overriding devices is unlikely. Indeed, I suspect 
the same is true for services. Most likely it would be for person 
information.

Not sure I follow about "faking" the URI.

-Jonathan R.

---

From: Aki Niemi <[email-masked]>
Date: Mon, 25 Oct 2004 15:57:14 +0300

> mailto:[email-masked]).

You're arguing that the default behavior is service override,
necessitating GRUU contacts if override is to be avoided. I don't agree
with this, because I don't see GRUU as an inherent feature in SIP, or
any other protocol for that matter. In other words, GRUUs won't be
available everywhere and you're argument seems to assume that they are,
or that override is always what we want.

However, in the absence of GRUU, the only way currently to represent two
different SIP-based services is to split them into two tuples that have
the corresponding service characteristics with an AoR contact. This in
itself is maybe not that useful, except when you want the services to
have different status. For example, I'm CLOSED for PoC, but OPEN for IM.
This is where override is not at all what we want.
 
> meaning outside of the presence document they were in.

Exactly. And similarly, if you do *not* want override and you're using
the contact as index, you NEED GRUU.

Your point about the tuple ID is true. It's a shame though, if because
of this limitation we would end up with yet another ID that only adds
this global scope but otherwise behaves the same.
 
> software agents (i.e., sip servers) for each, then there are two URIs 

I would not have separate AoRs on my business card for IM, PoC and
Voice, and I don't see why that should be any different in a presence
document.

There are numerous other examples as well: my mailto URL has an iCal
agent and an email agent, for example. Somehow the system is able to
dispatch the correct agent to handle the message.

> What is the point in including both?

Good question. Perhaps the two are different SW agents that may not even
reside on the same piece of plastic. They might not even share a common
protocol. Is there a reason not to include both?

Cheers,
Aki

...snip...

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 25 Oct 2004 18:19:55 -0400

I don't agree fully with either of you. See inline.

	Paul

> This is where override is not at all what we want.

Are these really two distinct UAs, each with a unique contact uri? (Even 
if you don't want to expose it.)

Or are these just two capabilities of the same UA?

In the latter case, that isn't two services. It is one service, that is 
sometimes capable of both PoC and IM, sometimes one or the other, and 
sometimes none. If the UA is capable of *either* PoC or IM, but not both 
concurrently, then this is the OR-of-ANDs problem, for which two tuples 
with the same address *may* be a solution. (If we have a different 
solution for overriding.)

If it is truly two UAs, but you only want to expose the AOR, which is 
the same, then we have no good way to represent this. You can perhaps 
represent it as an OR-of-ANDs case *if* any service request will of 
necessity, without special actions on the part of the caller, provide 
enough info so that the proxy will select the proper UA or will fork to 
both and only the right one will answer. But you can't use this approach 
if the caller must do something (like use callerprefs) to choose the 
proper UA (even though it doesn't know there are two.)

> this global scope but otherwise behaves the same.

This of course only makes sense when there is a 1:1 mapping between 
tuples published and tuples in the composed document. It would be nice 
if in this case we could count on the tuple id being preserved. 
Certainly this would then provide the discovery mechanism.

> dispatch the correct agent to handle the message.

We've been thru this months ago with Brian. If the address provided 
doesn't guarantee that I get to the service advertising that address 
then all sorts of things break.

As I noted above, you can get away with this in a few restricted case. 
E.g. a page mode IM service and a voice service, where it will always be 
clear that only the proper device will respond to a request.

But most of the interesting cases are more complex than this. E.g. if 
you try to treat session mode IM and voice as distinct services with the 
same address (AOR) then you can't always tell at invite time which one 
to involve. (The INVITE might be offerless.)

> protocol. Is there a reason not to include both?

In that case they are two different service instances that have the same 
capabilities. They should be shown as such.

	Paul

---

From: Aki Niemi <[email-masked]>
Date: Tue, 26 Oct 2004 14:15:20 +0300

Inline.

> Or are these just two capabilities of the same UA?

Why does that matter? They could be the same UA, or separate UAs on the
same device, or separate UAs on the same device that use a front-end
server that dispatches requests to the appropriate handler UA (both
would still have their own contact URIs when sending requests, same IP
address different ports); or they could be separate UAs on different
devices.

Even though I'm mainly after something along the lines of the first
three rather than the last, I don't see what difference it makes.

> solution for overriding.)

Right. This is mainly what I am after.

> proper UA (even though it doesn't know there are two.)

I think you're confusing routing a call with advertising capabilities
and services for a presentity. There doesn't need to be any correlation
between what one advertises in the presence document and what will
actually happen when a call is placed. Presence provides tidbits of
information, hints, and not a full description of the presentity's
registrations.

> Certainly this would then provide the discovery mechanism.

Yes. Another option is to create a new template package (similar to
watcherinfo) that notifys about the publication state of the resource.
This would make it possible to have the tuple-ids in publications and in
notifications belong to a separate namespace.

> then all sorts of things break.

I think I remember this discussion, and I was also then under the
impression that rather than presence, we were designing some sort of
distributed registration system. I don't think that is what we are
designing.

And what exactly would break? There are no guarantees in presence. Even
if the tuple states OPEN, I might choose to reject the call. You might
not have had my presence info available, or the presence state was
stale.

> to involve. (The INVITE might be offerless.)

Why would a watcher ever send an offerless INVITE, unless it's willing
to let the callee (presentity) decide?

Cheers,
Aki

...snip...

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 26 Oct 2004 10:56:35 -0400

> three rather than the last, I don't see what difference it makes.

It matters because if you allow it then you entirely gut the semantics 
of the capability descriptions. Including a capability for voice and a 
capability for video could either mean:

- I can do Voice alone, Video alone, or Voice and Video together
- I can do Voice alone, or Video alone

These make a big difference to the watcher that wants to do voice and 
video together. Ambiguity here is a bad thing.

> information, hints, and not a full description of the presentity's

There needs to be some truth in advertising. Yes, there is no certainty, 
because things can change. But that is different from just saying the 
wrong thing.

We agreed some time ago that the address in the tuple SHOULD, without 
further qualification on the caller's part, get you to a UAS that has 
the stated capabilities.

> distributed registration system. I don't think that is what we are

No. The discussion was about RPID.

> not have had my presence info available, or the presence state was

Answered above.

> to let the callee (presentity) decide?

Well, one reason might be because it is a B2BUA implementing callme. To 
do so it sends an offerless invite to one party, and then relays the 
resulting offer on to the other party.

A similar one is adding someone to a multimedia conference.

The basic point is that I will use the capabilities in the tuple/service 
description to decide which address to invite. The dialog establishing 
request may not have a full (or any) indication of which of the offered 
capabilities I desire to use.

Another example: I may see that you have one voice service and one 
voice+video service. I choose to call you at the voice+video service so 
that I will have the option of using video, but my initial call is still 
only audio. My intent is to later add video when/if it is needed. But 
both services have the same address, and if you route my call to the 
voice-only device, then we don't have truth in advertising.

Because there aren't any guarantees, I probably can't complain too much 
to you in this case. It could have been that my call was sent to your 
video phone, but you refuse video because you are having a bad-hair day. 
I can't tell the difference between these cases, but in my mind the 
latter is valid and the former is structural and invalid.

	Paul

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 31 Oct 2004 22:11:07 -0500

> video together. Ambiguity here is a bad thing.

The current capability description does not, as far as I can tell, allow 
you to discriminate concurrent capabilities from alternative 
capabilities. There is no way to express that "if you ask for video, my 
CPU power no longer allows (say, high-fidelity) audio".

> further qualification on the caller's part, get you to a UAS that has 

There are two cases:

(1) The watcher/caller doesn't know anything about caller preferences 
(which seems to be the one you're referring to).

(2) The watcher/caller does have this capability.

In case (1), you will always have this problem if there are multiple UAs 
with diverse capabilities "hiding" behind a single AOR. Merging the 
capabilities at the PA doesn't solve the problem, as you've now simply 
created a union of capabilities that, as such, does not exist.

A receiver of this information can easily do the same union of 
capabilities if it wants to, but is has additional information that 
there may not actually be an entity that has the combined capabilities. 
Again, by not throwing away information, you allow the watcher to make 
more intelligent decisions.

In case (2), the watcher can indeed disambiguate the UAs behind the AOR.

Henning

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 31 Oct 2004 23:19:40 -0500

> and the resulting possibility of conflicting or confusing results.

I think we still disagree here. I think your definition of a URI is too 
simplistic. We don't have to go into SIP land to see this: content 
negotiation in HTTP can allow two very different documents, in different 
languages, for example, to share the same URI.

See http://httpd.apache.org/docs/content-negotiation.html for a 
description on how a popular web server handles this, indicating that 
this is more than theoretical.

To state it briefly: I have no problem with having a particular 
composition policy would use URI identity as a means of merging. My 
problem is with having the data model rule out composition policies that 
deliver multiple service tuples with the same URI.

I believe that it is easy to define the meaning of such tuples to the 
watcher. By definition, by choosing such a composition policy, the 
composer has decided that it has other means to merge presence inputs, 
rather than relying on service URIs. We have, I believe, agreed that we 
are not going to enumerate all composition policies. To be meaningful, 
this decision must include not ruling out reasonable ones.

Henning