tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 7702

 
 
 

Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Groupchat

Part 2 of 2, p. 25 to 43
Prev RFC Part

 


prevText      Top      ToC       Page 25 
6.  MSRP Multi-party Messaging Session to XMPP MUC

   This section describes how to map a Multi-party Instant Message (IM)
   MSRP session to an XMPP 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).

Top      Up      ToC       Page 26 
   SIP               SIP               MSRP             XMPP
   User             Proxy             Switch           Server
    |             + S2X GW          + M2X GW          +X2S GW
    |                 |                 |             +X2M GW
    |                 |                 |                 |
    | (F35) SIP       |                 |                 |
    | INVITE          |                 |                 |
    |****************>|                 |                 |
    | (F36) SIP       |                 |                 |
    | 200 OK          |                 |                 |
    |<****************|                 |                 |
    | (F37) SIP ACK   |                 |                 |
    |****************>|                 |                 |
    | (F38) SIP       |                 |                 |
    | SUBSCRIBE       |                 |                 |
    | Event:          |                 |                 |
    | conference      |                 |                 |
    |****************>|                 |                 |
    | (F39) SIP       |                 |                 |
    | 200 OK          |                 |                 |
    |<****************|                 |                 |
    |                 | (F40) XMPP presence: enter room   |
    |                 |..................................>|
    |                 | (F41) XMPP presence               |
    |                 |<..................................|
    | (F42) SIP       |                 |                 |
    | NOTIFY          |                 |                 |
    |<****************|                 |                 |
    | (F43) SIP       |                 |                 |
    | 200 OK          |                 |                 |
    |****************>|                 |                 |
    .                 .                 .                 .
    .                 .                 .                 .
    | (F44) MSRP SEND                   |                 |
    |%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%>|                 |
    |                 |                 | (F45) XMPP      |
    |                 |                 | groupchat       |
    |                 |                 | message         |
    |                 |                 |................>|
    |                 |                 | (F46) XMPP      |
    |                 |                 | groupchat       |
    |                 |                 | message         |
    |                 |                 |<................|
    | (F47) MSRP 200 OK                 |                 |
    |<%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%|                 |
    .                 .                 .                 .

Top      Up      ToC       Page 27 
    .                 .                 .                 .
    | (F48) MSRP SEND                   |                 |
    |%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%>|                 |
    | (F49) MSRP 200 OK                 |                 |
    |<%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%|                 |
    |                 |                 | (F50) XMPP      |
    |                 |                 | message         |
    |                 |                 |................>|
    .                 .                 .                 .
    .                 .                 .                 .
    | (F51) MSRP NICKNAME               |                 |
    |%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%>|                 |
    |                 |                 | (F52) XMPP      |
    |                 |                 | presence        |
    |                 |                 |................>|
    |                 |                 | (F53) XMPP      |
    |                 |                 | presence        |
    |                 |                 | error           |
    |                 |                 |<................|
    | (F54) MSRP 425 Error              |                 |
    |<%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%|                 |
    .                 .                 .                 .
    .                 .                 .                 .
    | (F55) SIP REFER |                 |                 |
    |****************>|                 |                 |
    | (F56) SIP       |                 |                 |
    | 200 OK          |                 |                 |
    |<****************|                 |                 |
    | (F57) SIP       |                 |                 |
    | NOTIFY          |                 |                 |
    |<****************|                 |                 |
    |                 | (F58) XMPP message invite         |
    |                 |..................................>|
    .                 .                 .                 .
    .                 .                 .                 .
    | (F59) SIP BYE   |                 |                 |
    |****************>|                 |                 |
    |                 | (F60) XMPP presence unavailable   |
    |                 |..................................>|
    |                 | (F61) XMPP presence unavailable   |
    |                 |<..................................|
    | (F62) SIP       |                 |                 |
    | 200 OK          |                 |                 |
    |<****************|                 |                 |
    |                 |                 |                 |

Top      Up      ToC       Page 28 
   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.

