RFC 7573

Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): One-to-One Text Chat Sessions

📅 published June 2015, from ietf

Interworking between SIP and XMPP: One-to-One Text Chat Sessions 💖

okay bestie, the title block is basically the ID card 🪪 for this RFC. It's RFC 7573, published by the Internet Engineering Task Force (IETF), as a Standards Track document with ISSN 2070-1721, dated June 2015. The authors are P. Saint-Andre (from &yet) and S. Loreto (from Ericsson). It's the official mapping for SIP and XMPP one-to-one chat, so it's giving authority 👑

Abstract ✨

this doc defines a two-way protocol mapping for swapping instant messages in a one-to-one chat session between a SIP user and an XMPP user 🧚 for SIP text chat specifically, it maps to the Message Session Relay Protocol (MSRP). the whole thing is so clean ngl 💅

Status of This Memo 🎀

this is an Internet Standards Track document, no cap.

it's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community. it got public review and was approved for publication by the Internet Engineering Steering Group (IESG). if you want more on Internet Standards, check Section 2 of RFC 5741.

info about the current status, any errata, and how to send feedback is at http://www.rfc-editor.org/info/rfc7573 🦋

Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.

this document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the date of publication. please actually read those, bestie, because they explain your rights and restrictions for this doc 🫶

Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they are provided without warranty as described in the Simplified BSD License.

Table of Contents 🧭

1. Introduction ....................................................2
2. Intended Audience ...............................................3
3. Terminology .....................................................4
4. XMPP to MSRP ....................................................4
5. MSRP to XMPP ....................................................9
6. Composing Events ...............................................13
   6.1. Use of the Gone Chat State ................................14
7. Delivery Reports ...............................................15
8. Message Size ...................................................17
9. Internationalization Considerations ............................18
10. Security Considerations .......................................18
11. References ....................................................18
   11.1. Normative References .....................................18
   11.2. Informative References ...................................19
Acknowledgements ..................................................20
Authors' Addresses ................................................20

1. Introduction 🦋

okay so both SIP [RFC3261] and XMPP [RFC6120] can be used for one-to-one text chat over the Internet. to make sure these two can talk to each other, it's super important to define mappings in both directions 💜

the architectural assumptions behind these mappings are in [RFC7247], including how addresses and error conditions get mapped 🧚 this document specifies mappings for one-to-one text chat sessions (sometimes called "session-mode" messaging). specifically, it maps between XMPP messages of type "chat" and the Message Session Relay Protocol (MSRP) [RFC4975]. MSRP is commonly used in SIP-based systems for chat, but it's not actually tied to SIP, so non-SIP technologies can use it too 🫶 mappings for single instant messages and groupchat live in [RFC7572] and [GROUPCHAT].

the approach here is to directly map syntax and semantics from one protocol to the other. this mapping depends on the protocols defined in the following specs:

  • XMPP chat sessions using message stanzas of type "chat" are specified in [RFC6121].
  • MSRP chat sessions using the SIP INVITE and SEND request types are specified in [RFC4975].

in SIP-based systems that use MSRP, a chat session is formally negotiated, just like any other session type in SIP 📞 but XMPP is different. a one-to-one chat "session" in XMPP is informal and never formally negotiated. a user just sends a "chat" message to a contact, the contact replies, and all the messages swapped in a defined stretch of time count as one chat session. ideally those messages are tied together with an XMPP <thread/> element, as described in Section 5.1 of [RFC6121] 🧵

to close that gap, a gateway that wants to map between SIP/MSRP and XMPP for one-to-one chats needs to keep some extra state, as described below 🍓

2. Intended Audience 📚

the documents in this series are for software developers who already have a system built on one of these technologies (like SIP) and want to let that system talk to systems built on the other one (like XMPP) 🌈 we assume readers already know the core specs for both SIP [RFC3261] and XMPP [RFC6120], the base document for this series [RFC7247], and these chat-related specs:

  • "The Message Session Relay Protocol (MSRP)" [RFC4975]
  • "Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence" [RFC6121]
  • "Indication of Message Composition for Instant Messaging" [RFC3994]
  • "Chat State Notifications" [XEP-0085]

