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

[Paul Kyzivat <pkyzivat at cisco.com>]

Jonathan Rosenberg wrote:
> inline.
>
> Paul Kyzivat wrote:
>
> >  > In
> >
> > > such a case, there is simply no ability to override at all. The 
> > > compositor would basically assume that each published service is 
> > > separate and non-overlapping. If you want override, implement gruu.
> >
> >
> >
> > I don't follow you here. They can't be separate and non-overlapping 
> > services because they all have the same conctact address. So the 
> > compositor would be forced to either override, or somehow merge them.
>
>
> Sorry, let me clarify.

The clarification didn't help. :-(
More explanation below.

> When a compositor sees two services, it needs to decide whether or not 
> they are describing the same service or different ones. This distinction 
> is really only important in the absence of explicit composition policies 
> defined by users/admins. Absent explicit policies, it allows us to have 
> a simple default which says that separate services are reported 
> separately and if you have two descriptions of the same service, you 
> should pick the most recent one.

OK - restating:

  if (service A and service B are same service)
     composition includes more recent of A and B
  else (service A and service B are different services)
     composition includes both service A and service B

> If you had explicit policies, you could direct the server to have one 
> service overried another irregardless of the service URI.
>
> So, my point was this. Again only thinking about the default policy in 
> the absence of somethign explicit, here is the logic:
>
> if(service A URI == service B URI) {
>
>   if(service A URI == AOR) {
>
>      service A and B are different services
>
>   } else {
>
>      service A and B are the same service
>
>   }
>
> } else {
>
>      service A and B are different services
>
> }

Combining this logic with my restated logic above,

  if (service A URI == service B URI == AOR)
     composition includes both service A and service B

But this violates your rule about having two services with the same 
service URI.

I doubt this was what you intended. So I am still confused.

	Paul

> based on this logic, the compositor would then apply the default 
> composition - which is that two descriptions of the same service are 
> resolved by taking the most recent one.
>
> That means that, if a user wants to override another publication and 
> there is no ability to specify an explicit composiiton policy, the 
> published contact URI would need to be the same and NOT be an AOR.
>
> HTH,
> Jonathan R.


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