6.1.  Enter Room

   When the SIP user ("Romeo") wants to join a groupchat room
   ("capulet"), 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 mandatory 'path' and
   'chatroom' attributes.  Here we assume that Romeo's user agent has
   been configured to be aware of an MSRP switch (chat.example.org) it
   can use.  The MSRP media line is also accompanied by an 'accept-
   types' attribute specifying support for a Message/CPIM [RFC3862] top-
   level wrapper for the MSRP message.

   Example 27: SIP User Starts Session (F35)

   |  INVITE sip:capulet@rooms.example.com SIP/2.0
   |  From: "Romeo" <sip:romeo@example.org>;tag=43524545
   |  To: <sip:capulet@rooms.example.com>
   |  Contact: <sip:romeo@example.org>;gr=dr4hcr0st3lup4c
   |  Call-ID: 08CFDAA4-FAED-4E83-9317-253691908CD2
   |  CSeq: 1 INVITE
   |  Content-Type: application/sdp
   |  Content-Length: ...
   |
   |  c=IN IP4 s2x.example.org
   |  m=message 7313 TCP/MSRP *
   |  a=accept-types:message/cpim text/plain text/html
   |  a=accept-wrapped-types:text/plain text/html
   |  a=path:msrp://chat.example.org:7313/ansp71weztas;tcp
   |  a=chatroom:nickname private-messages

   Upon receiving the INVITE, the SIP proxy 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 [RFC7247].  Here we
   assume that the SIP proxy 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.

   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.  Here we assume the latter.

Top      Up      ToC       Page 29 
   Example 28: SIP-to-XMPP Gateway ACKs Session (F36)

   |  SIP/2.0 200 OK
   |  From: "Romeo" <sip:romeo@example.org>;tag=43524545
   |  To: <sip:capulet@rooms.example.com>;tag=a3343df32
   |  Contact: <sip:rooms.example.com;transport=tcp>;isfocus
   |  Call-ID: 08CFDAA4-FAED-4E83-9317-253691908CD2
   |  CSeq: 1 INVITE
   |  Content-Type: application/sdp
   |
   |  m=message 8763 TCP/MSRP *
   |  a=accept-types:message/cpim text/plain text/html
   |  a=accept-wrapped-types:text/plain text/html
   |  a=path:msrp://chat.example.org:8763/lkjh37s2s20w2a;tcp
   |  a=chatroom:nickname private-messages

   The SIP/MSRP user agent subscribes to a conference event package at
   the destination groupchat service.

   Example 29: Gateway Subscribes to the Conference (F38)

   |  SUBSCRIBE sip:capulet@rooms.example.com SIP/2.0
   |  To: <sip:capulet@rooms.example.com>;tag=a3343df32
   |  From: "Romeo" <sip:romeo@example.org>;tag=43524545
   |  Contact: <sip:romeo@example.org>;gr=dr4hcr0st3lup4c
   |  Call-ID: 08CFDAA4-FAED-4E83-9317-253691908CD2
   |  CSeq: 2 SUBSCRIBE
   |  Event: conference
   |  Expires: 600
   |  Accept: application/conference-info+xml
   |  Allow-Events: conference
   |  Content-Length: 0

   After the conference subscription request is acknowledged, the SIP-
   to-XMPP gateway sends presence from Romeo to the MUC chat room.

   Example 30: Romeo Enters XMPP Chat Room (F40)

   |  <presence from='romeo@example.org/dr4hcr0st3lup4c'
   |            to='montague@chat.example.org/Romeo'>
   |    <x xmlns='http://jabber.org/protocol/muc'/>
   |  </presence>

Top      Up      ToC       Page 30 
6.2.  Presence Broadcast

   If the MUC service is able to add the SIP/MSRP 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 <x/> element.

   Example 31: XMPP Service Sends Presence from Existing Occupants to
   New Occupant (F41)

   |  <presence from='capulet@rooms.example.com/Romeo'
   |            to='romeo@example.org/dr4hcr0st3lup4c'>
   |    <x xmlns='http://jabber.org/protocol/muc#user'>
   |      <item affiliation='none' role='participant'/>
   |      <status code='110'/>
   |    </x>
   |  </presence>
   |
   |  <presence from='capulet@rooms.example.com/Ben'
   |            to='romeo@example.org/dr4hcr0st3lup4c'>
   |    <x xmlns='http://jabber.org/protocol/muc#user'>
   |      <item affiliation='none' role='participant'/>
   |    </x>
   |  </presence>
   |
   |  <presence from='capulet@rooms.example.com/JuliC'
   |            to='romeo@example.org/dr4hcr0st3lup4c'>
   |    <x xmlns='http://jabber.org/protocol/muc#user'>
   |      <item affiliation='none' role='participant'/>
   |    </x>
   |  </presence>

   Upon receiving these presence stanzas, if the conference focus has
   already completed the subscription to the conference event package
   [RFC4575], the XMPP-to-SIP gateway translates them into a SIP NOTIFY
   request containing the participant list (represented in the
   conference-info format specified in [RFC4575]).

