• Name: Presence

This Service Genre has been developed to show the functionalities and behaviours required of services to register the presence of users. Services of this Genre might be used in SUMs along with messaging services to provide user to user communications; or could be specialised to allow services themselves to register their own availability within a SUM.

• e-Framework Service Genre Version: v1.1

This Service Genre allows users to announce that they are "present" online in real time. Presence services are particularly common in the context of online messaging, but are also typically part of online collaboration also.

Often, clients of services will list an identity for a given user, and possibly also a status ("Available", "Do not Disturb" etc). With the increasing use of Voice Over IP, presence services will become more common.

A central part of presence services is the notion of a contact list. Such a list enables users of the service to register their interest in knowing the presence of other users. Typically, the user being monitored has to give consent.

As defined the Presence Service Genre is not access controlled. Any client may attempt to contact a Presence service end point. There are no authentication controls. The service end point is responsible for determining which clients can declare Presence.

The Presence Service Genre supports functions to connect users to the presence service:

• Connect - A requester must connect to a presence service in order to be 'present'. When requesters are not connected, the presence service must recognise them as "unconnected". When a requester connects, their presence becomes "active" – and other users that have been granted access to the requester's status should be informed that the requester is now "active".
• Disconnect - A connected user disconnects from the presence service. The system must now reflect that they are "unconnected". Messages need to be send to any users that have access to the disconnecting user's status to show that the user has now left the presence service.

The Presence Service Genre supports functions to show the status of the presence:

• Request Authorisation From user - This request would be made by a user to another user on the presence service. The requester is asking the responder for permission to view the responder's status – that is, to add them to their contact list. Services should forward the request onto the target user.
• Grant Authorisation to User - This request grants another user permission to view the granter’s status on the presence service. This message would be sent in response to a “Request Authorisation” message. Services should process this response so the granter appears in the other user’s contact list.
• Grant Authorisation to User - This request grants another user permission to view the granter’s status on the presence service. This message would be sent in response to a "Request Authorisation" message. Services should process this response so the granter appears in the other user's contact list.
• Deny Authorisation to User - This request denies another user permission to view the denier’s status on the presence service. This message would be sent in response to a "Request Authorisation" message. Services should process this response so that the denier does not appear in the other user's contact list.
• Revoke Authorisation - This request allows a user to revoke access to their presence status from a user that has previously been granted access. Services should process this response so that the revoker no longer appears in the other user's contact list.
• Set Status: This request allows a user to set a status on their presence. This status might be e.g. "Do not disturb", "Available for chat", or "Busy". If this request is made, services need to update all those clients that are authorised to view the user’s status, so that the status message set is processed.

No other functionality is defined. The functionality that is defined MAY be extended.

Presence Services SHOULD be used in conjunction with real time messaging services for collaboration.

Connect SHALL meet the following conditions:

• The Request SHOULD specify:
  • The identifier of the requester connecting
  • A human readable name for the requester
• The Request MAY specify:
  • A status for the requester (e.g. "Available", "Do Not Disturb").

Disconnect SHALL meet the following conditions:

• The Request SHOULD specify:
  • The identifier of the requester disconnecting

Request Authorisation From user SHALL meet the following conditions:

• The Request SHOULD specify:
  • The identifier of the source requester (originator)
  • The identifier of the target user
• The Request MAY specify:
  • The human readable name of the source requester.
  • A message from the requester to the target clarifying why they seek authorisation to monitor the target.

Grant Authorisation to User SHALL meet the following conditions:

• The Request SHOULD specify:
  • The identifier of the source requester
  • The identifier of the target user to grant authorisation status to.

Deny Authorisation to User SHALL meet the following conditions:

• The Request SHOULD specify:
  • The identifier of the source requester
  • The identifier of the target user to deny authorisation status to.

Revoke Authorisation SHALL meet the following conditions:

• The Request SHOULD specify:
  • The identifier of the source requester
  • The identifier of the target user to deny authorisation status to.

Set Status SHALL meet the following conditions:

• The Request SHOULD specify:
  • The identifier of the source requester.
  • A status for the requester (e.g. "Available", "Do Not Disturb").

Responses SHALL include error indications.

The Presence Service MAY reject a request. The Presence Service End Point is responsible for routing the Presence Message to all destinations.

Individual Service Expressions SHOULD provide models showing how clients interact with service interfaces.

None

Presence Services MAY require authentication and authorisation mechanisms.

XMPP, Skype