RFC 5365

Multiple-Recipient MESSAGE Requests in the Session Initiation Protocol (SIP)

📅 published October 2008, from ietf

RFC 5365 🦋 Multiple-Recipient MESSAGE Requests in the Session Initiation Protocol (SIP)

Authors: M. Garcia-Martin and G. Camarillo, both from Ericsson 💅 Category: Standards Track 🎀 Date: October 2008 🌸 Obsoletes / Updates: the title block doesn't list anything this one obsoletes or updates ✨

Status of This Memo ✨

okay so this document is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 🫶 If you want the current standardization state and status of this protocol, check the "Internet Official Protocol Standards" (STD 1) 📚 And distribution of this memo is unlimited, so share away 🌈

Abstract 🦋

this doc is all about letting a SIP User Agent Client (UAC) send one SIP MESSAGE request to a whole group of destinations, using a SIP URI-list (Uniform Resource Identifier list) service ✨ The UAC sends a MESSAGE request that carries the payload plus the URI list to the MESSAGE URI-list service. That service then sends a MESSAGE request with the payload to every URI in the list. main character energy 👑

Table of Contents 📜

1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
3.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
4.  URI-List Document  . . . . . . . . . . . . . . . . . . . . . .  5
5.  Option-Tag . . . . . . . . . . . . . . . . . . . . . . . . . .  6
6.  Procedures at the User Agent Client  . . . . . . . . . . . . .  6
7.  Procedures at the MESSAGE URI-List Service . . . . . . . . . .  7
  7.1.  Determining the Intended Recipient . . . . . . . . . . . .  8
  7.2.  Creating an Outgoing MESSAGE Request . . . . . . . . . . .  8
  7.3.  Composing Bodies in the Outgoing MESSAGE Request . . . . . 10
8.  Procedures at the UAS  . . . . . . . . . . . . . . . . . . . . 11
9.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
10. Security Considerations  . . . . . . . . . . . . . . . . . . . 15
11. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 15
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
  13.1. Normative References . . . . . . . . . . . . . . . . . . . 16
  13.2. Informative References . . . . . . . . . . . . . . . . . . 17

1. Introduction 🧚

okay so [RFC3261] is SIP, and RFC 3248 [RFC3428] extends it so SIP can carry instant messages inside MESSAGE requests 💖 The thing is, SIP-based messaging as described in RFC 3428 [RFC3428] has no way to send the same request to several recipients, or to reply to everyone who got a SIP MESSAGE request. This memo is here to fix exactly that 🙈

Our first requirement looks like this:

REQ-1: It must be possible for a user to send an instant message request to an ad hoc group, where the identities of the recipients are carried in the message itself.

One way to get there is to set up a session of instant messages with an instant messaging conference server, and swap messages using MSRP (Message Session Relay Protocol) [RFC4975] ✨ That's reasonable in lots of cases, but sometimes the sender just wants to fire off a small pager-mode instant message to an ad hoc group without the hassle of setting up a session 💅 So this document focuses on pager-mode instant messages sent to a bunch of intended recipients.

To pull that off, we let SIP MESSAGE requests carry recipient-list bodies. These are URI lists in body parts whose Content-Disposition (RFC 2183) [RFC2183] is 'recipient-list', as specified in RFC 5363 [RFC5363] 🎀 A SIP MESSAGE URI-list service (a specialized application service) takes the request and sends a MESSAGE request with the received payload to each URI in the list. Every one of those MESSAGE requests holds a copy of the body from the original MESSAGE request 🫶

Now our second requirement, the "Reply-To-All" part:

REQ-2: It MUST be possible for the recipient of a group instant message to send a message to all other participants that received the same group instant message (i.e., Reply-To-All).

To meet this, the MESSAGE URI-list service also adds a URI list in body parts whose Content-Disposition (RFC 2183) [RFC2183] is 'recipient-list-history', as specified in RFC 5364 [RFC5364] 🔥 That 'recipient-list-history' body goes along with the instant message payload in every instant message sent to the recipients, so everyone can see who else got it. iconic 🌈