note well 👀 that not every protocol-compliant message is shown (SIP 100 TRYING messages, for example), so the reader can focus on the essential parts of the protocol flows.

3. Terminology 💅

a bunch of the terms used here are explained in [RFC3261], [RFC4975], [RFC6120], and [RFC6121] 📖

in flow diagrams, SIP/MSRP traffic is drawn with arrows like ***>, and XMPP traffic is drawn with arrows like ...> ✨

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 [RFC2119] 🔥

4. XMPP to MSRP ✨

okay so bestie, this section is about how an XMPP chat can turn into an MSRP session 💖 In XMPP, the "informal session" approach is basically just sending someone a <message/> of type "chat" without setting up any session stuff ahead of time 🎀 (see [RFC6121]). That lines up super well with a SIP MESSAGE request, which is covered in [RFC7572] 🦋 BUT the XMPP informal session can also get mapped to MSRP, as long as the XMPP-to-SIP gateway keeps some extra state around 🧚 Here's the order of events, no cap 👑

XMPP            XMPP        XMPP-to-MSRP        SIP             SIP
User           Server         Gateway          Server          User
 |               |               |               |               |
 | (F1) XMPP     |               |               |               |
 | message       |               |               |               |
 |..............>|               |               |               |
 |               | (F2) XMPP     |               |               |
 |               | message       |               |               |
 |               |..............>|               |               |
 |               |               | (F3) SIP      |               |
 |               |               | INVITE        |               |
 |               |               |**************>|               |
 |               |               |               | (F4) SIP      |
 |               |               |               | INVITE        |
 |               |               |               |**************>|
 |               |               |               | (F5) SIP      |
 |               |               |               | 200 OK        |
 |               |               |               |<**************|
 |               |               | (F6) SIP      |               |
 |               |               | 200 OK        |               |
 |               |               |<**************|               |
 |               |               | (F7) SIP ACK  |               |
 |               |               |**************>|               |
 |               |               |               | (F8) SIP ACK  |
 |               |               |               |**************>|
 |               |               | (F9) MSRP SEND                |
 |               |               |******************************>|
 .               .               .               .               .
 .               .               .               .               .
 |               |               | (F10) MSRP SEND               |
 |               |               |<******************************|
 |               | (F11) XMPP    |               |               |
 |               | message       |               |               |
 |               |<..............|               |               |
 | (F12) XMPP    |               |               |               |
 | message       |               |               |               |
 |<..............|               |               |               |
 .               .               .               .               .
 .               .               .               .               .
 |               |               |               | (F13) SIP BYE |
 |               |               |               |<**************|
 |               |               | (F14) SIP BYE |               |
 |               |               |<**************|               |
 |               |               | (F15) SIP     |               |
 |               |               | 200 OK        |               |
 |               |               |**************>|               |
 |               |               |               | (F16) SIP     |
 |               |               |               | 200 OK        |
 |               |               |               |**************>|

              Figure 1: XMPP to MSRP Order of Events

The mapping of XMPP syntax to SIP syntax MUST be as specified in [RFC7572]. Non-negotiable, the spec literally says so 🫶

First up, the XMPP user generates a chat message, the start of the whole drama 🌸

Example 1: Juliet Sends XMPP Message (F1)

<message from='juliet@example.com/yn0cl4bnw0yr3vym'
         to='romeo@example.net'
         id='a786hjs2'
         type='chat'>
  <thread>29377446-0CBB-4296-8958-590D79094C50</thread>
  <body>Art thou not Romeo, and a Montague?</body>
</message>

When the XMPP server gets a message stanza like this, it has to figure out what the domainpart of the 'to' address is, and it does that by following the procedures in Section 5 of [RFC7247] 🔥 If the domain is a SIP domain, the XMPP server hands the message stanza off to an XMPP-to-SIP gateway or connection manager that natively talks to MSRP-aware SIP servers 💅

So the XMPP-to-SIP gateway at the XMPP server starts an MSRP session with Romeo on Juliet's behalf 🦋 (Lowkey important: the gateway has no reliable way to know whether Romeo's client supports MSRP, so if it doesn't, the session initiation might end in an error 💀)

