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

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

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

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.


> > 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).
>
>
> 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.

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.

> 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 agree.

>     Paul

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