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

[Paul Kyzivat <pkyzivat at cisco.com>]

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 alice at example.com and alice.smith at example.com are aliases of each 
> > other 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.

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


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