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

From: Aki Niemi <[email-masked]>
Date: Tue, 16 Sep 2003 18:46:47 +0300

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: Sean Olson <[email-masked]>
Date: Tue, 16 Sep 2003 13:19:02 -0700 (PDT)

I don't think this is something that the composer
policy should necessarily try to solve. A more
intelligent client implementation seems like the
answer here. Collisions are a different issue and
centralized policy is probably the only tenable
solution.

--- Aki Niemi <[email-masked]> wrote:
> Sip mailing list 
> https://www1.ietf.org/mailman/listinfo/sip

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

---

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

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.

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