One document matched: draft-saintandre-sip-xmpp-chat-00.xml
<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM 'rfc2629.dtd'>
<?rfc compact="yes"?>
<?rfc sortrefs="yes"?>
<?rfc strict="yes"?>
<?rfc symrefs="yes"?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<rfc category="info" docName="draft-saintandre-sip-xmpp-chat-00.txt" ipr="full3978">
<front>
<title abbrev="SIP-XMPP Interworking: Text Chat">Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Text Chat</title>
<author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
<organization>XMPP Standards Foundation</organization>
<address>
<postal>
<street>P.O. Box 1641</street>
<city>Denver</city>
<region>CO</region>
<code>80201</code>
<country>USA</country>
</postal>
<email>stpeter@jabber.org</email>
<uri>https://stpeter.im/</uri>
</address>
</author>
<author initials="E." surname="Gavita" fullname="Eddy Gavita">
<organization>Ericsson</organization>
<address>
<postal>
<street>Decarie Boulevard</street>
<code></code>
<city>Town of Mount Royal</city>
<region>Quebec</region>
<country>Canada</country>
</postal>
<email>eddy.gavita@ericsson.com</email>
</address>
</author>
<author initials="N." surname="Hossain" fullname="Nazin Hossain">
<organization>Ericsson</organization>
<address>
<postal>
<street>Decarie Boulevard</street>
<city>Town of Mount Royal</city>
<region>Quebec</region>
<country>Canada</country>
</postal>
<email>Nazin.Hossain@ericsson.com</email>
</address>
</author>
<author initials="S." surname="Loreto" fullname="Salvatore Loreto">
<organization>Ericsson</organization>
<address>
<postal>
<street>Hirsalantie 11</street>
<code>02420</code>
<city>Jorvas</city>
<country>Finland</country>
</postal>
<email>Salvatore.Loreto@ericsson.com</email>
</address>
</author>
<date year="2008" month="January" day="4"/>
<area>RAI</area>
<keyword>Instant Messaging</keyword>
<keyword>SIP</keyword>
<keyword>MSRP</keyword>
<keyword>XMPP</keyword>
<abstract>
<t>This document defines a bi-directional protocol mapping for the exchange of instant messages in the context of a one-to-one chat session between a user of the Session Initiation Protocol (SIP) and a user of the Extensible Messaging and Presence Protocol (XMPP). Specifically for SIP text chat, this document specifies a mapping to the Message Session Relay Protocol (MSRP).</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<section title="Overview">
<t>Both the Session Initiation Protocol <xref target="SIP"/> and the Extensible Messaging and Presence Protocol <xref target='XMPP'/> can be used for the purpose of one-to-one text chat over the Inernet. To ensure interworking between these technologies, it is important to define bi-directional protocol mappings.</t>
<t>The architectural assumptions underlying such protocol mappings are provided in <xref target='SIP-XMPP'/>, including mapping of addresses and error conditions. Mappings for single instant messages (sometimes called "pager-mode" messaging) are provided in <xref target='SIP-XMPP-IM'/>. This document specifies mappings for one-to-one text chat sessions (sometimes called "session-mode" messaging); in particular, this document specifies mappings between XMPP and the Message Session Relay Protocol <xref target='MSRP'/>. Mapping of multi-user text chat (sometimes called "groupchat") is out of scope for this document.</t>
<t>Note: The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in <xref target="TERMS">RFC 2119</xref>.</t>
</section>
<section title="Scope">
<t>Both XMPP and SIP/SIMPLE technologies enable end users to send "instant messages" to other end users. The term "instant message" usually refers to messages sent between two end-users for delivery in close to real time (rather than messages that are stored and forwarded to the intended recipient upon request). Generally, there are three kinds of instant messages:</t>
<t>
<list style="numbers">
<t>Single messages, which are sent from the sender to the recipient outside the context of any one-to-one chat session or multi-user text conference. The message is immediately delivered and not stored in an inbox. In XMPP a single message is a <message/> stanza of type "normal" as specified in <xref target='XMPP-IM'/>. In SIP/SIMPLE a single message is sent via the MESSAGE method as specified in <xref target="MSRP"/>.</t>
<t>One-to-one chat messages, which are sent from the sender to the recipient (i.e., one-to-one) in the context of a "chat session" between the two entities. In XMPP a chat message is a <message/> stanza of type "chat". In SIP/SIMPLE a chat message is sent using an MSRP session.</t>
<t>Groupchat messages, which are sent from a sender to multiple recipients (i.e., 2 or more) in the context of a "multi-user chat session" or "text conference". In XMPP a groupchat message is a <message/> stanza of type "groupchat" that is reflected from the sender to multiple recipients by a multi-user chat service as defined in <xref target='XEP-0045'/>. In SIP/SIMPLE a groupchat message is reflected from the sender to multiple recipients by a conference server that uses MSRP to handle groupchat sessions.</t>
</list>
</t>
<t>This document only covers the scenario #2 above for converting XMPP messages of type "chat" to their corresponding SIP INVITE - MSRP message types on the SIP/SIMPLE side.</t>
<t>As in <xref target='SIP-XMPP-IM'/> and related documents, the approach taken here is to directly map syntax and semantics from one protocol to another. One-to-one chat sessions using XMPP message stanzas of type "chat" are specified in <xref target="XMPP-IM"/>, and a method for formally negotiating such a session is specified in <xref target='XEP-0155'/>. One-to-one chat sessions using the SIP MESSAGE method, the SIP INVITE method, and the Message Session Relay Protocol (MSRP) are specified in <xref target="SIP-MSG"/> and <xref target="MSRP"/>. In particular, this document defines a mapping between XMPP chat sessions (as specified in <xref target='XMPP-IM'/> and <xref target='XEP-0155'/>) and the Message Session Relay Protocol (as specified in <xref target='MSRP'/>).</t>
</section>
<section title="Connection Maintenance">
<t>XMPP makes use of long-lived TCP connections. If mobility affecting Layer 3 causes a dropped connection, the connection must be re-established. If mobility preserves the IP address, the TCP connection will be dropped. Any TLS session and SASL associations must be re-established if the TCP connection is dropped. XMPP binds directly to TCP in the core specification, so the TCP session must remain open for the entire duration of the chat/conversation. The XMPP Standards Foundation does define protocol extensions enabling transport of XMPP traffic over HTTP (refer to <xref target='XEP-0124'/> and <xref target='XEP-0206'/>), so that individual messages are carried using HTTP and are more robust in environments such as mobile networks, allowing for better recovery if a TCP session is broken.</t>
<t>SIMPLE is similar when using MSRP. The Message Session Relay Protocol <xref target="MSRP"/> is a protocol for transmitting instant messages (IM) in the context of a session. The protocol specification describes how the session can be negotiated and established with an offer or answer <xref target="OFFER"/> using the Session Description Protocol <xref target="SDP"/>. In SIMPLE, this exchange is carried using SIP as the signaling protocol. After the TCP connection is established, if it fails for any reason, then an MSRP endpoint MAY choose to re-create such session using a new SDP exchange in a SIP re-INVITE. SIMPLE also uses MESSAGE request for transporting instant messaging outside the context of a session. The MESSAGE request is sent inside the signaling path without establishing any dedicate connection.</t>
</section>
<section title="Acknowledgements">
<t>Some text in this document was borrowed from <xref target='SIP-XMPP'/> and from <xref target='XEP-0155'/>.</t>
</section>
</section>
<section title="Message Sessions">
<section title="Overview">
<t>The traditional model for one-to-one chat "session" in Jabber/XMPP is for a user to simply send a message to a contact with a thread ID, but without any formal negotiation of session parameter.</t>
<t>This informal approach to session initiation in XMPP can be mapped both to SIP pager-mode messaging using the SIP MESSAGE method (as documented in <xref target='SIP-XMPP'/>) and to a MSRP chat session. How the Gateway chooses to map the XMPP chat session in the SIP side is a matter of the implementation.</t>
<t>However, in XMPP it also possibile to formally request a chat session and negotiate its parameters (e.g., security, privacy, message logging) before beginning the session. The protocol for doing so is defined in <xref target='XEP-0155'/>. In this case, the XMPP chat session should be translated into a MSRP session.</t>
<t>This document covers the mapping of both informal and formally-negotiated XMPP chat session into a MSRP session.</t>
</section>
<section title="XMPP Formal Chat Session to MSRP">
<t>XMPP Protocol offers two ways an XMPP user can initiate a 1-1 chat: the first approach doesn't establish a session (this method is referred to the "informal session" approach); the second approach instead involves explicit negotiation of a session (this method is referred to the "formal session" approach).</t>
<t>This section describes how to map an XMPP "formal session" to an MSRP session.</t>
<t>The XMPP formal session is based on the protocol described in <xref target='XEP-0155'/>, which enable the initiation, renegotiation, and termination of a format chat session on the XMPP side. This approach maps to the semantic of the SIP INVITE and BYE methods.</t>
<figure>
<artwork><![CDATA[
XMPP User X2M GW SIP User
| | |
|(F1) (XMPP) Stanza session request |
|------------------------->| |
| |(F2) (SIP) INVITE |
| |------------------------->|
| |(F3) (SIP) 200 OK |
| |<-------------------------|
|(F4) (XMPP) Stanza session acceptance |
|<-------------------------| |
| |(F5) (SIP) ACK |
| |------------------------->|
|(F6) (XMPP) Stanza session completion |
|------------------------->| |
| |(F7) (MSRP) SEND |
| |------------------------->|
|(F8) (XMPP) Stanza session termination |
|------------------------->| |
| |(F9) (SIP) BYE |
| |------------------------->|
| |(F10) (SIP) 200 OK |
| |<-------------------------|
|(F11) (XMPP) Stanza acknoledgment |
| session termination |
|<-------------------------| |
]]></artwork>
</figure>
<section title="Initiating a Formal Session">
<t>When the XMPP user ("Juliet") wants to initiate a negotiated session with a SIP user ("Romeo"), she sends a <message/> stanza to Romeo containing a <feature/> child qualified by the 'http://jabber.org/protocol/feature-neg' namespace. The <message/> stanza must not contain a <body/< child (as specified in <xref target="XMPP-IM"/>), since thhat child element is used for human-readable text. The <message/> stanza type should be "normal". The stanza must contain a <thread/> element for tracking purposes (where the newly-generated ThreadID is unique to the proposed session). The encapsulated data form shall contain a FORM_TYPE field whose type is "hidden" and whose value is "urn:xmpp:ssn"; it must also contain a boolean field named "accept".</t>
<t>The XMPP user may request a session with a specific resource of the contact. However in this document the resource identifier will be ignored and discarded for cross-system interworking.</t>
<figure>
<preamble>Example: (F1) Juliet starts a formal session:</preamble>
<artwork><![CDATA[
<message type='normal'
from='juliet@example.com'
to='romeo@example.net'>
<thread>711609sa</thread>
<feature xmlns='http://jabber.org/protocol/feature-neg'>
<x xmlns='jabber:x:data' type='form'>
<title>Open chat with Juliet?</title>
<field var='FORM_TYPE' type='hidden'>
<value>urn:xmpp:ssn</value>
</field>
<field label='Accept this session?' type='form' var='accept'>
<value>true</value>
<required/>
</field>
<field label='Primary written language of the chat'
type='list-single' var='language'>
<value>en</value>
<option label='English'><value>en</value></option>
<option label='Italiano'><value>it</value></option>
</field>
</x>
</feature>
</message>
]]></artwork>
</figure>
<t>Upon receiving such a session request, the XMPP server to which Juliet has authenticated attempts to deliver the request to a local user or attempts to route the request to the foreign domain that services the hostname in the 'to' attribute. Naturally, in this document we assume that the hostname in the 'to' attribute is an IM-aware SIP service hosted by a separate server.</t>
<t>As specified in <xref target="XMPP-IM"/>, the XMPP server needs to determine the identity of the foreign domain, which it does by performing one or more <xref target="DNS-SRV"/> lookups. For message stanzas, the order of lookups recommended by <xref target="XMPP-IM"/> is to first try the "_xmpp-server" service as specified in <xref target="XMPP"/> and to then try the "_im" service as specified in <xref target="IMP-SRV"/>. Here we assume that the first lookup will fail but that the second lookup will succeed and return a resolution "_im._simple.example.net.", since we have already assumed that the example.net hostname is running a SIP instant messaging service. (Note: The XMPP server may have previously determined that the foreign domain is a SIMPLE server, in which case it would not need to perform the SRV lookups; the caching of such information is a matter of implementation and local service policy, and is therefore out of scope for this document.)</t>
<t>Once the XMPP server has determined that the foreign domain is serviced by a SIMPLE server, it must determine how to proceed. We here assume that the XMPP server contains or has available to it an XMPP-MSRP gateway. The XMPP server would then deliver the message stanza to the XMPP-MSRP gateway.</t>
<t>The XMPP-MSRP gateway is then responsible for translating the XMPP session into an MSRP session.</t>
<figure>
<preamble>Example: (F2) Juliet starts a formal session (SIP transformation):</preamble>
<artwork><![CDATA[
INVITE sip:romeo@example.net SIP/2.0
To: <sip:romeo@example.net>
From: <sip:juliet@example.com>;tag=786
Subject: Open chat with Juliet?
Call-ID: 711609sa
Content-Type: application/sdp
c=IN IP4 x2m.example.com
m=message 7654 TCP/MSRP *
a=accept-types:text/plain
a=lang:en
a=lang:it
a=path:msrp://x2m.example.com:7654/jshA7weztas;tcp
]]></artwork>
</figure>
<t>There is no direct mapping for the MSRP URIs. In fact MSRP URIs identify a session of instant message at a particular device; they are ephemeral and have not meaning outside the scope of that session. The authority component of the MSRP URI MUST contain the XMPP-MSRP gateway hostname or numeric IP address and an explicit port number.</t>
<t>Native XMPP supports text (i.e., UTF-8) only, so the "accept-types" attribute that follows an MSRP media line MUST indicate text/plain as the only media-type that is acceptable to the endpoint.</t>
<t>As specified in <xref target='SIP-XMPP'/>, the mapping of XMPP syntax elements to SIP and SDP syntax elements SHOULD be as shown in the following table. (Mappings for elements not mentioned are undefined).</t>
<figure>
<preamble>Table 1: Message syntax mapping from XMPP to SIP/SDP</preamble>
<artwork><![CDATA[
+-----------------------------+-----------------------------+
| XMPP Element or Attribute | SIP Header or SDP Contents |
+-----------------------------+-----------------------------+
| <thread/> | Call-ID |
| from | From |
| to | To |
| <title/> | Subject |
| xml:lang | a=lang:<language tag> |
| - | a=accept-types:text/plain |
+-----------------------------+-----------------------------+
]]></artwork>
</figure>
</section>
<section title="Accepting a Formal Session">
<t>The SIP user agent Romeo receiving the SIP invitation, containing an offered session description that includes a session of MSRP, accepts the invitation and includes an answer session description that acknowledges the choice of media.</t>
<figure>
<preamble>Example: (F3) Romeo accepts the request</preamble>
<artwork><![CDATA[
SIP/2.0 200 OK
To: <sip:romeo@example.net>;tag=087js
From: <sip:juliet@example.com>;tag=786
Call-ID: 711609sa
Content-Type: application/sdp
c=IN IP4 example.net
m=message 12763 TCP/MSRP *
a=accept-types:text/plain
a=lang:it
a=path:msrp://example.net:12763/kjhd37s2s20w2a;tcp
]]></artwork>
</figure>
<t>Upon receiving such a response, the MSRP-XMPP gateway SHOULD remember that this is a response to a SIP transaction related to an XMPP-MSRP translation. The gateway is responsible for translating the response into an XMPP message stanza and deliver it from the SIP user back to the XMPP user deliver.</t>
<t>The MSRP-XMPP gateway MUST include in the response translation values for all the fields that the XMPP request indicated are required.</t>
<figure>
<preamble>Example: (F4) Romeo accepts the request (XMPP translation)</preamble>
<artwork><![CDATA[
<message type='normal'
from='romeo@example.net'
to='juliet@example.com'>
<thread>711609sa</thread>
<feature xmlns='http://jabber.org/protocol/feature-neg'>
<x xmlns='jabber:x:data' type='submit'>
<field var='FORM_TYPE'>
<value>urn:xmpp:ssn</value>
</field>
<field var='accept'><value>true</value></field>
<field var='language'><value>it</value></field>
</x>
</feature>
</message>
]]></artwork>
</figure>
<t>The gateway MUST also send a SIP ACK to the SIP user.</t>
<figure>
<preamble>Example: (F5) The GW sends the ACK to Romeos UA:</preamble>
<artwork><![CDATA[
ACK sip:romeo@example.com SIP/2.0
To: <sip:romeo@example.net>;tag=087js
From: <sip:juliet@example.com>;tag=786
Call-ID: 711609sa
]]></artwork>
</figure>
<t>If Romeo accepted the session Juliet MUST either complete or cancel the stanza session negotiation. The user's client SHOULD verify that the selected values of the fields are acceptable before completing the stanza session negotiation -- and confirming that the session is open -- by replying with the form 'type' attribute set to 'result'. The form MUST contain the FORM_TYPE field and the "accept" field set to "1" or "true". The user MAY include other content "e.g., a <body/> element in the confirmation stanza:</t>
<figure>
<preamble>Example: (F6) Juliet completes negotiation, confirms session is open and send a message.</preamble>
<artwork><![CDATA[
<message type='normal'
from='juliet@example.com'
to='romeo@example.net'>
<thread>711609sa</thread>
<feature xmlns='http://jabber.org/protocol/feature-neg'>
<x xmlns='jabber:x:data' type='result'>
<field var='FORM_TYPE'>
<value>urn:xmpp:ssn</value>
</field>
<field var='accept'><value>true</value></field>
</x>
</feature>
</message>
]]></artwork>
</figure>
<t>Upon receiving such stanza completing the session negotiation, the XMPP server MUST not send any confirmation to the SIP side.</t>
<t>The XMPP-MSRP gateway must create a transaction identifier and use this and the SEND method to create an MSRP request start line.</t>
<t>The XMPP 'id' attribute is not required in the protocol and there is not a way to enforce its use for messages. It is RECOMMENDED to add it as a negotiable item in the XEP-0155, however it may not be present within the <message/> stanza, in this case the XMPP-MSRP MUST generate a new unique Message-ID.</t>
<t>Note: If the XMPP user has not explicitly requested message receipts during the negotiation, it is RECOMMENDED that the XMPP-MSRP inserts a Failure-Report header field value of "no" during the creation of a SEND request. The XMPP user can include the requested for message receipts using the Message Receipts XMPP protocol extension <xref target='XEP-0184'/>.</t>
<t>As specified in <xref target='SIP-XMPP'/>, the mapping of XMPP syntax elements to MSRP syntax elements SHOULD be as shown in the following table. (Mappings for elements not mentioned are undefined).</t>
<figure>
<preamble>Table 2: Message syntax mapping from XMPP Message to MSRP</preamble>
<artwork><![CDATA[
+-----------------------------+-----------------------------+
| XMPP Element or Attribute | MSRP Header |
+-----------------------------+-----------------------------+
| to | To-Path |
| from | From-Path |
| <body/> | body of the SEND request |
| - | Content-Type: text/plain |
| id | Message-ID |
+-----------------------------+-----------------------------+
]]></artwork>
</figure>
<t>Upon receiving the SEND request, if the request either contains a Failure-Report header field value of "yes" or does not contain a Failure-Report header at all, Alice's client MUST immediately generate and send a response.</t>
<figure>
<artwork><![CDATA[
MSRP d93kswow 200 OK
To-Path: msrp://x2m.example.com:7654/jshA7weztas;tcp
From-Path: msrp://example.net:12763/kjhd37s2s20w2a;tcp
-------d93kswow$
]]></artwork>
</figure>
<t>The XML character data of an XMPP message is not limited by the protocol, but is sometimes limited in deployment. However messages sent using MSRP can be delivered in several SEND requests, so when the XMPP-MSRP gateway receives a message longer then 2048, it is STRONGLY RECOMMENDED it delivers this message using as few chunks (at least 2048 octets long) as possible.</t>
</section>
<section title="Terminating a Formal Session">
<t>If Juliet decides to terminate the negotiated chat session, her client sends a <message/> stanza to Romeo containing a data form of type "submit". The <message/> stanza MUST contain a <thread/> element with the same XML character data as the original initiation request. The data form containing a boolean field named "terminate" set to a value of "1" or "true".</t>
<figure>
<preamble>Example: (F8) Juliet terminates the chat session</preamble>
<artwork><![CDATA[
<message type='normal'
from='juliet@example.com'
to='romeo@example.net'>
<thread>711609sa</thread>
<feature xmlns='http://jabber.org/protocol/feature-neg'>
<x xmlns='jabber:x:data' type='submit'>
<field var='FORM_TYPE'>
<value>urn:xmpp:ssn</value>
</field>
<field var='terminate'><value>1</value></field>
</x>
</feature>
</message>
]]></artwork>
</figure>
<t>Upon receiving such stanza terminating the chat session, the gateway terminates the SIP session by sending a SIP BYE to tear down the MSRP session with Romeo's client. Romeo's SIP client then responds with a 200 OK.</t>
<figure>
<preamble>Example: (F9) Juliet terminates the chat session (SIP translation)</preamble>
<artwork><![CDATA[
BYE romeo@example.com sip: SIP/2.0
Max-Forwards: 70
From: <sip:juliet@example.com>;tag=786
To: <sip:romeo@example.net>;tag=087js
Call-ID: 711609sa
Cseq: 1 BYE
Content-Length: 0
]]></artwork>
</figure>
<figure>
<preamble>Example: (F10) Romeo terminates the chat session</preamble>
<artwork><![CDATA[
SIP/2.0 200 OK
From: <sip:juliet@example.com>;tag=786
To: <sip:romeo@example.net>; tag=087js
Call-ID: 711609sa
CSeq: 1 BYE
Content-Length: 0
]]></artwork>
</figure>
<t>Upon receiving the 200 OK, the GW acknowledges the termination of the chat session on the XMPP side by sending a <message/> containing a data form of type "result", and the value of the "terminate" field set to "1" or "true". The client must mirror the <thread/> value it received.</t>
<figure>
<preamble>Example: (F11) Romeo terminates the chat session (XMPP translation)</preamble>
<artwork><![CDATA[
<message type='normal'
from='romeo@example.net'
to=='juliet@example.com'>
<thread>711609sa</thread>
<feature xmlns='http://jabber.org/protocol/feature-neg'>
<x xmlns='jabber:x:data' type='result'>
<field var='FORM_TYPE'>
<value>urn:xmpp:ssn</value>
</field>
<field var='terminate'><value>1</value></field>
</x>
</feature>
</message>
]]></artwork>
</figure>
</section>
<section title="Canceling the Negotiation">
<figure>
<artwork><![CDATA[
XMPP User X2M GW SIP User
| | |
|(F1) (XMPP) Stanza session request |
|------------------------->| |
| |(F2) (SIP) INVITE |
| |------------------------->|
| |(F3) (SIP) 200 OK |
| |<-------------------------|
|(F4) (XMPP) Stanza session acceptance |
|<-------------------------| |
| |(F5) (SIP) ACK |
| |------------------------->|
|(F6) (XMPP) Stanza session canceling |
|------------------------->| |
| |(F7) (SIP) BYE |
| |------------------------->|
| |(F8) (SIP) 200 OK |
| |<-------------------------|
]]></artwork>
</figure>
<t>If Romeo accepted the session, but Juliet decides to cancel the stanza session negotiation, the client must reply with a data form containing the FORM_TYPE field and the "accept" field set to "0" or "false":</t>
<figure>
<preamble>Example: (F6) User cancels stanza session negotiation</preamble>
<artwork><![CDATA[
<message type='normal'
from='juliet@example.com'
to='romeo@example.net'>
<thread>711609sa</thread>
<feature xmlns='http://jabber.org/protocol/feature-neg'>
<x xmlns='jabber:x:data' type='result'>
<field var='FORM_TYPE'>
<value>urn:xmpp:ssn</value>
</field>
<field var='accept'><value>0</value></field>
</x>
</feature>
</message>
]]></artwork>
</figure>
<t>Upon receiving such stanza canceling the session negotiation, the XMPP-MSRP Gateway MUST send a SIP BYE. Once the XMPP-MSRP receives the 200 OK, the internal session data is removed and the session is officially canceled also in the gateway.</t>
</section>
<section title="Rejecting a Formal Session">
<figure>
<artwork><![CDATA[
XMPP User X2M GW SIP User
| | |
|(F1) (XMPP) Stanza session request |
|------------------------->| |
| |(F2) (SIP) INVITE |
| |------------------------->|
| |(F3) (SIP) 4xx/6xx |
| |<-------------------------|
|(F4) (XMPP) Stanza session decline |
|<-------------------------| |
]]></artwork>
</figure>
<t>A common scenario occurs when the SIP UA is currently not willing or able to accept a formal session. The SIP UA declining an offer contained in an INVITE SHOULD return a 4xx or a 6xx response. Such response SHOULD include a Warning header field value explaining why the offer was rejected.</t>
<t>Upon receiving the error response for the SIP INVITE, the XMPP-MSRP GW will send back a "Session Reject" message back to the XMPP Client. The data form MUST contain the FORM_TYPE field and the "accept" field set to "0" or "false". It is reccomended that the form does not contain any other field even if the request indicated they are required. The client MAY include a reason in the <body/> child of the <message/> stanza.</t>
<t>The content of the Warning header field present in the SIP response SHOULD be copied in the <body/> child of the <message/> stanza. If the Warning header it is not present then the descriptive phrase of the SIP response can be used.</t>
<figure>
<preamble>Example: (F4) User declines offer and specifies reason</preamble>
<artwork><![CDATA[
<message type='normal'
from='romeo@example.net'
to='juliet@example.com'>
<thread>711609sa</thread>
<feature xmlns='http://jabber.org/protocol/feature-neg'>
<x xmlns='jabber:x:data' type='submit'>
<field var='FORM_TYPE'>
<value>urn:xmpp:ssn</value>
</field>
<field var='accept'><value>0</value></field>
</x>
</feature>
</message>
]]></artwork>
</figure>
</section>
</section>
<section title="XMPP Informal Session to MSRP">
<t>The "informal session" approach is to simply send someone a <message type='chat'/> without start any session negotiation before (as described in <xref target="XMPP-IM"/>). The XMPP "informal session" approach maps very well into a SIP MESSAGE request, as described in <xref target="SIP-XMPP"/>. Although the mapping to a SIP Message is straightforward, it is also possible to map an informal session to an MSRP session. The mapping will be provided in a future version of this specification.</t>
</section>
<section title="MSRP to XMPP formal session">
<t>Unlike the XMPP protocol, the MSRP protocol only offers one way to initiate a Chat session, that is typically initiated using the Session Description Protocol <xref target="SDP"/> via the SIP offer/answer mechanism <xref target="OFFER"/>.</t>
<t>This section will describe how to map a MSRP Chat session to either a formal or informal XMPP session.</t>
<figure>
<artwork><![CDATA[
SIP User M2X GW XMPP User
| | |
|(F1)(SIP) INVITE | |
|------------------------>| |
| |(F2)(XMPP) Stanza session request
| |------------------------->|
| |(F3)(XMPP) Stanza session acceptance
| |<-------------------------|
|(F4)(SIP) 200 OK | |
|<------------------------| |
|(F5)(SIP) ACK | |
|------------------------>| |
| |(F6)(XMPP) Stanza session completion
| |------------------------->|
|(F7)(MSRP) SEND | |
|------------------------>| |
| |(F8)(XMPP) Stanza message |
| |------------------------->|
|(F9)(SIP) BYE | |
|------------------------>| |
| |(F10)(XMPP) Stanza session termination
| |------------------------->|
| |(F11)(XMPP) Stanza acknowledgment
| | session termination
| |<-------------------------|
|(F12)(SIP) 200 OK | |
|<------------------------| |
]]></artwork>
</figure>
<section title="Initiating a Session">
<t>When Romeo wants to start an MSRP message session with Juliet, he first has to start the SIP session by sending out a SIP INVITE request containing an offered session description that includes an MSRP media line accompanied by a mandatory "path" attribute and corresponding URIs. The MSRP media line is also accompanied by an "accept-types" attribute used to specify the only media-types acceptable for Romeo (i.e., text/plain).</t>
<t>In addition to plain text messages, MSRP is able to carry arbitrary (binary) Multipurpose Internet Mail Extensions <xref target="MIME"/> compliant content, such as images or video clips.</t>
<figure>
<preamble>Example: (F1) SIP user starts the session:</preamble>
<artwork><![CDATA[
INVITE sip:juliet@example.com SIP/2.0
To: <sip:juliet@example.com>
From: <sip:romeo@example.net>;tag=576
Subject: Open chat with Romeo?
Call-ID: 742507no
Content-Type: application/sdp
c=IN IP4 example.net
m=message 7313 TCP/MSRP *
a=accept-types:text/plain
a=lang:en
a=lang:it
a=path:msrp://example.net:7313/ansp71weztas;tcp
]]></artwork>
</figure>
<t>Upon receiving the INVITE, the MSRP-XMPP gateway needs to determine the identity of the foreign domain, which it does by performing one or more DNS SRV lookups <xref target="DNS-SRV"/>. The gateway SHOULD resolve the address present in the To header of the INVITE to an im, then follow the rules in <xref target="IMP-SRV"/> regarding the "_im" SRV service for the target domain contained in the To header. If SRV address resolution fails for the "_im" service, the gateway MAY attempt a lookup for the "_xmpp-server" service as specified in <xref target="XMPP"/> or MAY return an error to the sender (i.e. 502 Bad Gateway).</t>
<t>If SVR address resolution succeeds, the gateway is responsible for translating the request into an XMPP message stanza to initiate a negotiated session from the SIP user to the XMPP user.</t>
<figure>
<preamble>Example: (F2) SIP user starts the session (XMPP transformation):</preamble>
<artwork><![CDATA[
<message type='normal'
from='romeo@example.net'
to='juliet@example.com'>
<thread>742507no</thread>
<feature xmlns='http://jabber.org/protocol/feature-neg'>
<x xmlns='jabber:x:data' type='form'>
<title>Open chat with Romeo?</title>
<field var='FORM_TYPE' type='hidden'>
<value>urn:xmpp:ssn</value>
</field>
<field label='Accept this session?' type='form' var='accept'>
<value>true</value>
<required/>
</field>
<field label='Primary written language of the chat'
type='list-single'
var='language'>
<value>en</value>
<option label='English'><value>en</value></option>
<option label='Italiano'><value>it</value></option>
</field>
</x>
</feature>
</message>
]]></artwork>
</figure>
<t>The mapping of SIP and SDP syntax elements to XMPP syntax elements SHOULD be as shown in the following table. (Mappings for elements not mentioned in the foregoing table are undefined).</t>
<figure>
<preamble>Table 3: Message syntax mapping from SIP to XMPP</preamble>
<artwork><![CDATA[
+-----------------------------+-----------------------------+
| SIP Header or SDP Contents | XMPP Element or Attribute |
+-----------------------------+-----------------------------+
| Call-ID | <thread/> |
| From | from |
| To | to |
| Subject | <title/> |
| accept-types | - |
| a=lang | xml:lang |
| To | to |
+-----------------------------+-----------------------------+
]]></artwork>
</figure>
</section>
<section title="Accepting a Session">
<t>If the request is accepted then Juliets client MUST include all the fields that were marked as required in the request message.</t>
<t>In the example below, we assume that Juliet accepts the session and specifies that she prefers to speak Italian with Romeo.</t>
<figure>
<preamble>Example: (F3) Juliet accepts session and specifies parameters:</preamble>
<artwork><![CDATA[
<message type='normal'
from='juliet@example.com'
to='romeo@example.net'>
<thread>742507no</thread>
<feature xmlns='http://jabber.org/protocol/feature-neg'>
<x xmlns='jabber:x:data' type='submit'>
<field var='FORM_TYPE'>
<value>urn:xmpp:ssn</value>
</field>
<field var='accept'><value>true</value></field>
<field var='language'><value>it</value></field>
</x>
</feature>
</message>
]]></artwork>
</figure>
<t>Upon receiving such a response, the MSRP-XMPP gateway SHOULD remember that this is a response to a stanza related to an MSRP-XMPP translation. The gateway is responsible for translating the response into a SIP response and deliver it from the XMPP user back to the SIP user.</t>
<figure>
<preamble>Example: (F4) Juliet accepts session (SIP translation)</preamble>
<artwork><![CDATA[
SIP/2.0 200 OK
To: <sip:juliet@example.com>;tag=534
From: <sip:romeo@example.net>;tag=576
Call-ID: 742507no
Content-Type: application/sdp
c=IN IP4 m2x.example.net
m=message 8763 TCP/MSRP *
a=accept-types:text/plain
a=lang:it
a=path:msrp://m2x.example.net:8763/lkjh37s2s20w2a;tcp
]]></artwork>
</figure>
</section>
<section title="Completing the Transaction">
<t>In this case, the 200 OK is routed back and is received by Romeo UA. Finally, Romeos client sends an acknowledgment message, ACK, to Juliets client to confirm the reception of the final response (200 OK).</t>
<figure>
<preamble>Example: (F5) Romeo sends the ACK:</preamble>
<artwork><![CDATA[
ACK sip:juliet@example.com SIP/2.0
To: <sip:juliet@example.com>;tag=534
From: <sip:romeo@example.net>;tag=576
Call-ID: 742507no
]]></artwork>
</figure>
<t>Upon receiving the ACK, the MSRP-XMPP gateway SHOULD remember this is an acknowledgment to an XMPP formal session. The gateway is responsible for translating the acknowledgment into a confirmation stanza, without inserting other content (e.g. a <body/> element can not be inserted).</t>
<figure>
<preamble>Example: (F6) Romeo sends the ACK (XMPP translation)</preamble>
<artwork><![CDATA[
<message type='normal'
from='romeo@example.net'
to='juliet@example.com'>
<thread>742507no</thread>
<feature xmlns='http://jabber.org/protocol/feature-neg'>
<x xmlns='jabber:x:data' type='result'>
<field var='FORM_TYPE'>
<value>urn:xmpp:ssn</value>
</field>
<field var='accept'><value>true</value></field>
</x>
</feature>
</message>
]]></artwork>
</figure>
</section>
<section title="Send a Message">
<t>When Romeo wants to send a message, he creates an MSRP SEND request that contains message.</t>
<figure>
<preamble>Example: (F7) Romeo send a message.</preamble>
<artwork><![CDATA[
MSRP ad49kswow SEND
To-Path: msrp://m2x.example.net:8763/lkjh37s2s20w2a;tcp
From-Path: msrp://example.net:7313/ansp71weztas;tcp
Message-ID: 44921zaqwsx
Byte-Range: 1-32/32
Failure-Report: no
Content-Type: text/plain
I forgot what I wanted to say!
-------ad49kswow$
]]></artwork>
</figure>
<t>Upon receiving the MSRP SEND request, the MSRP-XMPP gateway SHOULD remember that the message is for an XMPP user. The gateway is responsible for translating the MSRP SEND request in an XMPP message stanza.</t>
<figure>
<preamble>Example: (F8) Romeo sends a message (XMPP translation).</preamble>
<artwork><![CDATA[
<message type='normal'
from='romeo@example.net'
to='juliet@example.com'>
<thread>742507no</thread>
<body>I forgot what I wanted to say!</body>
</message>
]]></artwork>
</figure>
<t>The mapping of MSRP syntax elements to XMPP syntax elements SHOULD be as shown in the following table. (Mappings for elements not mentioned are undefined).</t>
<figure>
<preamble>Table 4: Message syntax mapping from MSRP Message to XMPP</preamble>
<artwork><![CDATA[
+-----------------------------+-----------------------------+
| MSRP Header | XMPP Element or Attribute |
+-----------------------------+-----------------------------+
| To-Path | to |
| From-Path | from |
| body of the SEND request | <body/> |
| Content-Type: text/plain | - |
| Message-ID | id |
+-----------------------------+-----------------------------+
]]></artwork>
</figure>
</section>
<section title="Terminating a Session">
<t>When Romeo wants to terminate the Session, he is required to send a SIP BYE request.</t>
<figure>
<preamble>Example: (F9) Romeo terminates the session</preamble>
<artwork><![CDATA[
BYE juliet@example.com sip: SIP/2.0
Max-Forwards: 70
From: <sip:romeo@example.net>;tag=576
To: <sip:juliet@example.com>;tag=534
Call-ID: 742507no
Cseq: 1 BYE
Content-Length: 0
]]></artwork>
</figure>
<t>Upon receiving the SIP BYE request, the GW SHOULD translate the request to a <message/> stanza containing a data form of type "submit". The <message/> element MUST contain a <thread/> element with the same XML character data as the original initiation request. The data form containing a boolean field named "terminate" should be set to a value of "1" or "true".</t>
<figure>
<preamble>Example: (F10) Romeo terminates the session (XMPP translation)</preamble>
<artwork><![CDATA[
<message type='normal'
from='romeo@example.net'
to='juliet@example.com'>
<thread>742507no</thread>
<feature xmlns='http://jabber.org/protocol/feature-neg'>
<x xmlns='jabber:x:data' type='submit'>
<field var='FORM_TYPE'>
<value>urn:xmpp:ssn</value>
</field>
<field var='terminate'><value>1</value></field>
</x>
</feature>
</message>
]]></artwork>
</figure>
<t>Juliet explicitly acknowledges the termination of the chat session on the XMPP side by sending a <message/> containing a data form of type "result", and the value of the "terminate" field set to "1" or "true". The client MUST mirror the <thread/> value it received.</t>
<figure>
<preamble>Example: (F11) Juliet acknowledges the termination of the session.</preamble>
<artwork><![CDATA[
<message type='normal'
from='juliet@example.com'
to=='romeo@example.net'>
<thread>742507no</thread>
<feature xmlns='http://jabber.org/protocol/feature-neg'>
<x xmlns='jabber:x:data' type='result'>
<field var='FORM_TYPE'>
<value>urn:xmpp:ssn</value>
</field>
<field var='terminate'><value>1</value></field>
</x>
</feature>
</message>
]]></artwork>
</figure>
<t>Upon receiving the acknowledgment message, the GW SHOULD translate it to a SIP answer 200 OK.</t>
<figure>
<preamble>Example: (F12) Juliet acknowledges the termination of the session (SIP translation)</preamble>
<artwork><![CDATA[
SIP/2.0 200 OK
From: <sip:romeo@example.net>;tag=576
To: <sip:juliet@example.com>;tag=534
Call-ID: 742507no
CSeq: 1 BYE
]]></artwork>
</figure>
</section>
<section title="Cancel the transaction">
<figure>
<artwork><![CDATA[
SIP User M2X GW XMPP User
| | |
|(F1)(SIP) INVITE | |
|----------------------->| |
| |(F2)(XMPP) Stanza session request
| |------------------------->|
|(F3)(SIP) CANCEL | |
|----------------------->| |
| |(F4)(XMPP) Stanza session termination
| |------------------------->|
| |(F5)(XMPP) Stanza acknowledgment
| | session termination
| |<-------------------------|
|(F6)(SIP) 200 OK | |
|<-----------------------| |
]]></artwork>
</figure>
<t>A common scenario occurs when the SIP user issues an invitation to set up a Chat session with an XMPP user and immediately after the SIP invitation is sent, the SIP user decides to cancel it. The XMPP-MSRP GW will receive the CANCEL request and using the the Call-ID, To, From and CSeq (sequence number only) header field values as a guide, will issue an XMPP Stanza session termination request to the XMPP user to cancel the XMPP formal session (assuming that it was already set up). Once the XMPP-MSRP GW receives an ACK stanza message for the session termination, the XMPP-MSRP GW will respond with a status of 200 (OK) back to the SIP user. It is important to note that if the SIP session transaction does not exist, the XMPP-MSRP GW will return a status of 481 (Transaction Does Not Exist) back to the SIP User.</t>
</section>
<section title="Rejecting a transaction">
<figure>
<artwork><![CDATA[
SIP User M2X GW XMPP User
| | |
|(F1)(SIP) INVITE | |
|-------------------------->| |
| |(F2)(XMPP) Stanza session request
| |------------------------->|
| |(F3)(XMPP) Stanza session decline
| |<-------------------------|
|(F4)(SIP) 4xx/6xx | |
|<--------------------------| |
]]></artwork>
</figure>
<t>Another common scenario occurs when the XMPP UA is currently not willing or able to accept a formal session request. The XMPP UA SHOULD decline the invitation. The data form MUST contain the FORM_TYPE field and the "accept" field set to "0" or "false". It is RECOMMENDED that the form does not contain any other fields even if the request indicated they are required. The client MAY include a reason in the <body/> child of the <message/> stanza:</t>
<figure>
<preamble>Example: (F3) User declines offer and specifies reason</preamble>
<artwork><![CDATA[
<message type='normal'
from='juliet@example.com'
to='romeo@example.net'>
<thread>742507no</thread>
<feature xmlns='http://jabber.org/protocol/feature-neg'>
<x xmlns='jabber:x:data' type='submit'>
<field var='FORM_TYPE'>
<value>urn:xmpp:ssn</value>
</field>
<field var='accept'><value>0</value></field>
</x>
</feature>
</message>
]]></artwork>
</figure>
<t>Upon receiving the declined response for the XMPP formal session request, the XMPP-MSRP GW SHOULD return a 4xx or a 6xx SIP response back to the SIP client. Any content that is contained in the <body/> child of the <message/>. stanza SHOULD be copied into the response Warning header field which explains why the offer was rejected.</t>
</section>
</section>
<section title="MSRP to an XMPP Informal Session">
<t>To follow.</t>
</section>
</section>
<section title="Security Considerations">
<t>To follow.</t>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor='MSRP'>
<front>
<title>The Message Session Relay Protocol (MSRP)</title>
<author initials='B.' surname='Campbell' fullname='B. Campbell'>
<organization /></author>
<author initials='R.' surname='Mahy' fullname='R. Mahy'>
<organization /></author>
<author initials='C.' surname='Jennings' fullname='C. Jennings'>
<organization /></author>
<date year='2007' month='September' />
<abstract>
<t>This document describes the Message Session Relay Protocol, a protocol for transmitting a series of related instant messages in the context of a session. Message sessions are treated like any other media stream when set up via a rendezvous or session creation protocol such as the Session Initiation Protocol. [STANDARDS TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='4975' />
<format type='TXT' octets='144254' target='ftp://ftp.isi.edu/in-notes/rfc4975.txt' />
</reference>
<reference anchor='IMP-SRV'>
<front>
<title>Address Resolution for Instant Messaging and Presence</title>
<author initials='J.' surname='Peterson' fullname='J. Peterson'>
<organization /></author>
<date year='2004' month='August' />
<abstract>
<t>Presence and instant messaging are defined in RFC 2778. The Common Profiles for Presence and Instant Messaging define two Universal Resource Identifier (URI) schemes: 'im' for INSTANT INBOXes and 'pres' for PRESENTITIES. This document provides guidance for locating the resources associated with URIs that employ these schemes. [STANDARDS TRACK] </t></abstract></front>
<seriesInfo name='RFC' value='3861' />
<format type='TXT' octets='15764' target='ftp://ftp.isi.edu/in-notes/rfc3861.txt' />
</reference>
<reference anchor='OFFER'>
<front>
<title>An Offer/Answer Model with Session Description Protocol (SDP)</title>
<author initials='J.' surname='Rosenberg' fullname='J. Rosenberg'>
<organization /></author>
<author initials='H.' surname='Schulzrinne' fullname='H. Schulzrinne'>
<organization /></author>
<date year='2002' month='June' />
<abstract>
<t>This document defines a mechanism by which two entities can make use of the Session Description Protocol (SDP) to arrive at a common view of a multimedia session between them. In the model, one participant offers the other a description of the desired session from their perspective, and the other participant answers with the desired session from their perspective. This offer/answer model is most useful in unicast sessions where information from both participants is needed for the complete view of the session. The offer/answer model is used by protocols like the Session Initiation Protocol (SIP). [STANDARDS TRACK] </t></abstract></front>
<seriesInfo name='RFC' value='3264' />
<format type='TXT' octets='60854' target='ftp://ftp.isi.edu/in-notes/rfc3264.txt' />
</reference>
<reference anchor='SIP'>
<front>
<title>SIP: Session Initiation Protocol</title>
<author initials='J.' surname='Rosenberg' fullname='J. Rosenberg'>
<organization /></author>
<author initials='H.' surname='Schulzrinne' fullname='H. Schulzrinne'>
<organization /></author>
<author initials='G.' surname='Camarillo' fullname='G. Camarillo'>
<organization /></author>
<author initials='A.' surname='Johnston' fullname='A. Johnston'>
<organization /></author>
<author initials='J.' surname='Peterson' fullname='J. Peterson'>
<organization /></author>
<author initials='R.' surname='Sparks' fullname='R. Sparks'>
<organization /></author>
<author initials='M.' surname='Handley' fullname='M. Handley'>
<organization /></author>
<author initials='E.' surname='Schooler' fullname='E. Schooler'>
<organization /></author>
<date year='2002' month='June' />
<abstract>
<t>This document describes Session Initiation Protocol (SIP), an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences. [STANDARDS TRACK] </t></abstract></front>
<seriesInfo name='RFC' value='3261' />
<format type='TXT' octets='647976' target='ftp://ftp.isi.edu/in-notes/rfc3261.txt' />
</reference>
<reference anchor='TERMS'>
<front>
<title abbrev='RFC Key Words'>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='Scott Bradner'>
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street></postal>
<phone>- +1 617 495 3864</phone>
<email>sob@harvard.edu</email></address></author>
<date year='1997' month='March' />
<area>General</area>
<keyword>keyword</keyword>
<abstract>
<t>
In many standards track documents several words are used to signify
the requirements in the specification. These words are often
capitalized. This document defines these words as they should be
interpreted in IETF documents. Authors who follow these guidelines
should incorporate this phrase near the beginning of their document:
<list>
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
RFC 2119.
</t></list></t>
<t>
Note that the force of these words is modified by the requirement
level of the document in which they are used.
</t></abstract></front>
<seriesInfo name='BCP' value='14' />
<seriesInfo name='RFC' value='2119' />
<format type='TXT' octets='4723' target='ftp://ftp.isi.edu/in-notes/rfc2119.txt' />
<format type='HTML' octets='17491' target='http://xml.resource.org/public/rfc/html/rfc2119.html' />
<format type='XML' octets='5777' target='http://xml.resource.org/public/rfc/xml/rfc2119.xml' />
</reference>
<reference anchor='XMPP'>
<front>
<title abbrev='XMPP Core'>Extensible Messaging and Presence Protocol (XMPP): Core</title>
<author initials='P.' surname='Saint-Andre' fullname='Peter Saint-Andre' role='editor'>
<organization>Jabber Software Foundation</organization>
<address>
<email>stpeter@jabber.org</email></address></author>
<date year='2004' month='October' />
<area>Applications</area>
<workgroup>XMPP Working Group</workgroup>
<keyword>RFC</keyword>
<keyword>Request for Comments</keyword>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<keyword>XMPP</keyword>
<keyword>Extensible Messaging and Presence Protocol</keyword>
<keyword>Jabber</keyword>
<keyword>IM</keyword>
<keyword>Instant Messaging</keyword>
<keyword>Presence</keyword>
<keyword>XML</keyword>
<keyword>Extensible Markup Language</keyword>
<abstract>
<t>This memo defines the core features of the Extensible Messaging and Presence Protocol (XMPP), a protocol for streaming Extensible Markup Language (XML) elements in order to exchange structured information in close to real time between any two network endpoints. While XMPP provides a generalized, extensible framework for exchanging XML data, it is used mainly for the purpose of building instant messaging and presence applications that meet the requirements of RFC 2779.</t></abstract></front>
<seriesInfo name='RFC' value='3920' />
<format type='TXT' octets='194313' target='ftp://ftp.isi.edu/in-notes/rfc3920.txt' />
<format type='HTML' octets='279912' target='http://xml.resource.org/public/rfc/html/rfc3920.html' />
<format type='XML' octets='234610' target='http://xml.resource.org/public/rfc/xml/rfc3920.xml' />
</reference>
<reference anchor='XMPP-IM'>
<front>
<title abbrev='XMPP IM'>Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence</title>
<author initials='P.' surname='Saint-Andre' fullname='Peter Saint-Andre' role='editor'>
<organization>Jabber Software Foundation</organization>
<address>
<email>stpeter@jabber.org</email></address></author>
<date year='2004' month='October' />
<area>Applications</area>
<workgroup>XMPP Working Group</workgroup>
<keyword>RFC</keyword>
<keyword>Request for Comments</keyword>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<keyword>XMPP</keyword>
<keyword>Extensible Messaging and Presence Protocol</keyword>
<keyword>Jabber</keyword>
<keyword>IM</keyword>
<keyword>Instant Messaging</keyword>
<keyword>Presence</keyword>
<keyword>XML</keyword>
<keyword>Extensible Markup Language</keyword>
<abstract>
<t>This memo describes extensions to and applications of the core features of the Extensible Messaging and Presence Protocol (XMPP) that provide the basic instant messaging (IM) and presence functionality defined in RFC 2779.</t></abstract></front>
<seriesInfo name='RFC' value='3921' />
<format type='TXT' octets='217527' target='ftp://ftp.isi.edu/in-notes/rfc3921.txt' />
<format type='HTML' octets='274538' target='http://xml.resource.org/public/rfc/html/rfc3921.html' />
<format type='XML' octets='234468' target='http://xml.resource.org/public/rfc/xml/rfc3921.xml' />
</reference>
<reference anchor="XEP-0155">
<front>
<title>Stanza Session Negotiation</title>
<author initials="I." surname="Paterson" fullname="Ian Paterson">
<organization/>
<address>
<email>ian.paterson@clientside.co.uk</email>
</address>
</author>
<author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
<organization/>
<address>
<email>stpeter@jabber.org</email>
</address>
</author>
<date day="15" month="March" year="2007"/>
</front>
<seriesInfo name="XSF XEP" value="0155"/>
<format type="HTML" target="http://www.xmpp.org/extensions/xep-0155.html"/>
</reference>
</references>
<references title='Informative References'>
<reference anchor='DNS-SRV'>
<front>
<title abbrev='DNS SRV RR'>A DNS RR for specifying the location of services (DNS SRV)</title>
<author initials='A.' surname='Gulbrandsen' fullname='Arnt Gulbrandsen'>
<organization>Troll Tech</organization>
<address>
<postal>
<street>Waldemar Thranes gate 98B</street>
<city>Oslo</city>
<region />
<code>N-0175</code>
<country>NO</country></postal>
<phone>+47 22 806390</phone>
<facsimile>+47 22 806380</facsimile>
<email>arnt@troll.no</email></address></author>
<author initials='P.' surname='Vixie' fullname='Paul Vixie'>
<organization>Internet Software Consortium</organization>
<address>
<postal>
<street>950 Charter Street</street>
<city>Redwood City</city>
<region>CA</region>
<code>94063</code>
<country>US</country></postal>
<phone>+1 650 779 7001</phone></address></author>
<author initials='L.' surname='Esibov' fullname='Levon Esibov'>
<organization>Microsoft Corporation</organization>
<address>
<postal>
<street>One Microsoft Way</street>
<city>Redmond</city>
<region>WA</region>
<code>98052</code>
<country>US</country></postal>
<email>levone@microsoft.com</email></address></author>
<date year='2000' month='February' />
<abstract>
<t>This document describes a DNS RR which specifies the location of the
server(s) for a specific protocol and domain.</t></abstract></front>
<seriesInfo name='RFC' value='2782' />
<format type='TXT' octets='24013' target='ftp://ftp.isi.edu/in-notes/rfc2782.txt' />
</reference>
<reference anchor='MIME'>
<front>
<title abbrev='Internet Message Bodies'>Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies</title>
<author initials='N.' surname='Freed' fullname='Ned Freed'>
<organization>Innosoft International, Inc.</organization>
<address>
<postal>
<street>1050 East Garvey Avenue South</street>
<city>West Covina</city>
<region>CA</region>
<code>91790</code>
<country>US</country></postal>
<phone>+1 818 919 3600</phone>
<facsimile>+1 818 919 3614</facsimile>
<email>ned@innosoft.com</email></address></author>
<author initials='N.S.' surname='Borenstein' fullname='Nathaniel S. Borenstein'>
<organization>First Virtual Holdings</organization>
<address>
<postal>
<street>25 Washington Avenue</street>
<city>Morristown</city>
<region>NJ</region>
<code>07960</code>
<country>US</country></postal>
<phone>+1 201 540 8967</phone>
<facsimile>+1 201 993 3032</facsimile>
<email>nsb@nsb.fv.com</email></address></author>
<date year='1996' month='November' />
<abstract>
<t>STD 11, RFC 822, defines a message representation protocol specifying considerable detail about US-ASCII message headers, and leaves the message content, or message body, as flat US-ASCII text. This set of documents, collectively called the Multipurpose Internet Mail Extensions, or MIME, redefines the format of messages to allow for</t>
<t>(1) textual message bodies in character sets other than US-ASCII,</t>
<t>(2) an extensible set of different formats for non-textual message bodies,</t>
<t>(3) multi-part message bodies, and</t>
<t>(4) textual header information in character sets other than US-ASCII.</t>
<t>These documents are based on earlier work documented in RFC 934, STD 11, and RFC 1049, but extends and revises them. Because RFC 822 said so little about message bodies, these documents are largely orthogonal to (rather than a revision of) RFC 822.</t>
<t>This initial document specifies the various headers used to describe the structure of MIME messages. The second document, RFC 2046, defines the general structure of the MIME media typing system and defines an initial set of media types. The third document, RFC 2047, describes extensions to RFC 822 to allow non-US-ASCII text data in Internet mail header fields. The fourth document, RFC 2048, specifies various IANA registration procedures for MIME-related facilities. The fifth and final document, RFC 2049, describes MIME conformance
criteria as well as providing some illustrative examples of MIME message formats, acknowledgements, and the bibliography.</t>
<t>These documents are revisions of RFCs 1521, 1522, and 1590, which themselves were revisions of RFCs 1341 and 1342. An appendix in RFC 2049 describes differences and changes from previous versions.</t></abstract></front>
<seriesInfo name='RFC' value='2045' />
<format type='TXT' octets='72932' target='ftp://ftp.isi.edu/in-notes/rfc2045.txt' />
</reference>
<reference anchor='SDP'>
<front>
<title>SDP: Session Description Protocol</title>
<author initials='M.' surname='Handley' fullname='M. Handley'>
<organization /></author>
<author initials='V.' surname='Jacobson' fullname='V. Jacobson'>
<organization /></author>
<author initials='C.' surname='Perkins' fullname='C. Perkins'>
<organization /></author>
<date year='2006' month='July' />
<abstract>
<t>This memo defines the Session Description Protocol (SDP). SDP is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. [STANDARDS TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='4566' />
<format type='TXT' octets='108820' target='ftp://ftp.isi.edu/in-notes/rfc4566.txt' />
</reference>
<reference anchor='SIP-MSG'>
<front>
<title>Session Initiation Protocol (SIP) Extension for Instant Messaging</title>
<author initials='B.' surname='Campbell' fullname='B. Campbell'>
<organization /></author>
<author initials='J.' surname='Rosenberg' fullname='J. Rosenberg'>
<organization /></author>
<author initials='H.' surname='Schulzrinne' fullname='H. Schulzrinne'>
<organization /></author>
<author initials='C.' surname='Huitema' fullname='C. Huitema'>
<organization /></author>
<author initials='D.' surname='Gurle' fullname='D. Gurle'>
<organization /></author>
<date year='2002' month='December' />
<abstract>
<t>Instant Messaging (IM) refers to the transfer of messages between users in near real-time. These messages are usually, but not required to be, short. IMs are often used in a conversational mode, that is, the transfer of messages back and forth is fast enough for participants to maintain an interactive conversation. This document proposes the MESSAGE method, an extension to the Session Initiation Protocol (SIP) that allows the transfer of Instant Messages. Since the MESSAGE request is an extension to SIP, it inherits all the request routing and security features of that protocol. MESSAGE requests carry the content in the form of MIME body parts. MESSAGE requests do not themselves initiate a SIP dialog; under normal usage each Instant Message stands alone, much like pager messages. MESSAGE requests may be sent in the context of a dialog initiated by some other SIP request. [STANDARDS TRACK] </t></abstract></front>
<seriesInfo name='RFC' value='3428' />
<format type='TXT' octets='41475' target='ftp://ftp.isi.edu/in-notes/rfc3428.txt' />
</reference>
<reference anchor='SIP-XMPP'>
<front>
<title>Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Core</title>
<author initials='P' surname='Saint-Andre' fullname='Peter Saint-Andre'>
<organization />
</author>
<author initials='A' surname='Houri' fullname='Avshalom Houri'>
<organization />
</author>
<author initials='J' surname='Hildebrand' fullname='Joe Hildebrand'>
<organization />
</author>
<date month='January' day='4' year='2008' />
<abstract><t>As a foundation for the definition of application-specific, bi-directional protocol mappings between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP), this document specifies the architectural assumptions underlying such mappings as well as the mapping of addresses and error conditions.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-saintandre-sip-xmpp-core-00' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-saintandre-sip-xmpp-core-00.txt' />
</reference>
<reference anchor='SIP-XMPP-IM'>
<front>
<title>Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Instant Messaging</title>
<author initials='P' surname='Saint-Andre' fullname='Peter Saint-Andre'>
<organization />
</author>
<author initials='A' surname='Houri' fullname='Avshalom Houri'>
<organization />
</author>
<author initials='J' surname='Hildebrand' fullname='Joe Hildebrand'>
<organization />
</author>
<date month='January' day='4' year='2008' />
<abstract><t>This document defines a bi-directional protocol mapping for the exchange of single instant messages between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP).</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-saintandre-sip-xmpp-im-00' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-saintandre-sip-xmpp-im-00.txt' />
</reference>
<reference anchor="XEP-0045">
<front>
<title>Multi-User Chat</title>
<author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
<organization/>
<address>
<email>stpeter@jabber.org</email>
</address>
</author>
<date day="10" month="April" year="2007"/>
</front>
<seriesInfo name="XSF XEP" value="0045"/>
<format type="HTML" target="http://www.xmpp.org/extensions/xep-0045.html"/>
</reference>
<reference anchor="XEP-0124">
<front>
<title>Bidirectional-streams Over Synchronous HTTP (BOSH)</title>
<author initials="I." surname="Paterson" fullname="Ian Paterson">
<organization/>
<address>
<email>ian.paterson@clientside.co.uk</email>
</address>
</author>
<author initials="D." surname="Smith" fullname="Dave Smith">
<organization/>
<address>
<email>dizzyd@jabber.org</email>
</address>
</author>
<author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
<organization/>
<address>
<email>stpeter@jabber.org</email>
</address>
</author>
<date day="21" month="February" year="2007"/>
</front>
<seriesInfo name="XSF XEP" value="0124"/>
<format type="HTML" target="http://www.xmpp.org/extensions/xep-0124.html"/>
</reference>
<reference anchor="XEP-0184">
<front>
<title>Message Receipts</title>
<author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
<organization/>
<address>
<email/>
</address>
</author>
<author initials="J." surname="Hildebrand" fullname="Joe Hildebrand">
<organization/>
<address>
<email>jhildebrand@jabber.com</email>
</address>
</author>
<date day="26" month="September" year="2007"/>
</front>
<seriesInfo name="XSF XEP" value="0184"/>
<format type="HTML" target="http://www.xmpp.org/extensions/xep-0184.html"/>
</reference>
<reference anchor="XEP-0206">
<front>
<title>XMPP Over BOSH</title>
<author initials="I." surname="Paterson" fullname="Ian Paterson">
<organization/>
<address>
<email>ian.paterson@clientside.co.uk</email>
</address>
</author>
<date day="04" month="June" year="2007"/>
</front>
<seriesInfo name="XSF XEP" value="0206"/>
<format type="HTML" target="http://www.xmpp.org/extensions/xep-0206.html"/>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 02:41:38 |