The User Agent Client (UAC) that sends a MESSAGE request to a MESSAGE URI-list service needs to be configured with the SIP URI of that service 🍓 How you discover that URI and provision it to the UAC is outside the scope of this document, so this doc won't cover it 🙈

2. Terminology 📖

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119], and they indicate requirement levels for compliant implementations 💜

This document reuses these terms from RFC 3261 [RFC3261]:

  • Address-of-Record (AOR)
  • User Agent (UA)
  • User Agent Client (UAC)
  • User Agent Server (UAS)

This document also defines some new terms, so pay attention bestie 👀

MESSAGE URI-list service: a specialized URI-list service that receives a MESSAGE request with a URI list and sends a similar MESSAGE request to each URI in the list. Here "similar" means some SIP header fields can change, but the service will not change the instant message payload 🦋 MESSAGE URI-list services act effectively as specialized B2BUAs (Back-to-Back-User-Agents). A server that provides them can also offer URI-list services for other methods, but that's outside the scope of this document, so we're only talking about MESSAGE URI-list services here ✨

Incoming MESSAGE request: a SIP MESSAGE request that a UAC creates and addresses to a MESSAGE URI-list service. On top of the regular instant message payload, it contains a URI list 🌸

Outgoing MESSAGE request: a SIP MESSAGE request that a MESSAGE URI-list service creates and addresses to a UAS (User Agent Server). It contains the regular instant message payload 💅

Intended recipient: the intended final recipient of the request that the MESSAGE URI-list service generates 🧚

Reply-To-All: the ability of an intended recipient to receive a MESSAGE request that includes the payload and the list of recipients, and then compose and send a MESSAGE request to the sender and the rest of the recipients 🫶 The replying entity can use a MESSAGE URI-list service if one is available, or it can create a sequence of regular single-recipient MESSAGE requests, one to each SIP AOR 🔥

3. Overview 🌈

okay here's the big picture ✨ A UAC creates a MESSAGE request with a multipart body that has a list of URIs (the intended recipients) and an instant message. That URI list follows the resource list document format from RFC 4826 [RFC4826], extended with the attributes defined in RFC 5364 [RFC5364] 🎀 The UAC sends this MESSAGE request to the MESSAGE URI-list service. When the service gets this incoming MESSAGE request, it creates one MESSAGE request per intended recipient (each one listed in the URI list) and copies the instant message payload into each of them 💖

The service also manipulates the XML resource list following the procedures in RFC 5364 [RFC5364], then attaches the result to each MESSAGE request along with the instant message payload. After that, it sends each outgoing MESSAGE request to its respective receiver 🦋

So the MESSAGE URI-list mechanism lets a sender target multiple recipients for one MESSAGE request. The sender puts an XML resource list document (per RFC 4826 [RFC4826], extended with the attributes from RFC 5364 [RFC5364]) in the body of the MESSAGE request. This resource list has a Content-Disposition (RFC 2183) [RFC2183] of 'recipient-list', as specified in RFC 5363 [RFC5363], and it holds the URIs of the targets 🍓 Each target URI can also be marked with the role the URI-list service will place it in (for example "to", "cc", or "bcc"), and with whether that target is expected to be anonymized, following the procedures in RFC 5364 [RFC5364] 💜

When the MESSAGE URI-list server expands the MESSAGE request to each recipient, it includes (along with the instant message payload) a new URI list based on the one it received. That new list has a Content-Disposition (RFC 2183) [RFC2183] of 'recipient-list-history', as specified in RFC 5364 [RFC5364] 🌸 It holds the non-anonymous "to" and "cc" targets, so recipients can see who else is in the group and reply to them 👑

4. URI-List Document 💅

as RFC 5363 [RFC5363] explains, individual URI-list services (like the MESSAGE URI-list service described here) need to specify a default format for 'recipient-list' bodies used within that service 🧚

