source: draft-ietf-stox-groupchat.xml

Last change on this file was 82, checked in by stpeter@…, 8 years ago

content-length fixes

  • Property svn:mime-type set to application/xml
File size: 90.2 KB
Line 
1<?xml version="1.0" encoding="us-ascii"?>
2<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
3<?rfc compact="yes"?>
4<?rfc sortrefs="yes"?>
5<?rfc strict="yes"?>
6<?rfc symrefs="yes"?>
7<?rfc toc="yes"?>
8<?rfc tocdepth="3"?>
9<rfc category="std" docName="draft-ietf-stox-groupchat-04" ipr="trust200902">
10
11  <front>
12    <title abbrev="SIP-XMPP Interworking: Groupchat">Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Groupchat</title>
13    <author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
14      <organization>&amp;yet</organization>
15      <address>
16        <postal>
17          <street>P.O. Box 787</street>
18          <city>Parker</city>
19          <region>CO</region>
20          <code>80134</code>
21          <country>USA</country>
22        </postal>
23        <email>ietf@stpeter.im</email>
24      </address>
25    </author>
26    <author initials="S." surname="Ibarra" fullname="Saul Ibarra Corretge">
27      <organization>AG Projects</organization>
28      <address>
29        <postal>
30          <street>Dr. Leijdsstraat 92</street>
31          <code>2021RK</code>
32          <city>Haarlem</city>
33          <country>The Netherlands</country>
34         </postal>
35        <email>saul@ag-projects.com</email>
36      </address>
37    </author>
38    <author initials="S." surname="Loreto" fullname="Salvatore Loreto">
39      <organization>Ericsson</organization>
40      <address>
41        <postal>
42          <street>Hirsalantie 11</street>
43          <code>02420</code>
44          <city>Jorvas</city>
45          <country>Finland</country>
46         </postal>
47        <email>Salvatore.Loreto@ericsson.com</email>
48      </address>
49    </author>
50    <date/>
51    <area>RAI</area>
52    <keyword>Text Chat</keyword>
53    <keyword>Groupchat</keyword>
54    <keyword>Instant Messaging</keyword>
55    <keyword>Session Initiation Protocol</keyword>
56    <keyword>SIP</keyword>
57    <keyword>Message Sessions Relay Protocol</keyword>
58    <keyword>MSRP</keyword>
59    <keyword>Extensible Messaging and Presence Protocol</keyword>
60    <keyword>XMPP</keyword>
61    <abstract>
62      <t>This document defines a bidirectional protocol mapping for the exchange of instant messages in the context of a multiparty chat session among users of the Session Initiation Protocol (SIP) and users of the Extensible Messaging and Presence Protocol (XMPP).  Specifically, this document defines a mapping between the SIP-based Message Session Relay Protocol (MSRP) and the XMPP Multi-User Chat (MUC) extension.</t>
63    </abstract>
64  </front>
65
66  <middle>
67
68    <section title="Introduction" anchor="intro">
69      <t>Both the Session Initiation Protocol (SIP) <xref target="RFC3261"/> and the Extensible Messaging and Presence Protocol (XMPP) <xref target="RFC6120"/> can be used for the purpose of multiparty text chat over the Internet.  To ensure interworking between these technologies, it is important to define bidirectional protocol mappings.</t>
70      <t>The architectural assumptions underlying such protocol mappings are provided in <xref target="I-D.ietf-stox-core"/>, including mapping of addresses and error conditions.  This document specifies mappings for multiparty text chat sessions (often called "groupchat"); specifically, this document defines a mapping between the XMPP Multi-User Chat (MUC) extension <xref target='XEP-0045'/> and SIP-based multiparty chat using Message Session Relay Protocol <xref target="RFC4975"/> as specified in <xref target="I-D.ietf-simple-chat"/>.</t>
71      <t>Both MUC and MSRP contain a large set of features, such as the ability to administer rooms, kick and ban users, reserve a nickname within a room, change room subject, enable room moderation, and destroy the room.  This document covers only a basic subset of groupchat features: joining a room, establishing or changing (but not permanently registering) a room nickname, modifying presence information within the room, sending a message to all participants, sending a private message to a single participant, inviting another user to the room, and leaving the room.  Future documents might define mappings for additional features beyond this set.</t>
72    </section>
73
74    <section title="Intended Audience" anchor="audience">
75      <t>The documents in this series are intended for use by software developers who have an existing system based on one of these technologies (e.g., SIP), and would like to enable communication from that existing system to systems based on the other technology (e.g., XMPP).  We assume that readers are familiar with the core specifications for both SIP <xref target='RFC3261'/> and XMPP <xref target='RFC6120'/>, with the base document for this series <xref target='I-D.ietf-stox-core'/>, and with the following groupchat-related specifications:</t>
76      <t>
77        <list style='symbols'>
78          <t>The Message Session Relay Protocol (MSRP) <xref target='RFC4975'/></t>
79          <t>Multi-User Chat <xref target='XEP-0045'/></t>
80        </list>
81      </t>
82    </section>
83
84    <section title="Terminology" anchor="terms">
85      <t>A number of technical terms used here are defined in <xref target="RFC3261"/>, <xref target="RFC4975"/>, <xref target="RFC6120"/>, and <xref target='XEP-0045'/>.  The term "JID" is short for "Jabber ID".</t>
86      <t>In flow diagrams, SIP/MSRP traffic is shown using arrows such as "***&gt;" whereas XMPP traffic is shown using arrows such as "...&gt;".</t>
87      <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>
88    </section>
89
90    <section title="XMPP MUC to MSRP Multi-party Messaging Session" anchor="muc2msrp">
91      <t>This section describes how to map an XMPP MUC session to an MSRP Multi-party Messaging session.  The following diagram outlines the overall protocol flow of a sample session, which includes some optional exchanges (such as sending messages, changing nickname, and inviting another user).</t>
92      <figure>
93        <artwork><![CDATA[
94XMPP        XMPP      XMPP-to-MSRP   MSRP-to-XMPP    MSRP
95User       Server       Gateway        Gateway    Conference
96 |            |            |              |            |
97 | (F1) XMPP  |            |              |            |
98 | enter room |            |              |            |
99 |...........>|            |              |            |
100 |            | (F2) XMPP  |              |            |
101 |            | enter room |              |            |
102 |            |...........>|              |            |
103 |            |            | (F3) SIP INVITE           |
104 |            |            |**************************>|
105 |            |            |              | (F4) SIP   |
106 |            |            |              | 200 OK     |
107 |            |            |              |<***********|
108 |            |            |              | (F5) SIP   |
109 |            |            |              | 200 OK     |
110 |            |            |              |<***********|
111 |            |            |              | (F6) SIP   |
112 |            |            |              | ACK        |
113 |            |            |              |***********>|
114 |            |            |              | (F7) MSRP  |
115 |            |            |              | NICKNAME   |
116 |            |            |              |***********>|
117 |            |            |              | (F8) MSRP  |
118 |            |            |              | 200 OK     |
119 |            |            |              |<***********|
120 |            |            |              | (F9) SIP   |
121 |            |            |              | SUBSCRIBE  |
122 |            |            |              | Event:     |
123 |            |            |              | conference |
124 |            |            |              |***********>|
125 |            |            |              | (F10) SIP  |
126 |            |            |              | 200 OK     |
127 |            |            |              |<***********|
128 |            |            |              | (F11) SIP  |
129 |            |            |              | NOTIFY     |
130 |            |            |              |<***********|
131 |            |            |              | (F12) SIP  |
132 |            |            |              | 200 OK     |
133 |            |            |              |***********>|
134 |            | (F13) XMPP presence       |            |
135 |            |<..........................|            |
136 | (F14) XMPP |            |              |            |
137 | presence   |            |              |            |
138 |<...........|            |              |            |
139 | (F15) XMPP |            |              |            |
140 | MUC subject|            |              |            |
141 |<...........|            |              |            |
142 .            .            .              .            .
143 .            .            .              .            .
144 | (F16) XMPP |            |              |            |
145 | groupchat  |            |              |            |
146 | message    |            |              |            |
147 |...........>|            |              |            |
148 |            | (F17) XMPP |              |            |
149 |            | groupchat  |              |            |
150 |            | message    |              |            |
151 |            |...........>|              |            |
152 |            |            | (F18) MSRP SEND           |
153 |            |            |**************************>|
154 |            |            |              | (F19) MSRP |
155 |            |            |              | 200 OK     |
156 |            |            |              |<***********|
157 |            | (F20) XMPP groupchat      |            |
158 |            | message                   |            |
159 |            |<..........................|            |
160 | (F21) XMPP |            |              |            |
161 | groupchat  |            |              |            |
162 | message    |            |              |            |
163 |<...........|            |              |            |
164 .            .            .              .            .
165 .            .            .              .            .
166 | (F22) XMPP |            |              |            |
167 | private    |            |              |            |
168 | message    |            |              |            |
169 |...........>|            |              |            |
170 |            | (F23) XMPP |              |            |
171 |            | private    |              |            |
172 |            | message    |              |            |
173 |            |...........>|              |            |
174 |            |            | (F24) MSRP SEND           |
175 |            |            |**************************>|
176 |            |            |              | (F25) MSRP |
177 |            |            |              | 200 OK     |
178 |            |            |              |<***********|
179 .            .            .              .            .
180 .            .            .              .            .
181 | (F26) XMPP |            |              |            |
182 | presence:  |            |              |            |
183 | change nick|            |              |            |
184 |...........>|            |              |            |
185 |            | (F27) XMPP |              |            |
186 |            | presence:  |              |            |
187 |            | change nick|              |            |
188 |            |...........>|              |            |
189 |            |            | (F28) MSRP NICKNAME       |
190 |            |            |**************************>|
191 |            |            |              | (F29) MSRP |
192 |            |            |              | 425 Error  |
193 |            |            |              |<***********|
194 |            | (F30) XMPP presence error |            |
195 |            |<..........................|            |
196 | (F31) XMPP |            |              |            |
197 | presence   |            |              |            |
198 | error      |            |              |            |
199 |<...........|            |              |            |
200 .            .            .              .            .
201 .            .            .              .            .
202 | (F32) XMPP |            |              |            |
203 | message:   |            |              |            |
204 | invite     |            |              |            |
205 |...........>|            |              |            |
206 |            | (F33) XMPP |              |            |
207 |            | message:   |              |            |
208 |            | invite     |              |            |
209 |            |...........>|              |            |
210 |            |            | (F34) SIP REFER           |
211 |            |            |**************************>|
212 |            |            |              | (F35) SIP  |
213 |            |            |              | 200 OK     |
214 |            |            |              |<***********|
215 |            |            |              | (F36) SIP  |
216 |            |            |              | NOTIFY     |
217 |            |            |              |<***********|
218 .            .            .              .            .
219 .            .            .              .            .
220 | (F37) XMPP |            |              |            |
221 | presence:  |            |              |            |
222 | exit room  |            |              |            |
223 |...........>|            |              |            |
224 |            | (F38) XMPP |              |            |
225 |            | presence:  |              |            |
226 |            | exit room  |              |            |
227 |            |...........>|              |            |
228 |            |            | (F39) SIP BYE             |
229 |            |            |**************************>|
230 |            |            |              | (F40) SIP  |
231 |            |            |              | 200 OK     |
232 |            |            |              |<***********|
233 |            | (F41) presence unavailable|            |
234 |            |<..........................|            |
235 | (F42) XMPP |            |              |            |
236 | presence   |            |              |            |
237 | unavailable|            |              |            |
238 |<...........|            |              |            |
239 |            |            |              |            |
240        ]]></artwork>
241      </figure>
242      <t>Detailed protocol flows and mappings are provided in the following sections.</t>
243
244      <section title="Enter Room" anchor="muc2msrp-enter">
245        <t>As defined in the XMPP Multi-User Chat (MUC) specification <xref target='XEP-0045'/>, when an XMPP user (say, "juliet@example.com") wants to join a groupchat room (say, "verona@chat.example.org"), she sends a directed &lt;presence/&gt; stanza <xref target='RFC6121'/> to that chat room.  In her request she also specifies the nickname she wants to use within the room (say, "JuliC"); in XMPP this room nickname is the resourcepart of an occupant JID (thus "verona@chat.example.org/JuliC").  The joining client signals its ability to speak the multi-user chat protocol by including in the initial presence stanza an empty &lt;x/&gt; element qualified by the 'http://jabber.org/protocol/muc' namespace.</t>
246        <figure>
247          <preamble>Example 1: Juliet enters room (F1)</preamble>
248          <artwork><![CDATA[
249|  <presence from='juliet@example.com/balcony'
250|            to='verona@chat.example.org/JuliC'>
251|    <x xmlns='http='http://jabber.org/protocol/muc'/>
252|  </presence>
253          ]]></artwork>
254        </figure>
255        <t>Upon receiving such a presence stanza, the XMPP server needs to determine the identity of the domainpart in the 'to' address, which it does by following the procedures discussed in <xref target='I-D.ietf-stox-core'/>.  Here we assume that the XMPP server has determined the domain is serviced by a SIP server, that it contains or has available to it an XMPP-to-SIP gateway or connection manager (which enables it to speak natively to SIP servers), and that it hands off the presence stanza to the XMPP-to-SIP gateway.</t>
256        <t>Because a multi-user chat service accepts the presence stanza shown above as a request to enter a room, the XMPP-to-SIP gateway transforms it into a SIP INVITE request.</t>
257        <figure>
258          <preamble>Example 2: SIP mapping of room join (F2)</preamble>
259          <artwork><![CDATA[
260|  INVITE sip:verona@chat.example.org SIP/2.0
261|  To: <sip:verona@chat.example.org>
262|  From: "Juliet" <sip:juliet@example.com>
263|  Contact: <sip:juliet@example.com>;gr=balcony
264|  Call-ID: BC466C1C-E01D-4FD1-B766-9AD174BAF2E7
265|  Content-Type: application/sdp
266|  Content-Length: ...
267|
268|  c=IN IP4 x2s.example.org
269|  m=message 7654 TCP/MSRP *
270|  a=accept-types:text/cpim
271|  a=accept-wrapped-types:text/plain text/html
272|  a=path:msrp://x2s.example.com:7654/jshA7weztas;tcp
273|  a=chatroom
274          ]]></artwork>
275        </figure>
276        <t>Here the Session Description Protocol offer specifies the MSRP-aware XMPP-to-SIP gateway on the XMPP side as well as other particulars of the session.</t>
277        <t><list style="empty"><t>There is no direct mapping for the MSRP URIs.  In fact MSRP URIs identify a session of instant messages at a particular device; they are ephemeral and have no meaning outside the scope of that session.  The authority component of the MSRP URI MUST contain the XMPP-to-SIP gateway hostname or numeric IP address and an explicit port number.</t></list></t>
278        <t>As specified in <xref target="I-D.ietf-stox-core"/>, the mapping of XMPP syntax elements to SIP and <xref target='RFC4566'/> syntax elements is as shown in the following table.</t>
279        <figure>
280          <preamble>Table 1: Message syntax mapping from XMPP to SIP/SDP</preamble>
281          <artwork><![CDATA[
282    +-----------------------------+-----------------------------+
283    |  XMPP Element or Attribute  |  SIP Header or SDP Contents |
284    +-----------------------------+-----------------------------+
285    |  from                       |  From                       |
286    |  <thread/>                  |  Call-ID                    |
287    |  to (without the /nick)     |  To                         |
288    +-----------------------------+-----------------------------+
289          ]]></artwork>
290        </figure>
291        <t>Here we assume that the MSRP conference server accepts the session establishment. It includes the 'isfocus' and other relevant feature tags in the Contact header field of the response. The MSRP conference server also includes an answer session description that acknowledges the choice of media and contains the extensions specified in <xref target="I-D.ietf-simple-chat"/>.</t>
292        <figure>
293          <preamble>Example 3: Chat room accepts session establishment (F4)</preamble>
294          <artwork><![CDATA[
295|  SIP/2.0 200 OK
296|  From: <sip:verona@chat.example.org>
297|  To: "Juliet" <sip:juliet@example.com>;tag=786
298|  Call-ID: BC466C1C-E01D-4FD1-B766-9AD174BAF2E7
299|  Contact: <sip:verona@chat.example.org;transport=tcp>;isfocus
300|  Content-Type: application/sdp
301|  Content-Length: ...
302|
303|  c=IN IP4 example.org
304|  m=message 12763 TCP/MSRP *
305|  a=chatroom:nickname private-messages
306|  a=accept-types:message/cpim
307|  a=accept-wrapped-types:text/plain text/html
308|  a=path:msrp://s2x.example.org:12763/kjhd37s2s20w2a;tcp
309         ]]></artwork>
310        </figure>
311        <t>Upon receiving such a response, the SIP server or associated SIP-to-XMPP gateway sends a SIP ACK to the MSRP conference server on behalf of the joining user.</t>
312        <figure>
313          <preamble>Example 4: Gateway sends ACK to MSRP conference server (F6)</preamble>
314          <artwork><![CDATA[
315|  ACK sip:verona@chat.example.org SIP/2.0
316|  To: <sip:verona@chat.example.org>;tag=087js
317|  From: "Juliet" <sip:juliet@example.com>;tag=786
318|  Call-ID: BC466C1C-E01D-4FD1-B766-9AD174BAF2E7
319          ]]></artwork>
320        </figure>
321      </section>
322
323      <section title="Set Nickname" anchor="muc2msrp-nicksetup">
324        <t>If the chat room server accepted the session, the SIMPLE server or associated SIP-to-XMPP gateway MUST set up the nickname as received in the presence stanza (i.e., the resourcepart of the 'to' address, such "JuliC" in "verona@chat.example.org/JuliC").  The nickname is set up using the extension specified in <xref target="I-D.ietf-simple-chat"/>.</t>
325        <figure>
326          <preamble>Example 5: Gateway sets up nickname (F7)</preamble>
327          <artwork><![CDATA[
328|  MSRP a786hjs2 NICKNAME
329|  To-Path: msrp://s2x.example.org:12763/kjhd37s2s20w2a;tcp
330|  From-Path: msrp://x2s.example.com:7654/jshA7weztas;tcp
331|  Use-Nickname: "JuliC"
332|  -------a786hjs2
333          ]]></artwork>
334        </figure>
335        <t>The MSRP conference server analyzes the existing allocation of nicknames, accepts the nickname proposal, and answers with a 200 response.</t>
336        <figure>
337          <preamble>Example 6: MSRP conference accepts nickname proposal (F8)</preamble>
338          <artwork><![CDATA[
339|  MSRP a786hjs2 200 OK
340|  To-Path: msrp://x2s.example.com:7654/jshA7weztas;tcp
341|  From-Path: msrp://s2x.example.org:12763/kjhd37s2s20w2a;tcp
342|  -------a786hjs2
343          ]]></artwork>
344        </figure>
345        <t>This section assumes that the nickname request is successful.  The error flow resulting from a nickname conflict is described under <xref target='muc2msrp-nickChange'/>.</t>
346      </section>
347
348      <section title="Conference Subscription" anchor="muc2msrp-sub">
349        <t>If the nickname request is successful, the XMPP-to-SIP gateway then formally subscribes to the MSRP conference on behalf of the XMPP user.</t>
350        <figure>
351          <preamble>Example 7: Gateway subscribes to the MSRP conference (F9)</preamble>
352          <artwork><![CDATA[
353|  SUBSCRIBE sip:verona@chat.example.org SIP/2.0
354|  To: <sip:verona@chat.example.org>
355|  From: "Juliet" <sip:juliet@example.com>
356|  Contact: <sip:juliet@example.com>;gr=balcony
357|  Call-ID: A260DEBD-4F1F-45D1-A2C0-3696636F6417
358|  Event: conference
359|  Expires: 600
360|  Accept: application/conference-info+xml
361|  Allow-Events: conference
362|  Content-Length: 0
363          ]]></artwork>
364        </figure>
365        <t>The conference server will accept or reject the request based on local policy.</t>
366        <figure>
367          <preamble>Example 8: MSRP conference server accepts subscription request (F10)</preamble>
368          <artwork><![CDATA[
369|  SIP/2.0 200 OK
370|  To: <sip:verona@chat.example.org>
371|  From: "Juliet" <sip:juliet@example.com>
372|  Call-ID: A260DEBD-4F1F-45D1-A2C0-3696636F6417
373|  Contact: <sip:verona@chat.example.org;transport=tcp>;isfocus
374|  Allow: SUBSCRIBE, NOTIFY, PRACK, INVITE, ACK, BYE,
375|         CANCEL, UPDATE, MESSAGE, REFER
376|  Expires: 600
377|  Content-Length: 0
378          ]]></artwork>
379        </figure>
380      </section>
381
382      <section title="Presence Broadcast" anchor="muc2msrp-presence">
383        <t>If the MSRP conference service accepts the request to enter a room, the XMPP user expects to receive back presence information from all the existing occupants of the room.  So the XMPP-to-SIP gateway MUST subscribe to the Conference Event package <xref target="RFC4575"/> on the MSRP conference server.  When the subscription is completed the MSRP conference server sends to the XMPP-to-SIP gateway a NOTIFY containing the presence information of all the existing occupants, represented using the <xref target='RFC4575'/> format.</t>
384        <figure>
385          <preamble>Example 9: MSRP conference sends presence information (F11)</preamble>
386          <artwork><![CDATA[
387|  NOTIFY sip:verona@chat.example.org SIP/2.0
388|  To: "Juliet" <sip:juliet@example.com>;gr=balcony
389|  From: <sip:verona@chat.example.org>;tag=a3343df32
390|  Call-ID: 6F563BA1-8177-4CED-8710-78D4D9593B08
391|  Event: conference
392|  Subscription-State: active;expires=3600
393|  Content-Type: application/conference-info+xml
394|  Content-Length: ...
395|
396|  <conference-info version="0" state="full"
397|      entity="sip:3402934234@chat.example.org">
398|    <conference-description>
399|      <subject>Today in Verona</subject>
400|      <conf-uris>
401|        <entry>
402|          <uri>tel:+18882934234</uri>
403|        </entry>
404|      </conf-uris>
405|    </conference-description>
406|    <users>
407|      <user entity="sip:verona@chat.example.org;gr=Romeo"
408|            state="full">
409|        <display-text>Romeo</display-text>
410|        <roles>
411|          <entry>participant</entry>
412|        </roles>
413|        <associated-aors>
414|          <entry>
415|            <uri>xmpp:romeo@example.com/orchard</uri>
416|          </entry>
417|        </associated-aors>
418|        <endpoint entity="sip:verona@chat.example.org;gr=Romeo"
419|                  state="full">
420|          <status>connected</status>
421|          <joining-info>
422|            <when>2013-12-12T10:01:03.691128+01:00</when>
423|          </joining-info>
424|          <media id="211835820">
425|            <type>message</type>
426|          </media>
427|        </endpoint>
428|      </user>
429|      <user entity="sip:verona@chat.example.org;gr=Ben"
430|            state="full">
431|        <display-text>Ben</display-text>
432|        <roles>
433|          <entry>participant</entry>
434|        </roles>
435|        <endpoint entity="sip:verona@chat.example.org;gr=Ben"
436|                  state="full">
437|          <status>connected</status>
438|          <media id="211835821">
439|            <type>message</type>
440|          </media>
441|        </endpoint>
442|      </user>
443|      <user entity="sip:verona@chat.example.org;gr=JuliC"
444|            state="full">
445|        <display-text>JuliC</display-text>
446|        <roles>
447|          <entry>participant</entry>
448|        </roles>
449|         <endpoint entity="sip:verona@chat.example.org;gr=JuliC"
450|                   state="full">
451|           <status>connected</status>
452|           <media id="211835822">
453|             <type>message</type>
454|           </media>
455|         </endpoint>
456|      </user>
457|    </users>
458|  </conference-info>
459          ]]></artwork>
460        </figure>
461        <t>The following table shows the syntax mapping from the RFC 4575 payload to the XMPP participant list. (Mappings for elements not mentioned are undefined.)</t>
462        <figure>
463          <preamble>Table 2: Participant list mapping</preamble>
464          <artwork><![CDATA[
465    +--------------------------------+-----------------------------+
466    |  RFC 4575 Element              |  XMPP Element or Attribute  |
467    +--------------------------------+-----------------------------+
468    |  conference-info entity        |  room JID                   |
469    |  conference subject            |  room subject               |
470    |  user entity                   |  occupant JID               |
471    |  user display-text / nickname  |  participant nickname       |
472    |  endpoint entity               |  occupant JID               |
473    |  user associated-aors          |  user full JID (if avail.)  |
474    +--------------------------------+-----------------------------+
475          ]]></artwork>
476        </figure>
477        <t>Upon receiving such a response, the SIP-to-XMPP gateway MUST send a 200 OK to the MSRP conference server and translate the participant list into a series of XMPP presence stanzas.</t>
478        <figure>
479          <preamble>Example 10: XMPP mapping of chatroom presence (F11)</preamble>
480          <artwork><![CDATA[
481|  <presence from='verona@chat.example.org/Romeo'
482|            to='juliet@example.com/balcony'>
483|    <x xmlns='http://jabber.org/protocol/muc#user'>
484|      <item affiliation='none' role='participant'/>
485|    </x>
486|  </presence>
487
488|  <presence from='verona@chat.example.org/Ben'
489|            to='juliet@example.com/balcony'>
490|    <x xmlns='http://jabber.org/protocol/muc#user'>
491|      <item affiliation='none' role='participant'/>
492|    </x>
493|  </presence>
494
495|  <presence from='verona@chat.example.org/JuliC'
496|            to='juliet@example.com/balcony'>
497|    <x xmlns='http://jabber.org/protocol/muc#user'>
498|      <item affiliation='none' role='participant'/>
499|      <status code='110'/>
500|    </x>
501|  </presence>
502          ]]></artwork>
503        </figure>
504        <t>If the NOTIFY included a subject, the gateway converts that into a separate XMPP message.</t>
505        <figure>
506          <preamble>Example 11: XMPP mapping of chatroom subject (F12)</preamble>
507          <artwork><![CDATA[
508|  <message from='verona@chat.example.com/mayor'
509|           to='juliet@example.com/balcony'
510|           id='mbh2vd68'>
511|    <subject>Today in Verona</subject>
512|  </message>
513          ]]></artwork>
514        </figure>
515        <t>The mapping of SIP and <xref target='RFC4575'/> payload syntax elements to XMPP syntax elements is as shown in the following table.  (Mappings for elements not mentioned are undefined.)</t>
516        <figure>
517          <preamble>Table 3: Message syntax mapping from SIP to XMPP</preamble>
518          <artwork><![CDATA[
519    +---------------------------------+-----------------------------+
520    | SIP Header or RFC4575 Contents  | XMPP Element or Attribute   |
521    +---------------------------------+-----------------------------+
522    |  <user entity=...>              |  from                       |
523    |  Call-ID                        |  thread                     |
524    |  To + / <display-text>          |  to                         |
525    |  roles                          |  role                       |
526    |  'none'                         |  affiliation                |
527    +---------------------------------+-----------------------------+
528          ]]></artwork>
529        </figure>
530      </section>
531
532      <section title="Exchange Messages" anchor="muc2msrp-message">
533        <t>Once the user has joined the chatroom, the user can exchange an unbounded number of messages, both public and private.</t>
534        <t>The mapping of XMPP syntax elements to MSRP syntax elements is as shown in the following table.  (Mappings for elements not mentioned are undefined.)</t>
535        <figure>
536          <preamble>Table 4: Message syntax mapping from XMPP Message to MSRP</preamble>
537          <artwork><![CDATA[
538    +-----------------------------+-----------------------------+
539    |  XMPP Element or Attribute  |  CPIM Header                |
540    +-----------------------------+-----------------------------+
541    |  to                         |  To                         |
542    |  from                       |  From                       |
543    |  <body/>                    |  body of the SEND request   |
544    +-----------------------------+-----------------------------+
545          ]]></artwork>
546        </figure>
547
548        <section title="Send a Message to All Occupants" anchor="muc2msrp-message-all">
549          <t>When Juliet wants to sends a message to all other occupants in the room, she sends a message of type "groupchat" to the &lt;room@service&gt; itself (in our example, &lt;verona@chat.example.org&gt;).</t>
550          <t>The following examples show an exchange of a public message.</t>
551          <figure>
552            <preamble>Example 12: Juliet sends message to all occupants (F16)</preamble>
553            <artwork><![CDATA[
554|  <message from='juliet@example.com/balcony'
555|           to='verona@chat.example.org'
556|           type='groupchat'
557|           id='lzfed24s'>
558|        <body>Who knows where Romeo is?</body>
559|  </message>
560            ]]></artwork>
561          </figure>
562          <t>Upon receiving such a message, the XMPP-to-SIP gateway MUST translate it into an MSRP SEND message.</t>
563          <figure>
564            <preamble>Example 13: Gateway maps XMPP message to MSRP (F18)</preamble>
565            <artwork><![CDATA[
566|  MSRP a786hjs2 SEND
567|  To-Path: msrp://s2x.example.org:12763/kjhd37s2s20w2a;tcp
568|  From-Path: msrp://x2s.example.com:7654/jshA7weztas;tcp
569|  Message-ID: 87652491
570|  Byte-Range: 1-*/*
571|  Content-Type: message/cpim
572|
573|  To: <sip:verona@chat.example.org>
574|  From: "Juliet" <sip:juliet@example.com>
575|  DateTime: 2008-10-15T15:02:31-03:00
576|  Content-Type: text/plain
577|
578|  Who knows where Romeo is?
579|  -------a786hjs2$
580            ]]></artwork>
581          </figure>
582          <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, the MSRP conference server MUST immediately generate and send a response.</t>
583          <figure>
584            <preamble>Example 14: MSRP conference returns 200 OK (F19)</preamble>
585            <artwork><![CDATA[
586|  MSRP d93kswow 200 OK
587|  To-Path: msrp://x2s.example.com:7654/jshA7weztas;tcp
588|  From-Path: msrp://s2x.example.org:12763/kjhd37s2s20w2a;tcp
589|  -------d93kswow$
590            ]]></artwork>
591          </figure>
592          <t>Since an XMPP MUC room could be moderated and an XMPP user cannot be sure whether her message has been accepted or not without receiving it back from the server, <xref target="XEP-0045"/> states that the sender needs to receive the same message it has generated.  So in this scenario the XMPP-to-SIP gateway has to reflect the message back to the sender.  This prodedure only applies to XMPP endpoints.</t>
593          <figure>
594            <preamble>Example 15: Gateway reflects message to XMPP user (F20)</preamble>
595            <artwork><![CDATA[
596|  <message from='verona@chat.example.org/JuliC'
597|           to='verona@chat.example.org'
598|           type='groupchat'
599|           id='ix51z73m'>
600|        <body>Who knows where Romeo is?</body>
601|  </message>
602            ]]></artwork>
603          </figure>
604        </section>
605
606        <section title="Send a Private Message" anchor="muc2msrp-message-private">
607          <t>Since each occupant has a unique JID, Juliet can send a "private message" to a selected occupant through the service by sending a message to the user's occupant JID.  The XMPP message type SHOULD be "chat" and MUST NOT be "groupchat", but MAY be left unspecified.</t>
608          <t>If the XMPP-to-SIP gateway has support for private messaging it MUST advertise that fact by adding a "private-messages" value to the a=chatroom SDP attribute it sends to the MSRP conference server, as specified in <xref target="I-D.ietf-simple-chat"/>.</t>
609          <figure>
610            <artwork><![CDATA[
611|  a=chatroom:nickname private-messages
612            ]]></artwork>
613          </figure>
614          <t>The following examples show an exchange of a private message.</t>
615          <figure>
616            <preamble>Example 16: Juliet sends private message (F22)</preamble>
617            <artwork><![CDATA[
618|  <message from='juliet@example.com/balcony'
619|           to='verona@chat.example.org/Romeo'
620|           type='chat'
621|           id='6sfln45q'>
622|        <body>O Romeo, Romeo! wherefore art thou Romeo?</body>
623|  </message>
624            ]]></artwork>
625          </figure>
626          <t>Upon receiving such a message, the XMPP-to-SIP gateway MUST translate it into an MSRP SEND message.</t>
627          <figure>
628            <preamble>Example 17: Gateway maps private message from XMPP to MSRP (F24)</preamble>
629            <artwork><![CDATA[
630|  MSRP a786hjs2 SEND
631|  To-Path: msrp://s2x.example.org:12763/kjhd37s2s20w2a;tcp
632|  From-Path: msrp://x2s.example.com:7654/jshA7weztas;tcp
633|  Message-ID: 87652491
634|  Byte-Range: 1-*/*
635|  Content-Type: message/cpim
636|
637|  To: <sip:verona@chat.example.org>;gr=Romeo
638|  From: <sip:juliet@example.org>;gr=balcony
639|  DateTime: 2008-10-15T15:02:31-03:00
640|  Content-Type: text/plain
641|
642|  O Romeo, Romeo! wherefore art thou Romeo?
643|  -------a786hjs2$
644            ]]></artwork>
645          </figure>
646          <t>After acknowledging the message by sending a SIP 200 OK (step F25), the MSRP conference server is responsible for sending the message to the intended recipient (not shown in the protocol flow).  When doing so, it MUST modify the "From" header to the sender's address within the chatroom.</t>
647          <figure>
648            <preamble>Example 18: MSRP conference sends private message to SIP user</preamble>
649            <artwork><![CDATA[
650|  MSRP a786hjs2 SEND
651|  To-Path: msrp://s2x.example.org:12763/kjhd37s2s20w2a;tcp
652|  From-Path: msrp://x2s.example.com:7654/jshA7weztas;tcp
653|  Message-ID: 87652491
654|  Byte-Range: 1-*/*
655|  Content-Type: message/cpim
656|
657|  To: <sip:romeo@example.com>
658|  From: <sip:verona@chat.example.com>;gr=JuliC
659|  DateTime: 2008-10-15T15:02:31-03:00
660|  Content-Type: text/plain
661|
662|  O Romeo, Romeo! wherefore art thou Romeo?
663|  -------a786hjs2$
664            ]]></artwork>
665          </figure>
666        </section>
667
668      </section>
669
670      <section title="Change Nickname" anchor="muc2msrp-nickChange">
671        <t>The XMPP user might want to change her nickname.  She can do so by sending an updated presence stanza to the room, containing a new nickname.</t>
672        <figure>
673          <preamble>Example 19: Juliet changes her nickname (F26)</preamble>
674          <artwork><![CDATA[
675|  <presence from='juliet@example.com/balcony'
676|            to='verona@chat.example.org/CapuletGirl'/>
677          ]]></artwork>
678        </figure>
679        <t>So far we have assumed that the requested nickname did not conflict with any existing nicknames.  The following text describes the handling of a nickname conflict.</t>
680        <t>The MSRP conference server analyzes the existing allocation of nicknames, and detects that the nickname proposal is already provided to another participant.  In this case the MSRP conference server answers with a 425 response.</t>
681        <figure>
682          <preamble>Example 20: MSRP conference does not accept nickname proposal (F29)</preamble>
683          <artwork><![CDATA[
684|  MSRP a786hjs2 425 Nickname usage failed
685|  To-Path: msrp://x2s.example.com:7654/jshA7weztas;tcp
686|  From-Path: msrp://s2x.example.org:12763/kjhd37s2s20w2a;tcp
687|  -------a786hjs2
688          ]]></artwork>
689        </figure>
690        <t>Upon receiving such a response, the SIP-to-XMPP gateway SHOULD translate it into an XMPP presence stanza of type "error" specifying a &lt;conflict/&gt; error condition (which implies that the XMPP client will then need to choose another nickname and repeat the process of joining).</t>
691        <figure>
692          <preamble>Example 21: Conflict error for nickname (F31)</preamble>
693          <artwork><![CDATA[
694|  <presence from='verona@chat.example.org/JuliC'
695|            to='juliet@example.com/balcony'
696|            type='error'>
697|    <x xmlns='http='http://jabber.org/protocol/muc'/>
698|    <error type='cancel' by='verona@chat.example.org'>
699|      <conflict xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
700|    </error>
701|  </presence>
702          ]]></artwork>
703        </figure>
704        <t>Alternatively, the gateway might generate a new nickname request on behalf of the XMPP user, thus shielding the XMPP client from handling the conflict error.</t>
705      </section>
706
707      <section title="Invite Another User to a Room" anchor="muc2msrp-invite">
708        <t>In XMPP there are two methods for inviting another user to a room: direct invitations <xref target='XEP-0249'/> (sent directly from the user's real JID outside the room to the invitee's real JID) and mediated invitations (sent through the room from the user's occupant JID to the invitee's JID).  In this document we cover mediated invitations only.</t>
709        <t>For example, if Juliet decides to invite Benvolio to the room, she sends a message stanza with an invite and Benvolio's JID (which could be his real JID or an occupant JID in another room).</t>
710        <figure>
711          <preamble>Example 22: Juliet invites Benvolio to the room (F32)</preamble>
712          <artwork><![CDATA[
713|  <message from='juliet@example.com/balcony'
714|           id='nzd143v8'
715|           to='verona@chat.example.org'>
716|    <x xmlns='http://jabber.org/protocol/muc#user'>
717|      <invite to='benvolio@example.com'/>
718|    </x>
719|  </message>
720          ]]></artwork>
721        </figure>
722        <t>The SIP-to-XMPP gateway then sends a SIP REFER request to the MSRP conference server indicating who needs to be invited in the Refer-To header, as per <xref target='RFC4579'/> (sec 5.5)</t>
723        <figure>
724          <preamble>Example 23: SIP mapping of invite (F34)</preamble>
725          <artwork><![CDATA[
726|  REFER sip:verona@chat.example.com SIP/2.0
727|  To: <sip:verona@chat.example.com>
728|  From: "Juliet" <sip:juliet@example.com>;tag=5534562
729|  Call-ID: 7FFCD8F7-EEB6-4506-A566-80D3CFC4C6E6
730|  Contact: <sip:juliet@example.com>;gr=balcony
731|  Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
732|  Accept: message/sipfrag
733|  Refer-To: <sip:benvolio@example.com>
734|  Supported: replaces
735|  Content-Length: 0
736          ]]></artwork>
737        </figure>
738        <t>The MSRP conference server then acknowledges the SIP REFER request with a 200 OK response (step F35).</t>
739        <t>The progress of the invitation will be tracked by the received NOTIFY requests as per <xref target='RFC3515'/>.</t>
740        <figure>
741          <preamble>Example 24: Progress notification for invitation (F36)</preamble>
742          <artwork><![CDATA[
743|  NOTIFY sip:juliet@example.com SIP/2.0
744|  To: <sip:juliet@example.com>;tag=5534562
745|  From: <sip:verona@chat.example.com>;tag=18747389
746|  Call-ID: 7FFCD8F7-EEB6-4506-A566-80D3CFC4C6E6
747|  Max-Forwards: 70
748|  Event: refer
749|  Subscription-State: active;expires=60
750|  Contact: <sip:verona@chat.example.com;transport=tcp>;isfocus
751|  Content-Type: message/sipfrag;version=2.0
752|  Content-Length: ...
753          ]]></artwork>
754        </figure>
755      </section>
756
757      <section title="Exit Room" anchor="muc2msrp-exit">
758        <t>If Juliet decides to exit the chatroom, her client sends a directed presence stanza of type "unavailable" to the occupant JID she is currently using in the room (here &lt;verona@chat.example.org/JuliC&gt;).</t>
759        <figure>
760          <preamble>Example 25: Juliet exits room (F37)</preamble>
761          <artwork><![CDATA[
762|  <presence from='juliet@example.com/balcony'
763|            to='verona@chat.example.org/JuliC'
764|            type='unavailable'/>
765          ]]></artwork>
766        </figure>
767        <t>Upon receiving such a stanza, the XMPP-to-SIP gateway terminates the SIP session by sending a SIP BYE to the MSRP conference server and the MSRP conference server responds with a 200 OK (steps F39 and F40).</t>
768        <t>Juliet MAY include a custom exit message in the presence stanza of type "unavailable", in which case it SHOULD be broadcasted to other participants using the methods described above.</t>
769        <figure>
770          <preamble>Example 26: Juliet exits the chatroom (F42)</preamble>
771          <artwork><![CDATA[
772|  <presence from='juliet@example.com/balcony'
773|            to='verona@chat.example.org/JuliC'
774|            type='unavailable'>
775|    <status>Time to go!</status>
776|  </presence>
777          ]]></artwork>
778        </figure>
779      </section>
780
781    </section>     
782
783
784    <section title="MSRP Multi-party Messaging Session to XMPP MUC" anchor="msrp2muc">
785
786      <t>This section describes how to map a Multi-party Instant Message (IM) MSRP session to an XMPP Multi-User Chat (MUC) session.  As before, the following diagram outlines the overall protocol flow of a sample session, which includes some optional exchanges (such as sending messages, changing nickname, and inviting another user).</t>
787
788      <figure>
789        <artwork><![CDATA[
790SIP         SIP      MSRP-to-XMPP   XMPP-to-MSRP     MUC
791User       Server      Gateway        Gateway      Service
792 |           |            |              |            |
793 | (F43) SIP |            |              |            |
794 | INVITE    |            |              |            |
795 |**********>|            |              |            |
796 | (F44) SIP |            |              |            |
797 | 200 OK    |            |              |            |
798 |<**********|            |              |            |
799 | (F45) SIP |            |              |            |
800 | ACK       |            |              |            |
801 |**********>|            |              |            |
802 | (F46) MSRP|            |              |            |
803 | NICKNAME  |            |              |            |
804 |**********>|            |              |            |
805 |           | (F47) SIP  |              |            |
806 |           | ACK        |              |            |
807 |           |***********>|              |            |
808 |           | (F48) MSRP |              |            |
809 |           | NICKNAME   |              |            |
810 |           |***********>|              |            |
811 |           | (F49) MSRP |              |            |
812 |           | 200 OK     |              |            |
813 |           |<***********|              |            |
814 | (F50) MSRP|            |              |            |
815 | 200 OK    |            |              |            |
816 |<**********|            |              |            |
817 |           |            | (F51) XMPP presence:      |
818 |           |            | enter room                |
819 |           |            |..........................>|
820 | (F52) SIP |            |              |            |
821 | SUBSCRIBE |            |              |            |
822 | Event:    |            |              |            |
823 | conference|            |              |            |
824 |**********>|            |              |            |
825 |           | (F53) SIP  |              |            |
826 |           | SUBSCRIBE  |              |            |
827 |           | Event:     |              |            |
828 |           | conference |              |            |
829 |           |***********>|              |            |
830 |           | (F54) SIP  |              |            |
831 |           | 200 OK     |              |            |
832 |           |<***********|              |            |
833 | (F55) SIP |            |              |            |
834 | 200 OK    |            |              |            |
835 |<**********|            |              |            |
836 |           |            |              | (F56) XMPP |
837 |           |            |              | presence   |
838 |           |            |              |<...........|
839 |           | (F57) SIP NOTIFY          |            |
840 |           |<**************************|            |
841 | (F58) SIP |            |              |            |
842 | NOTIFY    |            |              |            |
843 |<**********|            |              |            |
844 | (F59) SIP |            |              |            |
845 | 200 OK    |            |              |            |
846 |**********>|            |              |            |
847 |           |            |              | (F60) XMPP |
848 |           |            |              | message:   |
849 |           |            |              | subject    |
850 |           |            |              |<...........|
851 .           .            .              .            .
852 .           .            .              .            .
853 | (F61) MSRP|            |              |            |
854 | SEND      |            |              |            |
855 |**********>|            |              |            |
856 |           | (F62) MSRP |              |            |
857 |           | SEND       |              |            |
858 |           |***********>|              |            |
859 |           |            | (F63) XMPP message        |
860 |           |            | type: groupchat           |
861 |           |            |..........................>|
862 |           | (F64) MSRP |              |            |
863 |           | 200 OK     |              |            |
864 |           |<***********|              |            |
865 | (F65) MSRP|            |              |            |
866 | 200 OK    |            |              |            |
867 |<**********|            |              |            |
868 |           |            | (F66) XMPP message        |
869 |           |            | type: groupchat           |
870 |           |            |<..........................|
871 |           | (F67) MSRP |              |            |
872 |           | SEND       |              |            |
873 |           |<***********|              |            |
874 | (F68) MSRP|            |              |            |
875 | SEND      |            |              |            |
876 |<**********|            |              |            |
877 | (F69) MSRP|            |              |            |
878 | 200 OK    |            |              |            |
879 |**********>|            |              |            |
880 .           .            .              .            .
881 .           .            .              .            .
882 | (F70) MSRP|            |              |            |
883 | SEND      |            |              |            |
884 |**********>|            |              |            |
885 |           | (F71) MSRP |              |            |
886 |           | SEND       |              |            |
887 |           |***********>|              |            |
888 |           |            | (F72) XMPP message        |
889 |           |            |..........................>|
890 |           | (F73) MSRP |              |            |
891 |           | 200 OK     |              |            |
892 |           |<***********|              |            |
893 | (F74) MSRP|            |              |            |
894 | 200 OK    |            |              |            |
895 |<**********|            |              |            |
896 .           .            .              .            .
897 .           .            .              .            .
898 | (F75) MSRP|            |              |            |
899 | NICKNAME  |            |              |            |
900 |**********>|            |              |            |
901 |           | (F76) MSRP |              |            |
902 |           | NICKNAME   |              |            |
903 |           |***********>|              |            |
904 |           |            | (F77) XMPP presence       |
905 |           |            |..........................>|
906 |           |            | (F78) XMPP presence error |
907 |           |            |<..........................|
908 |           | (F79) MSRP |              |            |
909 |           | 425 Error  |              |            |
910 |           |<***********|              |            |
911 | (F80) MSRP|            |              |            |
912 | 425 Error |            |              |            |
913 |<**********|            |              |            |
914 .           .            .              .            .
915 .           .            .              .            .
916 | (F81) SIP |            |              |            |
917 | REFER     |            |              |            |
918 |**********>|            |              |            |
919 |           | (F82) SIP  |              |            |
920 |           | REFER      |              |            |
921 |           |***********>|              |            |
922 |           | (F83) SIP  |              |            |
923 |           | 200 OK     |              |            |
924 |           |<***********|              |            |
925 |           | (F84) SIP  |              |            |
926 |           | NOTIFY     |              |            |
927 |           |<***********|              |            |
928 |           |            | (F85) XMPP message: invite|
929 |           |            |..........................>|
930 | (F86) SIP |            |              |            |
931 | 200 OK    |            |              |            |
932 |<**********|            |              |            |
933 | (F87) SIP |            |              |            |
934 | NOTIFY    |            |              |            |
935 |<**********|            |              |            |
936 .           .            .              .            .
937 .           .            .              .            .
938 | (F88) SIP |            |              |            |
939 | BYE       |            |              |            |
940 |**********>|            |              |            |
941 |           | (F89) SIP  |              |            |
942 |           | BYE        |              |            |
943 |           |***********>|              |            |
944 |           |            | (F90) XMPP presence       |
945 |           |            | type: unavailable         |
946 |           |            |..........................>|
947 |           |            |              | (F91) XMPP |
948 |           |            |              | presence   |
949 |           |            |              | unavailable|
950 |           |            |              |<...........|
951 |           | (F92) SIP 200 OK          |            |
952 |           |<**************************|            |
953 | (F93) SIP |            |              |            |
954 | 200 OK    |            |              |            |
955 |<**********|            |              |            |
956 |           |            |              |            |
957        ]]></artwork>
958      </figure>
959
960      <t>If the XMPP presence stanza is received before the SIP SUBSCRIBE dialog is established for the "conference" event, then the server SHOULD cache the participant list until the subscription is established and delivered in a SIP NOTIFY request.</t>
961
962      <section title="Enter Room (Includes Set Nickname)" anchor="mrsp2muc-enter">
963
964        <t>When the SIP user ("Romeo") wants to join a groupchat room ("Verona"), 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" and "chatroom" attributes.  The MSRP media line is also accompanied by an "accept-types" attribute specifing support for a Message/CPIM top level wrapper for the MSRP message.</t>
965        <figure>
966          <preamble>Example 27: SIP user starts session (F43)</preamble>
967          <artwork><![CDATA[
968|  INVITE sip:verona@chat.example.org SIP/2.0
969|  To: <sip:verona@chat.example.org>
970|  From: "Romeo" <sip:romeo@example.com>
971|  Contact: <sip:romeo@example.com>;gr=orchard
972|  Call-ID: 08CFDAA4-FAED-4E83-9317-253691908CD2
973|  Content-Type: application/sdp
974|  Content-Length: ...
975|
976|  c=IN IP4 s2x.example.net
977|  m=message 7313 TCP/MSRP *
978|  a=accept-types:message/cpim text/plain text/html
979|  a=accept-wrapped-types:text/plain text/html
980|  a=path:msrp://s2x.example.net:7313/ansp71weztas;tcp
981|  a=chatroom
982          ]]></artwork>
983        </figure>
984        <t>Upon receiving the INVITE, the SIP server needs to determine the identity of the domain portion of the Request-URI or To header, which it does by following the procedures discussed in <xref target='I-D.ietf-stox-core'/>.  Here we assume that the SIP server has determined that the domain is serviced by an XMPP server, that it contains or has available to it a SIP-to-XMPP gateway or connection manager (which enables it to speak natively to XMPP servers), and that it hands off the message to the gateway.</t>
985        <t>Implementations MAY wait until the nickname is set with an MSRP NICKNAME chunk before joining the XMPP MUC or MAY choose a temporary nickname (such as the SIP From header display name) and use it to join the room.</t>
986        <figure>
987          <preamble>Example 28: SIP user acks session (F45)</preamble>
988          <artwork><![CDATA[
989|  SIP/2.0 200 OK
990|  To: <sip:verona@chat.example.org>
991|  From: "Romeo" <sip:romeo@example.com>
992|  Contact: <sip:x2s.example.com;transport=tcp>;isfocus
993|  Call-ID: 08CFDAA4-FAED-4E83-9317-253691908CD2
994|  Content-Type: application/sdp
995|
996|  c=IN IP4 x2s.example.com
997|  m=message 8763 TCP/MSRP *
998|  a=accept-types:message/cpim text/plain text/html
999|  a=accept-wrapped-types:text/plain text/html
1000|  a=path:msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp
1001|  a=chatroom:nickname private-messages
1002          ]]></artwork>
1003        </figure>
1004        <t>The SIP user then requests a nickname.</t>
1005        <figure>
1006          <preamble>Example 29: MSRP user sets up nickname (F46)</preamble>
1007          <artwork><![CDATA[
1008|  MSRP a786hjs2 NICKNAME
1009|  To-Path: msrp://s2x.example.net:7313/ansp71weztas;tcp
1010|  From-Path: msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp
1011|  Use-Nickname: "Romeo"
1012|  -------a786hjs2
1013          ]]></artwork>
1014        </figure>
1015        <t>Upon receiving the MSRP NICKNAME request, the SIP-to-XMPP gateway is responsible for generating an XMPP presence stanza and sending it to the chatroom.</t>
1016        <figure>
1017          <preamble>Example 30: Romeo enters XMPP chatroom (F52)</preamble>
1018          <artwork><![CDATA[
1019|  <presence from='romeo@example.com'
1020|            to='verona@chat.example.org/Romeo'>
1021|    <x xmlns='http='http://jabber.org/protocol/muc'/>
1022|  </presence>
1023          ]]></artwork>
1024        </figure>
1025        <t>If the room does not already contain another user with the requested nickname, the service accepts the access request.  Thus if the gateway does not receive any stanza of type "error" specifying a &lt;conflict/&gt; error condition within a reasonable amount of time (e.g., 5 seconds), it MUST answer the MSRP nickname proposal with a 200 OK response (S6).</t>
1026        <figure>
1027          <preamble>Example 31: Acknowledgement of join (F50)</preamble>
1028          <artwork><![CDATA[
1029|  MSRP a786hjs2 200 OK
1030|  To-Path: msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp
1031|  From-Path: msrp://s2x.example.net:7313/ansp71weztas;tcp
1032|  -------a786hjs2
1033          ]]></artwork>
1034        </figure>
1035        <t>Once the nickname has been set the user subscribes to the conference event.</t>
1036        <figure>
1037          <preamble>Example 32: User subscribes to the conference event (F52)</preamble>
1038          <artwork><![CDATA[
1039|  SUBSCRIBE sip:verona@chat.example.org SIP/2.0
1040|  To: <sip:verona@chat.example.org>
1041|  From: "Romeo" <sip:romeo@example.com>
1042|  Contact: <sip:romeo@example.com>;gr=orchard
1043|  Call-ID: A260DEBD-4F1F-45D1-A2C0-3696636F6417
1044|  Event: conference
1045|  Expires: 600
1046|  Accept: application/conference-info+xml
1047|  Allow-Events: conference
1048|  Content-Length: 0
1049          ]]></artwork>
1050        </figure>
1051        <t>The gateway will accept or reject the request based on local policy.</t>
1052        <figure>
1053          <preamble>Example 33: Gateway accepts subscription (F54)</preamble>
1054          <artwork><![CDATA[
1055|  SIP/2.0 200 OK
1056|  To: <sip:verona@chat.example.org>
1057|  From: "Romeo" <sip:romeo@example.com>
1058|  Call-ID: A260DEBD-4F1F-45D1-A2C0-3696636F6417
1059|  Contact: <sip:verona@chat.example.org;transport=tcp>;isfocus
1060|  Allow: SUBSCRIBE, NOTIFY, PRACK, INVITE, ACK, BYE,
1061|         CANCEL, UPDATE, MESSAGE, REFER
1062|  Expires: 600
1063|  Content-Length: 0
1064          ]]></artwork>
1065        </figure>
1066
1067      </section>
1068
1069      <section title="Presence Broadcast" anchor="msrp2muc-presence">
1070        <t>If the multi-user chat service is able to add the SIP user to the room, it sends presence from all the existing occupants' room JIDs to the new occupant's full JID, including extended presence information about roles in an &lt;x/&gt; element.</t>
1071         <figure>
1072          <preamble>Example 34: XMPP service sends presence from existing occupants to new occupant (F56)</preamble>
1073          <artwork><![CDATA[
1074|  <presence from='verona@chat.example.org/Romeo'
1075|            to='romeo@example.com'>
1076|    <x xmlns='http://jabber.org/protocol/muc#user'>
1077|      <item affiliation='none' role='participant'/>
1078|      <status='110'/>
1079|    </x>
1080|  </presence>
1081|
1082|  <presence from='verona@chat.example.org/Ben'
1083|            to='romeo@example.com'>
1084|    <x xmlns='http://jabber.org/protocol/muc#user'>
1085|      <item affiliation='none' role='participant'/>
1086|    </x>
1087|  </presence>
1088|
1089|  <presence from='verona@chat.example.org/JuliC'
1090|            to='romeo@example.com'>
1091|    <x xmlns='http://jabber.org/protocol/muc#user'>
1092|      <item affiliation='none' role='participant'/>
1093|    </x>
1094|  </presence>
1095          ]]></artwork>
1096        </figure>
1097        <t>Upon receiving these presence stanzas, if the MSRP conference server has already completed the subscription to the Conference Event package <xref target="RFC4575"/>, the XMPP-to-SIP gateway MUST translate them into a SIP NOTIFY request containing the participant list (represented in the conference-info format specified in <xref target='RFC4575'/>).</t>
1098        <figure>
1099          <preamble>Example 35: MSRP mapping of XMPP participant presence (F57)</preamble>
1100          <artwork><![CDATA[
1101|  NOTIFY sip:romeo@example.com SIP/2.0
1102|  To: <sip:romeo@example.com>;tag=43524545
1103|  From: <sip:verona@chat.example.org>;tag=a3343df32
1104|  Call-ID: 6F563BA1-8177-4CED-8710-78D4D9593B08
1105|  Event: conference
1106|  Subscription-State: active;expires=3600
1107|  Content-Type: application/conference-info+xml
1108|  Content-Length: ...
1109|
1110|  <conference-info version="0" state="full"
1111|      entity="sip:verona@chat.example.org">
1112|    <conference-description>
1113|      <subject>Today in Verona</subject>
1114|      <conf-uris>
1115|        <entry>
1116|          <uri>tel:+18882934234</uri>
1117|          <uri>sip:verona@chat.example.org</uri>
1118|        </entry>
1119|      </conf-uris>
1120|   </conference-description>
1121|   <users>
1122|     <user entity="sip:verona@chat.example.org;gr=JuliC"
1123|           state="full">
1124|       <display-text>JuliC</display-text>
1125|       <roles>
1126|         <entry>participant</entry>
1127|       </roles>
1128|       <endpoint entity="sip:verona@chat.example.org;gr=JuliC"
1129|                 state="full">
1130|         <status>connected</status>
1131|         <media id="211835821">
1132|           <type>message</type>
1133|         </media>
1134|       </endpoint>
1135|     </user>
1136|     <user entity="sip:verona@chat.example.org;gr=Ben"
1137|           state="full">
1138|       <display-text>Ben</display-text>
1139|       <roles>
1140|         <entry>participant</entry>
1141|       </roles>
1142|       <endpoint entity="sip:verona@chat.example.org;gr=Ben"
1143|                 state="full">
1144|         <status>connected</status>
1145|         <media id="211835822">
1146|           <type>message</type>
1147|         </media>
1148|       </endpoint>
1149|   </users>
1150|  </conference-info>
1151          ]]></artwork>
1152        </figure>
1153        <t>Because the "room roster" is communicated in XMPP by means of multiple presence stanzas (one for each participant) whereas the participant list is communicated in SIP by means of a single conference-info document, the SIP-to-XMPP gateway will need to keep track of the user's SIP URI and the mapping of that URI into an XMPP address; then, based on that mapping, it will need to determine when it has received a complete room roster from the MUC room, i.e., when it has received the in-room presence of the SIP user (which according to <xref target='XEP-0045'/> is the last presence stanza received in the initial batch sent after joining).  Once that happens, the SIP-to-XMPP gateway can construct the conference-info document containing the complete participant list and send that to the SIP user.</t>
1154      </section>
1155
1156      <section title="Exchange Messages" anchor="mrsp-exchange">
1157        <t>Once the user has joined the chat room, the user can exchange an unbounded number of messages, both public and private.</t>
1158        <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>
1159        <figure>
1160          <preamble>Table 5: Message syntax mapping from MSRP Message to XMPP</preamble>
1161          <artwork><![CDATA[
1162    +-----------------------------+-----------------------------+
1163    |  CPIM Header                |XMPP Element or Attribute    |
1164    +-----------------------------+-----------------------------+
1165    |  To                         |  to                         |
1166    |  From                       |  from                       |
1167    |  body of the SEND request   |  <body/>                    |
1168    +-----------------------------+-----------------------------+
1169          ]]></artwork>
1170        </figure>
1171
1172        <section title="Send a Message to All Occupants" anchor="msrp2muc-messageToAll">
1173          <t>When Romeo wants to send a message to all other occupants in the room, he sends an MSRP SEND request to &lt;room@service&gt; itself (i.e., &lt;verona@chat.example.org&gt; in our example).</t>
1174          <t>The following examples show an exchange of a public message.</t>
1175          <figure>
1176            <preamble>Example 36: Romeo sends a message to the chat room (F61)</preamble>
1177            <artwork><![CDATA[
1178|  MSRP a786hjs2 SEND
1179|  To-Path: msrp://s2x.example.net:7313/ansp71weztas;tcp
1180|  From-Path: msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp
1181|  Message-ID: 87652492
1182|  Byte-Range: 1-*/*
1183|  Content-Type: message/cpim
1184|
1185|  To: <sip:verona@chat.example.org>
1186|  From: "Romeo" <sip:romeo@example.com>;gr=orchard
1187|  DateTime: 2008-10-15T15:02:31-03:00
1188|  Content-Type: text/plain
1189|
1190|  Romeo is here!
1191|  -------a786hjs2$
1192            ]]></artwork>
1193          </figure>
1194          <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, the SIP-to-XMPP gateway MUST immediately translate it into an XMPP message stanza (F63) and then generate and send an MSRP response (F64).</t>
1195          <figure>
1196            <preamble>Example 37: XMPP mapping of message (F63)</preamble>
1197            <artwork><![CDATA[
1198|  <message from='romeo@example.com/orchard'
1199|           to='verona@chat.example.org'
1200|           type='groupchat'
1201|           id='8gbx1g4p'>
1202|    <body>Romeo is here!</body>
1203|  </message>
1204            ]]></artwork>
1205          </figure>
1206          <figure>
1207            <preamble>Example 38: MSRP response to public message (F64)</preamble>
1208            <artwork><![CDATA[
1209|  MSRP d93kswow 200 OK
1210|  To-Path: msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp
1211|  From-Path: msrp://s2x.example.net:7313/ansp71weztas;tcp
1212|  -------d93kswow$
1213            ]]></artwork>
1214          </figure>
1215          <t>Note well that the XMPP MUC room will reflect the sender's message back to all users, including the sender.  In MSRP this reflected message is unnecessary.  Therefore gateways are advised to maintain a cache and if the same stanza is received within a reasonable amount of time, assume is the reflected message and ignore it.</t>
1216        </section>
1217
1218        <section title="Send a Private Message" anchor="msrp2muc-privatemessage">
1219          <t>Romeo can send a "private message" to a selected occupant via the chat room service by sending a message to the occupant's room nickname.</t>
1220          <t>The following examples show an exchange of a private message.</t>
1221          <figure>
1222            <preamble>Example 39: Romeo sends a private message (F70)</preamble>
1223            <artwork><![CDATA[
1224|  MSRP a786hjs2 SEND
1225|  To-Path: msrp://s2x.example.net:7313/ansp71weztas;tcp
1226|  From-Path: msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp
1227|  Message-ID: 87652492
1228|  Byte-Range: 1-*/*
1229|  Content-Type: message/cpim
1230|
1231|  To: <sip:verona@chat.example.org>;gr=JuliC
1232|  From: "Romeo" <sip:romeo@example.com>;gr=orchard
1233|  DateTime: 2008-10-15T15:02:31-03:00
1234|  Content-Type: text/plain
1235|
1236|  I am here!!!
1237|  -------a786hjs2$
1238            ]]></artwork>
1239          </figure>
1240          <t>The MSRP conference is responsible for transforming the "From" address into an in-room address.</t>
1241          <figure>
1242            <preamble>Example 40: MSRP handling of private message (F71)</preamble>
1243            <artwork><![CDATA[
1244|  MSRP a786hjs2 SEND
1245|  To-Path: msrp://s2x.example.net:7313/ansp71weztas;tcp
1246|  From-Path: msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp
1247|  Message-ID: 87652492
1248|  Byte-Range: 1-*/*
1249|  Content-Type: message/cpim
1250|
1251|  To: <sip:verona@chat.example.org>;gr=JuliC
1252|  From: <sip:verona@chat.example.org>;gr=Romeo
1253|  DateTime: 2008-10-15T15:02:31-03:00
1254|  Content-Type: text/plain
1255|
1256|  I am here!!!
1257|  -------a786hjs2$
1258            ]]></artwork>
1259          </figure>
1260          <t>Once the MSRP conference sends that message to the gateway, the gateway is responsible for translating it into XMPP syntax.</t>
1261          <figure>
1262            <preamble>Example 41: XMPP mapping of private message (F72)</preamble>
1263            <artwork><![CDATA[
1264|  <message from='verona@chat.example.org/Romeo'
1265|           to='verona@chat.example.org/JuliC'
1266|           type='chat'
1267|           id='rg2ca9k7'/>
1268|    <body>I am here!!!</body>
1269|  </message>
1270            ]]></artwork>
1271          </figure>
1272        </section>
1273
1274      </section>
1275
1276      <section title="Change Nickname" anchor="msrp2muc-nickChange">
1277        <t>If Romeo decides to change his nickname within the room, he MUST send a new MSRP NICKNAME request. In fact modification of the nickname in MSRP is not different from the initial reservation and usage of a nickname.</t>
1278        <figure>
1279          <preamble>Example 42: MSRP user changes nickname (F75)</preamble>
1280          <artwork><![CDATA[
1281|  MSRP a786hjs2 NICKNAME
1282|  To-Path: msrp://s2x.example.net:7313/ansp71weztas;tcp
1283|  From-Path: msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp
1284|  Use-Nickname: "montecchi"
1285|  -------a786hjs2
1286          ]]></artwork>
1287        </figure>
1288        <t>Upon receiving such a message, the SIP-to-XMPP gateway MUST translate it into an XMPP presence stanza.</t>
1289        <figure>
1290          <preamble>Example 43: XMPP mapping of nickname change (F77)</preamble>
1291          <artwork><![CDATA[
1292|  <presence from='romeo@example.com'
1293|            to='verona@chat.example.org/montecchi'/>
1294          ]]></artwork>
1295        </figure>
1296        <t>The XMPP server will analyze the nickname allocation and determine if the requested nickname is available. In case the nickname
1297        is not available or not usable, the server will generate a presence stanza of type "error" specifying a &lt;conflict/&gt; error condition.</t>
1298        <figure>
1299          <preamble>Example 44: XMPP conflict error for nickname (F78)</preamble>
1300          <artwork><![CDATA[
1301|  <presence from='verona@chat.example.org/Romeo'
1302|            to='romeo@example.com/orchard'
1303|            type='error'>
1304|    <x xmlns='http='http://jabber.org/protocol/muc'/>
1305|    <error type='cancel' by='verona@chat.example.org'>
1306|      <conflict xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
1307|    </error>
1308|  </presence>
1309          ]]></artwork>
1310        </figure>
1311        <t>Upon receiving this stanza, the XMPP-SIP gateway will reply to the NICKNAME request with code 425</t>
1312        <figure>
1313          <preamble>Example 45: Gateway translates XMPP nickname conflict to MSRP error code (F79)</preamble>
1314          <artwork><![CDATA[
1315|  MSRP a786hjs2 425 Nickname usage failed
1316|  To-Path: msrp://s2x.example.net:7313/ansp71weztas;tcp
1317|  From-Path: msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp
1318|  -------a786hjs2
1319          ]]></artwork>
1320        </figure>
1321
1322      </section>
1323
1324      <section title="Invite Another User to a Room" anchor="msrp2muc-invite">
1325        <t>If a SIP user wants to invite another user to join the conference he will send a REFER request indicating who needs to be invited in the Refer-To header, as per Section 5.5 of <xref target='RFC4579'/>.</t>
1326        <figure>
1327          <preamble>Example 46: SIP user invites another user (F81)</preamble>
1328          <artwork><![CDATA[
1329|  REFER sip:verona@chat.example.org SIP/2.0
1330|  To: <sip:verona@chat.example.org>
1331|  From: "Romeo" <sip:romeo@example.com>;tag=5534562
1332|  Call-ID: AA11FE6F-8E13-42F3-BF35-AB509FAADA39
1333|  Contact: <sip:romeo@example.com>;gr=orchard
1334|  Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
1335|  Accept: message/sipfrag
1336|  Refer-To: <sip:benvolio@example.com>
1337|  Supported: replaces
1338|  Content-Length: 0
1339          ]]></artwork>
1340        </figure>
1341        <t>The XMPP-SIP gateway then acknowledges the SIP REFER request with a 200 OK response (step F83).</t>
1342        <t>The gateway will then send a NOTIFY requests as per <xref target='RFC3515'/> indicating that the invitation is is progress.  Since there is no way know the progress of the invitation until the user has joined, implementations are advised to terminate the REFER dialog subscription with the first NOTIFY, with a status code of 100 Trying.</t>
1343        <figure>
1344          <preamble>Example 47: Progress notification for invitation (F84)</preamble>
1345          <artwork><![CDATA[
1346|  NOTIFY sip:romeo@example.com SIP/2.0
1347|  To: <sip:romeo@example.com>;tag=5534562
1348|  From: <sip:verona@chat.example.org>;tag=18747389
1349|  Call-ID: AA11FE6F-8E13-42F3-BF35-AB509FAADA39
1350|  Event: refer
1351|  Subscription-State: terminated;reason=noresource
1352|  Contact: <sip:verona@chat.example.com;transport=tcp>;isfocus
1353|  Content-Type: message/sipfrag;version=2.0
1354|  Content-Length: ...
1355|
1356|  SIP/2.0 100 Trying
1357          ]]></artwork>
1358        </figure>
1359
1360      </section>
1361
1362      <section title="Exit Room" anchor="msrp2muc-exit">
1363        <t>If Romeo decides to exit the chat room, his client sends a SIP BYE to the &lt;verona@chat.example.org&gt; chat room.</t>
1364        <figure>
1365          <preamble>Example 48: Romeo terminates session (F88)</preamble>
1366          <artwork><![CDATA[
1367|  BYE sip:verona@chat.example.org SIP/2.0
1368|  Max-Forwards: 70
1369|  From: "Romeo" <sip:romeo@example.net>;tag=786
1370|  To: <sip:verona@chat.example.org>;tag=534
1371|  Call-ID: 08CFDAA4-FAED-4E83-9317-253691908CD2
1372|  Cseq: 1 BYE
1373|  Content-Length: 0
1374          ]]></artwork>
1375        </figure>
1376        <t>Upon receiving the SIP BYE, the SIP-to-XMPP gateway translates it into a presence stanza (F19) and sends it to the XMPP MUC room service.  Then the SIP-to-XMPP gateway responds with a 200 OK to the MSRP user.</t>
1377        <figure>
1378          <preamble>Example 49: Romeo exits chatroom (F90)</preamble>
1379          <artwork><![CDATA[
1380|  <presence from='romeo@example.com'
1381|            to='verona@chat.example.org/Romeo'
1382|            type='unavailable'/>
1383          ]]></artwork>
1384        </figure>
1385      </section>
1386    </section>
1387
1388    <section title="Handling of Nicknames and Display Names" anchor="names">
1389      <t>Fundamental rules for mapping addresses between XMPP and SIP are provided in <xref target="I-D.ietf-stox-core"/>.  However, chatrooms include a more specialized, unique identifier for each participant in a room, called a nickname.  Implementations are strongly encouraged to apply the rules for preparation and comparison of nicknames specified in <xref target='I-D.ietf-precis-nickname'/>.</t>
1390      <t>In addition to nicknames, some groupchat implementations also include display names (which might or might not be different from users' nicknames).  A display name need not be unique within the context of a room but instead simply provides a user-friendly name for a participant.</t>
1391      <t>In SIP, the nickname is the value of the XCON 'nickname' attribute of the &lt;user/&gt; element <xref target='RFC6501'/> and the display name is the XML character data of the conference-info &lt;display-text/&gt; element <xref target='RFC4575'/>.  In XMPP, the nickname is the value of the resourcepart of the occupant JID <xref target='XEP-0045'/> and the display name is the XML character data of the &lt;nick/&gt; element <xref target='XEP-0172'/>.</t>
1392      <t>In practice, the &lt;display-text/&gt; element is treated as canonical in SIP implementations, and the &lt;nick/&gt; element is rarely used in XMPP implementations.  Therefore, for display purposes SIP implementations ought to use the &lt;display-text/&gt; element (not the XCON 'nickname' attribute) and XMPP implementations ought to use the resourcepart of the occupant JID (not the character data of the &lt;nick/&gt; element).</t>
1393      <t>If there is a conflict between the SIP nickname and the XMPP nickname, the SIP-to-XMPP or XMPP-to-SIP gateway is responsible for adjusting the nickname to avoid the conflict and for informing the SIP or XMPP client of the unique nickname used to join the chatroom.</t>
1394    </section>
1395
1396    <section title="IANA Considerations" anchor="iana">
1397      <t>This document requests no actions of the IANA.</t>
1398    </section>
1399
1400    <section title="Security Considerations" anchor="security">
1401      <t>The security considerations of <xref target='RFC3261'/>, <xref target='RFC4975'/>, <xref target='RFC6120'/>, <xref target='I-D.ietf-stox-core'/>, <xref target='I-D.ietf-simple-chat'/>, and <xref target='XEP-0045'/> apply.</t>
1402    </section>
1403
1404  </middle>
1405
1406  <back>
1407
1408    <references title="Normative References">
1409
1410<reference anchor='I-D.ietf-precis-nickname'>
1411<front>
1412<title>Preparation and Comparison of Nicknames</title>
1413<author initials='P' surname='Saint-Andre' fullname='Peter Saint-Andre'>
1414    <organization />
1415</author>
1416<date month='January' day='23' year='2014' />
1417<abstract><t>This document describes how to prepare and compare Unicode strings representing nicknames, primarily for use within textual chatrooms. This profile is intended to be used by messaging and text conferencing technologies such as the Extensible Messaging and Presence Protocol (XMPP), the Message Session Relay Protocol (MSRP), and Centralized Conferencing (XCON).</t></abstract>
1418</front>
1419<seriesInfo name='Internet-Draft' value='draft-ietf-precis-nickname-09' />
1420<format type='TXT'
1421        target='http://www.ietf.org/internet-drafts/draft-ietf-precis-nickname-09.txt' />
1422</reference>
1423
1424<reference anchor="I-D.ietf-simple-chat">
1425<front>
1426<title>Multi-party Instant Message (IM) Sessions Using the Message Session Relay  Protocol (MSRP)</title>
1427<author initials="A" surname="Niemi" fullname="Aki Niemi">
1428    <organization/>
1429</author>
1430<author initials="M" surname="Garcia-Martin" fullname="Miguel Garcia-Martin">
1431    <organization/>
1432</author>
1433<author initials="G" surname="Sandbakken" fullname="Geir Arne Sandbakken">
1434    <organization/>
1435</author>
1436<date month="January" day="11" year="2013"/>
1437<abstract><t>The Message Session Relay Protocol (MSRP) defines a mechanism for sending instant messages within a peer-to-peer session, negotiated using the Session Initiation Protocol (SIP) and the Session Description Protocol (SDP).  This document defines the necessary tools for establishing multi-party instant messaging (IM) sessions, or chat rooms, with MSRP.</t></abstract>
1438</front>
1439<seriesInfo name="Internet-Draft" value="draft-ietf-simple-chat-18"/>
1440<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-ietf-simple-chat-18.txt"/>
1441</reference>
1442
1443<reference anchor="I-D.ietf-stox-core">
1444<front>
1445<title>Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Core</title>
1446<author initials="P" surname="Saint-Andre" fullname="Peter Saint-Andre">
1447    <organization/>
1448</author>
1449<author initials="A" surname="Houri" fullname="Avshalom Houri">
1450    <organization/>
1451</author>
1452<author initials="J" surname="Hildebrand" fullname="Joe Hildebrand">
1453    <organization/>
1454</author>
1455<date month="February" day="11" year="2014"/>
1456<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>
1457</front>
1458<seriesInfo name="Internet-Draft" value="draft-ietf-stox-core-11"/>
1459<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-ietf-stox-core-11.txt"/>
1460</reference>
1461
1462<reference anchor="RFC2119">
1463<front>
1464<title abbrev="RFC Key Words">Key words for use in RFCs to Indicate Requirement Levels</title>
1465<author initials="S." surname="Bradner" fullname="Scott Bradner">
1466<organization>Harvard University</organization>
1467<address>
1468<postal>
1469<street>1350 Mass.  Ave.</street>
1470<street>Cambridge</street>
1471<street>MA 02138</street></postal>
1472<phone>- +1 617 495 3864</phone>
1473<email>sob@harvard.edu</email></address></author>
1474<date year="1997" month="March"/>
1475<area>General</area>
1476<keyword>keyword</keyword>
1477<abstract>
1478<t>
1479   In many standards track documents several words are used to signify
1480   the requirements in the specification.  These words are often
1481   capitalized.  This document defines these words as they should be
1482   interpreted in IETF documents.  Authors who follow these guidelines
1483   should incorporate this phrase near the beginning of their document:
1484
1485<list>
1486<t>
1487      The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
1488      NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and
1489      "OPTIONAL" in this document are to be interpreted as described in
1490      RFC 2119.
1491</t></list></t>
1492<t>
1493   Note that the force of these words is modified by the requirement
1494   level of the document in which they are used.
1495</t></abstract></front>
1496<seriesInfo name="BCP" value="14"/>
1497<seriesInfo name="RFC" value="2119"/>
1498<format type="TXT" octets="4723" target="ftp://ftp.isi.edu/in-notes/rfc2119.txt"/>
1499<format type="HTML" octets="17491" target="http://xml.resource.org/public/rfc/html/rfc2119.html"/>
1500<format type="XML" octets="5777" target="http://xml.resource.org/public/rfc/xml/rfc2119.xml"/>
1501</reference>
1502
1503<reference anchor="RFC3261">
1504<front>
1505<title>SIP: Session Initiation Protocol</title>
1506<author initials="J." surname="Rosenberg" fullname="J.  Rosenberg">
1507<organization/></author>
1508<author initials="H." surname="Schulzrinne" fullname="H.  Schulzrinne">
1509<organization/></author>
1510<author initials="G." surname="Camarillo" fullname="G.  Camarillo">
1511<organization/></author>
1512<author initials="A." surname="Johnston" fullname="A.  Johnston">
1513<organization/></author>
1514<author initials="J." surname="Peterson" fullname="J.  Peterson">
1515<organization/></author>
1516<author initials="R." surname="Sparks" fullname="R.  Sparks">
1517<organization/></author>
1518<author initials="M." surname="Handley" fullname="M.  Handley">
1519<organization/></author>
1520<author initials="E." surname="Schooler" fullname="E.  Schooler">
1521<organization/></author>
1522<date year="2002" month="June"/>
1523<abstract>
1524<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>
1525<seriesInfo name="RFC" value="3261"/>
1526<format type="TXT" octets="647976" target="ftp://ftp.isi.edu/in-notes/rfc3261.txt"/>
1527</reference>
1528
1529<reference anchor='RFC4579'>
1530<front>
1531<title>Session Initiation Protocol (SIP) Call Control - Conferencing for User Agents</title>
1532<author initials='A.' surname='Johnston' fullname='A. Johnston'>
1533<organization /></author>
1534<author initials='O.' surname='Levin' fullname='O. Levin'>
1535<organization /></author>
1536<date year='2006' month='August' />
1537<abstract>
1538<t>This specification defines conferencing call control features for the Session Initiation Protocol (SIP).  This document builds on the Conferencing Requirements and Framework documents to define how a tightly coupled SIP conference works.  The approach is explored from the perspective of different user agent (UA) types: conference-unaware, conference-aware, and focus UAs.  The use of Uniform Resource Identifiers (URIs) in conferencing, OPTIONS for capabilities discovery, and call control using REFER are covered in detail with example call flow diagrams.  The usage of the isfocus feature tag is defined.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.  [STANDARDS TRACK]</t></abstract></front>
1539<seriesInfo name='RFC' value='4579' />
1540<format type='TXT' octets='96506' target='http://www.rfc-editor.org/rfc/rfc4579.txt' />
1541</reference>
1542
1543<reference anchor="RFC4975">
1544<front>
1545<title>The Message Session Relay Protocol (MSRP)</title>
1546<author initials="B." surname="Campbell" fullname="B.  Campbell">
1547<organization/></author>
1548<author initials="R." surname="Mahy" fullname="R.  Mahy">
1549<organization/></author>
1550<author initials="C." surname="Jennings" fullname="C.  Jennings">
1551<organization/></author>
1552<date year="2007" month="September"/>
1553<abstract>
1554<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>
1555<seriesInfo name="RFC" value="4975"/>
1556<format type="TXT" octets="144254" target="ftp://ftp.isi.edu/in-notes/rfc4975.txt"/>
1557</reference>
1558
1559<reference anchor='RFC6120'>
1560<front>
1561<title>Extensible Messaging and Presence Protocol (XMPP): Core</title>
1562<author initials='P.' surname='Saint-Andre' fullname='P. Saint-Andre'>
1563<organization /></author>
1564<date year='2011' month='March' />
1565<abstract>
1566<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>
1567<seriesInfo name='RFC' value='6120' />
1568<format type='TXT' octets='451942' target='http://www.rfc-editor.org/rfc/rfc6120.txt' />
1569</reference>
1570
1571<reference anchor='RFC6121'>
1572<front>
1573<title>Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence</title>
1574<author initials='P.' surname='Saint-Andre' fullname='P. Saint-Andre'>
1575<organization /></author>
1576<date year='2011' month='March' />
1577<abstract>
1578<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>
1579<seriesInfo name='RFC' value='6121' />
1580<format type='TXT' octets='244800' target='http://www.rfc-editor.org/rfc/rfc6121.txt' />
1581</reference>
1582
1583<reference anchor="XEP-0045">
1584  <front>
1585    <title>Multi-User Chat</title>
1586    <author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
1587      <organization/>
1588      <address>
1589        <email>stpeter@jabber.org</email>
1590      </address>
1591    </author>
1592    <date day="16" month="July" year="2008"/>
1593  </front>
1594  <seriesInfo name="XSF XEP" value="0045"/>
1595  <format type="HTML" target="http://www.xmpp.org/extensions/xep-0045.html"/>
1596</reference>
1597
1598    </references>
1599
1600    <references title="Informative References">
1601
1602<reference anchor='RFC3515'>
1603<front>
1604<title>The Session Initiation Protocol (SIP) Refer Method</title>
1605<author initials='R.' surname='Sparks' fullname='R. Sparks'>
1606<organization /></author>
1607<date year='2003' month='April' />
1608<abstract>
1609<t>This document defines the REFER method.  This Session Initiation Protocol (SIP) extension requests that the recipient REFER to a resource provided in the request.  It provides a mechanism allowing the party sending the REFER to be notified of the outcome of the referenced request.  This can be used to enable many applications, including call transfer.  In addition to the REFER method, this document defines the refer event package and the Refer-To request header. [STANDARDS-TRACK]</t></abstract></front>
1610<seriesInfo name='RFC' value='3515' />
1611<format type='TXT' octets='47788' target='http://www.rfc-editor.org/rfc/rfc3515.txt' />
1612</reference>
1613
1614<reference anchor="RFC4566">
1615<front>
1616<title>SDP: Session Description Protocol</title>
1617<author initials="M." surname="Handley" fullname="M.  Handley">
1618<organization/></author>
1619<author initials="V." surname="Jacobson" fullname="V.  Jacobson">
1620<organization/></author>
1621<author initials="C." surname="Perkins" fullname="C.  Perkins">
1622<organization/></author>
1623<date year="2006" month="July"/>
1624<abstract>
1625<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>
1626<seriesInfo name="RFC" value="4566"/>
1627<format type="TXT" octets="108820" target="ftp://ftp.isi.edu/in-notes/rfc4566.txt"/>
1628</reference>
1629
1630<reference anchor='RFC4575'>
1631<front>
1632<title>A Session Initiation Protocol (SIP) Event Package for Conference State</title>
1633<author initials='J.' surname='Rosenberg' fullname='J. Rosenberg'>
1634<organization /></author>
1635<author initials='H.' surname='Schulzrinne' fullname='H. Schulzrinne'>
1636<organization /></author>
1637<author initials='O.' surname='Levin' fullname='O. Levin'>
1638<organization /></author>
1639<date year='2006' month='August' />
1640<abstract>
1641<t>This document defines a conference event package for tightly coupled conferences using the Session Initiation Protocol (SIP) events framework, along with a data format used in notifications for this package.  The conference package allows users to subscribe to a conference Uniform Resource Identifier (URI).  Notifications are sent about changes in the membership of this conference and optionally about changes in the state of additional conference components. [STANDARDS TRACK]</t></abstract></front>
1642<seriesInfo name='RFC' value='4575' />
1643<format type='TXT' octets='97484' target='ftp://ftp.isi.edu/in-notes/rfc4575.txt' />
1644</reference>
1645
1646<reference anchor='RFC6501'>
1647<front>
1648<title>Conference Information Data Model for Centralized Conferencing (XCON)</title>
1649<author initials='O.' surname='Novo' fullname='O. Novo'>
1650<organization /></author>
1651<author initials='G.' surname='Camarillo' fullname='G. Camarillo'>
1652<organization /></author>
1653<author initials='D.' surname='Morgan' fullname='D. Morgan'>
1654<organization /></author>
1655<author initials='J.' surname='Urpalainen' fullname='J. Urpalainen'>
1656<organization /></author>
1657<date year='2012' month='March' />
1658<abstract>
1659<t>RFC 5239 defines centralized conferencing (XCON) as an association of participants with a central focus.  The state of a conference is represented by a conference object.  This document defines an XML- based conference information data model to be used for conference objects.  A conference information data model is designed to convey information about the conference and about participation in the conference.  The conference information data model defined in this document constitutes an extension of the data format specified in the Session Initiation Protocol (SIP) event package for conference State. [STANDARDS-TRACK]</t></abstract></front>
1660<seriesInfo name='RFC' value='6501' />
1661<format type='TXT' octets='180210' target='http://www.rfc-editor.org/rfc/rfc6501.txt' />
1662</reference>
1663
1664<reference anchor="XEP-0172">
1665  <front>
1666    <title>User Nickname</title>
1667    <author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
1668      <organization/>
1669      <address>
1670        <email>stpeter@jabber.org</email>
1671      </address>
1672    </author>
1673    <author initials="V." surname="Mercier" fullname="Valerie Mercier">
1674      <organization/>
1675      <address>
1676        <email>valerie.mercier@orange-ftgroup.com</email>
1677      </address>
1678    </author>
1679    <date day="21" month="March" year="2012"/>
1680  </front>
1681  <seriesInfo name="XSF XEP" value="0172"/>
1682  <format type="HTML" target="http://xmpp.org/extensions/xep-0172.html"/>
1683</reference>
1684
1685<reference anchor="XEP-0249">
1686  <front>
1687    <title>Direct MUC Invitations</title>
1688    <author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
1689      <organization/>
1690      <address>
1691        <email>stpeter@jabber.org</email>
1692      </address>
1693    </author>
1694    <date day="22" month="September" year="2011"/>
1695  </front>
1696  <seriesInfo name="XSF XEP" value="0249"/>
1697  <format type="HTML" target="http://xmpp.org/extensions/xep-0249.html"/>
1698</reference>
1699
1700    </references>
1701
1702    <section title="Acknowledgements" anchor="acks">
1703      <t>Special thanks to Fabio Forno for coauthoring an early version of this document.</t>
1704      <t>Thanks also to Dave Crocker, Philipp Hancke, and Olle Johansson for their feedback.</t>
1705      <t>The authors gratefully acknowledge the assistance of Markus Isomaki and Yana Stamcheva as the working group chairs and Gonzalo Camarillo and Alissa Cooper as the sponsoring Area Directors.</t>
1706      <t>Some text in this document was borrowed from <xref target="I-D.ietf-stox-core"/> and from <xref target="XEP-0045"/>.</t>
1707      <t>Peter Saint-Andre wishes to acknowledge Cisco Systems, Inc., for employing him during his work on earlier versions of this document.</t>
1708    </section>
1709
1710  </back>
1711
1712</rfc>
Note: See TracBrowser for help on using the repository browser.