Top      Up      ToC       Page 31 
   Example 32: SIP Mapping of XMPP Participant Presence Stanzas (F42)

   |  NOTIFY sip:romeo@example.org SIP/2.0
   |  To: <sip:romeo@example.org>;tag=43524545
   |  From: <sip:capulet@rooms.example.com>;tag=a3343df32
   |  Call-ID: 08CFDAA4-FAED-4E83-9317-253691908CD2
   |  CSeq: 3 NOTIFY
   |  Event: conference
   |  Subscription-State: active;expires=3600
   |  Content-Type: application/conference-info+xml
   |  Content-Length: ...
   |
   |  <conference-info version="0" state="full"
   |      entity="sip:capulet@rooms.example.com">
   |    <conference-description>
   |      <subject>Today in Verona</subject>
   |      <conf-uris>
   |        <entry>
   |          <uri>tel:+18882934234</uri>
   |          <uri>sip:capulet@rooms.example.com</uri>
   |        </entry>
   |      </conf-uris>
   |   </conference-description>
   |   <users>
   |     <user entity="sip:capulet@rooms.example.com;gr=JuliC"
   |           state="full">
   |       <display-text>JuliC</display-text>
   |       <roles>
   |         <entry>participant</entry>
   |       </roles>
   |       <endpoint entity="sip:capulet@rooms.example.com;gr=JuliC"
   |                 state="full">
   |         <status>connected</status>
   |         <media id="211835821">
   |           <type>message</type>
   |         </media>
   |       </endpoint>
   |     </user>
   |     <user entity="sip:capulet@rooms.example.com;gr=Ben"
   |           state="full">
   |       <display-text>Ben</display-text>
   |       <roles>
   |         <entry>participant</entry>
   |       </roles>
   |       <endpoint entity="sip:capulet@rooms.example.com;gr=Ben"
   |                 state="full">
   |         <status>connected</status>
   |         <media id="211835822">