Example 2: Gateway Starts SIP Session on Behalf of Juliet (F3)

INVITE sip:romeo@example.net SIP/2.0
To: <sip:romeo@example.net>
From: <sip:juliet@example.com>
Contact: <sip:juliet@example.com>;gr=yn0cl4bnw0yr3vym
Subject: Open chat with Juliet?
Call-ID: 29377446-0CBB-4296-8958-590D79094C50
CSeq: 1 INVITE
Content-Type: application/sdp

c=IN IP4 x2s.example.com
m=message 7654 TCP/MSRP *
a=accept-types:text/plain
a=path:msrp://x2s.example.com:7654/jshA7weztas;tcp

Here we're assuming Romeo's client supports MSRP and that Romeo accepts the MSRP session request 🙈

Example 3: Romeo Accepts Session Request (F5)

SIP/2.0 200 OK
From: <sip:juliet@example.com>
To: <sip:romeo@example.net>
Contact: <sip:romeo@example.net>;gr=dr4hcr0st3lup4c
Call-ID: 29377446-0CBB-4296-8958-590D79094C50
CSeq: 1 INVITE
Content-Type: application/sdp

c=IN IP4 s2x.example.net
m=message 12763 TCP/MSRP *
a=accept-types:text/plain
a=path:msrp://s2x.example.net:12763/kjhd37s2s20w2a;tcp

Then the XMPP-to-SIP gateway acknowledges the session acceptance on Juliet's behalf ✨

Example 4: Gateway Sends ACK to Romeo (F7)

ACK sip:juliet@example.com SIP/2.0
To: <sip:romeo@example.net>;gr=dr4hcr0st3lup4c
From: <sip:juliet@example.com>
Contact: <sip:juliet@example.com>;gr=yn0cl4bnw0yr3vym
Call-ID: 29377446-0CBB-4296-8958-590D79094C50
CSeq: 2 ACK

Next, the XMPP-to-SIP gateway transforms the original XMPP chat message into MSRP 🎀

Example 5: Gateway Maps XMPP Message to MSRP (F9)

MSRP a786hjs2 SEND
From-Path: msrp://x2s.example.com:7654/jshA7weztas;tcp
To-Path: msrp://s2x.example.net:12763/kjhd37s2s20w2a;tcp
Message-ID: 54C6F4F1-A39C-47D6-8718-FA65B3D0414A
Byte-Range: 1-25/25
Content-Type: text/plain

Art thou not Romeo, and a Montague?
-------a786hjs2$

Romeo can then send a reply from his MSRP client, iconic behaviour 🍓

Example 6: Romeo Sends Reply (F10)

MSRP di2fs53v SEND
To-Path: msrp://x2s.example.com:7654/jshA7weztas;tcp
From-Path: msrp://s2x.example.net:12763/kjhd37s2s20w2a;tcp
Message-ID: 6480C096-937A-46E7-BF9D-1353706B60AA
Byte-Range: 1-25/25
Failure-Report: no
Content-Type: text/plain

Neither, fair saint, if either thee dislike.
-------di2fs53v$

The SIP-to-XMPP gateway then transforms that message into the right XMPP syntax so it can be routed to the intended recipient 🧚

Example 7: Gateway Maps MSRP Message to XMPP (F11)

<message from='romeo@example.net/dr4hcr0st3lup4c'
         to='juliet@example.com/yn0cl4bnw0yr3vym'
         id='di2fs53v'
         type='chat'>
  <thread>29377446-0CBB-4296-8958-590D79094C50</thread>
  <body>Neither, fair saint, if either thee dislike.</body>
</message>

When the MSRP user wants to end the chat session, their MSRP client sends a SIP BYE 👋

Example 8: Romeo Terminates Chat Session (F13)

BYE juliet@example.com sip: SIP/2.0
From: <sip:juliet@example.com>;tag=786
To: <sip:romeo@example.net>;tag=087js
Call-ID: 29377446-0CBB-4296-8958-590D79094C50
CSeq: 3 BYE
Content-Length: 0

