[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



Hi,

Paul Kyzivat wrote:
> 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 completely agree with this. I think the ability for a PUA to explicitly override something as compared to just providing it to the composition black box is important. What is needed for this is a way to explicitly address a "raw" published tuple (raw meaning that it has not gone through the composition logic yet). Doing this through a unique contact address is fine, but this is not always possible. Can't there simply be some sort of identifier within the tuple that could be used for the same? If a tuple is published with the same identifier as an existing tuple, it is considered to be an override. This is exactly the same logic as is proposed to be based on contact for tuples and device-id for devices. I don't understand why we couldn't allow this for the reason that unique contact is sometimes hard to get. Also I don't think this has anything to do with identifying services which some people don't like. This would just be meta-data related to the tuple, not something that watchers would use.   
 
> 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.

I think we should solve this part of the problem now.

Markus

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