One document matched: draft-saintandre-sip-xmpp-chat-06.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="1"?>
<rfc category="std" docName="draft-saintandre-sip-xmpp-chat-06" ipr="trust200902">
<front>
<title abbrev="SIP-XMPP Interworking: Chat">Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): One-to-One Text Chat</title>
<author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>1899 Wynkoop Street, Suite 600</street>
<city>Denver</city>
<region>CO</region>
<code>80202</code>
<country>USA</country>
</postal>
<phone>+1-303-308-3282</phone>
<email>psaintan@cisco.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>
<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>
<date/>
<area>RAI</area>
<keyword>Text Chat</keyword>
<keyword>Instant Messaging</keyword>
<keyword>Session Initiation Protocol</keyword>
<keyword>SIP</keyword>
<keyword>Message Sessions Relay Protocol</keyword>
<keyword>MSRP</keyword>
<keyword>Extensible Messaging and Presence Protocol</keyword>
<keyword>XMPP</keyword>
<abstract>
<t>This document defines a bidirectional 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" anchor="intro">
<t>Both the Session Initiation Protocol <xref target="RFC3261"/> and the Extensible Messaging and Presence Protocol <xref target='RFC6120'/> can be used for the purpose of one-to-one text chat over the Internet. To ensure interworking between these technologies, it is important to define bidirectional protocol mappings.</t>
<t>The architectural assumptions underlying such protocol mappings are provided in <xref target='I-D.saintandre-sip-xmpp-core'/>, including mapping of addresses and error conditions. This document specifies mappings for one-to-one text chat sessions (sometimes called "session-mode" messaging); in particular, this document specifies mappings between XMPP messages of type "chat" and the Message Session Relay Protocol <xref target='RFC4975'/>. Mappings for single instant messages and groupchat are provided in separate documents.</t>
<t>The approach taken here is to directly map syntax and semantics from one protocol to another. The mapping described herein depends on the protocols defined in the following specifications:</t>
<t>
<list style='symbols'>
<t>XMPP chat sessions using message stanzas of type "chat" are specified in <xref target="RFC6121"/>.</t>
<t>SIP-based chat sessions using the SIP INVITE and SEND request types are specified in <xref target='RFC4975'/>.</t>
</list>
</t>
<t>In SIMPLE, a chat session is formally negotiated just as any other session type is using SIP. By contrast, a one-to-one chat "session" in XMPP is an informal construct and is not formally negotiated: a user simply sends a message of type "chat" to a contact, the contact then replies to the message, and the sum total of such messages exchanged during a defined period of time is considered to be a chat session. To overcome the disparity between these approaches, a gateway that wishes to map between SIP and XMPP for one-to-one chat sessions needs to maintain some additional state, as described below.</t>
<t>The discussion venue for this document is the mailing list of the DISPATCH WG; visit https://www.ietf.org/mailman/listinfo/dispatch for subscription information and discussion archives.</t>
</section>
<section title="Terminology" anchor="terms">
<t>The 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='RFC2119'/>.</t>
</section>
<section title="XMPP to MSRP" anchor="xmpp2msrp">
<t>In XMPP, the "informal session" approach is to simply send someone a <message/> of type "chat" without starting any session negotiation ahead of time (as described in <xref target="RFC6121"/>). The XMPP "informal session" approach maps very well into a SIP MESSAGE request, as described in <xref target="I-D.saintandre-sip-xmpp-core"/>. However, the XMPP informal session approach can also be mapped to MSRP if the XMPP-to-SIP gateway maintains additional state.</t>
<t>The order of events is as follows.</t>
<figure>
<artwork><![CDATA[
XMPP User GW SIP User
| | |
|(F1) (XMPP) Chat message | |
|------------------------->| |
| |(F2) (SIP) INVITE |
| |------------------------->|
| |(F3) (SIP) 200 OK |
| |<-------------------------|
| |(F4) (SIP) ACK |
| |------------------------->|
| |(F5) (MSRP) SEND |
| |------------------------->|
| |(F6) (MSRP) A reply |
| |<-------------------------|
|(F7) (XMPP) A reply | |
|<-------------------------| |
| | |
. . .
. . .
. . .
| | |
| |(F8) (SIP) BYE |
| |<-------------------------|
| |(F9) (SIP) 200 OK |
| |------------------------->|
| | |
]]></artwork>
</figure>
<t>First the XMPP user would generate an XMPP chat message.</t>
<figure>
<preamble>Example: (F1) Juliet sends an XMPP message</preamble>
<artwork><![CDATA[
<message from='juliet@example.com/balcony'
to='romeo@example.net'
type='chat'>
<thread>711609sa</thread>
<body>Art thou not Romeo, and a Montague?</body>
</message>
]]></artwork>
</figure>
<t>The local SIP-to-XMPP gateway at the SIMPLE server would then determine if Romeo supports MSRP. If so, the SIP-to-XMPP gateway would initiate an MSRP session with Romeo on Juliet's behalf.</t>
<figure>
<preamble>Example: (F2) Gateway starts a formal session on behalf of Juliet</preamble>
<artwork><![CDATA[
INVITE sip:romeo@example.net SIP/2.0
To: <sip:romeo@example.net>
From: <sip:juliet@example.com>
Contact: <sip:juliet@example.com>;gr=balcony
Subject: Open chat with Juliet?
Call-ID: 711609sa
Content-Type: application/sdp
c=IN IP4 x2s.example.com
m=message 7654 TCP/MSRP *
a=accept-types:text/plain
a=lang:en
a=lang:it
a=path:msrp://x2s.example.com:7654/jshA7weztas;tcp
]]></artwork>
</figure>
<t>Here we assume that Romeo accepts the MSRP session request.</t>
<figure>
<preamble>Example: (F3) Romeo accepts the request</preamble>
<artwork><![CDATA[
SIP/2.0 200 OK
To: <sip:juliet@example.com>;gr=balcony
From: <sip:romeo@example.net>
Contact: <sip:romeo@example.net>;gr=orchard
Call-ID: 711609sa
Content-Type: application/sdp
c=IN IP4 s2x.example.net
m=message 12763 TCP/MSRP *
a=accept-types:text/plain
a=lang:it
a=path:msrp://s2x.example.net:12763/kjhd37s2s20w2a;tcp
]]></artwork>
</figure>
<t>The XMPP-to-SIP gateway then acknowledges the session acceptance on behalf of Romeo.</t>
<figure>
<preamble>Example: (F4) Gateway sends ACK to Romeo's UA</preamble>
<artwork><![CDATA[
ACK sip:juliet@example.com SIP/2.0
To: <sip:romeo@example.net>;gr=orchard
From: <sip:juliet@example.com>
Contact: <sip:juliet@example.com>;gr=balcony
Call-ID: 711609sa
]]></artwork>
</figure>
<t>The XMPP-to-SIP gateway then transforms the original XMPP chat message into MSRP.</t>
<figure>
<preamble>Example: (F5) Gateway transforms XMPP message to MSRP</preamble>
<artwork><![CDATA[
MSRP a786hjs2 SEND
From-Path: msrp://x2s.example.com:7654/jshA7weztas;tcp
To-Path: msrp://s2x.example.net:12763/kjhd37s2s20w2a;tcp
Message-ID: 87652491
Byte-Range: 1-25/25
Content-Type: text/plain
Art thou not Romeo, and a Montague?
-------a786hjs2$
]]></artwork>
</figure>
<t>Romeo can then send a reply using his MSRP user agent.</t>
<figure>
<preamble>Example: (F6) Romeo sends a reply</preamble>
<artwork><![CDATA[
MSRP a786hjs2 SEND
To-Path: msrp://x2s.example.com:7654/jshA7weztas;tcp
From-Path: msrp://s2x.example.net:12763/kjhd37s2s20w2a;tcp
Message-ID: 87652491
Byte-Range: 1-25/25
Failure-Report: no
Content-Type: text/plain
Neither, fair saint, if either thee dislike.
-------a786hjs2$
]]></artwork>
</figure>
<t>The SIP-to-XMPP gateway would then transform that message into appropriate XMPP syntax for routing to the intended recipient.</t>
<figure>
<preamble>Example: (F7) Gateway transforms MSRP message to XMPP</preamble>
<artwork><![CDATA[
<message from='romeo@example.net/orchard'
to='juliet@example.com/balcony'
type='chat'>
<thread>711609sa</thread>
<body>Neither, fair saint, if either thee dislike.</body>
</message>
]]></artwork>
</figure>
<t>When the MSRP user wishes to end the chat session, the user's MSRP client sends a SIP BYE.</t>
<figure>
<preamble>Example: (F8) Romeo terminates the chat session</preamble>
<artwork><![CDATA[
BYE juliet@example.com sip: SIP/2.0
Max-Forwards: 70
From: <sip:romeo@example.net>;tag=087js
To: <sip:juliet@example.com>;tag=786
Call-ID: 711609sa
Cseq: 1 BYE
Content-Length: 0
]]></artwork>
</figure>
<t>The BYE is then acknowledged by the XMPP-to-SIP gateway.</t>
<figure>
<preamble>Example: (F9) Gateway acknowledges termination</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>
</section>
<section title="MSRP to XMPP" anchor="msrp2xmpp">
<t>When an MSRP client sends messages through a gateway to an XMPP client that does not support formal sessinos, the order of events is as follows.</t>
<figure>
<artwork><![CDATA[
SIP User GW XMPP User
| | |
|(F1)(SIP) INVITE | |
|------------------------>| |
|(F2)(SIP) 200 OK | |
|<------------------------| |
|(F3)(SIP) ACK | |
|------------------------>| |
|(F4)(MSRP) SEND | |
|------------------------>| |
| |(F5)(XMPP) A chat message |
| |------------------------->|
| |(F6)(XMPP) A reply |
| |<-------------------------|
| | |
|(F7)(MSRP) SEND | |
|<------------------------| |
| | |
. . .
. . .
. . .
| | |
|(F8)(SIP) BYE | |
|------------------------>| |
|(F9)(SIP) 200 OK | |
|<------------------------| |
| | |
]]></artwork>
</figure>
<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>
Contact: <sip:romeo@example.net>;gr=orchard
Subject: Open chat with Romeo?
Call-ID: 742507no
Content-Type: application/sdp
c=IN IP4 s2x.example.net
m=message 7313 TCP/MSRP *
a=accept-types:text/plain
a=lang:en
a=lang:it
a=path:msrp://s2x.example.net:7313/ansp71weztas;tcp
]]></artwork>
</figure>
<figure>
<preamble>Example: (F2) Gateway accepts session on Juliet's behalf</preamble>
<artwork><![CDATA[
SIP/2.0 200 OK
To: <sip:romeo@example.net>;gr=orchard
From: <sip:juliet@example.com>
Contact: <sip:juliet@example.com>;gr=balcony
Call-ID: 742507no
Content-Type: application/sdp
c=IN IP4 x2s.example.com
m=message 8763 TCP/MSRP *
a=accept-types:text/plain
a=lang:it
a=path:msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp
]]></artwork>
</figure>
<figure>
<preamble>Example: (F3) Romeo sends ACK</preamble>
<artwork><![CDATA[
ACK sip:juliet@example.com SIP/2.0
To: <sip:juliet@example.com>;gr=balcony
From: <sip:romeo@example.net>
Contact: <sip:romeo@example.net>;gr=orchard
Call-ID: 742507no
]]></artwork>
</figure>
<figure>
<preamble>Example: (F4) Romeo sends a message</preamble>
<artwork><![CDATA[
MSRP ad49kswow SEND
To-Path: msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp
From-Path: msrp://s2x.example.net:7313/ansp71weztas;tcp
Message-ID: 44921zaqwsx
Byte-Range: 1-32/32
Failure-Report: no
Content-Type: text/plain
I take thee at thy word ...
-------ad49kswow$
]]></artwork>
</figure>
<figure>
<preamble>Example: (F5) Romeo sends a message (XMPP translation)</preamble>
<artwork><![CDATA[
<message from='romeo@example.net'
to='juliet@example.com'
type='chat'>
<thread>742507no</thread>
<body>I take thee at thy word ...</body>
</message>
]]></artwork>
</figure>
<figure>
<preamble>Example: (F6) Juliet sends a reply</preamble>
<artwork><![CDATA[
<message from='juliet@example.com'
to='romeo@example.net'
type='chat'>
<thread>711609sa</thread>
<body>What man art thou ...?</body>
</message>
]]></artwork>
</figure>
<figure>
<preamble>Example: (F8) Gateway transforms XMPP message to MSRP</preamble>
<artwork><![CDATA[
MSRP a786hjs2 SEND
To-Path: msrp://s2x.example.net:7313/jshA7weztas;tcp
From-Path: msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp
Message-ID: 87652491
Byte-Range: 1-25/25
Failure-Report: no
Content-Type: text/plain
What man art thou ...?
-------a786hjs2$
]]></artwork>
</figure>
<figure>
<preamble>Example: (F9) Romeo terminates the session</preamble>
<artwork><![CDATA[
BYE juliet@example.com sip: SIP/2.0
Max-Forwards: 70
To: <sip:juliet@example.com>;gr=balcony
From: <sip:romeo@example.net>
Contact: <sip:romeo@example.net>;gr=orchard
Call-ID: 742507no
Cseq: 1 BYE
Content-Length: 0
]]></artwork>
</figure>
<figure>
<preamble>Example: (F10) Gateway acknowledges the termination of the session on behalf of XMPP user</preamble>
<artwork><![CDATA[
SIP/2.0 200 OK
To: <sip:juliet@example.com>;gr=balcony
From: <sip:romeo@example.net>
Contact: <sip:romeo@example.net>;gr=orchard
Call-ID: 742507no
CSeq: 1 BYE
]]></artwork>
</figure>
</section>
<section title="Security Considerations" anchor="security">
<t>Detailed security considerations for instant messaging protocols are given in <xref target='RFC2779'/>, for SIP-based instant messaging in <xref target="RFC3428"/> (see also <xref target="RFC3261"/>), and for XMPP-based instant messaging in <xref target="RFC6121"/> (see also <xref target="RFC6120"/>).</t>
<t>This document specifies methods for exchanging instant messages through a gateway that translates between SIP and XMPP. Such a gateway MUST be compliant with the minimum security requirements of the instant messaging protocols for which it translates (i.e., SIP and XMPP). The addition of gateways to the security model of instant messaging specified in <xref target="RFC2779"/> introduces some new risks. In particular, end-to-end security properties (especially confidentiality and integrity) between instant messaging user agents that interface through a SIMPLE-XMPP gateway can be provided only if common formats are supported. Specification of those common formats is out of scope for this document, although it is recommended to use <xref target="RFC3862"/> for instant messages.</t>
</section>
<section title="IANA Considerations" anchor="iana">
<t>This document requests no actions of IANA.</t>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor='I-D.saintandre-sip-xmpp-core'>
<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='June' day='13' year='2013' />
<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-05' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-saintandre-sip-xmpp-core-05.txt' />
</reference>
<reference anchor='RFC2119'>
<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='RFC3261'>
<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="RFC3862">
<front>
<title>Common Presence and Instant Messaging (CPIM): Message Format</title>
<author initials='G.' surname='Klyne' fullname='G. Klyne'>
<organization /></author>
<author initials='D.' surname='Atkins' fullname='D. Atkins'>
<organization /></author>
<date year='2004' month='August' /></front>
<seriesInfo name='RFC' value='3862' />
<format type='TXT' octets='56133' target='ftp://ftp.isi.edu/in-notes/rfc3862.txt' />
</reference>
<reference anchor='RFC4975'>
<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='RFC6120'>
<front>
<title>Extensible Messaging and Presence Protocol (XMPP): Core</title>
<author initials='P.' surname='Saint-Andre' fullname='P. Saint-Andre'>
<organization /></author>
<date year='2011' month='March' />
<abstract>
<t>The Extensible Messaging and Presence Protocol (XMPP) is an application profile of the Extensible Markup Language (XML) that enables the near-real-time exchange of structured yet extensible data between any two or more network entities. This document defines XMPP's core protocol methods: setup and teardown of XML streams, channel encryption, authentication, error handling, and communication primitives for messaging, network availability ("presence"), and request-response interactions. This document obsoletes RFC 3920. [STANDARDS-TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='6120' />
<format type='TXT' octets='451942' target='http://www.rfc-editor.org/rfc/rfc6120.txt' />
</reference>
<reference anchor='RFC6121'>
<front>
<title>Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence</title>
<author initials='P.' surname='Saint-Andre' fullname='P. Saint-Andre'>
<organization /></author>
<date year='2011' month='March' />
<abstract>
<t>This document defines extensions to core features of the Extensible Messaging and Presence Protocol (XMPP) that provide basic instant messaging (IM) and presence functionality in conformance with the requirements in RFC 2779. This document obsoletes RFC 3921. [STANDARDS-TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='6121' />
<format type='TXT' octets='244800' target='http://www.rfc-editor.org/rfc/rfc6121.txt' />
</reference>
</references>
<references title='Informative References'>
<reference anchor="RFC2779">
<front>
<title abbrev='Instant Messaging/Presence Protocol'>Instant Messaging / Presence Protocol Requirements</title>
<author initials='M.' surname='Day' fullname='Mark Day'>
<organization>SightPath, Inc.</organization>
<address>
<postal>
<street>135 Beaver Street</street>
<city>Waltham</city>
<region>MA</region>
<code>02452</code>
<country>US</country></postal>
<email>mday@alum.mit.edu</email></address></author>
<author initials='S.' surname='Aggarwal' fullname='Sonu Aggarwal'>
<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>sonuag@microsoft.com</email></address></author>
<author initials='J.' surname='Vincent' fullname='Jesse Vincent'>
<organization>Into Networks, Inc.</organization>
<address>
<postal>
<street>150 Cambridgepark Drive</street>
<city>Cambridge</city>
<region>MA</region>
<code>02140</code>
<country>US</country></postal>
<email>jesse@intonet.com</email></address></author>
<date month='February' year='2000' />
<abstract>
<t>Presence and Instant Messaging have recently emerged as a new medium of communications over the Internet. Presence is a means for finding, retrieving, and subscribing to changes in the presence information (e.g. "online" or "offline") of other users. Instant messaging is a means for sending small, simple messages that are delivered immediately to online users.</t>
<t>Applications of presence and instant messaging currently use independent, non-standard and non-interoperable protocols developed by various vendors. The goal of the Instant Messaging and Presence Protocol (IMPP) Working Group is to define a standard protocol so that independently developed applications of instant messaging and/or presence can interoperate across the Internet. This document defines a minimal set of requirements that IMPP must meet.</t></abstract></front>
<seriesInfo name='RFC' value='2779' />
<format type='TXT' octets='47420' target='ftp://ftp.isi.edu/in-notes/rfc2779.txt' />
</reference>
<reference anchor='RFC3428'>
<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>
</references>
<section title="Acknowledgements" anchor="acks">
<t>Some text in this document was borrowed from <xref target='I-D.saintandre-sip-xmpp-core'/>.</t>
<t>Thanks to Adrian Georgescu, Saul Ibarra, and Tory Patnoe for their feedback.</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 02:40:02 |