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

From: [email-masked]
Date: Tue, 12 Oct 2004 23:27:42 +0300

Hi,

> -----Original Message-----
> From: ext Paul Kyzivat [mailto:[email-masked]]
> Sent: 12 October, 2004 16:21
> To: Henning Schulzrinne
> Cc: Dag Ekengren; Isomaki Markus (Nokia-TP/Espoo); Jonathan Rosenberg;
> [email-masked]
> Subject: Re: [Simple] Re: Presence Data Model: Overriding services
> (tuples)
> 
> 
> 
> 
> Henning Schulzrinne wrote:
> >> 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?
> 
> At the moment the answer is that Jonathan's data model document says 
> they must be unique.
> 

I think this has to be relaxed, and there must be something else used to provide the uniqueness. I think Jonathan uses the uniqueness for two purposes: 1. Providing the override capability. I have argued that this should be done using something else than the contact URI as the key. 2. Providing the watcher a contact using which the watcher gets to the service described by the tuple. This is very useful, but I don't think it is essential. 

Markus

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 12 Oct 2004 17:49:42 -0400

To add to this: I think it is generally a bad idea to rely on URI 
comparisons outside the protocol context, as this tends to require 
fairly detailed knowledge about URI schemes from elements that otherwise 
can and should remain ignorant about such things. Why should a composer 
be required to know whether two h323 URIs are the same? (Encoding rules 
and issues as to which parameters matter and which ones don't make 
"blind" comparison error-prone, i.e., two non-equal-looking URIs may 
indeed be the same to an entity that actually understands the scheme.)

I'm not opposed to having smart composers that are indeed clever enough 
to merge two tuples based on recognizing that the URIs are indeed 
semantically the same, but don't want every implementation to have to 
have such knowledge. (Smart composers might further recognize that 
[email-masked] and [email-masked] are aliases of each other 
and there's no point in reporting both.)

> 
> I think this has to be relaxed, and there must be something else used
> to provide the uniqueness. I think Jonathan uses the uniqueness for
> two purposes: 1. Providing the override capability. I have argued
> that this should be done using something else than the contact URI as
> the key. 2. Providing the watcher a contact using which the watcher
> gets to the service described by the tuple. This is very useful, but
> I don't think it is essential.

---

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

> indeed be the same to an entity that actually understands the scheme.)

Using the URI equivalence to decide on override is just the proposed 
default composition policy, nothing more.

It is my suspicion that this is a problem in theory and not in practice. 
By the time we have systems running composition across URIs for services 
they don't even understand, my guess is that you'll have the ability to 
express composition policies that can do whatever you really want.

> and there's no point in reporting both.)

As above, perhaps the problem here is that folks are interpreting the 
model to imply that you have to do composition differently based on 
whether two services are "conflicting" - i.e., have the same URI, or 
not. You don't have to. This is a suggested default policy to allow what 
seems to be a desired feature to take place in an interoperable way 
prior to the arrival of specifications that allow a user to control 
their composition policy.

-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: Paul Kyzivat <[email-masked]>
Date: Wed, 13 Oct 2004 10:31:56 -0400

Jonathan Rosenberg wrote:
> 
>> I'm not opposed to having smart composers that are indeed clever 
>> enough to merge two tuples based on recognizing that the URIs are 
>> indeed semantically the same, but don't want every implementation to 
>> have to have such knowledge. (Smart composers might further recognize 
>> that [email-masked] and [email-masked] are aliases of each 
>> other and there's no point in reporting both.)
> 

I fear we are slipping back into the same problem with composition that 
we had with "what is a tuple" - that there are widely divergent views on 
the subject that have not been exposed, discussed, or resolved.

I don't know of any simple policy that will resolve conflicting 
information in a way that would be halfway sensible in a range of 
reasonable use cases. The only answer that is "simple enough" and that 
won't mess up is simple catenation - providing all the info to the 
watcher. If we can support that, then we can go spend another couple of 
years working on more sophisticated policies.

	Paul

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 17 Oct 2004 23:33:12 -0400

> express composition policies that can do whatever you really want.

This is obviously non-falsiable, but I'm pretty uncomfortable with this. 
I can see all kinds of URIs that are going to be common in presence 
documents, such as jabber and H.323 URIs, that not all composers will 
know what to do with. If I have a new URI scheme that is meaningful to 
my watchers, should I have to wait until my service provider or software 
vendor gets around to supporting it?

All tuples are "alternative ways of reaching a presentity". In many 
cases, such as the tel URI case discussed, but also with im:, for 
example, they may lead to the same IP address and port after some set of 
bindings. There is nothing new, confusing or dangerous here.

Henning