The BYE then gets acknowledged by the XMPP-to-SIP gateway 💖

Example 9: Gateway Acknowledges Termination (F15)

SIP/2.0 200 OK
From: <sip:juliet@example.com>;tag=786
To: <sip:romeo@example.net>;tag=087js
Call-ID: 29377446-0CBB-4296-8958-590D79094C50
CSeq: 3 BYE
Content-Length: 0

Because there's no formal session on the XMPP side, there's no matching message from the gateway to the XMPP user. BUT it's reasonable for the gateway to send a "gone" chat state notification [XEP-0085], as described under Section 6.1 ✨

Also, [RFC6121] doesn't define any explicit method for an XMPP user to formally end a chat session. So a gateway would need to either listen for a "gone" chat state notification from the XMPP user, or run a timer that treats the XMPP informal chat session as ended after some amount of time has passed ⏰ ([XEP-0085] suggests generating a "gone" chat state if a user hasn't interacted with the chat session interface, system, or device for a relatively long period of time, e.g., 10 minutes) 🥺

5. MSRP to XMPP ✨

okay so this is the other direction 💌 when an MSRP client sends messages through a gateway to an XMPP client, the order of events goes like this 🧚

   SIP             SIP         MSRP-to-XMPP       XMPP            XMPP
   User           Server         Gateway         Server           User
    |               |               |               |               |
    | (F17) SIP     |               |               |               |
    | INVITE        |               |               |               |
    |**************>|               |               |               |
    |               | (F18) SIP     |               |               |
    |               | INVITE        |               |               |
    |               |**************>|               |               |
    |               | (F19) SIP     |               |               |
    |               | 200 OK        |               |               |
    |               |<**************|               |               |
    | (F20) SIP     |               |               |               |
    | 200 OK        |               |               |               |
    |<**************|               |               |               |
    | (F21) SIP ACK |               |               |               |
    |**************>|               |               |               |
    |               | (F22) SIP ACK |               |               |
    |               |**************>|               |               |
    | (F23) MSRP SEND               |               |               |
    |******************************>|               |               |
    |               |               | (F24) XMPP    |               |
    |               |               | message       |               |
    |               |               |..............>|               |
    |               |               |               | (F25) XMPP    |
    |               |               |               | message       |
    |               |               |               |..............>|
    .               .               .               .               .
    .               .               .               .               .
    |               |               |               | (F26) XMPP    |
    |               |               |               | message       |
    |               |               |               |<..............|
    |               |               | (F27) XMPP    |               |
    |               |               | message       |               |
    |               |               |<..............|               |
    | (F28) MSRP SEND               |               |               |
    |<******************************|               |               |
    .               .               .               .               .
    .               .               .               .               .
    |               |               |               |               |
    |               |               |               |               |
    | (F29) SIP BYE |               |               |               |
    |**************>|               |               |               |
    |               | (F30) SIP BYE |               |               |
    |               |**************>|               |               |
    |               | (F31) SIP     |               |               |
    |               | 200 OK        |               |               |
    |               |<**************|               |               |
    | (F32) SIP     |               |               |               |
    | 200 OK        |               |               |               |
    |<**************|               |               |               |

Figure 2: MSRP to XMPP Order of Events

The mapping of SIP syntax to XMPP syntax MUST be as specified in [RFC7572].

The flow kicks off when Romeo starts a chat session with Juliet, and yes, it's a whole saga 🎀

Example 10: Romeo Starts Chat Session (F17)

   | INVITE sip:juliet@example.com SIP/2.0
   | From: <sip:romeo@example.net>
   | To: <sip:juliet@example.com>
   | Contact: <sip:romeo@example.net>;gr=dr4hcr0st3lup4c
   | Subject: Open chat with Romeo?
   | Call-ID: F6989A8C-DE8A-4E21-8E07-F0898304796F
   | CSeq: 1 INVITE
   | Content-Type: application/sdp
   |
   | c=IN IP4 s2x.example.net
   | m=message 7313 TCP/MSRP *
   | a=accept-types:text/plain
   | a=path:msrp://s2x.example.net:7313/ansp71weztas;tcp