The default format for 'recipient-list' bodies in MESSAGE URI-list services is the resource list document from RFC 4826 [RFC4826], extended with the copy control attributes from [RFC5364]. UACs and MESSAGE URI-list services that handle 'recipient-list' bodies MUST support both of these formats, and they MAY support other formats too 🫶

As RFC 5364 [RFC5364] describes, each URI can be tagged with a 'copyControl' attribute set to "to", "cc", or "bcc", which tells you the role the recipient will get the MESSAGE request in 🎀 URIs can also get the 'anonymize' attribute, which stops the MESSAGE URI-list server from disclosing that target URI in a URI list 🙈

RFC 5364 [RFC5364] also defines a 'recipient-list-history' body that contains the list of intended recipients. The default format for 'recipient-list-history' bodies in MESSAGE URI-list services is also the resource list document from RFC 4826 [RFC4826], extended with the copy control attributes from [RFC5364]. MESSAGE URI-list services MUST support both of these formats; UASs MAY support these formats. MESSAGE URI-list servers and UASs MAY support other formats 🔥

The RFC 4826 [RFC4826] resource list document has a bunch of features that the MESSAGE URI-list service doesn't need. The service only has to move a simple flat list of URIs between a UAC and the MESSAGE URI-list server, and between the MESSAGE URI-list server and the UAS 🌈 It doesn't need hierarchical lists, or the ability to include entries by reference relative to the Extensible Configuration Access Protocol (XCAP) [RFC4825] root URI ✨ So the MESSAGE URI-list service specified here only uses flat resource list documents that don't contain relative references 💖

5. Option-Tag ✨

okay so this section is short and sweet 🎀 It defines the recipient-list-message option-tag, which goes in the Require and Supported SIP header fields 💖

This option-tag makes sure a server can actually process the recipient-list body that shows up in a MESSAGE request 🫶 It also gives you a way to find out what the server can do, through the responses to OPTIONS requests 🔍

Section 6 has the normative procedures for using this option-tag, so go there for the actual rules 📜

6. Procedures at the User Agent Client 💅

bestie, this is the UAC side, so this is where the multiple-recipient MESSAGE gets made 🦋 A UAC that wants one creates a MESSAGE request that MUST be formatted according to RFC 3428 [RFC3428] Section 4 💌 The UAC puts the SIP or SIPS URI of the MESSAGE URI-list service in the Request-URI 🎯 On top of the usual instant message body, it adds a recipient-list body whose Content-Disposition type is recipient-list, which is specified in RFC 5363 [RFC5363] 📋 That body holds a URI list of everyone getting the MESSAGE 👑 Target URIs in that body MAY also be tagged with the copyControl and anonymize attributes from RFC 5364 [RFC5364] 🙈 And the UAC MUST also include the recipient-list-message option-tag, defined in Section 5, in a Require header field ✨

UACs making MESSAGE requests that carry recipient-list bodies (like we talked about earlier) MUST include this option-tag in a Require header field 🔥 UAs that can receive and process MESSAGEs with a recipient-list body (also from earlier) SHOULD include this option-tag in a Supported header field when they respond to OPTIONS requests 💜

Multiple-recipient MESSAGE requests have a multipart body, and that body holds both the list body and the actual instant message payload 🌈 Sometimes the MESSAGE can have bodies besides the text and the list ones, like when the request is protected with S/MIME per RFC 3851 [RFC3851] 🧚

Usually the MESSAGE URI-list service copies all the significant header fields into the outgoing MESSAGE request 🍓 BUT, there can be times when the SIP UA wants the service to add a particular header field with a particular value, even though that header field wasn't in the MESSAGE the UAC sent 👀 In that case the UAC MAY use the "?" mechanism from Section 19.1.1 of RFC 3261 [RFC3261] to tuck extra info into any URI in the list 🎀 However, the UAC MUST NOT use the special "body" hname (see Section 19.1.1 of RFC 3261 [RFC3261]) to encode a body, because the body is already in the MESSAGE request itself 🙅‍♀️

