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

From: [email-masked]
Date: Mon, 11 Oct 2004 13:12:20 +0300

Hi all,

I have some questions on the overriding functionality described in presence data model draft chapters 6.2 and 7.2.2. The draft says:

   Indeed, a client might
   explicitly choose to publish with the same service URI as another
   client, if its goal is to explicitly override the service of the
   other.  Using the same service ID is the "hint" to the presence
   server that conflicting data exists, and one needs to be chosen.

The assumption in the draft is that each SIP service is represented by a contact that is GRUU. Assuming an event package whereby a PUA can learn about publications of other PUAs before any composition happens, this is a good model since it gives an unique handle to each service, and allows PUAs to really do explicit overrides.

However, my concern is that there are currently many SIP presence systems being worked on which do not support GRUU generation. One example is 3GPP Release 6 IMS. In those systems the SIP service contact address is supposed to be the AoR. 

Would it be possible to add a source-id element for the services, so that the presence compositor would know whether services are supposed to be in the same category or not? The rule would be that if _either_ contact URI _or_ source-id is the same, the "newer" publication will explicitly override the old one. In this way overriding would become possible also for those implementations which can't use GRUU. Or is there some other way to enable this? And if you don't like the name source-id, just invent something else. I'm not sure if source-id that Jonathan had as an open issue is the same as here or something different. My interest is just the semantic related to overriding. 

Markus     

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 11 Oct 2004 16:34:41 -0400

[email-masked] wrote:

> Hi all,
> 
> I have some questions on the overriding functionality described in
> presence data model draft chapters 6.2 and 7.2.2. The draft says:
> 
> Indeed, a client might explicitly choose to publish with the same
> service URI as another client, if its goal is to explicitly override
> the service of the other.  Using the same service ID is the "hint" to
> the presence server that conflicting data exists, and one needs to be
> chosen.
> 
> The assumption in the draft is that each SIP service is represented
> by a contact that is GRUU. Assuming an event package whereby a PUA
> can learn about publications of other PUAs before any composition
> happens, this is a good model since it gives an unique handle to each
> service, and allows PUAs to really do explicit overrides.
> 
> However, my concern is that there are currently many SIP presence
> systems being worked on which do not support GRUU generation. One
> example is 3GPP Release 6 IMS. In those systems the SIP service
> contact address is supposed to be the AoR.

Is it too late to change this in R6?

That said, I do think we need to address the case of what the server 
should be doing if the contact URI is the AOR. Clearly it can know that 
the URI is the AOR, and probably shouldn't ovverried each published 
service with each other.

> 
> Would it be possible to add a source-id element for the services, so
> that the presence compositor would know whether services are supposed
> to be in the same category or not? The rule would be that if _either_
> contact URI _or_ source-id is the same, the "newer" publication will
> explicitly override the old one. In this way overriding would become
> possible also for those implementations which can't use GRUU. Or is
> there some other way to enable this? And if you don't like the name
> source-id, just invent something else. I'm not sure if source-id that
> Jonathan had as an open issue is the same as here or something
> different. My interest is just the semantic related to overriding.

I think this takes us back into the never-ending madness of being able 
to explicitly name and list services, i.e., "telephony", "voip", etc.

I'd propose something different. I would instead say that, if the 
compositor sees an AOR as the published contact URI, it means that the 
PUA does not believe it is reachable directly, only through the AOR. 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.

Does that work?

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 11 Oct 2004 19:02:27 -0400

Jonathan Rosenberg wrote:
> PUA does not believe it is reachable directly, only through the AOR.

Or at least is only *willing* to be reached thru the AOR.

 > In

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.

	Paul

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 13 Oct 2004 06:07:26 -0400

inline.

> compositor would be forced to either override, or somehow merge them.

Sorry, let me clarify.

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.

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

}

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.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 13 Oct 2004 11:58:41 -0400

>> compositor would be forced to either override, or somehow merge them.

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

> 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

>      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