Subject: [Simple] PS = back-to-back PA + registrar?

From: "Li Hua Tang" <[email-masked]>
Date: Thu, 7 Feb 2002 16:51:51 +0800

Hi all,

It's generally accepted that a PS is a combined PA/Proxy/Registrar. During
our work we find that it's difficult for PS to change the role from proxy
to PA or otherwise, when the presentity changes status from online to
offline or otherwise. (In our understanding, PS acts as a proxy if the
presentity is online and acts as a PA when the presentity goes offline.)

Maybe a back-to-back PA + registrar is a better combination. It can hide
the complexity for PS to handle the subscriptions. Assume once the
presentity comes online, it registers to the PS, with or without the
presence documents or CPL. PS generates a subscription to this registered
presentity (not considering the third party registration) and gets presence
info from the notification created by the presentity. All the presence info
are stored in the backstage database and updated with the notifications.
When a watcher invokes a subscription to the PS, the PS can access to this
database to get current presence info of the specific presentity. It's a
simple model. The PS is an end presentity to any watcher and also an end
watcher for any presentity. It can low down the number of transactions
exsiting in the PS.
Another advantage of this model is that through this way the PS can provide
flexible features to higher application level. For example, all the
presence info are available from the PS.

In this case, it requires the high performance of database management. It
needs to update the presence info according to the notifications from
presentities and it must fire an event to notify the PS to generate a
notification to the watchers. Sometimes the database manager must provide
merging presence info when querying.

A question puzzles me in this condition. If a subscription with buddylist
event package is received, the PS handles it acting as a PA, not a BLSS. Is
it reasonable?

What's your opinion of this model? Any comment is highly anticipated!

Best regards,

Tang Lihua
Research Member, Infrastructure Technology
IBM China Research Lab.

4/F, HaoHai Building, No.7, 5th Street, Shangdi, Beijing 100085
Phone: (8610)62986677-542
Tie line 905-542
Email:  [email-masked]

_______________________________________________
simple mailing list
[email-masked]
http://mailman.dynamicsoft.com/mailman/listinfo/simple

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 11 Feb 2002 16:06:51 -0500

> presentity is online and acts as a PA when the presentity goes offline.)

It should work. Can you identify specific problems?

> presence info are available from the PS.

This is certainly a valid model. It has been discussed on the list, and
is certainly allowed. The specification does not mandate implementation
architectures, it merely provides tools. I don't think there is anything
in the spec that would prevent this from working adequately well. Maybe
just a mention encouraging user agents to support it....

> event package is received, the PS handles it acting as a PA, not a BLSS.

A BLSS is a type of PA; its one that handles that particular event
package.

-Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com
_______________________________________________
simple mailing list
[email-masked]
http://mailman.dynamicsoft.com/mailman/listinfo/simple