So when the INVITE lands, the SIP (MSRP) server has to figure out whose domain it is, looking at the domain part of the Request-URI or To header 👀 It does that by following the procedures in Section 5 of [RFC7247]. If the domain turns out to be an XMPP domain, the SIP server hands the INVITE off to an associated MSRP-to-XMPP gateway or connection manager, the one that actually speaks XMPP natively 🫶

Example 11: Gateway Accepts Session on Juliet's Behalf (F19)

   | SIP/2.0 200 OK
   | From: <sip:romeo@example.net>;gr=dr4hcr0st3lup4c
   | To: <sip:juliet@example.com>
   | Contact: <sip:juliet@example.com>;gr=yn0cl4bnw0yr3vym
   | Call-ID: F6989A8C-DE8A-4E21-8E07-F0898304796F
   | CSeq: 1 INVITE
   | Content-Type: application/sdp
   |
   | c=IN IP4 x2s.example.com
   | m=message 8763 TCP/MSRP *
   | a=accept-types:text/plain
   | a=path:msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp

Example 12: Romeo Sends ACK (F21)

   | ACK sip:juliet@example.com SIP/2.0
   | To: <sip:juliet@example.com>;gr=yn0cl4bnw0yr3vym
   | From: <sip:romeo@example.net>
   | Contact: <sip:romeo@example.net>;gr=dr4hcr0st3lup4c
   | Call-ID: F6989A8C-DE8A-4E21-8E07-F0898304796F
   | CSeq: 2 ACK

Example 13: Romeo Sends Message (F23)

   | MSRP ad49kswow SEND
   | To-Path: msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp
   | From-Path: msrp://s2x.example.net:7313/ansp71weztas;tcp
   | Message-ID: 676FDB92-7852-443A-8005-2A1B9FE44F4E
   | Byte-Range: 1-32/32
   | Failure-Report: no
   | Content-Type: text/plain
   |
   | I take thee at thy word ...
   | -------ad49kswow$

Example 14: MSRP-to-XMPP Gateway Maps MSRP Message to XMPP (F24)

   | <message from='romeo@example.net'
   |          to='juliet@example.com'
   |          id='ad49kswow'
   |          type='chat'>
   |   <thread>F6989A8C-DE8A-4E21-8E07-F0898304796F</thread>
   |   <body>I take thee at thy word ...</body>
   | </message>

Example 15: Juliet Sends Reply (F26)

   | <message from='juliet@example.com'
   |          to='romeo@example.net'
   |          id='ms53b7z9'
   |          type='chat'>
   |   <thread>29377446-0CBB-4296-8958-590D79094C50</thread>
   |   <body>What man art thou ...?</body>
   | </message>

Example 16: Gateway Maps XMPP Message to MSRP (F28)

   | MSRP ms53b7z9 SEND
   | To-Path: msrp://s2x.example.net:7313/jshA7weztas;tcp
   | From-Path: msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp
   | Message-ID: 17EBA17B-94C0-463B-AD84-DE405C4C9D41
   | Byte-Range: 1-25/25
   | Failure-Report: no
   | Content-Type: text/plain
   |
   | What man art thou ...?
   | -------ms53b7z9$

Example 17: Romeo Terminates Chat Session (F29)

   | BYE juliet@example.com sip: SIP/2.0
   | To: <sip:juliet@example.com>;gr=yn0cl4bnw0yr3vym
   | From: <sip:romeo@example.net>
   | Contact: <sip:romeo@example.net>;gr=dr4hcr0st3lup4c
   | Call-ID: F6989A8C-DE8A-4E21-8E07-F0898304796F
   | CSeq: 3 BYE
   | Content-Length: 0

Example 18: Gateway Acknowledges Termination of Session on Behalf of Juliet (F31)

   | SIP/2.0 200 OK
   | To: <sip:juliet@example.com>;gr=yn0cl4bnw0yr3vym
   | From: <sip:romeo@example.net>
   | Contact: <sip:romeo@example.net>;gr=dr4hcr0st3lup4c
   | Call-ID: F6989A8C-DE8A-4E21-8E07-F0898304796F
   | CSeq: 3 BYE