here's an example of a URI that uses the "?" mechanism:

sip:bob@example.com?Accept-Contact=*%3bmobility%3d%22mobile%22

That URI asks the MESSAGE URI-list service to add this header field to the MESSAGE going to bob@example.com:

Accept-Contact: *;mobility="mobile"

The resource list document format in RFC 4826 [RFC4826] has extra features, like hierarchical lists and entries pulled in by reference relative to the XCAP root URI 🌸 But the multiple MESSAGE URI-list service in this document doesn't need any of that 🙃 So when you're using the default resource list document, UAs SHOULD use flat lists (no hierarchical lists) and SHOULD NOT use <entry-ref> elements 💅

7. Procedures at the MESSAGE URI-List Service 🎀

when the MESSAGE URI-list service gets a MESSAGE request with a URI list, it answers the UAC with a 202 (Accepted) response 📨

ngl this part is important 😭 The status code in that response does NOT tell you whether the MESSAGEs the URI-list service generated were actually delivered to the URIs on the list 💀 A 202 (Accepted) just means the service got the MESSAGE and will TRY to send similar MESSAGEs to the URIs on the list 🫠 Designing a way to tell a client about the delivery status of an instant message is outside the scope of this document, so don't look for it here 🙈

Since the MESSAGE URI-list service doesn't use hierarchical lists or lists with entries that refer to the XCAP root URI, a MESSAGE URI-list server that gets a URI list with more info than we just described MAY discard all the extra information 🗑️

If a MESSAGE request has a Request-URI with a URI that uses the "?" mechanism (see Section 19.1.1 of RFC 3261 [RFC3261]), and that URI has the special "body" hname to include an extra body, the MESSAGE URI-list server MAY discard the contents of the "body" parameter 🧹

7.1. Determining the Intended Recipient

okay, so on receiving a MESSAGE request with a URI list, the MESSAGE URI-list service figures out who the intended recipients are by looking at the URI list in the body 👀

Section 4.1 of RFC 5363 [RFC5363] covers the cases where duplicated URIs show up in a URI list 🔁 To avoid sending duplicate requests, MESSAGE URI-list services MUST take those actions from RFC 5363 [RFC5363] into account so the same recipient doesn't get the same message twice 🚫

7.2. Creating an Outgoing MESSAGE Request

