Session Initiation Protocol (SIP) Extension for Instant Messaging
updated by
- rfc-8591 — SIP-Based Messaging with S/MIME
Extracted elements (28)
Implementations SHOULD NOT create dialogs for the primary purpose of associating MESSAGE requests with one another, because dialog-associated MESSAGE requests must follow the same network path as other SIP requests, causing likely congestion when IM volume is high and preventing separation between IM and signaling endpoints.
The 1300-byte message size limit is not based on path MTU to the next hop (as SIP does for transport decisions) because a MESSAGE client is unlikely to know the MTU for upstream devices beyond the next hop; a fixed conservative limit ensures no upstream proxy forwards large content over UDP.
The document addresses the pager model only (each IM stands alone), not the session model (explicit conversation with clear beginning and end). The session model for IM requires additional work and was deferred to the SIMPLE working group.
Using message/cpim bodies is expected to enable interoperability between endpoints using different IM protocols, since message/cpim is designed for support across multiple instant message protocols and allows end-to-end security even through gateways.
A UA presented with an IM URI SHOULD resolve it to a SIP URI and place it in the Request-URI before sending. If unable to resolve, it MAY place the IM URI directly, delegating resolution to a downstream device.
A UAC MUST NOT initiate a new out-of-dialog MESSAGE transaction to a given URI if there is a previous out-of-dialog transaction pending for the same URI. A UAC SHOULD NOT initiate overlapping MESSAGE transactions inside a dialog unless the route set uses congestion-controlled transport at every hop.
A UAS receiving a MESSAGE request SHOULD respond with a final response immediately. A 2xx response to a MESSAGE request MUST NOT contain a body, and a UAS MUST NOT insert a Contact header field into a 2xx response.
A UAS that supports the MESSAGE method MUST be prepared to receive and render bodies of type text/plain, and may support message/cpim.
All UACs which support the MESSAGE method MUST be prepared to send MESSAGE requests with a body of type text/plain. They may send bodies of type message/cpim.
If the MESSAGE request containing an Expires header field also contains a Date header field, the UAS SHOULD interpret the Expires value as delta time from the Date field; otherwise from the time the UAS received the request.
If the UAC adds an Expires header field with a non-zero value, it SHOULD also add a Date header field containing the time the message is sent.
If the UAC receives a 202 Accepted response, it MUST NOT assume the message has been delivered to the final destination, as it was only accepted by an intermediary such as a gateway or store-and-forward server.
Implementations of the MESSAGE method SHALL support all instant message requirements in RFC 2779 relevant to its scope of applicability.
MESSAGE requests SHOULD be sent over transports that implement end-to-end congestion control such as TCP or SCTP whenever possible.
Record-Route and Route header fields MUST NOT contain IM URIs; these header fields contain concrete SIP or SIPS URIs according to SIP rules.
The size of MESSAGE requests outside of a media session MUST NOT exceed 1300 bytes, unless the UAC has positive knowledge that the message will not traverse a congestion-unsafe link or that the message size is at least 200 bytes less than the lowest MTU value en route.
User Agents MUST NOT insert Contact header fields into MESSAGE requests. MESSAGE requests do not initiate dialogs.
A MESSAGE request MAY contain a body, using standard MIME header fields to identify the content. Header field tables define which SIP header fields are mandatory (m), optional (o), or not applicable (-) for MESSAGE requests and responses.
Response semantics: 200 OK means the UAS accepted the message (not that the user has read it); 202 Accepted means delivery to an intermediary; 4xx/5xx means unsuccessful delivery; 6xx means successfully delivered but refused.
The BNF for the MESSAGE method is: MESSAGEm = %x4D.45.53.53.41.47.45 (MESSAGE in caps). The method name is case sensitive.
The MESSAGE method is a new SIP method that carries instant message content in the request body as MIME parts. MESSAGE requests do not establish dialogs; each message stands alone like a pager message, though they may be sent within an existing dialog.
This specification registers the MESSAGE method in the IANA SIP Parameters Method registry at http://www.iana.org/assignments/sip-parameters/Method.
MESSAGE bodies MUST be secured with S/MIME when end-to-end protection is required. SIP MESSAGE endpoints MUST support encryption (CMS EnvelopeData) and S/MIME signatures (CMS SignedData).
The message/cpim format allows S/MIME protection of metadata across protocol boundaries, enabling sender authentication even when a message crosses a gateway to another CPIM-compliant IM service that does not understand SIP headers.
The SIPS URI mechanism provides hop-by-hop integrity and privacy but requires trusting all proxies to not fork to unauthorized destinations. A forking proxy can deliver a MESSAGE to additional endpoints without UAC knowledge.
To prevent replay attacks, all signed MESSAGE requests and responses MUST contain a Date header field covered by the message signature. Messages with dates more than several minutes old or in the future SHOULD be rejected with 400 (Incorrect Date or Time).
UAs that support MESSAGE MUST implement end-to-end authentication, body integrity, and body confidentiality mechanisms, because MESSAGE carries actual communication payload rather than session signaling.
When local proxies are used for outbound transmission, proxy authentication as specified in RFC 3261 is RECOMMENDED to verify originator identity and prevent spoofing and spamming.