idnits 2.17.1 draft-ietf-prim-server-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 6 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** The abstract seems to contain references ([RFC2779]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 6 instances of lines with non-RFC2606-compliant FQDNs in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? RFC 2119 keyword, line 275: '...IBER, or else it MUST be removed by th...' RFC 2119 keyword, line 350: '...ed in this definition MUST be escaped....' RFC 2119 keyword, line 356: '... Internationalized Domain Name [IDN]. A string for "domain" MUST be a...' RFC 2119 keyword, line 364: '... PRIM USER AGENT SHOULD recognize a PR...' RFC 2119 keyword, line 366: '...milarly, a USER AGENT SHOULD display a...' (88 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 937 has weird spacing: '...-header sub...' == Line 1121 has weird spacing: '...-header con...' == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: 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 unless the servers already have knowledge about the relaying server's authentication strength through some out-of-band manner. If the servers acknowledge the authentication strength of the other end, the AStrength header MAY NOT appear in the relayed request. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: The connection end-points MAY use a LOGIN command for the authentication. But, if two end-points have authenticated each other with an out-of-band method (e.g. TLS) or they have enough knowledge about the other end-point for their purpose (e.g. IP address), it MAY NOT use such a particular command. If the connection uses TLS, then the domains served by each end-point are established in the beginning, through the certificates provided. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 2001) is 8223 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '34' on line 214 == Missing Reference: 'CPIM-PIDF' is mentioned on line 1620, but not defined == Missing Reference: 'RFC 2234' is mentioned on line 313, but not defined ** Obsolete undefined reference: RFC 2234 (Obsoleted by RFC 4234) == Missing Reference: 'RFC2396' is mentioned on line 349, but not defined ** Obsolete undefined reference: RFC 2396 (Obsoleted by RFC 3986) == Missing Reference: 'RFC 2368' is mentioned on line 351, but not defined ** Obsolete undefined reference: RFC 2368 (Obsoleted by RFC 6068) == Missing Reference: 'IDN' is mentioned on line 356, but not defined == Missing Reference: 'RFC 2782' is mentioned on line 427, but not defined == Missing Reference: 'CPIM-MSGFMT' is mentioned on line 1068, but not defined == Missing Reference: 'RFC2145' is mentioned on line 592, but not defined ** Obsolete undefined reference: RFC 2145 (Obsoleted by RFC 7230) == Missing Reference: 'RFC 2289' is mentioned on line 797, but not defined == Missing Reference: 'RFC 2045' is mentioned on line 863, but not defined == Missing Reference: 'Example' is mentioned on line 1600, but not defined == Missing Reference: 'KEYED-MD5' is mentioned on line 1578, but not defined == Missing Reference: 'RFC 1778' is mentioned on line 1651, but not defined ** Obsolete undefined reference: RFC 1778 (Obsoleted by RFC 3494) == Unused Reference: 'OpenPGP' is defined on line 1680, but no explicit reference was found in the text == Unused Reference: 'RFC1738' is defined on line 1689, but no explicit reference was found in the text == Unused Reference: 'SMIME' is defined on line 1704, but no explicit reference was found in the text == Unused Reference: 'URI' is defined on line 1710, but no explicit reference was found in the text == Unused Reference: 'XML' is defined on line 1713, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-ietf-impp-cpim-01 -- Possible downref: Normative reference to a draft: ref. 'CPIM' == Outdated reference: A later version (-08) exists of draft-ietf-impp-cpim-msgfmt-00 ** Obsolete normative reference: RFC 2440 (ref. 'OpenPGP') (Obsoleted by RFC 4880) ** Obsolete normative reference: RFC 822 (Obsoleted by RFC 2822) ** Obsolete normative reference: RFC 1738 (Obsoleted by RFC 4248, RFC 4266) ** Downref: Normative reference to an Informational RFC: RFC 2778 ** Downref: Normative reference to an Informational RFC: RFC 2779 ** Obsolete normative reference: RFC 2222 (ref. 'SASL') (Obsoleted by RFC 4422, RFC 4752) ** Obsolete normative reference: RFC 2633 (ref. 'SMIME') (Obsoleted by RFC 3851) ** Obsolete normative reference: RFC 2246 (ref. 'TLS') (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 2396 (ref. 'URI') (Obsoleted by RFC 3986) -- Possible downref: Non-RFC (?) normative reference: ref. 'XML' Summary: 21 errors (**), 0 flaws (~~), 27 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT H. Sugano 3 S. Fujimoto 4 Fujitsu 6 F. Mazzoldi 7 A. Diacakis 8 Personity, Inc. 10 G. Hudson 11 MIT 13 J. D. Ramsdell 14 The MITRE Corporation 16 Expires: April 2002 October 2001 18 Presence and Instant Messaging Protocol (PRIM) 19 Server-Server Protocol Specification 20 22 Status of this Memo 24 This document is an Internet-Draft and is in full conformance with 25 all provisions of Section 10 of RFC2026. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet- Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html. 43 Please send comments to the authors or to the prim@ml.fujitsulabs.com 44 discussion list. 46 Copyright Notice 48 Copyright (C) The Internet Society (2001). All Rights Reserved. 50 Abstract 52 The architecture and specifications of the Presence and Instant 53 Messaging protocols (PRIM) are described. PRIM defines a set of 54 protocols for the Presence and Instant Messaging services which 55 satisfy the IMPP requirements [RFC2779]. PRIM is also designed so as 56 to conform with the Common Profile for Instant Messaging (CPIM) 57 specification being developed in the IMPP WG. This memo describes 58 the PRIM Server-Server protocol specification. 60 Table of Contents 62 1. Introduction ......................................... 5 63 1.1. Design Principles .................................... 5 64 1.2. Terminology .......................................... 6 65 2. Architecture ......................................... 6 66 2.1. Overall Architecture ................................. 6 67 2.2. Presence Model ....................................... 7 68 2.2.1. Presence Servers ..................................... 7 69 2.2.2. Presence Subscriptions ............................... 7 70 2.2.3. PRESENCE INFORMATION ................................. 8 71 2.3. Instant Messaging Model .............................. 8 72 3. Identifier Namespace ................................. 8 73 4. Establishing Connections ............................. 10 74 4.1. Server-server Connections ............................ 10 75 4.2. Connections and Services ............................. 10 76 4.3. Name Resolution ...................................... 11 77 4.4. Shared Connections ................................... 11 78 5. Command Structure .................................... 12 79 5.1. Generic Commands ..................................... 12 80 5.1.1. Command Headers ...................................... 12 81 5.1.2. Command Body ......................................... 13 82 5.2. Requests ............................................. 13 83 5.2.1. Method ............................................... 14 84 5.2.2. Version .............................................. 14 85 5.2.3. Request Identifier ................................... 15 86 5.2.4. Content Length ....................................... 15 87 5.3. Responses ............................................ 15 88 6. Command Headers ...................................... 16 89 6.1. General Headers ...................................... 16 90 6.1.1. From ................................................. 16 91 6.1.2. To ................................................... 17 92 6.1.3. Domain ............................................... 17 93 6.1.4. Auth-State ........................................... 17 94 6.1.5. SASL-Mechanism ....................................... 17 95 6.1.6. Redirect ............................................. 18 96 6.1.7. Server-Address ....................................... 18 97 6.1.8. AStrength ............................................ 18 98 6.1.9. Date ................................................. 20 99 6.2. Entity Headers ....................................... 20 100 6.2.1. Content-Type ......................................... 20 101 6.3. Presence Headers ..................................... 20 102 6.3.1. Duration ............................................. 20 103 6.3.2. Subscription-ID ...................................... 20 104 6.4. IM Headers ........................................... 21 105 6.4.1. Message-ID ........................................... 21 106 6.4.2. Conversation-ID ...................................... 21 107 6.4.3. Reply-To ............................................. 21 108 7. Command Specifications ............................... 21 109 7.1. Presence Service Commands ............................ 21 110 7.1.1. SUBSCRIBE - Placement and renewal of SUBSCRIPTION .... 22 111 7.1.2. UNSUBSCRIBE - Removal of SUBSCRIPTION ................ 23 112 7.1.3. NOTIFY - Propagation of PRESENCE INFORMATION ......... 24 113 7.2. Instant Messaging Service Commands ................... 25 114 7.2.1. SEND - Sending Messages .............................. 25 115 7.3. General Commands ..................................... 27 116 7.3.1. LOGIN - Connection Setup ............................. 27 117 7.3.2. STARTTLS - Secuire Connection Setup .................. 28 118 7.3.3. LOGOUT - Connection Shutdown ......................... 29 119 7.3.4. PING - Testing a connectionG ......................... 29 120 7.3.5. VERIFYSERVER - Verifying a server's authority ........ 29 121 8. Response Codes ....................................... 30 122 9. Authentication ....................................... 33 123 9.1. Server-Server Authentication ......................... 33 124 9.2. Authentication Using LOGIN ........................... 34 125 10. Presence Information Data Format (PIDF) ............. 36 126 11. IM Format ........................................... 36 127 12. Security Considerations ............................. 37 128 13. References .......................................... 37 129 14. Acknowledgements .................................... 38 130 15. Author's Addresses .................................. 38 131 16. Full Copyright Statement ............................ 39 133 1. Introduction 135 Instant Messaging and Presence (IM/P) services provide users a way to 136 know others are available to communicate with them primarily by 137 exchanging short text messages and possibly by other communications 138 media such as voice and/or video. The PRIM, PResence and Instant 139 Messaging, protocols are designed for such services so that these 140 services can be provided by a set of servers distributed across a 141 large number of administrative domains. 143 PRIM specifications are classified into two parts; a client-server 144 protocol specification and a server-server protocol specification. 145 The former is the protocol for clients of the PRIM IM/P services to 146 communicate with the IM/P servers exchanging PRESENCE INFORMATION and 147 INSTANT MESSAGES, and it is mainly used within a single 148 administrative domain. On the other hand, the latter is the protocol 149 for the IM/P servers to communicate with other servers possibly in 150 the different domains. This separation is meaningful because of the 151 simplified architecture of PRIM described below. 153 This memo gives the PRIM server-server protocol specification. This 154 serves as a protocol not only for communications between the PRIM 155 servers, but also for communications between different domains that 156 may internally use other protocols than PRIM. This is accomplished by 157 gatewaying the internal protocol to the PRIM protocol. The 158 specification of the PRIM client-server protocol is presented in a 159 separate document. 161 The PRIM specifications are developed on the basis of the IMPP 162 activities such as the Model and Requirements documents for the IM/P 163 services [RFC2778,RFC2779]. PRIM is also designed to conform to the 164 Common Profile for Instant Messaging (CPIM) specifications being 165 developed by the IMPP WG. This enables that users of PRIM services 166 exchange PRESENCE INFORMATION and INSTANT MESSAGES with the users of 167 the services which use other CPIM compatible protocols. 169 1.1. Design Principles 171 Some of the design principles on which the PRIM specifications are 172 based are as follows. Note that the latter two are only relevant to 173 the PRIM client-server protocol. 175 o Transfer protocol directly atop of TCP 177 PRIM assumes TCP as the basic transport mechanism for INSTANT 178 MESSAGES and PRESENCE INFORMATION. TCP provides a sufficiently 179 reliable transport infrastructure which is required by both INSTANT 180 MESSAGING and PRESENCE SERVICES. 182 o Long-lived Client/Server connections 184 PRIM uses long-lived client/server TCP connections in order to 185 receive INSTANT MESSAGES and PRESENCE INFORMATION NOTIFICATIONS. 186 Note that this is the prevailing model used by most Presence and IM 187 systems today. It brings the following advantages: 189 - Overhead is reduced, because authentication is performed once, at 190 the beginning of the connection. This is important, for example, 191 when PRESENCE INFORMATION NOTIFICATIONS occur frequently. 193 - Connections are firewall friendly, because USER AGENTS initiate 194 connections from inside a firewall that can carry NOTIFICATIONS or 195 messages initiated from the outside. 197 o Selective Presence Publication 199 [RFC2779] stipulates various requirements for access control; 2.3.x 200 and several in section 5. Among others, we consider the feature of 201 "Polite Blocking" (5.1.15, 5.2.3) to be very important for PRESENCE 202 SERVICES. This protocol contains a mechanism for such selective 203 PRESENCE INFORMATION publication as well as in-band access control. 205 1.2. Terminology 207 [RFC2778] and [RFC2779] define the terminology for the PRESENCE and 208 INSTANT MESSAGING fields. Please refer to those documents for a 209 complete glossary of the UPPER CASED terms. 211 The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", 212 "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be 213 interpreted as described in RFC 2119 [34]. 215 2. Architecture 217 This section describes an overall PRIM architecture for both client- 218 server and server-server protocols. 220 2.1. Overall Architecture 222 The PRIM architecture involves two components: Service Domains and 223 USER AGENTS. A Service Domain in the context of PRIM is an 224 administrative entity where a PRINCIPAL has its identifier as an 225 entity such as PRESENTITY/WATCHER and SENDER/INBOX to enjoy the 226 PRESENCE and INSTANT MESSAGING SERVICES. A PRINCIPAL's Service 227 Domain is called its Home Domain, and the PRINCIPAL connects to its 228 Home Domain via a USER AGENT to access PRESENCE and INSTANT MESSAGING 229 SERVICES. 231 A Service Domain consists of PRESENCE and/or INSTANT MESSAGING 232 SERVERS together with USER AGENTS. A USER AGENT only communicates 233 with the SERVERS in its HOME DOMAIN, and the PRIM client-server 234 protocol is used by the USER AGENT and SERVERS. A SERVER can 235 communicate with other SERVERS using the PRIM server-server protocol 236 specified in this memo. The protocol commands transferred by this 237 protocol are those either initiated by the SERVER itself or relayed 238 on behalf of USER AGENTS. These SERVERS may be located in different 239 Service Domains. 241 The PRIM protocols are both connection-based, i.e. every protocol 242 commands are transferred through a TCP connection. A USER AGENT 243 communicating with a SERVER exchanges the protocol commands through a 244 client-server connection established between the SERVER and the USER 245 AGENT. Similarly, a SERVER communicating with another SERVER 246 exchanges the protocol commands using a server-server connection 247 between the two SERVERS. 249 2.2. Presence Model 251 2.2.1. Presence Servers 253 Presence servers are primary components of PRESENCE SERVICE. A 254 presence server in a Service Domain stores and manages PRESENCE 255 INFORMATION published by PRESENTITIES in that domain and 256 SUBSCRIPTIONS from SUBSCRIBERS to the PRESENTITIES. The SUBSCRIBERS 257 may be located in the same domain and may subscribe from different 258 domains. If a presence server receives a request for a PRESENTITY in 259 a different domain, it forwards the request to the target domain 260 using an inter-domain server-server connection. 262 When a part of PRESENCE INFORMATION of a PRESENTITY is changed, 263 NOTIFICATION messages for relevant SUBSCRIBERS to that particular 264 PRESENTITY will be issued by the presence server. 266 2.2.2. Presence Subscriptions 268 WATCHERS can subscribe to a PRESENTITY in order to receive 269 NOTIFICATIONS when the PRESENCE INFORMATION of that PRESENTITY 270 changes. 272 SUBSCRIPTIONS have a duration under which they are in effect. This 273 duration is specified at the time that the subscription is placed or 274 renewed. Once that period elapses, the SUBSCRIPTION has to be either 275 renewed by the SUBSCRIBER, or else it MUST be removed by the 276 PRESENTITY's Presence Server. 278 This renewal may be either issued by the USER AGENT, or by the 279 SUBSCRIBER's Presence Server on behalf of the SUBSCRIBER. 281 2.2.3. PRESENCE INFORMATION 283 PRESENCE INFORMATION transported by the PRIM protocol consists of one 284 or more PRESENCE TUPLEs, as defined by the IMPP model document 285 [RFC2778]. PRIM adopts the CPIM Presence Information Data Format 286 [CPIM-PIDF] as its presence data format. 288 2.3. Instant Messaging Model 290 INSTANT MESSAGING SERVICE provides a functionality of sending and 291 receiving INSTANT MESSAGES for PRINCIPALS. USER AGENTS are able to 292 exchange INSTANT MESSAGES with a client-server connection to the 293 INSTANT MESSAGING SERVERS. An INSTANT MESSAGING SERVER provides an 294 INSTANT INBOX for receiving Instant Messages. 296 When a USER AGENT wishes to start receiving INSTANT MESSAGES, it 297 starts listening to that INSTANT INBOX. Conversely, when it no 298 longer wishes to receive INSTANT MESSAGES from that INSTANT INBOX, it 299 stops listening to the INBOX. 301 INSTANT INBOXes have two states, as described in RFC 2779: OPEN and 302 CLOSED. An INBOX is OPEN when at least one PRINCIPAL is listening to 303 that INBOX. It is CLOSED when there are no PRINCIPALS listening to 304 the INBOX. 306 If an INSTANT MESSAGE is sent to an INBOX that has multiple 307 PRINCIPALS listening, the message is considered to be delivered 308 successfully if at least one PRINCIPAL receives it. 310 3. Identifier Namespace 312 This section defines the syntax of identifiers which appear as the 313 protocol elements. The ABNF [RFC 2234] is used for the syntax 314 definitions. 316 The next ABNF defines a Presence or IM identifiers, which are used to 317 identify PRESENTITIES and INSTANT INBOXes respectively. It also 318 defines IP address formats to be referred in some header definitions. 320 presence-id = word-pres ":" local-part "@" domain 321 im-id = word-im ":" local-part "@" domain 322 local-part = 1*( unreserved / escaped ) 323 unreserved = ALPHA / DIGIT / "!" / "$" / "&" / "'" / "*" 324 / "." / "+" / "-" / "/" / "=" / "?" / "_" / "~" 325 escaped = "%" hex-char hex-char 326 hex-char = DIGIT / "A" / "B" / "C" / "D" / "E" / "F" 327 / "a" / "b" / "c" / "d" / "e" / "f" 328 domain = 1*domain-label *("." 1*domain-label) 329 domain-label = 1*( unreserved / escaped ) 330 word-pres = %x70.72.65.73 ; "pres" 331 word-im = %x69.6D ; "im" 332 decimal-byte = 1*3DIGIT 333 ALPHA = 334 DIGIT = 336 hex4 = 1*4hex-char 337 hexseq = hex4 *(":" hex4) 338 ip6-address = hexseq / hexseq "::" [ hexseq ] / "::" [ hexseq ] 339 ip4-address = "::" 1*1decimal-byte 3*3("." 1*1decimal-byte) 341 The PRIM Presence and IM identifiers are defined so as to align with 342 CPIM [CPIM]. They have the form of URI [RFC2396] and the same URI 343 schemes are selected for Presence identifiers ("pres:") and IM 344 identifiers ("im:"). 346 The syntax for the "local-part" and "domain" of those identifiers are 347 similar to that for email addresses, specified as addr-spec in 348 [RFC822]. But, the characters defined in this specification is 349 restricted so as to conform to the URI syntax [RFC2396]. The 350 characters which are not allowed in this definition MUST be escaped. 351 Also note that, unlike a mailto: URL [RFC 2368], a pres: or im: URL 352 cannot contain multiple addresses. 354 Moreover, The syntax for "domain-label" here is so defined that it 355 will be conformant to the prospective specification of the 356 Internationalized Domain Name [IDN]. A string for "domain" MUST be a 357 valid domain name according to the rules currently in existence. 359 Followings are some examples of valid Presence and IM identifiers: 361 pres:joe@example.net 362 im:%22Jane%20Smith%22@domain.com 364 A PRIM USER AGENT SHOULD recognize a PRESENTITY or INSTANT INBOX 365 identifier without the scheme if it is entered in a PRESENCE or 366 INSTANT MESSAGING context. Similarly, a USER AGENT SHOULD display a 367 PRESENCE or INSTANT MESSAGING identifier without the scheme if it is 368 displayed in a PRESENCE or INSTANT MESSAGING context. 370 A PRINCIPAL may or may not have the same IDENTIFIER for its 371 PRESENTITY and its IM INBOX. However, for an integrated Presence and 372 IM service, the service SHOULD NOT assign the IDENTIFIERS which are 373 different only in the scheme part to different PRINCIPALS. 375 4. Establishing Connections 377 4.1. Server-server Connections 379 A Presence or Instant Messaging Server send a command to another 380 server through a server-server connection. The command may be the one 381 issued by the server itself or the one issued originally by a USER 382 AGENT and forwarded. It can reuse an existing connection to the 383 destination server if already exists. If there is no connection to 384 the destination, the originating server tries to establish a new 385 connection. To do that, it will resolve the name of the recipient of 386 the command to locate the destination server. 388 When a server establishes a connection to another server, that 389 connection end-point can be authorized to communicate on behalf of 390 multiple PRESENTITIES or INBOXES. For example, if server A receives a 391 subscription request from server B, on behalf of user 392 thanos@personity.com, server A MUST verify that server B is one of 393 the servers of the personity.com domain. If so, it will then accept 394 other requests from server B that pertain to users of the 395 personity.com domain. 397 PRIM provides several methods to authenticate and authorize servers, 398 which are described in section 1x.x. 400 The connection may be closed by either side at any time when there 401 are no outstanding commands on the connection from that server's 402 point of view. A server which has received a command may close the 403 connection if it encounters a serious error during the processing of 404 the command. In this case, the server SHOULD respond with "400 Bad 405 Request" error if possible before closing the connection. Any 406 commands sent to a server which closed the connection before sending 407 a reply can safely be assumed to have gone unprocessed. 409 4.2. Connections and Services 411 PRIM specifications allow the separation of PRESENCE SERVICE and 412 INSTANT MESSAGING SERVICE, i.e. the specifications allow a server 413 only providing one of those services. A server (and a USER AGENT as 414 well) may establish two distinct connections for the two services 415 even though they are provided by the same domain. Of course, a server 416 which serves only one of these services may establish only one 417 connection for that service to a single domain. 419 4.3. Name Resolution 421 For the server location, PRIM reuses the existing Domain Name 422 Services to achieve this. The domain name resolution is performed 423 with the domain name of the destination address of the PRIM command 424 to be transported. 426 A server MUST discover a remote domain's server using the following 427 algorithm: the server performs a SRV [RFC 2782] lookup for the remote 428 domain using the protocol "tcp" and the service "prim-pr" (for 429 PRESENCE) or "prim-im" (for INSTANT MESSAGING). If the two SRV 430 lookups for the "prim-pr" and "prim-im" services in a domain return 431 the same host and port number, the server MAY establish a single 432 connection to that host/port to enjoy the two services. 434 If no SRV record is present, the server performs an A lookup on the 435 remote domain and uses the resulting IP addresses with the allocated 436 port [xxx] for PRESENCE or [xxx] for INSTANT MESSAGING. 438 Note: The protocol is capable of using two different TCP ports: one 439 for the PRESENCE SERVICE and one for the INSTANT MESSAGING SERVICE. 440 However, the usage of one or two ports will be possible for different 441 needs. The protocol ensures there is no ambiguity between commands 442 received from different services. 444 4.4. Shared Connections 446 When a domain provides both the PRESENCE and INSTANT MESSAGING 447 SERVICES in a single host and port, it has been declared using the 448 DNS SRV RR as stated in the previous section. In that case, the 449 initiating server MAY open a single connection and authenticate 450 itself once on that connection using one of available authentication 451 methods. 453 The server can differentiate between the presence and instant 454 messaging service commands by the command name itself. The "general" 455 commands such as LOGIN, STARTTLS, or PING do not care which services 456 they are used for in a shared connection. If the STARTTLS command is 457 needed for the connection, one STARTTLS command is sufficient. 459 If a server received a command for the service it does not provide 460 for some unexpected reason, the server MUST respond with '501 Not 461 Implemented' error. 463 5. Command Structure 465 This section describes the structure of generic PRIM commands and 466 also gives a classification of PRIM requests based on the connections 467 on which they are transported. The details of the requests 468 specifications are described separately in the later sections. 470 5.1. Generic Commands 472 A connection transports a sequence of commands. The underlying 473 character set for commands is Unicode, represented in UTF-8 [RFC 474 2279]. Command bodies are an exception; they should be treated as 475 unprocessed octets. An implementation MUST properly handle arbitrary 476 binary data in the body. A command is either a request or a 477 response. 479 PRIM-command = request / response 481 Requests and responses use the generic command format of [RFC822] for 482 transferring entities (the body of the command). Both types of 483 command consist of a start-line, one or more command-header fields 484 (also known as "headers"), an empty line (i.e., a line with nothing 485 preceding the CRLF) indicating the end of the header fields, and an 486 optional command-body. 488 generic-command = start-line 489 *command-header 490 CRLF 491 [ command-body ] 493 start-line = request-line / response-line 495 Receivers of commands SHOULD ignore any empty line(s) received where 496 a start-line is expected. 498 5.1.1. Command Headers 500 PRIM command-header fields follow the same syntactic restriction as 501 specified by [CPIM-MSGFMT]. Thus, each header field consists of a 502 header name followed by a colon ("%x3A"), a single whitespace 503 ("%x20") and a field value. Header names are case-sensitive. The 504 entire header MUST be contained in a single line. 506 Command header fields are categorized into four types; general- 507 header, presence-header, im-header, and entity-header. General- 508 header fields are applicable to both of PRIM Presence and Instant 509 Messaging Protocols, and used for controlling the basic behavior of 510 the PRIM applications, such as connection management and delivery of 511 the commands. Presence-header fields and im-header fields are 512 included as a meta-data of the content of the commands of the 513 Presence and Instant Messaging Protocols respectively. Entity-header 514 fields describes the common feature of the body of the command. 516 command-header = (general-header ; 517 / presence-header ; 518 / im-header ; 519 / entity-header ; 520 ) 522 5.1.2. Command Body 524 Some commands of the PRIM Presence and Instant Messaging Protocols 525 can contain a command-body. The command-body is used to carry 526 presence information, instant message, or other information. 528 5.2. Requests 530 A generic PRIM request includes the method to be applied to the 531 resource, the protocol version, and the data needed for asynchronous 532 requests. 534 request-line = method 535 SP version 536 SP request-identifier 537 SP content-length 538 CRLF 540 As PRIM specifies two kinds of protocols for Presence and Instant 541 Messaging Services, a PRIM request is classified into two categories. 543 request = (presence-request / im-request) 545 presence-request = request-line 546 *((general-header 547 / presence-header 548 / entity-header) CRLF) 549 CRLF 550 [ command-body ] 552 im-request = request-line 553 *((general-header 554 / im-header 555 / entity-header) CRLF) 556 CRLF 557 [ command-body ] 559 5.2.1. Method 561 The method token indicates the method to be performed on the 562 resource. Here, methods are categorized into three groups; presence 563 methods for presence services, IM methods for instant messaging 564 services, and general methods for both. In section 8.4, these are 565 further classified for the detailed specifications. 567 method = general-method 568 / presence-method 569 / im-method 571 general-method = "LOGIN" ; Section 7.3.1 572 / "STARTTLS" ; Section 7.3.2 573 / "LOGOUT" ; Section 7.3.3 574 / "PING" ; Section 7.3.4 575 / "VERIFYSERVER" ; Section 7.3.5 577 presence-method = "SUBSCRIBE" ; Section 7.1.1 578 / "UNSUBSCRIBE" ; Section 7.1.2 579 / "NOTIFY" ; Section 7.1.3 581 im-method = "SEND" ; Section 7.2.1 583 5.2.2. Version 585 The version identifies the version of the protocol in use. It 586 contains the name string specifying the protocol and the major and 587 minor version numbers. 589 version = "PRIM" "/" 1*DIGIT "." 1*DIGIT 591 PRIM adopts the similar protocol versioning policy to those described 592 in RFC 2145 [RFC2145] and RFC 2616 [HTTP1.1]. Thus, the protocol 593 version is intended to allow the sender to indicate the format of a 594 command and its capability for understanding further communication. 595 See RFC 2616 and 2145 for more detailed explanations. 597 A PRIM application SHOULD send a command version equal to the highest 598 version for which it is at least conditionally compliant, and whose 599 major version is no higher than the highest version supported by the 600 other end, if it is known. A PRIM application MUST NOT send a 601 version for which it is not at least conditionally compliant. 603 A server MAY send a 505 (Version Not Supported) response if cannot 604 send a response using the major version used in the client's request. 606 5.2.3. Request Identifier 608 Request identifiers are used to implement asynchronous requests. 610 request-identifier = 1*[ALPHA / DIGIT] / "-" 612 An endpoint of a connection is responsible for generating request 613 identifiers, and the request identifiers are used to match responses 614 it receives with the requests it has sent. The other endpoint of a 615 connection is responsible for labeling a response with the identifier 616 it received in the request. An identifier may be reused after the 617 endpoint receives the response to the request with the identifier. 619 The request identifier of a command is "-" if and only if the request 620 expects no reply. If an endpoint receives a request with the request 621 identifier "-", it MUST NOT send any response to the request. 623 5.2.4. Content Length 625 The content-length header contains the length of the command body in 626 bytes. 628 content-length = 1*DIGIT 630 5.3. Responses 632 A response includes many of the same fields as a request with the 633 addition of a status code and a response phrase. 635 response-line = version 636 SP request-identifier 637 SP content-length 638 SP status-code 639 SP response-phrase 640 CRLF 642 The request identifier in the response MUST NOT be "-". 644 The status-code is a 3 digit code and the response-phrase is a short 645 message description. The values are defined in Section 8. 647 Some status codes are common to all commands, whereas others are only 648 used by a subset of commands. Common status codes to all commands 649 are: 651 200 OK 652 300 Redirect 653 400 Bad Request 654 401 Unauthorized (except for LOGIN) 655 402 Forbidden (except for LOGIN, STARTTLS, PING) 656 501 Internal Server Error 657 503 Version Not Supported 659 6. Command Headers 661 Command headers are defined as follows: 663 general-header = (from-header 664 / to-header 665 / auth-state-header 666 / SASL-mechanism-header 667 / redirect-header 668 / server-address-header 669 / astrength-header 670 / date-header 671 ) 673 presence-header = duration-header 675 im-header = (message-id-header 676 / conversation-id-header 677 / reply-to-header 678 ) 680 entity-header = content-type-header 682 6.1. General Headers 684 6.1.1. From 686 Identifies the PRESENTITY or INBOX that issued this command, or that 687 it was issued on behalf of. 689 from-header = "From: " ( presence-id / im-id ) 691 The value of this header is either "presence-id" or "im-id". 692 "presence-id" MUST be used only if the underlying method is a 693 "presence-method" or "general-method". "im-id" MUST be used only if 694 the underlying method is an "im-method" or "general-method". 696 The receiving end of a command SHOULD always check that the sender is 697 authorized to send commands on behalf of the identifier in the from- 698 header, as described in Sections 13. 700 6.1.2. To 702 Specifies the PRESENTITY or INBOX this command is intended to. 704 to-header = "To: " ( presence-id / im-id ) 706 The value of this header is either "presence-id" or "im-id". 707 "presence-id" MUST be used only if the underlying method is a 708 "presence-method" or "general-method". "im-id" MUST be used only if 709 the underlying method is an "im-method" or "general-method". 711 6.1.3. Domain 713 Identifies the domain when used with the LOGIN command in the 714 server-server connection. 716 domain-header = "Domain: " domain 718 The value of this header MUST be a valid domain name. 720 6.1.4. Auth-State 722 Indicates the status in the authentication process in the LOGIN 723 command. 725 auth-state-header = "Auth-State: " 726 ( "init" 727 / "continue" 728 / "abort" ) 730 6.1.5. SASL-Mechanism 732 Specifies the SASL mechanism in the LOGIN request or the response to 733 the LOGIN request. In the request, the SASL mechanism the USER AGENT 734 wants to use MUST be specified. When used in the response, one or 735 more mechanisms which the server supports MAY be specified. 737 SASL-mechanism-header = "SASL-Mech: " mechanisms 738 mechanisms = mechanism [ *(SP mechanism) ] 739 mechanism = 1*20(ALPHA / DIGIT / "-" / "_") 741 6.1.6. Redirect 743 When a server cannot handle requests from a USER AGENT or other 744 server, it issues an error response "300 Redirect" which includes the 745 redirect-header. This lets the caller know that its request cannot 746 be handled at this server and an alternative server address and port 747 are provided. 749 redirect-header = "Redirect: " address SP port 750 address = domain / ip4-address / ip6-address 751 port = 1*DIGIT 753 6.1.7. Server-Address 755 Indicates the IP address for the server that is initiating the 756 connection. This header is used in the VERIFYSERVER method to show 757 the address of the server that needs verification (see Sections 10.5 758 and 13.2). 760 server-address-header = "Server-Address: " 761 ( ip4-address / ip6-address ) 763 6.1.8. AStrength 765 When a server acts as a relay, it MUST communicate to the next node a 766 rough indication of the authentication strength of the previous hops 767 using the "Astrength" header unless the servers already have 768 knowledge about the relaying server's authentication strength through 769 some out-of-band manner. If the servers acknowledge the 770 authentication strength of the other end, the AStrength header MAY 771 NOT appear in the relayed request. 773 The syntax for the Astrength header is: 775 astrength-header = "AStrength: " astrength 776 astrength = "strong" / "medium" / "weak" / "none" 778 The meanings of the astrength values are: 780 strong Command authenticity and integrity cannot be 781 compromised by an attacker who has full 782 control of all network links, assuming no 783 compromise of keying materials, installed 784 software, or cryptographic algorithms. 786 medium Command authenticity or integrity could be 787 compromised by a packet substitution or DNS 788 spoofing attack. 790 weak Command could be forged by an attacker who has 791 previously been a passive listener on one or 792 more network links. 794 none Command could be forged by an attacker with no 795 special information. 797 Examples of medium protection include one-time passwords [RFC 2289] 798 and HTTP digest authentication [RFC 2617 section 3]. Examples of 799 weak protection include cleartext passwords or security protocols 800 subject to replay attacks. 802 If a server or USER AGENT receives a command with no Astrength 803 header, it should assume that the equivalent Astrength is "none". 805 A server relaying a command MUST communicate the weaker of the 806 strength of the connection it received the command on and the 807 Astrength value communicated from the last entity. 809 A server MAY choose to reject a command with a "410 AStrength Too 810 Weak" error because it does not come with sufficient authentication 811 strength (either as reported by the Astrength value or based on the 812 connection from the immediate requester). A relay MUST NOT reject a 813 response on the basis of insufficient authentication strength. 815 Note that, separately from connection-level authentication, an 816 operation may be authenticated using an end-to-end signature. The 817 Astrength header does not bear any relation to this kind of 818 authentication. 820 An example scenario: a PRIM USER AGENT connects to a server for 821 example.net and authenticates using a weak mechanism. It then issues 822 a "send" command from alice@example.net to bob@domain.com. The 823 example.net server connects to domain.com, authenticates using 824 DNSSEC- signed public keys and forwards the IM with "Astrength: weak" 825 because the previous link was authenticated with a weak. The 826 domain.com server sends the command to the clients receiving commands 827 for bob@domain.com with "Astrength: weak" since that was the 828 authentication value claimed by example.net, even though domain.com 829 received the command over a strongly authenticated link. 831 Another example scenario: a PRIM client connects to a server for 832 example.net and authenticates using some strong SASL mechanism as 833 alice. It then issues a "send" command from alice@example.net to 834 bob@domain.com. The example.net server connects to domain.com and 835 authenticates, but example.net's public key DNS record is not signed, 836 so it could have been forged by a DNS spoofing attack. The 837 example.net server sends the IM with "Astrength: strong" because it 838 received the command from Alice over a strongly authenticated link; 839 however, the domain.com server will weaken the Astrength to "Medium" 840 when forwarding the command to Bob's clients. 842 6.1.9. Date 844 Specifies the date and time this command was originally issued. PRIM 845 adopts the date syntax as defined in Section 15.5, i.e. specified in 846 [RFC1123]. 848 date-header = "Date: " date-time 849 ; as defined in Section 15.5 851 [It will be affected by the CPIM specification because it would be 852 preferable to have the same format with it. Need more discussions.] 854 6.2. Entity Headers 856 6.2.1. Content-Type 858 A command-body MUST NOT be included unless the description of the 859 particular method allows it. If a command-body is included, the 860 protocol command headers MUST include a Content-Type as specified in 861 [RFC 2045]. 863 The Content-Transfer-Encoding header from [RFC 2045] is not necessary 864 and MUST NOT be included in any command or response. An 865 implementation which receives a Content-Transfer-Encoding header 866 should reject the command with an error 400 Bad Request. 868 6.3. Presence Headers 870 6.3.1. Duration 872 When used with a SUBSCRIBE command and its response, it specifies the 873 amount of seconds the caused subscription SHOULD remain in effect 874 for. 876 duration-header = "Duration: " 1*DIGIT 878 6.3.2. Subscription-ID 880 Specifies the unique identifier of the subscription in the watcher 881 and presentity pair. This header MUST appear in the SUBSCRIBE and 882 NOTIFY commands, and in the responses to SUBSCRIBE commands. 884 subscription-id-header = "Subscription-ID: " 1*(unreserved / escaped) 886 6.4. IM Headers 888 6.4.1. Message-ID 890 The message-id-header specifies the identifier of each IM, which 891 distinguishes the message from others. The sender must generate a 892 globally unique message-id for each IM sent. 894 message-id-header = "Message-ID" 1*(DIGIT / ALPHA) ": " im-id 896 6.4.2. Conversation-ID 898 The conversation-id is used in the SEND command to identify the 899 conversation channel shared by the participants of an IM exchange. A 900 "conversation channel" means a virtual channel which consists of a 901 thread of IMs. When a PRINCIPAL replies to an IM, the reply MUST 902 have the same conversation-id header. 904 conversation-id-header = "Conversation-ID: " 1*(unreserved / escaped) 906 6.4.3. Reply-To 908 The reply-to-header is optionally specified in a SEND command. It 909 indicates an INSTANT INBOX identifier where the sender would prefer 910 to receive any replies. The recipient SHOULD use the "reply-to" 911 header, instead of the "from" header, if the former exists. 913 reply-to-header = "Reply-To: " im-id 915 7. Command Specifications 917 This section describes the command specifications for the PRIM 918 commands used on the server-server connections. The commands are 919 those for establishing connections, and exchanging PRESENCE 920 INFORMATION and INSTANT MESSAGES. 922 In header descriptions below, the sign (o) on the right hand of a 923 header indicates that the header is optional. 925 7.1. Presence Service Commands 927 This section describes the details of the protocol for the PRESENCE 928 SERVICE. 930 7.1.1. SUBSCRIBE - Placement and renewal of SUBSCRIPTION 932 Headers: Request Response 933 --------------------------------------------------------------- 934 from-header from-header 935 to-header to-header 936 duration-header duration-header 937 subscription-id-header subscription-id-header 938 date-header 939 astrength-header (o) 940 content-type-header (o) 941 --------------------------------------------------------------- 943 The SUBSCRIBE method is used to express a WATCHER's interest on the 944 PRESENCE INFORMATION of a PRESENTITY. There are two scenarios where 945 the method is issued: when a 947 o WATCHER wishes to establish a new SUBSCRIPTION to a PRESENTITY, 948 or 950 o Presence Server or USER AGENT needs to renew a SUBSCRIPTION on 951 behalf of a WATCHER 953 from-header: identifies the WATCHER requesting the SUBSCRIPTION. 955 to-header: specifies the PRESENTITY to subscribe to. 957 duration-header: specifies the amount of seconds that this 958 subscription is valid for. 960 subscription-id-header: specifies the unique identifier of the 961 subscription within the watcher (requester) and the presentity. 963 date-header: specifies date and time when the command is generated. 965 astrength-header: specifies the authentication strength of the 966 previous hops as described in Section 6.1.8. 968 The SUBSCRIBE command MAY have a command-body in order to present a 969 piece of information to the target presence server. The meaning of 970 the command-body depends on the services or implementations. 972 A response to the SUBSCRIBE command contains no command-body. After a 973 successful (200 or 201) response to the command, a NOTIFY command 974 which carries the presence information of the target PRESENTITY MUST 975 be immediately invoked. 977 If the value of the duration-header of a SUBSCRIBE command is zero, 978 no subscription is established. In this case, if the subscription- 979 id-header's value is the same one as an existing SUBSCRIPTION of the 980 WATCHER to the PRESENTITY, that SUBSCRIPTION MUST be removed. If the 981 value of the subscription-id-header does not match any of the 982 existing SUBSCRIPTIONS of the WATCHER to the PRESENTITY, it has no 983 impact on these SUBSCRIPTIONS and the SUBSCRIBE command behaves like 984 "fetching" the PRESENCE INFORMATION. 986 The Return Codes are: 988 200 OK: The SUBSCRIPTION was placed successfully. The command 989 contains no command-body. 991 201 Duration Adjusted: The SUBSCRIPTION was placed successfully, 992 yet a different duration was set and this is indicated in the 993 duration- header of the response. 995 402 Forbidden: The PRESENTITY authenticated in the current 996 connection does not have rights (through the current ACL) to 997 SUBSCRIBE to the PRESENTITY requested. No command-body is present. 999 403 Resource Not Found: The PRESENTITY does not exist. No command- 1000 body is present. 1002 404 Subscription Not Found: The subscription specified by the 1003 subscription-id-header does not exist in the case of renewing 1004 SUBSCRIBE requests. No command-body is present. 1006 505 Too Many Subscriptions: The maximum amount of SUBSCRIPTIONS 1007 placed by the system administrator or by the targeted PRESENTITY 1008 has been reached. No command-body is present. 1010 If a SUBSCRIPTION already exists between a WATCHER and a PRESENTITY, 1011 then a successful SUBSCRIBE request from the WATCHER updates the 1012 duration of the SUBSCRIPTION to the value carried in the request. 1014 7.1.2. UNSUBSCRIBE - Removal of SUBSCRIPTION 1016 Headers: Request Response 1017 --------------------------------------------------------------- 1018 from-header from-header 1019 to-header to-header 1020 astrength-header (o) 1021 --------------------------------------------------------------- 1023 The UNSUBSCRIBE method indicates that the WATCHER is no longer 1024 interested in receiving NOTIFICATIONS for changes in PRESENCE 1025 INFORMATION of a PRESENTITY. 1027 It may either be issued by a USER AGENT or a Presence Server on 1028 behalf of the WATCHER. 1030 The from-header identifies the WATCHER requesting the SUBSCRIPTION 1031 cancellation. 1033 The to-header specifies the PRESENTITY to unsubscribe from. 1035 The Response MUST NOT carry a command-body. The Return Codes in the 1036 Response are: 1038 200 OK: The SUBSCRIPTION was removed. 1040 404 Subscription Not Found: there is no SUBSCRIPTION from the 1041 specified WATCHER to the specified PRESENTITY. 1043 Note: When the duration of a SUBSCRIPTION elapses, without the 1044 reception of a renewal, the Presence Server MUST assume an implicit 1045 UNSUBSCRIBE method has been received. 1047 7.1.3. NOTIFY - Propagation of PRESENCE INFORMATION 1049 Headers: Request Response 1050 --------------------------------------------------------------- 1051 from-header from-header 1052 to-header to-header 1053 subscription-id-header 1054 astrength-header (o) 1055 duration-header (o) 1056 date-header 1057 content-type-header 1058 --------------------------------------------------------------- 1060 The NOTIFY command informs WATCHERS when the PRESENCE INFORMATION of 1061 the PRESENTITY they have SUBSCRIPTIONS to has changed. Also, it MUST 1062 be issued immediately after processing of successful SUBSCRIBE 1063 commands. The NOTIFY will carry the whole PRESENCE INFORMATION and 1064 not just the modified tuple. 1066 The command-body carries a presence document corresponding to the 1067 PRESENCE INFORMATION for the PRESENTITY. The body MUST be a data of 1068 the Content-Type "message/cpim" [CPIM-MSGFMT] containing an 1069 "application/cpim-pidf+xml" data [CPIM-PIDF], or just a data of the 1070 "application/cpim-pidf+xml" type. 1072 The headers for this command are: 1074 from-header: identifies the PRESENTITY this NOTIFICATION is about. 1076 to-header: specifies the WATCHER that needs to receive this 1077 information. 1079 astrength-header: specifies the authentication strength of the 1080 previous hops as described in Section 6.1.8. 1082 duration-header: specifies the amount of remaining seconds that the 1083 corresponding subscription is valid for. Optional. 1085 date-header: specifies date and time when the command is generated. 1087 content-type-header: specifies the content type of the command- 1088 body. 1090 The Response MUST NOT carry any command-body. 1092 The NOTIFY command MAY contain the duration-header that specifies the 1093 amount of remaining seconds of the corresponding SUBSCRIPTION. If 1094 the value of the duration-header is zero, the NOTIFY command informs 1095 the WATCHER that the SUBSCRIPTION has been canceled by some means. 1096 No future NOTIFICATIONS will be sent to this WATCHER. 1098 The Return Codes are: 1100 200 OK: the PRESENCE INFORMATION was received and processed 1101 correctly. 1103 400 Bad Request: The command was malformed or the command-body did 1104 not carry a valid XML document. The PRESENCE INFORMATION was not 1105 accepted. 1107 403 Resource Not Found: no such WATCHER exists. 1109 7.2. Instant Messaging Service Commands 1111 This section describes the details of the commands for the INSTANT 1112 MESSAGE SERVICE. 1114 7.2.1. SEND - Sending Messages 1116 Headers: Request Response 1117 --------------------------------------------------------------- 1118 from-header from-header 1119 to-header to-header 1120 message-id-header message-id-header 1121 conversation-id-header conversation-id-header 1122 date-header 1123 astrength-header (o) 1124 content-type-header 1125 --------------------------------------------------------------- 1127 [Note. It would be necessary to make the "SEND" command syntax 1128 compatible with the CPIM specification. We need more discussion.] 1130 The SEND command is used to transport an INSTANT MESSAGE. 1132 The command-body carries an INSTANT MESSAGE, as described in section 1133 11. 1135 The headers for this command are: 1137 from-header: identifies the SENDER of the message. 1139 to-header: identifies the INSTANT INBOX the message is sent to. 1141 astrength-header: indicates the lowest authentication strength for 1142 previous hops of the command. 1144 message-id-header: specifies a unique identifier for each INSTANT 1145 MESSAGE. 1147 conversation-id-header: specifies a unique identifier to 1148 distinguish a given conversation thread between multiple 1149 participants. 1151 date-header: specifies date and time when the command is generated. 1153 content-type-header: specifies the content type of the command- 1154 body. 1156 The response to this method MUST NOT carry any command-body, and MAY 1157 have the following return codes: 1159 101 Unknown Delivery Status: The IM Service cannot assure that the 1160 message was delivered. 1162 200 OK: the INSTANT MESSAGE was delivered at least to one PRINCIPAL 1163 that was listening to the recipient INSTANT INBOX. 1165 402 Forbidden: The PRINCIPAL authenticated in the current 1166 connection does not have rights (through the current ACL) to send 1167 messages to the recipient INSTANT INBOX. 1169 408 Inbox Is Closed: the INSTANT MESSAGE could not be delivered 1170 because the recipient INSTANT INBOX was closed. This may be issued 1171 by either the IM Server if there is no-one listening to that inbox, 1172 or by a USER AGENT if it decides to block the sender (see 1173 explanation below). 1175 The response code sent by the IM Server hosting the recipient INSTANT 1176 INBOX is always the most positive response from all the connections 1177 listening to that INBOX. Thus, if at least one USER AGENT 1178 acknowledges the message, then its server will acknowledge it too. 1180 Note: It is important to remember that PRESENCE INFORMATION may be 1181 revealed through the responses to INSTANT MESSAGES. For example, it 1182 may be possible for someone to "ping" an INSTANT INBOX by sending 1183 messages to it, in order to deduce PRESENCE INFORMATION from the 1184 state of that INBOX. USER AGENT implementations can prevent that if 1185 necessary by returning 408 Inbox Is Closed if the sender of an 1186 INSTANT MESSAGE should not know that the INBOX is OPEN. 1188 7.3. General Commands 1190 The commands described in this section apply to both the PRESENCE and 1191 INSTANT MESSAGING services. 1193 7.3.1. LOGIN - Connection Setup 1195 Headers: Request Response 1196 --------------------------------------------------------------- 1197 domain-header domain-header 1198 auth-state-header auth-state-header 1199 SASL-mechanism-header SASL-mechanism-header 1200 --------------------------------------------------------------- 1202 For a server-server connection, the initiating host MAY issue a LOGIN 1203 request prior to sending any presence or IM commands in order to 1204 authenticate itself as an authoritative host in the initiating 1205 domain. The domain MUST be presented with the domain-header. 1207 If the authentication process is not successful the TCP connection 1208 MUST be dropped. The LOGIN request MAY be preceded by the STARTTLS 1209 request when the implementations support TLS for a secure connection. 1210 Any other requests that are received before the authentication 1211 completed MUST receive an "Unauthorized" response. 1213 The authentication process is not necessarily completed in a single 1214 request/response pair, but it can be fulfilled in a sequence of the 1215 request/response pairs. The auth-state-header MUST be used to 1216 indicate the state of the authentication process. 1218 The command-body in the LOGIN request and its response MAY carry the 1219 authentication information for the respective SASL mechanism. 1221 See section 9 for the details of authentication procedures. 1223 Return Codes: 1225 100 Authentication Continued: This response may possibly carry a 1226 command-body with information pertaining to the SASL challenge, and 1227 a SASL-mechanism-header specifying the SASL mechanism supported by 1228 the server. The originator needs to send other LOGIN command, with 1229 auth-state-header as "continue", and the response to the challenge 1230 in the command-body. 1232 200 OK: The sender is authenticated and the connection may be used 1233 to transport further commands. 1235 406 Authorization Failed: The operation failed to authenticate the 1236 connection. No further commands are allowed and the receiver MUST 1237 terminate the connection. 1239 409 Already Authenticated: This is returned if a LOGIN command has 1240 already succeeded. 1242 7.3.2. STARTTLS - Secuire Connection Setup 1244 Headers: Request Response 1245 --------------------------------------------------------------- 1246 none none 1247 --------------------------------------------------------------- 1249 A server MAY issue STARTTLS request to upgrade a TCP connection to a 1250 TLS [TLS] enabled one. Implementations that support TLS MAY issue a 1251 STARTTLS request prior to issuing any other requests. 1253 Once the client credentials are successfully exchanged using TLS 1254 negotiation, the "EXTERNAL" SASL mechanism MAY be used in the 1255 subsequent LOGIN process. The "PLAIN" SASL mechanism SHOULD NOT be 1256 used if the STARTTLS upgrading process fails to establish a fully 1257 strong encryption layer. 1259 The Request and the response MUST NOT carry a command-body. 1261 Return Codes: 1263 200 OK: The TLS negotiation should start. Once a STARTTLS command 1264 issued, the initiator MUST NOT issue further requests until a 1265 server response is received and the TLS negotiation is completed. 1267 501 Not Implemented: TLS is not implemented and thus the client 1268 must authenticate itself using the LOGIN method. 1270 7.3.3. LOGOUT - Connection Shutdown 1272 Headers: Request 1273 --------------------------------------------------------------- 1274 none 1275 --------------------------------------------------------------- 1277 The receiver of the LOGOUT command MUST NOT send any response. 1279 7.3.4. PING - Testing a connectionG 1281 Headers: Request 1282 --------------------------------------------------------------- 1283 none 1284 --------------------------------------------------------------- 1286 When a peer in a connection wants to verify if the connection is 1287 alive, it may send a PING command. No response is expected from the 1288 other peer. 1290 A successful transmission of a PING does not guarantee its reception 1291 at the other end, nor does it verify that all is well with its peer. 1292 However the transmission of the PING may provoke an error, and 1293 thereby causing the sending peer to realize there is a problem with 1294 the connection. If this happens the USER AGENT or server assumes an 1295 implicit LOGOUT command. 1297 7.3.5. VERIFYSERVER - Verifying a server's authority 1299 Headers: Request Response 1300 --------------------------------------------------------------- 1301 server-address-header server-address-header 1302 --------------------------------------------------------------- 1304 As described in section 13.2, when a server needs to verify whether 1305 another server (known through its IP address) belongs to a given 1306 domain, it performs one or more DNS lookups. Large domains with a 1307 significant amount of servers might not be able to publish every 1308 entry for every server, due to DNS limitations. Thus a DNS lookup 1309 might not be sufficient to determine whether a given server belongs 1310 to a given domain. 1312 If it is not possible to verify the domain of a server through a DNS 1313 lookup, a VERIFYSERVER command can be issued. 1315 The VERIFYSERVER MAY be issued in a new TCP connection, without 1316 previous LOGIN. The verifying server will issue the command to any 1317 of the addresses returned in the DNS lookup. 1319 The server-address-header specifies the IP address of the server that 1320 needs verification. 1322 The response MUST NOT have a command body. 1324 Return Codes: 1326 200 OK: the server does belong to that domain. 1328 403 Resource Not Found: the server does not belong to this domain. 1330 8. Response Codes 1332 The policy for assigning response codes follows the convention used 1333 in HTTP/1.1 [HTTP1.1]. 1335 o 1xx: Informational - Request received, continuing process 1337 o 2xx: Success - The action was successfully received, understood, 1338 and accepted 1340 o 3xx: Redirection - Further action must be taken in order to 1341 complete the request 1343 o 4xx: Request Error - The request contains bad syntax or cannot be 1344 fulfilled 1346 o 5xx: Server Error - The server failed to fulfill an apparently 1347 valid request 1349 100 Authentication Continued 1351 The request for authentication has been accepted and the 1352 authentication process is continued. 1354 101 Unknown Delivery Status 1355 The server was unable to determine that the message was 1356 successfully delivered to an INSTANT INBOX or that the transmission 1357 failed. This could be because the message was delivered on a best- 1358 effort basis, or it was delivered to an "offline" message store. 1360 200 OK 1362 The request has been successfully processed. 1364 201 Duration Adjusted 1366 The SUBSCRIPTION was placed successfully, yet its duration was not 1367 acceptable to the server. A new duration was set and this was 1368 indicated in the duration-header of the response. 1370 300 Redirect 1372 The server was unable to deal with the request and instructs the 1373 caller to reconnect to a different server and reissue the operation 1374 there. 1376 400 Bad Request 1378 The request could not be understood by the server due to malformed 1379 syntax of the headers or malformed content. The requesting host 1380 SHOULD NOT repeat the request without modifications. 1382 401 Unauthorized 1384 The request requires authentication. If received this response, 1385 the requesting host MUST authenticate itself through the LOGIN 1386 request. 1388 402 Forbidden 1390 The server understood the request, but it has not been authorized. 1392 403 Resource Not Found 1394 The specified resource was not found at the server. 1396 404 Subscription Not Found 1398 The SUBSCRIPTION specified in the Subscription-ID header was not 1399 found at the resource. 1401 406 Authentication Failed 1402 The authentication process has failed. The reason for it is one of 1403 the following: 1405 o The authentication process using the specified SASL-Mechanism 1406 failed. 1408 o The LOGIN request specifies an inappropriate SASL Mechanism. 1410 o In the midst of the authentication process, the requester tries to 1411 start another authentication process by specifying 'Auth-State: 1412 init'. 1414 407 Timeout 1416 The server timed-out after waiting for a response from another 1417 client or server. 1419 408 Inbox Is Closed 1421 The INSTANT INBOX is not currently accepting messages. 1423 409 Already Authenticated 1425 The connection was authenticated previously through a LOGIN 1426 command. 1428 410 Astrength Too Weak 1430 The command was rejected because the server requires a higher level 1431 of security and this could not be provided. 1433 500 Internal Server Error 1435 The request has not been fulfilled because of the error internal to 1436 the server. 1438 501 Not Implemented 1440 The server does not support the functionality required to fulfill 1441 the request. This response is typically returned when the server 1442 has received a request of the services it does not provide. 1444 502 Bad Gateway 1446 The server, while acting as a gateway or proxy, received an invalid 1447 response from the other PRIM or non-PRIM server it accessed in 1448 attempting to fulfill the request. 1450 503 Version Not Supported 1452 The server or client does not support the specified protocol 1453 version used for the request. 1455 504 Gateway Timeout 1457 The server, while acting as a gateway or proxy, did not receive a 1458 timely response from the other PRIM or non-PRIM server it accessed 1459 in attempting to fulfill the request. 1461 505 Too Many Subscriptions 1463 The SUBSCRIBE request has not been fulfilled because the request 1464 exceeds the specified maximum number of SUBSCRIPTIONS at the 1465 resource. When this status code is received, the client SHOULD NOT 1466 retry the SUBSCRIPTION immediately. 1468 9. Authentication 1470 PRIM implements security on a per-connection basis: each connection 1471 end-point is authenticated in order to establish the PRESENTITIES 1472 and INBOXES on behalf of which that end-point can communicate. 1474 After authentication succeeds, the other end-point will accept 1475 requests pertaining to those PRESENTITIES or INBOXES, and direct 1476 requests to them over that connection. 1478 9.1. Server-Server Authentication 1480 When a server establishes a connection to another server, that 1481 connection end-point can be authorized to communicate on behalf of 1482 multiple PRESENTITIES or INBOXES. This is usually performed by 1483 authenticating the end-point as a valid host of the initiating 1484 domain. 1486 The connection end-points MAY use a LOGIN command for the 1487 authentication. But, if two end-points have authenticated each other 1488 with an out-of-band method (e.g. TLS) or they have enough knowledge 1489 about the other end-point for their purpose (e.g. IP address), it MAY 1490 NOT use such a particular command. If the connection uses TLS, then 1491 the domains served by each end-point are established in the 1492 beginning, through the certificates provided. 1494 Another type of authorization can take place throughout the duration 1495 of the connection. Each end-point will establish that a domain is 1496 being served by the other end-point when the first request pertaining 1497 to that domain is received. This can happen more than once per 1498 connection. 1500 Verification that a given server is responsible for a given domain is 1501 done by performing a name resolution (as described in section 7.2). 1502 It is possible that due to DNS limitations, in the case of a domain 1503 with a large number of servers, only partial DNS records are 1504 advertised. Thus, the address of the server initiating the 1505 connection may not be in the records received. In this case a 1506 VERIFYSERVER method is performed to establish whether the initiating 1507 server has authority over the corresponding domain. This is 1508 described in Section 10.5. 1510 9.2. Authentication Using LOGIN 1512 When a server establishes a connection to a server, it MAY issue a 1513 LOGIN command to authenticate itself as a valid host representing its 1514 domain. The LOGIN authentication procedure in PRIM uses SASL [SASL]. 1515 The LOGIN request and response MUST include a SASL-Mechanism header 1516 field so that the end-points could negotiate the SASL mechanism to be 1517 used. As SASL mechanisms, every PRIM implementation MUST implement 1518 PLAIN [SASL-PLAIN] and is RECOMMENDED to implement CRAM-MD5 [CRAM- 1519 MD5], and EXTERNAL [SASL]. It MAY also implement other mechanisms as 1520 needed. 1522 The LOGIN authentication procedure is sketched as follows; 1524 (1) The initial LOGIN request 1526 A server issues a LOGIN request including the Auth-State header 1527 with the value "init". It MUST also contain the Domain header 1528 specifying the initiating domain and the SASL-Mechanism header 1529 whose value is a comma-separated list of SASL mechanisms the 1530 initiating host is capable to use in the descending order of 1531 preference. 1533 [Example] 1535 LOGIN PRIM/1.0 0224 0 1536 Domain: prim.fujitsu.com 1537 Auth-State: init 1538 SASL-Mech: CRAM-MD5,PLAIN 1540 If the LOGIN request is acceptable, the target server SHOULD 1541 respond with '100 Authentication Continued' response. It MUST 1542 contains the SASL-Mechanism header with the value of at least one 1543 selected SASL mechanism by the server. If a challenge-response 1544 mechanism is selected, the response MUST contain a challenge data 1545 in the body. 1547 PRIM/1.0 0224 48 100 Authentication Continued 1548 Domain: prim.fujitsu.com 1549 Auth-State: init 1550 SASL-Mech: CRAM-MD5 1552 <20010226095208.1018677043.foo1.bar.fujitsu.com> 1554 (2) The subsequent LOGIN requests 1556 If an initiating server receives a '100 Authentication Continued' 1557 response to the initial LOGIN request, it SHOULD try another LOGIN 1558 request with the header 'Auth-State: continue'. This LOGIN request 1559 MUST contain the SASL-Mechanism header with the single value of 1560 selected SASL mechanism. 1562 The LOGIN request MAY contain the domain's authentication 1563 information in the body required by the selected mechanism. Details 1564 in the case of CRAM-MD5, PLAIN, and EXTERNAL are described in the 1565 following subsections. 1567 If the LOGIN request is validated, the target server respond with a 1568 '200 OK' response. If the same PRINCIPAL is already authenticated 1569 by a preceding LOGIN procedure, the server MAY respond with a '409 1570 Already Authenticated'. Otherwise, a '406 Authentication Failed' 1571 response SHOULD be returned to the USER AGENT. In this case, the 1572 USER AGENT MUST NOT send any other request commands in this 1573 connection. 1575 (2-a) CRAM-MD5 1577 The USER AGENT calculates the response data using the keyed MD5 1578 algorithm [KEYED-MD5] where the key is the shared pass phrase and 1579 the text is the challenge data. Then, it sends the hexadecimal 1580 string of the response octets prepended by the user name and CRLF 1581 in the body of the LOGIN request. 1583 [Example] 1585 LOGIN PRIM/1.0 0225 50 1586 Domain: prim.fujitsu.com 1587 Auth-State: continue 1588 SASL-Mech: CRAM-MD5 1589 Content-Type: text/plain 1590 prim.fujitsu.com 1591 106d12b16fc323dc2f3d19b587f8d0ff 1593 (2-b) PLAIN 1595 The PLAIN mechanism SHOULD be used only on a fully secured 1596 connection, such as one already encrypted with TLS. In this case, 1597 the body part of the LOGIN request contains the user name and the 1598 pass phrase in a plain text separated by CRLF. 1600 [Example] 1602 LOGIN PRIM/1.0 84505230 27 1603 Domain: prim.fujitsu.com 1604 Auth-State: continue 1605 SASL-Mech: PLAIN 1606 Content-Type: text/plain 1608 prim.fujitsu.com 1609 hi there! 1611 (2-c) EXTERNAL 1613 The EXTERNAL mechanism is intended to be used in the case that the 1614 PRINCIPAL has been already authenticated with some external 1615 authentication method, such as TLS mutual authentication. The LOGIN 1616 command using this mechanism contains nothing in the body. 1618 10. Presence Information Data Format (PIDF) 1620 PRIM adopts CPIM Presence Information Data Format [CPIM-PIDF] as 1621 its presence data format. This brings CPIM conformance to PRIM 1622 with its native presence data format. The content-type 1623 "application/cpim-pidf+xml" is defined in that specification. 1625 See the reference for detailed information. 1627 11. IM Format 1629 INSTANT MESSAGES are opaque payloads transferred by SEND commands 1630 tagged by a MIME [MIME] content type. 1632 A SEND command MUST contain a Content-Type header which specifies 1633 the content type of the payload. It MAY contain any proper MIME 1634 header which may not be defined here. 1636 For the CPIM conformance, A USER AGENT MUST understand and generate 1637 messages of the content type 'message/cpim'[CPIM-MSG]. In 1638 particular, a USER AGENT MUST generate an INSTANT MESSAGE of the 1639 type 'message/cpim' if it sends the message to other domains which 1640 do not or may not understand PRIM. The correspondence between the 1641 PRIM and CPIM message format is described in Section 17. 1643 The PRIM servers MUST forward the message as is when the message is 1644 relayed to the clients or other servers. That is, the servers MUST 1645 NOT delete or modify any header which appears in the command. 1647 12. Security Considerations 1649 There exists many kind of security threats in the Presence / Instant 1650 Messaging services and applications as described in the IMPP 1651 Requirements [RFC 1778] and the CPIM document [CPIM]. 1653 PRIM specifies mechanisms to achieve connection security and to 1654 realize access control including presence publication control. 1656 The future PRIM specifications will conform to the expected CPIM data 1657 formats for secure and interoperable Presence information and IM 1658 exchanges [CPIM,CPIM-MSG]. It will acquire the message level 1659 security such as end-to-end confidentiality and integrity. 1661 13. References 1663 [CPIM] D. Crocker et al., "A Common Profile for Instant Messaging 1664 (CPIM)", draft-ietf-impp-cpim-01.txt, Work in Progress. 1666 [CPIM-MSG] D. Atkins and G. Klyne, "Common Presence and Instant 1667 Messaging Message Format", draft-ietf-impp-cpim-msgfmt-00.txt, 1668 Work in Progress. 1670 [CRAM-MD5] J.Klensin, R.Catoe and P. Krumviede, "IMAP/POP AUTHorize 1671 Extension for Simple Challenge/Response", RFC 2195, September 997. 1673 [HTTP1.1] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, 1674 P. Leach, and T. Berners-Lee, "Hypertext Transfer Protocol -- 1675 HTTP/1.1", RFC 2616, June 1999 1677 [MIME] Multipurpose Internet Mail Extensions. See RFC 822, RFC 2045, 1678 RFC 2046, RFC 2047, RFC 2048, and RFC 2049. 1680 [OpenPGP] J. Callas, etc., "OpenPGP Message Format", RFC2440, 1681 November 1998. 1683 [RFC822] Crocker, D., "Standard for the format of ARPA Internet text 1684 messages", RFC 822, STD 11, Aug 1982. 1686 [RFC1123] R. Braden, "Requirements for Internet Hosts -- Application 1687 and Support", RFC 1123, October 1989 1689 [RFC1738] T. Berners-Lee, L. Masinter, M. McCahill, "Uniform Resource 1690 Locators", RFC 1738, December 1994. 1692 [RFC2778] M. Day, J. Rosenberg, H. Sugano, "A Model for Presence and 1693 Instant Messaging", RFC 2778, February 2000. 1695 [RFC2779] M.Day, S.Aggarwal, G.Mohr, and J.Vincent, "Instant 1696 Messaging / Presence Protocol Requirements", RFC 2779, February 2000. 1698 [SASL] J. Myers, "Simple Authentication and Security Layer (SASL)", 1699 RFC2222, October 1997. 1701 [SASL-PLAIN] C. Newman, "Using TLS with IMAP, POP3 and ACAP", 1702 RFC2595, June 1999. 1704 [SMIME] P. Hoffman, Ed, "S/MIME Version 3 Message Specification", 1705 RFC2633, June 1999. 1707 [TLS] T.Dierks, and C. Allen, "The TLS Protocol Version 1.0", 1708 RFC2246, January 1999. 1710 [URI] T. Berners-Lee, R. Fielding, L. Masinter, "Uniform Resource 1711 Identifiers (URI): Generic Syntax", RFC2396, August 1998. 1713 [XML] Extensible Mark Up Language. A W3C recommendation. See 1714 http://www.w3.org/TR/1998/REC-xml-19980210 for the 10 February 1998 1715 version. 1717 14. Acknowledgements 1719 The authors greatly appreciate helpful comments from John Stracke and 1720 Harald Alvestrand. 1722 15. Author's Addresses 1723 F. Mazzoldi 1724 flo@personity.com 1725 Personity, Inc. 1726 4516 Henry Street, Suite 113 1727 Pittsburgh PA 15213 1728 USA 1730 A. Diacakis 1731 thanos@personity.com 1732 Personity, Inc. 1733 4516 Henry Street, Suite 113 1734 Pittsburgh, PA 15213 1735 USA 1737 S. Fujimoto 1738 shingo_fujimoto@jp.fujitsu.com 1739 Fujitsu Laboratories Ltd. 1740 64, Nishiwaki 1741 Ohkubo-cho 1742 Akashi 674 1743 Japan 1745 G. Hudson 1746 ghudson@mit.edu 1747 Massachusetts Institue of Technology 1748 Cambridge, MA 02139 1749 USA 1751 J. D. Ramsdell 1752 ramsdell@mitre.org 1753 The MITRE Corporation 1754 202 Burlington Road 1755 Bedford, MA 01730-1420 1756 USA 1758 H. Sugano 1759 sugano.h@jp.fujitsu.com 1760 Fujitsu Laboratories Ltd. 1761 64, Nishiwaki 1762 Ohkubo-cho 1763 Akashi 674 1764 Japan 1766 16. Full Copyright Statement 1768 Copyright (C) The Internet Society (2001). All Rights Reserved. 1770 This document and translations of it may be copied and furnished to 1771 others, and derivative works that comment on or otherwise explain it 1772 or assist in its implementation may be prepared, copied, published 1773 and distributed, in whole or in part, without restriction of any 1774 kind, provided that the above copyright notice and this paragraph are 1775 included on all such copies and derivative works. However, this 1776 document itself may not be modified in any way, such as by removing 1777 the copyright notice or references to the Internet Society or other 1778 Internet organizations, except as needed for the purpose of 1779 developing Internet standards in which case the procedures for 1780 copyrights defined in the Internet Standards process must be 1781 followed, or as required to translate it into languages other than 1782 English. 1784 The limited permissions granted above are perpetual and will not be 1785 revoked by the Internet Society or its successors or assigns. 1787 This document and the information contained herein is provided on an 1788 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1789 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1790 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1791 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1792 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1794 Acknowledgement 1796 Funding for the RFC editor function is currently provided by the 1797 Internet Society.