the MESSAGE URI-list service acts as a UAC for outgoing MESSAGE requests, so for each intended recipient it makes a brand new MESSAGE request following the procedures in Section 4 of RFC 3428 [RFC3428] ✨ Section 5.3 of RFC 5363 [RFC5363] has extra general guidance for creating outgoing requests too 💖 This document also specifies these procedures:

  • A MESSAGE URI-list service MUST include a From header field whose value is the same as the From header field in the incoming MESSAGE request, subject to the privacy requirements (see RFC 3323 [RFC3323] and RFC 3325 [RFC3325]) expressed in the incoming MESSAGE request 🕵️‍♀️
    • Note that this does not apply to the "tag" parameter.
    • > Failing to copy the From header field of the sender leads to unacceptable security and privacy failures 😱 This requirement also doesn't mean to contradict requirements for other services running on the same physical node 🫶 For example, a privacy service (see RFC 3323 [RFC3323]) can live on the same box as the MESSAGE URI-list service, and in that case the privacy service wins over the MESSAGE URI-list service 👑
  • A MESSAGE URI-list service SHOULD generate a new To header field value set to the intended recipient's URI 🎯 Per the procedures in RFC 3261 [RFC3261] Section 8.1.1.1, that value is also expected to be equal to the Request-URI of the outgoing MESSAGE request 🌈
    • The MESSAGE URI-list service behaves as a User Agent Client, so the To header field should be populated with the recipient's URI 🧚
  • A MESSAGE URI-list service SHOULD create a new Call-ID header field value 🆕
    • A Call-ID header field might hold addressing info the sender wants to keep private 🤫 There's no need to keep the same Call-ID on both sides of the MESSAGE URI-list service, and since the service acts as a User Agent Client, it is recommended to create a new Call-ID header field value according to the regular SIP procedures 🦋
  • If a P-Asserted-Identity header field was in the incoming MESSAGE request, the request came from a trusted source (as specified in RFC 3325 [RFC3325]), and the first hop of the outgoing MESSAGE request is also trusted, then a MESSAGE URI-list service MUST include a P-Asserted-Identity header field in the outgoing MESSAGE request with the same received value 🪪 However, if the first hop of the outgoing MESSAGE request is NOT trusted and the incoming MESSAGE request included a Privacy header field with a value different than 'none', the MESSAGE URI-list service MUST NOT include a P-Asserted-Identity header field in the outgoing MESSAGE request 🙅‍♀️
  • If a MESSAGE URI-list service can assert the identity of a user (e.g., using HTTP Digest authentication scheme as per RFC 2617 [RFC2617], S/MIME as per RFC 3851 [RFC3851], etc.), and the service has a mechanism to map that authentication scheme to a user's SIP or SIPS URI, and it's subject to the privacy requirements expressed in the incoming MESSAGE request (see RFC 3323 [RFC3323]), then the MESSAGE URI-list service MAY insert a P-Asserted-Identity header with the value of the user's asserted URI 🪄
  • If the incoming MESSAGE request contains an Authorization or Proxy-Authorization header field whose realm is set to the MESSAGE URI-list server's realm, then the MESSAGE URI-list service SHOULD NOT copy it to the outgoing MESSAGE request 🔐 Otherwise (i.e., if the Authorization or Proxy-Authorization header field of the incoming MESSAGE request contains a different realm), the MESSAGE URI-list service MUST copy the value to the respective header field of the outgoing MESSAGE request 🔑
  • A MESSAGE URI-list service SHOULD create a separate count for the CSeq header field [RFC3261] of the outgoing MESSAGE request 🔢
  • A MESSAGE URI-list service SHOULD initialize the value of the Max-Forward header field of the outgoing MESSAGE request 🚀
  • A MESSAGE URI-list service MUST include its own value in the Via header field 🛤️

7.3. Composing Bodies in the Outgoing MESSAGE Request 💌

okay so every time the MESSAGE URI-list service builds an outgoing MESSAGE, it keeps the relevant bodies from the incoming one and copies them over 📦. These bullets are the exceptions to that normal body handling, so pay attention ✨

  • A MESSAGE request arriving at a MESSAGE URI-list service can have one or more security bodies (like S/MIME, RFC 3851 [RFC3851]) encrypted with the public key of the MESSAGE URI-list service. Those bodies are treated as read by the service itself, not by the recipient of the outgoing request, who can't decrypt them anyway 💀 So a MESSAGE URI-list service MUST NOT copy any security body (like an S/MIME per RFC 3851 [RFC3851] encrypted body) addressed to the MESSAGE URI-list service into the outgoing MESSAGE request. That includes bodies encrypted with the public key of the URI-list service.
  • The incoming MESSAGE request usually has a recipient-list body or reference, as indicated in RFC 5363 [RFC5363], with the actual list of recipients 📝 If that URI list includes resources tagged with the 'copyControl' attribute set to a value of "to" or "cc", the URI-list service SHOULD include a URI list in each of the outgoing MESSAGE requests. This list SHOULD be formatted according to the resource list document format specified in RFC 4826 [RFC4826] and the copyControl extension specified in RFC 5364 [RFC5364]. The MESSAGE URI-list service MUST follow the procedures specified in RFC 5364 [RFC5364] with respect to handling of the 'anonymize', 'count', and 'copyControl' attributes 🫶
  • If the MESSAGE URI-list service includes a URI list in an outgoing MESSAGE request, it MUST include a Content-Disposition header field as per RFC 2183 [RFC2183] with the value set to 'recipient-list-history' and a "handling" parameter as per RFC 3204 [RFC3204] set to "optional" 🏷️
  • If a MESSAGE URI-list service includes a URI list in an outgoing MESSAGE request, it SHOULD use S/MIME (RFC 3851) [RFC3851] to encrypt the URI list with the public key of the receiver 🔐
  • The MESSAGE URI-list service SHOULD copy all the remaining message bodies (e.g., text messages, images, etc.) of the incoming MESSAGE request to the outgoing MESSAGE request 🖼️
  • If there is only one body left, the MESSAGE URI-list service MUST remove the multipart/mixed wrapper in the outgoing MESSAGE request 🎁

