Subject: [Simple] We need a clear description of Presence

From: "Li Hua Tang" <[email-masked]>
Date: Mon, 18 Mar 2002 10:35:47 +0800

Hi, all

We need a clear description of Presence, not just described as
online/offline/away... What is standardized in draft-ietf-impp-cpim-pidf-01
is not sufficient.

Presence is defined in RFC2778 as the communication state of a user. In
fact, it's a broad concept. The presence information can include following
aspects:
1. online/offline/away status,
2. user willingness: do not disturb/willing to chat,
3. available communication device status: open/close,
4. geography location,
5. presence history is also very useful
and more.

How can we descibe all this information in a unified way?

Your comments are welcome.

Best regards,

Tang Lihua
Research Member, Infrastructure Technology
IBM China Research Lab.
Phone: (8610)62986677-542 Tie line: 905-542
Email:  [email-masked]

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 18 Mar 2002 20:15:40 -0500

Comments below.

	Paul

> How can we descibe all this information in a unified way?

It hasn't been discussed much, but there is considerable overlap between
presence and callerprefs. Callerprefs provides a way to qualify the
Contact addresses registered for an address-of-record. For instance,
the media, classes of calls, and priorities that are acceptable. Also
q-values permit prioritizing among alternative contact addresses, so that
for instance voicemail can be ranked higher than direct connection for
some types of calls.

This hasn't been integrated into the default presence document, but
it ought to be. The presence document as currently defined has the
contact addresses and the q-values, but not the other qualifying information.

This added information can be used to describe many, but not all,of the 
things mentioned above. For instance, suppose you have a device capable of 
both voice and chat. Normally you might register as:

	REGISTER ...
	...
	Contact: sip:your@device;media="audio/*,message/*"

If you receive a voice call, and want to indicate unavailability for voice, 
but continued availability to chat, you might reregister:

	REGISTER ...
	...
	Contact: sip:your@device;media="message/*"

They you would update this again at completion of your call when
you are again willing to receive voice.

Given a suitable linkage between the registrar and presence server,
then these changes ought to be reported as presence changes.

This isn't a complete solution to the issues you describe. It can be
viewed as extra capability that reduces the problem, or it may be
considered as making the problem larger. I think it is essential that
presence and callerprefs be harmonized.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 19 Mar 2002 00:13:54 -0500

Paul Kyzivat wrote:

> presence and callerprefs be harmonized.

I think you want the presence document to be able to support the
expressiveness which caller preferences has. However, I don't think you
want a user to explicitly set their presence by registrations. Rather,
the presence server would compose their registrations (including caller
prefs data), with their uploaded presence docs (which provide explicit
presence indications), to generate a final composed presence document.

Using caller prefs for the UA to explicitly set presence is bad, since
it depends on the UA knowing the policy of the presence server in its
construction of the presence doc. By being explicit, i..e, "set my
presence to available", that problem is avoided.

That said, I think much work is needed to build upon PIDF and add status
values and other parameters needed for a more expressive system. At the
very least, we need some statuses for IM. I would really like to see
such a work item picked up by SIMPLE.

Thanks,
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

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 19 Mar 2002 11:17:15 -0500

> presence to available", that problem is avoided.

Since there is no standard for uploading a presence document,
a UA *always* has to know the policy the presence server uses to
construct or acquire the presence document. Knowing that the presence
server will construct the document in a way consistent with the registration
is no worse than knowing that it gets it by ftp upload to a particular
file, or by payload in a REGISTER message.

Use of callerprefs requires registration. Requiring that the UA also
format and upload a presence document each time simply adds to the
burden on both it and the servers - at least in the case that presence
server and registrar are colocated. It also can result in divergence
of the two states, through error or negligence.

> such a work item picked up by SIMPLE.

agreed.

	Paul

---

From: "Niemi Aki (NET/Espoo)" <[email-masked]>
Date: Wed, 27 Mar 2002 17:11:57 +0200

Hi All,

Based on the discussions at the SIMPLE session at the IETF53 meeting, do 
we now have consensus that the approaches we're studying for the message 
transport inside an IM session are in fact:

	- SIP MESSAGE (with a specific "feature set")
	- IMSX (draft-mrose-simple-exchange-01.txt)

At least this was my impression from the presentations/discussions there.

I assume this means that IMTP as such is not considered any more, but an 
updated version of draft-ietf-simple-im-session-00.txt that addresses 
the issues Jonathan presented, may instead be expected?

Cheers,
Aki