Top      Up      ToC       Page 32 
   |           <type>message</type>
   |         </media>
   |       </endpoint>
   |     </user>
   |   </users>
   |  </conference-info>

   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 information 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 [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 information document
   containing the complete participant list and send that to the SIP
   user.

6.3.  Exchange Messages

   Once the user has joined the chat room, the user can exchange an
   unbounded number of messages, both public and private.

   The mapping of MSRP syntax elements to XMPP syntax elements MUST be
   as shown in the following table.  (Mappings for elements not
   mentioned are undefined.)

   Table 5: Message Syntax Mapping from MSRP Message to XMPP

       +-----------------------------+-----------------------------+
       |  CPIM Header                |XMPP Element or Attribute    |
       +-----------------------------+-----------------------------+
       |  To                         |  to                         |
       |  From                       |  from                       |
       |  body of the SEND request   |  <body/>                    |
       +-----------------------------+-----------------------------+

6.3.1.  Send a Message to All Occupants

   When Romeo wants to send a message to all other occupants in the
   room, he sends an MSRP SEND request to <room@service>
   (<capulet@rooms.example.com> in our example).

Top      Up      ToC       Page 33 
   The following examples show an exchange of a public message.

   Example 33: Romeo Sends a Message to the Chat Room (F44)

   |  MSRP a786hjs2 SEND
   |  To-Path: msrp://room.example.com:7313/ansp71weztas;tcp
   |  From-Path: msrp://chat.example.org:8763/lkjh37s2s20w2a;tcp
   |  Message-ID: 87652492
   |  Byte-Range: 1-*/*
   |  Content-Type: message/cpim
   |
   |  To: <sip:capulet@rooms.example.com>
   |  From: "Romeo" <sip:romeo@example.org>;gr=dr4hcr0st3lup4c
   |  DateTime: 2008-10-15T15:02:31-03:00
   |  Content-Type: text/plain
   |
   |  Romeo is here!
   |  -------a786hjs2$

   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 immediately
   translates it into an XMPP message stanza and then generates and
   sends an MSRP response.

   Example 34: XMPP Mapping of Message (F45)

   |  <message from='romeo@example.org/dr4hcr0st3lup4c'
   |           to='capulet@rooms.example.com'
   |           type='groupchat'
   |           id='8gbx1g4p'>
   |    <body>Romeo is here!</body>
   |  </message>

   Example 35: MSRP Response to Public Message (F47)

   |  MSRP d93kswow 200 OK
   |  To-Path: msrp://rooms.example.com:8763/lkjh37s2s20w2a;tcp
   |  From-Path: msrp://chat.example.org:7313/ansp71weztas;tcp
   |  -------d93kswow$

   Note well that the XMPP MUC room will reflect the sender's message
   back to all users, including the sender.  The MSRP-to-XMPP gateway
   SHOULD wait until receiving this reflected message before sending an
   MSRP 200 OK reply to the original sender.

Top      Up      ToC       Page 34 
6.3.2.  Send a Private Message

   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.

   The following examples show an exchange of a private message.

   Example 36: Romeo Sends a Private Message (F48)

   |  MSRP a786hjs2 SEND
   |  To-Path: msrp://rooms.example.com:7313/ansp71weztas;tcp
   |  From-Path: msrp://chat.example.org:8763/lkjh37s2s20w2a;tcp
   |  Message-ID: 87652492
   |  Byte-Range: 1-*/*
   |  Content-Type: message/cpim
   |
   |  To: <sip:capulet@rooms.example.com>;gr=JuliC
   |  From: "Romeo" <sip:romeo@example.org>;gr=dr4hcr0st3lup4c
   |  DateTime: 2008-10-15T15:02:31-03:00
   |  Content-Type: text/plain
   |
   |  I am here!!!
   |  -------a786hjs2$

   The MSRP switch is responsible for transforming the 'From' address
   into an in-room address (not shown).

   Once the MSRP switch sends that message to the gateway, the gateway
   is responsible for translating it into XMPP syntax.

   Example 37: XMPP Mapping of Private Message (F50)

   |  <message from='capulet@rooms.example.com/Romeo'
   |           to='capulet@rooms.example.com/JuliC'
   |           type='chat'
   |           id='rg2ca9k7'>
   |    <body>I am here!!!</body>
   |  </message>

6.4.  Change Nickname

   If Romeo decides to change his nickname within the room, he sends 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.

Top      Up      ToC       Page 35 
   Example 38: MSRP User Changes Nickname (F51)

   |  MSRP a786hjs2 NICKNAME
   |  To-Path: msrp://chat.example.org:7313/ansp71weztas;tcp
   |  From-Path: msrp://rooms.example.com:8763/lkjh37s2s20w2a;tcp
   |  Use-Nickname: "montecchi"
   |  -------a786hjs2

   Upon receiving such a message, the MSRP-to-XMPP gateway translates it
   into an XMPP presence stanza.

   Example 39: XMPP Mapping of Nickname Change (F52)

   |  <presence from='romeo@example.org/dr4hcr0st3lup4c'
   |            to='capulet@rooms.example.com/montecchi'/>

   The XMPP server will analyze the nickname allocation and determine if
   the requested nickname is available.  In case the nickname is not
   available or not usable, the server will generate a presence stanza
   of type "error" specifying a <conflict/> error condition.

   Example 40: XMPP Conflict Error for Nickname (F53)

   |  <presence from='capulet@rooms.example.com/Romeo'
   |            to='romeo@example.org/dr4hcr0st3lup4c'
   |            type='error'>
   |    <x xmlns='http://jabber.org/protocol/muc'/>
   |    <error type='cancel' by='capulet@rooms.example.com'>
   |      <conflict xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
   |    </error>
   |  </presence>

   Upon receiving this stanza, the XMPP-to-MSRP gateway will reply to
   the NICKNAME request with code 425.

   Example 41: Gateway Translates XMPP Nickname Conflict to MSRP Error
   Code (F54)

   |  MSRP a786hjs2 425 Nickname usage failed
   |  To-Path: msrp://chat.example.org:7313/ansp71weztas;tcp
   |  From-Path: msrp://rooms.example.com:8763/lkjh37s2s20w2a;tcp
   |  -------a786hjs2

6.5.  Invite Another User to a Room

   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 [RFC4579].

Top      Up      ToC       Page 36 
   Example 42: SIP User Invites Another User (F55)

   |  REFER sip:capulet@rooms.example.com SIP/2.0
   |  To: <sip:capulet@rooms.example.com>;tag=a3343df32
   |  From: "Romeo" <sip:romeo@example.org>;tag=5534562
   |  Call-ID: 08CFDAA4-FAED-4E83-9317-253691908CD2
   |  CSeq: 4 REFER
   |  Contact: <sip:romeo@example.org>;gr=dr4hcr0st3lup4c
   |  Accept: message/sipfrag
   |  Refer-To: <sip:benvolio@example.com>
   |  Supported: replaces
   |  Content-Length: 0

   The SIP-to-XMPP gateway then acknowledges the SIP REFER request with
   a 200 OK response (step F56).

   The gateway will then send a NOTIFY request as per [RFC3515]
   indicating that the invitation is in progress.  Since there is no way
   to know the progress of the invitation until the user has joined,
   implementations are advised to terminate the REFER dialog
   subscription upon receiving the first NOTIFY request, with a status
   code of 100 Trying.

   Example 43: Progress Notification for Invitation (F56)

   |  NOTIFY sip:romeo@example.org SIP/2.0
   |  To: <sip:romeo@example.org>;tag=5534562
   |  From: <sip:capulet@rooms.example.com>;tag=a3343df32
   |  Call-ID: 08CFDAA4-FAED-4E83-9317-253691908CD2
   |  CSeq: 5 NOTIFY
   |  Event: refer
   |  Subscription-State: terminated;reason=noresource
   |  Contact: <sip:capulet@rooms.example.com;transport=tcp>;isfocus
   |  Content-Type: message/sipfrag;version=2.0
   |  Content-Length: ...
   |
   |  SIP/2.0 100 Trying

6.6.  Exit Room

   If Romeo decides to exit the chat room, his client sends a SIP BYE to
   the <montague@chat.example.org> chat room.

Top      Up      ToC       Page 37 
   Example 44: Romeo Terminates Session (F59)

   |  BYE sip:capulet@rooms.example.com SIP/2.0
   |  Max-Forwards: 70
   |  From: "Romeo" <sip:romeo@example.org>;tag=5534562
   |  To: <sip:capulet@rooms.example.com>;tag=a3343df32
   |  Call-ID: 08CFDAA4-FAED-4E83-9317-253691908CD2
   |  CSeq: 6 BYE
   |  Content-Length: 0

   Upon receiving the SIP BYE, the SIP-to-XMPP gateway translates it
   into a presence stanza of type "unavailable" (F60) and sends it to
   the XMPP MUC room service.  Then, the SIP-to-XMPP gateway responds
   with a 200 OK to the MSRP user (F62).

   Example 45: Romeo Exits Chat Room (F60)

   |  <presence from='romeo@example.org/dr4hcr0st3lup4c'
   |            to='capulet@rooms.example.com/Romeo'
   |            type='unavailable'/>

7.  Handling of Nicknames and Display Names

   Fundamental rules for mapping addresses between XMPP and SIP are
   provided in [RFC7247].  However, chat rooms include a more
   specialized, unique identifier for each participant in a room, called
   a "nickname".  Implementations SHOULD apply the rules for preparation
   and comparison of nicknames specified in [RFC7700].

   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.

   In the SIP conference event package, the nickname is the value of the
   Centralized Conferencing (XCON) 'nickname' attribute of the <user/>
   element [RFC6501] and the display name is the XML character data of
   the conference-info <display-text/> element [RFC4575].  In XMPP, the
   nickname is the value of the resourcepart of the occupant JID
   [XEP-0045] and the display name is the XML character data of the
   <nick/> element [XEP-0172].

   In practice, the <display-text/> element is treated as canonical in
   SIP implementations, and the <nick/> element is rarely used in XMPP
   implementations.  Therefore, for display purposes, SIP
   implementations ought to use the <display-text/> element if the XCON

Top      Up      ToC       Page 38 
   'nickname' attribute is not present, and XMPP implementations ought
   to use the resourcepart of the occupant JID if the <nick/> element is
   not present.

   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 chat room.

8.  Message Size

   It is possible for MSRP messages to exceed the size allowed by an
   XMPP service on the far end of an MSRP-to-XMPP gateway; see [RFC7573]
   for a discussion of this issue.

9.  Security Considerations

   The security considerations of [RFC3261], [RFC4975], [RFC6120],
   [RFC7247], [RFC7701], and [XEP-0045] apply.

   This document specifies methods for exchanging groupchat messages
   through a gateway that translates between SIP and XMPP.  Such a
   gateway MUST be compliant with the minimum security requirements of
   the protocols for which it translates (i.e., MSRP/SIP and XMPP).  The
   addition of gateways to the security models of MSRP, SIP, and XMPP
   introduces some new risks.  In particular, end-to-end security
   properties (especially confidentiality and integrity) between user
   agents that interface through an MSRP-to-XMPP gateway can be provided
   only if common formats are supported; unfortunately, although
   [RFC3862] specifies such a format for one-to-one instant messages,
   the problem of end-to-end security for multi-party messaging has not
   been solved in a standardized way.

   Some of the features that are not addressed by the minimal
   interoperability baseline defined in this document are relevant to
   security, such as the ability to administer rooms, kick out and ban
   users, and enable room moderation.  Users needing to take advantage
   of such features cannot do so through a gateway in a standardized
   manner and therefore will need to use native clients for the relevant
   protocol (MSRP or XMPP).

   As mentioned in [RFC7572], there are several possible methods for
   end-to-end encryption of one-to-one instant messages.  Unfortunately,
   because there is no widely deployed method for end-to-end encryption
   of multi-party instant messages, this document cannot provide a
   recommendation in this regard.

Top      Up      ToC       Page 39 
10.  References

10.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M., and E.
              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
              DOI 10.17487/RFC3261, June 2002,
              <http://www.rfc-editor.org/info/rfc3261>.

   [RFC4579]  Johnston, A. and O. Levin, "Session Initiation Protocol
              (SIP) Call Control - Conferencing for User Agents",
              BCP 119, RFC 4579, DOI 10.17487/RFC4579, August 2006,
              <http://www.rfc-editor.org/info/rfc4579>.

   [RFC4975]  Campbell, B., Ed., Mahy, R., Ed., and C. Jennings, Ed.,
              "The Message Session Relay Protocol (MSRP)", RFC 4975,
              DOI 10.17487/RFC4975, September 2007,
              <http://www.rfc-editor.org/info/rfc4975>.

   [RFC5627]  Rosenberg, J., "Obtaining and Using Globally Routable User
              Agent URIs (GRUUs) in the Session Initiation Protocol
              (SIP)", RFC 5627, DOI 10.17487/RFC5627, October 2009,
              <http://www.rfc-editor.org/info/rfc5627>.

   [RFC6120]  Saint-Andre, P., "Extensible Messaging and Presence
              Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120,
              March 2011, <http://www.rfc-editor.org/info/rfc6120>.

   [RFC6121]  Saint-Andre, P., "Extensible Messaging and Presence
              Protocol (XMPP): Instant Messaging and Presence",
              RFC 6121, DOI 10.17487/RFC6121, March 2011,
              <http://www.rfc-editor.org/info/rfc6121>.

   [RFC7247]  Saint-Andre, P., Houri, A., and J. Hildebrand,
              "Interworking between the Session Initiation Protocol
              (SIP) and the Extensible Messaging and Presence Protocol
              (XMPP): Architecture, Addresses, and Error Handling",
              RFC 7247, DOI 10.17487/RFC7247, May 2014,
              <http://www.rfc-editor.org/info/rfc7247>.

Top      Up      ToC       Page 40 
   [RFC7573]  Saint-Andre, P. and S. Loreto, "Interworking between the
              Session Initiation Protocol (SIP) and the Extensible
              Messaging and Presence Protocol (XMPP): One-to-One Text
              Chat Sessions", RFC 7573, DOI 10.17487/RFC7573, June 2015,
              <http://www.rfc-editor.org/info/rfc7573>.

   [RFC7700]  Saint-Andre, P., "Preparation, Enforcement, and Comparison
              of Internationalized Strings Representing Nicknames",
              RFC 7700, DOI 10.17487/RFC7700, December 2015,
              <http://www.rfc-editor.org/info/rfc7700>.

   [RFC7701]  Niemi, A., Garcia-Martin, M., and G. Sandbakken, "Multi-
              party Chat Using the Message Session Relay Protocol
              (MSRP)", RFC 7701, DOI 10.17487/RFC7701, December 2015,
              <http://www.rfc-editor.org/info/rfc7701>.

   [XEP-0045] Saint-Andre, P., "Multi-User Chat", XSF XEP 0045, February
              2012, <http://www.xmpp.org/extensions/xep-0045.html>.

10.2.  Informative References

   [RFC3515]  Sparks, R., "The Session Initiation Protocol (SIP) Refer
              Method", RFC 3515, DOI 10.17487/RFC3515, April 2003,
              <http://www.rfc-editor.org/info/rfc3515>.

   [RFC3862]  Klyne, G. and D. Atkins, "Common Presence and Instant
              Messaging (CPIM): Message Format", RFC 3862,
              DOI 10.17487/RFC3862, August 2004,
              <http://www.rfc-editor.org/info/rfc3862>.

   [RFC4353]  Rosenberg, J., "A Framework for Conferencing with the
              Session Initiation Protocol (SIP)", RFC 4353,
              DOI 10.17487/RFC4353, February 2006,
              <http://www.rfc-editor.org/info/rfc4353>.

   [RFC4566]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
              Description Protocol", RFC 4566, DOI 10.17487/RFC4566,
              July 2006, <http://www.rfc-editor.org/info/rfc4566>.

   [RFC4575]  Rosenberg, J., Schulzrinne, H., and O. Levin, Ed., "A
              Session Initiation Protocol (SIP) Event Package for
              Conference State", RFC 4575, DOI 10.17487/RFC4575, August
              2006, <http://www.rfc-editor.org/info/rfc4575>.

Top      Up      ToC       Page 41 
   [RFC6501]  Novo, O., Camarillo, G., Morgan, D., and J. Urpalainen,
              "Conference Information Data Model for Centralized
              Conferencing (XCON)", RFC 6501, DOI 10.17487/RFC6501,
              March 2012, <http://www.rfc-editor.org/info/rfc6501>.

   [RFC6502]  Camarillo, G., Srinivasan, S., Even, R., and J.
              Urpalainen, "Conference Event Package Data Format
              Extension for Centralized Conferencing (XCON)", RFC 6502,
              DOI 10.17487/RFC6502, March 2012,
              <http://www.rfc-editor.org/info/rfc6502>.

   [RFC7572]  Saint-Andre, P., Houri, A., and J. Hildebrand,
              "Interworking between the Session Initiation Protocol
              (SIP) and the Extensible Messaging and Presence Protocol
              (XMPP): Instant Messaging", RFC 7572,
              DOI 10.17487/RFC7572, June 2015,
              <http://www.rfc-editor.org/info/rfc7572>.

   [RFC7614]  Sparks, R., "Explicit Subscriptions for the REFER Method",
              RFC 7614, DOI 10.17487/RFC7614, August 2015,
              <http://www.rfc-editor.org/info/rfc7614>.

   [RFC7647]  Sparks, R. and A. Roach, "Clarifications for the Use of
              REFER with RFC 6665", RFC 7647, DOI 10.17487/RFC7647,
              September 2015, <http://www.rfc-editor.org/info/rfc7647>.

   [XEP-0172] Saint-Andre, P. and V. Mercier, "User Nickname", XSF
              XEP 0172, March 2012,
              <http://xmpp.org/extensions/xep-0172.html>.

   [XEP-0249] Saint-Andre, P., "Direct MUC Invitations", XSF XEP 0249,
              September 2011,
              <http://xmpp.org/extensions/xep-0249.html>.

Top      Up      ToC       Page 42 
Acknowledgements

   Special thanks to Fabio Forno for coauthoring an early draft version
   of this document and to Ben Campbell for his detailed and insightful
   reviews.

   Thanks also to Dave Crocker, Philipp Hancke, Olle Johansson, Paul
   Kyzivat, and Matt Ryan for their feedback.

   Leif Johansson reviewed the document on behalf of the Security
   Directorate.

   Stephen Farrell, Barry Leiba, Pete Resnick, and Martin Stiemerling
   provided helpful input during IESG review.

   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.

   Peter Saint-Andre wishes to acknowledge Cisco Systems, Inc., for
   employing him during his work on earlier draft versions of this
   document.

Top      Up      ToC       Page 43 
Authors' Addresses

   Peter Saint-Andre
   &yet

   Email: peter@andyet.com
   URI:   https://andyet.com/


   Saul Ibarra Corretge
   AG Projects
   Dr. Leijdsstraat 92
   Haarlem  2021RK
   The Netherlands

   Email: saul@ag-projects.com


   Salvatore Loreto
   Ericsson
   Hirsalantie 11
   Jorvas  02420
   Finland

   Email: Salvatore.Loreto@ericsson.com