Subject: RE: [Sip] Handling of identical Tuples by Multiple PUAs - PUBLIS H 00

From: "George Foti (QC/EMC)" <[email-masked]>
Date: Tue, 16 Sep 2003 12:13:35 -0500

Hi Aki,
Well the newest publication policy wont win in all cases. Certainly, not in my example, as the PUA on which I forgot to logoff  will become the *newest* once in a while.

I was hoping, that similar to the usage of XCAP for setting authorization policies, we have a standardized procedure to control (ignore/consider) policy composers at the PUA level.
May be that should be added on to the authorization draft!
Forget about segementation, collision detection, etc
That is still an option for implementations but need not be standradized.

Thx/gf
> -----Original Message-----
> From: Aki Niemi [mailto:[email-masked]]
> Sent: Tuesday, September 16, 2003 11:47 AM
> To: George Foti (QC/EMC)
> Cc: [email-masked]
> Subject: Re: [Sip] Handling of identical Tuples by Multiple PUAs -
> PUBLIS H 00
> 
> 
> Hi George,
> 
> I think the composer policy could simply be that the newest 
> publication 
> wins. That way the zombie PUA's state will not propagate to the 
> watchers. Maybe this is something we ought to state in the draft?
> 
> But I think shutting down (remotely) such a zombie publisher 
> is somewhat 
> outside the scope of PUBLISH. Personally, I think this problem may be 
> more appropriately solved by designing the PUA such that it doesn't 
> zombie out, e.g., it takes user inactivity as a hint and stops 
> publication refreshes.
> 
> Other than that, I'm open to suggestions. The main reason for not 
> including event segmentation and collision detection to 
> PUBLISH was that 
> it created a lot of (unnecessary) complexity.
> 
> Cheers,
> Aki
> 
> On 16.09.2003 18:01, ext George Foti (QC/EMC):
> 
> > Hi Aki,
> > 
> > I think it should better explained in the draft how will such a
> > composer policy be set. If I have a PUA that is configured to
> > automatically publish presence information when I logon and if I
> > forgot to logoff, then how can I set the composer policy to ignore
> > that PUA or not include the information from that PUA in this case.
> > 
> > Should this not be standradized ??
> > 
> > Thx/gf
> > 
> >> -----Original Message----- From: Aki Niemi
> >> [mailto:[email-masked]] Sent: Tuesday, September 16, 2003
> >> 10:55 AM To: George Foti (QC/EMC) Cc: [email-masked] Subject: Re:
> >> [Sip] Handling of identical Tuples by Multiple PUAs - PUBLISH 00
> >> 
> >> 
> >> Hi George,
> >> 
> >> Inline.
> >> 
> >> On 15.09.2003 17:36, ext George Foti (QC/EMC):
> >>> If multiple PUAs publishes information on the same tuple,
> >> does it mean
> >>> that the ESC will have multiple entity-tags associated with
> >> that tuple,
> >>> one for each publishing PUA.
> >> 
> >> Each PUA publishes its own view of presence. Each view is assigned
> >> with an entity-tag, and each view can have tuples that overlap 
> >> across other PUAs. Resolving these "collisions" is at the hands of
> >> the composer. For example, it could automatically take preference
> >> for the "newest" view on that tuple.
> >> 
> >>> Also, the only means to stop a specfic PUA from updating
> >> that tuple is
> >>> through explictly disallowing that PUA from updating the
> >> state event for
> >>> that tuple, in the authorization policies in the ESC.
> >> 
> >> As it now stands, this requires setting the composer policy in such
> >> a way that the unwanted presence information never gets composed
> >> into the presence document.
> >> 
> >> Cheers, Aki
> >> 
> >> 
> >>> 
> >>> Thanks /gf
> >>> 
> >>> 
> >>> 
> >> 
> >> 
> 
> 

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: [email-masked]
Date: Thu, 18 Sep 2003 13:25:14 +0300

Hi, 

Inline.

 > From: ext George Foti (QC/EMC) [mailto:[email-masked]]
 > Sent: 16 September, 2003 20:14
 > To: Niemi Aki (NMP/Helsinki)
 > Cc: [email-masked]
 > Subject: RE: [Sip] Handling of identical Tuples by Multiple PUAs -
 > PUBLIS H 00
 > 
 > 
 > Hi Aki,
 > Well the newest publication policy wont win in all cases. 
 > Certainly, not in my example, as the PUA on which I forgot 
 > to logoff  will become the *newest* once in a while.

Right, but my point was that with the "nexest wins" policy you could potentially override that zombie information by publishing this same information from another PUA. However, this would permit you to override, but not delete that zombie state.
 
 > I was hoping, that similar to the usage of XCAP for setting 
 > authorization policies, we have a standardized procedure to 
 > control (ignore/consider) policy composers at the PUA level.

Agreed. I too think that the authorization of watchers is very much similar to authorization of publishers. In fact, authorizing publications for a given presentity is almost exactly the same as presence authorization but reduced to apply to only a single watcher - in this case the PA. 

In both cases, you will end up specifying which tuples selected, what sort of authentication needs to be applied, etc.

Cheers,
Aki

---

From: [email-masked]
Date: Mon, 22 Sep 2003 17:16:29 +0300

Hi George,

I support your proposal that a new XCAP usage for presence composer policy management would be useful. I don't think it should be part of the authorization usage, though. Also I hope we could proceed with SIP PUBLISH without it. 

So maybe this could be seen as the next step in the presence publication work, which could be done after the basic publishing is dealt with.

Markus 

> Certainly, not in my example, as the PUA on which I forgot to 
> logoff  will become the *newest* once in a while.
>