Subject: RE: [Simple] Re: Presence Data Model: Overriding services (tuples)

From: "Dag Ekengren" <[email-masked]>
Date: Tue, 12 Oct 2004 10:01:11 +0200

Paul Kyzivat wrote:

> > In
>> such a case, there is simply no ability to override at all. The
>> compositor would basically assume that each published service is
>> separate and non-overlapping. If you want override, implement gruu.
>
>I don't follow you here. They can't be separate and non-overlapping
>services because they all have the same conctact address. So the
>compositor would be forced to either override, or somehow merge them.
>
>	Paul
>

Out of curiosity, is there anything that says that the contact uri must
be unique within the composed document? With the service tuples being
identified by tuple-id:s, is there anything preventing to such tuples
having the same contact uri:s?

In an earlier discussion, I argued that the tuple-id:s are not
necessary, but this may be the case where they are needed.

/Dag

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 12 Oct 2004 07:47:22 -0400

> having the same contact uri:s?
There are several plausible scenarios where you could have the same 
contact URI appear twice. For example, limitations in the capabilities 
description may not allow you to express "this URI can do A1,A2,A3  OR 
it can do B1,B2,B3" (but not random combinations of sub-capabilities 
such as A1,B1).

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 12 Oct 2004 09:21:00 -0400

>> having the same contact uri:s?

At the moment the answer is that Jonathan's data model document says 
they must be unique.

> it can do B1,B2,B3" (but not random combinations of sub-capabilities 

I am torn about this. I fully agree with this example, and repeating the 
contact address in two tuples seems the most straightforward way to 
represent it.

OTOH, I agree that there are benefits to having the addresses be unique. 
Specifically, its hard to imagine how a composition policy could work if 
two tuples with the same contact could represent *either* an override or 
two services available simultaneously at the same address.

I don't know if this can be resolved without first tackling the problem 
of composition policy. But I think that will be a long time in coming.

I guess my inclination is to *allow* duplicates for now, and leave it as 
a later exercise to possibly restrict them as part of a composition 
policy. I don't think the presence of duplicates should be a problem for 
watchers.

	Paul

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 12 Oct 2004 16:24:44 -0400

> At the moment the answer is that Jonathan's data model document says 

Hmm; I thought the discussions in the design team allowed them to be 
non-unique. I don't see how this can realistically be enforced. I seem 
to recall discussions that this non-uniqueness wouldn't really affect 
UIs, since you'd just get two icons, which just happened to lead to the 
same URI, possibly qualified with different prescaps.

My basic concern is that, as of right now, the only composition policy 
we have specified (implicitly) is concatenation. I'm really worried if 
we built systems that break badly for this 'null' composition policy.

> two services available simultaneously at the same address.

That would have to be marked up explicitly in any event. For example, 
you may want to say "if my sip URI is available, don't show my tel URI 
tuple". I don't see how this is affected by having duplicate URIs.

> policy. I don't think the presence of duplicates should be a problem for 

I agree.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 13 Oct 2004 06:16:57 -0400

Please, no.

This is right back to where we started. How, then, should a watcher 
interpret a document where there are two services with the same URI? As 
soon as the answer is "several plausible scenarios", we have invalidated 
the idea of the presence model, which is that the document has one and 
only one meaning.

I don't think the spec is explicit that each service in the document has 
to have a different URI, but that has been the intent.

I do not want to add a feature to the data model which basically allows 
for OR-of-AND style capability decalarations, which is the motivating 
use case you are indicating below. We have never had that to date for 
any of our capability decalration specs, either SDP or callee-caps (RFC 
3840). Thus, I see no need to permit its representation in a presence 
document right now. If we want it, it can be added later in any number 
of ways that do not require the inclusion of multiple <service> elements 
with the same URI.

The main point though, and this cannot be overstated - is that the 
problem we've had to date with "what is a tuple" is that we were never 
willing to be concise and make a decision about what a piece of data 
really meant in a document. That path led to interoperability problems. 
The path we are on now is to make concrete statements about what the 
document means. Choice of interpretation is our enemy here! I am really 
worried that folks are trying to push this work back down the path to 
where we were before, and I think its a big mistake. Please don't.

-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: Wed, 13 Oct 2004 06:26:21 -0400

Henning Schulzrinne wrote:

> non-unique. I don't see how this can realistically be enforced. 

The enforcement is only within a document. The entity that creates the 
document, be it the compositor or the publishers, just doesn't put 
multiple services with the same URI. I dont understand why this is hard.

> we built systems that break badly for this 'null' composition policy.