The rest of the MESSAGE request for a given URI in the URI list MUST be created following the rules in Section 19.1.5, "Forming Requests from a URI", of RFC 3261 [RFC3261]. Section 19.1.5 of RFC 3261 [RFC3261] says this:

"An implementation SHOULD treat the presence of any headers or body parts in the URI as a desire to include them in the message, and choose to honor the request on a per-component basis."

SIP allows a "method" parameter to be appended to a URI, so it's totally legit for the 'uri' attribute of the <entry> element in the XML resource list to contain a "method" parameter 🦋 Still, MESSAGE URI-list services MUST generate only MESSAGE requests, regardless of the "method" parameter that the URIs in the list indicate. Effectively, that means MESSAGE URI-list services MUST ignore the "method" parameter in each of the URIs present in the URI list 🙅‍♀️

8. Procedures at the UAS 🧚

A UAS (in this specification, also known as intended recipient UAS) that receives a MESSAGE request from the MESSAGE URI-list service behaves as specified in RFC 3428 [RFC3428] Section 7 ✨

If the UAS supports this specification and the MESSAGE request contains a body with a Content-Disposition header field as per RFC 2183 [RFC2183] set to 'recipient-list-history', then the UAS will be able to determine the SIP Address-of-Record (AOR) of the other intended recipients of the MESSAGE request. This is lowkey iconic because it lets the user create a reply request (e.g., MESSAGE, INVITE) to the sender and the rest of the recipients included in the URI list 💬

9. Examples 🎀

Figure 1 shows an example of operation. A SIP UAC issuer sends a MESSAGE request, and the MESSAGE URI-list service answers with a 202 (Accepted) response and then sends a MESSAGE request to each of the intended recipients 📨

+--------+        +---------+      +--------+ +--------+ +--------+
|SIP UAC |        | MESSAGE |      |intended| |intended| |intended|
| issuer |        | URI-list|      | recip. | | recip. | | recip. |
|        |        | service |      |   1    | |   2    | |   n    |
+--------+        +---------+      +--------+ +--------+ +--------+
    |                  |               |          |          |
    | F1 MESSAGE       |               |          |          |
    | ---------------->|               |          |          |
    | F2 202 Accepted  |               |          |          |
    |<---------------- |  F3 MESSAGE   |          |          |
    |                  | ------------->|          |          |
    |                  |  F4 MESSAGE   |          |          |
    |                  | ------------------------>|          |
    |                  |  F5 MESSAGE   |          |          |
    |                  | ----------------------------------->|
    |                  |  F6 200 OK    |          |          |
    |                  |<------------- |          |          |
    |                  |  F7 200 OK    |          |          |
    |                  |<------------------------ |          |
    |                  |  F8 200 OK    |          |          |
    |                  |<----------------------------------- |
    |                  |               |          |          |
    |                  |               |          |          |
    |                  |               |          |          |

Figure 1: Example of operation

The MESSAGE request F1 (shown in Figure 2) is so cute 🥹 It contains a multipart/mixed body made of two bodies: a text/plain body with the instant message payload, and an application/resource-lists+xml body with the list of recipients 💜

MESSAGE sip:list-service.example.com SIP/2.0
Via: SIP/2.0/TCP uac.example.com
    ;branch=z9hG4bKhjhs8ass83
