Multiple-Recipient MESSAGE Requests in the Session Initiation Protocol (SIP)
Extracted elements (29)
A new Call-ID is recommended for outgoing MESSAGE requests because the incoming Call-ID may contain addressing information the sender wants private, and since the MESSAGE URI-list service acts as a UAC there is no need to preserve the original Call-ID across the service boundary.
The MESSAGE URI-list service is designed for pager-mode instant messages to ad hoc groups, explicitly avoiding the overhead of establishing a session (e.g., via MSRP), which is considered unnecessary when a user simply wants to send a small one-time message to multiple recipients.
The MESSAGE URI-list service only uses flat resource list documents without hierarchical lists or XCAP-relative entry references, because the service only needs to transfer a simple flat list of URIs and these more complex features are unnecessary.
The UAC SHOULD use flat lists (no hierarchical lists) and SHOULD NOT use <entry-ref> elements when using the default resource list document format, as the MESSAGE URI-list service defined here does not require or use those features.
A MESSAGE URI-list service MUST include a From header field in the outgoing MESSAGE request whose value is the same as the From header field in the incoming MESSAGE request, subject to privacy requirements. Failure to do so results in unacceptable security and privacy failures.
A MESSAGE URI-list service MUST NOT copy any security body (e.g., S/MIME encrypted body) addressed to the MESSAGE URI-list service to the outgoing MESSAGE request, as such bodies are intended to be read by the URI-list service itself.
A UAC creating a multiple-recipient MESSAGE request MUST format it according to RFC 3428 Section 4, MUST include a 'recipient-list' body with Content-Disposition 'recipient-list', and MUST include the 'recipient-list-message' option-tag in a Require header field.
If a P-Asserted-Identity header was present in the incoming MESSAGE and the request was from a trusted source and the first hop of the outgoing request is also trusted, the MESSAGE URI-list service MUST include P-Asserted-Identity with the same value in the outgoing request.
If the first hop of the outgoing MESSAGE request is not trusted and the incoming request included a Privacy header field with a value other than 'none', the MESSAGE URI-list service MUST NOT include a P-Asserted-Identity header field in the outgoing request.
If the incoming MESSAGE contains an Authorization or Proxy-Authorization header whose realm matches the MESSAGE URI-list server's realm, the service SHOULD NOT copy it to the outgoing request; if the realm differs, the service MUST copy the value.
If the MESSAGE URI-list service includes a URI list in an outgoing MESSAGE request, it MUST include a Content-Disposition header field set to 'recipient-list-history' with a 'handling' parameter set to 'optional'.
If the URI list includes resources tagged with 'copyControl' set to 'to' or 'cc', the URI-list service SHOULD include a URI list in each outgoing MESSAGE request formatted as per RFC 4826 and RFC 5364, following procedures for 'anonymize', 'count', and 'copyControl' attributes.
If there is only one body left after composing the outgoing MESSAGE request, the MESSAGE URI-list service MUST remove the multipart/mixed wrapper.
MESSAGE URI-list services MUST generate only MESSAGE requests regardless of any 'method' parameter present in the URIs in the list; the 'method' parameter MUST be ignored.
MESSAGE URI-list services MUST support both the resource list document format (RFC 4826) and the copy control extension (RFC 5364) for 'recipient-list-history' bodies; UASs MAY support these formats.
MESSAGE URI-list services MUST take actions specified in RFC 5363 to avoid sending duplicated requests to the same recipient when duplicate URIs appear in the URI list.
The UAC MUST NOT use the special 'body' hname in the '?' URI mechanism to encode a body, since the body is already present in the MESSAGE request itself.
UACs and MESSAGE URI-list services handling 'recipient-list' bodies MUST support the resource list document format (RFC 4826) extended with copy control attributes (RFC 5364), and MAY support other formats.
UAs able to receive and process MESSAGEs with a recipient-list body SHOULD include the 'recipient-list-message' option-tag in a Supported header field when responding to OPTIONS requests.
An incoming MESSAGE request is a SIP MESSAGE created by a UAC addressed to a MESSAGE URI-list service, containing both the regular instant message payload and a URI list body with Content-Disposition 'recipient-list'.
An outgoing MESSAGE request is created by the MESSAGE URI-list service for each intended recipient, containing the instant message payload and optionally a 'recipient-list-history' body to support Reply-To-All functionality.
The MESSAGE URI-list service answers the UAC with a 202 (Accepted) response upon receiving a MESSAGE with a URI list. This response does not indicate delivery success to the individual recipients; it only confirms the service received and will attempt delivery.
The MESSAGE URI-list service receives a SIP MESSAGE request containing a URI list and instant message payload, then sends a separate MESSAGE request to each URI in the list. It behaves as a specialized B2BUA (Back-to-Back User Agent).
The 'recipient-list-message' option-tag is defined for use in Require and Supported SIP header fields to ensure a server can process the 'recipient-list' body in a MESSAGE request and to advertise this capability in OPTIONS responses.
This document registers the SIP option tag 'recipient-list-message' in the IANA SIP Parameter Registry 'Option Tags' section, indicating that the body contains a list of URIs identifying recipients of a SIP MESSAGE request.
If the instant message content must remain private, the UAC SHOULD use S/MIME (RFC 3851) to encrypt the message body with a content encryption key, and SHOULD encrypt that key with each receiver's public key and attach it to the MESSAGE request.
Implementations of MESSAGE URI-list services MUST follow the security-related rules in RFC 5363, including opt-in lists and mandatory authentication and authorization of clients, to prevent abuse of the service.
Each outgoing MESSAGE request body is multipart/mixed containing: (1) the instant message payload copied from the incoming request and (2) an application/resource-lists+xml body with Content-Disposition 'recipient-list-history; handling=optional' containing non-anonymous 'to' and 'cc' recipients.
The incoming MESSAGE request body is multipart/mixed containing: (1) the instant message payload (e.g., text/plain) and (2) an application/resource-lists+xml body with Content-Disposition 'recipient-list' encoding the URI list with optional 'copyControl' and 'anonymize' attributes.