idnits 2.17.1 draft-saintandre-xmpp-simple-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1216. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1193. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1200. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1206. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (August 8, 2005) is 6829 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: '1' on line 1006 -- Looks like a reference, but probably isn't: '2' on line 934 -- Looks like a reference, but probably isn't: '3' on line 938 == Unused Reference: 'IMP-MODEL' is defined on line 1124, but no explicit reference was found in the text ** Obsolete normative reference: RFC 822 (Obsoleted by RFC 2822) ** Obsolete normative reference: RFC 2396 (Obsoleted by RFC 3986) ** Obsolete normative reference: RFC 3454 (ref. 'STRINGPREP') (Obsoleted by RFC 7564) ** Obsolete normative reference: RFC 2718 (ref. 'URL-GUIDE') (Obsoleted by RFC 4395) ** Obsolete normative reference: RFC 3920 (ref. 'XMPP-CORE') (Obsoleted by RFC 6120) ** Obsolete normative reference: RFC 3921 (ref. 'XMPP-IM') (Obsoleted by RFC 6121) -- Obsolete informational reference (is this intentional?): RFC 3490 (ref. 'IDNA') (Obsoleted by RFC 5890, RFC 5891) == Outdated reference: A later version (-19) exists of draft-ietf-simple-message-sessions-11 Summary: 10 errors (**), 0 flaws (~~), 5 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Saint-Andre 3 Internet-Draft JSF 4 Expires: February 9, 2006 A. Houri 5 IBM 6 J. Hildebrand 7 Jabber, Inc. 8 August 8, 2005 10 Basic Messaging and Presence Interoperability between the Extensible 11 Messaging and Presence Protocol (XMPP) and Session Initiation Protocol 12 (SIP) for Instant Messaging and Presence Leveraging Extensions (SIMPLE) 13 draft-saintandre-xmpp-simple-05 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on February 9, 2006. 40 Copyright Notice 42 Copyright (C) The Internet Society (2005). 44 Abstract 46 This document defines a bi-directional protocol mapping for use by 47 gateways that enable the exchange of presence information and single 48 instant messages between systems that implement the Extensible 49 Messaging and Presence Protocol (XMPP) and those that implement the 50 basic extensions to the Session Initiation Protocol (SIP) for instant 51 messaging and presence. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1 Architectural Assumptions . . . . . . . . . . . . . . . . 3 57 1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 58 2. Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 2.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 2.2 XMPP to SIP . . . . . . . . . . . . . . . . . . . . . . . 7 61 2.3 SIP to XMPP . . . . . . . . . . . . . . . . . . . . . . . 8 62 3. Instant Messages . . . . . . . . . . . . . . . . . . . . . . . 8 63 3.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 8 64 3.2 XMPP to SIP . . . . . . . . . . . . . . . . . . . . . . . 9 65 3.3 SIP to XMPP . . . . . . . . . . . . . . . . . . . . . . . 11 66 4. Presence Subscriptions . . . . . . . . . . . . . . . . . . . . 12 67 4.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 12 68 4.2 XMPP to SIP . . . . . . . . . . . . . . . . . . . . . . . 13 69 4.3 SIP to XMPP . . . . . . . . . . . . . . . . . . . . . . . 15 70 5. Presence Notifications . . . . . . . . . . . . . . . . . . . . 18 71 5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 18 72 5.2 XMPP to SIP . . . . . . . . . . . . . . . . . . . . . . . 19 73 5.3 SIP to XMPP . . . . . . . . . . . . . . . . . . . . . . . 21 74 6. Security Considerations . . . . . . . . . . . . . . . . . . . 23 75 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 76 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 77 8.1 Normative References . . . . . . . . . . . . . . . . . . . 24 78 8.2 Informative References . . . . . . . . . . . . . . . . . . 25 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 26 80 Intellectual Property and Copyright Statements . . . . . . . . 27 82 1. Introduction 84 In order to help ensure interoperability between instant messaging 85 and presence systems that conform to the requirements of RFC 2779 86 [IMP-REQS], it is important to clearly define mappings between such 87 protocols. Within the IETF, work has proceeded on two such 88 protocols: 90 o Various extensions to the Session Initiation Protocol ([SIP]) for 91 instant messaging and presence, as developed within the SIP for 92 Instant Messaging and Presence Leveraging Extensions (SIMPLE) 93 Working Group 94 o The Extensible Messaging and Presence Protocol (XMPP), which 95 consists of a formalization of the core XML streaming protocols 96 developed originally by the Jabber open-source community 98 One approach to helping ensure interoperability between such 99 protocols is to map each protocol to the abstract semantics described 100 in [CPIM] and [CPP]; that is the approach taken by [SIMPLE-CPIM] and 101 [XMPP-CPIM]. The approach taken in this document is to directly map 102 semantics from one protocol to another (i.e., from SIP/SIMPLE to XMPP 103 and vice-versa), mainly for use by gateways between systems that 104 implement one or the other of these protocols. 106 The mappings specified in this document cover four areas that address 107 basic instant messaging and presence functionality: 109 o Mapping of addresses 110 o Mapping of single instant messages 111 o Mapping of presence subscriptions 112 o Mapping of presence notifications 114 Mapping of more advanced functionality (e.g., messaging sessions 115 rather than single messages) is out of scope for this document; 116 however, the authors will attempt to address such issues in future 117 documents. 119 1.1 Architectural Assumptions 121 This document assumes that the mapping between protocols will most 122 likely occur by means of a gateway between an XMPP network and a SIP 123 network being used for instant messaging and presence. Such a 124 gateway is a dedicated translator between the XMPP and SIP/SIMPLE 125 protocols. Although such a gateway could use the [CPIM] and [CPP] 126 specifications to define the common formats into which the protocols 127 are translated for purposes of interworking (as specified in [SIMPLE- 128 CPIM] and [XMPP-CPIM]), this document assumes that a gateway will 129 translate directly from one protocol to the other. Naturally, a 130 gateway need not be a distinct entity on the network and may be co- 131 resident with an XMPP server or a SIMPLE "server" (although there is 132 no such thing as a SIMPLE server per se, we use the term here to 133 refer to a SIP proxy, redirect, or registrar server that supports the 134 SIP extensions for instant messaging and/or presence). Within this 135 document, we refer to a gateway from an XMPP network to a SIP network 136 being used for instant messaging and presence as an "XMPP-SIMPLE 137 gateway" and we refer to a gateway from a SIP network being used for 138 instant messaging and presence to an XMPP network as a "SIMPLE-XMPP 139 gateway". 141 1.2 Terminology 143 The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 144 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 145 RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be 146 interpreted as described in RFC 2119 [TERMS]. 148 2. Addresses 150 2.1 Overview 152 The address formats used to identify XMPP entities are different from 153 those used to identify SIP entities. The XMPP address format is 154 specified in [XMPP-CORE]; as specified in [XMPP-IM], instant 155 messaging and presence applications of XMPP must also support 'im:' 156 and 'pres:' URIs as specified in [CPIM] and [CPP] respectively, 157 although such support may simply involve leaving resolution of such 158 addresses up to an XMPP server. The SIP address format for instant 159 messaging is specified in [SIP-IM]; it may use either 'sip:' or 160 'sips:' URIs as specified in [SIP] or an 'im:' URI as specified in 161 [CPIM]. The SIP address format for presence is specified in [SIP- 162 PRES]; it may use either 'sip:' or 'sips:' URIs as specified in [SIP] 163 or a 'pres:' URI as specified in [CPP]. 165 In this document we describe mappings for addresses of the form 166 only, ignoring any protocol-specific extensions such as 167 XMPP resource identifiers or SIP telephone numbers and passwords. In 168 addition, we have ruled the mapping of domain names as out of scope 169 for now since that is a matter for the Domain Name System; 170 specifically, the issue for interworking between SIP and XMPP relates 171 to the translation of fully internationalized domain names (which the 172 SIP address format does not allow, but which the XMPP address format 173 does allow via [IDNA]) into non-internationalized domain names. 174 Therefore, in the following sections we discuss local-part addresses 175 only (these are called variously "usernames", "instant inboxes", 176 "presentities", and "node identifiers" in the protocols at issue). 178 The sip:/sips:, im:/pres:, and XMPP address schemes allow different 179 sets of characters (although all three allow alphanumeric characters 180 and disallow both spaces and control characters). In some cases, 181 characters allowed in one scheme are forbidden in others; these 182 characters must be mapped appropriately in order to ensure 183 interoperable communications across systems. 185 The local-part address in sip:/sips: URIs inherits from the 186 "userinfo" rule in [RFC2396] with several changes; here we discuss 187 the SIP "user" rule only: 189 user = 1*( unreserved / escaped / user-unreserved ) 190 user-unreserved = "&" / "=" / "+" / "$" / "," / ";" / "?" / "/" 191 unreserved = alphanum / mark 192 mark = "-" / "_" / "." / "!" / "~" / "*" / "'" 193 / "(" / ")" 195 The local-part address in im:/pres: URIs inherits from the "local- 196 part" rule in [RFC822]: 198 local-part = word *("." word) 199 word = atom / quoted-string 200 atom = 1* 201 CHAR = 202 specials = "(" / ")" / "<" / ">" / "@" / "," / ";" 203 / ":" / "\" / <"> / "." / "[" / "]" 205 The local-part address in XMPP addresses allows any US-ASCII 206 character except space, controls, and the " & ' / : < > @ characters. 208 Therefore, following table lists the allowed and forbidden characters 209 in the local-part addresses of each protocol (aside from the 210 alphanumeric, space, and control characters): 212 Table 1: Allowed and forbidden characters (view #1) 214 +----------+--------------+--------------+ 215 | TYPE | ALLOWED | FORBIDDEN | 216 +----------+--------------+--------------+ 217 | SIP/SIPS | ! $ & ' ( ) | " # % / : < | 218 | | * + , - . / | > @ [ \ ] ^ | 219 | | ; = ? _ ~ | ` { | } | 220 +----------+--------------+--------------+ 221 | IM/PRES | ! # $ % & ' | " ( ) , . : | 222 | | * + - / = ? | ; < > @ [ \ | 223 | | ^ _ ` { | } | ] | 224 | | ~ | | 225 +----------+--------------+--------------+ 226 | XMPP | ! # $ % ( ) | " & ' / : < | 227 | | * + , - . ; | > @ | 228 | | = ? [ \ ] ^ | | 229 | | _ `{ | } ~ | | 230 +----------+--------------+--------------+ 232 Now we arrange them in an easier-to-read format, in order by 233 hexadecimal character number (where the "A" row shows the allowed 234 characters and the "F" row shows the forbidden characters). 236 Table 2: Allowed and forbidden characters (view #2) 238 +---+----------------------------------+ 239 | SIP/SIPS CHARACTERS | 240 +---+----------------------------------+ 241 | A | ! $ &'()*+,-./ ; = ? _ ~ | 242 | F | "# % : < > @[\]^ `{|} | 243 +---+----------------------------------+ 244 | IM/PRES CHARACTERS | 245 +---+----------------------------------+ 246 | A | ! #$%&' *+ - / = ? ^_`{|}~ | 247 | F | " () , . :;< > @[\] | 248 +---+----------------------------------+ 249 | XMPP CHARACTERS | 250 +---+----------------------------------+ 251 | A | ! #$% ()*+,-. ; = ? [\]^_`{|}~ | 252 | F | " &' /: < > @ | 253 +---+----------------------------------+ 255 The following table shows the complement of allowed US-ASCII 256 characters in each addressing scheme when compared individually to 257 the other schemes, which we will use in transforming one address 258 format into another (each cell shows the characters that are allowed 259 in the row protocol but forbidden in the column protocol). 261 Table 3: Partial complements of allowed characters 263 +----------+----------+-----------+-------+ 264 | | SIP/SIPS | IM/PRES | XMPP | 265 +----------+----------+-----------+-------+ 266 | SIP/SIPS | N/A | (),.; | &'/ | 267 +----------+----------+-----------+-------+ 268 | IM/PRES | #%/^`{\} | N/A | &'/ | 269 +----------+----------+-----------+-------+ 270 | XMPP | #%[\]^` | (),.;[\] | N/A | 271 | | {|} | | | 272 +----------+----------+-----------+-------+ 274 In addition to the US-ASCII characters described above, many non-US- 275 ASCII (specifically, UTF-8) characters are allowed in XMPP addresses 276 but not allowed in sip:/sips: or im:/pres: URIs, since XMPP allows 277 internationalized local-part addresses. A straightforward mapping of 278 these characters to US-ASCII characters is provided in Section 2.2.5 279 of [URL-GUIDE], namely to encode unsafe octets using percent-encoding 280 (%hexhex). 282 2.2 XMPP to SIP 284 The following is a high-level algorithm for mapping an XMPP address 285 to a sip:, sips:, im:, or pres: URI: 287 1. Split XMPP address into node identifier (local-part; mapping 288 described in remaining steps), domain identifier (hostname; 289 mapping is out of scope), and resource identifier (specifier for 290 particular device or connection; discard this for cross-system 291 interoperability). 292 2. Apply Nodeprep profile of [STRINGPREP] (as specified in [XMPP- 293 CORE]) for canonicalization (OPTIONAL). 294 3. Translate "\26" to "&", "\27" to "'", and "\2f" to "/" 295 respectively (this is consistent with [JEP-0106]). 296 4. Determine if the foreign domain supports im: and pres: URIs 297 (discovered via [SRV] lookup as specified in [XMPP-IM]), else 298 assume that the foreign domain supports sip:/sips: URIs. 299 5. If converting into im: or pres: URI, for each byte, if the byte 300 is in the set (),.;[\] (i.e., the partial complement from Row 3, 301 Column 2 of Table 3 above) then transform that byte to %hexhex. 302 If converting into sip: or sips: URI, for each byte, if the byte 303 is in the set #%[\]^`{|} (i.e., the partial complement from Row 304 3, Column 1 of Table 3 above) then transform that byte to 305 %hexhex. 306 6. Combine resulting local-part with mapped hostname to form 307 local@domain address. 309 7. Prepend with 'im:' scheme (for XMPP stanzas) or 310 'pres:' scheme (for XMPP stanzas) if foreign domain 311 supports these, else prepend with 'sip:' or 'sips:' scheme 312 according to local service policy. 314 2.3 SIP to XMPP 316 The following is a high-level algorithm for mapping a sip:, sips:, 317 im:, or pres: URI to an XMPP address: 319 1. Remove URI scheme. 320 2. Split at the first '@' character into local-part and hostname 321 (mapping the latter is out of scope). 322 3. Translate %hexhex to equivalent octets. 323 4. Treat result as a UTF-8 string. 324 5. Translate "&" to "\26", "'" to "\27", and "/" to "\2f" 325 respectively in order to properly handle the characters forbidden 326 in XMPP addresses but allowed in sip:/sips: URIs and im:/pres: 327 URIs as shown in Column 3 of Table 3 above (this is consistent 328 with [JEP-0106]). 329 6. Apply Nodeprep profile of [STRINGPREP] (as specified in [XMPP- 330 CORE]) for canonicalization (OPTIONAL). 331 7. Recombine local-part with mapped hostname to form local@domain 332 address. 334 3. Instant Messages 336 3.1 Overview 338 Both XMPP and IM-aware SIP systems enable entities (often but not 339 necessarily human users) to send "instant messages" to other 340 entities. The term "instant message" usually refers to messages sent 341 between two entities for delivery in close to real time (rather than 342 messages that are stored and forwarded to the intended recipient upon 343 request). Generally there are three kinds of instant message: 345 o Single messages, which are sent from the sender to the recipient 346 outside the context of any one-to-one chat session or multi-user 347 text conference. 348 o Chat messages, which are sent from the sender to the recipient in 349 the context of a "messaging session" between the two entities. 350 o Groupchat messages, which are sent from a sender to multiple 351 recipients in the context of a text conference (along the lines of 352 [IRC]). 354 This document covers single messages only, since they form the 355 "lowest common denominator" for instant messaging on the Internet. 356 It is likely that future documents will address chat messages as 357 well, especially once the SIMPLE WG completes its work on one-to-one 358 messaging sessions (a likely candidate for finalization is [MSRP]). 360 Instant messaging using XMPP message stanzas of type "normal" is 361 specified in [XMPP-IM]. Instant messaging using SIP requests of type 362 MESSAGE (often called "pager-model" messaging) is specified in 363 [SIP-IM]. 365 As described in [XMPP-IM], a single instant message is an XML 366 stanza of type "normal" sent over an XML stream (since 367 "normal" is the default for the 'type' attribute of the 368 stanza, the attribute is often omitted). In this document we will 369 assume that such a message is sent from an XMPP client to an XMPP 370 server over an XML stream negotiated between the client and the 371 server, and that the client is controlled by a human user (this is a 372 simplifying assumption introduced for explanatory purposes only; the 373 XMPP sender could be a bot-controlled client, a component such as a 374 workflow application, a server, etc.). Continuing the tradition of 375 Shakespeare examples in XMPP documentation, we will say that the XMPP 376 user has an XMPP address of . 378 As described in [SIP-IM], a single instant message is a SIP MESSAGE 379 request sent from a SIP user agent to an intended recipient who is 380 most generally referenced by an Instant Message URI of the form 381 but who may be referenced by a SIP or SIPS URI of 382 the form or Here again we 383 introduce the simplifying assumption that the user agent is 384 controlled by a human user, whom we shall dub . 386 3.2 XMPP to SIP 388 When Juliet wants to send an instant message to Romeo, she interacts 389 with her XMPP client, which generates an XMPP stanza. The 390 syntax of the stanza, including required and optional 391 elements and attributes, is defined in [XMPP-IM]. The following is 392 an example of such a stanza: 394 Example: XMPP user sends message: 396 | 398 | Art thou not Romeo, and a Montague? 399 | 401 Upon receiving such a stanza, the XMPP server to which Juliet has 402 connected either delivers it to a local recipient (if the hostname in 403 the 'to' attribute matches one of the hostnames serviced by the XMPP 404 server) or attempts to route it to the foreign domain that services 405 the hostname in the 'to' attribute. Naturally, in this document we 406 assume that the hostname in the 'to' attribute is an IM-aware SIP 407 service hosted by a separate server. As specified in [XMPP-IM], the 408 XMPP server needs to determine the identity of the foreign domain, 409 which it does by performing one or more [SRV] lookups. For message 410 stanzas, the order of lookups recommended by [XMPP-IM] is to first 411 try the "_xmpp-server" service as specified in [XMPP-CORE] and to 412 then try the "_im" service as specified in [IMP-SRV]. Here we assume 413 that the first lookup will fail but that the second lookup will 414 succeed and return a resolution "_im._simple.example.net.", since we 415 have already assumed that the example.net hostname is running a SIP 416 instant messaging service. (Note: The XMPP server may have 417 previously determined that the foreign domain is a SIMPLE server, in 418 which case it would not need to perform the SRV lookups; the caching 419 of such information is a matter of implementation and local service 420 policy, and is therefore out of scope for this document.) 422 Once the XMPP server has determined that the foreign domain is 423 serviced by a SIMPLE server, it must determine how to proceed. We 424 here assume that the XMPP server contains or has available to it an 425 XMPP-SIMPLE gateway. The XMPP server would then deliver the message 426 stanza to the XMPP-SIMPLE gateway. 428 The XMPP-SIMPLE gateway is then responsible for translating the XMPP 429 message stanza into a SIP MESSAGE request from the XMPP user to the 430 SIP user: 432 Example: XMPP user sends message (SIP transformation): 434 | MESSAGE sip:romeo@example.net SIP/2.0 435 | Via: SIP/2.0/TCP julietpc.example.com;branch=z9hG4bK776sgdkse 436 | Max-Forwards: 70 437 | From: sip:juliet@example.com;tag=49583 438 | To: sip:romeo@example.net 439 | Call-ID: Hr0zny9l3@example.com 440 | CSeq: 1 MESSAGE 441 | Content-Type: text/plain 442 | Content-Length: 37 443 | 444 | Art thou not Romeo, and a Montague? 446 The mapping of XMPP syntax elements to SIP syntax elements SHOULD be 447 as shown in the following table. (Mappings for elements not 448 mentioned are undefined.) 449 Table 3: Message syntax mapping from XMPP to SIP 451 +-----------------------------+--------------------------+ 452 | XMPP Element or Attribute | SIP Header or Contents | 453 +-----------------------------+--------------------------+ 454 | | body of MESSAGE | 455 | | Subject | 456 | | (no mapping) | 457 | from | From | 458 | id | (no mapping) | 459 | to | To | 460 | type | (no mapping) | 461 | xml:lang | Content-Language | 462 +-----------------------------+--------------------------+ 464 3.3 SIP to XMPP 466 When Romeo wants to send an instant message to Juliet, he interacts 467 with his SIP user agent, which generates a SIP MESSAGE request. The 468 syntax of the MESSAGE request is defined in [SIP-IM]. The following 469 is an example of such a request: 471 Example: SIP user sends message: 473 | MESSAGE sip:juliet@example.com SIP/2.0 474 | Via: SIP/2.0/TCP romeopc.example.com;branch=eskdgs677Kb4Ghz9 475 | Max-Forwards: 70 476 | From: sip:romeo@example.net;tag=38594 477 | To: sip:juliet@example.com 478 | Call-ID: M4spr4vdu@example.net 479 | CSeq: 1 MESSAGE 480 | Content-Type: text/plain 481 | Content-Length: 26 482 | 483 | Neither, fair saint, if either thee dislike. 485 Section 5 of [SIP-IM] stipulates that a SIP User Agent presented with 486 an im: URI should resolve it to a sip: or sips: URI. Therefore we 487 assume that the To header of a request received by a SIMPLE-XMPP 488 gateway will contain a sip: or sips: URI. The gateway SHOULD resolve 489 that address to an im: URI for SIP MESSAGE requests, then follow the 490 rules in [IMP-SRV] regarding the "_im" SRV service for the target 491 domain contained in the To header. If SRV address resolution fails 492 for the "_im" service, the gateway MAY attempt a lookup for the 493 "_xmpp-server" service as specified in [XMPP-CORE] or MAY return an 494 error to the sender (the SIP "502 Bad Gateway" error seems most 495 appropriate). If SRV address resolution succeeds, the gateway is 496 responsible for translating the request into an XMPP message stanza 497 from the SIP user to the XMPP user and returning a SIP "200 OK" 498 message to the sender: 500 Example: SIP user sends message (XMPP transformation): 502 | 504 | Neither, fair saint, if either thee dislike. 505 | 507 The mapping of SIP syntax elements to XMPP syntax elements SHOULD be 508 as shown in the following table. (Mappings for elements not 509 mentioned in the foregoing table are undefined.) 511 Table 4: Message syntax mapping from SIP to XMPP 513 +--------------------------+-----------------------------+ 514 | SIP Header or Contents | XMPP Element or Attribute | 515 +--------------------------+-----------------------------+ 516 | Call-ID | (no mapping) | 517 | Content-Language | xml:lang | 518 | CSeq | id (OPTIONAL) | 519 | From | from | 520 | Subject | | 521 | To | to | 522 | body of MESSAGE | | 523 +--------------------------+-----------------------------+ 525 Note: When transforming SIP pager-model messages, a SIMPLE-XMPP 526 gateway SHOULD specify no XMPP 'type' attribute or a 'type' attribute 527 whose value is "normal". 529 4. Presence Subscriptions 531 4.1 Overview 533 Both XMPP and presence-aware SIP systems enable entities (often but 534 not necessarily human users) to subscribe to the presence of other 535 entities. XMPP presence subscriptions are specified in [XMPP-IM]. 536 Presence subscriptions using a SIP event package for presence are 537 specified in [SIP-PRES]. 539 As described in [XMPP-IM], XMPP presence subscriptions are managed 540 using XMPP presence stanzas of type "subscribe", "subscribed", 541 "unsubscribe", and "unsubscribed". The main subscription states are 542 "none" (neither the user nor the contact is subscribed to the other's 543 presence information), "from" (the user has a subscription from the 544 contact), "to" (the user has a subscription to the contact's presence 545 information), and "both" (both user and contact are subscribed to 546 each other's presence information). 548 As described in [SIP-PRES], SIP presence subscriptions are managed 549 through the use of SIP SUBSCRIBE events sent from a SIP user agent to 550 an intended recipient who is most generally referenced by an Instant 551 Message URI of the form but who may be referenced 552 by a SIP or SIPS URI of the form or 553 . 555 The subscription models underlying XMPP and SIP are quite different. 556 For instance, XMPP presence subscriptions are long-lived (indeed 557 permanent if not explicitly cancelled), whereas SIP presence 558 subscriptions are short-lived (the default time to live of a SIP 559 presence subscription is 3600 seconds, as specified in Section 6.4 of 560 [SIP-PRES]). These differences are addressed below. 562 4.2 XMPP to SIP 564 An XMPP user initiates a subscription by sending a subscription 565 request to another entity (conventionally called a "contact"), which 566 request the contact either accepts or declines. If the contact 567 accepts the request, the user will have a subscription to the 568 contact's presence information until (1) the user unsubscribes or (2) 569 the contact cancels the subscription. The subscription request is 570 encapsulated in a presence stanza of type "subscribe": 572 Example: XMPP user subscribes to SIP contact: 574 | 578 Upon receiving such a stanza, the XMPP server to which Juliet has 579 connected needs to determine the identity of the foreign domain, 580 which it does by performing one or more [SRV] lookups. For presence 581 stanzas, the order of lookups recommended by [XMPP-IM] is to first 582 try the "_xmpp-server" service as specified in [XMPP-CORE] and to 583 then try the "_pres" service as specified in [IMP-SRV]. Here we 584 assume that the first lookup will fail but that the second lookup 585 will succeed and return a resolution "_pres._simple.example.net.", 586 since we have already assumed that the example.net hostname is 587 running a SIP presence service. 589 Once the XMPP server has determined that the foreign domain is 590 serviced by a SIMPLE server, it must determine how to proceed. We 591 here assume that the XMPP server contains or has available to it an 592 XMPP-SIMPLE gateway. The XMPP server would then deliver the presence 593 stanza to the XMPP-SIMPLE gateway. 595 The XMPP-SIMPLE gateway is then responsible for translating the XMPP 596 subscription request into a SIP SUBSCRIBE request from the XMPP user 597 to the SIP user: 599 Example: XMPP user subscribes to SIP contact (SIP transformation): 601 | SUBSCRIBE sip:romeo@example.net SIP/2.0 602 | Via: SIP/2.0/TCP simple.example.net;branch=z9hG4bKna998sk 603 | From: ;tag=ffd2 604 | To: 605 | Call-ID: l04th3s1p@example.com 606 | Event: presence 607 | Max-Forwards: 70 608 | CSeq: 123 SUBSCRIBE 609 | Contact: 610 | Accept: application/pidf+xml 611 | Expires: 3600 612 | Content-Length: 0 614 The SIP user then SHOULD send a response indicating acceptance of the 615 subscription request: 617 Example: SIP accepts subscription request: 619 | SIP/2.0 200 OK 620 | Via: SIP/2.0/TCP simple.example.net;branch=z9hG4bKna998sk 621 | From: 622 | To: ;tag=ffd2 623 | Call-ID: l04th3s1p@example.com 624 | CSeq: 123 SUBSCRIBE 625 | Contact: 626 | Expires: 3600 627 | Content-Length: 0 629 The XMPP-SIMPLE gateway SHOULD transform the 200 OK into a presence 630 stanza of type "subscribed": 632 Example: XMPP user receives acknowledgement from SIP contact: 634 | 638 The SIP user also SHOULD immediately send a presence notification to 639 the XMPP user (see Section 5). 641 Note: It is the responsibility of the XMPP-SIMPLE gateway to set the 642 value of the Expires header and to periodically renew the 643 subscription on the SIMPLE side of the gateway so that the 644 subscription appears to be permanent to the XMPP user. 646 At any time after subscribing, the XMPP user may unsubscribe from the 647 contact's presence. This is done by sending a presence stanza of 648 type "unsubscribe": 650 Example: XMPP user unsubscribes from SIP contact: 652 | 656 The XMPP-SIMPLE gateway is responsible for translating the 657 unsubscribe command into a SIP SUBSCRIBE request with the Expires 658 header set to a value of zero: 660 Example: XMPP user unsubscribes from SIP contact (SIP 661 transformation): 663 | SUBSCRIBE sip:romeo@example.net SIP/2.0 664 | Via: SIP/2.0/TCP simple.example.net;branch=z9hG4bKna998sk 665 | From: ;tag=ffd2 666 | To: ;tag=xfg9 667 | Call-ID: 1ckm32@example.com 668 | Event: presence 669 | Max-Forwards: 70 670 | CSeq: 789 SUBSCRIBE 671 | Contact: 672 | Accept: application/pidf+xml 673 | Expires: 0 674 | Content-Length: 0 676 Upon sending the transformed unsubscribe, the XMPP-SIMPLE gateway 677 SHOULD a presence stanza of type "unsubscribed" to the XMPP user: 679 Example: XMPP user receives unsubscribed notification: 681 | 685 4.3 SIP to XMPP 687 A SIP user initiates a subscription to a contact's presence 688 information by sending a SIP SUBSCRIBE request to the contact. The 689 following is an example of such a request: 691 Example: SIP user subscribes to XMPP contact: 693 | SUBSCRIBE sip:juliet@example.com SIP/2.0 694 | Via: SIP/2.0/TCP simple.example.net;branch=z9hG4bKna998sk 695 | From: ;tag=ffd2 696 | To: ;tag=xfg9 697 | Call-ID: 4wcm0n@example.net 698 | Event: presence 699 | Max-Forwards: 70 700 | CSeq: 263 SUBSCRIBE 701 | Contact: 702 | Accept: application/pidf+xml 703 | Content-Length: 0 705 Upon receiving such a request, a SIMPLE-XMPP gateway is responsible 706 for translating it into an XMPP subscription request from the SIP 707 user to the XMPP user: 709 Example: SIP user subscribes to XMPP contact (XMPP transformation): 711 | 715 Notice that the Expires header was not included in the SUBSCRIBE 716 request; this means that the default value of 3600 (i.e., 3600 717 seconds = 1 hour) applies. 719 It is the responsibility of the SIMPLE-XMPP gateway to properly 720 handle the difference between short-lived SIP presence subscriptions 721 and long-lived XMPP presence subscriptions. The gateway has two 722 options when the SIP user's subscription expires: 724 o Cancel the subscription (i.e., treat it as temporary) and send an 725 XMPP presence stanza of type "unsubscribe" to the XMPP contact; 726 this honors the SIP semantic but will seem rather odd to the XMPP 727 contact. 728 o Maintain the subscription (i.e., treat it as long-lived) and send 729 (1) a SIP NOTIFY request to the SIP user containing a PIDF 730 document specifying that the XMPP contact now has a basic status 731 of "closed" and (2) an XMPP presence stanza of type "unavailable" 732 to the XMPP contact; this violates the letter of the SIP semantic 733 but will seem more natural to the XMPP contact. 735 Which of these options the SIMPLE-XMPP gateway chooses is up to the 736 implementation. 738 If the implementation chooses the first option, the protocol 739 generated would be as follows: 741 Example: SIP subscription expires (treated as temporary by gateway): 743 | 747 If the implementation chooses the second option, the protocol 748 generated would be as follows: 750 Example: SIP subscription expires (treated as long-lived by gateway): 752 | NOTIFY sip:192.0.2.2 SIP/2.0 753 | Via: SIP/2.0/TCP simple.example.net;branch=z9hG4bKna998sk 754 | From: ;tag=ffd2 755 | To: ;tag=xfg9 756 | Call-ID: j4s0h4vny@example.com 757 | Event: presence 758 | Max-Forwards: 70 759 | CSeq: 232 NOTIFY 760 | Contact: 761 | Content-Type: application/pidf+xml 762 | Content-Length: 194 763 | 764 | 765 | 767 | 768 | 769 | closed 770 | 771 | 772 | 774 Example: SIP subscription expires (treated as long-lived by gateway): 776 | 780 At any time, the SIP user may cancel the subscription by sending a 781 SUBSCRIBE request whose Expires header is set to a value of zero: 783 Example: SIP user cancels subscription: 785 | SUBSCRIBE sip:juliet@example.com SIP/2.0 786 | Via: SIP/2.0/TCP simple.example.net;branch=z9hG4bKna998sk 787 | From: ;tag=ffd2 788 | To: ;tag=xfg9 789 | Call-ID: 1tsn1ce@example.net 790 | Event: presence 791 | Max-Forwards: 70 792 | CSeq: 987 SUBSCRIBE 793 | Contact: 794 | Expires: 0 795 | Accept: application/pidf+xml 796 | Content-Length: 0 798 As above, upon receiving such a request, a SIMPLE-XMPP gateway is 799 responsible for doing one of the following: 801 o Cancel the subscription (i.e., treat it as temporary) and send an 802 XMPP presence stanza of type "unsubscribe" to the XMPP contact. 803 o Maintain the subscription (i.e., treat it as long-lived) and send 804 (1) a SIP NOTIFY request to the SIP user containing a PIDF 805 document specifying that the XMPP contact now has a basic status 806 of "closed" and (2) an XMPP presence stanza of type "unavailable" 807 to the XMPP contact. 809 5. Presence Notifications 811 5.1 Overview 813 Both XMPP and presence-aware SIP systems enable entities (often but 814 not necessarily human users) to send presence notifications to other 815 entities. At a minimum, the term "presence" refers to information 816 about an entity's availability for communication on a network (on/ 817 off), often supplemented by information that further specifies the 818 entity's communications context (e.g., "do not disturb"). Some 819 systems and protocols extend this notion even further and refer to 820 any relatively ephemeral information about an entity as a kind of 821 presence; categories of such "extended presence" include geographical 822 location (e.g., GPS coordinates), user mood (e.g., grumpy), user 823 activity (e.g., walking), and ambient environment (e.g., noisy). In 824 this document, we focus on the "least common denominator" of network 825 availability only, although future documents may address broader 826 notions of presence, including extended presence. 828 Presence using XMPP presence stanzas of type "available" or 829 "unavailable" is specified in [XMPP-IM]. SIP presence using a SIP 830 event package for presence is specified in [SIP-PRES]. 832 As described in [XMPP-IM], presence information about an entity is 833 communicated by means of an XML stanza sent over an XML 834 stream. In this document we will assume that such a presence stanza 835 is sent from an XMPP client to an XMPP server over an XML stream 836 negotiated between the client and the server, and that the client is 837 controlled by a human user (again, this is a simplifying assumption 838 introduced for explanatory purposes only). In general, XMPP presence 839 is sent by the user to the user's server and then broadcasted to all 840 entities who are subscribed to the user's presence information. 842 As described in [SIP-PRES], presence information about an entity is 843 communicated by means of a SIP NOTIFY event sent from a SIP user 844 agent to an intended recipient who is most generally referenced by an 845 Instant Message URI of the form but who may be 846 referenced by a SIP or SIPS URI of the form or 847 . Here again we introduce the simplifying 848 assumption that the user agent is controlled by a human user. 850 5.2 XMPP to SIP 852 When Juliet interacts with her XMPP client to modify her presence 853 information (or when her client automatically updates her presence 854 information, e.g. via an "auto-away" feature), her client generates 855 an XMPP stanza. The syntax of the stanza, 856 including required and optional elements and attributes, is defined 857 in [XMPP-IM]. The following is an example of such a stanza: 859 Example: XMPP user sends presence notification: 861 | 863 Upon receiving such a stanza, the XMPP server to which Juliet has 864 connected broadcasts it to all subscribers who are authorized to 865 receive presence notifications from Juliet. For each subscriber, 866 broadcasting the presence notification involves either delivering it 867 to a local recipient (if the hostname in the subscriber's address 868 matches one of the hostnames serviced by the XMPP server) or 869 attempting to route it to the foreign domain that services the 870 hostname in the subscriber's address. Naturally, in this document we 871 assume that the hostname is a SIP presence service hosted by a 872 separate server. As specified in [XMPP-IM], the XMPP server needs to 873 determine the identity of the foreign domain, which it does by 874 performing one or more [SRV] lookups. For presence stanzas, the 875 order of lookups recommended by [XMPP-IM] is to first try the "_xmpp- 876 server" service as specified in [XMPP-CORE] and to then try the 877 "_pres" service as specified in [IMP-SRV]. Here we assume that the 878 first lookup will fail but that the second lookup will succeed and 879 return a resolution "_pres._simple.example.net.", since we have 880 already assumed that the example.net hostname is running a SIP 881 presence service. (Note: The XMPP server may have previously 882 determined that the foreign domain is a SIMPLE server, in which case 883 it would not need to perform the SRV lookups; the caching of such 884 information is a matter of implementation and local service policy, 885 and is therefore out of scope for this document.) 887 Once the XMPP server has determined that the foreign domain is 888 serviced by a SIMPLE server, it must determine how to proceed. We 889 here assume that the XMPP server contains or has available to it an 890 XMPP-SIMPLE gateway. The XMPP server would then deliver the presence 891 stanza to the XMPP-SIMPLE gateway. 893 The XMPP-SIMPLE gateway is then responsible for translating the XMPP 894 presence stanza into a SIP NOTIFY request and included PIDF document 895 from the XMPP user to the SIP user: 897 Example: XMPP user sends presence notification (SIP transformation): 899 | NOTIFY sip:192.0.2.2 SIP/2.0 900 | Via: SIP/2.0/TCP simple.example.net;branch=z9hG4bKna998sk 901 | From: ;tag=ffd2 902 | To: ;tag=xfg9 903 | Call-ID: j4s0h4vny@example.com 904 | Event: presence 905 | Subscription-State: active;expires=599 906 | Max-Forwards: 70 907 | CSeq: 157 NOTIFY 908 | Contact: 909 | Content-Type: application/pidf+xml 910 | Content-Length: 192 911 | 912 | 913 | 915 | 916 | 917 | open 918 | 919 | 920 | 922 The mapping of XMPP syntax elements to SIP syntax elements SHOULD be 923 as shown in the following table. (Mappings for elements not 924 mentioned are undefined.) 925 Table 5: Presence syntax mapping from XMPP to SIP 927 +-----------------------------+---------------------------+ 928 | XMPP Element or Attribute | SIP Header or PIDF Data | 929 +-----------------------------+---------------------------+ 930 | stanza | "Event: presence" [1] | 931 | from | From | 932 | id | (no mapping) | 933 | to | To | 934 | type | basic status [2] | 935 | xml:lang | Content-Language | 936 | | PIDF priority for tuple | 937 | | (no mapping) | 938 | | note [3] | 939 +-----------------------------+---------------------------+ 941 Note the following regarding these mappings: 943 1. Only a presence stanza which lacks a 'type' attribute or whose 944 'type' attribute has a value of "unavailable" should be mapped by 945 an XMPP-SIMPLE gateway to a SIP NOTIFY request, since those are 946 the only presence stanzas that represent notifications. 947 2. Because the lack of a 'type' attribute indicates that an XMPP 948 entity is available for communications, the gateway SHOULD map 949 that information to a PIDF status of "open". Because a 950 'type' attribute with a value of "unavailable" indicates that an 951 XMPP entity is not available for communications, the gateway 952 SHOULD map that information to a PIDF status of 953 "closed". 954 3. The character data of the XMPP element MAY be mapped to 955 the character data of the PIDF element. 957 5.3 SIP to XMPP 959 When Romeo changes his presence, his SIP user agent generates a SIP 960 NOTIFY request. The syntax of the NOTIFY request is defined in [SIP- 961 PRES]. The following is an example of such a request: 963 Example: SIP user sends presence notification: 965 | NOTIFY sip:192.0.2.1 SIP/2.0 966 | Via: SIP/2.0/TCP simple.example.net;branch=z9hG4bKna998sk 967 | From: ;tag=ffd2 968 | To: ;tag=xfg9 969 | Call-ID: j0sj4sv1m@example.net 970 | Event: presence 971 | Subscription-State: active;expires=499 972 | Max-Forwards: 70 973 | CSeq: 8775 NOTIFY 974 | Contact: 975 | Content-Type: application/pidf+xml 976 | Content-Length: 193 977 | 978 | 979 | 981 | 982 | 983 | closed 984 | 985 | 986 | 988 Upon receiving such a request, a SIMPLE-XMPP gateway is responsible 989 for translating it into an XMPP presence stanza from the SIP user to 990 the XMPP user: 992 Example: SIP user sends presence notification (XMPP transformation): 994 | 998 The mapping of SIP syntax elements to XMPP syntax elements SHOULD be 999 as shown in the following table. (Mappings for elements not 1000 mentioned are undefined.) 1001 Table 6: Presence syntax mapping from SIP to XMPP 1003 +---------------------------+-----------------------------+ 1004 | SIP Header or PIDF Data | XMPP Element or Attribute | 1005 +---------------------------+-----------------------------+ 1006 | basic status | type [1] | 1007 | Content-Language | xml:lang | 1008 | CSeq | id (OPTIONAL) | 1009 | From | from | 1010 | priority for tuple | | 1011 | To | to | 1012 | body of MESSAGE | | 1013 +---------------------------+-----------------------------+ 1015 Note the following regarding these mappings: 1017 1. A PIDF basic status of "open" SHOULD be mapped to no 'type' 1018 attribute, and a PIDF basic status of "closed" SHOULD be mapped 1019 to a 'type' attribute whose value is "unavailable". 1021 6. Security Considerations 1023 Detailed security considerations for instant messaging and presence 1024 protocols are given in [IMP-REQS], specifically in Sections 5.1 1025 through 5.4. Detailed security considerations for XMPP are given in 1026 [XMPP-CORE]. Detailed security considerations for SIP-based 1027 messaging are given in [SIP-IM] and for SIP-based presence are given 1028 in [SIP-PRES] (see also the security considerations for the Session 1029 Initiation Protocol given in [SIP]). 1031 This document specifies methods for exchanging instant messages and 1032 presence information through a gateway that translates between SIP 1033 and XMPP. Such a gateway MUST be compliant with the minimum security 1034 requirements of the instant messaging and presence protocols for 1035 which it translates (i.e., SIP and XMPP). The introduction of 1036 gateways to the security model of instant messaging and presence 1037 specified in [IMP-REQS] introduces some new risks. In particular, 1038 end-to-end security properties (especially confidentiality and 1039 integrity) between instant messaging and presence user agents that 1040 interface through a SIMPLE-XMPP gateway can be provided only if 1041 common formats are supported. Specification of those common formats 1042 is out of scope for this document, although it is recommended to use 1043 [MSGFMT] for instant messages and [PIDF] for presence. 1045 [IMP-REQS] requires that conformant technologies shall include 1046 methods for blocking communications from unwanted addresses. Such 1047 blocking is the responsibility of conformant technology (e.g., XMPP 1048 or SIP) and is out of scope for this memo. 1050 7. Acknowledgements 1052 The authors wish to thank Nathaniel Borenstein and Rohan Mahy for 1053 suggestions and encouragement, Daniel-Constantin Mierla for earlier 1054 work on SIMPLE-XMPP interworking, and Sandeep Sharma for feedback 1055 based on implementation experience. 1057 8. References 1059 8.1 Normative References 1061 [IMP-SRV] Peterson, J., "Address Resolution for Instant Messaging 1062 and Presence", RFC 3861, August 2004. 1064 [PIDF] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, 1065 W., and J. Peterson, "Presence Information Data Format 1066 (PIDF)", RFC 3863, August 2004. 1068 [RFC822] Crocker, D., "Standard for the format of ARPA Internet 1069 text messages", STD 11, RFC 822, August 1982. 1071 [RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1072 Resource Identifiers (URI): Generic Syntax", RFC 2396, 1073 August 1998. 1075 [SIP] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1076 A., Peterson, J., Sparks, R., Handley, M., and E. 1077 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1078 June 2002. 1080 [SIP-IM] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., 1081 and D. Gurle, "Session Initiation Protocol (SIP) Extension 1082 for Instant Messaging", RFC 3428, December 2002. 1084 [SIP-PRES] 1085 Rosenberg, J., "A Presence Event Package for the Session 1086 Initiation Protocol (SIP)", RFC 3856, August 2004. 1088 [SRV] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 1089 specifying the location of services (DNS SRV)", RFC 2782, 1090 February 2000. 1092 [STRINGPREP] 1093 Hoffman, P. and M. Blanchet, "Preparation of 1094 Internationalized Strings ("STRINGPREP")", RFC 3454, 1095 December 2002. 1097 [TERMS] Bradner, S., "Key words for use in RFCs to Indicate 1098 Requirement Levels", BCP 14, RFC 2119, March 1997. 1100 [URL-GUIDE] 1101 Masinter, L., Alvestrand, H., Zigmond, D., and R. Petke, 1102 "Guidelines for new URL Schemes", RFC 2718, November 1999. 1104 [XMPP-CORE] 1105 Saint-Andre, P., "Extensible Messaging and Presence 1106 Protocol (XMPP): Core", RFC 3920, October 2004. 1108 [XMPP-IM] Saint-Andre, P., "Extensible Messaging and Presence 1109 Protocol (XMPP): Instant Messaging and Presence", 1110 RFC 3921, October 2004. 1112 8.2 Informative References 1114 [CPIM] Peterson, J., "Common Profile for Instant Messaging 1115 (CPIM)", RFC 3860, August 2004. 1117 [CPP] Peterson, J., "Common Profile for Presence (CPP)", 1118 RFC 3859, August 2004. 1120 [IDNA] Faltstrom, P., Hoffman, P., and A. Costello, 1121 "Internationalizing Domain Names in Applications (IDNA)", 1122 RFC 3490, March 2003. 1124 [IMP-MODEL] 1125 Day, M., Rosenberg, J., and H. Sugano, "A Model for 1126 Presence and Instant Messaging", RFC 2778, February 2000. 1128 [IMP-REQS] 1129 Day, M., Aggarwal, S., and J. Vincent, "Instant Messaging 1130 / Presence Protocol Requirements", RFC 2779, 1131 February 2000. 1133 [IRC] Oikarinen, J. and D. Reed, "Internet Relay Chat Protocol", 1134 RFC 1459, May 1993. 1136 [JEP-0106] 1137 Saint-Andre, P. and J. Hildebrand, "JID Escaping", JSF 1138 JEP 0106, May 2005. 1140 [MSGFMT] Klyne, G. and D. Atkins, "Common Presence and Instant 1141 Messaging (CPIM): Message Format", RFC 3862, August 2004. 1143 [MSRP] Campbell, B., "The Message Session Relay Protocol", 1144 draft-ietf-simple-message-sessions-11 (work in progress), 1145 July 2005. 1147 [SIMPLE-CPIM] 1148 Rosenberg, J. and B. Campbell, "CPIM Mapping of SIMPLE 1149 Presence and Instant Messaging", 1150 draft-ietf-simple-cpim-mapping-01 (work in progress), 1151 June 2002. 1153 [XMPP-CPIM] 1154 Saint-Andre, P., "Mapping the Extensible Messaging and 1155 Presence Protocol (XMPP) to Common Presence and Instant 1156 Messaging (CPIM)", RFC 3922, October 2004. 1158 Authors' Addresses 1160 Peter Saint-Andre 1161 Jabber Software Foundation 1162 P.O. Box 1641 1163 Denver, CO 80201 1164 US 1166 Email: stpeter@jabber.org 1168 Avshalom Houri 1169 IBM 1170 Building 18/D, Kiryat Weizmann Science Park 1171 Rehovot 76123 1172 Israel 1174 Email: avshalom@il.ibm.com 1176 Joe Hildebrand 1177 Jabber, Inc. 1178 1899 Wynkoop Street, Suite 600 1179 Denver, CO 80202 1180 US 1182 Email: jhildebrand@jabber.com 1184 Intellectual Property Statement 1186 The IETF takes no position regarding the validity or scope of any 1187 Intellectual Property Rights or other rights that might be claimed to 1188 pertain to the implementation or use of the technology described in 1189 this document or the extent to which any license under such rights 1190 might or might not be available; nor does it represent that it has 1191 made any independent effort to identify any such rights. Information 1192 on the procedures with respect to rights in RFC documents can be 1193 found in BCP 78 and BCP 79. 1195 Copies of IPR disclosures made to the IETF Secretariat and any 1196 assurances of licenses to be made available, or the result of an 1197 attempt made to obtain a general license or permission for the use of 1198 such proprietary rights by implementers or users of this 1199 specification can be obtained from the IETF on-line IPR repository at 1200 http://www.ietf.org/ipr. 1202 The IETF invites any interested party to bring to its attention any 1203 copyrights, patents or patent applications, or other proprietary 1204 rights that may cover technology that may be required to implement 1205 this standard. Please address the information to the IETF at 1206 ietf-ipr@ietf.org. 1208 Disclaimer of Validity 1210 This document and the information contained herein are provided on an 1211 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1212 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1213 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1214 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1215 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1216 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1218 Copyright Statement 1220 Copyright (C) The Internet Society (2005). This document is subject 1221 to the rights, licenses and restrictions contained in BCP 78, and 1222 except as set forth therein, the authors retain all their rights. 1224 Acknowledgment 1226 Funding for the RFC Editor function is currently provided by the 1227 Internet Society.