Internet DRAFT - draft-houri-simple-arch
draft-houri-simple-arch
SIMPLE Group A. Houri
Internet-Draft IBM
Expires: November 30, 2003 A. Audu
Alcatel
T. Hiller
Lucent
T. Hansen
AT&T Laboratories
June 2003
SIP/SIMPLE Based Presence and IM Architecture
draft-houri-simple-arch-03
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 30, 2003.
Copyright Notice
Copyright (C) The Internet Society (2003).
Abstract
This document collects information required for the creation a
complete Presence and IM system using SIMPLE and other IETF
Houri, et al. Expires November 30, 2003 [Page 1]
Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003
protocols. This information has been spread out across numerous
other internet drafts and RFCs. The document tries to put everything
together, discussing the servers involved, security mechanisms, call
flows, etc. The goal of this document is that someone, who is not an
expert in the IETF protocols, can read this document and understand
how the IETF protocols can be used for building a complete system and
how it should work. SPECIFCATIONS SECTION TO BE UPDATED SHORTLY
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. High Level Architecture . . . . . . . . . . . . . . . . . . . 7
4.1 Single Server System . . . . . . . . . . . . . . . . . . . 8
4.2 Multiple Server System . . . . . . . . . . . . . . . . . . 9
5. Specifications . . . . . . . . . . . . . . . . . . . . . . . . 9
5.1 IMPP/CPIM Specifications . . . . . . . . . . . . . . . . . 9
5.2 SIMPLE Group Specifications . . . . . . . . . . . . . . . 10
5.2.1 Presence . . . . . . . . . . . . . . . . . . . . . . . 10
5.2.2 Data Representation and Access Control . . . . . . . . 11
5.2.3 Messaging . . . . . . . . . . . . . . . . . . . . . . 12
5.2.4 Lists - Events and Manipulation . . . . . . . . . . . 12
5.2.5 Publish . . . . . . . . . . . . . . . . . . . . . . . 12
5.2.6 Watchers . . . . . . . . . . . . . . . . . . . . . . . 13
5.2.7 SIMPLE/CPIM Related Docs . . . . . . . . . . . . . . . 13
5.2.8 Relevant SIP Group Specifications . . . . . . . . . . 13
5.2.9 Relevant SIPPING Group Specifications . . . . . . . . 14
5.3 Basic Functional Model . . . . . . . . . . . . . . . . . . 15
5.4 Basic Flows . . . . . . . . . . . . . . . . . . . . . . . 19
5.4.1 Registration . . . . . . . . . . . . . . . . . . . . . 19
5.4.2 Sending and Receiving Messages . . . . . . . . . . . . 21
5.4.2.1 Sending a Pager Mode Message . . . . . . . . . . . 22
5.4.2.2 Receiving a Pager Mode Message . . . . . . . . . . 25
5.4.2.3 Deferred Message Delivery to IM Application . . . 28
5.4.2.4 Delivery of Deferred Message to User . . . . . . . 30
5.4.2.5 Logging Pager-Mode Messages . . . . . . . . . . . 32
5.4.2.6 Establishing a Point-to-Point Messaging Session . 32
5.4.2.7 Sending a Message Within a Messaging Session . . . 35
5.4.2.8 Receiving a Message Within a Messaging Session . . 37
5.4.2.9 Adding a Member to an Established Session . . . . 37
5.4.2.10 Transitioning a Two Party Session to a
Multiparty Conference and Adding a Third
Participant . . . . . . . . . . . . . . . . . . . 37
5.4.2.11 Adding a User to a Multiparty Session . . . . . . 41
5.4.2.12 Leaving a Messaging Session . . . . . . . . . . . 42
5.4.2.13 Logging Messaging Session Messages . . . . . . . . 42
5.4.3 Group Operations . . . . . . . . . . . . . . . . . . . 42
Houri, et al. Expires November 30, 2003 [Page 2]
Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003
5.4.3.1 Creating a Group . . . . . . . . . . . . . . . . . 43
5.4.3.2 Deleting a Group . . . . . . . . . . . . . . . . . 45
5.4.3.3 Modifying a Group . . . . . . . . . . . . . . . . 46
5.4.3.4 Retrieving a Group . . . . . . . . . . . . . . . . 47
5.4.3.5 Publishing User Management Policy . . . . . . . . 48
5.4.4 Access Deferred Messages . . . . . . . . . . . . . . . 49
5.4.5 Presence Operations . . . . . . . . . . . . . . . . . 50
5.4.5.1 Publishing Presence . . . . . . . . . . . . . . . 51
5.4.5.2 Subscribing to Presence (or a Presence List) . . . 52
5.4.5.3 Receiving a Presence Notification . . . . . . . . 53
5.4.5.4 Querying Presence . . . . . . . . . . . . . . . . 54
5.5 Security and Privacy Issues in IM/Presence Architecture . 54
5.5.1 Authentication . . . . . . . . . . . . . . . . . . . . 55
5.5.1.1 Challenge-Response Access Authentication
Mechanism . . . . . . . . . . . . . . . . . . . . 55
5.5.1.2 Limitations . . . . . . . . . . . . . . . . . . . 57
5.5.2 Authorization . . . . . . . . . . . . . . . . . . . . 57
5.5.3 Integrity And Confidentiality . . . . . . . . . . . . 57
5.5.3.1 Privacy . . . . . . . . . . . . . . . . . . . . . 57
5.5.3.2 AAA Service . . . . . . . . . . . . . . . . . . . 59
5.6 Types of Deployments . . . . . . . . . . . . . . . . . . . 59
5.6.1 Enterprise (Single Domains of Trust) . . . . . . . . . 60
5.6.1.1 Definition . . . . . . . . . . . . . . . . . . . . 60
5.6.1.2 Components & Diagrams . . . . . . . . . . . . . . 60
5.6.1.3 Scenarios . . . . . . . . . . . . . . . . . . . . 60
5.6.1.3.1 Locating Other Servers . . . . . . . . . . . . 60
5.6.1.3.2 Creating Connections . . . . . . . . . . . . . 60
5.6.1.3.3 Authentication . . . . . . . . . . . . . . . . 60
5.6.1.3.4 State Replication . . . . . . . . . . . . . . 60
5.6.1.3.5 Advanced Configurations & Scenarios . . . . . 61
5.6.1.3.5.1 Firewalls . . . . . . . . . . . . . . . . 61
5.6.1.3.5.2 Wireless . . . . . . . . . . . . . . . . . 61
5.6.1.3.5.3 Gateways . . . . . . . . . . . . . . . . . 61
5.6.2 Federated Systems . . . . . . . . . . . . . . . . . . 61
5.6.2.1 Definition . . . . . . . . . . . . . . . . . . . . 61
5.6.2.2 Components & Diagrams . . . . . . . . . . . . . . 61
5.6.2.3 Scenarios . . . . . . . . . . . . . . . . . . . . 61
5.6.2.3.1 Locating Other Servers . . . . . . . . . . . . 61
5.6.2.3.2 Creating Connections . . . . . . . . . . . . . 61
5.6.2.3.3 Authentication . . . . . . . . . . . . . . . . 61
5.6.2.3.4 State Replication . . . . . . . . . . . . . . 62
5.6.2.3.5 Advanced Configurations & Scenarios . . . . . 62
5.6.2.3.5.1 Firewalls . . . . . . . . . . . . . . . . 62
5.6.2.3.5.2 Wireless . . . . . . . . . . . . . . . . . 62
5.6.2.3.5.3 Gateways . . . . . . . . . . . . . . . . . 62
5.6.3 Public Systems Interconnecting . . . . . . . . . . . . 62
5.6.3.1 Definition . . . . . . . . . . . . . . . . . . . . 62
5.6.3.2 Components & Diagrams . . . . . . . . . . . . . . 62
Houri, et al. Expires November 30, 2003 [Page 3]
Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003
5.6.3.3 Scenarios . . . . . . . . . . . . . . . . . . . . 62
5.6.3.3.1 Locating Other Servers . . . . . . . . . . . . 62
5.6.3.3.2 Creating Connections . . . . . . . . . . . . . 62
5.6.3.3.3 Authentication . . . . . . . . . . . . . . . . 63
5.6.3.3.4 State Replication . . . . . . . . . . . . . . 63
5.6.3.3.5 Advanced Configurations & Scenarios . . . . . 63
5.6.3.3.5.1 Firewalls . . . . . . . . . . . . . . . . 63
5.6.3.3.5.2 Wireless . . . . . . . . . . . . . . . . . 63
5.6.3.3.5.3 Gateways . . . . . . . . . . . . . . . . . 63
5.6.4 Open systems . . . . . . . . . . . . . . . . . . . . . 63
5.6.4.1 Definition . . . . . . . . . . . . . . . . . . . . 63
5.6.4.2 Components & Diagrams . . . . . . . . . . . . . . 63
5.6.4.3 Scenarios . . . . . . . . . . . . . . . . . . . . 63
5.6.4.3.1 Locating Other Servers . . . . . . . . . . . . 64
5.6.4.3.2 Creating Connections . . . . . . . . . . . . . 64
5.6.4.3.3 Authentication . . . . . . . . . . . . . . . . 64
5.6.4.3.4 State Replication . . . . . . . . . . . . . . 64
5.6.4.3.5 Advanced Configurations & Scenarios . . . . . 64
5.6.4.3.5.1 Firewalls . . . . . . . . . . . . . . . . 64
5.6.4.3.5.2 Wireless . . . . . . . . . . . . . . . . . 64
5.6.4.3.5.3 Gateways . . . . . . . . . . . . . . . . . 64
5.7 Basic User Scenarios . . . . . . . . . . . . . . . . . . . 64
5.7.1 Locating the Server(s) . . . . . . . . . . . . . . . . 64
5.7.2 Connection . . . . . . . . . . . . . . . . . . . . . . 65
5.7.3 Logging-In (AKA Registering) . . . . . . . . . . . . . 65
5.7.4 Authentication . . . . . . . . . . . . . . . . . . . . 65
5.7.5 Uploading Presence Document . . . . . . . . . . . . . 65
5.7.6 Subscribing to a Presentity . . . . . . . . . . . . . 65
5.7.7 Getting Notifications . . . . . . . . . . . . . . . . 65
5.7.8 Sending IM . . . . . . . . . . . . . . . . . . . . . . 65
5.7.9 Receiving IM . . . . . . . . . . . . . . . . . . . . . 65
5.8 The Presence Document . . . . . . . . . . . . . . . . . . 65
5.9 Composition From Multiple Sources . . . . . . . . . . . . 68
5.10 Status Values . . . . . . . . . . . . . . . . . . . . . . 68
5.11 Instant Messages . . . . . . . . . . . . . . . . . . . . . 68
5.12 Advanced Presence Scenarios . . . . . . . . . . . . . . . 68
5.13 Partial Notifications . . . . . . . . . . . . . . . . . . 68
5.14 Authorization of Subscription . . . . . . . . . . . . . . 68
5.15 Presence Lists . . . . . . . . . . . . . . . . . . . . . . 68
5.16 Watchers List . . . . . . . . . . . . . . . . . . . . . . 68
5.17 Advanced IM Scenarios . . . . . . . . . . . . . . . . . . 68
5.17.1 IM Sessions . . . . . . . . . . . . . . . . . . . . . 68
5.17.2 IM Conferences . . . . . . . . . . . . . . . . . . . . 69
5.17.3 Instant Conferences . . . . . . . . . . . . . . . . . 69
5.17.4 Scheduled Conferences . . . . . . . . . . . . . . . . 69
5.17.5 Switching between IM Page Mode, IM Sessions and IM
Conferences . . . . . . . . . . . . . . . . . . . . . 69
5.18 Client Capabilities . . . . . . . . . . . . . . . . . . . 69
Houri, et al. Expires November 30, 2003 [Page 4]
Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003
5.19 Profiles . . . . . . . . . . . . . . . . . . . . . . . . . 69
5.20 Additional Issues and Services . . . . . . . . . . . . . . 69
5.20.1 Invisible (Lurking) Mode . . . . . . . . . . . . . . . 69
5.20.2 Action Cues . . . . . . . . . . . . . . . . . . . . . 70
5.20.3 Emoticons & Backgrounds . . . . . . . . . . . . . . . 70
5.20.4 Message History . . . . . . . . . . . . . . . . . . . 70
5.20.5 Offline Messages . . . . . . . . . . . . . . . . . . . 70
5.20.6 Queued Offline Messages . . . . . . . . . . . . . . . 70
5.20.7 Other Offline . . . . . . . . . . . . . . . . . . . . 70
5.20.8 File Sharing . . . . . . . . . . . . . . . . . . . . . 70
5.20.9 Voice . . . . . . . . . . . . . . . . . . . . . . . . 70
5.20.10 Video . . . . . . . . . . . . . . . . . . . . . . . 70
5.20.11 General Application Invocation . . . . . . . . . . . 71
5.21 Security Considerations . . . . . . . . . . . . . . . . . 71
5.21.1 Authentication . . . . . . . . . . . . . . . . . . . . 71
5.21.2 Network Authentication of the endpoint . . . . . . . . 71
5.21.3 Endpoint Authentication of the Service Elements . . . 72
5.21.4 Authorization for Service . . . . . . . . . . . . . . 72
5.21.5 Integrity and Privacy of SIP/SIMPLE Messages . . . . . 72
5.21.6 Configuration of Subscriber Data or Stored Messages . 73
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 73
6.1 Normative References . . . . . . . . . . . . . . . . . . . . 73
6.2 Non-Normative References . . . . . . . . . . . . . . . . . . 76
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 77
A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 77
Intellectual Property and Copyright Statements . . . . . . . . 78
Houri, et al. Expires November 30, 2003 [Page 5]
Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003
1. Introduction
SIMPLE, SIP and SIPPING groups seems to be the most active groups in
the IETF. Currently there are more then a hundred active I-Ds. This
document tries to summarize the work in the SIMPLE group by defining
what are the possible architectures for the creation of a SIMPLE
based presence and IM system.
The document starts by a definitions section in which we define the
entities and the concepts that will serve us while we describe the
architecture. The definitions sections is followed by a high level
architecture that defines a very basic presence and IM architecture.
The document continues with a specifications section in which we
survey the current RFCs and active internet-drafts that will be
referred throughout the document. These specifications are actually
the building blocks of the systems described.
After the introductory sections there are two major parts to this
document: The server centric view of the possible systems, in which
we describe the possible server deployments of a presence and IM
systems. The second major part of the document is the user centric
view in which we describe basic and advanced scenarios of presence
and IM from the UA's point of view.
Note that this is only the very first draft of the document. Most of
it is still TBD.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1]
3. Definitions
This document uses terms as defined in various internet-drafts and
RFCs. See Section 5 for the complete list and description of
specifications used in the document.
[TBD. This section will contain a lot of definitions that we will
need. Need to specify for each definition, the specification it
was taken from, Noting definitions that are defined in this
document.]
Presence User Agent (PUA): A Presence User Agent manipulates presence
information for a presentity. This manipulation can be the side
effect of some other action (such as sending a SIP REGISTER
request to add a new Contact) or can be done explicitly through
the publication of presence documents. We explicitly allow
Houri, et al. Expires November 30, 2003 [Page 6]
Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003
multiple PUAs per presentity. This means that a user can have
many devices (such as a cell phone and Personal Digital Assistant
(PDA)), each of which is independently generating a component of
the overall presence information for a presentity. PUAs push data
into the presence system, but are outside of it, in that they do
not receive SUBSCRIBE messages, or send NOTIFY messages.
Presence Agent (PA): A presence agent is a SIP user agent which is
capable of receiving SUBSCRIBE requests, responding to them, and
generating notifications of changes in presence state. A presence
agent must have knowledge of the presence state of a presentity.
This means that it must have access to presence data manipulated
by PUAs for the presentity. One way to do this is by co-locating
the PA with the proxy/registrar. Another way is to co-locate it
with the presence user agent of the presentity. However, these
are not the only ways, and this specification makes no
recommendations about where the PA function should be located. A
PA is always addressable with a SIP (or SIPS) URI that uniquely
identifies the presentity (i.e, sip:joe@example.com). There can
be multiple PAs for a particular presentity, each of which handles
some subset of the total subscriptions currently active for the
presentity. A PA is also a notifier (defined in RFC 3265 [7])
that supports the presence event package.
Presence Server: A presence server is a physical entity that can act
as either a presence agent or as a proxy server for SUBSCRIBE
requests. When acting as a PA, it is aware of the presence
information of the presentity through some protocol means. When
acting as a proxy, the SUBSCRIBE requests are proxied to another
entity that may act as a PA.
Edge Presence Server: An edge presence server is a presence agent
that is co-located with a PUA. It is aware of the presence
information of the presentity because it is co- located with the
entity that manipulates this presence information.
Registrar: A registrar is a server that accepts REGISTER requests and
places the information it receives in those requests into the
location service for the domain it handles.
Location Service: A location service is used by a SIP redirect or
proxy server to obtain information about a callee's possible
location(s). It contains a list of bindings of address-of- record
keys to zero or more contact addresses. The bindings can be
created and removed in many ways; this specification defines a
REGISTER method that updates the bindings.
4. High Level Architecture
This section describes a high level abstraction of a presence and IM
system. The intention of this section is to provide a basis for the
description of the more complex system further on.
Houri, et al. Expires November 30, 2003 [Page 7]
Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003
[TBD. Relate between entities and specification documents.]
4.1 Single Server System
A system of a single presence server to which user agents are
connected will look like the following,
+---------+ +----------------+
|Presence | | Authentication |
| Server | | Server |
+---------+ +----------------+
^ ^
| |
| V
| +------------+
| | Registrar/ |
| | Locator |
| +------------+
| ^
| +---------+ |
+---->| Proxy |<-+
+---------+
^^^^^
|||||
VVVVV
User Agents
Figure 1
Figure 1 illustrates a very simple (or even simplistic) presence and
IM architecture of a single server. Users connect through a proxy to
the system. The proxy directs their logon (REGISTER)requests to the
registrar that uses a back-end authentication directory for
authenticating the users. Subscription and notifications requests
are directed to the presence server that serves them. Sending
instant messages can be done directly between the users or via the
proxy.
Houri, et al. Expires November 30, 2003 [Page 8]
Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003
4.2 Multiple Server System
A system of multiple servers to which user agents are connected will
look like the following,
+---------+ +---------+
| Single | | Single |
| Server | o o o | Server |
| System | | System |
+---------+ +---------+
^^^^^ ^^^^^
||||| |||||
VVVVV VVVVV
User Agents User Agents
Figure 2
Figure 2 illustrates a more complex scenario where there are multiple
units of a single server system. Users may connect to each of the
single server systems. Following issues arise:
o Mapping of users to their servers - Users may have their presence
list (e.g. buddy list) and other information stored at one of the
servers. When a user logs on, its server side storage has to be
retrieved from the appropriate server. Furthermore, changes to
the server side storage has to be replicated to the appropriate
server
o Replication of presence information - When a user logs on to one
of the servers and uploads its presence information, other users
that are logged on to other servers may subscribe to the user.
There should be a way of replicating the presence information
between the servers or at least letting other users know where a
certain user is logged on.
[TBD. How the above problems are solved.]
5. Specifications
This section will survey all the active internet drafts and RFCs that
are relevant this the SIMPLE based presence and IM architecture.
THIS SECTION WILL BE UPDATED SHORTLY AND DOES NOT SHOW THE FULL
CURRENT STATE OF SIMPLE SPECS.
5.1 IMPP/CPIM Specifications
The IMPP working group was the first group at the IETF to start
working on presence and IM protocols. A protocol was not defined by
the IMPP group but very important basic documents were produced.
Houri, et al. Expires November 30, 2003 [Page 9]
Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003
o RFC 2778 [3] - The basic IETF document for presence and IM.
Defines an abstract model for a presence and instant messaging
system. It defines the various entities involved, defines
terminology, and outlines the services provided by the system.
The goal is to provide a common vocabulary for further work on
requirements for protocols and markup for presence and instant
messaging.
o RFC 2779 [4] - The second basic IETF document for presence and IM.
The document defines the requirements for presence and IM service.
The requirements include: Scalability, Format, Security etc.
o RFC 3859 [11] - Defines common semantics and data formats for
presence to facilitate the creation of gateways between presence
services.
o RFC 3860 [12] - Defines common semantics and data formats for
instant messaging to facilitate the creation of gateways between
instant messaging services.
o RFC 3861 [13] - Presence and instant messaging are defined in RFC
2778 [3]. The Common Profiles for Presence and Instant Messaging
define two Universal Resource Identifier (URI) schemes: 'im' for
INSTANT INBOXes and 'pres' for PRESENTITIES. This document
provides guidance for locating the resources associated with URIs
that employ these schemes.
o RFC 3862[14] - Defines the MIME content type 'Message/CPIM', a
message format for protocols that conform to the Common Profile
for Instant Messaging (CPIM) specification.
o RFC 3863[15] - Specifies the Common Profile for Presence (CPP)
Presence Information Data Format (PIDF) as a common presence data
format for CPP-compliant Presence protocols, and also defines a
new media type "application/pidf+xml" to represent the XML MIME
entity for PIDF.
5.2 SIMPLE Group Specifications
The SIMPLE group defines the extensions required for the SIP protocol
in order to be able to implement presence and IM system. Following
is a list of the active specifications that are group documents or
were submitted to the group. Each specification is followed by a
short description of what each specification provides. The documents
were divided into several categories.
5.2.1 Presence
Following documents define the notification mechanisms and
requirements for presence notifications using the SIP protocol.
o RFC 3856 [10] - The basic presence document for SIMPLE. Describes
the usage of the Session Initiation Protocol (SIP) for
subscriptions and notifications of presence. Subscriptions and
notifications of presence are supported by defining an event
Houri, et al. Expires November 30, 2003 [Page 10]
Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003
package within the general SIP event notification framework [7].
o draft-ietf-simple-pres-filter-reqs [20] - Defines a set of
structured requirements whereby an event subscriber (client) may
specify when notifications are sent to it and what the contents
should be.
o draft-ietf-simple-event-filter-funct [30] - The document provides
the mechanism whereby a watcher can specify the presence event
filtering rules, using XML, for the presence agent (PA) and how
that PA is to behave when receiving such filter.
o draft-ietf-simple-partial-notify [19] - Presents a solution for
delivering presence information that aids in reducing and
increasing efficiency of devices that have constrains as low data
processing capabilities, small display and limited battery power.
Other limitations may be caused by the interface between the
terminal and the network, i.e. over radio links with high latency
and low bandwidth. The solution introduces a new MIME-type
"partial notifications" and a Require header extension
"partial-notification".
5.2.2 Data Representation and Access Control
Following documents define ways to represent, and control access to,
presence information stored in a server.
o draft-ietf-simple-rpid [31] - Provides a way of richly
representing presentity information by adding elements to the
basic Presence Information Data Format (PIDF) that provide
additional information about the presentity and its contacts.
o draft-ietf-simple-partial-pdif-format [32] - A characteristic of
the PIDF is that it always carries all the presence information
available for the presentity. In some low bandwidth scenarios,
this may be overwhelming. This document provides a way of
limiting the information that is transported over the network by
reporting only the changed parts of the PIDF of a presentity.
o draft-ietf-simple-xcap [27] - Defines the eXensible Markup
Language (XML) Configuration Access Protocol (XCAP) for enabling a
client to read, write, and modify application configuration data
stored in a server in XML format. An example of such application
configuration data is the access authorization document.
o draft-ietf-geopriv-common-policy [33] - Defines a framework for
authorization policies used for controlling access to application
specific data. This framework combines common location and
SIP-presence-specific authorization aspects.
o draft-ietf-simple-presence-rules [34] - Authorization rules or
policies specify what presence information can be given to which
watchers and when. This document defines an XML document format
for expressing presence authorization rules; the resulting
document can be manipulated by clients using XCAP.
Houri, et al. Expires November 30, 2003 [Page 11]
Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003
5.2.3 Messaging
Following documents define requirements and ways to implement a
session of messages. Note that the MESSAGE method RFC is a SIP group
document [9].
o draft-ietf-simple-message-sessions [35] - The document describes a
method of initiating, transmitting and managing a series of
instant messages within a session using SIP. Such a media session
(MSRP session) is managed by using Session Description Protocol
(SDP) offer/answer model carried over SIP. It is established
using a SIP INVITE, just as a normal audio or video session would
be established.
5.2.4 Lists - Events and Manipulation
Traditional presence and IM systems usually enable users to store a
list of presences on which they subscribe on the server side. The
users logging on to the system do not have to send the list every
time they logon. The following documents deal with requirements and
models for having parallel possibilities in the SIMPLE protocols.
o draft-ietf-simple-event-list [18] - This extension to SIP enables
subscribing to a homogeneous collection of event packages.
Instead of the subscriber sending a SUBSCRIBE for each resource
individually, the subscriber can subscribe to an entire
collection, and then receive notifications when the state of any
of the resources in the collection changes.
o draft-ietf-simple-data-req [17] - Provides a framework and
requirements for data manipulations for presence. These data
manipulations include: presentity list, adding/removing
presentities and authorization lists.
5.2.5 Publish
SIMPLE users that need to publish their presence document to the
presence server were using two types of workrooms:
o Using the REGISTER method for uploading the presence document.
o Using other protocols for uploading the presence document
Following documents describe how it can be done via the SIP protocol
while defining a new PUBLISH method
o draft-ietf-sip-publish [36] - Describes an extension to the
Session Initiation Protocol (SIP). The purpose of this extension
is to create a means, ( referred to as SIP PUBLISH) for publishing
event state used within the framework for SIP Event Notification
(RFC3265 [7]). The first application of this extension is
targeted at the publication of presence information.
o draft-ietf-simple-xcap-pidf-manipulation-usage [37] - Describes a
usage of XCAP for manipulating the contents of Presence
Houri, et al. Expires November 30, 2003 [Page 12]
Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003
Information Data Format (PIDF) based presence document in a SIP
environment. It picks up where SIP PUBLISH leaves off. SIP
PUBLISH allows a single PUA to publish its view of the state of
its presentity. Since the PUA is tied to a single device, the
published state is device dependent. Also, SIP PUBLISH creates a
soft state which has to be refreshed before expiry of its
lifespan. Thus SIP PUBLISH is unsuitable for setting overall,
device independent, non-transient state. This document describes
how XCAP can be used by a client to accomplish these.
5.2.6 Watchers
Watcher information refers to the set of users subscribed to a
particular resource within a particular event package. Watcher
information changes dynamically as users subscribe, unsubscribe, are
approved, or are rejected. A user can subscribe to this information,
and therefore learn about changes to it.
o draft-ietf-simple-winfo-package [23] - Defines the watcher
information template-package for the SIP event framework. This
event package is a template-package because it can be applied to
any event package, including itself.
o draft-ietf-simple-winfo-format [22] - Defines an XML format for
watcher information for a resource.
5.2.7 SIMPLE/CPIM Related Docs
Following documents define a mapping between the IMPP/CPIM documents
(Section 5.1) or define ways to extend what is defined in IMPP/CPIM.
o draft-ietf-simple-cpim-mapping [16] - Defines how the SIMPLE work
group SIP events package for distribution of presence information
[10] and the MESSAGE extension for the transport of instant
messages map to the abstract CPIM service defined in RFCs
3859-3863, in order to interoperate with other CPIM compliant
presence and instant messaging services.
o draft-ietf-simple-prescaps-ext [38] - Proposes extensions to
Presence Information Data Format (PIDF)[15] to be used within the
SIMPLE based presence systems in order to enable building better
applications.
5.2.8 Relevant SIP Group Specifications
Following SIP RFCs are very relevant to this document:
o RFC3261 [5] - The basic document of Session Initiation Protocol
(SIP).
o RFC3263 [6] - Describes the DNS procedures used by SIP to allow a
client to resolve a SIP Uniform Resource Identifier (URI) into the
IP address, port, and transport protocol of the next hop to
contact. These procedures also allow a server to send a response
Houri, et al. Expires November 30, 2003 [Page 13]
Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003
to a backup client if the primary client has failed.
o RFC3265 [7] - Provides an extensible framework by which SIP nodes
can request notification from remote nodes indicating that certain
events have occurred. The event notification mechanisms defined
are NOT intended to be a general-purpose infrastructure for all
classes of event subscription and notification.
o RFC3428 [9] - Defines the MESSAGE method as an extension to SIP
that allows the transfer of Instant Messages. Since the MESSAGE
request is an extension to SIP, it inherits all the request
routing and security features of the SIP protocol. MESSAGE
requests carry the content in the form of MIME body parts.
MESSAGE requests do not themselves initiate a SIP dialog; under
normal usage each Instant Message stands alone, much like pager
messages. MESSAGE requests may be sent in the context of a dialog
initiated by some other SIP request.
5.2.9 Relevant SIPPING Group Specifications
The SIPPING group is responsible for defining requirements for SIP
and SIMPLE work. Following is an initial list of SIPPING documents
that are relevant to the architecture described in this document.
[TBD. Other relevant SIPPING documents?]
o draft-niemi-sipping-event-throttle-reqs [24] - The document
defines requirements for all event packages to specify a maximum
rate at which event notifications are generated by a single
notifier. Such a limit is provided in order to reduce network
congestion. In addition to the fixed limits introduced by
specific event packages, further mechanisms for limiting the rate
of event notification are also allowed to be defined by event
package specifications but none have been specified so far. This
memo discusses the requirements for a throttle mechanism that
allows a subscriber to further limit the rate of event
notification.
o draft-ietf-sipping-conferencing-framework [25] - Defines a
framework for how conferencing in SIP can occur. Note that the
basic definition of SIP defines dialogs that are two-party by
default. The framework in the document describes the overall
architecture, terminology, and protocol components needed for
multi-party conferencing.
o draft-ietf-sipping-cc-conferencing [26] - Defines conferencing
call control features for SIP. The document builds on the
Conferencing Requirements and Framework documents [25] to define
how a tightly coupled SIP conference works. The approach is
explored from different user agent (UA) types perspective:
conference-unaware, conference-aware and focus UAs. The use of
URIs in conferencing, OPTIONS for capabilities discovery, and call
control using REFER are covered in detail with example call flow
diagrams.
Houri, et al. Expires November 30, 2003 [Page 14]
Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003
5.3 Basic Functional Model
Figure 1-3 shows a generic IMPS system, including SIP/SIMPLE flows.
The various deployment types above are specializations of the generic
model. Figure 1 shows the general SIP/SIMPLE architcture. All flows
are SIP/SIMPLE (author note - the network presence sources is
incorrectly drawn in the figure and needs to be fixed).
Houri, et al. Expires November 30, 2003 [Page 15]
Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003
+-----------+
|Network | +-----------+
|Presence | | AAA |
|Sources | | |
+----+------+ +-----+-----+
| |
+------+ +------------+--------------------------+
| | | |
| | | |
+-----------+ +---+--+----+ +-----+-----+ +-------+ +-----+-----+
|Messaging | |Presence | |Conference +---+Message+--+IM |
|Gateway | |Application| |Server | |Store | |Application|
+-----------+ +----|------+ +-------+---+ +-------+ +-----+-----+
| | | |
| | | |
| +--------------+ | +-------------------+
+---------------------------+ | | |
| | | |
+-----------+ +-+-+-+----+-+
| End User | |Home Serving|
| | |Proxy |
+------+----+ +---+--+----++
| | | |
| | | |
| +----------------+ | +-------------+
| | | |
+------+--+--+ +--------+-------+ +----+----+
| Edge | |Service Provider| |Transport|
| Proxy | |Edge Proxy | |Proxy |
+------------+ +----------------+ +---------+
Figure 3
Houri, et al. Expires November 30, 2003 [Page 16]
Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003
Figure x shows the functional architecture for group managment.
+-----------+
| AAA |
| |
+-----+-----+
|
+----------------+-----------------+
| | |
| | |
+-----+-----+ +-----+-----+ +-----+-----+
|Presence | |Conference | |IM |
|Application| |Server | |Application|
+----+------+ +----+------+ +-----+-----+
| | |
| | |
+--------------+ | +---------------+
| | |
| | |
+-----------+ +---+-+--+---+
| End User |----------|Group Mgt |
| | |Directory |
+-----------+ +------------+
Figure 4
Houri, et al. Expires November 30, 2003 [Page 17]
Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003
The following figure shows the functional architecture for users
accessing deferred messages.
+-----------+
| AAA |
| |
+-----+-----+
|
|
|
|
+-----+-----+
| Message |
| Store |
+-----+-----+
|
|
|
|
+-----+-----+
| End User |
| |
+-----------+
Figure 5
The elements of the sytem are in the above figures are:
o End point: nodes that support the IMPS instant messaging and
presence.
o Home Serving Proxy (HSP): a server that supports registrar,
proxy, and application interface functions.
o Transport Proxy: an IMPS node that provides transport of IMPS
control messages but is not directly servicing the actual requests
of the IMPS control protocol. The proxy may route IMPS control
messages to the HSP to/from the end point, or to/from other HSPs.
o Edge Proxy: a specialized proxy that many architectures use as an
intermediary between the end point and the fixed network, often
provides (SIP/SIMPLE) compression, authentication, and admission
control function.
Houri, et al. Expires November 30, 2003 [Page 18]
Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003
o Service Provider Edge Proxy: a specialized proxy used as an
intermediary from the home service provider to other service
providers or external systems.
o Network Presence Sources: Source of presence information not
published directly by user equipment. Examples might include
adapters for HLR registration state, geo-location systems, and the
like.
o AAA: Performs authentication, authorization, and accounting
functions on behalf of the Radio Network and IP Access and SIP
entities. Only one monolithic AAA server is depicted; but it may
be that proxy AAA servers are involved to proxy AAA to an AAA
server that can authenticate the user, i.e., AAA Proxies are not
shown in the figures. Furthermore, the AAA server that
authenticates the user is not necessarily the AAA server that
authorizes various services. (???what does that mean in a real
system???)
o Messaging Conference Server: Provides messaging sessions by
duplicating messages received from one end point to all the
endpoints of a conference session.
o Message Store: Provides persistent storage of messages when users
are not available (e.g., the user is in a tunnel) or when messages
must be archived.
o Instant Messaging Application: Supports the delivery of pager
mode messages to the message store for users that are not
currently available; may also archive messages for later
retrieval.
o Presence Application: Supports presence subscription,
notification, and publication.
o Group Management Directory: Stores the lists of users associated
with groups.
o Gateway: will note be specified in this document because the
gateway interacts with systems not named nor specified herein.
5.4 Basic Flows
5.4.1 Registration
This section states requirements for a registration function that
associates an address of record with an IP address that has been
assigned to a user endpoint. An example of an address of record is
one of the legal formats of a URI [RFC 2396].
The following example assumes that the user has gained access to a
access network and has been assigned an IP address. The user must
perform IMPS registration to associate the assigned IP address with
their address of record. This registration also indicates to the
network the instant message capabilities that are supported by the
end point. Figure 6 shows the message exchange.
Houri, et al. Expires November 30, 2003 [Page 19]
Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003
The HSP utilizes HAAA of the end point to authenticate and authorize
the user during registration. After completion of registration, the
home server stores the end point's address and is able to send
messages to the endpoint. The registration does not authorize any
service nor does it indicate to end point the services supported by
the server.
Refer to Section 8 for a discussion on registration authentication.
Houri, et al. Expires November 30, 2003 [Page 20]
Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003
Registration
EP HSP AAA Watcher
| | | |
| (1) Register | | |
| Request | | |
|---------------->| | |
| | | |
| | (2) AAA | |
| | Request | |
| |-------------->| |
| | | |
| | (3) AAA | |
| | Response | |
| |<--------------| |
| | | |
| (4) Register | | |
| Response | | |
|<----------------| Registrar | |
| | Stores Contact| |
| | Address | |
| |--------+ | |
| | | | |
| | | | |
| |<-------+ | |
| | | |
| | | |
| | Send | |
| | registration | |
| | messages to | |
| | watcher | |
| |------------------------------>|
| | | |
Figure 6
1. The end point sends a Registration Request to the HSP.
2. The HSP sends an AAA Request to the HAAA server.
3. The HAAA server sends an AAA Response to the HSP server.
4. The HSP acknowledges the Registration Request to the end point
with a Register Response.
5. The HSP stores the new contact in its registration database.
6. if there are any registration watchers, the HSP issues
registration event notifications to them.
5.4.2 Sending and Receiving Messages
Instant messaging shall support two different messaging modes:
Houri, et al. Expires November 30, 2003 [Page 21]
Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003
Pager mode: Each message is self-contained in one instant
messaging request message. This mode is most useful for short
sequences of messages, for small messages, and for messages sent
to few users or to a static group of users. (See RFC 3228 for
more information.)
Session mode. A set of messages is carried via some transport
protocol; this protocol is not SIP. The function of IMPS in this
case is to establish a messaging session between the interested
parties. The choice of the transport protocol to support a
messaging session is ???tbd??. From a user perspective, session
mode is like a chat room. This mode is most useful for extended
sequences of messages, for large messages, for messages sent to a
large of number of users, or to a group of users that may change
over the life of the message.
For short messages, especially in a wireless environment, pager mode
is more spectrally efficient and represents lower latency to the user
that establishing separate transport sessions. This transport
session is independent of any transport involved in the transport of
IMPS control messages. If the user plans on sending many messages,
or large messages, pager-mode is less efficient in comparison to
session mode.
It is possible that a message contains a reference (e.g., a URL) that
points to a large message instead of containing the message itself.
This section first addresses pager mode and then session mode
messaging.
5.4.2.1 Sending a Pager Mode Message
The end point sends a pager-mode request to the sender Home Service
Proxy (HSP). This may occur via intermediary IMPS proxies if
necessary. The pager mode request contains the logical name of the
desired target user or group. The body of the pager-mode request
contains a message encapsulated in the form of a valid MIME format,
which includes text, general multi media such as audio, still photos,
or video. MIME is the widely used format for email attachments. The
sender HSP receives the pager-mode request and queries the user's
HAAA to verify that the user is allowed to send a message through
this proxy. The authorization response from the HAAA includes
transmission policy logic for the user. The authorization can be
cached and details are left to ???what???, i.e., it is not necessary
for the HSP to check the AAA for the user for each pager mode
request. Authentication and Authorization mechanisms are discussed
in Section ?. The sender HSP then executes user transmission policy
logic e.g., expands the logical name of the target to which the
message is being sent, expands nicknames to logical names, etc. The
Houri, et al. Expires November 30, 2003 [Page 22]
Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003
HSP sends the request to the sender IM Application, which verifies
the user is authorized for service; if so logs the message on behalf
of the user. As in the case of the HSP, the authorization can be
cached and details are left to ???what???. In the typical case, the
sender HSP then determines if the pager mode request is targeted to a
user in the domain of the sender HSP. If this is the case, the HSP
sends the request to the target user's IM Application. That IM
Application logs the pager mode request and proxies it to the sender
HSP, which then delivers the requst to the target user. The receiver
endpoint responds with an acknowledge response to the sender HSP,
which proxies the response to the sender endpoint.
If the message is not targeted to a user in the sender HSP domain,
the sender HSP then proxies the request onward via intermediary IMPS
proxies towards the destination. The message is delivered to the
receiver's HSP, which proxies the pager mode message to the IM
Application that supports the target user, as explained in Section ?.
The receiver's HSP responds with an acknowledge response to the
sender HSP, which proxies it to the sending user. Figure ? shows a
message exchange associated assuming a sender HSP up to the point of
delivery to the receiver HSP. Figure ? then completes the scenario.
If some intermediary proxy in the chain at any point is unable to
forward the message, that proxy returns an appropriate error
response.
It is possible that the endpoint could be able to determine the
receiver HSP without using the sending HSP; however, this would
bypass the sender IM Application.
Houri, et al. Expires November 30, 2003 [Page 23]
Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003
End Sender IM HAAA Receiver
Point HSP Application HSP
| | | | |
| (1) Pager- | | | |
| Mode Request | | | |
|------------->| | | |
| | (2) AAA | | |
| | Request | | |
| |-------------------------->| |
| | | | |
| | | | |
| | (3) AAA | | |
| | Response | | |
| |<--------------------------| |
| | | | |
| | (4) Pager- | | |
| | Mode Request| | |
| |------------>| | |
| | | (5) AAA | |
| | | Request | |
| | |------------>| |
| | | | |
| | | (6) AAA | |
| | | Response | |
| | |<------------| |
| | | | |
| | |(7) Pager- | |
| | |Mode Response| |
| | |<------------| |
| | | | |
| | (8) Pager- | | |
| | Mode Request| | |
| |--------------------------------------->|
| | | | |
| | | | |
| |(9) Pager- | | |
| |Mode Response| | |
| |<----------------------------------------
| | | | |
| (10) Pager | | | |
| Mode Response| | | |
|<-------------| | | |
| | | | |
Figure 7
Houri, et al. Expires November 30, 2003 [Page 24]
Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003
1. The endpoint station sends a pager mode request.
2. The sender HSP authenticates the user's request by sending an AAA
request to the user's HAAA.
3. The HAAA authenticates and authorizes the user and sends an AAA
response to the sender HSP.
4. The sender HSP proxies the request to the sender IM Application.
5. The IM Application authenticates and authorizes the user's
request by sending an AAA request to the user's HAAA.
6. The HAAA authenticates and authorizes the user and sends an AAA
response to the IM Application.
7. The sender IM Application archives the message and proxies the
request back to the sender HSP.
8. The sender HSP proxies the request to the receiver HSP.
9. The receiver's HSP proxies a request response to the sender HSP.
10. The sender HSP sends a request response to the sending endpoint.
If the user plans on sending messages to a group, the user or some
other party must have previously created the desired group. A group
is created using list management as described below (see section
6.3). In this case the pager-mode request is sent to the HSP serving
the group. The list's logical name is the target name of the pager
mode request. There are two alternative approaches outlined herein
for the delivery of the pager mode request to a group:
o The HSP serving the list sends the pager mode request to all the
recipients per the list; recipients then acknowledge the pager
mode request and one acknowledge is received per received
recipient. It is possible the members of the lists are additional
groups themselves. for the case of wireless use, a sending
endpoint (mobile station) receives one acknowledge from all
physical recipients, which may be a spectral burden if the final
expansion of the list is very large.
o The HSP serving the list verifies it can expand the list, sends
one acknowledge to the entity that sent the pager mode request,
which can be another HSP or the endpoint, and creates a new pager
mode request to each of the recipients on the list. The sending
endpoint only receives one acknowledge, which is spectrally more
efficient.
Security associated with sending a pager mode request is discussed in
the section ?
5.4.2.2 Receiving a Pager Mode Message
The above scenario shows a user sending a pager-mode request to a
receiver's HSP. This section shows the reception process for the
page-mode from the point of reception by the receiver's HSP. If the
pager-mode request was sent to many receivers, they will all behave
Houri, et al. Expires November 30, 2003 [Page 25]
Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003
with the reception process below.
A message targeted to the user's address of record is delivered to
that user's HSP (the receiver HSP). The receiver HSP recognizes that
the address of record is served by this HSP, i.e., is in the
administrative domain of this HSP. The receiver HSP verifies that
the receiving user is authorized to receive message through this HSP
by sending an AAA request to the HAAA of the targeted user. The HAAA
of the target user authorizes the receiver's HSP to deliver the
message in an AAA Response and provides a reception policy to the
receiver's HSP. The authorization can be cached and details are tbd,
i.e., it is not necessary for the HSP to check the AAA for the user
for each pager mode request.
Authentication and Authorization is discussed in Section ???. The
receiver's HSP then executes routing or filtering logic associated
with this user (user policy), and acts accordingly, e.g., discards
the message, stores it for later delivery, etc. In the typical case
the user is authorized and willing to receive the message and has
previously registered a contact address. The receiver HSP then
proxies the pager-mode request to the receiver's IP application,
which verifies the user is authorized for service, and proxies an
acknowledge back. As in the case of the HSP, the authorization can
be cached and details tbd. The receiver HSP then consults its
registration table for that logical name, and then finds the IP
address of the endpoint. The receiver HSP then sends the request to
the associated IP address. The message is received at the endpoint
and the endpoint responds with an acknowledge response, which is
routed via proxies to the entity that sent the pager-mode request.
From the previous section we see that that entity could be the
endpoint itself that is the origin of the pager-mode request, or
other sender HSPs that expanded the target list. (editor note: would
the response have to pass via the sender HSP?) Lastly, the receiving
endpoint alerts its user upon reception of the pager-mode request.
See Figure ?? for scenario example.
Because wireless resources are scarce and the user may not desire
messages from just anyone, the user may populate a policy in the HSP
that controls how incoming messages will be processed. For example,
"unwanted" messages may be discarded, allowing the user to avoid
charges associated with such messages. (See section ???)
Houri, et al. Expires November 30, 2003 [Page 26]
Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003
Sender Receiver IM HAAA End
HSP HSP Application Point
| | | | |
| (1) Pager- | | | |
| Mode Request | | | |
|------------->| | | |
| | (2) AAA | | |
| | Request | | |
| |-------------------------->| |
| | | | |
| | | | |
| | (3) AAA | | |
| | Response | | |
| |<--------------------------| |
| | | | |
| | (4) Pager- | | |
| | Mode Request| | |
| |------------>| | |
| | | (5) AAA | |
| | | Request | |
| | |------------>| |
| | | | |
| | | (6) AAA | |
| | | Response | |
| | |<------------| |
| | | | |
| | |(7) Pager- | |
| | |Mode Response| |
| | |<------------| |
| | | | |
| | (8) Pager- | | |
| | Mode Request| | |
| |--------------------------------------->|
| | | | |
| | | | |
| |(9) Pager- | | |
| |Mode Response| | |
| |<---------------------------------------|
| | | | |
| (10) Pager | | | |
| Mode Response| | | |
|<-------------| | | |
| | | | |
Figure 8
Houri, et al. Expires November 30, 2003 [Page 27]
Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003
1. The sender HSP sends a pager mode request to the receiver HSP.
2. The receiver HSP veifies that the user is authorized to recieve
such requests by sending an AAA request to the HAAA of the
target user.
3. The HAAA authenticates and authorizes the user and sends an AAA
response to the receiver HSP.
4. The receiver HSP proxies the request to the receiver IM
Application.
5. The IM Application authenticates and authorizes the user's
request by sending an AAA request to the user's HAAA.
6. The user's HAAA authenticates and authorizes the user and sends
an AAA response to the IM Application.
7. The receiver IM Application archives the message and proxies the
request back to the receiver HSP.
8. The HAAA sends an AAA response to the receiver HSP that
authorizes the pager-mode request and that may contain a
reception policy for the target user.
9. After possibly screening the request based on some policy, the
receiver HSP sends the request to the endpoint.
10. The endpoint sends a request response to the receiver HSP.
11. The receiver HSP sends the request response to the sender HSP.
5.4.2.3 Deferred Message Delivery to IM Application
It may be in Figure 6 that the receiver endpoint is not avaible. In
this case, the receiver IM Application will archive the message at
the message store and arrange for delivery later.
When the receiver HSP receives the pager mode request from the sender
HSP, it then sends the pager-mode request to the receiver IM
Application. Pager-mode messages are delivered to the recipient's IM
application, which applies local policy in determining what to do
with that message. In the typical case, the policy will be to
forward the message to the registered contact if there is one, and to
store the message for future delivery if there is no registered
contact. Another reasonable policy might be to reject the message if
there are no registered contacts for the recipient. If the message
is stored for deferred delivery, the IM application may (based on
policy) indicate in its response to the sender that delivery of the
message has been deferred. Th The IM Application also logs the
message.
The following call flow shows the delivery of a pager-mode message to
an IM application, and the storing of that message by the IM
application for deferred delivery to the intended recipient. The
actual delivery of the message to the user will occur at some future
time, and is addressed in a separate call flow in the following
section.
Houri, et al. Expires November 30, 2003 [Page 28]
Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003
Sender Receiver IM HAAA Message
HSP HSP Application Store
| | | | |
| (1) Pager- | | | |
| Mode Request | | | |
|------------->| | | |
| | (2) AAA | | |
| | Request | | |
| |-------------------------->| |
| | | | |
| | | | |
| | (3) AAA | | |
| | Response | | |
| |<--------------------------| |
| | | | |
| | (4) Pager- | | |
| | Mode Request| | |
| |------------>| | |
| | | (5) Store | |
| | | Message | |
| | |------------------------->|
| | | | |
| | | | |
| | |(6) Acknowledge |
| | |<-------------------------|
| | | | |
| |(7) Pager- | | |
| |Mode Response| | |
| |<------------| | |
| | | | |
| (8) Pager | | | |
| Mode Response| | | |
|<-------------| | | |
| | | | |
Figure 9
1. The sender HSP sends a pager mode request to the receiver HSP.
2. The receiver HSP verifies that the user is authorized to receive
such requests by sending an AAA request to the HAAA of the target
user.
3. The receiver HSP proxies the request to the receiver IM
Application.
4. The receiver IM Application archives the message in the message
store.
5. The message store acknowledges successful storage to the IM
Application.
Houri, et al. Expires November 30, 2003 [Page 29]
Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003
6. The IM Application sends a request response to the receiver HSP.
7. The receiver HSP sends a request response to the sender HSP.
5.4.2.4 Delivery of Deferred Message to User
In the previous section, the IM Application archived the message in
the message store. At a later point in time, the user becomes
available to receive instant messages. The IM application learns the
user is available when it receives a presence notification that
indicates the user is available to receive deferred instant messages.
Houri, et al. Expires November 30, 2003 [Page 30]
Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003
Presence Receiver IM HAAA Message
Application HSP Application Store
| | | | |
| (1) available| | | |
| notification | | | |
|------------->| | | |
| |(2) available| | |
| |notification | | |
| |------------>| | |
| | | | |
| | | | |
| | | | |
| | | | |
| |<--------------------------| |
| | | | |
| | (4) Pager- | | |
| | Mode Request| | |
| |------------>| | |
| | | (5) Store | |
| | | Message | |
| | |------------------------->|
| | | | |
| | | | |
| | |(6) Acknowledge |
| | |<-------------------------|
| | | | |
| |(7) Pager- | | |
| |Mode Response| | |
| |<------------| | |
| | | | |
| (8) Pager | | | |
| Mode Response| | | |
|<-------------| | | |
| | | | |
Figure 10
1. The IM Application sends a message retrieve request to the
message store.
2. The message store responds with deferred messages.
3. The IM Application sends one pager-mode request to the receiver
HSP for each message returned by the message store.
4. The receiver HSP sends a pager-mode request to the MS.
5. The MS sends a pager-mode response back to the receiver HSP.
6. The receiver HSP sends a pager-mode response back to the IM
Application
Houri, et al. Expires November 30, 2003 [Page 31]
Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003
5.4.2.5 Logging Pager-Mode Messages
Logging pager-mode messages is outside the scope of this document.
5.4.2.6 Establishing a Point-to-Point Messaging Session
There are two options for session based message transport:
o Direct connections between parties; for two users this can be
point-to-point, otherwise multicast is assumed.
o Connections via a network based conference-like function that
duplicates messages.
The endpoint sends a messaging session request to its Home Service
Proxy (HSP). This messaging session invitation does not actuate the
transport session establishment itself; rather it serves to invite
desired entities to establish the transport protocol instance that
will intrinsically support message transport. The messaging session
request indicates a messaging session of some type, e.g., CPIM/TCP,
XMPP, etc., that is desired. The request contains the logical name
of the desired target user or group as well as information describing
the message transport session to be established.
The HSP receives this messaging session request and sends an
authentication request to the HAAA of the user to verify that the
user is authorized to such a request through this proxy. The HAAA
responds with an AAA response, which contains a transmission policy.
The HSP then executes user transmission policy logic, e.g., expands
the logical name, expands nicknames associated with the logical name,
etc. In the typical case, the HSP determines if the transport
establish request is targeted to a user in the domain of the HSP. If
so the HSP delivers the messaging session request to the target user.
If the messaging session request is not targeted to a user in the
domain of the HSP, the HSP then proxies the request onward towards
the receiver HSP of the target user via intermediary proxies. If
some proxy in the chain is unable to forward the messaging session
request, that proxy returns an appropriate error response.
Otherwise, the request is delivered to the receiver HSP, which then
sends an AAA to the target user's HAAA to request authorization for
the messaging session request. The HAAA responds with an AAA
response. The receiver HSP proxies the messaging session request to
the target user. The endpoint alerts the user so it can determine
whether to accept the messaging session request or not. If the
target user accepts the request, it sends a messaging session
response to its HSP, which proxies the messaging session response via
the intermediary proxies to the sender's HSP. At this point, the
endpoint and the terminating entity execute the desired transport
Houri, et al. Expires November 30, 2003 [Page 32]
Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003
protocol establish that was identified by the messaging session
request.
Houri, et al. Expires November 30, 2003 [Page 33]
Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003
Figure 9 provides an example flow of a point-to-point messaging
session establishment.
End Sender Receiver Sender Receiver End
Point HSP HSP HAAA HAAA Point
| | | | | |
|(1) messaging | | | |
|session | | | | |
|request | | | | |
| | (2) AAA | | | |
| | Request | | | |
| |------------------------->| | |
| | | | | |
| | | | | |
| | (3) AAA | | | |
| | Response | | | |
| |<-------------------------| | |
| | | | | |
| |(4) messaging| | | |
| |session | | | |
| |request | | | |
| |------------>| (5) AAA | | |
| | | Request | | |
| | |----------------------->| |
| | | | | |
| | | (6) AAA | | |
| | | Response | | |
| | |<-----------------------| |
| | |(7) messaging | |
| | |session | | |
| | |request | | |
| | |---------------------------------->|
| | |(8) messaging | |
| | |session | | |
| | |response | | |
| | |<----------------------------------|
| | | | | |
| |(9) messaging| | | |
| |session | | | |
| |response | | | |
| |<------------| | | |
|(10) messaging | | | |
|session | | | | |
|response | | | | |
|<-----------| | | | |
| | | | | |
Houri, et al. Expires November 30, 2003 [Page 34]
Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003
Figure 11
1. The endpoint sends a messaging session invitation to the senders
HSP.
2. The sender HSP authenticates the user's request and verifies the
user is authorized to use that HSP. The sender HSP sends the
request to the receiver HSP.
3. The receiver HSP sends the request to the receiver.
4. The receiver sends a message session response to the receiver
HSP.
5. The receiver HSP sends a message session response to the sender
HSP.
6. The sender HSP sends a message session response to the endpoint.
7. The endpoint sends a message session acknowledge to the target.
8. The two endpoints establish a messaging session.
5.4.2.7 Sending a Message Within a Messaging Session
When the messaging session as establishment is complete, the user may
send messages using it. This is shown in Figure ??. If a network
based conference server is involved, it will copy the messages and
forward them via the transport connection.
Houri, et al. Expires November 30, 2003 [Page 35]
Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003
| |
| |
| (1) Messaging Session |
| Establishment Complete |
|<------------------------>|
| |
| |
| |
| |
| (2) Message over |
| Messaging Session |
|<------------------------>|
| |
| |
| |
Figure 12
1. The messaging session is established, which may be between two
users or between each user and the conference server.
2. The message is sent over the messaging session.
Houri, et al. Expires November 30, 2003 [Page 36]
Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003
5.4.2.8 Receiving a Message Within a Messaging Session
When the transport session as negotiated by SIP is complete, a user
may receive messages via the transport session as shown below.
| |
| |
| (1) Messaging Session |
| Establishment Complete |
|<------------------------>|
| |
| |
| |
| |
| (2) Message over |
| Messaging Session |
|<------------------------>|
| |
| |
| |
Figure 13
1. The messaging session is established, which may be between two
users or between each user and the instant messaging application.
2. The message is received over the messaging session.
5.4.2.9 Adding a Member to an Established Session
This document specifies use of conference control procedures to add a
member to an established session. The conference control design team
of the SIPPING WG of the IETF is designing these procedures. Two
cases are considered:
o Adding a third user point-to-point session. Transition a two-user
session to a multiparty conference and add a third part to the
conference.
o Adding a user to a multiparty session, i.e., a session with more
than two current users.
5.4.2.10 Transitioning a Two Party Session to a Multiparty Conference
and Adding a Third Participant
Houri, et al. Expires November 30, 2003 [Page 37]
Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003
End End Conference AAA
Point A Point B Server
| | | |
| | | |
| (1) pt2pt | | |
| Session | | |
| Established | | |
|<-------------->| | |
| | | |
| (2) Conference | | |
| Session | | |
| Request | | |
|-------------------------------->| |
| | | (3) AAA |
| | | Request |
| | |-------------->|
| | | |
| | | (4) AAA |
| | | Request |
|(5) Conference | |<--------------|
|Session Response| | |
|-------------------------------->| |
| | | |
| | | |
| (6) Conference | | |
| Session Ack | | |
|<--------------------------------| |
| | | |
| | | |
| (7) Replace | | |
| Request | | |
|--------------->| | |
| | | |
| (8) Replace | | |
| Response | | |
|<---------------| | |
| | | |
| (9) Release | | |
| Request | | |
|<---------------| | |
| | | |
| (10) Release | | |
| Response | | |
|--------------->| | |
| | | |
Figure 14
Houri, et al. Expires November 30, 2003 [Page 38]
Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003
End End Conference End
Point A Point B Server Point C
| | | |
| | | |
| |(11) Messaging | |
| |Session Request | |
| |--------------->| |
| | | |
| |(12) Messaging | |
| |Session Response| |
| |<---------------| |
| | | |
| |(13) Messaging | |
| |Session Ack | |
| |--------------->| |
| (14) Notify | | |
| Request | | |
|<---------------| | |
| | | |
| (15) Notify | | |
| Response | | |
|--------------->| | |
| | | |
| (16) Join | | |
| Request | | |
|------------------------------------------------->|
| | | |
| (17) Join | | |
| Response | | |
|<-------------------------------------------------|
| | |(18) Messaging |
| | |Session Request |
| | |<-------------- |
| | | |
| | |(19) Messaging |
| | |Session Response|
| | |--------------->|
| | | |
| | | (20) Messaging |
| | | Session Ack |
| | |<---------------|
| | | |
| | | |
Figure 15
Houri, et al. Expires November 30, 2003 [Page 39]
Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003
End End Conference End
Point A Point B Server Point C
| | | |
| | | |
| | | |
| (21) pt2pt | | |
| Messaging | | |
| Session | | |
|<------------------------------------------------>|
| | (22) pt2pt | |
| | Messaging | |
| | Session | (23) pt2pt |
| |<-------------->| Messaging |
| | | Session |
| | |<-------------->|
| | | |
| | | |
| | | |
Figure 16
1. A and B have a point-to-point messaging session. A now
determines it wishes to add C to the messaging session.
2. A sends a conference session request to the conference server.
This informs the conference server of the identity of the
conference to be established. Later the actual messaging
transport session is initialized. The method by which A finds
the conference server is not shown in this flow.
3. The conference server sends an AAA request to the HAAA of the
requesting user to verify that user is authorized to use this
conference server.
4. The HAAA sends an AAA response to the requesting user.
5. The conference server responds conference session response.
6. A sends a messaging session acknowledge to the conference server.
7. A sends a replace request to B that requests that B release the
point-to-point messaging session with A and replace with a
point-to-point messaging session to a conference server.
8. B sends a replace response to A.
9. B sends a release request to A.
10. A responds with a release request response.
11. B sends a messaging session request to the conference server.
12. The conference server sends a messaging session response to B.
13. B sends a messaging session acknowledge to the conference
server.
14. B sends a notify request to inform A that it has replaced the
connection to A with one to the conference server.
Houri, et al. Expires November 30, 2003 [Page 40]
Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003
15. A sends a notify response to B.
16. A asks C to join the conference. The endpoint alerts user C and
user C makes the decision to join the session.
17. C sends a response to A.
18. C sends a messaging session requst to the conference server.
19. The conference server tells C it is allowed to join the
conference.
20. C acknowledges that response.
21. A and the conference server establish a point-to-point messaging
session.
22. B and the conference server establish a point-to-point messaging
session.
23. C and the conference server establish a point-to-point messaging
session.
5.4.2.11 Adding a User to a Multiparty Session
Figure 13 exactly depicts this case, i.e., substitute any other user
being for user C in that figure.
Houri, et al. Expires November 30, 2003 [Page 41]
Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003
5.4.2.12 Leaving a Messaging Session
This document specifies use of conference control procedures to
delete a member to an established session. The conference control
design team of the SIPPING WG of the IETF is designing these
procedures. The following shows B dropping off the established
conference session.
End Conference
Point B Server
| |
| |
| (1) Release |
| Request |
|------------------------->|
| |
| |
| (2) Release |
| Response |
|<-------------------------|
| |
| |
| (3) Quit |
| Messaging Session |
|<------------------------>|
| |
| |
Figure 17
1. B sends a Release Request
2. The conference server sends a Release Response to B.
3. B and the conference server terminate the messaging transport
session.
5.4.2.13 Logging Messaging Session Messages
Logging messages from a messaging session is outside the scope of the
architecture.
5.4.3 Group Operations
A group is a nested collection of addresses or identifiers such as an
address or record. A group is identified by a single address.
Various operations can be performed on a group. The semantics of the
Houri, et al. Expires November 30, 2003 [Page 42]
Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003
operations performed on a group (as opposed to being performed on an
individual address) depend on, and should be defined by, each
operation. This implies a need for usual group operations such as
creation, modification, retrieval, and deletion lists.
When the endpoint desires to perform instant messaging (presence)
list operations, such as creating or deleting the list, or modifying
an existing list, the endpoint establishes security association and
then a list management session with its HSP. The endpoint then
executes the desired list operation using the list management
session. The method by which the endpoint is provisioned with a URL
of the list server is outside the scope of this document. OMA has
specified IP Provisioning Over the Air and such methods should be
adopted or extended if necessary for this application.
The following operations are supported:
o Add, with a list of URIs to add to the designated list.
o Delete, with a list of URIs to delete from the designated list.
o A list of existing URIs on the designated list that are to be
overwritten with new attributes.
o Retrieve the designated list.
o Only one list can be affected in a single transaction.
5.4.3.1 Creating a Group
Users or service providers can create a group in more than one way.
The list management session requires and authentication of the user
and an authorization that the user is permitted to create lists at
this HSP. A security session establishes privacy of all list
management transactions, to be discussed in section 1.1.16.5.2. The
user sends a create group request, which is acknowledged, to install
the list on the Directory. After the transaction is complete, the
security and list management session are terminated.
The AAA server could be the Home AAA server of the user or could be
an AAA server local to the Directory.
Houri, et al. Expires November 30, 2003 [Page 43]
Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003
End
Point A Directory AAA
| | |
| | |
| (1) Create | |
| Group | |
|------------------------->| |
| | (2) AAA Request |
| |-------------------------->|
| | |
| | |
| | |
| | (3) AAA Response |
| |<--------------------------|
| (4) Create | |
| Group Response | |
|<-------------------------| |
| | |
| | |
Figure 18
1. A user sends a create group request to the directory.
2. The directory sends an AAA request to the AAA of the requesting
user to verify the user is authorized to create a group.
3. The AAA sends an AAA response that authorizes the user to create
the group.
4. The user creates the group.
5. The directory acknowledges the creation of the group.
Houri, et al. Expires November 30, 2003 [Page 44]
Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003
5.4.3.2 Deleting a Group
Authorized entities may desire to delete group lists.
End
Point A Directory AAA
| | |
| | |
| (1) Delete | |
| Group | |
|------------------------->| |
| | (2) AAA Request |
| |-------------------------->|
| | |
| | |
| | |
| | (3) AAA Response |
| |<---------------------------
| (4) Delete | |
| Group Response | |
|<------------------------>| |
| | |
| | |
Figure 19
1. A user sends a delete group request to the directory.
2. The directory sends an AAA request to the AAA of the requesting
user to verify the user is authorized to delete the group.
3. The AAA sends an AAA response that authorizes the user to delete
the group.
4. The user creates the group.
5. The directory acknowledges the deletion of the group by sending a
group delete response.
Houri, et al. Expires November 30, 2003 [Page 45]
Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003
5.4.3.3 Modifying a Group
Authorized entities may desire to modify group lists.
End
Point A Directory AAA
| | |
| | |
| (1) Modify | |
| Group | |
|------------------------->| |
| | (2) AAA Request |
| |-------------------------->|
| | |
| | |
| | |
| | (3) AAA Response |
| |<---------------------------
| (4) Modify | |
| Group Response | |
|<------------------------>| |
| | |
| | |
Figure 20
1. A user sends a modify group request to the directory.
2. The directory sends an AAA request to the AAA of the requesting
user to verify the user is authorized to modify the group.
3. The AAA sends an AAA response that authorizes the user to modify
the group.
4. The directory acknowledges the modification of the group by
sending a group modify response.
Houri, et al. Expires November 30, 2003 [Page 46]
Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003
5.4.3.4 Retrieving a Group
Authorized entities may desire to retrieve group lists.
End
Point A Directory AAA
| | |
| | |
| (1) Retrieve | |
| Group | |
|------------------------->| |
| | (2) AAA Request |
| |-------------------------->|
| | |
| | |
| | |
| | (3) AAA Response |
| |<---------------------------
| (4) Retrieve | |
| Group Response | |
|<------------------------>| |
| | |
| | |
Figure 21
1. A user sends a retrieve group request to the directory.
2. The directory sends an AAA request to the AAA of the requesting
user to verify the user is authorized to modify the group.
3. The AAA sends an AAA response that authorizes the user to modify
the group.
4. The directory sends the group data to the user.
Houri, et al. Expires November 30, 2003 [Page 47]
Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003
5.4.3.5 Publishing User Management Policy
As stated above, wireless resources are often scarce and the user may
not desire to receive messages from just anyone, the user may
populate a policy in the HSP that controls how incoming messages will
be processed.
End
Point A Directory AAA
| | |
| | |
| (1) edit Reception | |
| Policy | |
|------------------------->| |
| | (2) AAA Request |
| |-------------------------->|
| | |
| | |
| | |
| | (3) AAA Response |
| |<---------------------------
| (4) edit Reception | |
| Response | |
|<------------------------>| |
| | |
| | |
Figure 22
1. The endpoint establishes a policy management session with the
presence application.
2. The presence application verifies the user is authorized to
modify the policy by sending an AAA request to the AAA server.
3. The AAA responds to the presence application with an
authorization for the user.
4. The endpoint edits the reception policy.
5. The endpoint terminates the policy management session.
Houri, et al. Expires November 30, 2003 [Page 48]
Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003
5.4.4 Access Deferred Messages
An end use may wish to access deferred messages. In order to ensure
that the unauthorized entities do not access the user's deferred
messages, the IM Application authenticates and authorizes the user to
access the messages before sending a request to the message store.
End Message
Point A Directory AAA Store
| | | |
| | | |
| (1) Retrieve | | |
| Message Request | | |
|------------------>| | |
| | (2) AAA Request | |
| |---------------->| |
| | | |
| | | |
| |(3) AAA Response | |
| |<----------------| |
| | | |
| | | |
| | | |
|< | (4) Retrieve | |
| | Message Request | |
| |--------------------------------->|
| | | |
| | (5) Retrieve | |
| | Message Response| |
| |<---------------------------------|
| (6) Retrieve | | |
| Message Response | | |
|<------------------| | |
| | | |
Figure 23
1. The user sends a request to the IM Application to retrieve
deferred messages.
2. The IM Application authenticates and authorizes the user by
sending an AAA Request to the user's HAAA.
3. The HAAA authenticates and authorizes the user and sends an AAA
Response to the IM Application authorizing the user to access the
deferred messages.
Houri, et al. Expires November 30, 2003 [Page 49]
Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003
4. The IM Application requests the messages by sending a message
retrieve request to the Message Store.
5. The Message Store sends the messages to the IM Application.
6. The IM Application sends the messages to the user.
5.4.5 Presence Operations
Houri, et al. Expires November 30, 2003 [Page 50]
Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003
5.4.5.1 Publishing Presence
The endpoint sends a presence publish request to the presence
application via the HSP as in the Figure 20Figure 17. This request
contains the new presence document to publish . The presence
application authenticates the user and verifies the user is
authorized to store the event at this proxy.
End Presence
Point A Application AAA
| | |
| | |
| (1) Presence | |
| Publish Request | |
|------------------------->| |
| | (2) AAA Request |
| |-------------------------->|
| | |
| | |
| | |
| | (3) AAA Response |
| |<--------------------------|
| (4) Presence | |
| Publish Response | |
|<-------------------------| |
| | |
| | |
Figure 24
1. The endpoint sends a presence publish request to the presence
application.
2. The presence application sends an AAA request to the AAA server
to authorize the MS to publish a presence document to this
application.
3. The AAA sends an AAA response to the presence application
authorizing the presence publish request.
4. The presence application sends a presence publish response to the
endpoint.
Houri, et al. Expires November 30, 2003 [Page 51]
Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003
5.4.5.2 Subscribing to Presence (or a Presence List)
The endpoint sends a presence subscription request to the presence
application of the presence application that owns the presence state
of entity referenced in the logical address. This is shown in Figure
21Figure 18. The user may be subscribing to events for a specific
user or a list of users.
End Presence
Point A Application AAA
| | |
| | |
| (1) Presence | |
| Subscribe Request | |
|------------------------->| |
| | (2) AAA Request |
| |-------------------------->|
| | |
| | |
| | |
| | (3) AAA Response |
| |<--------------------------|
| (4)Presence | |
| Subscribe Response | |
|<-------------------------| |
| | |
| (5) Presence | |
| Notification Response | |
|<-------------------------| |
| | |
| | |
Figure 25
1. The endpoint sends a presence subscribe request to the presence
application that supports the desired entity.
2. The presence application sends an AAA request to the AAA server
to authorize the requesting user to subcribe to the presence of
the presentity.
3. The AAA server sends an AAA response to the presence application
authorizing the presence subscription request.
4. The presence application sends a presence subscription response
to the endpoint.
5. The presence application sends a presence notification response
to the endpoint.
Houri, et al. Expires November 30, 2003 [Page 52]
Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003
5.4.5.3 Receiving a Presence Notification
An endpoint that has previously subscribed to an event as above. The
endpoint receives a notification from the presence application of the
presentity or presentity list as follows according to the
subscription parameters when the subscription was made.
"
End Presence
Point A Application
| |
| |
| (1) Presence |
| Notify Request |
|<-------------------------|
| |
| |
| |
| (2) Presence |
| Notify Response |
|<-------------------------|
| |
| |
Figure 26
1. The endpoint receives a presence notification request.
2. The endpoint sends a presence notification response.
Houri, et al. Expires November 30, 2003 [Page 53]
Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003
5.4.5.4 Querying Presence
End Presence
Point A Application AAA
| | |
| | |
| (1) Presence | |
| Query Request | |
|------------------------->| |
| | (2) AAA Request |
| |-------------------------->|
| | |
| | |
| | |
| | (3) AAA Response |
| |<--------------------------|
| (4) Presence | |
| Query Response | |
|<-------------------------| |
| | |
| | |
Figure 27
1. The endpoint sends a presence query request to the presence
application that supports the desired entity.
2. The presence application sends an AAA request to the AAA server
to authorize the requesting user to query the presence of the
presentity.
3. The HAAA sends an AAA response to the presence application
authorizing the presence query request.
4. The presence application sends a presence query response to the
endpoint.
5.5 Security and Privacy Issues in IM/Presence Architecture
As requests travel from clients to servers, it is important that the
integrity of the message be safeguarded. At the server, the identity
of the client must first be authenticated before authorizing its
request. Integrity of the responses sent by the server must also be
safeguarded. Also, the privacy rights of the clients must not be
violated; the clients should be given the ability to set
accessibility controls (authorization) to information it owns. On
top of all this, the network and framework must be protected from
attacks (e.g. denial-of-service (DOS), worms or viruses) launched
Houri, et al. Expires November 30, 2003 [Page 54]
Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003
from the network level, or from the application itself.
Security often refers to mechanisms used to provide data
confidentiality, integrity and authentication. This section gives a
brief overview of the various aspects of security and privacy
solutions available for use in a SIP based IM/Presence framework.
5.5.1 Authentication
This allows the system to verify "who" is requesting it for service.
The IM system depends on mechanism built into the underlying SIP
protocol to authenticate users. SIP provides a stateless
challenge-based mechanism for authentication that is itself based on
authentication in HTTP. A proxy or UA that receives a request may
challenge the initiator of the request to provide assurance of its
identity. After the originator has been successfully identified, the
recipient of the request should then carry out the Authorization
process to ascertain if the requestor is authorized to make the
request in question, or not.
HTTP/1.0 offers two access authentication schemes: Basic and Digest.
Both schemes depend on verifying that both parties to a communication
know a shared secret (a password). However, Basic's verification
steps involves sending the password in the clear (a big weakness of
this method), unlike in Digest.
5.5.1.1 Challenge-Response Access Authentication Mechanism
When a client (via its Proxy/UA) makes a requests of a server for
access to a protected object or resource, the server can challenge
the UA to provide authentication information by sending the "401
Unauthorized" response message, with a WWW-Authenticate header field
that includes at least a challenge applicable to the requested
resource.
The proxy/User Agent in turn, uses the "407 Proxy Authentication
Required" response message to challenge the authorization of the
client, and must include a Proxy-Authenticate header field containing
at least one challenge applicable to the proxy for the requested
resource.
The challenge itself is composed of a case-insensitive string token
representing the authentication scheme in use (i.e. "Basic" or
"Digest"), followed by a comma-separated list of attribute value
pairs carrying authentication parameters. One such attribute is the
realm, defines the protection space or region under the control of
the server for which the authentication scheme is in effect. The
realm value is a string generally assigned by the challenging origin
Houri, et al. Expires November 30, 2003 [Page 55]
Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003
server. This is often the canonical root URL (absolute URI) of the
server, (e.g. " myrealm@host.com" ) . Other attributes include:
o domain: a quoted space-separated list of URIs that define the
protection space. The client can use this to determine the set of
URIs for which the same authentication information may be sent.
o nonce : a server-specified (hexadecimal or base64) data string
which is uniquely generated each time a 401 response is made. The
contents of the nonce are implementation dependent; for example,
to protect against replay-attack, an implementation may chose not
to accept previously used nonce. The nonce is opaque to the
client.
o opaque : a string of data specified by the server which should be
returned unchanged by the client in the authorization header of
subsequent requests.
o stale : a flag indicating that the previous request from client
was rejected because the nonce value was state.
o algorithm : a string indicating a pair of algorithms to produce
the digest and a checksum (in the case of Digest scheme). If this
is absent, it is assumed to be "MD5" .
o qop-options: an optional indication of the "quality of
protection" values supported by the server.
An example of the WWW-Authenticate header field in a "401
Unauthorized" challenge is:
WWW-Authenticate: Digest
realm="myhost.com",
qop="auth,auth-int",
nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
opaque="5ccc069c403ebaf9f0171e9517f40e41"
A user agent responding to the challenge, or wishing to authenticate
itself with the origin server does so by including an Authorization
header field with its request. Also, a client may authenticate
itself with the proxy/UA by including a Proxy-Authorization header
field with the request. Both these header field values contain
credentials bearing the authentication information of the client for
the realm of the resource being requested. The UA must chose to use
one of the challenges with the strongest authentication scheme it
understands, and request credentials from the user based on that
challenge.
In "basic" authentication scheme, the client must authenticate itself
with a user-ID and a password for each realm. This is not a secure
method as the user name and password are sent in the clear. The
"digest" scheme challenges using a nonce value and the client's
response contains, among other parameters, checksum of the user name,
Houri, et al. Expires November 30, 2003 [Page 56]
Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003
password, the nonce, and the requested URI. Thus the password is
never sent in the clear.
An example of an Authorization header field is:
Authorization: Digest username="Joe",
realm="myhost.com",
nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
uri="sip:joe@myhost.com",
qop=auth,
nc=00000001,
cnonce="0a4f113b",
response="6629fae49393a05397450978507c4ef1",
opaque="5ccc069c403ebaf9f0171e9517f40e41"
5.5.1.2 Limitations
Though the Digest scheme is more secure than the Basic scheme, both
are password based, and thus suffer from problems with password
systems (there is no initial secure link between the server and
client over which to establish the password). Also, the "Digest"
scheme provides message authentication and replay protection only,
without message integrity or confidentiality; it is not as secure as
Kerberos or any client-side private key scheme. See RFC 3261 [5] and
RFC 2617 [2]
5.5.2 Authorization
This is the act of determining whether a requesting entity (client)
is allowed access to a resource, and if so, to what extent. XCAP
[27] has been defined to allow a client provision authorization
decision rules regarding watchers of the presence information
produced by the clients. The authorization decisions in the form of
permission-statements are used by the server to grant or deny access
to the client's presence information stored on the server. See
XCAP-USAGE [28] and PRESENCE-RULES [34].
5.5.3 Integrity And Confidentiality
5.5.3.1 Privacy
This is the withholding of aspects of an individual or entity (e.g.
the identity of a person and related personal information that the
owner wants to remain confidential), from the recipient party in an
exchange of information (as carried in a SIP dialog). These parties
may include the intended destination(s) of the messages and/or any
intermediaries handling the messages. The confidential aspects may
Houri, et al. Expires November 30, 2003 [Page 57]
Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003
include personal data, properties, preferences, and behavioral traits
(e.g. schedules and habits).
Security mechanisms are employed to maintain privacy by protecting
information that should remain private or confidential. Such
mechanisms include making anonymous a party or entity involved in an
information exchange, and encryption.
RFC 3323 [8] defines three levels of privacy - one user-provided, and
the other two, network-provided. User provided privacy involves the
user agent populating the "From" header field of a request with an
anonymous value. Users also take necessary steps to avoid revealing
other unnecessary identity information in related SIP headers (e.g.
Display-names and URIs). For example, a From header for anonymity
is:
From: "Anonymous" <sip:anonymous@anonymous.com>;tag=1928774
In network-provided privacy, intermediaries in the network cooperate
in concealing the confidential information. The user must have a way
of requesting or signaling the desired level of privacy to the user
agent, to ensure the call is routed to the intermediaries capable of
providing the privacy service. The privacy-header (called Privacy)
exists for this reason. User agents should include a Privacy header
when networked-provided privacy is required. It is used to request
privacy handling for requests and responses.
For example, the currently allowed privacy-value options are shown in
the following production:
Privacy-hdr = "Privacy" HCOLON priv-value *(";" priv-value)
priv-value = "header" / "session" / "user" / "none" /
"critical" / token
where:
o header: user requests that a privacy service obscure those headers
which can't be completely rid of identifying information without
the assistance of intermediaries (e.g. Via, Contact headers)
session: user requests that anonymity be provided for the
session(s) (as described in SDP protocol body).
o User: Set by intermediaries to communicate that user-level privacy
functions must be provided by the network.
o None: user requests that no privacy functions be applied by the
privacy service. Critical: User asserts that the privacy services
requested for by the message are critical, and that if these
services can't be provided, the call/request should be rejected.
Houri, et al. Expires November 30, 2003 [Page 58]
Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003
When a Privacy header is constructed, it must consist of either the
value 'none', or one or more of the values 'user', 'header' and
'session', which may be followed by the 'critical' indicator.
5.5.3.2 AAA Service
For greater versatility and scalability, it may be more convenient
for SIP entities to communicate with an Authentication, Authorization
and Accounting (AAA) server (via the SIP-AAA interface). This frees
the agent nodes from storing user credentials and profiles locally.
A common protocol for the AAA framework is Diameter , whose base
supports usage accounting. This based protocol could be used with
appropriate extensions suitable for applications such as network
access control and mobility/roaming. A Diameter client is a device
(e.g. a Network Access Server (NAS) or a Foreign Agent) at the edge
of the network that wishes to perform access control. A Diameter
client generates Diameter messages to request authentication,
authorization and accounting services for the user. A Diameter agent
is a node that does not authenticate or authorize messages locally,
but leaves this functionality to the AAA server. For SIP
applications, the SIP Server and the Diameter client are assumed
co-located and the SIP Server uses the Diameter client to interface
with the AAA infrastructure for authenticating SIP requests (see
Figure 32). This requires presence of a Diameter SIP application as
defined in [29]
[SIP-UA]<--->[SIP-SRVR]-[DIAMETER-CLIENT]<--->[DIAMETER-SRVR]
Figure 32
5.6 Types of Deployments
Several types of presence and IM systems deployments are described:
o Enterprise (Single Domains of Trust)- A presence and IM system
that is built for an enterprise use. The employees of the
enterprise is usually authenticated using the same credentials
that they use for other operations within the enterprise. The
system is usually located within the secured enterprise network
o Federated Systems - Several networks that have created a
federation between them. In these systems a user is able to
inter-operate with users on other systems. There is no need for
each user of being authenticated since the authentication is done
at the level of each system.
o Public Systems Interconnecting - A public system that enables
registered users to use the services of the system (as AOL, MSN,
Houri, et al. Expires November 30, 2003 [Page 59]
Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003
Yahoo). The users in each public system do not belong to the same
organization and therefore can not be trusted as a whole as in
enterprise systems.
o Open Systems - Users do not belong to an organization and are not
registered to use the services of a public system. The services
that the users will use will be freely available on the network
while peer to peer operations between users will be very common in
these system
[TBD. Are there other types of deployments?]
5.6.1 Enterprise (Single Domains of Trust)
5.6.1.1 Definition
[TBD. Detailed definition and examples of the system]
5.6.1.2 Components & Diagrams
[TBD. Definitions of components involved and basic diagrams]
5.6.1.3 Scenarios
[TBD. Several scenarios are listed below. We may need to define
different scenarios for each system type]
5.6.1.3.1 Locating Other Servers
[TBD. How other servers are located mostly referring to RFC 3263
[6]]
5.6.1.3.2 Creating Connections
[TBD. Which server created a connection to which server. When a
connection is broken who is recolonize for re-establishing the
connection etc.]
5.6.1.3.3 Authentication
[TBD. How authentication between servers is done. The
authentication can be very different according to the type of the
system described.]
5.6.1.3.4 State Replication
[TBD. What state the servers in the system should replicate. How
it can be done.]
Houri, et al. Expires November 30, 2003 [Page 60]
Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003
5.6.1.3.5 Advanced Configurations & Scenarios
5.6.1.3.5.1 Firewalls
[TBD. Firewall considerations for the system]
5.6.1.3.5.2 Wireless
[TBD. What the system needs to have in order to support wireless
devices. It could have been discussed under gateways but this
issue deserves a section of its own]
5.6.1.3.5.3 Gateways
[TBD. What gateways the system may need to use. How they are
deployed. What components in each system are involved in
supporting the gateway operation]
5.6.2 Federated Systems
5.6.2.1 Definition
[TBD. Detailed definition and examples of the system]
5.6.2.2 Components & Diagrams
[TBD. Definitions of components involved and basic diagrams]
5.6.2.3 Scenarios
[TBD. Several scenarios are listed below. We may need to define
different scenarios for each system type]
5.6.2.3.1 Locating Other Servers
[TBD. How other servers are located mostly referring to RFC 3263
[6]]
5.6.2.3.2 Creating Connections
[TBD. Which server created a connection to which server. When a
connection is broken who is recolonize for re-establishing the
connection etc.]
5.6.2.3.3 Authentication
[TBD. How authentication between servers is done. The
authentication can be very different according to the type of the
Houri, et al. Expires November 30, 2003 [Page 61]
Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003
system described.]
5.6.2.3.4 State Replication
[TBD. What state the servers in the system should replicate. How
it can be done.]
5.6.2.3.5 Advanced Configurations & Scenarios
5.6.2.3.5.1 Firewalls
[TBD. Firewall considerations for the system]
5.6.2.3.5.2 Wireless
[TBD. What the system needs to have in order to support wireless
devices. It could have been discussed under gateways but this
issue deserves a section of its own]
5.6.2.3.5.3 Gateways
[TBD. What gateways the system may need to use. How they are
deployed. What components in each system are involved in
supporting the gateway operation]
5.6.3 Public Systems Interconnecting
5.6.3.1 Definition
[TBD. Detailed definition and examples of the system]
5.6.3.2 Components & Diagrams
[TBD. Definitions of components involved and basic diagrams]
5.6.3.3 Scenarios
[TBD. Several scenarios are listed below. We may need to define
different scenarios for each system type]
5.6.3.3.1 Locating Other Servers
[TBD. How other servers are located mostly referring to RFC 3263
[6]]
5.6.3.3.2 Creating Connections
Houri, et al. Expires November 30, 2003 [Page 62]
Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003
[TBD. Which server created a connection to which server. When a
connection is broken who is recolonize for re-establishing the
connection etc.]
5.6.3.3.3 Authentication
[TBD. How authentication between servers is done. The
authentication can be very different according to the type of the
system described.]
5.6.3.3.4 State Replication
[TBD. What state the servers in the system should replicate. How
it can be done.]
5.6.3.3.5 Advanced Configurations & Scenarios
5.6.3.3.5.1 Firewalls
[TBD. Firewall considerations for the system]
5.6.3.3.5.2 Wireless
[TBD. What the system needs to have in order to support wireless
devices. It could have been discussed under gateways but this
issue deserves a section of its own]
5.6.3.3.5.3 Gateways
[TBD. What gateways the system may need to use. How they are
deployed. What components in each system are involved in
supporting the gateway operation]
5.6.4 Open systems
5.6.4.1 Definition
[TBD. Detailed definition and examples of the system]
5.6.4.2 Components & Diagrams
[TBD. Definitions of components involved and basic diagrams]
5.6.4.3 Scenarios
[TBD. Several scenarios are listed below. We may need to define
different scenarios for each system type]
Houri, et al. Expires November 30, 2003 [Page 63]
Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003
5.6.4.3.1 Locating Other Servers
[TBD. How other servers are located mostly referring to RFC 3263
[6]]
5.6.4.3.2 Creating Connections
[TBD. Which server created a connection to which server. When a
connection is broken who is recolonize for re-establishing the
connection etc.]
5.6.4.3.3 Authentication
[TBD. How authentication between servers is done. The
authentication can be very different according to the type of the
system described.]
5.6.4.3.4 State Replication
[TBD. What state the servers in the system should replicate. How
it can be done.]
5.6.4.3.5 Advanced Configurations & Scenarios
5.6.4.3.5.1 Firewalls
[TBD. Firewall considerations for the system]
5.6.4.3.5.2 Wireless
[TBD. What the system needs to have in order to support wireless
devices. It could have been discussed under gateways but this
issue deserves a section of its own]
5.6.4.3.5.3 Gateways
[TBD. What gateways the system may need to use. How they are
deployed. What components in each system are involved in
supporting the gateway operation]
5.7 Basic User Scenarios
[TBD. The very basic user scenarios that will be done by a UA
that uses presence and IM]
5.7.1 Locating the Server(s)
Houri, et al. Expires November 30, 2003 [Page 64]
Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003
[TBD. How the server(s) that the user will use will be located.
Mostly referring to RFC 3263 [6]]
5.7.2 Connection
[TBD. Who creates the connection to whom. Reusing of existing
connections. Re-establishing broken connections etc.]
5.7.3 Logging-In (AKA Registering)
[TBD. Use of the REGISTER method in order to logon into the
domain.]
5.7.4 Authentication
[TBD. What authentication methods can be used in order to
authenticate a used in the domain.]
5.7.5 Uploading Presence Document
[TBD. Use of PUBLISH for uploading the presence document. In
systems that do not support PUBLISH yet what other methods are
available for publishing the presence document (REGISTER fields,
HTTP, Web Services)]
5.7.6 Subscribing to a Presentity
[TBD. Simple subscription to a single presentity]
5.7.7 Getting Notifications
[TBD. Getting notifications on the subscribed presentity.
Assuming no authorization or other issues.]
5.7.8 Sending IM
[TBD. Sending IM to another user.]
5.7.9 Receiving IM
[TBD. Receiving IM from another user]
5.8 The Presence Document
PRESENCE of a user or an entity conveys the ability and willingness
of that entity to angage in communication activity with other
entities. This information is represented in a Presence Document.
The basic form of this is the XML based PIDF (Presence Information
Houri, et al. Expires November 30, 2003 [Page 65]
Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003
Document Format) document, defined in [15].]
In PIDF, presence information is modeled as a series of tuples, each
of which contains a status, communications address or contact (a
URI), and other optional markup. The status can be OPEN (available
for communication) or CLOSED (not available for communication). The
status may be extended with other multiple values. Other tuples may
be contained in the presence information, including:
o Identifier: a token to identify the tuple within the presence
information.
o Status: OPEN/CLOSE and/or other extension values.
o Communication Address: Communication means and contact address of
this tuple (optional).
o Relative Priority: numerical value specifying the relative
preference of a communication address (optional)
o Timestamp: timestamp when the tuple was last changed (optiona).
o Note: human readable text about the tuple (optional).
An example of a PIDF document using a default XML namespace is shown
below. It shows that Joe can be contacted via a telephone, instant
messaging (IM) and e-mail. It also shows that Joe is currently busy
on IM. Joe prefers to be contacted via IM and e-mail. He also
indicates that he will be on vacation next week.
Houri, et al. Expires November 30, 2003 [Page 66]
Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:im="urn:ietf:params:xml:ns:pidf:im"
entity="pres:Joe@example.com">
<tuple id="sg89ae">
<status>
<basic>open</basic>
</status>
<contact priority="0.2">tel:+09012345678</contact>
</tuple>
<tuple id="ef64bg">
<status>
<im:im>busy</im:im>
</status>
<contact priority="0.8">im:Joe@yahoo.com</contact>
<timestamp>2004-10-27T16:49:29Z</timestamp>
</tuple>
<tuple id="eg92n8">
<status>
<basic>open</basic>
</status>
<contact priority="1.0">mailto:Joe@yahoo.com</contact>
</tuple>
<note>I'll be on vacation next week</note>
</presence>
[ Add Rich Presence information, and example ]
The PIDF defines a basic XML format for represnting presence
information for a presentiy. That format defines a textual note, an
indication of availability (open or closed) and a Universal Resource
Identifier (URI) for communication. However, it is often the case
that additional information about a user need to be conveyed in ways
that are suitable for automata, and as such is not appropriate for
placement in the "note" element of the PIDF document. The Rich
Presence Information Data Format (RPID) [31] defines extensions to
the PIDF for conveying richer presence information.
One of the characteristics of the PIDF is that the document needs to
carry all the presence information available for the presentity. In
a low bandwidth and high-latency-link environment, the share volume
of such information may be overwhelming, leading to non-optimal
performance. For such environments, it is beneficial to limit the
amount of information transporeted over the network by transporting
only portions of PIDF. This is achieved via the use of a MIME type
which enables transporting changed parts of teh PIDF as specified in
[32]
Houri, et al. Expires November 30, 2003 [Page 67]
Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003
5.9 Composition From Multiple Sources
[TBD. Composing a presence document when there are multiple
publishers]
5.10 Status Values
[TBD. Capture the latest on the ongoing discussion on status
values]
5.11 Instant Messages
[TBD. On the possible format and content of IMs]
5.12 Advanced Presence Scenarios
[TBD. Covering advanced scenarios of usage of presence and
notifications]
5.13 Partial Notifications
[TBD. Summarizing the latest work on partial notifications of
changes to presence documents]
5.14 Authorization of Subscription
[TBD. Scenarios of how subscription authorization can be done.
The topic should include privacy lists (who can see me) and
authorization by an action of the user being subscribed on]
5.15 Presence Lists
[TBD. Catching the latest on events list]
5.16 Watchers List
[TBD. Describing what is watchers. How to subscribe to your
watchers etc.]
5.17 Advanced IM Scenarios
[TBD. Advanced scenarios of IMs including sessions conferences
etc.]
5.17.1 IM Sessions
[TBD. The famous subject of creation of IM session. Describe the
various proposals in this ares. Describe the additional
Houri, et al. Expires November 30, 2003 [Page 68]
Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003
components that systems will have to implement in order to enable
IM sessions. Describe the possible scenarios for creating IM
sessions]
5.17.2 IM Conferences
[TBD. Describe the various possibilities of creation a conference
of IM. Use the relevant parts (for IM) from the conference model
work]
5.17.3 Instant Conferences
[TBD. An instant conference is a conference that is created on
the spot. Usually it is the evolution of one on one IM session.
See Section 5.17.5]
5.17.4 Scheduled Conferences
[TBD. A scheduled conference is a conference in which invitations
are sent to people and advance and they join the conference on the
specified time.]
5.17.5 Switching between IM Page Mode, IM Sessions and IM Conferences
[TBD. Hoe switching can be done between various types of IM
interactions. Not sure if there is already work regarding this
subject]
5.18 Client Capabilities
[TBD. How a client informs the server and other clients on its
capabilities. It is a big issue especially on mobile devices]
5.19 Profiles
[TBD. Yet another big issue, Searching for other users, Sending
profiles to other users etc.]
5.20 Additional Issues and Services
5.20.1 Invisible (Lurking) Mode
[TBD. I want to login into a system see other people while they
do not see me. Should it be allowed? Should users in the system
be notified that lurking is possible.]
Houri, et al. Expires November 30, 2003 [Page 69]
Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003
5.20.2 Action Cues
[TBD. How action cues are going to be sent between users. for
example and indication that your IM partner is typing a response
now]
5.20.3 Emoticons & Backgrounds
[TBD. How the emoticons/backgrounds are downloaded to the
client?] [How is the content of the emoticons/backgrounds is
controlled?]
5.20.4 Message History
[TBD. Storing of message history. Retrieving message history.
Who can store? Who can retrieve? Should I be able to block other
users that I chat with from saving my messages? etc.]
5.20.5 Offline Messages
[TBD. Getting messages that were sent to me while my client is
not connected to the system. Two ways are discussed below]
5.20.6 Queued Offline Messages
[TBD. Messages that are delivered to the user when s/he logs in]
5.20.7 Other Offline
[TBD. Delivery via email, SMS etc.]
5.20.8 File Sharing
[TBD. Sending files between users. A lot of security and
bandwidth issues should be raised here]
5.20.9 Voice
[TBD. Using client capacities, presence information and IMs in
order to start a voice session. The voice session itself will be
done via the INVITE message. We might talk here about sending
voice as the payload of IMs.]
5.20.10 Video
[TBD. Using client capacities, presence information and IMs in
order to start a video session. The video session itself will be
done via the INVITE message. We might talk here about sending
Houri, et al. Expires November 30, 2003 [Page 70]
Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003
video as the payload of IMs.]
5.20.11 General Application Invocation
[TBD. General application invocation using the mechanisms
discussed in this document. I.e. client capabilities, presence
information and IMs]
5.21 Security Considerations
Security is not a single monolithic property of the system, but
rather a series of related but independent properties. This section
discusses threats and stage 2 level solutions to address those
threats. Generic threats considered are:
1. Unauthorized usage of network SIP/SIMPLE servers, either as a new
user or an existing user, of the messaging and presence services
2. Rogue network entity representation as being an authentic network
entity to the endpoint
3. Eavesdropping or altering a message
4. Unauthorized access and modification of configuration data or
stored messages of another user
5.21.1 Authentication
Mutual authentication is required:
o Authentication of the endpoint by service elements
o Authentication of service elements by the endpoint
Note that authentication is separate from authorization to use the
network. A user may be authenticated but nevertheless refused
service.
5.21.2 Network Authentication of the endpoint
It is possible that an attacker represent itself to service elements
as a valid endpoint. This could occur by the attacker attempting to
register or send SIP/SIMPLE packets using the identity of a valid
endpoint.
The general solution to this type of threat is cryptographic
authentication, which could be provided at the SIP layer or at a
lower layer. SIP supports a number of challenge response mechanisms
such as digest authentication [ref]. The HSP or other proxies can
perform SIP authentication using the AAA system. Possible lower
layer security systems include TLS or IKE/IPSec. If TLS is used, the
endpoint has to have a certificate verifiable by a PKI. This is also
Houri, et al. Expires November 30, 2003 [Page 71]
Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003
true for IKE the control protocol for IPSec , however, IPSec can also
be used with pre-shared keys that exist between the endpoint and the
service elements or the AAA server that can make them available to
the service elements.
In some cases the authentication may be performed by one service
element on behalf of other service elements. This may be referred to
a transitive trust model. For this to be applicable, there must be a
secure relationship between the sevice elements.
5.21.3 Endpoint Authentication of the Service Elements
It is important that the endpoint determine that it is communicating
with legitimate service elements. TLS and IPSec provide hop-by-hop
mechanisms. These allow the endpoint to verify the identity of the
first service element in a chain of service elements. The endpoint
must generally rely on the trust model then to establish the identity
of remote service elements. Examples include use of sips uri or 3GPP
IMS.
5.21.4 Authorization for Service
Having authenticated the user, the service elements can use the AAA
system to make authorization decisions relative to specific service
requests.
Another way to authorize the user is certificate attributes in the
user's certificate. This assumes the service elements have verified
the user's certificate.
5.21.5 Integrity and Privacy of SIP/SIMPLE Messages
An attacker may attempt to eavesdrop or alter messages. General
solutions to these types of threats are to use:
o Secure transport protocols such as IPSec or TLS between the
endpoint and the HSP or between the endpoint and the first SIP
proxy encountered by the SIP traffic. There needs to be a
transitive trust on the part of the endpoint with all proxies
involved. Examples include use of sips uri or 3GPP IMS.
o Security transport protocols such as IPSec or TLS between the
endpoint and the conference bridge. There needs to be a trust on
the part of the endpoint and the conference bridge function
involved. Examples include use of sips uri or 3GPP IMS.
o /MIME to protect SIP/SIMPLE message bodies; this security is
between and users, i.e., is end to end. However, in some
commercial applications the message store itself is viewed as a
"user" if the messages may need to be audited later, e.g., the
Houri, et al. Expires November 30, 2003 [Page 72]
Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003
Security Exchange Commission if it needs to review messages from
brokers to investors.
o It is possible to use both security transport protocols and
S/MIME: the former protects the SIP/SIMPLE messages as they
traverse public facilities and the S/MIME protects the message
bodies end to end.
5.21.6 Configuration of Subscriber Data or Stored Messages
An attacker may attempt an unauthorized access and modification of
configuration data of another user. An example of configured data is
instant message groups. The general solution to this threat is to
o Authenticate the user; this is likely a separate authentication as
the data is stored in separate systems outside the scope of the
SIP proxies.
o Verify that the authenticated user is authorized to access or
modify the specific data for a specific user.
o Apply encryption and integrity on the data access control
messages.
o The encryption and integrity should operate between the endpoint
and the directory or database that stores the user's configuration
data or deferred messages.
6. References
6.1 Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
Leach, P., Luotonen, A. and L. Stewart, "HTTP Authentication:
Basic and Digest Access Authentication", RFC 2617, June 1999.
[3] Day, M., Rosenberg, J. and H. Sugano, "A Model for Presence and
Instant Messaging", RFC 2778, February 2000.
[4] Day, M., Aggarwal, S., Mohr, G. and J. Vincent, "Instant
Messaging / Presence Protocol Requirements", RFC 2779, February
2000.
[5] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[6] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol
(SIP): Locating SIP Servers", RFC 3263, June 2002.
Houri, et al. Expires November 30, 2003 [Page 73]
Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003
[7] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002.
[8] Peterson, J., "A Privacy Mechanism for the Session Initiation
Protocol (SIP)", RFC 3323, November 2002.
[9] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C. and
D. Gurle, "Session Initiation Protocol (SIP) Extension for
Instant Messaging", RFC 3428, December 2002.
[10] Rosenberg, J., "A Presence Event Package for the Session
Initiation Protocol (SIP)", RFC 3856, August 2004.
[11] Peterson, J., "Common Profile for Presence (CPP)", RFC 3859,
August 2004.
[12] Peterson, J., "Common Profile for Instant Messaging (CPIM)",
RFC 3860, August 2004.
[13] Peterson, J., "Address Resolution for Instant Messaging and
Presence", RFC 3861, August 2004.
[14] Klyne, G. and D. Atkins, "Common Presence and Instant Messaging
(CPIM): Message Format", RFC 3862, August 2004.
[15] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W. and
J. Peterson, "Presence Information Data Format (PIDF)", RFC
3863, August 2004.
[16] Campbell, B. and J. Rosenberg, "CPIM Mapping of SIMPLE Presence
and Instant Messaging", draft-ietf-simple-cpim-mapping-01 (work
in progress), June 2002.
[17] Rosenberg, J. and M. Isomaki, "Requirements for Manipulation of
Data Elements in Session Initiation Protocol (SIP) for Instant
Messaging and Presence Leveraging Extensions (SIMPLE) Systems",
draft-ietf-simple-data-req-03 (work in progress), June 2003.
[18] Roach, A., Rosenberg, J. and B. Campbell, "A Session Initiation
Protocol (SIP) Event Notification Extension for Resource
Lists", draft-ietf-simple-event-list-05 (work in progress),
August 2004.
[19] Lonnfors, M., Costa-Requena, J., Leppanen, E. and H. Khartabil,
"Partial Notification of Presence Information",
draft-ietf-simple-partial-notify-02 (work in progress), April
2004.
Houri, et al. Expires November 30, 2003 [Page 74]
Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003
[20] Khartabil, H., Leppanen, E. and T. Moran, "Requirements for
Presence Specific Event Notification Filtering",
draft-ietf-simple-pres-filter-reqs-03 (work in progress),
January 2004.
[21] Campbell, B., "SIMPLE Presence Publication Requirements",
draft-ietf-simple-publish-reqs-00 (work in progress), February
2003.
[22] Rosenberg, J., "An Extensible Markup Language (XML) Based
Format for Watcher Information",
draft-ietf-simple-winfo-format-04 (work in progress), January
2003.
[23] Rosenberg, J., "A Watcher Information Event Template-Package
for the Session Initiation Protocol (SIP)",
draft-ietf-simple-winfo-package-05 (work in progress), January
2003.
[24] Niemi, A., "Requirements for Limiting the Rate of Event
Notifications", draft-niemi-sipping-event-throttle-reqs-02
(work in progress), July 2003.
[25] Rosenberg, J., "A Framework for Conferencing with the Session
Initiation Protocol",
draft-ietf-sipping-conferencing-framework-03 (work in
progress), October 2004.
[26] Johnston, A. and O. Levin, "Session Initiation Protocol Call
Control - Conferencing for User Agents",
draft-ietf-sipping-cc-conferencing-05 (work in progress),
October 2004.
[27] Rosenberg, J., "The Extensible Markup Language (XML)
Configuration Access Protocol (XCAP)",
draft-ietf-simple-xcap-04 (work in progress), October 2004.
[28] Rosenberg, J., "Extensible Markup Language (XML) Configuration
Access Protocol (XCAP)Usages for Setting Presence
Authorization", draft-ietf-simple-xcap-auth-usage-01 (work in
progress), October 2003.
[29] Garcia-Martin, M., Belinchon, M., Pallares-Lopez, M.,
Canales-Valenzuela, C. and K. Tammi, "Diameter Session
Initiation Protocol (SIP) Application",
draft-ietf-aaa-diameter-sip-app-04 (work in progress), October
2004.
Houri, et al. Expires November 30, 2003 [Page 75]
Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003
[30] Khartabil, H., "Functional Description of Event Notification
Filtering", draft-ietf-simple-event-filter-funct-03 (work in
progress), October 2004.
[31] Schulzrinne, H., Gurbani, V., Kyzivat, P. and J. Rosenberg,
"RPID: Rich Presence: Extensions to the Presence Information
Data Format (PIDF)", draft-ietf-simple-rpid-03 (work in
progress), March 2004.
[32] Lonnfors, M., Leppanen, E. and H. Khartabil, "Presence
Information Data format (PIDF) Extension for Partial Presence",
draft-ietf-simple-partial-pidf-format-01 (work in progress),
April 2004.
[33] Schulzrinne, H., "A Document Format for Expressing Privacy
Preferences", draft-ietf-geopriv-common-policy-02 (work in
progress), October 2004.
[34] Rosenberg, J., "Presence Authorization Rules",
draft-ietf-simple-presence-rules-00 (work in progress), May
2004.
[35] Campbell, B., "The Message Session Relay Protocol",
draft-ietf-simple-message-sessions-08 (work in progress),
August 2004.
[36] Niemi, A., "An Event State Publication Extension to the Session
Initiation Protocol (SIP)", draft-ietf-sip-publish-04 (work in
progress), May 2004.
[37] Isomaki, M., "An Extensible Markup Language (XML) Configuration
Access Protocol (XCAP) Usage for Manipulating Presence
Document Contents",
draft-ietf-simple-xcap-pidf-manipulation-usage-02 (work in
progress), October 2004.
[38] Lonnfors, M. and K. Kiss, "User agent capability presence
status extension", draft-ietf-simple-prescaps-ext-01 (work in
progress), May 2004.
6.2 Non-Normative References
[39] Saint-Andre, P., "Extensible Messaging and Presence Protocol
(XMPP): Instant Messaging and Presence", draft-ietf-xmpp-im-22
(work in progress), April 2004.
Houri, et al. Expires November 30, 2003 [Page 76]
Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003
Authors' Addresses
Avshalom Houri
IBM
Science Park Building 18/D
Rehovot
Israel
Phone: +972 8 9409761 Ext. 123
EMail: avshalom@il.ibm.com
Alex Audu
Alcatel
3400 West Plano Parkway
Plano,
USA
Phone:
EMail: alex.audu@alcatel.com
Tom Hiller
Lucent
Chicago, IL
USA
Phone:
EMail: tomhiller@lucent.com
Tony Hansen
AT&T Laboratories
Middletown, NJ 07748
USA
Phone: +1.732.420.8934
EMail: tony@att.com
Appendix A. Acknowledgements
The authors gratefully acknowledges the contributions of: Jonathan
Rosenberg, Robert Sparks, Jon Peterson, Ben Campbell and Orit Levin.
Houri, et al. Expires November 30, 2003 [Page 77]
Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2003). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Houri, et al. Expires November 30, 2003 [Page 78]