6. Composing Events ⌨️💭

okay the "someone is typing..." feature 😭 both XMPP and MSRP let a client find out when the person they're chatting with is composing a message inside a chat session. literally so relatable.

For XMPP, the Chat State Notifications spec [XEP-0085] has five states: active, inactive, gone, composing, and paused. Some are about the act of typing (composing, paused), and others are about whether the sender is still involved in the chat (active, inactive, gone). Quick heads up: the "gone" chat state is NOT the same thing as the <gone/> stanza error condition from [RFC6120], so don't mix them up 🙈

For MSRP (and, in general, for SIP for Instant Messaging and Presence Leveraging Extensions (SIMPLE) systems), the Indication of Message Composition for Instant Messaging spec [RFC3994] has just two states: idle and active. Idle means the sender isn't actively typing, and active means they are, so the sending client just flips back and forth between the two 💅

Because XEP-0085 states can carry info that [RFC3994] doesn't capture, gateways get to choose: either (a) map only the composing-related states, or (b) map all the XEP-0085 states. Both are valid, babe 🦋

The following mappings are suggested.

Table 3: Mapping of SIP/SIMPLE isComposing Events to XMPP Chat states

   +-------------------+--------------------+
   | isComposing Event |  Chat State        |
   +-------------------+--------------------+
   | active            |  composing         |
   | idle              |  active            |
   +-------------------+--------------------+

Table 4: Mapping of XMPP Chat States to SIP/SIMPLE isComposing Events

   +-------------------+--------------------+
   | Chat State        | isComposing Event  |
   +-------------------+--------------------+
   | active            |  idle              |
   | inactive          |  idle              |
   | gone              |  none (Section 6.1)|
   | composing         |  active            |
   | paused            |  idle              |
   +-------------------+--------------------+

