*** AT&T's IM Anywhere provides: OPEN with hints: Available Away Be right back Do not disturb On the phone you can also create your own custom messages CLOSED Offline (invisible, lurking) Any of the states (including Offline) can be chosen at any time. *** Jabber: 1. Unavailable (maps to CLOSED) 2. Available (maps to OPEN) with sub-statuses: - away - extended away - do not disturb - free/desiring to chat 3. Invisible Any status can be extended with a natural-language description of the status. More information at http://www.jabber.org/ietf/draft-miller-jabber-00.html#common-presence *** MSN: Busy, be right back, away, on the phone, out to lunch, appear off-line *** AOL: Idle, Away *** Yahoo: Be right back, busy, not at home, not at my desk, not in the office, on the phone, out to lunch, stepped out, custom AT&T, MSN and Yahoo all have the option of automatically setting the option to a status such as Away or Idle after a certain amount of idleness has passed. Proposal by V. Gurbani (01/13/03): OPEN Available Away (1) Busy-interrupt (2) Busy-no-interrupt (3) Busy-interrupt-authority (4) Custom (1) "Be right back", "Extended away" can all be subsumed in "Away". (2) "On the phone" can be subsumed here if the UA alternate comm- unication capablities (like IM). (3) "Do not disturb" and other domain specific semantics that Henning hinted at (e.g. "surgeon in a surgery; cannot be disturbed") can be subsumed by this sub-status. (4) Here is where other domain specific semantics that Henning mentioned can be subsumed; e.g. "professor in an oral; can be distrubed if the need is paramount". Basically, only those with authority (i.e. a secretary) can interrupt the presentity. Furthermore, I think that for "Busy-no-interrupt" and "Busy-interrupt-with-authority", the specification has to provide some guidance to the software designer. The presentity's UA should *not* even display IMs for the presentity if it in "Busy-no-interrupt" mode. Likewise, if the presentity's UA is in "Busy-interrupt-authority" status, only those IMs from an authorized user (i.e. department secretary, hospital administrator, etc.) should be displayed. Should be describable on a per-media basis. Duration: instead of lunch (e.g., min, hours, days, weeks) RFC 2778 states: STATUS is further defined by the model to have at least two states that interact with INSTANT MESSAGE delivery -- OPEN, in which INSTANT MESSAGES will be accepted, and CLOSED, in which INSTANT MESSAGES will not be accepted. PIDF states: 4.1.4. The element The element contains one of the following strings: "open" or "closed". The values "open" and "closed" has the same meaning as OPEN and CLOSED defined in RFC 2778 respectively, and stand for availability of receiving instant messages if the is for an instant messaging address. Looking across these, I see a number of general states or statuses in common: - Offline/Logged Off - Online/Available - Away - Do Not Disturb - Busy/Occupied - Not Available/Extended Away - AIM has a bunch of different ways to classify a user. I *think* these merely reflect different types of active user. - ICQ and Jabber have "Free for chat"/"Invitation to chat". - Yahoo has "Inviting to a game" For the most part I am going to ignore these for the time being. The common status values seem to bundle together particular values for an assortment of characteristics: - willingness to engage in live communication - willingness to accept messages for later delivery - media available for use - rough measure of how long current status will remain - textual description. closed should indicate no willingness to accept messages in any form. (This includes INVITE regardless of media, as well as MESSAGE.) A status of open indicates some willingness to accept messages in some form, but must be qualified with additional status values to indicate to what extent. Callerprefs feature tags are used to indicate what particular media and styles of communication are available. E.g. Using the mapping we have proposed, true would indicate that session mode IM is accepted, while true indicates voice is ok. And they may be used together if both are supported. The callerprefs 'methods' feature specifies what methods are supported. Supporting MESSAGE indicates support for page mode IM, and supporting INVITE indicates support for sessions involving some media. The 'voicemail' feature is close for voice communication, but isn't so good for other media such as IM. I propose that we define a new callerpref feature tag with a name such as "recorder", which has similar semantics to 'voicemail' but is media neutral. This should supercede 'voicemail' for both callerprefs and presence. When used with presence, it means that incoming media will be recorded for later delivery and processing by a human. It should be used in conjunction with 'automata' for full precision. * a device * one of many logical targets of communications on a device * a presentity availability: real-time, delayed (message store) how much longer, when again draft-ietf-calsch-many-xcal-02 integration of xCal only available to certain people - would be used for filtering physical presence ("in office") inactive/active - per device Do not disturb - as a third category.