idnits 2.17.1 draft-saintandre-xmpp-msrp-00.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 19. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1294. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1305. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1312. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1318. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. 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 IETF Trust Copyright Line does not match the current year == Line 1201 has weird spacing: '...ssaging and...' == 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). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Upon receiving such stanza completing the session negotiation, the XMPP server MUST not send any confirmation to the SIP side. -- 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 (November 11, 2007) is 6011 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3920 (ref. 'XMPP') (Obsoleted by RFC 6120) ** Obsolete normative reference: RFC 3921 (ref. 'XMPP-IM') (Obsoleted by RFC 6121) -- Obsolete informational reference (is this intentional?): RFC 4566 (ref. 'SDP') (Obsoleted by RFC 8866) Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 9 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 XMPP Standards Foundation 4 Intended status: Informational E. Gavita 5 Expires: May 14, 2008 N. Hossain 6 S. Loreto 7 Ericsson 8 November 11, 2007 10 Interworking between the Extensible Messaging and Presence Protocol 11 (XMPP) and the Message Session Relay Protocol (MSRP) 12 draft-saintandre-xmpp-msrp-00.txt 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on May 14, 2008. 39 Copyright Notice 41 Copyright (C) The IETF Trust (2007). 43 Abstract 45 This document defines a bidirectional protocol mapping for use by 46 gateways that enable the exchange of messages in the context of a 47 chat session between a system that implements the Extensible 48 Messaging and Presence Protocol (XMPP) and a system that implements 49 the Session Initiation Protocol (SIP), specifically for the latter 50 session-mode messages that use the Message Session Relay Protocol 51 (MSRP). 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.2. Architectural Assumptions . . . . . . . . . . . . . . . . 4 58 1.3. Connection Maintenance . . . . . . . . . . . . . . . . . . 5 59 1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 60 1.5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 6 61 2. Message Sessions . . . . . . . . . . . . . . . . . . . . . . . 6 62 2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 2.2. XMPP Formal Chat Session to MSRP . . . . . . . . . . . . . 7 64 2.2.1. Initiating a Formal Session . . . . . . . . . . . . . 8 65 2.2.2. Accepting a Formal Session . . . . . . . . . . . . . . 11 66 2.2.3. Terminating a Formal Session . . . . . . . . . . . . . 14 67 2.2.4. Canceling the Negotiation . . . . . . . . . . . . . . 16 68 2.2.5. Rejecting a Formal Session . . . . . . . . . . . . . . 17 69 2.3. XMPP Informal Session to MSRP . . . . . . . . . . . . . . 18 70 2.4. MSRP to XMPP formal session . . . . . . . . . . . . . . . 18 71 2.4.1. Initiating a Session . . . . . . . . . . . . . . . . . 19 72 2.4.2. Accepting a Session . . . . . . . . . . . . . . . . . 22 73 2.4.3. Completing the Transaction . . . . . . . . . . . . . . 23 74 2.4.4. Send a Message . . . . . . . . . . . . . . . . . . . . 23 75 2.4.5. Terminating a Session . . . . . . . . . . . . . . . . 24 76 2.4.6. Cancel the transaction . . . . . . . . . . . . . . . . 26 77 2.4.7. Rejecting a transaction . . . . . . . . . . . . . . . 27 78 2.5. MSRP to an XMPP Informal Session . . . . . . . . . . . . . 28 79 3. Security Considerations . . . . . . . . . . . . . . . . . . . 28 80 4. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 81 4.1. Normative References . . . . . . . . . . . . . . . . . . . 28 82 4.2. Informative References . . . . . . . . . . . . . . . . . . 29 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 84 Intellectual Property and Copyright Statements . . . . . . . . . . 31 86 1. Introduction 88 1.1. Overview 90 Within the IETF, work on instant messaging has proceeded on two 91 technologies that conform to the requirements defined in [IMP-REQS]: 93 o The Extensible Messaging and Presence Protocol [XMPP], which 94 consists of a formalization of the core XML streaming protocols 95 developed originally by the Jabber open-source community; the 96 relevant specifications are [XMPP] for the XML streaming layer and 97 [XMPP-IM] for basic presence and instant messaging extensions, 98 including both single messages via XMPP stanzas of type 99 "normal" and messaging sessions via XMPP stanzas of 100 type "chat". 101 o Various extensions to the Session Initiation Protocol [SIP] for 102 instant messaging and presence, as developed within the SIP for 103 Instant Messaging and Presence Leveraging Extensions (SIMPLE) 104 Working Group; the relevant specifications for instant messaging 105 are [SIP-MSG] for single messages (also called "pager-mode" 106 messaging) and [MSRP] for messaging sessions (also called 107 "session-mode" messaging). 109 Because both of these technologies have been implemented and deployed 110 over the Internet, it is important to clearly define bidirectional 111 mappings between them. Work on such mappings began with 112 [XMPP-SIMPLE], which defines mappings for addresses, presence, and 113 single messages. This document extends that work by defining a 114 mapping for one-to-one chat or messaging sessions. 116 Both XMPP and SIP/SIMPLE technologies enable end users to send 117 "instant messages" to other end users. The term "instant message" 118 usually refers to messages sent between two end-users for delivery in 119 close to real time (rather than messages that are stored and 120 forwarded to the intended recipient upon request). Generally, there 121 are three kinds of instant messages: 123 1. Single messages, which are sent from the sender to the recipient 124 outside the context of any one-to-one chat session or multi-user 125 text conference. The message is immediately delivered and not 126 stored in an inbox. In XMPP a single message is a 127 stanza of type "normal" as specified in [XMPP-IM]. In SIP/SIMPLE 128 a single message is sent via the MESSAGE method as specified in 129 [MSRP]. 130 2. One-to-one chat messages, which are sent from the sender to the 131 recipient (i.e., one-to-one) in the context of a "chat session" 132 between the two entities. In XMPP a chat message is a 133 stanza of type "chat". In SIP/SIMPLE a chat message is sent 134 using an MSRP session. 135 3. Groupchat messages, which are sent from a sender to multiple 136 recipients (i.e., 2 or more) in the context of a "multi-user chat 137 session" or "text conference". In XMPP a groupchat message is a 138 stanza of type "groupchat" that is reflected from the 139 sender to multiple recipients by a multi-user chat service as 140 defined in [XEP-0045]. In SIP/SIMPLE a groupchat message is 141 reflected from the sender to multiple recipients by a conference 142 server that uses MSRP to handle groupchat sessions. 144 This document only covers the scenario #2 above for converting XMPP 145 messages of type "chat" to their corresponding SIP INVITE - MSRP 146 message types on the SIP/SIMPLE side. 148 As in [XMPP-SIMPLE], the approach taken here is to directly map 149 syntax and semantics from one protocol to another. One-to-one chat 150 sessions using XMPP message stanzas of type "chat" are specified in 151 [XMPP-IM], and a method for formally negotiating such a session is 152 specified in [XEP-0155]. One-to-one chat sessions using the SIP 153 MESSAGE method, the SIP INVITE method, and the Message Session Relay 154 Protocol (MSRP) are specified in [SIP-MSG] and [MSRP]. In 155 particular, this document defines a mapping between XMPP chat 156 sessions (as specified in [XMPP-IM] and [XEP-0155]) and the Message 157 Session Relay Protocol (as specified in [MSRP]). 159 1.2. Architectural Assumptions 161 In this section we remind the reader of the Architectural Assumptions 162 already presented in [XMPP-SIMPLE], with some small changes necessary 163 to support the MSRP scenario. 165 XMPP IM technologies consist of three element types: Clients, Servers 166 and Gateways. Each client can source and sink messages. Each Server 167 relays messages between Clients and from/to Gateways and handles 168 presence information. The Gateway provides transformations between 169 XMPP and other IM protocols. 171 SIP/SIMPLE technologies employ four element types: Clients, Proxies, 172 Presence Servers and Gateways. Each Client can source and sink 173 messages. A Proxy server relays messages between Clients and/or 174 Gateways. SIMPLE defines separable Presence Servers to maintain 175 presence about Client users. Gateways provide transformations 176 between SIMPLE and other IM protocols. 178 Protocol mapping between XMPP and SIP SIMPLE may occur in a number of 179 different entities, depending on the architecture of messaging 180 deployments. For instance, protocol translation could occur within a 181 multi-protocol server, within a multi-protocol client, or within a 182 gateway that acts as a dedicated protocol translator. This document 183 assumes that the protocol translation will occur within a gateway. 184 Specifically, we assume that the protocol translation will occur 185 within an "XMPP-to-MSRP gateway" that translates XMPP syntax and 186 semantics on behalf of an XMPP service when communicating with SIP 187 SIMPLE services and/or within an "MSRP-to-XMPP gateway" that 188 translates SIP syntax and semantics on behalf of a SIP SIMPLE service 189 when communicating with XMPP services. 191 We further assume that protocol translation will occur within a 192 gateway in the source domain, so that messages and presence 193 information generated by the user of an XMPP service will be 194 translated by a gateway within the trust domain of that XMPP service, 195 and messages and presence information generated by the user of an 196 MSRP service will be translated by a gateway within the trusted 197 domain of that MSRP service. 199 An architectural diagram for a typical gateway deployment is shown 200 below, where the entities have the following significance and the "#" 201 character is used to show the boundary of a trusted domain: 203 o juliet@example.com -- an XMPP user. 204 o example.com -- a XMPP service. 205 o x2m.example.com -- an XMPP-to-MSRP gateway. 206 o romeo@example.net -- an MSRP user. 207 o example.net -- an MSRP service. 208 o m2x.example.net -- an MSRP-to-XMPP gateway. 210 ##################################################################### 211 # # # 212 # +-- m2x.example.net---#------------- example.com # 213 # | # | | # 214 # example.net------------------#--- x2m.example.com | # 215 # | # | # 216 # | # | # 217 # romeo@example.net # juliet@example.com # 218 # # # 219 ##################################################################### 221 1.3. Connection Maintenance 223 XMPP makes use of long-lived TCP connections. If mobility affecting 224 Layer 3 causes a dropped connection, the connection must be re- 225 established. If mobility preserves the IP address, the TCP 226 connection will be dropped. Any TLS session and SASL associations 227 must be re-established if the TCP connection is dropped. XMPP binds 228 directly to TCP in the core specification, so the TCP session must 229 remain open for the entire duration of the chat/conversation. The 230 XMPP Standards Foundation does define protocol extensions enabling 231 transport of XMPP traffic over HTTP (refer to [XEP-0124] and 232 [XEP-0206]), so that individual messages are carried using HTTP and 233 are more robust in environments such as mobile networks, allowing for 234 better recovery if a TCP session is broken. 236 SIMPLE is similar when using MSRP. The Message Session Relay 237 Protocol [MSRP] is a protocol for transmitting instant messages (IM) 238 in the context of a session. The protocol specification describes 239 how the session can be negotiated and established with an offer or 240 answer [OFFER] using the Session Description Protocol [SDP]. In 241 SIMPLE, this exchange is carried using SIP as the signaling protocol. 242 After the TCP connection is established, if it fails for any reason, 243 then an MSRP endpoint MAY choose to re-create such session using a 244 new SDP exchange in a SIP re-INVITE. SIMPLE also uses MESSAGE 245 request for transporting instant messaging outside the context of a 246 session. The MESSAGE request is sent inside the signaling path 247 without establishing any dedicate connection. 249 1.4. Terminology 251 This document inherits terminology from [MSRP], [SIP], [XMPP], and 252 [XMPP-IM]. 254 The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 255 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 256 RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be 257 interpreted as described in [TERMS]. 259 1.5. Acknowledgements 261 Some text in this document was borrowed from [XMPP-SIMPLE] and from 262 [XEP-0155]. 264 2. Message Sessions 266 2.1. Overview 268 The traditional model for one-to-one chat "session" in Jabber/XMPP is 269 for a user to simply send a message to a contact with a thread ID, 270 but without any formal negotiation of session parameter. 272 This informal approach to session initiation in XMPP can be mapped 273 both to SIP pager-mode messaging using the SIP MESSAGE method (as 274 documented in [XMPP-SIMPLE]) and to a MSRP chat session. How the 275 Gateway chooses to map the XMPP chat session in the SIP side is a 276 matter of the implementation. 278 However, in XMPP it also possibile to formally request a chat session 279 and negotiate its parameters (e.g., security, privacy, message 280 logging) before beginning the session. The protocol for doing so is 281 defined in [XEP-0155]. In this case, the XMPP chat session should be 282 translated into a MSRP session. 284 This document covers the mapping of both informal and formally- 285 negotiated XMPP chat session into a MSRP session. 287 2.2. XMPP Formal Chat Session to MSRP 289 XMPP Protocol offers two ways an XMPP user can initiate a 1-1 chat: 290 the first approach doesn't establish a session (this method is 291 referred to the "informal session" approach); the second approach 292 instead involves explicit negotiation of a session (this method is 293 referred to the "formal session" approach). 295 This section describes how to map an XMPP "formal session" to an MSRP 296 session. 298 The XMPP formal session is based on the protocol described in 299 [XEP-0155], which enable the initiation, renegotiation, and 300 termination of a format chat session on the XMPP side. This approach 301 maps to the semantic of the SIP INVITE and BYE methods. 303 XMPP User X2M GW SIP User 304 | | | 305 |(F1) (XMPP) Stanza session request | 306 |------------------------->| | 307 | |(F2) (SIP) INVITE | 308 | |------------------------->| 309 | |(F3) (SIP) 200 OK | 310 | |<-------------------------| 311 |(F4) (XMPP) Stanza session acceptance | 312 |<-------------------------| | 313 | |(F5) (SIP) ACK | 314 | |------------------------->| 315 |(F6) (XMPP) Stanza session completion | 316 |------------------------->| | 317 | |(F7) (MSRP) SEND | 318 | |------------------------->| 319 |(F8) (XMPP) Stanza session termination | 320 |------------------------->| | 321 | |(F9) (SIP) BYE | 322 | |------------------------->| 323 | |(F10) (SIP) 200 OK | 324 | |<-------------------------| 325 |(F11) (XMPP) Stanza acknoledgment | 326 | session termination | 327 |<-------------------------| | 329 2.2.1. Initiating a Formal Session 331 When the XMPP user ("Juliet") wants to initiate a negotiated session 332 with a SIP user ("Romeo"), she sends a stanza to Romeo 333 containing a child qualified by the 334 'http://jabber.org/protocol/feature-neg' namespace. The 335 stanza must not contain a stanza type should be "normal". The stanza must contain a 338 element for tracking purposes (where the newly-generated 339 ThreadID is unique to the proposed session). The encapsulated data 340 form shall contain a FORM_TYPE field whose type is "hidden" and whose 341 value is "urn:xmpp:ssn"; it must also contain a boolean field named 342 "accept". 344 The XMPP user may request a session with a specific resource of the 345 contact. However in this document the resource identifier will be 346 ignored and discarded for cross-system interworking. 348 Example: (F1) Juliet starts a formal session: 350 353 711609sa 354 355 356 Open chat with Juliet? 357 358 urn:xmpp:ssn 359 360 361 true 362 363 364 366 en 367 368 369 370 371 372 374 Upon receiving such a session request, the XMPP server to which 375 Juliet has authenticated attempts to deliver the request to a local 376 user or attempts to route the request to the foreign domain that 377 services the hostname in the 'to' attribute. Naturally, in this 378 document we assume that the hostname in the 'to' attribute is an IM- 379 aware SIP service hosted by a separate server. 381 As specified in [XMPP-IM], the XMPP server needs to determine the 382 identity of the foreign domain, which it does by performing one or 383 more [DNS-SRV] lookups. For message stanzas, the order of lookups 384 recommended by [XMPP-IM] is to first try the "_xmpp-server" service 385 as specified in [XMPP] and to then try the "_im" service as specified 386 in [IMP-SRV]. Here we assume that the first lookup will fail but 387 that the second lookup will succeed and return a resolution 388 "_im._simple.example.net.", since we have already assumed that the 389 example.net hostname is running a SIP instant messaging service. 390 (Note: The XMPP server may have previously determined that the 391 foreign domain is a SIMPLE server, in which case it would not need to 392 perform the SRV lookups; the caching of such information is a matter 393 of implementation and local service policy, and is therefore out of 394 scope for this document.) 395 Once the XMPP server has determined that the foreign domain is 396 serviced by a SIMPLE server, it must determine how to proceed. We 397 here assume that the XMPP server contains or has available to it an 398 XMPP-MSRP gateway. The XMPP server would then deliver the message 399 stanza to the XMPP-MSRP gateway. 401 The XMPP-MSRP gateway is then responsible for translating the XMPP 402 session into an MSRP session. 404 Example: (F2) Juliet starts a formal session (SIP transformation): 406 INVITE sip:romeo@example.net SIP/2.0 407 To: 408 From: ;tag=786 409 Subject: Open chat with Juliet? 410 Call-ID: 711609sa 411 Content-Type: application/sdp 413 c=IN IP4 x2m.example.com 414 m=message 7654 TCP/MSRP * 415 a=accept-types:text/plain 416 a=lang:en 417 a=lang:it 418 a=path:msrp://x2m.example.com:7654/jshA7weztas;tcp 420 There is no direct mapping for the MSRP URIs. In fact MSRP URIs 421 identify a session of instant message at a particular device; they 422 are ephemeral and have not meaning outside the scope of that session. 423 The authority component of the MSRP URI MUST contain the XMPP-MSRP 424 gateway hostname or numeric IP address and an explicit port number. 426 Native XMPP supports text (i.e., UTF-8) only, so the "accept-types" 427 attribute that follows an MSRP media line MUST indicate text/plain as 428 the only media-type that is acceptable to the endpoint. 430 As specified in [XMPP-SIMPLE], the mapping of XMPP syntax elements to 431 SIP and SDP syntax elements SHOULD be as shown in the following 432 table. (Mappings for elements not mentioned are undefined). 434 Table 1: Message syntax mapping from XMPP to SIP/SDP 436 +-----------------------------+-----------------------------+ 437 | XMPP Element or Attribute | SIP Header or SDP Contents | 438 +-----------------------------+-----------------------------+ 439 | | Call-ID | 440 | from | From | 441 | to | To | 442 | | Subject | 443 | xml:lang | a=lang:<language tag> | 444 | - | a=accept-types:text/plain | 445 +-----------------------------+-----------------------------+ 447 2.2.2. Accepting a Formal Session 449 The SIP user agent Romeo receiving the SIP invitation, containing an 450 offered session description that includes a session of MSRP, accepts 451 the invitation and includes an answer session description that 452 acknowledges the choice of media. 454 Example: (F3) Romeo accepts the request 456 SIP/2.0 200 OK 457 To: <sip:romeo@example.net>;tag=087js 458 From: <sip:juliet@example.com>;tag=786 459 Call-ID: 711609sa 460 Content-Type: application/sdp 462 c=IN IP4 example.net 463 m=message 12763 TCP/MSRP * 464 a=accept-types:text/plain 465 a=lang:it 466 a=path:msrp://example.net:12763/kjhd37s2s20w2a;tcp 468 Upon receiving such a response, the MSRP-XMPP gateway SHOULD remember 469 that this is a response to a SIP transaction related to an XMPP-MSRP 470 translation. The gateway is responsible for translating the response 471 into an XMPP message stanza and deliver it from the SIP user back to 472 the XMPP user deliver. 474 The MSRP-XMPP gateway MUST include in the response translation values 475 for all the fields that the XMPP request indicated are required. 477 Example: (F4) Romeo accepts the request (XMPP translation) 479 <message type='normal' 480 from='romeo@example.net' 481 to='juliet@example.com'> 482 <thread>711609sa</thread> 483 <feature xmlns='http://jabber.org/protocol/feature-neg'> 484 <x xmlns='jabber:x:data' type='submit'> 485 <field var='FORM_TYPE'> 486 <value>urn:xmpp:ssn</value> 487 </field> 488 <field var='accept'><value>true</value></field> 489 <field var='language'><value>it</value></field> 490 </x> 491 </feature> 492 </message> 494 The gateway MUST also send a SIP ACK to the SIP user. 496 Example: (F5) The GW sends the ACK to Romeos UA: 498 ACK sip:romeo@example.com SIP/2.0 499 To: <sip:romeo@example.net>;tag=087js 500 From: <sip:juliet@example.com>;tag=786 501 Call-ID: 711609sa 503 If Romeo accepted the session Juliet MUST either complete or cancel 504 the stanza session negotiation. The user's client SHOULD verify that 505 the selected values of the fields are acceptable before completing 506 the stanza session negotiation -- and confirming that the session is 507 open -- by replying with the form 'type' attribute set to 'result'. 508 The form MUST contain the FORM_TYPE field and the "accept" field set 509 to "1" or "true". The user MAY include other content "e.g., a 510 <body/> element in the confirmation stanza: 512 Example: (F6) Juliet completes negotiation, confirms session is open 513 and send a message. 515 <message type='normal' 516 from='juliet@example.com' 517 to='romeo@example.net'> 518 <thread>711609sa</thread> 519 <feature xmlns='http://jabber.org/protocol/feature-neg'> 520 <x xmlns='jabber:x:data' type='result'> 521 <field var='FORM_TYPE'> 522 <value>urn:xmpp:ssn</value> 523 </field> 524 <field var='accept'><value>true</value></field> 525 </x> 526 </feature> 527 </message> 529 Upon receiving such stanza completing the session negotiation, the 530 XMPP server MUST not send any confirmation to the SIP side. 532 The XMPP-MSRP gateway must create a transaction identifier and use 533 this and the SEND method to create an MSRP request start line. 535 The XMPP 'id' attribute is not required in the protocol and there is 536 not a way to enforce its use for messages. It is RECOMMENDED to add 537 it as a negotiable item in the XEP-0155, however it may not be 538 present within the <message/> stanza, in this case the XMPP-MSRP MUST 539 generate a new unique Message-ID. 541 Note: If the XMPP user has not explicitly requested message receipts 542 during the negotiation, it is RECOMMENDED that the XMPP-MSRP inserts 543 a Failure-Report header field value of "no" during the creation of a 544 SEND request. The XMPP user can include the requested for message 545 receipts using the Message Receipts XMPP protocol extension 546 [XEP-0184]. 548 As specified in [XMPP-SIMPLE], the mapping of XMPP syntax elements to 549 MSRP syntax elements SHOULD be as shown in the following table. 550 (Mappings for elements not mentioned are undefined). 552 Table 2: Message syntax mapping from XMPP Message to MSRP 554 +-----------------------------+-----------------------------+ 555 | XMPP Element or Attribute | MSRP Header | 556 +-----------------------------+-----------------------------+ 557 | to | To-Path | 558 | from | From-Path | 559 | <body/> | body of the SEND request | 560 | - | Content-Type: text/plain | 561 | id | Message-ID | 562 +-----------------------------+-----------------------------+ 564 Upon receiving the SEND request, if the request either contains a 565 Failure-Report header field value of "yes" or does not contain a 566 Failure-Report header at all, Alice's client MUST immediately 567 generate and send a response. 569 MSRP d93kswow 200 OK 570 To-Path: msrp://x2m.example.com:7654/jshA7weztas;tcp 571 From-Path: msrp://example.net:12763/kjhd37s2s20w2a;tcp 572 -------d93kswow$ 574 The XML character data of an XMPP message is not limited by the 575 protocol, but is sometimes limited in deployment. However messages 576 sent using MSRP can be delivered in several SEND requests, so when 577 the XMPP-MSRP gateway receives a message longer then 2048, it is 578 STRONGLY RECOMMENDED it delivers this message using as few chunks (at 579 least 2048 octets long) as possible. 581 2.2.3. Terminating a Formal Session 583 If Juliet decides to terminate the negotiated chat session, her 584 client sends a <message/> stanza to Romeo containing a data form of 585 type "submit". The <message/> stanza MUST contain a <thread/> 586 element with the same XML character data as the original initiation 587 request. The data form containing a boolean field named "terminate" 588 set to a value of "1" or "true". 590 Example: (F8) Juliet terminates the chat session 592 <message type='normal' 593 from='juliet@example.com' 594 to='romeo@example.net'> 595 <thread>711609sa</thread> 596 <feature xmlns='http://jabber.org/protocol/feature-neg'> 597 <x xmlns='jabber:x:data' type='submit'> 598 <field var='FORM_TYPE'> 599 <value>urn:xmpp:ssn</value> 600 </field> 601 <field var='terminate'><value>1</value></field> 602 </x> 603 </feature> 604 </message> 606 Upon receiving such stanza terminating the chat session, the gateway 607 terminates the SIP session by sending a SIP BYE to tear down the MSRP 608 session with Romeo's client. Romeo's SIP client then responds with a 609 200 OK. 611 Example: (F9) Juliet terminates the chat session (SIP translation) 613 BYE romeo@example.com sip: SIP/2.0 614 Max-Forwards: 70 615 From: <sip:juliet@example.com>;tag=786 616 To: <sip:romeo@example.net>;tag=087js 617 Call-ID: 711609sa 618 Cseq: 1 BYE 619 Content-Length: 0 621 Example: (F10) Romeo terminates the chat session 623 SIP/2.0 200 OK 624 From: <sip:juliet@example.com>;tag=786 625 To: <sip:romeo@example.net>; tag=087js 626 Call-ID: 711609sa 627 CSeq: 1 BYE 628 Content-Length: 0 630 Upon receiving the 200 OK, the GW acknowledges the termination of the 631 chat session on the XMPP side by sending a <message/> containing a 632 data form of type "result", and the value of the "terminate" field 633 set to "1" or "true". The client must mirror the <thread/> value it 634 received. 636 Example: (F11) Romeo terminates the chat session (XMPP translation) 638 <message type='normal' 639 from='romeo@example.net' 640 to=='juliet@example.com'> 641 <thread>711609sa</thread> 642 <feature xmlns='http://jabber.org/protocol/feature-neg'> 643 <x xmlns='jabber:x:data' type='result'> 644 <field var='FORM_TYPE'> 645 <value>urn:xmpp:ssn</value> 646 </field> 647 <field var='terminate'><value>1</value></field> 648 </x> 649 </feature> 650 </message> 652 2.2.4. Canceling the Negotiation 654 XMPP User X2M GW SIP User 655 | | | 656 |(F1) (XMPP) Stanza session request | 657 |------------------------->| | 658 | |(F2) (SIP) INVITE | 659 | |------------------------->| 660 | |(F3) (SIP) 200 OK | 661 | |<-------------------------| 662 |(F4) (XMPP) Stanza session acceptance | 663 |<-------------------------| | 664 | |(F5) (SIP) ACK | 665 | |------------------------->| 666 |(F6) (XMPP) Stanza session canceling | 667 |------------------------->| | 668 | |(F7) (SIP) BYE | 669 | |------------------------->| 670 | |(F8) (SIP) 200 OK | 671 | |<-------------------------| 673 If Romeo accepted the session, but Juliet decides to cancel the 674 stanza session negotiation, the client must reply with a data form 675 containing the FORM_TYPE field and the "accept" field set to "0" or 676 "false": 678 Example: (F6) User cancels stanza session negotiation 680 <message type='normal' 681 from='juliet@example.com' 682 to='romeo@example.net'> 683 <thread>711609sa</thread> 684 <feature xmlns='http://jabber.org/protocol/feature-neg'> 685 <x xmlns='jabber:x:data' type='result'> 686 <field var='FORM_TYPE'> 687 <value>urn:xmpp:ssn</value> 688 </field> 689 <field var='accept'><value>0</value></field> 690 </x> 691 </feature> 692 </message> 694 Upon receiving such stanza canceling the session negotiation, the 695 XMPP-MSRP Gateway MUST send a SIP BYE. Once the XMPP-MSRP receives 696 the 200 OK, the internal session data is removed and the session is 697 officially canceled also in the gateway. 699 2.2.5. Rejecting a Formal Session 701 XMPP User X2M GW SIP User 702 | | | 703 |(F1) (XMPP) Stanza session request | 704 |------------------------->| | 705 | |(F2) (SIP) INVITE | 706 | |------------------------->| 707 | |(F3) (SIP) 4xx/6xx | 708 | |<-------------------------| 709 |(F4) (XMPP) Stanza session decline | 710 |<-------------------------| | 712 A common scenario occurs when the SIP UA is currently not willing or 713 able to accept a formal session. The SIP UA declining an offer 714 contained in an INVITE SHOULD return a 4xx or a 6xx response. Such 715 response SHOULD include a Warning header field value explaining why 716 the offer was rejected. 718 Upon receiving the error response for the SIP INVITE, the XMPP-MSRP 719 GW will send back a "Session Reject" message back to the XMPP Client. 720 The data form MUST contain the FORM_TYPE field and the "accept" field 721 set to "0" or "false". It is reccomended that the form does not 722 contain any other field even if the request indicated they are 723 required. The client MAY include a reason in the <body/> child of 724 the <message/> stanza. 726 The content of the Warning header field present in the SIP response 727 SHOULD be copied in the <body/> child of the <message/> stanza. If 728 the Warning header it is not present then the descriptive phrase of 729 the SIP response can be used. 731 Example: (F4) User declines offer and specifies reason 733 <message type='normal' 734 from='romeo@example.net' 735 to='juliet@example.com'> 736 <thread>711609sa</thread> 737 <feature xmlns='http://jabber.org/protocol/feature-neg'> 738 <x xmlns='jabber:x:data' type='submit'> 739 <field var='FORM_TYPE'> 740 <value>urn:xmpp:ssn</value> 741 </field> 742 <field var='accept'><value>0</value></field> 743 </x> 744 </feature> 745 </message> 747 2.3. XMPP Informal Session to MSRP 749 The "informal session" approach is to simply send someone a <message 750 type='chat'/> without start any session negotiation before (as 751 described in [XMPP-IM]). The XMPP "informal session" approach maps 752 very well into a SIP MESSAGE request, as described in [XMPP-SIMPLE]. 753 Although the mapping to a SIP Message is straightforward, it is also 754 possible to map an informal session to an MSRP session. The mapping 755 will be provided in a future version of this specification. 757 2.4. MSRP to XMPP formal session 759 Unlike the XMPP protocol, the MSRP protocol only offers one way to 760 initiate a Chat session, that is typically initiated using the 761 Session Description Protocol [SDP] via the SIP offer/answer mechanism 762 [OFFER]. 764 This section will describe how to map a MSRP Chat session to either a 765 formal or informal XMPP session. 767 SIP User M2X GW XMPP User 768 | | | 769 |(F1)(SIP) INVITE | | 770 |------------------------>| | 771 | |(F2)(XMPP) Stanza session request 772 | |------------------------->| 773 | |(F3)(XMPP) Stanza session acceptance 774 | |<-------------------------| 775 |(F4)(SIP) 200 OK | | 776 |<------------------------| | 777 |(F5)(SIP) ACK | | 778 |------------------------>| | 779 | |(F6)(XMPP) Stanza session completion 780 | |------------------------->| 781 |(F7)(MSRP) SEND | | 782 |------------------------>| | 783 | |(F8)(XMPP) Stanza message | 784 | |------------------------->| 785 |(F9)(SIP) BYE | | 786 |------------------------>| | 787 | |(F10)(XMPP) Stanza session termination 788 | |------------------------->| 789 | |(F11)(XMPP) Stanza acknowledgment 790 | | session termination 791 | |<-------------------------| 792 |(F12)(SIP) 200 OK | | 793 |<------------------------| | 795 2.4.1. Initiating a Session 797 When Romeo wants to start an MSRP message session with Juliet, he 798 first has to start the SIP session by sending out a SIP INVITE 799 request containing an offered session description that includes an 800 MSRP media line accompanied by a mandatory "path" attribute and 801 corresponding URIs. The MSRP media line is also accompanied by an 802 "accept-types" attribute used to specify the only media-types 803 acceptable for Romeo (i.e., text/plain). 805 In addition to plain text messages, MSRP is able to carry arbitrary 806 (binary) Multipurpose Internet Mail Extensions [MIME] compliant 807 content, such as images or video clips. 809 Example: (F1) SIP user starts the session: 811 INVITE sip:juliet@example.com SIP/2.0 812 To: <sip:juliet@example.com> 813 From: <sip:romeo@example.net>;tag=576 814 Subject: Open chat with Romeo? 815 Call-ID: 742507no 816 Content-Type: application/sdp 818 c=IN IP4 example.net 819 m=message 7313 TCP/MSRP * 820 a=accept-types:text/plain 821 a=lang:en 822 a=lang:it 823 a=path:msrp://example.net:7313/ansp71weztas;tcp 825 Upon receiving the INVITE, the MSRP-XMPP gateway needs to determine 826 the identity of the foreign domain, which it does by performing one 827 or more DNS SRV lookups [DNS-SRV]. The gateway SHOULD resolve the 828 address present in the To header of the INVITE to an im, then follow 829 the rules in [IMP-SRV] regarding the "_im" SRV service for the target 830 domain contained in the To header. If SRV address resolution fails 831 for the "_im" service, the gateway MAY attempt a lookup for the 832 "_xmpp-server" service as specified in [XMPP] or MAY return an error 833 to the sender (i.e. 502 Bad Gateway). 835 If SVR address resolution succeeds, the gateway is responsible for 836 translating the request into an XMPP message stanza to initiate a 837 negotiated session from the SIP user to the XMPP user. 839 Example: (F2) SIP user starts the session (XMPP transformation): 841 <message type='normal' 842 from='romeo@example.net' 843 to='juliet@example.com'> 844 <thread>742507no</thread> 845 <feature xmlns='http://jabber.org/protocol/feature-neg'> 846 <x xmlns='jabber:x:data' type='form'> 847 <title>Open chat with Romeo? 848 849 urn:xmpp:ssn 850 851 852 true 853 854 855 858 en 859 860 861 862 863 864 866 The mapping of SIP and SDP syntax elements to XMPP syntax elements 867 SHOULD be as shown in the following table. (Mappings for elements 868 not mentioned in the foregoing table are undefined). 870 Table 3: Message syntax mapping from SIP to XMPP 872 +-----------------------------+-----------------------------+ 873 | SIP Header or SDP Contents | XMPP Element or Attribute | 874 +-----------------------------+-----------------------------+ 875 | Call-ID | | 876 | From | from | 877 | To | to | 878 | Subject | | 879 | accept-types | - | 880 | a=lang | xml:lang | 881 | To | to | 882 +-----------------------------+-----------------------------+ 884 2.4.2. Accepting a Session 886 If the request is accepted then Juliets client MUST include all the 887 fields that were marked as required in the request message. 889 In the example below, we assume that Juliet accepts the session and 890 specifies that she prefers to speak Italian with Romeo. 892 Example: (F3) Juliet accepts session and specifies parameters: 894 <message type='normal' 895 from='juliet@example.com' 896 to='romeo@example.net'> 897 <thread>742507no</thread> 898 <feature xmlns='http://jabber.org/protocol/feature-neg'> 899 <x xmlns='jabber:x:data' type='submit'> 900 <field var='FORM_TYPE'> 901 <value>urn:xmpp:ssn</value> 902 </field> 903 <field var='accept'><value>true</value></field> 904 <field var='language'><value>it</value></field> 905 </x> 906 </feature> 907 </message> 909 Upon receiving such a response, the MSRP-XMPP gateway SHOULD remember 910 that this is a response to a stanza related to an MSRP-XMPP 911 translation. The gateway is responsible for translating the response 912 into a SIP response and deliver it from the XMPP user back to the SIP 913 user. 915 Example: (F4) Juliet accepts session (SIP translation) 917 SIP/2.0 200 OK 918 To: <sip:juliet@example.com>;tag=534 919 From: <sip:romeo@example.net>;tag=576 920 Call-ID: 742507no 921 Content-Type: application/sdp 923 c=IN IP4 m2x.example.net 924 m=message 8763 TCP/MSRP * 925 a=accept-types:text/plain 926 a=lang:it 927 a=path:msrp://m2x.example.net:8763/lkjh37s2s20w2a;tcp 929 2.4.3. Completing the Transaction 931 In this case, the 200 OK is routed back and is received by Romeo UA. 932 Finally, Romeos client sends an acknowledgment message, ACK, to 933 Juliets client to confirm the reception of the final response (200 934 OK). 936 Example: (F5) Romeo sends the ACK: 938 ACK sip:juliet@example.com SIP/2.0 939 To: <sip:juliet@example.com>;tag=534 940 From: <sip:romeo@example.net>;tag=576 941 Call-ID: 742507no 943 Upon receiving the ACK, the MSRP-XMPP gateway SHOULD remember this is 944 an acknowledgment to an XMPP formal session. The gateway is 945 responsible for translating the acknowledgment into a confirmation 946 stanza, without inserting other content (e.g. a <body/> element can 947 not be inserted). 949 Example: (F6) Romeo sends the ACK (XMPP translation) 951 <message type='normal' 952 from='romeo@example.net' 953 to='juliet@example.com'> 954 <thread>742507no</thread> 955 <feature xmlns='http://jabber.org/protocol/feature-neg'> 956 <x xmlns='jabber:x:data' type='result'> 957 <field var='FORM_TYPE'> 958 <value>urn:xmpp:ssn</value> 959 </field> 960 <field var='accept'><value>true</value></field> 961 </x> 962 </feature> 963 </message> 965 2.4.4. Send a Message 967 When Romeo wants to send a message, he creates an MSRP SEND request 968 that contains message. 970 Example: (F7) Romeo send a message. 972 MSRP ad49kswow SEND 973 To-Path: msrp://m2x.example.net:8763/lkjh37s2s20w2a;tcp 974 From-Path: msrp://example.net:7313/ansp71weztas;tcp 975 Message-ID: 44921zaqwsx 976 Byte-Range: 1-32/32 977 Failure-Report: no 978 Content-Type: text/plain 980 I forgot what I wanted to say! 981 -------ad49kswow$ 983 Upon receiving the MSRP SEND request, the MSRP-XMPP gateway SHOULD 984 remember that the message is for an XMPP user. The gateway is 985 responsible for translating the MSRP SEND request in an XMPP message 986 stanza. 988 Example: (F8) Romeo sends a message (XMPP translation). 990 <message type='normal' 991 from='romeo@example.net' 992 to='juliet@example.com'> 993 <thread>742507no</thread> 994 <body>I forgot what I wanted to say!</body> 995 </message> 997 The mapping of MSRP syntax elements to XMPP syntax elements SHOULD be 998 as shown in the following table. (Mappings for elements not 999 mentioned are undefined). 1001 Table 4: Message syntax mapping from MSRP Message to XMPP 1003 +-----------------------------+-----------------------------+ 1004 | MSRP Header | XMPP Element or Attribute | 1005 +-----------------------------+-----------------------------+ 1006 | To-Path | to | 1007 | From-Path | from | 1008 | body of the SEND request | <body/> | 1009 | Content-Type: text/plain | - | 1010 | Message-ID | id | 1011 +-----------------------------+-----------------------------+ 1013 2.4.5. Terminating a Session 1015 When Romeo wants to terminate the Session, he is required to send a 1016 SIP BYE request. 1018 Example: (F9) Romeo terminates the session 1020 BYE juliet@example.com sip: SIP/2.0 1021 Max-Forwards: 70 1022 From: <sip:romeo@example.net>;tag=576 1023 To: <sip:juliet@example.com>;tag=534 1024 Call-ID: 742507no 1025 Cseq: 1 BYE 1026 Content-Length: 0 1028 Upon receiving the SIP BYE request, the GW SHOULD translate the 1029 request to a <message/> stanza containing a data form of type 1030 "submit". The <message/> element MUST contain a <thread/> element 1031 with the same XML character data as the original initiation request. 1032 The data form containing a boolean field named "terminate" should be 1033 set to a value of "1" or "true". 1035 Example: (F10) Romeo terminates the session (XMPP translation) 1037 <message type='normal' 1038 from='romeo@example.net' 1039 to='juliet@example.com'> 1040 <thread>742507no</thread> 1041 <feature xmlns='http://jabber.org/protocol/feature-neg'> 1042 <x xmlns='jabber:x:data' type='submit'> 1043 <field var='FORM_TYPE'> 1044 <value>urn:xmpp:ssn</value> 1045 </field> 1046 <field var='terminate'><value>1</value></field> 1047 </x> 1048 </feature> 1049 </message> 1051 Juliet explicitly acknowledges the termination of the chat session on 1052 the XMPP side by sending a <message/> containing a data form of type 1053 "result", and the value of the "terminate" field set to "1" or 1054 "true". The client MUST mirror the <thread/> value it received. 1056 Example: (F11) Juliet acknowledges the termination of the session. 1058 <message type='normal' 1059 from='juliet@example.com' 1060 to=='romeo@example.net'> 1061 <thread>742507no</thread> 1062 <feature xmlns='http://jabber.org/protocol/feature-neg'> 1063 <x xmlns='jabber:x:data' type='result'> 1064 <field var='FORM_TYPE'> 1065 <value>urn:xmpp:ssn</value> 1066 </field> 1067 <field var='terminate'><value>1</value></field> 1068 </x> 1069 </feature> 1070 </message> 1072 Upon receiving the acknowledgment message, the GW SHOULD translate it 1073 to a SIP answer 200 OK. 1075 Example: (F12) Juliet acknowledges the termination of the session 1076 (SIP translation) 1078 SIP/2.0 200 OK 1079 From: <sip:romeo@example.net>;tag=576 1080 To: <sip:juliet@example.com>;tag=534 1081 Call-ID: 742507no 1082 CSeq: 1 BYE 1084 2.4.6. Cancel the transaction 1086 SIP User M2X GW XMPP User 1087 | | | 1088 |(F1)(SIP) INVITE | | 1089 |----------------------->| | 1090 | |(F2)(XMPP) Stanza session request 1091 | |------------------------->| 1092 |(F3)(SIP) CANCEL | | 1093 |----------------------->| | 1094 | |(F4)(XMPP) Stanza session termination 1095 | |------------------------->| 1096 | |(F5)(XMPP) Stanza acknowledgment 1097 | | session termination 1098 | |<-------------------------| 1099 |(F6)(SIP) 200 OK | | 1100 |<-----------------------| | 1102 A common scenario occurs when the SIP user issues an invitation to 1103 set up a Chat session with an XMPP user and immediately after the SIP 1104 invitation is sent, the SIP user decides to cancel it. The XMPP-MSRP 1105 GW will receive the CANCEL request and using the the Call-ID, To, 1106 From and CSeq (sequence number only) header field values as a guide, 1107 will issue an XMPP Stanza session termination request to the XMPP 1108 user to cancel the XMPP formal session (assuming that it was already 1109 set up). Once the XMPP-MSRP GW receives an ACK stanza message for 1110 the session termination, the XMPP-MSRP GW will respond with a status 1111 of 200 (OK) back to the SIP user. It is important to note that if 1112 the SIP session transaction does not exist, the XMPP-MSRP GW will 1113 return a status of 481 (Transaction Does Not Exist) back to the SIP 1114 User. 1116 2.4.7. Rejecting a transaction 1118 SIP User M2X GW XMPP User 1119 | | | 1120 |(F1)(SIP) INVITE | | 1121 |-------------------------->| | 1122 | |(F2)(XMPP) Stanza session request 1123 | |------------------------->| 1124 | |(F3)(XMPP) Stanza session decline 1125 | |<-------------------------| 1126 |(F4)(SIP) 4xx/6xx | | 1127 |<--------------------------| | 1129 Another common scenario occurs when the XMPP UA is currently not 1130 willing or able to accept a formal session request. The XMPP UA 1131 SHOULD decline the invitation. The data form MUST contain the 1132 FORM_TYPE field and the "accept" field set to "0" or "false". It is 1133 RECOMMENDED that the form does not contain any other fields even if 1134 the request indicated they are required. The client MAY include a 1135 reason in the <body/> child of the <message/> stanza: 1137 Example: (F3) User declines offer and specifies reason 1139 <message type='normal' 1140 from='juliet@example.com' 1141 to='romeo@example.net'> 1142 <thread>742507no</thread> 1143 <feature xmlns='http://jabber.org/protocol/feature-neg'> 1144 <x xmlns='jabber:x:data' type='submit'> 1145 <field var='FORM_TYPE'> 1146 <value>urn:xmpp:ssn</value> 1147 </field> 1148 <field var='accept'><value>0</value></field> 1149 </x> 1150 </feature> 1151 </message> 1152 Upon receiving the declined response for the XMPP formal session 1153 request, the XMPP-MSRP GW SHOULD return a 4xx or a 6xx SIP response 1154 back to the SIP client. Any content that is contained in the <body/> 1155 child of the <message/>. stanza SHOULD be copied into the response 1156 Warning header field which explains why the offer was rejected. 1158 2.5. MSRP to an XMPP Informal Session 1160 To follow. 1162 3. Security Considerations 1164 To follow. 1166 4. References 1168 4.1. Normative References 1170 [IMP-SRV] Peterson, J., "Address Resolution for Instant Messaging 1171 and Presence", RFC 3861, August 2004. 1173 [MSRP] Campbell, B., Mahy, R., and C. Jennings, "The Message 1174 Session Relay Protocol (MSRP)", RFC 4975, September 2007. 1176 [OFFER] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1177 with Session Description Protocol (SDP)", RFC 3264, 1178 June 2002. 1180 [SIP] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1181 A., Peterson, J., Sparks, R., Handley, M., and E. 1182 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1183 June 2002. 1185 [TERMS] Bradner, S., "Key words for use in RFCs to Indicate 1186 Requirement Levels", BCP 14, RFC 2119, March 1997. 1188 [XEP-0155] 1189 Paterson, I. and P. Saint-Andre, "Stanza Session 1190 Negotiation", XSF XEP 0155, March 2007. 1192 [XMPP] Saint-Andre, P., Ed., "Extensible Messaging and Presence 1193 Protocol (XMPP): Core", RFC 3920, October 2004. 1195 [XMPP-IM] Saint-Andre, P., Ed., "Extensible Messaging and Presence 1196 Protocol (XMPP): Instant Messaging and Presence", 1197 RFC 3921, October 2004. 1199 [XMPP-SIMPLE] 1200 Saint-Andre, P., "Basic Messaging and Presence 1201 Interworking between the Extensible Messaging and 1202 Presence Protocol (XMPP) and Session Initiation Protocol 1203 (SIP) for Instant Messaging and Presence Leveraging 1204 Extensions (SIMPLE)", draft-saintandre-xmpp-simple-10 1205 (work in progress), August 2007. 1207 4.2. Informative References 1209 [DNS-SRV] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 1210 specifying the location of services (DNS SRV)", RFC 2782, 1211 February 2000. 1213 [IMP-REQS] 1214 Day, M., Aggarwal, S., Mohr, G., and J. Vincent, "Instant 1215 Messaging / Presence Protocol Requirements", RFC 2779, 1216 February 2000. 1218 [MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1219 Extensions (MIME) Part One: Format of Internet Message 1220 Bodies", RFC 2045, November 1996. 1222 [SDP] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1223 Description Protocol", RFC 4566, July 2006. 1225 [SIP-MSG] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., 1226 and D. Gurle, "Session Initiation Protocol (SIP) Extension 1227 for Instant Messaging", RFC 3428, December 2002. 1229 [XEP-0045] 1230 Saint-Andre, P., "Multi-User Chat", XSF XEP 0045, 1231 April 2007. 1233 [XEP-0124] 1234 Paterson, I., Smith, D., and P. Saint-Andre, 1235 "Bidirectional-streams Over Synchronous HTTP (BOSH)", XSF 1236 XEP 0124, February 2007. 1238 [XEP-0184] 1239 Saint-Andre, P. and J. Hildebrand, "Message Receipts", XSF 1240 XEP 0184, September 2007. 1242 [XEP-0206] 1243 Paterson, I., "XMPP Over BOSH", XSF XEP 0206, June 2007. 1245 Authors' Addresses 1247 Peter Saint-Andre 1248 XMPP Standards Foundation 1249 P.O. Box 1641 1250 Denver, CO 80201 1251 USA 1253 Email: stpeter@jabber.org 1254 URI: https://stpeter.im/ 1256 Eddy Gavita 1257 Ericsson 1258 Decarie Boulevard 1259 Town of Mount Royal, Quebec 1260 Canada 1262 Email: eddy.gavita@ericsson.com 1264 Nazin Hossain 1265 Ericsson 1266 Decarie Boulevard 1267 Town of Mount Royal, Quebec 1268 Canada 1270 Email: Nazin.Hossain@ericsson.com 1272 Salvatore Loreto 1273 Ericsson 1274 Hirsalantie 11 1275 Jorvas 02420 1276 Finland 1278 Email: Salvatore.Loreto@ericsson.com 1280 Full Copyright Statement 1282 Copyright (C) The IETF Trust (2007). 1284 This document is subject to the rights, licenses and restrictions 1285 contained in BCP 78, and except as set forth therein, the authors 1286 retain all their rights. 1288 This document and the information contained herein are provided on an 1289 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1290 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1291 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1292 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1293 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1294 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1296 Intellectual Property 1298 The IETF takes no position regarding the validity or scope of any 1299 Intellectual Property Rights or other rights that might be claimed to 1300 pertain to the implementation or use of the technology described in 1301 this document or the extent to which any license under such rights 1302 might or might not be available; nor does it represent that it has 1303 made any independent effort to identify any such rights. Information 1304 on the procedures with respect to rights in RFC documents can be 1305 found in BCP 78 and BCP 79. 1307 Copies of IPR disclosures made to the IETF Secretariat and any 1308 assurances of licenses to be made available, or the result of an 1309 attempt made to obtain a general license or permission for the use of 1310 such proprietary rights by implementers or users of this 1311 specification can be obtained from the IETF on-line IPR repository at 1312 http://www.ietf.org/ipr. 1314 The IETF invites any interested party to bring to its attention any 1315 copyrights, patents or patent applications, or other proprietary 1316 rights that may cover technology that may be required to implement 1317 this standard. Please address the information to the IETF at 1318 ietf-ipr@ietf.org. 1320 Acknowledgment 1322 Funding for the RFC Editor function is provided by the IETF 1323 Administrative Support Activity (IASA).