Subject: [Simple] Different verbosity levels of presence information

From: [email-masked]
Date: Wed, 26 Sep 2001 17:10:51 +0300

Hi,

I have a couple of basic questions about the subscription of presence
information. 

What I think would be required is that a watcher is able to subscribe to
different "verbosity levels" of presence information of a given presentity.
If the presence document is large having a lot of attributes and changing
often, it might be an overkill in wireless and small handset environment.
That's why it would be nice to be able to subscribe either to the full or
partial presence state of a presentity.

Can this be done by doing different SIP event packages with different levels
of presence information associated with them or is there some
architecturally better way? The watcher would then decide which one of them
to subscribe.

Another question is about subscription to a list of presentities (buddy list
etc.). I guess there is no sound way of doing that in a single SIP subscribe
transaction, so again some kind of sub-package would be needed? But even in
that case how is the list of URIs delivered? Is this outside the scope of
SIP? Again the problem raises from the desire to protect the limited
bandwith available over the air.

Best Regards,
	Markus

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 2 Oct 2001 03:18:16 -0400

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, September 26, 2001 10:11 AM
> To: [email-masked]
> Subject: [Simple] Different verbosity levels of presence information
> 
> 
> Hi,
> 

Full state/partial state is one thing, used just for the purposes of message
efficiency. Another issue is subscription to a subset of the state of the
presentity. For example, if a presentity has eight contact addresses, I
might like to receive notifications only when there are changes in the IM
contact, and only receive information about that contact (whether its
through full state or partial updates). This would reduce the size of the
NOTIFYs, and also their frequency.

The ability to restrict subscriptions in the second manner is described in
the presence spec as "filters". There are documents carried in the bodies of
subscribe. There are no defined filters at this time, and its still a
somewhat vague concept. When we get to the point where presence docs really
do contain a lot of stuff, we can figure out exactly what the requirements
are and begin defining them. All the presence spec needs to do is leave a
place holder for them, which it does.

> architecturally better way? The watcher would then decide 

It would be done with filters, as I mention above.

> bandwith available over the air.

I would envision this working much like a regular sip invitation to a URL
that happens to be a group. The identities of the group participants would
be established out of band, so that the request URI in the subscribe merely
identifies the group. Whether this is a sub-package, a new package, or even
just the regular presence package, remains to be discussed. I would tend to
think its a sub-package (group subscriptions make sense for all packages).
What the data format is for the NOTIFY is a good question...

-Jonathan R.

---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com