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

From: Paul Kyzivat <[email-masked]>
Date: Mon, 01 Nov 2004 13:41:02 -0500

Henning Schulzrinne wrote:
> Paul Kyzivat wrote:
> 
>> 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.
> 
> 
> 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".

It is limited. As I (one of the authors) understand and intended it, the 
capabilities represented by independent feature-params should be 
interpretted as concurrent capabilities. (Multiple values of the same 
feature-param represent alternative capabilities.)

This interpretation is required for the matching algorithm in 
callerprefs to make any sense. It is an unfortunate limitation, since 
there are reasons to want to express both notions. But it was a 
limitation of the notation at hand, and a desire not to complicate it 
further. Alternative capabilities can be represented by using different 
contact addresses that happen to be handled by the same server. (A 
kludge, but it can work.)

After realizing this limitation was not going to be easily fixed there, 
I was somewhat comforted by the expectation that we could do better with 
presence, where the notation is not so limited. We now seem to be in a 
situation were we haven't solved the problem in presence either. I hope 
to come back to that. But we don't solve the problem by pretending there 
is no difference between alternative and simultaneous capabilities.

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

Diverse UAs hiding behind a common address (the AOR) is a problem. The 
general solution to this is "don't do it".

Publishing this as two tuples with the same AOR isn't better than 
merging them as one. Long ago you spelled out the trick to merging these 
- say nothing about those features where there is ambiguity.

In principle, if they are published as separate tuples, then a watcher 
could reach the right one by both using the address and including 
explicit callerprefs to select the features desired among those 
advertised. But We have agreed it is unreasonable to expect watchers to 
do that.

Here is an example of this case:

- UA1 supports simultaneous voice and video, no IM.
- UA2 supports simultaneous voice and IM, no video.
- Both are registered with AOR of sip:[email-masked].
- Both publish presence with their capabilities, using
   only their AOR as the address.
- Bob is a watcher of Alice.
- Assume Bob receives two tuples for alice, as above.
- Bob wants a videophone call with Alice, so he selects
   the voice+video tuple from his videophone and selects
   "call".
- The phone sends an invite with offers for voice and
   video to Alice's AOR.
- The invite is forked to UA1 and UA2. Both find it
   acceptable and ring.
- Alice happens to answer UA2.
- Bob ends up with a voice-only call.

You fix this in a few ways:
- You insist that distinct addresses be used
- You require every call to include callerprefs for every
   capability it may want to use.

I thought we had agreed that distinct addresses must be used in this 
case - I just don't think it is reasonable to expect that callers will 
insert the callerprefs, or that proxies will necessarily honor them.

This does however put us between a rock and a hard place if UAs do this, 
even though it is wrong. Putting both tuples into the final document 
isn't an accurate representation of the situation, nor is having the 
most recent one override the older one. The only accurate composition 
policy is to merge them, deleting conflicting attributes, but that isn't 
especially satisfying either.

	Paul

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 01 Nov 2004 15:23:17 -0500

inline.

Aki Niemi wrote:

> Inline.
> 
> On Tue, 2004-10-26 at 01:19, ext Paul Kyzivat wrote:
> 
>>>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.
>>
>>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?
> 
> 
> 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.

Let me explain some of the motivation for why the data model says to use 
gruu.

The idea is that each agent providing a service should only publish 
based on its own view of the service it offers. That is, it shouldn't 
assume that it knows anything about other services on the same AOR, or 
know what the compositor is doing. The publication from the agent should 
say, "when you hit this URI, this is the service you get". If the URI is 
the AOR, it can't make definitive statements like this, since it doesnt 
know what other devices are attached to the AOR. The only thing the PUA 
does know definitively is the service offered by itself, which is 
addressable by its GRUU.

As such, if I have SIP clients on different devices, even if they are 
behind the same AOR after composition, each of those clients won't know 
that, and as such, would need to publish information about themselves 
via their gruu.

The compositor can aggregate these together because the registration 
state provides the AOR/GRUU bindings.

> 
> 
>>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.)
> 
> 
> Right. This is mainly what I am after.

I don't like the idea of using multiple services to address a limitation 
in our current ability to represent more complex capability sets.

-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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 01 Nov 2004 15:31:58 -0500

inline.

Paul Kyzivat wrote:

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

I think the answer here is that you wouldn't try to represent these 
capabilities in the merged tuple. If there are capabilities not in 
common between the two, you'd probably drop them altogether.

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

I think its not reasonable to prohibit this; I think it will be a common 
case. The answer, as I stated above, is to simply discard any capability 
indicators not shared across the component services. You need to 
maintain the property that the characteristics included in the tuple 
provide a "loose contract" for what you'll get when you invoke that URI.

> - say nothing about those features where there is ambiguity.

Right.

> especially satisfying either.

I'm not sure I see a better alternative.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 01 Nov 2004 15:35:46 -0500

inline.

Henning Schulzrinne wrote:

> Jonathan Rosenberg wrote:
> 
>> 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.
> 
> 
> 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.

Perhaps I've missed it through the long chains of emails, but you can 
concisely state what is it you want that to mean? The two suggested so 
far were (1) different views of the same service from different sources 
which could not be reconciled by the compositor, and so are presented to 
the watcher for reconciliation, and (2) or-of-and kind of capability 
declarations.

My view on (2), which I've stated in a previous response, is that you 
are better off just removing cpabilities which conflict between 
different services used as input to composition.

-Jonathan R.

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 01 Nov 2004 15:47:36 -0500

> the watcher for reconciliation, and (2) or-of-and kind of capability 

Multiple components of the service whose capabilities cannot be 
represented by a simple merger without loss of information.

> different services used as input to composition.

Not sure if I understand the proposal correctly, but are you suggesting 
that if one publishing entity for the AOR has text capabilities and the 
other doesn't, that the single service tuple not advertise text at all?

In that case, what would happen with two tuples with the same AOR?

(1) If the watcher supports caller prefs (or the equivalent for other 
URIs, as in my example of content-negotiation for HTTP), it can pick the 
service capability combination that actually exists.

(2) If the watcher does not support caller prefs (but understands 
capabilities), it can do the merging, but know that it might not be able 
to steer the call, so the result may or may not be optimal. Having one 
tuple makes this no more or less likely.

(3) If the watcher doesn't support callerprefs nor understands 
capabilities in presence, it just sees two tuples that look the same in 
the parts that it cares about and merges them. No harm done.

Since the compositor cannot know whether the watcher is in category (1), 
(2) or (3), it seems inappropriate for the compositor to rule out 
capable watchers, particularly since not-so-bright watchers are no worse 
of with the extra information.

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 01 Nov 2004 23:05:24 -0500

Paul Kyzivat wrote:

> is no difference between alternative and simultaneous capabilities.

I wouldn't want to ignore that distinction, but we'd have to separate 
two different issues:

(1) Alternative capabilities that are caused by having multiple contacts 
(devices, software, etc.), where you get bundles of capabilities that 
you cannot combine in one session. ("Software 1 does A+V, Software 2 
does T").

(2) Alternative capabilities that are caused by the capability 
constraints of a single device or software, e.g., due to CPU or software 
limitation ("no, you can't do high-rate video and AAC audio together").

We may be able to solve (2), but we can, in particular, solve (1) [the 
more common case, in my opinion] fairly easily if we don't get in the way.

> general solution to this is "don't do it".

That defeats the whole point of having AORs.

> advertised. But We have agreed it is unreasonable to expect watchers to 

There is a subtle point here that seems to keep getting lost: I agree 
that we cannot *expect* a watcher to do this. I want to *allow* a 
watcher with that capability to do this. You and Jonathan, if I 
understand you correctly, don't want to allow me to build a system that 
leverages this capability.

As I tried to point out, by giving information to the watcher, a dumb 
watcher can easily do exactly the same operation that you'd like to 
force the composer to always do.

> insert the callerprefs, or that proxies will necessarily honor them.

As I've tried to point out, the "caller is clueless" case is harmless. 
The same thing happens as if you'd just published a merged document.

In many interesting cases, the PA and proxy know each other (they are 
part of the same setup, even if they are not the same piece of 
software). Thus, the publisher can know that this works - or not do it 
if it doesn't and if it cares to give the caller a choice rather than a 
"you might get one of these capability sets, but you don't get to decide 
which one".

> especially satisfying either.

With the simple composition of addition, none of this is necessary. No 
information is lost and the watcher can do exactly what the composer 
would have done, except not having to guess what information was there 
before it had to be ditched by an forced composition policy along the way.

---

From: Aki Niemi <[email-masked]>
Date: Tue, 02 Nov 2004 09:39:03 +0200

> general solution to this is "don't do it".

Don't agree.

> - say nothing about those features where there is ambiguity.

It is immensely better if you think of this in terms of availability and
willingness to communicate (the tuples have different basic status and
extension statuses, possibly vendor specific ones) instead of in terms
of support of features (as in callee capabilities).

>    capability it may want to use.

Well, what you describe above is a feature, not a bug, so my suggestion
is not to "fix" it.

I think what you're describing is if anything, a bug in offer-answer if
it doesn't allow an offerer to explicitly state what medias it
*requires* for the call setup to be successful.

Having said that though, you *could* implement your presence system
using GRUUs to get the above behavior, and that's completely all right.
But it isn't all right to mandate that as the one and *only* behavior.

> insert the callerprefs, or that proxies will necessarily honor them.

I've never agreed with mandating this, although I've always thought that
it is a reasonable alternative.

> especially satisfying either.

How about the <status> element? If there is conflicting information,
some of which may not even be understood by the composer, putting both
tuples into the final document is the only accurate representation.

Cheers,
Aki

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 03 Nov 2004 23:11:10 -0500

inline.

Henning Schulzrinne wrote:

>> far were (1) different views of the same service from different 
>> sources which could not be reconciled by the compositor, and so are 
>> presented to the watcher for reconciliation, and (2) or-of-and kind of 
>> capability declarations.
> 
> 

Right.

This is based on the premise that the characteristics and status in the 
tuple form a "loose contract". Its loose in that there are no 
guarantees, but it is meant to represent the nature of the service you 
are going to get if you hit that URI. In that regard, if I have two 
devices hiding behind an AOR, and they have different capabilities for 
media (for example), there is nothing I can concretely say about the 
nature of the service I'll get at that URI, so I say nothing.

This is consistent with the view of how callee caps are applied to an 
AOR in RFC3840, which says the same thing - if a capability is not 
shared by all components of the aor, you cannot bind it to the AOR.

If you want to advertise the component services, you need to use a 
different URI for each one (i.e., gruu). Thus, you can have it both ways.

> service capability combination that actually exists.

I very much dislike the idea of requiring in any way the watcher to have 
to do something special to reach that particular service. Why not make 
it easy and just include the gruu instead of the aor? This way, the 
caller can pick which one of these it wants without having to play the 
callerprefs guessing game.

Right.

> of with the extra information.

I think this argument you are making would only support the proposal 
here. Since the presenitty cannot know whether the watcher has caller 
prefs, I think it is bad to depend on them in any way. As a result, if 
it wants to report two components of the same service as differing, with 
a choice to the watcher, it uses a gruu so that the watcher just picks 
which URI it wants and uses it.

People seem bothered by usage of gruu here. I'm not sure I understand that.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 03 Nov 2004 23:19:53 -0500

inline.

Henning Schulzrinne wrote:

>> advertised. But We have agreed it is unreasonable to expect watchers 
>> to do that.
> 
> 

Nothing can stop a watcher from using caller prefs on a tuple.

However, the point of advertising multiple tuples in a presence document 
is to give a watcher choice in selecting one or the other. What I object 
to is telling the watcher that they do indeed have a choice, but not 
provide them the tools to make that choice. Instead, the only way that 
they can make a choice is to try and force routing by caller prefs, 
which is known to be problematic, and is why we eventually specified 
gruu. If you don't provide the tools for making the choice in the 
presence document (invoking one URI or another), then don't offer a choice.

As such, what I am saying is that there are several options for the 
compositor:

1. offer each published service as a separate tuple using the gruu for each

2. combine the two so that the tuple only contains information common 
between the two published services, and the contact URI is the aor

3. combine the two so that the tuple contains a union of information. 
This violates the "loose contract" of the presence document, but there 
are no presence police so it remains a choice.

I don't see any loss of functionality here at all. All I see is that 
there is a need to use gruu instead of caller prefs to select a service, 
something we've concluded is the right thing for other similar problems.

-Jonathan R.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 04 Nov 2004 09:04:57 -0500

Trimmed. Comment at end.

	Paul

Jonathan Rosenberg wrote:
>> URIs, as in my example of content-negotiation for HTTP), it can pick 
>> the service capability combination that actually exists.
> 
>> capabilities), it can do the merging, but know that it might not be 
>> able to steer the call, so the result may or may not be optimal. 
>> Having one tuple makes this no more or less likely.
> 
> Right.
> 
>> capabilities in presence, it just sees two tuples that look the same 
>> in the parts that it cares about and merges them. No harm done.
>>
>> Since the compositor cannot know whether the watcher is in category 
>> (1), (2) or (3), it seems inappropriate for the compositor to rule out 
>> capable watchers, particularly since not-so-bright watchers are no 
>> worse of with the extra information.
> 

I think that using GRUUs is the "best" answer here. But I think the jury 
is out on how often that will be an option. There are a couple of 
reasons they might not be:
- the registrar and/or the UA may not support GRUU.
   It certainly isn't widely supported yet. And both
   need to support it before it can be available in
   published tuples.

- in theory the PS itself could assign GRUUs for the
   tuples, and then proxy requests to them, using
   the AOR and callerprefs to steer the request. But
   this is also a big burden, and something it may not
   be reasonable to expect the PS to do.

As a result, I think, like it or not, there will be a lot of abuse of 
the system, with diverse UAs using their AOR as the tuple contact. I 
think we need to make the best of a bad situation.

Including multiple tuples with the same contact does provide the 
subscriber with extra information compared with merging them and 
supressing the differences. And this is just one option for the 
compositor. The other options you have mentioned are still available.

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 08 Nov 2004 14:51:03 -0500

To add to this: presumably this discussion is not restricted to SIP 
URIs. As I pointed out earlier, HTTP URIs have similar overloading 
properties and no GRUU-equivalent option. It seems unwise to state a 
general rule for all URI schemas for all future applications, 
particularly since the gains of doing this are rather modest, in my opinion.