Max-Forwards: 70
To: MESSAGE URI-list service <sip:list-service.example.com>
From: Alice <sip:alice@example.com>;tag=32331
Call-ID: d432fa84b4c76e66710
CSeq: 1 MESSAGE
Require: recipient-list-message
Content-Type: multipart/mixed;boundary="boundary1"
Content-Length: 501

--boundary1
Content-Type: text/plain

Hello World!

--boundary1
Content-Type: application/resource-lists+xml
Content-Disposition: recipient-list

<?xml version="1.0" encoding="UTF-8"?>
<resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists"
          xmlns:cp="urn:ietf:params:xml:ns:copycontrol">
  <list>
    <entry uri="sip:bill@example.com" cp:copyControl="to" />
    <entry uri="sip:randy@example.net" cp:copyControl="to"
                                       cp:anonymize="true"/>
    <entry uri="sip:eddy@example.com" cp:copyControl="to"
                                      cp:anonymize="true"/>
    <entry uri="sip:joe@example.org" cp:copyControl="cc" />
    <entry uri="sip:carol@example.net" cp:copyControl="cc"
                                       cp:anonymize="true"/>
    <entry uri="sip:ted@example.net" cp:copyControl="bcc" />
    <entry uri="sip:andy@example.com" cp:copyControl="bcc" />
  </list>
</resource-lists>
--boundary1--

Figure 2: MESSAGE request received at the MESSAGE URI-list server

The MESSAGE requests F3, F4, and F5 are similar in nature 👯 All of them contain a multipart/mixed body made of two other bodies: a text/plain body with the instant message payload, and an application/resource-lists+xml body with the list of recipients. Unlike the text/plain body, the application/resource-lists+xml bodies of F3, F4, and F5 are not equal to the application/resource-lists+xml body in the incoming MESSAGE request F1. That's because the URI-list service has anonymized the URIs tagged with the 'anonymize' attribute and has removed the URIs tagged with a "bcc" 'copyControl' attribute. Besides, the content disposition of these bodies is different 🙈 Figure 3 shows an example of the MESSAGE request F3.

MESSAGE sip:bill@example.com SIP/2.0
Via: SIP/2.0/TCP list-service.example.com
    ;branch=z9hG4bKhjhs8as34sc
Max-Forwards: 70
To: <sip:bill@example.com>
From: Alice <sip:alice@example.com>;tag=210342
Call-ID: 39s02sdsl20d9sj2l
CSeq: 1 MESSAGE
Content-Type: multipart/mixed;boundary="boundary1"
Content-Length: 501

--boundary1
Content-Type: text/plain

Hello World!

--boundary1
Content-Type: application/resource-lists+xml
Content-Disposition: recipient-list-history; handling=optional

<?xml version="1.0" encoding="UTF-8"?>
<resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists"
          xmlns:cp="urn:ietf:params:xml:ns:copycontrol">
  <list>
    <entry uri="sip:bill@example.com" cp:copyControl="to" />
    <entry uri="sip:anonymous@anonymous.invalid" cp:copyControl="to"
                                                 cp:count="2"/>
    <entry uri="sip:joe@example.org" cp:copyControl="cc" />
    <entry uri="sip:anonymous@anonymous.invalid" cp:copyControl="cc"
                                                 cp:count="1"/>
  </list>
</resource-lists>
--boundary1--

Figure 3: MESSAGE request sent by the MESSAGE URI-list server

10. Security Considerations 🔐

Buckle up, this part is serious 🚨

RFC 5363 [RFC5363] discusses issues related to SIP URI-list services. Implementations of MESSAGE URI-list services MUST follow the security-related rules in RFC 5363 [RFC5363]. These rules include opt-in lists and mandatory authentication and authorization of clients 🛡️