The XMPP Chat State Notifications spec [XEP-0085] allows "standalone notifications" to be sent outside the context of a message, theoretically even before any messages are exchanged 🤯 So a gateway could send an <active/> notification to the XMPP user when the SIP user accepts or starts a chat session (that's after F6 in Section 4 or after F22 in Section 5). BUT, and this is a big but, XMPP clients might not expect that as a way to say "the informal chat has started" 💀 so it's kinda a vibe check.

6.1. Use of the Gone Chat State ✨

okay so the "gone" chat state doesn't have a direct isComposing equivalent 🙈 but it's still super useful. when an XMPP-to-MSRP gateway gets a "gone" state, it can use that as the signal to end the formal chat session in MSRP, which means sending a SIP BYE for the session from the gateway to the SIP user 🫶 the examples below show this indirect mapping. it would happen if the XMPP user sent a "gone" chat state after step F12 in Figure 1 or step F28 in Figure 2. in either case, the XMPP user ends the session instead of the SIP user, which is what Figures 1 and 2 currently show 💅

Example 19: Juliet Sends Gone Chat State

<message from='juliet@example.com'
         id='nx62f197'
         to='romeo@example.net'
         type='chat'>
  <thread>29377446-0CBB-4296-8958-590D79094C50</thread>
  <gone xmlns='http://jabber.org/protocol/chatstates'/>
</message>

Example 20: XMPP-to-MSRP Gateway Maps Gone Chat State to SIP BYE

BYE romeo@example.net sip: SIP/2.0
From: <sip:juliet@example.com>;tag=786
To: <sip:romeo@example.net>;tag=087js
Call-ID: 29377446-0CBB-4296-8958-590D79094C50
CSeq: 3 BYE
Content-Length: 0

and it works the other way too 🦋 when an MSRP-to-XMPP gateway gets a SIP BYE, that can trigger a "gone" chat state notification to the XMPP user. this indirect mapping would happen after step F14 in Figure 1 or step F30 in Figure 2. (bestie, the vibes are so cyclical rn 🌈)

Example 21: Romeo Terminates Chat Session

BYE juliet@example.com sip: SIP/2.0
To: <sip:juliet@example.com>;gr=yn0cl4bnw0yr3vym
From: <sip:romeo@example.net>
Contact: <sip:romeo@example.net>;gr=dr4hcr0st3lup4c
Call-ID: F6989A8C-DE8A-4E21-8E07-F0898304796F
CSeq: 3 BYE
Content-Length: 0

Example 22: MSRP-to-XMPP Gateway Generates Gone Chat State

<message from='romeo@example.net'
         id='hs61v397'
         to='juliet@example.com'
         type='chat'>
  <thread>F6989A8C-DE8A-4E21-8E07-F0898304796F</thread>
  <gone xmlns='http://jabber.org/protocol/chatstates'/>
</message>

so to make all of this work 🎀, gateways that support chat state notifications MUST support the "gone" state. it's only recommended, not required, by [XEP-0085], but we're going full send here 😭

it's also reasonable for gateways to run timers that automatically trigger a "gone" chat state if the XMPP user hasn't sent a message within the "session" for a certain amount of time. [XEP-0085] suggests generating a "gone" chat state when a user hasn't interacted with the chat session interface, system, or device for a relatively long period of time, e.g., 10 minutes ⏰🌸

7. Delivery Reports 📬

okay the delivery reports part is so satisfying 🥹 both XMPP and MSRP let a client find out when a message has been received by the intended recipient.

for XMPP, the Message Receipts specification [XEP-0184] defines a method and XML namespace for asking for, and returning, indications that a message has reached a client controlled by the intended recipient 💌

for MSRP, there's a native reporting feature in the form of REPORT chunks (see Sections 7.1.2 and 7.1.3 of [RFC4975]) ✨

the XMPP Message Receipts element <request xmlns='urn:xmpp:receipts'/> gets mapped to an MSRP Success-Report header field with a value of "yes", and the XMPP element <received xmlns='urn:xmpp:receipts'/> gets mapped to an MSRP REPORT request 🔁

going the other direction, a Success-Report header field with a value of "yes" in an MSRP SEND request gets mapped to an XMPP <request xmlns='urn:xmpp:receipts'/> element. an MSRP REPORT request gets mapped to an XMPP message that only contains a <received xmlns='urn:xmpp:receipts'/> element 🦋

one thing to know: the XMPP Message Receipts specification doesn't support failure reports, so there's no mapping for the MSRP Failure-Report header field. gateways SHOULD set that header field to "no" 🙈

examples time bestie 🍓 first, the XMPP user sends a message asking for a delivery notification.

Example 23: Juliet Sends XMPP Message with Receipt Request

<message from='juliet@example.com'
         id='bf9m36d5'
         to='romeo@example.net'
         type='chat'>
  <thread>29377446-0CBB-4296-8958-590D79094C50</thread>
  <body>What man art thou ...?</body>
  <request xmlns='urn:xmpp:receipts'/>
</message>

Example 24: Gateway Maps XMPP Message to MSRP

MSRP bf9m36d5 SEND
To-Path: msrp://s2x.example.net:7313/jshA7weztas;tcp
From-Path: msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp
Message-ID: 6187CF9B-317A-41DA-BB6A-5E48A9C794EF
Byte-Range: 1-25/25
Success-Report: yes
Failure-Report: no
Content-Type: text/plain

What man art thou ...?
-------bf9m36d5$

then the recipient sends back a report 💖

Example 25: Romeo Returns MSRP Receipt

MSRP hx74g336 REPORT
To-Path: msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp
From-Path: msrp://s2x.example.net:7313/jshA7weztas;tcp
Message-ID: 6187CF9B-317A-41DA-BB6A-5E48A9C794EF
Byte-Range: 1-106/106
Status: 000 200 OK
-------hx74g336$

Example 26: MSRP-to-XMPP Gateway Maps Receipt to XMPP

<message from='romeo@example.net'
         id='hx74g336'
         to='juliet@example.com'>
  <received xmlns='urn:xmpp:receipts' id='87652491'/>
</message>

8. Message Size 📏

so unlike page-mode messaging [RFC3428] (which says a MESSAGE request can't be bigger than 1300 bytes), session-mode messaging [RFC4975] can handle much bigger messages 🙌 MSRP has a chunking mechanism, so a large message can get split up into several MSRP SEND requests. the MSRP gateway at an XMPP service acts as an MSRP endpoint, so it's the one responsible for receiving chunked messages and putting them back together into a single message for the XMPP recipient 🧩 (and yes, implementations really need to be careful about accepting very large messages, so check Section 14.5 of [RFC4975] 😬)

there's no hard limit on the size of an XMPP stanza, but in practice, most XMPP services (at least on the public Internet) set a maximum stanza size to help prevent denial-of-service attacks 🛡️ as specified in Section 13.12 of [RFC6120], that maximum isn't allowed to be less than 10,000 bytes.

the administrators of an XMPP service need to make sure the matching MSRP gateway is configured with the same or a smaller maximum MSRP message size as the maximum XMPP stanza size 🎀 this lets the gateway return a good value for the Session Description Protocol (SDP) "max-size" attribute (see Section 8.6 of [RFC4975]), and it lets the gateway handle incoming messages larger than the configured limits properly 💅

if an MSRP-to-XMPP gateway implementation gets an MSRP message that goes over its configured limit (like we just described), it MUST return an MSRP 413 error. for example, it can do this in response to the first SEND request whose Byte-Range header field shows a byte total over the limit 🚫

9. Internationalization Considerations 🌍

if you want the details on internationalized text in messages, check out [RFC7572] 💜

10. Security Considerations 🔐

this part is serious, bestie, so no cap, read every bit of it 😭 detailed security considerations are in the following documents:

  • for instant messaging protocols in general, see [RFC2779]
  • for MSRP chat, see [RFC4975]; for when SIP is used to negotiate MSRP sessions, see [RFC3261]
  • for XMPP-based instant messaging, see [RFC6121] and also [RFC6120]
  • for SIP-XMPP interworking in general, see [RFC7247]
  • for end-to-end encryption of instant messages, see [RFC7572]

11. References 📚

11.1. Normative References

11.2. Informative References

  • [GROUPCHAT] Saint-Andre, P., Corretge, S., and S. Loreto, "Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Groupchat", Work in Progress, draft-ietf-stox-groupchat-11, March 2015.
  • [RFC2779] Day, M., Aggarwal, S., Mohr, G., and J. Vincent, "Instant Messaging / Presence Protocol Requirements", RFC 2779, DOI 10.17487/RFC2779, February 2000, <http://www.rfc-editor.org/info/rfc2779>.
  • [RFC3428] Campbell, B., Ed., Rosenberg, J., Schulzrinne, H., Huitema, C., and D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, DOI 10.17487/RFC3428, December 2002, <http://www.rfc-editor.org/info/rfc3428>.

Acknowledgements ✨

Okay bestie, huge shoutout to Eddy Gavita and Nazin Hossain for coauthoring an early draft of this doc 🫶 they were literally the first ones in the chat 💖

Thanks to Mary Barnes, Ben Campbell, Dave Crocker, Adrian Georgescu, Philipp Hancke, Saul Ibarra Corretge, Tory Patnoe, and Matt Ryan for giving feedback. You all are iconic 👑

Stephen Farrell, Brian Haberman, Joel Jaeggli, Barry Leiba, Kathleen Moriarty, and Pete Resnick helped out with input during IESG review. Their notes made the whole thing so much better 🌸

The authors also want to thank Markus Isomaki and Yana Stamcheva, who were the working group chairs 🦋, and Gonzalo Camarillo and Alissa Cooper, who were the sponsoring Area Directors 💅 ily for keeping everything on track.

Peter Saint-Andre wants to acknowledge Cisco Systems, Inc., for employing him while he worked on earlier draft versions of this document 🧚 that's a whole era of work, and it deserves the credit ✨

Authors' Addresses 🎀

Here's where you can reach the authors. Slide into their inboxes if you have questions 💌

Peter Saint-Andre
&yet

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


Salvatore Loreto
Ericsson
Hirsalantie 11
Jorvas  02420
Finland

EMail: Salvatore.Loreto@ericsson.com
📦 where this page comes from