INTERNET-DRAFT H. Sugano
Fujitsu
F. Mazzoldi
Personity, Inc.
A. Diacakis
Personity, Inc.
S. Fujimoto
Fujitsu
G. Hudson
MIT
J. D. Ramsdell
The MITRE Corporation
Expires: January 2001 July 2001
Presence and Instant Messaging Protocol (PRIM)
<draft-mazzoldi-prim-impp-02.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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.
Please send comments to the authors or to the prim@ml.fujitsulabs.com
discussion list.
Mazzoldi et al. [Page 1]
INTERNET DRAFT PRIM Specification March 2001
Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract
The architecture and specifications of the Presence and Instant
Messaging protocols (PRIM) are described. PRIM defines a set of
protocols for the Presence and Instant Messaging services which
satisfy the IMPP requirements [RFC2779]. PRIM is also designed so as
to conform with the Common Profile for Instant Messaging (CPIM)
specification being developed in the IMPP WG.
Mazzoldi et al. [Page 2]
INTERNET DRAFT PRIM Specification March 2001
Table of Contents
1. Introduction ......................................... 6
1.1. Design Goals and Assumptions ......................... 6
2. Terminology .......................................... 7
3. Architecture ......................................... 7
3.1. Service Domain Clustering ............................ 8
4. Connection Model ..................................... 8
4.1. Client-server Connections ............................ 8
4.2. Server-server Connections ............................ 8
4.3. Shared Connections for Both Services ................. 9
5. Presence Model ....................................... 9
5.1. Presence Servers ..................................... 9
5.2. PRESENCE INFORMATION ................................. 10
5.3. Presence Publication and Distribution ................ 10
5.4. Lease Model of Presence Information .................. 11
5.5. Presence Subscriptions ............................... 12
6. Instant Messaging Model .............................. 12
7. Namespace ............................................ 12
7.1. Identifiers .......................................... 13
7.2. Name Resolution ...................................... 14
7.2.1. Client-Server Connections ............................ 14
7.2.2. Server-Server Connections ............................ 15
8. Command Structure .................................... 15
8.1. Generic Commands ..................................... 15
8.1.1. Command Headers ...................................... 16
8.1.2. Command Body ......................................... 16
8.2. Requests ............................................. 16
8.2.1. Method ............................................... 17
8.2.2. Version .............................................. 18
8.2.3. Request Identifier ................................... 19
8.2.4. Content Length ....................................... 19
8.3. Responses ............................................ 19
8.4. Classification Of PRIM Methods ....................... 20
9. Command Headers ...................................... 21
9.1. Common Headers ....................................... 22
9.1.1. From ................................................. 22
9.1.2. To ................................................... 22
9.1.3. Auth-State ........................................... 22
9.1.4. SASL-Mechanism ....................................... 22
9.1.5. Redirect ............................................. 22
9.1.6. Server-Address ....................................... 23
9.1.7. AStrength ............................................ 23
9.1.8. Max-Content-Length ................................... 24
9.1.9. Date ................................................. 25
9.2. Entity Headers ....................................... 25
9.2.1. Content-Type ......................................... 25
9.3. Presence Headers ..................................... 25
Mazzoldi et al. [Page 3]
INTERNET DRAFT PRIM Specification March 2001
9.3.1. Class ................................................ 25
9.3.2. Tuple-ID ............................................. 25
9.3.3. Duration ............................................. 26
9.3.4. PI-Type .............................................. 26
9.3.5. Watcher-Type ......................................... 26
9.4. IM Headers ........................................... 26
9.4.1. Message-ID ........................................... 26
9.4.2. Conversation-ID ...................................... 26
9.4.3. Reply-To ............................................. 27
10. Base Command Specifications ......................... 27
10.1. Presence Service Commands ........................... 27
10.1.1. SUBSCRIBE - Placement and renewal of SUBSCRIPTION
..................................................... 27
10.1.2. UNSUBSCRIBE - Removal of SUBSCRIPTION ............... 29
10.1.3. FETCH - Requesting a PRESENCE snapshot .............. 29
10.1.4. NOTIFY - Propagation of PRESENCE INFORMATION ........ 30
10.1.5. CANCELSUBSCRIPTION - reporting cancelled
SUBSCRIPTION ...................................... 31
10.2. Instant Messaging Service Commands .................. 32
10.2.1. SEND - Sending Messages ............................. 32
10.3. General Commands .................................... 34
10.3.1. LOGIN - Connection Setup ............................ 34
10.3.2. STARTTLS - Secuire Connection Setup ................. 35
10.3.3. LOGOUT - Connection Shutdown ........................ 36
10.3.4. PING - Testing a connectionG ........................ 36
10.3.5. VERIFYSERVER - Verifying a server's authority ....... 37
11. Control Commands Specifications ..................... 37
11.1. Presence Service Commands ........................... 38
11.1.1. PUBLISH - Publication of PRESENCE INFORMATION ....... 38
11.1.2. REMOVE - Removal of PRESENCE INFORMATION ............ 40
11.1.3. SETCLASSTABLE ....................................... 41
11.1.4. GETCLASSTABLE ....................................... 42
11.1.5. STARTWATCHERNOTIFY .................................. 42
11.1.6. STOPWATCHERNOTIFY ................................... 43
11.1.7. WATCHERNOTIFY ....................................... 44
11.2. Instant Messaging Service Commands .................. 44
11.2.1. LISTEN .............................................. 44
11.2.2. SILENCE ............................................. 45
11.3. General Commands .................................... 46
11.3.1. SETACL .............................................. 46
11.3.2. GETACL .............................................. 47
12. Authentication ...................................... 47
12.1. Client-Server Authentication ........................ 47
12.2. Server-Server Authentication ........................ 50
13. Privacy Management .................................. 51
13.1. Presence Publication Control ........................ 51
13.1.1. Class Table ......................................... 51
13.1.2. Example ............................................. 51
Mazzoldi et al. [Page 4]
INTERNET DRAFT PRIM Specification March 2001
13.2. Access Control ...................................... 52
13.2.1. Overview ............................................ 52
13.2.2. PRESENTITY ACL ...................................... 53
13.2.3. INSTANT INBOX ACL ................................... 54
13.2.4. Example ............................................. 54
14. Presence Information Data Format (PIDF) ............. 55
14.1. General Design ...................................... 55
14.2. Required Headers for PIDF ........................... 56
14.3. XML Format Definition ............................... 56
14.4. XML tags and attributes definitions ................. 57
14.5. Date Format ......................................... 58
14.6. Examples ............................................ 59
14.7. Presence Document DTD ............................... 60
15. IM Format ........................................... 60
16. CPIM/PRIM Mapping ................................... 61
16.1. Presence Protocol ................................... 61
16.2. Instant Messaging Protocol .......................... 61
17. Security Considerations ............................. 62
18. Appendix A: Response Codes .......................... 62
19. References .......................................... 65
20. Acknowledgements .................................... 66
21. Author's Addresses .................................. 67
22. Full Copyright Statement ............................ 68
Mazzoldi et al. [Page 5]
INTERNET DRAFT PRIM Specification March 2001
1. Introduction
On the Internet and elsewhere, a growing number of people would like
to know when others are available to communicate with them. A system
that provides this type of PRESENCE INFORMATION is known as Presence
Service.
INSTANT MESSAGING allows text base communication to occur in a rapid,
conversational fashion. An INSTANT MESSAGE is delivered to a
recipient if the recipient is listening for messages, otherwise the
message is dropped and the sender is informed of the delivery
failure.
PRESENCE and INSTANT MESSAGING SERVICES are separate and can work
independently of each other. However, by utilizing the PRESENCE
SERVICE a user has a better idea as to whether a recipient is
listening for INSTANT MESSAGES. Therefore, the two services are often
used in tandem.
The PResence and Instant Messaging (PRIM) protocol is designed so
that INSTANT MESSAGING and PRESENCE SERVICES can be provided by a set
of servers distributed across a large number of administrative
domains.
PRIM is also designed to conform to the Common Profile for Instant
Messaging (CPIM) specification being developed by the IMPP WG. This
enables that users of PRIM services exchange PRESENCE INFORMATION and
INSTANT MESSAGES with the users of the services which use other CPIM
compatible protocols.
1.1. Design Goals and Assumptions
Some of the design principles on which this protocol is based are:
o Transfer protocol directly atop of TCP
PRIM assumes TCP as the basic transport mechanism for INSTANT
MESSAGES and PRESENCE INFORMATION. TCP provides a sufficiently
reliable transport infrastructure which is required by both INSTANT
MESSAGING and PRESENCE SERVICES.
o Long-lived Client/Server connections
PRIM uses long-lived client/server TCP connections in order to
receive INSTANT MESSAGES and PRESENCE INFORMATION NOTIFICATIONS.
Note that this is the prevailing model used by most Presence and IM
systems today. It brings the following advantages:
Mazzoldi et al. [Page 6]
INTERNET DRAFT PRIM Specification March 2001
- Overhead is reduced, because authentication is performed once, at
the beginning of the connection. This is important, for example,
when PRESENCE INFORMATION NOTIFICATIONS occur frequently.
- Connections are firewall friendly, because USER AGENTS initiate
connections from inside a firewall that can carry NOTIFICATIONS or
messages initiated from the outside.
o Selective Presence Publication
[RFC2779] stipulates various requirements for access control; 2.3.x
and several in section 5. Among others, we consider the feature of
"Polite Blocking" (5.1.15, 5.2.3) to be very important for PRESENCE
SERVICES. This protocol contains a mechanism for such selective
PRESENCE INFORMATION publication as well as in-band access control.
2. Terminology
[RFC2778] and [RFC2779] define the terminology for the PRESENCE and
INSTANT MESSAGING fields. Please refer to those documents for a
complete glossary of the UPPER CASED terms.
The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",
"RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
interpreted as described in RFC 2119.
3. Architecture
The PRIM architecture involves two components: Service Domains and
USER AGENTS. A Service Domain in the context of PRIM is an
administrative entity of the PRESENCE and INSTANT MESSAGING SERVICES.
Each Service Domain consists of Presence and/or Instant Messaging
Servers, that are responsible for a set of PRINCIPALS. A PRINCIPAL
has an identifier as an entity such as PRESENTITY/WATCHER and
SENDER/INBOX to enjoy the PRESENCE and INSTANT MESSAGING SERVICES. A
PRINCIPAL's Service Domain is called its Home Domain. A PRINCIPAL
connects to servers in its Home Domain via an USER AGENT to access
PRESENCE and INSTANT MESSAGING SERVICES.
PRIM adopts a Client-Server-Server-Client architecture (Figure 1). A
USER AGENT only communicates with servers in its Home Domain, and
only servers can communicate with other servers. These servers may
be located in different domains. The PRIM specifications stipulate
the protocols to be utilized in the two types of communications;
Client-Server and Server-Server. Note that, for server-server
communications, the other server may be a gateway to another domain
using different protocols internally.
Mazzoldi et al. [Page 7]
INTERNET DRAFT PRIM Specification March 2001
+------------------+ +------------------+
| SERVICE DOMAIN |<-------->| SERVICE DOMAIN |
+------------------+ +------------------+
^ ^ ^ ^
| | | |
| | | |
v v v v
+------+ +------+ +------+ +------+
| UA | | UA | | UA | | UA |
+------+ +------+ +------+ +------+
Figure 1. PRIM Service Architecture
3.1. Service Domain Clustering
It may be necessary to have multiple Presence and/or IM Servers to
handle PRINCIPALS of a given domain. It is beyond the scope of this
document to describe how servers within a domain choose to locate
each other and what protocol they choose to communicate with.
4. Connection Model
PRIM is a connection-based protocol. Every protocol command is
exchanged through TCP connections established between clients and
servers or servers and servers.
4.1. Client-server Connections
Both for the PRESENCE SERVICE and the INSTANT MESSAGING SERVICE, USER
AGENTS need to open a TCP connection with each server. This
connection will remain open while the USER AGENT wishes to send or
receive information to/from the PRESENCE or IM SERVICES.
When a USER AGENT establishes a connection to a server, it
authenticate its PRINCIPAL using SASL. If the authentication process
succeeds, the server associates that connection with the specific
PRINCIPAL. After that, the server MUST ensure each request it
receives through that connection pertains to that PRINCIPAL. If a
request pertains to an unauthorized principal the server returns an
error message.
Details of the authentication process is described in section 13.1.
4.2. Server-server Connections
When a Presence or Instant Messaging Server needs to exchange
Mazzoldi et al. [Page 8]
INTERNET DRAFT PRIM Specification March 2001
information with another server, it will resolve the recipient's
name, and start a connection. The connection may be shared by
commands from and to different users. The connection may be closed
by either side at any time when there are no outstanding commands on
the connection from that server's point of view. Any commands sent
to a server which gracefully closed the connection before sending a
reply can safely be assumed to have gone unprocessed.
When a server establishes a connection to another server, that
connection end-point can be authorized to communicate on behalf of
multiple PRESENTITIES or INBOXES. This authorization can take place
either at connection time, or throughout the duration of the
connection.
For example, if server A receives a subscription request from server
B, on behalf of user thanos@networkprojects.com, server A MUST verify
that server B is one of the servers of the networkprojects.com
domain. If so, it will then accept other requests from server B that
pertain to users of the networkprojects.com domain.
PRIM provides several methods to authenticate and authorize servers,
which are described in section 13.2.
4.3. Shared Connections for Both Services
Although the PRESENCE SERVICE and the INSTANT MESSAGING SERVICE are
separate, there may be implementations that choose to implement both.
Additionally those implementations may prefer to share a TCP
connection for both services. To do so, a USER AGENT would open a
single connection and authenticate itself twice using the LOGIN
command, once to the PRESENCE SERVICE and once to the INSTANT
MESSAGING SERVICE. This feature is OPTIONAL for the PRIM
implementations.
The server can differentiate between the commands for either service
by examining the version in the request line that indicates which
service the command pertains to. If the connection is to use TLS,
the STARTTLS connection will only be issued once. The version used
in the STARTTLS command can be that of either service.
5. Presence Model
5.1. Presence Servers
Presence servers are primary components of PRESENCE SERVICE. A
presence server in a Service Domain stores and manages PRESENCE
INFORMATION published by PRESENTITIES in that domain and
Mazzoldi et al. [Page 9]
INTERNET DRAFT PRIM Specification March 2001
SUBSCRIPTIONS from SUBSCRIBERS to the PRESENTITIES. The SUBSCRIBERS
may be located in the same domain and may subscribe from different
domains. If a presence server receives a request for a PRESENTITY in
a different domain, it forwards the request to the target domain
using a inter-domain server-server connection.
When a part of PRESENCE INFORMATION of a PRESENTITY is changed, the
presence server issues NOTIFICATION messages to the relevant
SUBSCRIBERS to that PRESENTITY.
5.2. PRESENCE INFORMATION
PRESENCE INFORMATION transported by the PRIM protocol consists of one
or more PRESENCE TUPLEs, as defined by the IMPP model document
[RFC2778]. A PRESENCE TUPLE may contain status of a particular
COMMUNICATION MEANS, status of a PRINCIPAL, or other information. In
PRIM, a PRESENCE TUPLE is the unit of manipulation for PRESENCE
INFORMATION in the PRESENCE SERVERS. The PRESENCE USER AGENT can
publish PRESENCE INFORMATION per PRESENCE TUPLE.
5.3. Presence Publication and Distribution
Following the IMPP requirements [RFC2779], PRINCIPALS publishing
PRESENCE INFORMATION need to be able to show different PRESENCE
INFORMATION to different WATCHERS, and may also choose not to deliver
PRESENCE INFORMATION to designated WATCHERS ("polite blocking"). To
do so, PRIM uses a notion of Classes of WATCHER. Each PRESENTITY can
classify WATCHERS in different Classes. A WATCHER MUST only exist in
one Class. This classification takes place in the Class Table. The
Class Table may be stored in a presence server, but it may be stored
in other servers co-located with the presence server.
+-------------------------+---------------------------+
| Class Name | Members |
+=========================+===========================+
| important_people | wife@example.com |
| | @workdomain.com |
+-------------------------+---------------------------+
| not_so_important_people | friend@otherexample.com |
| | uncle@otherdomain.com |
+-------------------------+---------------------------+
Table 1. Class Table Example
Table 1 depicts the structure of the Class Table, where the class
"important_people" contains "wife@example.com" and WATCHERS from
"workdomain.com", the class "not_so_important_people" contains
"friend@otherexample.com" and "uncle@otherdomain.com". There is
Mazzoldi et al. [Page 10]
INTERNET DRAFT PRIM Specification March 2001
always the implicit default class, into which all the WATCHERS not
specified by the Class Table are classified.
As stated above, PRESENCE INFORMATION can be updated by the unit of
PRESENCE TUPLE. A PRESENCE TUPLE in a presence updating request,
i.e. a PUBLISH request, from the PRESENCE USER AGENT is associated
with Class information, explicitly or implicitly, for which the new
PRESENCE INFORMATION is distributed. In addition, a PRESENCE TUPLE is
always associated with a TUPLE-ID information. A TUPLE-ID is a name
of a PRESENCE TUPLE.
It should be noted that PRESENCE TUPLES for different Classes may
have the same TUPLE-ID. In this case, the TUPLEs with the same
TUPLE-ID are considered as variations for different classes of
WATCHERS. When a WATCHER in a particular class requests (by
Subscribe or Fetch) for PRESENCE INFORMATION of a PRESENTITY, the set
of PRESENCE TUPLES published for that class is delivered to the
WATCHER.
A PRESENCE USER AGENT of a PRESENTITY manipulates its PRESENCE
INFORMATION by adding, modifying, or deleting TUPLES specifying the
target Class(es). This operation can change the appearance of the
PRESENCE INFORMATION of the PRESENTITY for the WATCHERS in that
class.
When the server receives such an updating request, it retrieves from
the Class Table the list of SUBSCRIBERS to receive the updated
PRESENCE INFORMATION. Then, the presence server will issue
NOTIFICATIONS containing the updated PRESENCE INFORMATION to the
relevant SUBSCRIBERS.
Note: PRINCIPALS can update one PRESENCE TUPLE at a time. However
NOTIFICATIONS contain the whole PRESENCE INFORMATION for a
PRESENTITY. The reason for this is that PRESENCE INFORMATION may be
encrypted end-to-end and thus, if only one PRESENCE TUPLE was
published the receiving remote server may not be able to determine
which existing tuple the new one should replace.
5.4. Lease Model of Presence Information
PRIM adopts the lease model for publishing PRESENCE INFORMATION. That
is, a PRESENTITY MAY have two pieces of PRESENCE INFORMATION, a lease
value and a permanent value, for each PRESENCE TUPLE. The USER AGENT
publishes the lease value and specifies a duration for that lease.
The lease needs to be renewed by the USER AGENT when the duration
elapses, otherwise the permanent value is published automatically by
the server. If no permanent value exists, that tuple will be removed
and no longer published.
Mazzoldi et al. [Page 11]
INTERNET DRAFT PRIM Specification March 2001
This feature provides a flexible solution to handle PRESENCE
INFORMATION for different communication means. While availability of
some devices is subject to unexpected failure or constantly changing
communication environment, that of other communication means might
always be acquirable from a particular entity. The latter do not
have to use the lease value. Instead it can just change the
permanent value of the PRESENCE INFORMATION.
5.5. Presence Subscriptions
WATCHERS can subscribe to a PRESENTITY in order to receive
NOTIFICATIONS when the PRESENCE INFORMATION of that PRESENTITY
changes.
SUBSCRIPTIONS have a duration under which they are in effect. This
duration is specified at the time that the subscription is placed or
renewed. Once that period elapses, the SUBSCRIPTION has to be either
renewed by the SUBSCRIBER, or else it MUST be removed by the
PRESENTITY's Presence Server.
This renewal may be either issued by the USER AGENT, or by the
SUBSCRIBER's Presence Server on behalf of the SUBSCRIBER.
6. Instant Messaging Model
INSTANT INBOXes are entities that receive INSTANT MESSAGES. When a
USER AGENT wishes to start receiving INSTANT MESSAGES, it issues a
LISTEN command to that INSTANT INBOX. Conversely, when it no longer
wishes to receive INSTANT MESSAGES from that INSTANT INBOX, it issues
a SILENCE command.
INSTANT INBOXes have two states, as described in RFC 2779: OPEN and
CLOSED. An INBOX is OPEN when at least one INBOX USER AGENT is
listening to that inbox. It is CLOSED when there are no INBOX USER
AGENT listening to the INBOX.
If an INSTANT MESSAGE is sent to an INBOX that has multiple USER
AGENTS listening, the message is considered to be delivered
successfully if at least one USER AGENT receives it.
7. Namespace
In the following sections, the protocol specification of PRIM is
described. The ABNF [RFC 2234] is used to define the syntax of the
protocol elements. In this section, the syntax of identifiers and the
namespace resolution methods are provided.
Mazzoldi et al. [Page 12]
INTERNET DRAFT PRIM Specification March 2001
7.1. Identifiers
The next ABNF defines a Presence or IM identifiers, which are used to
identify PRESENTITIES and INSTANT INBOXes respectively. It also
defines IP address formats to be referred in some header definitions.
presence-id = word-pres ":" local-part "@" domain
im-id = word-im ":" local-part "@" domain
local-part = 1*( unreserved / escaped )
unreserved = ALPHA / DIGIT / "!" / "$" / "&" / "'" / "*"
/ "." / "+" / "-" / "/" / "=" / "?" / "_" / "~"
escaped = "%" hex-char hex-char
hex-char = DIGIT / "A" / "B" / "C" / "D" / "E" / "F"
/ "a" / "b" / "c" / "d" / "e" / "f"
domain = 1*domain-label *("." 1*domain-label)
domain-label = 1*( unreserved / escaped )
word-pres = %x70.72.65.73 ; "pres"
word-im = %x69.6D ; "im"
decimal-byte = 1*3DIGIT
ALPHA = <defined by RFC 2234 -- 'A'-'Z' / 'a'-'z'>
DIGIT = <defined by RFC 2234 -- '0'-'9'>
hex4 = 1*4hex-char
hexseq = hex4 *(":" hex4)
ip6-address = hexseq / hexseq "::" [ hexseq ] / "::" [ hexseq ]
ip4-address = "::" 1*1decimal-byte 3*3("." 1*1decimal-byte)
The PRIM Presence and IM identifiers are defined so as to align with
CPIM [CPIM]. They have the form of URI [RFC2396] and the same URI
schemes are selected for Presence identifiers ("pres:") and IM
identifiers ("im:").
The syntax for the "local-part" and "domain" of those identifiers are
similar to that for email addresses, specified as addr-spec in
[RFC822]. But, the characters defined in this specification are
restricted so as to conform to the URI syntax [RFC2396]. The
characters which are not allowed in this definition MUST be escaped
and the "unreserved" characters MUST NOT be escaped. Also note that,
unlike a mailto: URL [RFC 2368], a pres: or im: URL cannot contain
multiple addresses.
Moreover, the syntax for "domain-label" here is so defined that it
will be conformant to the prospective specification of the
Internationalized Domain Name [IDN]. A string for "domain" MUST be a
valid domain name according to the rules currently in existence.
Followings are some examples of valid Presence and IM identifiers:
Mazzoldi et al. [Page 13]
INTERNET DRAFT PRIM Specification March 2001
pres:joe@example.net
im:%22Jane%20Smith%22@domain.com
Note that the "local-part" and "domain" are case-insensitive. So,
pres:Joe@Example.Net
pres:joe@ExAmPle.NET
are treated as equivalent.
A PRIM USER AGENT SHOULD recognize a PRESENTITY or INSTANT INBOX
identifier without the scheme if it is entered in a PRESENCE or
INSTANT MESSAGING context. Similarly, a USER AGENT SHOULD display a
PRESENCE or INSTANT MESSAGING identifier without the scheme if it is
displayed in a PRESENCE or INSTANT MESSAGING context.
A PRINCIPAL may or may not have the same IDENTIFIER for its
PRESENTITY and its IM INBOX. However, for an integrated Presence and
IM service, the service SHOULD NOT assign the IDENTIFIERS which are
different only in the scheme part to different PRINCIPALS.
7.2. Name Resolution
Should two PRINCIPALS, each in a different Service Domain, need to
communicate, their corresponding Servers will need to locate each
other, given the IDENTIFIERS of the PRINCIPALS. Moreover, when a
USER AGENT wishes to connect to the Service Domain, it also needs to
locate the servers. PRIM reuses the existing Domain Name Services to
achieve this.
If the domain of the two PRINCIPALS is the same, and they are handled
by different servers, there needs to be a protocol to allow the
servers to interact. This protocol is not in the scope of the
current document.
7.2.1. Client-Server Connections
A USER AGENT MAY support site-specific means of server discovery, but
it SHOULD support the following standard discovery algorithm: the
USER AGENT performs a SRV [RFC 2782] lookup for its home domain using
the protocol "tcp" and the service "presence-clients" for the
PRESENCE SERVICE or "im-clients" for the INSTANT MESSAGING SERVICE.
If no SRV record is present, the USER AGENT performs an A-record look
up on the domain and uses the resulting IP addresses with the
allocated port [xxx] for the PRESENCE SERVICE or [xxx] for the
INSTANT MESSAGING SERVICE.
Mazzoldi et al. [Page 14]
INTERNET DRAFT PRIM Specification March 2001
7.2.2. Server-Server Connections
A server MUST discover a remote domain's server using the following
algorithm: the server performs a SRV lookup for the remote domain
using the protocol "tcp" and the service "presence" (for PRESENCE) or
"im" (for INSTANT MESSAGING). If no SRV record is present, the
server performs an A lookup on the remote domain and uses the
resulting IP addresses with the allocated port [xxx] for PRESENCE or
[xxx] for INSTANT MESSAGING.
Note: The protocol is capable of using four different TCP ports: two
for the PRESENCE SERVICE and two for the INSTANT MESSAGING SERVICE.
Within each service, there may be different ports for client and
server connections. However, the usage of one, two, three or four
ports will be possible for different needs. The protocol ensures
there is no ambiguity between commands received from different
services, or from clients/servers.
8. Command Structure
This section describes the structure of generic PRIM commands and
also gives a classification of PRIM requests based on the connections
on which they are transported. The details of the requests
specifications are described separately in the later sections.
8.1. Generic Commands
A connection transports a sequence of commands. The underlying
character set for commands is Unicode, represented in UTF-8 [RFC
2279]. Command bodies are an exception; they should be treated as
unprocessed octets. An implementation MUST properly handle arbitrary
binary data in the body. A command is either a request or a
response.
PRIM-command = request / response
Requests and responses use the generic command format of [RFC822] for
transferring entities (the body of the command). Both types of
command consist of a start-line, one or more command-header fields
(also known as "headers"), an empty line (i.e., a line with nothing
preceding the CRLF) indicating the end of the header fields, and an
optional command-body.
generic-command = start-line
*command-header
CRLF
[ command-body ]
Mazzoldi et al. [Page 15]
INTERNET DRAFT PRIM Specification March 2001
start-line = request-line / response-line
Receivers of commands SHOULD ignore any empty line(s) received where
a start-line is expected.
8.1.1. Command Headers
PRIM command-header fields follows the same syntactic restriction as
specified by [CPIM-MSGFMT]. Thus, each header field consists of a
header name followed by a colon ("%x3A"), a single whitespace
("%x20") and a field value. Header names are case-sensitive. The
entire header MUST be contained in a single line.
Command header fields are categorized into four types; general-
header, presence-header, im-header, and entity-header. General-
header fields are applicable to both of PRIM Presence and Instant
Messaging Protocols, and used for controlling the basic behavior of
the PRIM applications, such as connection management and delivery of
the commands. Presence-header fields and im-header fields are
included as a meta-data of the content of the commands of the
Presence and Instant Messaging Protocols respectively. Entity-header
fields describes the common feature of the body of the command.
command-header = (general-header ;
/ presence-header ;
/ im-header ;
/ entity-header ;
)
8.1.2. Command Body
Some commands of the PRIM Presence and Instant Messaging Protocols
can contain a command-body. The command-body is used to carry
presence information, instant message, or other information.
8.2. Requests
A generic PRIM request includes the method to be applied to the
resource, the protocol version, and the data needed for asynchronous
requests.
request-line = method
SP version
SP request-identifier
SP content-length
Mazzoldi et al. [Page 16]
INTERNET DRAFT PRIM Specification March 2001
CRLF
As PRIM specifies two kinds of protocols for Presence and Instant
Messaging Services, a PRIM request is classified into two categories.
request = (presence-request / im-request)
presence-request = presence-request-line
*general-header
*presence-header
*entity-header
CRLF
[ command-body ]
im-request = im-request-line
*general-header
*im-header
*entity-header
CRLF
[ command-body ]
presence-request-line = (general-method / presence-method)
SP pres-version
SP request-identifier
SP content-length
CRLF
im-request-line = (general-method / im-method)
SP im-version
SP request-identifier
SP content-length
CRLF
8.2.1. Method
The method token indicates the method to be performed on the
resource. Here, methods are categorized into three groups; presence
methods for presence services, IM methods for instant messaging
services, and general methods for both. In section 8.4, these are
further classified for the detailed specifications.
method = general-method
/ presence-method
/ im-method
general-method = "LOGIN" ; Section 10.1
/ "STARTTLS" ; Section 10.2
Mazzoldi et al. [Page 17]
INTERNET DRAFT PRIM Specification March 2001
/ "LOGOUT" ; Section 10.3
/ "PING" ; Section 10.4
/ "VERIFYSERVER" ; Section 10.5
/ "SETACL" ; Section 10.6.1
/ "GETACL" ; Section 10.6.2
presence-method = "SUBSCRIBE" ; Section 11.1.1
/ "UNSUBSCRIBE" ; Section 11.1.2
/ "FETCH" ; Section 11.1.4
/ "CANCELSUBSCRIPTION" ; Section 11.1.3
/ "NOTIFY" ; Section 11.3
/ "PUBLISH" ; Section 11.2.1
/ "REMOVE" ; Section 11.2.2
/ "SETCLASSTABLE" ; Section 11.4.2
/ "GETCLASSTABLE" ; Section 11.4.3
/ "STARTWATCHERNOTIFY" ; Section 11.4.4
/ "STOPWATCHERNOTIFY" ; Section 11.4.5
/ "WATCHERNOTIFY" ; Section 11.4.6
im-method = "SEND" ; Section 12.2
/ "LISTEN" ; Section 12.1.1
/ "SILENCE" ; Section 12.1.2
8.2.2. Version
The version identifies the version of the protocol in use. It
contains the name string specifying the protocol and the major and
minor version numbers.
version = pres-version / im-version
pres-version = "PRIM-PR" "/" 1*DIGIT "." 1*DIGIT
im-version = "PRIM-IM" "/" 1*DIGIT "." 1*DIGIT
PRIM-PR is used to identify the PRIM Presence Protocol, and is used
for all the requests and responses within the PRESENCE SERVICE.
PRIM-IM is utilized by all requests and responses within the INSTANT
MESSAGING SERVICE.
PRIM adopts the similar protocol versioning policy to those described
in RFC 2145 [RFC2145] and RFC 2616 [HTTP1.1]. Thus, the protocol
version is intended to allow the sender to indicate the format of a
command and its capability for understanding further communication.
See RFC 2616 and 2145 for more detailed explanations.
A PRIM application SHOULD send a command version equal to the highest
version for which it is at least conditionally compliant, and whose
major version is no higher than the highest version supported by the
other end, if it is known. A PRIM application MUST NOT send a
Mazzoldi et al. [Page 18]
INTERNET DRAFT PRIM Specification March 2001
version for which it is not at least conditionally compliant.
A server MAY send a 505 (Version Not Supported) response if cannot
send a response using the major version used in the client's request.
8.2.3. Request Identifier
Request identifiers are used to implement asynchronous requests.
request-identifier = 1*[ALPHA / DIGIT] / "-"
An endpoint of a connection is responsible for generating request
identifiers, and the request identifiers are used to match responses
it receives with the requests it has sent. The other endpoint of a
connection is responsible for labeling a response with the identifier
it received in the request. An identifier may be reused after the
endpoint receives the response to the request with the identifier.
The request identifier of a command is "-" if and only if the request
expects no reply. If an endpoint receives a request with the request
identifier "-", it MUST NOT send any response to the request.
8.2.4. Content Length
The content-length header contains the length of the command body in
bytes.
content-length = 1*DIGIT
8.3. Responses
A response includes many of the same fields as a request with the
addition of a status code and a response phrase.
response-line = version
SP request-identifier
SP content-length
SP status-code
SP response-phrase
CRLF
The request identifier in the response MUST NOT be "-".
The status-code is a 3 digit code and the response-phrase is a short
message description. The values are defined in Appendix A.
Mazzoldi et al. [Page 19]
INTERNET DRAFT PRIM Specification March 2001
Some status codes are common to all commands, whereas others are only
used by a subset of commands. Common status codes to all commands
are:
200 OK
300 Redirect
400 Bad Request
401 Unauthorized (except for LOGIN)
402 Forbidden (except for LOGIN, STARTTLS, PING)
501 Internal Server Error
503 Version Not Supported
8.4. Classification Of PRIM Methods
As stated in Section 4, PRIM protocol commands are transported on two
sorts of connections; client-server connections and server-server
connections. Because those two connections have slightly different
characteristics, some commands are used for both connections and the
other are used only for one of those. In particular, some commands
related to user control are only used for client-server connections.
So, it is useful to classify PRIM methods into two classes from this
respect.
The PRIM request commands are classified into two classes: Base
commands and Control commands. Base commands are those which can be
transported on the server-server connections and possibly on the
client-server connections as well. Control commands are those which
can be transported only on the client-server connections.
The following table shows how each commands be classified into those
classes.
Type of Service Base command Control command
-------------------------------------------------------------------
Presence SUBSCRIBE (+C->S) PUBLISH (C->S)
UNSUBSCRIBE (+C->S) REMOVE (C->S)
FETCH (+C->S) SETCLASSTABLE (C->S)
GETCLASSTABLE (C->S)
NOTIFY (+S->C) STARTWATCHERNOTIFY
CANCELSUBSCRIPTION (C->S)
(+S->C) STOPWATCHERNOTIFY
(C->S)
WATCHERNOTIFY (S->C)
-------------------------------------------------------------------
Instant Messaging SEND (+C->S, +S->C) LISTEN (C->S)
SILENCE (C->S)
Mazzoldi et al. [Page 20]
INTERNET DRAFT PRIM Specification March 2001
-------------------------------------------------------------------
Common for LOGIN (+C->S) SETACL (C->S)
Presence and IM LOGOUT (+C->S) GETACL (C->S)
STARTTLS (+C->S)
PING (+C->S, +S->C)
VERIFYSERVER
Table 2: PRIM protocol command table
Note. Base commands are basically used for S->S, while control
commands are used only for C->S and S->C. Base commands are also
used for C->S or S->C connections (except VERIFYSERVER). Those
additional usages are designated as "+C->S" and "+S->C" in the table.
9. Command Headers
Command headers are defined as follows:
general-header = (from-header
/ to-header
/ auth-state-header
/ SASL-mechanism-header
/ redirect-header
/ server-address-header
/ astrength-header
/ max-content-length-header
/ date-header
)
CRLF
presence-header = (class-header
/ tuple-id-header
/ duration-header
/ pi-type-header
/ watcher-type-header
)
CRLF
im-header = (message-id-header
/ conversation-id-header
/ reply-to-header
)
CRLF
Mazzoldi et al. [Page 21]
INTERNET DRAFT PRIM Specification March 2001
entity-header = content-type-header CRLF
9.1. Common Headers
9.1.1. From
Identifies the PRESENTITY or INBOX that issued this command, or that
it was issued on behalf of.
from-header = "From: " ( presence-id / im-id )
The receiving end of a command SHOULD always check that the sender is
authorized to send commands on behalf of the identifier in the from-
header, as described in Sections 13.
9.1.2. To
Specifies the PRESENTITY or INBOX this command is intended to.
to-header = "To: " ( presence-id / im-id )
9.1.3. Auth-State
Indicates the status in the authentication process in the LOGIN
command. See section ?.? for the detailed use of this header.
auth-state-header = "Auth-State: "
( "init"
/ "continue"
/ "abort" )
9.1.4. SASL-Mechanism
Specifies the SASL mechanism in the LOGIN request or the response to
the LOGIN request. In the request, the SASL mechanism the USER AGENT
wants to use MUST be specified. When used in the response, one or
more mechanisms which the server supports MAY be specified.
SASL-mechanism-header = "SASL-Mech: " mechanisms
mechanisms = mechanism [ *(SP mechanism) ]
mechanism = 1*20(ALPHA / DIGIT / "-" / "_")
9.1.5. Redirect
When a server cannot handle requests from a USER AGENT or other
server, it issues an error repsponse "300 Redirect" which includes the
redirect-header. This lets the caller know that its request cannot
Mazzoldi et al. [Page 22]
INTERNET DRAFT PRIM Specification March 2001
be handled at this server and an alternative server address and port
are provided.
redirect-header = "Redirect: " address SP port
address = domain / ip4-address / ip6-address
port = 1*DIGIT
9.1.6. Server-Address
Indicates the IP address for the server that is initiating the
connection. This header is used in the VERIFYSERVER method to show
the address of the server that needs verification (see Sections 10.5
and 13.2).
server-address-header = "Server-Address: "
( ip4-address / ip6-address )
9.1.7. AStrength
When a server acts as a relay, it MUST communicate to the next node a
rough indication of the authentication strength of the previous hops
using the "Astrength" header. The syntax for the Astrength header
is:
astrength-header = "AStrength: " astrength
astrength = "strong" / "medium" / "weak" / "none"
The meanings of the astrength values are:
strong Command authenticity and integrity cannot be
compromised by an attacker who has full
control of all network links, assuming no
compromise of keying materials, installed
software, or cryptographic algorithms.
medium Command authenticity or integrity could be
compromised by a packet substitution or DNS
spoofing attack.
weak Command could be forged by an attacker who has
previously been a passive listener on one or
more network links.
none Command could be forged by an attacker with no
special information.
Examples of medium protection include one-time passwords [RFC 2289]
and HTTP digest authentication [RFC 2617 section 3]. Examples of
Mazzoldi et al. [Page 23]
INTERNET DRAFT PRIM Specification March 2001
weak protection include cleartext passwords or security protocols
subject to replay attacks.
If a server or USER AGENT receives a command with no Astrength
header, it should assume that the equivalent Astrength is "none",
with one exception: If a server receives a command directly from a
USER AGENT, it should determine the strength of that connection and
use the appropriate AStrength.
A server relaying a command MUST communicate the weaker of the
strength of the connection it received the command on and the
Astrength value communicated from the last entity.
A server MAY choose to reject a command with a "410 AStrength Too
Weak" error because it does not come with sufficient authentication
strength (either as reported by the Astrength value or based on the
connection from the immediate requestor). A relay MUST NOT reject a
response on the basis of insufficient authentication strength.
Note that, separately from connection-level authentication, an
operation may be authenticated using an end-to-end signature. The
Astrength header does not bear any relation to this kind of
authentication.
An example scenario: a PRIM USER AGENT connects to a server for
example.net and authenticates using a weak mechanism. It then issues
a "send" command from alice@example.net to bob@domain.com. The
example.net server connects to domain.com, authenticates using
DNSSEC- signed public keys and forwards the IM with "Astrength: weak"
because the previous link was authenticated with a weak. The
domain.com server sends the command to the clients receiving commands
for bob@domain.com with "Astrength: weak" since that was the
authentication value claimed by example.net, even though domain.com
received the command over a strongly authenticated link.
Another example scenario: a PRIM client connects to a server for
example.net and authenticates using some strong SASL mechanism as
alice. It then issues a "send" command from alice@example.net to
bob@domain.com. The example.net server connects to domain.com and
authenticates, but example.net's public key DNS record is not signed,
so it could have been forged by a DNS spoofing attack. The
example.net server sends the IM with "Astrength: strong" because it
received the command from Alice over a strongly authenticated link;
however, the domain.com server will weaken the Astrength to "Medium"
when forwarding the command to Bob's clients.
9.1.8. Max-Content-Length
Mazzoldi et al. [Page 24]
INTERNET DRAFT PRIM Specification March 2001
Used by the USER AGENT to indicate to the server that it MUST NOT
send commands with length greater than the value supplied.
max-content-length-header = "Max-Content-Length: " 1*DIGIT
9.1.9. Date
Specifies the date and time this command was originally issued. PRIM
adopts the date syntax as defined in Section 15.5, i.e. specified in
[RFC1123].
date-header = "Date: " date-time
; as defined in Section 15.5
[It will be affected by the CPIM specification because it would be
preferable to have the same format with it. Need more discussions.]
9.2. Entity Headers
9.2.1. Content-Type
A command-body MUST NOT be included unless the description of the
particular method allows it. If a command-body is included, the
protocol command headers MAY include a Content-Type as specified in
[RFC 2045]; if no Content-Type is provided, the default is
"application/presence" for Presence commands, "text/plain;
charset=UTF-8" for Instant Messaging commands, and
"application/octet- stream" for the LOGIN command.
The Content-Transfer-Encoding header from [RFC 2045] is not necessary
and MUST NOT be included in any command or response. An
implementation which receives a Content-Transfer-Encoding header
should reject the command with an error 400 Bad Request.
9.3. Presence Headers
9.3.1. Class
Identifies the class(es) to which the PRESENCE TUPLE should be
published (See Section 14.1).
class-header = "Class: " class [ SP class ]
class = 1*(unreserved / escaped)
9.3.2. Tuple-ID
Mazzoldi et al. [Page 25]
INTERNET DRAFT PRIM Specification March 2001
Identifies the PRESENCE TUPLE that is being published. This can be
any string that uniquely identifies the tuple or it MAY be the
CONTACT ADDRESS for the communication means that corresponds to the
PRESENCE TUPLE.
tuple-id-header = "Tuple-ID: " 1*(unreserved / escaped)
9.3.3. Duration
Specifies the amount of seconds this command should remain in effect.
Used for the leased operations.
duration-header = "Duration: " 1*DIGIT
9.3.4. PI-Type
Indicates whether new leased PRESENCE INFORMATION is being published,
an existing lease is being renewed, a permanent value is being
published, or a leased value is being replaced with a permanent
value.
pi-type-header = "PI-Type: "
( "leased"
/ "permanent"
/ "renew"
/ "revert")
9.3.5. Watcher-Type
Used by the WATCHERNOTIFY command to specify whether a FETCH or
SUBSCRIBE operation has occured.
watcher-type-header = "Watcher-Type: " ("fetch" / "subscribe")
9.4. IM Headers
9.4.1. Message-ID
The message-id-header specifies the identifier of each IM, which
distinguishes the message from others. The sender must generate a
unique message-id for each IM sent.
message-id-header = "Message-ID" 1*(DIGIT / ALPHA) ": " im-id
9.4.2. Conversation-ID
Mazzoldi et al. [Page 26]
INTERNET DRAFT PRIM Specification March 2001
The conversation-id is used in the SEND command to identify the
conversation channel shared by the participants of an IM exchange. A
"conversation channel" means a virtual channel which consists of a
thread of IMs. When a PRINCIPAL replies to an IM, the reply MUST
have the same conversation-id header.
conversation-id-header = "Conversation-ID: " 1*(unreserved / escaped)
9.4.3. Reply-To
The reply-to-header is optionally specified in a SEND command. It
indicates an INSTANT INBOX identifier where the sender would prefer
to receive any replies. The recipient SHOULD use the "reply-to"
header, instead of the "from" header, if the former exists.
reply-to-header = "Reply-To: " im-id
10. Base Command Specifications
PRIM base commands are PRIM commands which can be used in the PRIM
server-server connections. Most of those are also used in the PRIM
client-server connections. The base commands are those for
establishing connections to the Presence and Instant Messaging
services and utilizing them. The class of base commands does not
include the PRIM control commands which is described in the section
11.
In header descriptions below, headers specified as (o) indicates they
are optional.
10.1. Presence Service Commands
This section describes the details of the protocol for the PRESENCE
SERVICE.
10.1.1. SUBSCRIBE - Placement and renewal of SUBSCRIPTION
Direction: S->S, C->S
Response: mandatory
Headers: Request Response
---------------------------------------------------------------
S->S from-header from-header
to-header to-header
duration-header duration-header
astrength-header
Mazzoldi et al. [Page 27]
INTERNET DRAFT PRIM Specification March 2001
---------------------------------------------------------------
C->S from-header from-header
to-header to-header
duration-header duration-header
---------------------------------------------------------------
The SUBSCRIBE method is used to express a WATCHER's interest on the
PRESENCE INFORMATION of a PRESENTITY. There are two scenarios where
the method is issued: when a
o WATCHER wishes to establish a new SUBSCRIPTION to a PRESENTITY,
or
o Presence Server or USER AGENT needs to renew a SUBSCRIPTION on
behalf of a WATCHER
The from-header identifies the WATCHER requesting the SUBSCRIPTION.
The to-header specifies the PRESENTITY to subscribe to.
The duration-header specifies the amount of seconds that this
subscription is valid for.
The Return Codes are:
200 OK: The SUBSCRIPTION was placed successfully. The command-body
carries the current PRESENCE INFORMATION for the PRESENTITY.
201 Duration Adjusted: The SUBSRIPTION was placed successfully, yet
a different duration was set and this is indicated in the duration-
header of the response.
402 Forbidden: The PRESENTITY authenticated in the current
connection does not have rights (through the current ACL) to
SUBSCRIBE to the PRESENTITY requested. No command-body is present.
403 Resource Not Found: The PRESENTITY does not exist. No command-
body is present.
505 Too Many Subscriptions: The maximum amount of SUBSCRIPTIONS
placed by the system administrator or by the targeted PRESENTITY
has been reached. No command-body is present.
If a SUBSCRIPTION already exists between a WATCHER and a PRESENTITY,
then a successful SUBSCRIBE request from the WATCHER updates the
duration of the SUBSCRIPTION to the value carried in the request.
Mazzoldi et al. [Page 28]
INTERNET DRAFT PRIM Specification March 2001
10.1.2. UNSUBSCRIBE - Removal of SUBSCRIPTION
Direction: S->S, C->S
Response: mandatory
Headers: Request Response
---------------------------------------------------------------
S->S from-header from-header
to-header to-header
astrength-header
---------------------------------------------------------------
C->S from-header from-header
to-header to-header
---------------------------------------------------------------
The UNSUBSCRIBE method indicates that a WATCHER is no longer
interested in receiving NOTIFICATIONS for changes in PRESENCE
INFORMATION of a PRESENTITY.
It may either be issued by a USER AGENT or a Presence Server on
behalf of the WATCHER.
The from-header identifies the WATCHER requesting the SUBSCRIPTION
cancellation.
The to-header specifies the PRESENTITY to unsubscribe from.
The Response MUST NOT carry a command-body. The Return Codes in the
Response are:
200 OK: The SUBSCRIPTION was removed.
404 Subscription Not Found: there is no SUBSCRIPTION from the
specified WATCHER to the specified PRESENTITY.
Note: When the duration of a SUBSCRIPTION elapses, without the
reception of a renewal, the Presence Server MUST assume an implicit
UNSUBSCRIBE method has been received.
10.1.3. FETCH - Requesting a PRESENCE snapshot
Direction: S->S, C->S
Response: mandatory
Headers: Request Response
---------------------------------------------------------------
S->S from-header from-header
to-header to-header
Mazzoldi et al. [Page 29]
INTERNET DRAFT PRIM Specification March 2001
astrength-header
---------------------------------------------------------------
C->S from-header from-header
to-header to-header
---------------------------------------------------------------
The FETCH method is used when a WATCHER wishes to retrieve the
present value of the PRESENCE INFORMATION for a PRESENTITY.
The from-header identifies the WATCHER requesting the PRESENCE
INFORMATION
The to-header specifies the PRESENTITY that the WATCHER is interested
in.
The Return Codes are:
200 OK: The FETCH was successful. The command-body carries the
current PRESENCE INFORMATION for the PRESENTITY.
402 Forbidden: The PRESENTITY authenticated in the current
connection does not have rights (through the current ACL) to FETCH
the PRESENCE INFO. No command-body is present.
403 Resource Not Found: The PRESENTITY does not exist. No command-
body is present.
10.1.4. NOTIFY - Propagation of PRESENCE INFORMATION
Direction: S->S, S->C
Response: mandatory?
Headers: Request Response
---------------------------------------------------------------
S->S from-header from-header
to-header to-header
astrength-header
---------------------------------------------------------------
S->C from-header from-header
to-header to-header
astrength-header (o)
---------------------------------------------------------------
The NOTIFY command informs WATCHERS when the PRESENCE INFORMATION
of the PRESENTITY they have SUBSCRIPTIONS to has changed. This
command is always issued by Presence Servers.
Mazzoldi et al. [Page 30]
INTERNET DRAFT PRIM Specification March 2001
When a successful PUBLISH method with "leased" PI-type is processed
by the Presence Server, it will go through the list of
SUBSCRIPTIONS, filtered by the Class Table, and identify all the
WATCHERS that need to be notified of the change. It will then send
one NOTIFY command for each of these WATCHERS. When there is no
"lease" value at a PRESENCE TUPLE, a successful PUBLISH method with
"permanent" PI-type will cause to send NOTIFY commands to relevant
WATCHERS.
When some tuple of leased PRESENCE INFORMATION expires (the
duration time elapses) without receiving another PUBLISH command,
that PRESENCE INFORMATION needs to be reverted to the permanent
values. The Presence Server, then, with the same algorithm as
before, sends new NOTIFY commands to the WATCHERS. The NOTIFY will
carry the whole PRESENCE INFORMATION and not just the modified
tuple.
The command-body MUST carry a valid XML document as described in
Section 15, corresponding to the PRESENCE INFORMATION for the
PRESENTITY.
The headers for this command are:
from-header: the PRESENTITY this NOTIFICATION is about
to-header: the WATCHER that needs to receive this information
The Response MUST NOT carry any command-body. The Return Codes are:
200 OK: the PRESENCE INFORMATION was received and processed
correctly.
400 Bad Request: The command was malformed or the command-body did
not carry a valid XML document. The PRESENCE INFORMATION was not
accepted.
403 Resource Not Found: no such WATCHER exists.
10.1.5. CANCELSUBSCRIPTION - reporting cancelled SUBSCRIPTION
Direction: S->S, S->C
Response: none
Headers: Request
---------------------------------------------------------------
S->S from-header
to-header
astrength-header
Mazzoldi et al. [Page 31]
INTERNET DRAFT PRIM Specification March 2001
---------------------------------------------------------------
S->C from-header
to-header
astrength-header (o)
---------------------------------------------------------------
The CANCELSUBSCRIPTION method is used when a PRINCIPAL controlling
a PRESENTITY denies SUBSCRIPTION access (through a SETACL) to a
current WATCHER.
The Presence Server, realizing that the WATCHER already had a
subscription, will send a CANCELSUBSCRIPTION command to the
WATCHER, letting it know that its SUBSCRIPTION has been cancelled.
No future NOTIFICATIONS will be sent to this WATCHER.
The from-header specifies the PRESENTITY that is canceling the
subscription.
The to-header specifies the WATCHER who's SUBSCRIPTION has been
canceled.
No response is needed for this command.
10.2. Instant Messaging Service Commands
This section describes the details of the Base commands for the
INSTANT MESSAGE SERVICE.
10.2.1. SEND - Sending Messages
Direction: C->S, S->S, S->C
Response: mandatory
Headers: Request Response
---------------------------------------------------------------
S->S from-header from-header
to-header to-header
message-id-header message-id-header
conversation-id-header conversation-id-header
astrength-header
---------------------------------------------------------------
C->S,S->C from-header from-header
to-header to-header
message-id-header message-id-header
conversation-id-header conversation-id-header
astrength-header (o)
Mazzoldi et al. [Page 32]
INTERNET DRAFT PRIM Specification March 2001
---------------------------------------------------------------
[Note. It would be necessary to make the "SEND" command syntax
compatible with the CPIM specification. We need more discussion.]
The SEND command is used to transport an INSTANT MESSAGE from the
SENDER's USER AGENT to the RECEIVER's USER AGENT.
The command-body carries an INSTANT MESSAGE, as described in section
16.
The from-header identifies the SENDER of the message.
The to-header identifies the INSTANT INBOX the message is sent to.
The astrength-header indicates the lowest authentication strength for
previous hops of the command.
The message-id-header specifies a unique identifier for each INSTANT
MESSAGE.
The conversation-id-header specifies a unique identifier to
distinguish a given conversation thread between multiple
participants.
The reply-to-header indicates an INSTANT INBOX identifier where the
sender would prefer to receive any replies.
The response to this method MUST NOT carry any command-body, and MAY
have the following return codes:
101 Unknown Delivery Status: The IM Service cannot assure that the
message was delivered.
200 OK: the INSTANT MESSAGE was delivered at least to one PRINCIPAL
that was listening to the recipient INSTANT INBOX.
402 Forbidden: The PRINCIPAL authenticated in the current
connection does not have rights (through the current ACL) to send
messages to the recipient INSTANT INBOX.
408 Inbox Is Closed: the INSTANT MESSAGE could not be delivered
because the recipient INSTANT INBOX was closed. This may be issued
by either the IM Server if there is no-one listening to that inbox,
or by a USER AGENT if it decides to block the sender (see
explanation below).
The response code sent by the IM Server hosting the recipient INSTANT
Mazzoldi et al. [Page 33]
INTERNET DRAFT PRIM Specification March 2001
INBOX is always the most positive response from all the connections
listening to that INBOX. Thus, if at least one USER AGENT
acknowledges the message, then its server will acknowledge it too.
Note: It is important to remember that PRESENCE INFORMATION may be
revealed through the responses to INSTANT MESSAGES. For example, it
may be possible for someone to "ping" an INSTANT INBOX by sending
messages to it, in order to deduce PRESENCE INFORMATION from the
state of that INBOX. USER AGENT implementations can prevent that if
necessary by returning 408 Inbox Is Closed if the sender of an
INSTANT MESSAGE should not know that the INBOX is OPEN.
10.3. General Commands
The commands described in this section apply to both the PRESENCE and
INSTANT MESSAGING services.
10.3.1. LOGIN - Connection Setup
Direction: C->S, S->S
Response: mandatory
Headers: Request Response
---------------------------------------------------------------
S->S domain-header domain-header
auth-state-header auth-state-header
SASL-mechanism-header SASL-mechanism-header
max-content-length max-content-length
---------------------------------------------------------------
C->S from-header from-header
auth-state-header auth-state-header
SASL-mechanism-header SASL-mechanism-header
max-content-length max-content-length
---------------------------------------------------------------
When a USER AGENT establishes a connection to a server, the it MUST
issue a LOGIN request to the server in order to start the
authentication process. The USER AGENT MUST specify the identifier
(pres: or im: address) of the PRINCIPAL in the from-header.
For a server-server connection, the initiating host MUST issue a
LOGIN request prior to sending any presence or IM commands in order
to authenticate itself as an authoritative host in the initiating
domain. The domain MUST be presented with the domain-header.
If the authentication process is not successful the TCP connection
MUST be dropped. The LOGIN request MAY be preceded by the STARTTLS
Mazzoldi et al. [Page 34]
INTERNET DRAFT PRIM Specification March 2001
request when the implementations support TLS for a secure connection.
Any other requests that are received before the authentication
completed MUST receive an "Unauthorized" response.
The authentication process is not necessarily completed in a single
request/response pair, but it can be fulfilled in a sequence of the
request/response pairs. The auth-state-header MUST be used to
indicate the state of the authentication process.
The command-body in the LOGIN request and its response MAY carry the
authentication information for the respective SASL mechanism.
See section 13 for the details of authentication procedures.
Return Codes:
100 Authentication Continued: This response may possibly carry a
command-body with information pertaining to the SASL challenge, and
a SASL-mechanism-header specifying the SASL mechanism supported by
the server. The originator needs to send other LOGIN command, with
auth-state-header as "continue", and the response to the challenge
in the command-body.
200 OK: The sender is authenticated and the connection may be used
to transport further commands.
406 Authorization Failed: The operation failed to authenticate the
connection. No further commands are allowed and the receiver MUST
terminate the connection.
409 Already Authenticated: This is returned if a LOGIN command has
already succeeded.
10.3.2. STARTTLS - Secuire Connection Setup
Direction: C->S, S->S
Response: mandatory
Headers: Request Response
---------------------------------------------------------------
S->S none none
---------------------------------------------------------------
C->S none none
---------------------------------------------------------------
A client or server MAY issue STARTTLS request to upgrade a TCP
connection to a TLS [TLS] enabled one. Implementations that support
TLS MAY issue a STARTTLS request prior to issuing any other requests.
Mazzoldi et al. [Page 35]
INTERNET DRAFT PRIM Specification March 2001
Once the client credentials are successfully exchanged using TLS
negotiation, the "EXTERNAL" SASL mechanism MAY be used in the
subsequent LOGIN process. The "PLAIN" SASL mechanism SHOULD NOT be
used if the STARTTLS upgrading process fails to establish a fully
strong encryption layer.
The Request and the response MUST NOT carry a command-body.
Return Codes:
200 OK: The TLS negotiation should start. Once a STARTTLS command
issued, the initiator MUST NOT issue further requests until a
server response is received and the TLS negotiation is completed.
501 Not Implemented: TLS is not implemented and thus the client
must authenticate itself using the LOGIN method.
10.3.3. LOGOUT - Connection Shutdown
Direction: C->S, S->S
Response: none
Headers: Request
---------------------------------------------------------------
S->S none
---------------------------------------------------------------
C->S none
---------------------------------------------------------------
The receiver of the LOGOUT command MUST NOT send any response.
10.3.4. PING - Testing a connectionG
Direction: C->S, S->S, C->S
Response: none
Headers: Request
---------------------------------------------------------------
S->S none
---------------------------------------------------------------
C->S,S->C none
---------------------------------------------------------------
When a peer in a connection wants to verify if the connection is
alive, it may send a PING command. No response is expected from the
other peer.
Mazzoldi et al. [Page 36]
INTERNET DRAFT PRIM Specification March 2001
A successful transmission of a PING does not guarantee its reception
at the other end, nor does it verify that all is well with its peer.
However the transmission of the PING may provoke an error, and
thereby causing the sending peer to realize there is a problem with
the connection. If this happens the USER AGENT or server assumes an
implicit LOGOUT command.
10.3.5. VERIFYSERVER - Verifying a server's authority
Direction: S->S
Response: mandatory
Headers: Request Response
---------------------------------------------------------------
S->S server-address-header server-address-header
---------------------------------------------------------------
As described in section 13.2, when a server needs to verify whether
another server (known through its IP address) belongs to a given
domain, it performs one or more DNS lookups. Large domains with a
significant amount of servers might not be able to publish every
entry for every server, due to DNS limitations. Thus a DNS lookup
might not be sufficient to determine whether a given server belongs
to a given domain.
If it is not possible to verify the domain of a server through a DNS
lookup, a VERIFYSERVER command can be issued.
The VERIFYSERVER MAY be issued in a new TCP connection, without
previous LOGIN. The verifying server will issue the command to any
of the addresses returned in the DNS lookup.
The server-address-header specifies the IP address of the server that
needs verification.
The response MUST NOT have a command body.
Return Codes:
200 OK: the server does belong to that domain.
403 Resource Not Found: the server does not belong to this domain.
11. Control Commands Specifications
PRIM control commands are those which are used only in the PRIM
Mazzoldi et al. [Page 37]
INTERNET DRAFT PRIM Specification March 2001
client-server connections. The control commands include those for
PRESENCE INFORMATION publication and privacy control, setting of IM
receiver and access control.
11.1. Presence Service Commands
This section describes the details of the commands for the PRESENCE
INFORMATION publication and privacy control.
11.1.1. PUBLISH - Publication of PRESENCE INFORMATION
Direction: C->S
Response: mandatory
Headers: Request Response
---------------------------------------------------------------
C->S from-header from-header
pi-type-header pi-type-header
duration-header (o) duration-header (o)
tuple-id-header tuple-id-header
class-header (o) class-header (o)
---------------------------------------------------------------
This method is used to publish PRESENCE INFORMATION for a PRESENTITY.
It is used to set the leased and permanent values of the PRESENCE
INFORMATION.
The command-body MUST carry one XML document as described in Section
15, corresponding to the PRESENCE TUPLE the USER AGENT wishes to
publish.
The USER AGENT SHOULD ensure that at most one PRESENCE TUPLE is
published for a given address at any moment for a specific class.
If the class-header is present in this command, the value specifies
the classes of WATCHERS to which the carried PRESENCE INFORMATION
should be published. The value of the class-header MUST be one or
more valid class names which are already placed in the Class Table.
If this command has no class-header, it MUST be considered as
published to the default class.
All successful PUBLISH operations will cause NOTIFICATIONS to be sent
to all the SUBSCRIBERS in the Class(es) specified by the class-header
or the default class, except:
o Renewal of an existing lease
o Publishing of permanent PI, while a valid lease exists
Mazzoldi et al. [Page 38]
INTERNET DRAFT PRIM Specification March 2001
In addition, the expiration of a lease value of a PRESENCE TUPLE will
also cause NOTIFICATIONS to be sent to all the SUBSCRIBERS to the
TUPLE of the PRESENTITY.
The headers used for this method are:
from-header: identifies the PRESENTITY publishing the PRESENCE
INFORMATION
pi-type-header: if this header carries the value "leased", the
PRESENCE INFORMATION will be valid only for the period of time
specified in the duration-header (in seconds). After that time
elapses and the lease is not renewed the PRESENCE INFORMATION
reverts to its permanent value.
The leased value can be renewed if the USER AGENT issues a PUBLISH
operation with a "renew" pi-type-header.
The leased value can be removed if the USER AGENT issues a PUBLISH
operation with a "revert" pi-type-header.
If "permanent" is specified, this determines that value that the
PRESENCE INFORMATION will revert to when the lease expires.
duration-header: only available for the "leased" or "renew" value
in the type-header, it represents the amount of seconds for which
the PRESENCE TUPLE sent will be valid. After that period, if no
PUBLISH method is received, the server MUST publish the permanent
value of the PRESENCE TUPLE or, if no permanent value exists it
MUST remove the PRESENCE TUPLE.
tuple-id-header: identifies the PRESENCE TUPLE that is being
published. The server uses this value to determine which existing
PRESENCE TUPLE it must remove or replace with the current one.
class-header: the Classes the PRESENCE TUPLE should be published
to. This value is used to determine which WATCHERS should receive
this information. If the class-header is not present, it MUST be
treated that the PRESENCE TUPLE is published to the default class.
The Response for this command MUST NOT carry any command-body. The
Return codes for this command are:
200 OK: the PRESENCE TUPLE has been accepted. If it is leased or
if it is permanent and no lease exists, the PRESENTITY'S PRESENCE
INFO will be distributed to all SUBSCRIBERS in the classes
specified in the class-header.
Mazzoldi et al. [Page 39]
INTERNET DRAFT PRIM Specification March 2001
400 Bad Request: The command was malformed or the command-body did
not carry valid PRESENCE INFORMATION as defined in section 15. The
PRESENCE TUPLE was not accepted.
402 Forbidden: The PRESENTITY authenticated in the current
connection does not have rights (through the current ACL) to
PUBLISH PRESENCE INFORMATION for this PRESENTITY.
403 Resource Not Found: The PRESENTITY does not exist.
11.1.2. REMOVE - Removal of PRESENCE INFORMATION
Direction: C->S
Response: mandatory
Headers: Request Response
---------------------------------------------------------------
C->S from-header from-header
tuple-id-header tuple-id-header
class-header (o) class-header (o)
---------------------------------------------------------------
This method is used to remove one TUPLE of PRESENCE INFORMATION for a
PRESENTITY. The TUPLE is specified by tuple-id-header and optional
class-header. Once removed the PRESENCE TUPLE will no longer be
published to WATCHERS.
The value of the class-header MUST be a valid class name which are
already placed in the Class Table. If this command has no class-
header, it MUST be considered that the default class is specified.
This command will remove both the leased and permanent values of the
tuple, and also trigger the appropriate NOTIFICATIONS.
The headers used by this method are:
from-header: identifies the PRESENTITY publishing the PRESENCE
INFORMATION
tuple-id-header: identifies the PRESENCE TUPLE that is being
removed.
class-header: the Classes from which the PRESENCE TUPLE should be
removed from. If the class-header is not present, it MUST be
treated as the default class is specified.
The Response for this command MUST NOT carry any command-body. The
Mazzoldi et al. [Page 40]
INTERNET DRAFT PRIM Specification March 2001
Return codes for this command are:
200 OK: the PRESENCE TUPLE has been removed
402 Forbidden: The PRESENTITY authenticated in the current
connection does not have rights (through the current ACL) to REMOVE
any PRESENCE TUPLES.
403 Resource Not Found: The PRESENTITY does not exist or the tuple
does not exist.
The successful removal of a PRESENCE TUPLE will trigger the server to
send NOTIFICATION commands to all the SUBSCRIBERS in the Class(es)
specified by the Class header.
11.1.3. SETCLASSTABLE
Direction: C->S
Response: mandatory
Headers: Request Response
---------------------------------------------------------------
C->S from-header from-header
---------------------------------------------------------------
Through the SETCLASSTABLE method, the USER AGENT sets the list of
WATCHERS belonging to a given Class.
The command-body of the SETCLASSTABLE command MUST carry a CLASSTABLE
XML Element, as described in Section 14.1.
The from-header specifies the PRESENTITY for which this Class Table
should be set.
The Response MUST NOT carry a command-body. The possible Return
Codes are:
200 OK: The class table sent replaced the one currently active in
the server.
400 Bad Request: The command was malformed or the command-body did
not carry a valid XML document. The Class table did not replace
the current one.
402 Forbidden: The PRESENTITY authenticated in the current
connection does not own the PRESENTITY specified in the from-
header. The Class table did not replace the current one.
Mazzoldi et al. [Page 41]
INTERNET DRAFT PRIM Specification March 2001
403 Resource Not Found: The PRESENTITY does not exist. The Class
table did not replace the current one.
11.1.4. GETCLASSTABLE
Direction: C->S
Response: mandatory
Headers: Request Response
---------------------------------------------------------------
C->S from-header from-header
---------------------------------------------------------------
The GETCLASSTABLE method is used by the USER AGENT to retrieve the
Class Table for a given PRESENTITY. The response to GETCLASSTABLE
command contains a CLASSTABLE XML element in the command-body.
The from-header specifies the identifier of the PRESENTITY for which
the Class Table is required.
The Return Codes are:
200 OK: The command-body of the Response carries a CLASSTABLE XML
Element, as described in Section 14.1., representing the Class
Table for the PRESENTITY requested.
402 Forbidden: The PRESENTITY authenticated in the current
connection does not own the PRESENTITY in the from-header. No
command-body is present.
403 Resource Not Found: The PRESENTITY does not exist. No command-
body is present.
11.1.5. STARTWATCHERNOTIFY
Direction: C->S
Response: mandatory
Headers: Request Response
---------------------------------------------------------------
C->S from-header from-header
---------------------------------------------------------------
This command instructs a server to start sending watcher information
to a USER AGENT.
The from-header identifies the PRESENTITY requesting the
Mazzoldi et al. [Page 42]
INTERNET DRAFT PRIM Specification March 2001
NOTIFICATIONS.
The Response to STARTWATCHERNOTIFY may carry a command-body,
depending on the return Code:
200 OK: The server will start sending NOTIFICATIONS when new
SUBSCRIPTIONS are placed or when the a FETCH is performed on the
PRESENTITY. The command-body carries an XML document SUBSCRIBERS
with the information about the current SUBSCRIBERS of the specified
presentity.
402 Forbidden: The PRESENTITY authenticated in the current
connection does not have rights to perform the requested operation.
No command-body is present.
403 Resource Not Found: The PRESENTITY does not exist. No command-
body is present.
The XML document carried in the command-body if the operation is
successful MUST be valid under the following DTD:
<!ELEMENT subscribers (subscriber)*>
<!ELEMENT subscriber (#PCDATA)>
Each subscriber element carries the identifier of one WATCHER
SUBSCRIBED to the requested PRESENTITY.
11.1.6. STOPWATCHERNOTIFY
Direction: C->S
Response: mandatory
Headers: Request Response
---------------------------------------------------------------
C->S from-header from-header
---------------------------------------------------------------
This command instructs a server to stop sending watcher information
to a USER AGENT.
The from-header identifies the PRESENTITY requesting the termination
of the NOTIFICATIONS.
The Response to STARTWATCHERNOTIFY MUST NOT carry a command-body.
200 OK: The server will stop sending watcher information
NOTIFICATIONS.
Mazzoldi et al. [Page 43]
INTERNET DRAFT PRIM Specification March 2001
402 Forbidden: The PRESENTITY authenticated in the current
connection does not have rights to perform the requested operation.
403 Resource Not Found: The PRESENTITY does not exist.
11.1.7. WATCHERNOTIFY
Direction: S->C
Response: mandatory
Headers: Request Response
---------------------------------------------------------------
S->C from-header from-header
to-header to-header
watcher-type-header
---------------------------------------------------------------
Notifies the PRINCIPAL that a FETCH and SUBSCRIBE operation was
performed on the PRESENTITY indicated in the to-header, by the
PRESENTITY indicated in the from-header. This command is also issued
when a SUBSCRIPTION to that PRESENTITY has been changed by an
UNSUBSCRIBE command or expiration.
The headers for this method are:
from-header: identifies the WATCHER performing the FETCH or
SUBSCRIBE request.
to-header: specifies the PRESENTITY that the FETCH or SUBSCRIBE was
performed upon.
watcher-type-header: specifies whether a FETCH or SUBSCRIBE
occurred.
11.2. Instant Messaging Service Commands
11.2.1. LISTEN
Direction: C->S
Response: mandatory
Headers: Request Response
---------------------------------------------------------------
C->S from-header from-header
---------------------------------------------------------------
Whenever a USER AGENT needs to receive messages targeted to an
Mazzoldi et al. [Page 44]
INTERNET DRAFT PRIM Specification March 2001
INSTANT INBOX, it MUST issue a LISTEN command to its IM Server.
The from-header specifies the INSTANT INBOX identifier that the
PRINCIPAL wishes to listen to.
The Response MUST NOT carry a command-body either, and the possible
Return Codes are:
200 OK: the PRINCIPAL is now listening to the INSTANT INBOX, and
will receive any messages sent to it.
402 Forbidden: The PRINCIPAL authenticated in the current
connection does not have rights (through the current ACL) to LISTEN
to the INSTANT INBOX requested.
403 Resource Not Found: The INSTANT INBOX does not exist.
11.2.2. SILENCE
Direction: C->S
Response: mandatory
Headers: Request Response
---------------------------------------------------------------
C->S from-header from-header
---------------------------------------------------------------
When a PRINCIPAL is not interested to receive any more messages from
an INSTANT INBOX, it issues a SILENCE method, through which it
instructs the IM Server not to forward any messages arriving to the
specified INBOX through its connection.
The from-header specifies the INSTANT INBOX identifier the PRINCIPAL
does not want to listen to any more.
The response to this command MUST NOT have any command-body either,
and the return codes are:
200 OK: the PRINCIPAL will not longer receive any messages for the
specified INBOX. This does not imply that the INBOX is closed,
since there may be other PRINCIPALS listening to the same INBOX.
403 Resource Not Found: The INBOX does not exist.
408 Inbox Is Closed: the PRINCIPAL is not currently listening to
that INBOX.
Mazzoldi et al. [Page 45]
INTERNET DRAFT PRIM Specification March 2001
11.3. General Commands
The general control commands are those to control Access Control
Lists.
The PRESENCE and INSTANT MESSAGING SERVICES use the Access Control
Lists to determine what operations PRESENTITIES and INSTANT INBOXES
are permitted to perform on protected resources. The operations
that can be performed on PRESENTITIES are different than those for
INSTANT INBOXES. However, the access control mechanisms are the
same and thus we will describe them together.
11.3.1. SETACL
Direction: C->S
Response: mandatory
Headers: Request Response
---------------------------------------------------------------
C->S from-header from-header
---------------------------------------------------------------
This operation is used by the USER AGENT to send an access control
list to the server.
The command-body MUST carry a valid XML document according to the
DTD given in Section 1?.
The from-header specifies the PRESENTITY or INBOX this ACL pertains
to.
The Response MUST NOT have a command-body.
Return Codes:
200 OK: The access control list sent replaced the one currently
active in the server.
400 Bad Request: The command was malformed or the command-body did
not carry a valid XML document. The access control list did not
replace the current one.
402 Forbidden: The PRINCIPAL authenticated in the current
connection does not own the requested resource, thus cannot set the
ACL for it. The access control list did not replace the current
one.
403 Resource Not Found: The resource (PRESENTITY or IM INBOX) does
Mazzoldi et al. [Page 46]
INTERNET DRAFT PRIM Specification March 2001
not exist. The access control list did not replace the current
one.
11.3.2. GETACL
Direction: C->S
Response: mandatory
Headers: Request Response
---------------------------------------------------------------
C->S from-header from-header
---------------------------------------------------------------
This method is issued to retrieve the current access control list for
a specific resource from a Presence or IM server.
The from-header specifies the identifier of the resource (PRESENTITY
or IM INBOX) for which the ACL is required.
The Return Codes are:
200 OK: The command-body of the Response has a valid XML document
according to the DTD presented in Section 14, representing the
current ACL for the resource requested.
402 Forbidden: The PRINCIPAL authenticated in the current
connection does not own the requested resource, thus cannot get the
ACL for it. No command-body is present.
403 Resource Not Found: The resource (PRESENTITY or IM INBOX) does
not exist. No command-body is present.
12. Authentication
PRIM implements security on a per-connection basis: each connection
end-point is authenticated in order to establish the PRESENTITIES
and INBOXES on behalf of which that end-point can communicate.
After authentication succeeds, the other end-point will accept
requests pertaining to those PRESENTITIES or INBOXes, and direct
requests to them over that connection.
12.1. Client-Server Authentication
When a USER AGENT establishes a connection to a server it issues a
LOGIN command to authenticate its PRINCIPAL. The authentication
Mazzoldi et al. [Page 47]
INTERNET DRAFT PRIM Specification March 2001
procedure in PRIM uses SASL [SASL]. The LOGIN request and response
MUST include a SASL-Mechanism header field so that the USER AGENT
and the server could negotiate the SASL mechanism to be used. As
SASL mechanisms, every PRIM implementation MUST implement PLAIN
[SASL-PLAIN] and is RECOMMENDED to implement CRAM-MD5 [CRAM-MD5],
and EXTERNAL [SASL]. It MAY also implement other mechanisms as
needed.
If the authentication process succeeds, the server associates that
connection with the specific PRINCIPAL. After that, the server
MUST ensure each request it receives through that connection
pertains to that PRINCIPAL. If a request pertains to an
unauthorized principal the server returns an error message.
The LOGIN authentication procedure is sketched as follows;
(1) The initial LOGIN request
A USER AGENT issues a LOGIN request including the Auth-State header
with the value "init". It MUST also contain the SASL-Mechanism
header whose value is a comma-separated list of SASL mechanisms the
USER AGENT is capable to use in the descending order of preference.
[Example]
LOGIN PRIM-PR/1.0 0224 0
From: pres:suga@prim.fujitsu.com
Auth-State: init
SASL-Mech: CRAM-MD5 PLAIN
If the LOGIN request is acceptable, the server SHOULD respond with
'100 Authentication Continued' response. It MUST contains the
SASL-Mechanism header with the value of at least one selected SASL
mechanism by the server. If a challenge-response mechanism is
selected, the response MUST contain a challenge data in the body.
PRIM-PR/1.0 0224 48 100 Authentication Continued
From: pres:suga@prim.fujitsu.com
Auth-State: init
SASL-Mech: CRAM-MD5
<20010226095208.1018677043.foo1.bar.fujitsu.com>
(2) The subsequent LOGIN requests
If a USER AGENT receives a '100 Authentication Continued' response
to the initial LOGIN request, it SHOULD try another LOGIN request
Mazzoldi et al. [Page 48]
INTERNET DRAFT PRIM Specification March 2001
with the header 'Auth-State: continue'. This LOGIN request MUST
contain the SASL-Mechanism header with the single value of selected
SASL mechanism.
The LOGIN request MAY contain the PRINCIPAL's authentication
information in the body required by the selected mechanism. Details
in the case of CRAM-MD5, PLAIN, and EXTERNAL are described in the
following subsections.
If the LOGIN request is validated, the server respond with a '200
OK' response. If the same PRINCIPAL is already authenticated by a
preceding LOGIN procedure, the server MAY respond with a '409
Already Authenticated'. Otherwise, a '406 Authentication Failed'
response SHOULD be returned to the USER AGENT. In this case, the
USER AGENT MUST NOT send any other request commands in this
connection.
(2-a) CRAM-MD5
The USER AGENT calculates the response data using the keyed MD5
algorithm [KEYED-MD5] where the key is the shared pass phrase and
the text is the challenge data. Then, it sends the hexadecimal
string of the response octets prepended by the user name and CRLF
in the body of the LOGIN request.
[Example]
LOGIN PRIM-PR/1.0 0225 55
From: pres:suga@prim.fujitsu.com
Auth-State: continue
SASL-Mech: CRAM-MD5
Content-Type: text/plain
suga@prim.fujitsu.com
106d12b16fc323dc2f3d19b587f8d0ff
(2-b) PLAIN
The PLAIN mechanism is intended to be used only on a fully secured
connection, such as one already encrypted using a prior STARTTLS
command. In this case, the body part of the LOGIN request contains
the user name and the pass phrase in a plain text separated by
CRLF.
[Example]
LOGIN PRIM-PR/1.0 84505230 32
Mazzoldi et al. [Page 49]
INTERNET DRAFT PRIM Specification March 2001
From: pres:suga@prim.fujitsu.com
Auth-State: continue
SASL-Mech: PLAIN
Content-Type: text/plain
suga@prim.fujitsu.com
hi there!
(2-c) EXTERNAL
The EXTERNAL mechanism is intended to be used in the case that the
PRINCIPAL has been already authenticated with some external
authentication method, such as TLS client authentication. The LOGIN
command using this mechanism contains nothing in the body.
12.2. Server-Server Authentication
When a server establishes a connection to another server, that
connection end-point MUST be authorized to communicate on behalf of
multiple WATCHERS/PRESENTITIES or SENDERS/INBOXES. This authorization
takes place at connection time using a LOGIN command.
If the connection uses TLS, then the domains served by each end-point
are established in the beginning, through the certificates provided.
Then the LOGIN command MUST contain the "EXTERNAL" SASL-mechanism
specifying the authorized domain name it represents in the domain-
header.
If the connection does not use TLS but the end-points can be
authenticated using some other shared secrets, the LOGIN command MUST
specify another SASL-mechanism such as CRAM-MD5.
If the connection does not use TLS and the end-points shares no
secret, the LOGIN command SHOULD specify "ANONYMOUS" SASL-mechanism.
The server receiving the command MAY accept the LOGIN by checking the
originating server truly belongs to the originating domain using DNS,
or MAY verify the originating server by using a VERIFYSERVER request.
For example, if server A receives a LOGIN request from a server B in
the networkprojects.com domain, server A MUST verify that server B is
one of the servers of the networkprojects.com domain. If so, it will
then accept other requests from server B that pertain to users of the
networkprojects.com domain.
Verification that a given server is responsible for a given domain is
done by performing a name resolution (as described in section 7.2).
Mazzoldi et al. [Page 50]
INTERNET DRAFT PRIM Specification March 2001
It is possible that due to DNS limitations, in the case of a domain
with a large number of servers, only partial DNS records are
advertised. Thus, the address of the server initiating the
connection may not be in the records received. In this case a
VERIFYSERVER method is performed to establish whether the initiating
server has authority over the corresponding domain. This is
described in Section 10.5.
13. Privacy Management
13.1. Presence Publication Control
When a USER AGENT publishes a PRESENCE TUPLE, it issues a PUBLISH
request to the server. It MUST contain a Class header which
specifies the class of WATCHERS that will receive that PRESENCE
TUPLE. The server retrieves the relevant WATCHERS from the Class
Table when it receives the PUBLISH request.
13.1.1. Class Table
Class Tables are stored at the server. They MAY be manipulated by
the USER AGENTS through the GETCLASSTABLE and SETCLASSTABLE commands,
and they MAY be manipulated out-of-band by other applications.
A SETCLASSTABLE request and GETCLASSTABLE response contain an XML
encoded Class Table in its body. The DTD of the Class Table is
defined as follows:
<!ELEMENT classtable (class)*>
<!ELEMENT class (watcher)*>
<!ATTLIST class name CDATA #REQUIRED>
<!ELEMENT watcher (#PCDATA)>
The matching of WATCHERS to entries in the Class Table goes from
It is assumed that there is the "default class" for all the WATCHERS
not explicitly specified in the Class Table.
13.1.2. Example
As an example, consider the following Class Table document for
bob@workdomain.com:
<classtable>
<class name="important_people">
<watcher>wife@example.com</watcher>
Mazzoldi et al. [Page 51]
INTERNET DRAFT PRIM Specification March 2001
<watcher>@workdomain.com</watcher>
</class>
<class name="not_so_important_people">
<watcher>friend@otherexample.com</watcher>
<watcher>uncle@otherdomain.com</watcher>
<watcher>slacker@workdomain.com</watcher>
</class>
</classtable>
Every publication of a PRESENCE TUPLE for "important_people" will
only be distributed to "wife@example.com" and all WATCHERS from
"workdomain.com" (except "slacker@workdomain.com").
Every publication of a PRESENCE TUPLE for "not_so_important_people"
will only be distributed to "friend@otherexample.com",
"uncle@otherdomain.com" and "slacker@workdomain.com".
Note that every publication of a PRESENCE TUPLE without specifying
Class header is handled as a publication to the default class and
will go to all WATCHERS that their identifier doesn't match any of
those in the Class Table.
13.2. Access Control
13.2.1. Overview
There are two kinds of protected resources: PRESENTITIES and INSTANT
INBOXES. Certain requests pertaining to those resources are subject
to access control and may only be invoked on behalf of a restricted
set of PRINCIPALS. Thus each protected resource has an access
control list. Access control lists MAY be manipulated by the USER
AGENTS through the GETACL and SETACL commands, and they MAY be
manipulated out-of-band by other applications.
In order to decide if a particular request for an INBOX or a
PRESENTITY is permitted, an access control list is used. Abstractly,
the decision depends on three parameters, the originator of the
request, the operation requested, and the parameters of the
operation. The originator of the request is identified in the "From"
field of a request. There are several operations that pertain to
PRESENTITY ACLs, some that pertain to INSTANT INBOX ACLs, and some
that pertain to both.
Access control decisions on behalf of the PRINCIPALS are made at
their home servers. The USER AGENT sets the access control list on
Mazzoldi et al. [Page 52]
INTERNET DRAFT PRIM Specification March 2001
the Presence and Instant Messaging servers.
More specific ACL entries are evaluated before less specific ones:
o If the ACL object has an entry with the requestor's
identifier as a key, the value of that entry is the list of
permitted operations.
o Next, if the ACL object has an entry with domain name of the
requestor's identifier, the value of that entry is the list of
permitted operations.
o Next, if there is an entry with the key ".", the value of that
entry is the list of permitted operations.
o Finally, no operations are permitted if there is no corresponding
key.
In representing an access control list as an ACL object, each key is
either a PRIM identifier, a Domain identifier (preceded by "@") or
"." for everybody. The value associated with a key is a set of
elements representing permitted operations.
Note that the Server may distinguish if each ACL object is
referencing a PRIM identifier, a domain or "everybody" by comparing
the first character with "@" and ".".
SUBSCRIBE, FETCH, PUBLISH and REMOVE give the target the right to
perform that operation to the ACL owner's PRESENCE INFORMATION.
SEND, LISTEN and SILENCE give the target the right to perform that
operation to the ACL owner's INSTANT INBOX.
13.2.2. PRESENTITY ACL
The ACL for a PRESENTITY conforms to the following DTD. This is used
by the GETACL and SETACL commands, described in Sections 10.6.1 and
10.6.2.
<!ELEMENT acl (entry)*>
<!ELEMENT entry (target, allow)>
<!ELEMENT target (address+)>
<!ELEMENT address (#PCDATA)>
<!ELEMENT allow (fetch | subscribe | publish | remove)*>
<!ELEMENT fetch EMPTY>
<!ELEMENT subscribe EMPTY>
Mazzoldi et al. [Page 53]
INTERNET DRAFT PRIM Specification March 2001
<!ELEMENT publish EMPTY>
<!ELEMENT remove EMPTY>
13.2.3. INSTANT INBOX ACL
The ACL for an INSTANT INBOX conforms to the following DTD. This is
used by the GETACL and SETACL commands, described in Section 10.6.1
and 10.6.2.
<!ELEMENT acl (entry)*>
<!ELEMENT entry (target, allow)>
<!ELEMENT target (address+)>
<!ELEMENT address (#PCDATA)>
<!ELEMENT allow (send | listen | silence)*>
<!ELEMENT send EMPTY>
<!ELEMENT listen EMPTY>
<!ELEMENT silence EMPTY>
13.2.4. Example
A sample access control list represented as an ACL object follows.
In this example:
o The user permits all operations from "secretary@mycompany.com".
Note that she can even PUBLISH my PRESENCE INFORMATION.
o Forbids all operations from any user at "badguys.com", except
"goodfriend@badguys.com" who is permitted to FETCH and SUBSCRIBE.
o Permits FETCH and SUBSCRIBE from all users from "@mycompany.com".
o Allows FETCH operations from all other users.
<acl>
<entry>
<target>
<address>secretary@mycompany.com</address>
</target>
<allow>
<fetch/>
<subscribe/>
<publish/>
<remove/>
</allow>
</entry>
Mazzoldi et al. [Page 54]
INTERNET DRAFT PRIM Specification March 2001
<entry>
<target>
<address>@mycompany.com</address>
<address>goodfriend@badguys.com</address>
</target>
<allow>
<fetch/>
<subscribe/>
</allow>
</entry>
<entry>
<target>
<address>@badguys.com</address>
</target>
<allow>
</allow>
</entry>
<entry>
<target>
<address>.</address>
</target>
<allow>
<fetch/>
</allow>
</entry>
</acl>
14. Presence Information Data Format (PIDF)
[Note: The content of this section is tentative. This section should
be rewritten in order to conform to CPIM when the presence format of
CPIM is defined.]
14.1. General Design
Presence information in PRIM is encoded as a MIME-encapsulated XML
object. XML is adopted for a base format because of its
expressiveness for structured data and its broad acceptance on the
Internet. MIME is used to wrap presence XML objects to suit with the
[RFC822] style command syntax of PRIM. MIME would also be preferable
when MIME based security mechanism (S/MIME or PGP/MIME) is needed for
end-to-end security.
Mazzoldi et al. [Page 55]
INTERNET DRAFT PRIM Specification March 2001
We have designed PIDF so that the XML part can be transfered end-to-
end without requiring any interpretation or modification of the
contents at the Home Servers and any relaying servers. Furthermore,
as we assume a case that different devices (e.g. PC, PDA, and cell
phone) can update parts of PRESENCE INFORMATION of a single
PRESENTITY, PIDF is designed so that the presence servers can handle
each part independently of others. This is important to solve the
race-condition induced by this use case.
The smallest unit of transporting PRESENCE INFORMATION is a PRESENCE
TUPLE. Thus, a tuple is a single XML document encapsulated by MIME.
The MIME type for a tuple is "application/presence". In a case that
multiple tuples are to be transferred in a single PRIM command, those
tuples are combined in a single MIME object by a MIME multipart
mechanim. The MIME type used for such a composite object is
"multipart/mixed".
14.2. Required Headers for PIDF
All PRIM commands transporting PIDF formatted presence documents MUST
have a Content-Type header, whose value is the MIME type of the
presence document.
A tuple, a MIME object whose MIME type is "application/presence",
MUST have a non-MIME-related header: tuple-id-header. The tuple-id-
header header is used to identify the TUPLE by the USER AGENTs and
the presence server storing the PRESENCE INFORMATION.
The Content-Transfer-Encoding header MUST NOT appear in any PRIM
commands. Other MIME related headers, such as Content-ID or Content-
Description, MAY be appear in a presence document, but they MUST NOT
affect the server behavior at all.
14.3. XML Format Definition
The XML part of a presence document MUST be a well-formed XML
document [XML]. The presence XML language is defined as a DTD in
section 15.7. However, clients and servers are not required to
validate the presence documents according to that DTD.
A presence document SHOULD NOT include any processor instructions or
CDATA sections. Client implementations MAY discard them silently.
This is because PRIM assumes the existence of resource-limited
terminals, that may have only a very simple parser.
Elements not defined in this document MAY appear in a presence
document. But, such elements do not have any particular meaning, and
SHOULD be silently discarded by clients.
Mazzoldi et al. [Page 56]
INTERNET DRAFT PRIM Specification March 2001
14.4. XML tags and attributes definitions
14.4.1. The <presence> element
The root element of the presence document is defined as <presence>.
This element contains one optional <presentity> element and zero or
more <contact> elements.
The root element has two attributes as defined below:
o address: this attributes indicates the unique identifier of the
PRESENTITY publishing this presence document.
o date: this attribute contains an indication of the date and time
when this presence document was published. The format for
expressing date and time is defined in 15.5.
14.4.2. The <presentity> element
The <presentity> element contains one <display-name> element, an
optional <note> element, and an optional <other-markup> element.
The intention of this element is to contain information not related
to any <contact> information but related to the PRESENTITY itself.
Examples for such information may include the user's mental state
(contained in <note>) or some profile of the user like vcard info
(maybe contained in <other-markup>).
14.4.3. The <contact> element
The <contact> element contains the PRESENCE INFORMATION related to
one PRESENCE TUPLE. It MUST contain <display-name> and <status>
elements, and MAY be followed by <preference>, <note> and <other-
markup> elements.
The <contact> element also MUST contain one "address" attribute, that
contains the URL form [RFC1738] of the communication address.
14.4.4. The <status> element
The <status> element has no children elements, but it has the "value"
attribute containing the status value. In order to simplify client
implementations, the same values will be used for all types of
contact addresses (IM, e-mail, phone, ...).
The value of the "value" attribute MUST be one of the following
strings:
Mazzoldi et al. [Page 57]
INTERNET DRAFT PRIM Specification March 2001
open
closed
"open" implies that the contact address is in normal working order
and messages will be read in a timely fashion. "closed" implies that
the contact address will temporarily not work.
The <status> element MAY have a optional attribute "details", which
describes the detailed information about status. Currently, the only
value specified for this attribute is "deferred", which implies that
a greater than normal delay will be experienced before the principal
receives communications sent to the contact address.
14.4.5. The <display-name> element
The <display-name> element contains a string for the purpose of the
display by the USER AGENT.
14.4.6. The <note> element
The <note> element of the presence document contains some comments
related to one PRESENTITY or address. This element SHOULD only
contain text, without any tags.
Note that, in future versions, the specification may support XML
namespaces, what would allow more advanced formatting of these notes
very easily (e.g. by including some XHTML markup)
The content of the note SHOULD be sufficiently small to be rendered
in several user interfaces, including a small GSM screen, a "tooltip"
on a PC screen and other space-limited situations.
14.4.7. The <preference> element
The <preference> element is an empty element which has only the
"value" attribute. The value of this attribute is an unsigned
integer, represented in decimal, specifying the preference of a
contact relative to the other contacts. Preference values MUST be
less than 2^32. A lower preference value indicates a more desirable
contact address. A contact without a preference value is less
desirable than any contact address with a preference value.
14.5. Date Format
As the format for expressing "date", PRIM adopts the syntax from
[RFC822] section 5 as amended by [RFC1123] section 5.2.14. Time
zones MUST be expressed numerically. For reference, the ABNF
Mazzoldi et al. [Page 58]
INTERNET DRAFT PRIM Specification March 2001
resulting from these references and restrictions is (note that ABNF
strings are case-insensitive, so ASCII case-folding MUST be performed
when matching day and month strings):
date-time = [day ","] date time
day = "Mon" / "Tue" / "Wed" / "Thu" / "Fri"
/ "Sat" / "Sun"
date = 1*2DIGIT month 4DIGIT
month = "Jan" / "Feb" / "Mar" / "Apr" / "May"
/ "Jun" / "Jul" / "Aug" / "Sep" / "Oct"
/ "Nov" / "Dec"
time = hour zone
hour = 2DIGIT ":" 2DIGIT [":" 2DIGIT]
zone = ("+" / "-") 4DIGIT ; hours+min (HHMM)
Example: date = "Thu, 30 Mar 2000 09:59:34 -0500"
14.6. Examples
The following example is a simple, but complete PRESENCE INFORMATION
record that could be sent from the Presence Service to a WATCHER,
including INSTANT MESSAGING and telephone addresses.
Content-Type: multipart/mixed; boundary="0123456789"
--0123456789
Content-Type: application/presence
Tuple-ID: im:foo@bar.com
<presence identifier="pres:foo@bar.com"
date="Thu, 5 Sep 2000 15:45:45 -0500">
<presentity>
<display-name>FOO (^^)v</display-name>
<note>I'm Hungry.</note>
</presentity>
<contact address="im:foo@bar.com">
<display-name>IM</display-name>
<status value="open"/>
<preference value="1"/>
</contact>
</presence>
--0123456789
Content-Type: application/presence
Tuple-ID: tel:+1-800-IGOTYOU
<presence identifier="pres:foo@bar.com"
Mazzoldi et al. [Page 59]
INTERNET DRAFT PRIM Specification March 2001
date="Thu, 5 Sep 2000 16:30:28 -0500">
<contact address="tel:+1-800-IGOTYOU">
<display-name>Phone(Office)</display-name>
<status value="open" detail="deferred"/>
</contact>
</presence>
--0123456789--
14.7. Presence Document DTD
<!ENTITY % URI "CDATA">
<!ENTITY % statuses "open|closed">
<!-- The entity "details" is defined as CDATA for
extensibility. But, the only distiuguished value
"deferred" has a meaning at present. -->
<!ENTITY % details "CDATA">
<!-- the presence tag is the top-level tag for presence. -->
<!ELEMENT presence (presentity?,contact)>
<!ATTLIST presence identifier %URI; #REQUIRED>
<!ATTLIST presence date CDATA #REQUIRED>
<!ELEMENT presentity (display-name, note?, other-markup?)>
<!ELEMENT display-name (#PCDATA)>
<!ELEMENT note (#PCDATA)>
<!ELEMENT other-markup (#PCDATA)>
<!-- the contact tag is for each tuple. -->
<!ELEMENT contact (display-name, status,
preference?, note?,
other-markup?)>
<!ATTLIST contact address %URI; #IMPLIED>
<!ELEMENT status EMPTY>
<!ATTLIST status value (%statuses;) #REQUIRED>
<!ATTLIST status detail %details; #IMPLIED>
<!ELEMENT preference EMPTY>
<!ATTLIST preference value CDATA #REQUIRED>
15. IM Format
Mazzoldi et al. [Page 60]
INTERNET DRAFT PRIM Specification March 2001
INSTANT MESSAGES are opaque payloads transferred by SEND commands
tagged by a MIME [MIME] content type.
A SEND command MUST contain a Content-Type header which specifies the
content type of the payload. It MAY contain any proper MIME header
which may not be defined here.
For the CPIM conformance, A USER AGENT MUST understand and generate
messages of the content type 'message/cpim'[CPIM-MSG]. In
particular, a USER AGENT MUST generate an INSTANT MESSAGE of the type
'message/cpim' if it sends the message to other domains which do not
or may not understand PRIM. The correspondence between the PRIM and
CPIM message format is described in Section 17.
The PRIM servers MUST forward the message as is when the message is
relayed to the clients or other servers. That is, the servers MUST
NOT delete or modify any header which appears in the command.
16. CPIM/PRIM Mapping
16.1. Presence Protocol
CPIM defines a slightly different subscription model as a common
protocol framework for the presence service. In CPIM, a "subscribe"
operation will invoke a response reporting only the result of the
operation and another immediate "notify" operation conveying the
PRESENCE INFORMATION, while the response of the SUBSCRIBE command in
PRIM contains the PRESENCE INFORMATION at the same time.
A CPIM gateway SHOULD be implemented to absorb this difference when
the "subscribe" operation is gatewayed.
[[Note: More investigation needed. Another choice would be to modify
the PRIM spec to align the CPIM framework.]]
When the CPIM presence format is finished, the mapping between the
elements of PRIM presence format and those of CPIM will be described.
16.2. Instant Messaging Protocol
The CPIM message format document [CPIM-MSG] defines the common format
for INSTANT MESSAGES for the sake of interoperability and the
capability to achieve end-to-end security.
A gateway to other domains which does not or may not understand PRIM
MUST send INSTANT MESSAGES in the CPIM message format of the content
type 'message/cpim'. The gateway MUST convert the SEND request to
Mazzoldi et al. [Page 61]
INTERNET DRAFT PRIM Specification March 2001
the corresponding request to the "message" operation [CPIM] of the
protocol on the other side. The incoming response MUST be converted
to the corresponding PRIM response message. [Details will be
described in the next revision. ]
If a USER AGENT send a signed or encrypted INSTANT MESSAGES, it MUST
compose them in the CPIM message format.
For mapping the PRIM command format to the CPIM message format, the
following rules SHOULD be applied. [Note: Obviously, more
investigation is needed.]
o To, From, and Date headers in a PRIM command are copied to the
message header part in the CPIM message. [Reply-to, too?]
o Message-ID and Conversation-ID headers in a PRIM command is
converted using the CPIM namespace mechanism and moved to the
message header part in the CPIM message as follows;
NS: PRIM <http://www.fujitsulabs.com/prim/>
PRIM.Message-ID: [[a unique id for this message]]
PRIM.Conversation-ID: [[a unique id for this conversation]]
o Content-type header in a PRIM command are moved to the content
header part in the CPIM message.
17. Security Considerations
There exists many kind of security threats in the Presence / Instant
Messaging services and applications as described in the IMPP
Requirements [RFC 1778] and the CPIM document [CPIM].
PRIM specifies mechanisms to achieve connection security and to
realize access control including presence publication control.
The future PRIM specifications will conform to the expected CPIM data
formats for secure and interoperable Presence information and IM
exchanges [CPIM,CPIM-MSG]. It will acquire the message level
security such as end-to-end confidentiality and integrity.
18. Appendix A: Response Codes
The policy for assigning response codes follows the convention used
in HTTP/1.1 [HTTP1.1].
Mazzoldi et al. [Page 62]
INTERNET DRAFT PRIM Specification March 2001
o 1xx: Informational - Request received, continuing process
o 2xx: Success - The action was successfully received, understood,
and accepted
o 3xx: Redirection - Further action must be taken in order to
complete the request
o 4xx: Request Error - The request contains bad syntax or cannot be
fulfilled
o 5xx: Server Error - The server failed to fulfill an apparently
valid request
100 Authentication Continued
The request for authentication has been accepted and the
authentication process is continued.
101 Unknown Delivery Status
The server was unable to determine that the message was
successfully delivered to an INSTANT INBOX or that the transmission
failed. This could be because the message was delivered on a best-
effort basis, or it was delivered to an "offline" message store.
200 OK
Everything is dandy!
201 Duration Adjusted
The SUBSRIPTION was placed successfully, yet its duration was not
acceptable to the server. A new duration was set and this was
indicated in the duration-header of the response.
300 Redirect
The server was unable to deal with the request and instructs the
caller to reconnect to a different server and reissue the operation
there.
400 Bad Request
The request could not be understood by the server due to malformed
syntax of the headers or malformed content. The client SHOULD NOT
repeat the request without modifications.
Mazzoldi et al. [Page 63]
INTERNET DRAFT PRIM Specification March 2001
401 Unauthorized
The request requires user authentication. The client MUST
authenticate itself through the LOGIN request.
402 Forbidden
The server understood the request, but it has not been authorized.
403 Resource Not Found
The specified resource was not found at the server.
404 Subscription Not Found
The SUBSCRIPTION specified in the Subscription-ID header was not
found at the resource. This status code MAY appear in the response
to the UNSUBSCRIBE and CANCELSUBSCRIPTION requests, and the
SUBSCRIBE request in "renew" mode.
406 Authentication Failed
The authentication process has failed. The reason for it is one of
the following:
o The authentication process using the specified SASL-Mechanism
failed.
o The LOGIN request specifies an inappropriate SASL Mechanism.
o In the midst of the authentication process, the client tries to
start another authentication process by specifying 'Auth-State:
init'.
407 Timeout
The server timed-out after waiting for a response from another
client or server.
408 Inbox Is Closed
The INSTANT INBOX is not currently accepting messages.
409 Already Authenticated
The connection was authenticated previously through a LOGIN
command.
Mazzoldi et al. [Page 64]
INTERNET DRAFT PRIM Specification March 2001
410 Astrength Too Weak
The command was rejected because the server requires a higher level
of security and this could not be provided.
500 Internal Server Error
The request has not been fulfilled because of the error internal to
the server.
501 Not Implemented
The server does not support the functionality required to fulfill
the request.
503 Version Not Supported
The server or client does not support the specified protocol
version used for the request.
505 Too Many Subscriptions
The SUBSCRIBE request has not been fulfilled because the request
exceeds the specified maximum number of SUBSCRIPTIONS at the
resource. When this status code is received, the client SHOULD NOT
retry the SUBSCRIPTION immediately.
19. References
[CPIM] D. Crocker et al., "A Common Profile for Instant Messaging
(CPIM)", draft-ietf-impp-cpim-01.txt, Work in Progress.
[CPIM-MSG] D. Atkins and G. Klyne, "Common Presence and Instant
Messaging Message Format", draft-ietf-impp-cpim-msgfmt-00.txt,
Work in Progress.
[CRAM-MD5] J.Klensin, R.Catoe and P. Krumviede, "IMAP/POP AUTHorize
Extension for Simple Challenge/Response", RFC 2195, September 997.
[HTTP1.1] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter,
P. Leach, and T. Berners-Lee, "Hypertext Transfer Protocol --
HTTP/1.1", RFC 2616, June 1999
[MIME] Multipurpose Internet Mail Extensions. See RFC 822, RFC 2045,
RFC 2046, RFC 2047, RFC 2048, and RFC 2049.
[OpenPGP] J. Callas, etc., "OpenPGP Message Format", RFC2440,
Mazzoldi et al. [Page 65]
INTERNET DRAFT PRIM Specification March 2001
November 1998.
[RFC822] Crocker, D., "Standard for the format of ARPA Internet text
messages", RFC 822, STD 11, Aug 1982.
[RFC1123] R. Braden, "Requirements for Internet Hosts -- Application
and Support", RFC 1123, October 1989
[RFC1738] T. Berners-Lee, L. Masinter, M. McCahill, "Uniform Resource
Locators", RFC 1738, December 1994.
[RFC2778] M. Day, J. Rosenberg, H. Sugano, "A Model for Presence and
Instant Messaging", RFC 2778, February 2000.
[RFC2779] M.Day, S.Aggarwal, G.Mohr, and J.Vincent, "Instant
Messaging / Presence Protocol Requirements", RFC 2779, February 2000.
[SASL] J. Myers, "Simple Authentication and Security Layer (SASL)",
RFC2222, October 1997.
[SASL-PLAIN] C. Newman, "Using TLS with IMAP, POP3 and ACAP",
RFC2595, June 1999.
[SMIME] P. Hoffman, Ed, "S/MIME Version 3 Message Specification",
RFC2633, June 1999.
[TLS] T.Dierks, and C. Allen, "The TLS Protocol Version 1.0",
RFC2246, January 1999.
[URI] T. Berners-Lee, R. Fielding, L. Masinter, "Uniform Resource
Identifiers (URI): Generic Syntax", RFC2396, August 1998.
[XML] Extensible Mark Up Language. A W3C recommendation. See
http://www.w3.org/TR/1998/REC-xml-19980210 for the 10 February 1998
version.
20. Acknowledgements
The authors greatly appreciate helpful comments from John Stracke and
Harald Alvestrand.
This document is based upon several Internet Drafts submitted to the
IMPP-WG:
IMTP/PITP: G. Hudson, MIT
OneIM: A. Diacakis, F. Mazzoldi, Network Projects, Inc.
PePP: H. Sugano et al, Fujitsu
Mazzoldi et al. [Page 66]
INTERNET DRAFT PRIM Specification March 2001
SIMP: J. Ramsdell, MITRE Corporation
21. Author's Addresses
F. Mazzoldi
flo@personity.com
Personity, Inc.
4516 Henry Street, Suite 113
Pittsburgh PA 15213
USA
A. Diacakis
thanos@personity.com
Personity, Inc.
4516 Henry Street, Suite 113
Pittsburgh, PA 15213
USA
S. Fujimoto
shingo@flab.fujitsu.co.jp
Fujitsu Laboratories Ltd.
64, Nishiwaki
Ohkubo-cho
Akashi 674
Japan
G. Hudson
ghudson@mit.edu
Massachusetts Institue of Technology
Cambridge, MA 02139
USA
J. D. Ramsdell
ramsdell@mitre.org
The MITRE Corporation
202 Burlington Road
Bedford, MA 01730-1420
USA
H. Sugano
suga@flab.fujitsu.co.jp
Fujitsu Laboratories Ltd.
64, Nishiwaki
Ohkubo-cho
Akashi 674
Japan
Mazzoldi et al. [Page 67]
INTERNET DRAFT PRIM Specification March 2001
22. Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
Acknowledgement
Funding for the RFC editor function is currently provided by the
Internet Society.
Mazzoldi et al. [Page 68]