If the contents of the instant message need to be kept private, the User Agent Client SHOULD use S/MIME as per RFC 3851 [RFC3851] to prevent a third party from viewing this information. In this case, the user agent client SHOULD encrypt the instant message body with a content encryption key. Then, for each receiver in the list, the UAC SHOULD encrypt the content encryption key with the public key of the receiver, and attach it to the MESSAGE request. Privacy bestie energy, no cap 💅

11. IANA Considerations 📋

This document defines the SIP option tag 'recipient-list-message'

The following row has been added to the "Option Tags" section of the SIP Parameter Registry ✨

+------------------------+------------------------------+-----------+
| Name                   | Description                  | Reference |
+------------------------+------------------------------+-----------+
| recipient-list-message | The body contains a list of  | [RFC5365] |
|                        | URIs that indicates the      |           |
|                        | recipients of the SIP        |           |
|                        | MESSAGE request              |           |
+------------------------+------------------------------+-----------+

Table 1: Registration of the 'recipient-list-message' Option-Tag in SIP

12. Acknowledgements 💖

Duncan Mills supported the idea of having 1 to n MESSAGEs. Ben Campbell, Paul Kyzivat, Cullen Jennings, Jonathan Rosenberg, Dean Willis, and Keith Drage provided helpful comments 🫶

13. References 📚

13.1. Normative References

Okay bestie, these are the docs the spec literally can't function without 📚✨ Here's the whole squad:

  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 🔑
  • [RFC2183] Troost, R., Dorner, S., and K. Moore, "Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field", RFC 2183, August 1997. 🎀
  • [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999. 🔐
  • [RFC3204] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet, F., Watson, M., and M. Zonoun, "MIME media types for ISUP and QSIG Objects", RFC 3204, December 2001. 🦋
  • [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. 📞 The main SIP spec, obviously iconic.
  • [RFC3323] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002. 🙈
  • [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, November 2002. 🪪
  • [RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, December 2002. 💬 This is the instant messaging one, so it's literally the reason we're all here.
  • [RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004. 💌
  • [RFC4826] Rosenberg, J., "Extensible Markup Language (XML) Formats for Representing Resource Lists", RFC 4826, May 2007. 🧾
  • [RFC5363] Camarillo, G. and A.B. Roach, "Framework and Security Considerations for Session Initiation Protocol (SIP) URI-List Services", RFC 5363, October 2008. 🛡️
  • [RFC5364] Garcia-Martin, M. and G. Camarillo, "Extensible Markup Language (XML) Format Extension for Representing Copy Control Attributes in Resource Lists", RFC 5364, October 2008. 🌸

13.2. Informative References

These ones are more like the bonus reading, not required, but so good 🧚

  • [RFC4825] Rosenberg, J., "The Extensible Markup Language (XML) Configuration Access Protocol (XCAP)", RFC 4825, May 2007. 🍓
  • [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message Session Relay Protocol (MSRP)", RFC 4975, September 2007. 🌈

Authors' Addresses

Meet the brains behind it all, the Ericsson girlies 👑

Miguel A. Garcia-Martin
Ericsson
Via de los Poblados 13
Madrid  28033
Spain

EMail: miguel.a.garcia@ericsson.com


Gonzalo Camarillo
Ericsson
Hirsalantie 11
Jorvas  02420
Finland

EMail: Gonzalo.Camarillo@ericsson.com

Okay, the legal bit, but make it cute 💅

Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis, and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 🫶

Intellectual Property

Now the IP part, which is basically the IETF being like "we're not picking sides on patents" 🧐

The IETF takes no position on the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document, or on whether any license under such rights might or might not be available. It also doesn't say it has independently tried to find any such rights. If you want the procedures for rights in RFC documents, check BCP 78 and BCP 79. 📜

Copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, and the results of any attempt to get a general license or permission to use such proprietary rights by implementers or users of this specification can all be found in the IETF online IPR repository at http://www.ietf.org/ipr. 🗂️

Last bit: if you know about any copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard, the IETF wants you to tell them at ietf-ipr@ietf.org. Speak up, babe 📣🦋

📦 where this page comes from