I don't understand here. There is a whole section in the data model that 
talks about the things one can do for composition policy, including the 
pivot concepts that you yourself introduced. This is far from just 
concatenation.

I also don't see how anything breaks here by having unique URI. Indeed, 
there is clear breakage when they are not. As Paul pointed out:

> OTOH, I agree that there are benefits to having the addresses be unique. Specifically, its hard to imagine how a composition policy could work if two tuples with the same contact could represent *either* an override or two services available simultaneously at the same address. 

The problem is much worse than just composition policy. Its any 
recipient of a presence document. If we can't differentiate between 
"there is one service with an or-of-and capabilities" and "these two 
services are alternates", watchers of any sort, be they network 
applications or PC clients, and compositors, won't be able to sort out 
the difference, and each will reach differing conclusions about what the 
document means. That is the very problem that the data model is seeking 
to avoid!

>>> contact URI appear twice. For example, limitations in the 
>>> capabilities description may not allow you to express "this URI can 
>>> do A1,A2,A3  OR it can do B1,B2,B3" (but not random combinations of 
>>> sub-capabilities such as A1,B1).
>>
>>
>>
>> I am torn about this. I fully agree with this example, and repeating 
>> the contact address in two tuples seems the most straightforward way 
>> to represent it.
>>
>> OTOH, I agree that there are benefits to having the addresses be 
>> unique. Specifically, its hard to imagine how a composition policy 
>> could work if two tuples with the same contact could represent 
>> *either* an override or two services available simultaneously at the 
>> same address.
> 
> 

The point Paul is saying is that once you have multiple ones, you cannot 
determine why you have multiple ones in a document. Does it mean these 
are alternates which represent conflicting views of the same service 
(which you have proposed in a separate thread for <person>), or does it 
mean that this is one larger service which multiple simultaneous 
capability sets?

>>
>> I guess my inclination is to *allow* duplicates for now, and leave it 
>> as a later exercise to possibly restrict them as part of a composition 
>> policy. I don't think the presence of duplicates should be a problem 
>> for watchers.
> 
> 
> I agree.

No, I disagre, for the same reason I've been repeating in my other 
mails. Choice of interpetation is our enemy. You cannot just allow it 
and then define what it means later on.

-Jonathan R.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 13 Oct 2004 10:24:54 -0400

> the idea of the presence model, which is that the document has one and 

There have been two meanings suggested for this case:

- "alternative views" - data from different sources, about the same
   resource. The data may either be complementary or conflicting.
   Everybody seems to agree that we can have this arriving at the
   composer in different presence documents that are somehow to be
   composed. Henning is suggesting that it must also be possible for
   this to be the case in a single document - generally as the result
   of naive composing. This leaves the hard composition problem to
   the watcher.

   I think Henning makes a good case that this is needed. We aren't
   going to be able to "solve" the hard composition problems any time
   soon. Naive solutions that simply throw away one or the other of
   the competing views aren't going to yield acceptable results.

- "OR-of-AND" - data from (presumably) a single source that expresses
   a more complex relationship among capabilites than we can otherwise
   represent. More on this one below.

These two uses (if present) require *different* interpretation. Hence 
they need to be distinguishable by a watcher.

> to have a different URI, but that has been the intent.

I guess it was your intent. It wasn't mine, and I don't think it was 
Henning's.

> of ways that do not require the inclusion of multiple <service> elements 

I wanted this is callee-caps. (I looked into ways to revise the rules 
for registration so that contacts could be repeated with different sets 
of capabilities.) But gave up on it, as too hard to get approved.

One of the reasons gave up there was because presence was coming, which 
had the potential for a much richer representation, without the same 
historical constraints.

Later in this thread David Boyer asked for an example of this. One that 
comes to mind is:

- I can do voice and video, or I can do gaming, at this address.
   Both are negotiated using SIP and SDP.

Another:

- This contact can do regular voice, it can do PTT, but not both
   on the same call. (Seems like a poor way to design things, but
   also seems to be a common restriction.)

> where we were before, and I think its a big mistake. Please don't.

I don't want to do that.

I agree that there is a problem if we permit tuples with the same 
contact to mean both of the above, without any way of distinguishing.

I think the need to represent "alternative views" in one document is 
more pressing. So I propose that we permit this usage, and postpone 
consideration of how to represent "OR-of-ANDs".

As long as there is only this one interpretation I don't think we have 
set back progress at all. In fact, it permits us to move forward to 
useful products without defining how to do composition more 
sophisticated than catenation.

	Paul