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

[Henning Schulzrinne <hgs at cs.columbia.edu>]

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 
alice at example.com and alice.smith at example.com 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.

_______________________________________________
Simple mailing list
Simple at ietf.org
https://www1.ietf.org/mailman/listinfo/simple