ietf-corpus

rfc-4975

The Message Session Relay Protocol (MSRP)

B. Campbell (Editor), R. Mahy (Editor), C. Jennings (Editor)
date2007-09 streamIETF arearai wgsimple statusPROPOSED STANDARD pages63 canonicalhttps://www.rfc-editor.org/rfc/rfc4975 doi10.17487/RFC4975 errataview
This document describes the Message Session Relay Protocol, a protocol for transmitting a series of related instant messages in the context of a session. Message sessions are treated like any other media stream when set up via a rendezvous or session creation protocol such as the Session Initiation Protocol. [STANDARDS-TRACK]

updated by

Extracted elements (32)

design-rationale §8.5

The earlier COMEDIA-based connection-direction negotiation mechanism was removed from MSRP because it added significant complexity to connection management; the specification now mandates that the offer sender is always the active (connecting) endpoint.

realtime

design-rationale §7.3.1

The end-line uses seven '-' characters so that receivers can search for the four-character sequence '----' 32 bits at a time, enabling end-line detection at the same throughput as a plain memory copy, while still permitting mid-stream message interruption.

realtime

design-rationale §5.3

The 'partial' Failure-Report value lets a sender opt out of the hop-by-hop timer-based acknowledgment needed for 'yes' reporting, while still allowing non-timeout errors (policy violations, ICMP errors) to be reported — a compromise between no reporting and full reporting.

realtime

interoperability-note §8.3

Endpoints implementing only the core MSRP specification (no relay support) MUST still be prepared to receive more than one URI in the SDP path attribute; only the leftmost URI is used for connection establishment.

realtime

normative-requirement §7.3.1 MUST

All MSRP endpoints MUST be able to receive the multipart/mixed and multipart/alternative media types. If a SEND request contains an unsupported Content-Type and Failure-Report is not 'no', the receiver MUST respond with status code 415.

realtime

normative-requirement §8.6 MUST NOT

An MSRP endpoint MUST NOT send content of a type not signaled by the peer in the accept-types or accept-wrapped-types SDP attributes, and MUST NOT send a top-level MIME document of a type absent from accept-types.

realtime

normative-requirement §8.1 MUST

An SDP media-line for MSRP over TCP MUST use the protocol field value 'TCP/MSRP' (or 'TCP/TLS/MSRP' for TLS), the media field MUST be 'message', and the format list MUST be '*'.

realtime, sip

normative-requirement §5.1 MUST

Any SEND chunk with a body larger than 2048 octets MUST be interruptible, indicated by a '*' in the range-end field of the Byte-Range header. Senders MUST NOT send chunks larger than 2048 octets unless prepared to interrupt them.

realtime, tcp

normative-requirement §5.4 MUST

Connections using the 'msrps' scheme MUST use TLS. The SubjectAltName in the received certificate MUST match the hostname part of the URI and the certificate MUST be valid per RFC 3280.

tls, security

normative-requirement §8.2 MUST

Each SDP offer or answer proposing MSRP MUST contain a 'path' attribute with one or more MSRP URIs that include explicit port numbers. The rightmost URI MUST identify the generating endpoint and MUST NOT duplicate any URI for another active session.

realtime, sip

normative-requirement §5.4 MUST

If a node receives a first SEND request whose To-Path URI matches no existing session, it MUST reject the request with a 481 response; if the session is already in use on another connection, it MUST reject with a 506 response.

realtime, security

normative-requirement §7.1.1 MUST

If Failure-Report is 'yes' and a 200 response is not received within 30 seconds of sending the last byte of the transaction, the element MUST inform the user that the request probably failed.

realtime

normative-requirement §7.1.1 MUST

If no Success-Report header field is present in a SEND request it MUST be treated as 'no'; if no Failure-Report header field is present it MUST be treated as 'yes'.

realtime

normative-requirement §3 MUST

MSRP MUST be used only in the context of a rendezvous mechanism that provides both MSRP URIs to participating endpoints and protects their confidentiality; the URIs MUST NOT be made available to untrusted third parties or be easily discoverable.

realtime, security

normative-requirement §7.1 MUST NOT

Non-SEND request bodies MUST NOT exceed 10240 octets, and the Content-Type header field MUST be the last field in the message header section when a body is present.

realtime

normative-requirement §7.1.2 MUST NOT

REPORT requests MUST NOT include Success-Report or Failure-Report header fields, MUST contain a Status header field, and MSRP nodes MUST NOT send REPORT requests in response to other REPORT requests.

realtime

normative-requirement §7.1 MUST

The transaction identifier in every MSRP request MUST NOT collide with other concurrent transactions and MUST contain at least 64 bits of randomness.

security

normative-requirement §5.4 MUST

When a new MSRP session is created, the initiating (active) endpoint MUST open the transport connection to the answerer and MUST immediately issue a SEND request, which MAY have no body.

realtime

protocol-element §4

MSRP defines two methods: SEND, for delivering a complete message or a chunk of a larger message; and REPORT, for conveying delivery status (success or failure) of a previously sent message or byte range.

realtime

protocol-element §6

MSRP URIs use the 'msrp' scheme (plaintext TCP) or 'msrps' scheme (TLS-protected TCP). URIs are ephemeral, session-scoped, and encoded entirely in US-ASCII. The transport parameter MUST be 'tcp' for TCP connections.

realtime, tls

protocol-element §5.3

Success-Report ('yes'/'no') and Failure-Report ('yes'/'no'/'partial') header fields in SEND requests independently control whether success and failure REPORT requests are generated; 'partial' failure reporting omits the hop-by-hop timer mechanism.

realtime

protocol-element §7.1.1

The Message-ID header field provides a unique identifier for an entire message (not an individual chunk). All chunks of the same message carry the same Message-ID, allowing reassembly and correlation with REPORT requests.

realtime

registry §15.7

Four new SDP attribute names are registered: 'accept-types', 'accept-wrapped-types', 'max-size', and 'path', each used in the MSRP SDP media description.

registry, realtime, sip

registry §15.5

This document registers the 'msrp' and 'msrps' URI schemes and the recommended IANA port for MSRP (Section 15.4), and registers 'TCP/MSRP' and 'TCP/TLS/MSRP' as SDP transport protocol identifiers.

registry, realtime

registry §15.1

This document registers the MSRP method names (SEND, REPORT), a set of MSRP header field names (To-Path, From-Path, Message-ID, Success-Report, Failure-Report, Byte-Range, Status), and MSRP status codes in new IANA registries.

registry, realtime

security-consideration §5.4

Allowing multiple connections per session would permit an eavesdropper who learns the URI to inject messages on a separate connection; therefore MSRP MUST reject with 506 any attempt to bind a session already in use on another connection.

security, realtime

security-consideration §14.1

MSRP URIs serve as bearer tokens; an endpoint can reject requests to URIs it does not expect and correlate a URI with the probable sender. URIs MUST be hard to guess and MUST be protected from eavesdroppers to prevent session hijacking.

security, realtime

security-consideration §14.2

TLS is the recommended transport-level protection mechanism for MSRP. 'msrps' URIs ensure the next hop is TLS-protected but make no assertion about other hops; each hop's URI must be independently verified for the desired security properties.

tls, security, realtime

state-machine §5.4

Connection model: the session initiator is the 'active' endpoint and MUST connect to the answerer's URI; upon connection the active endpoint sends an immediate SEND (possibly bodiless). The passive endpoint waits for the first incoming SEND, matches its To-Path URI to a session, and associates the connection with that session.

realtime, tcp

wire-format §9

An MSRP request starts with 'MSRP SP transact-id SP method CRLF', followed by To-Path and From-Path header fields (each carrying one or more MSRP URIs), optional method-specific headers, an optional body after an extra CRLF, and ends with an end-line.

realtime

wire-format §7.1.1

The Byte-Range header field encodes 'range-start "-" range-end "/" total', where the first octet has position 1; range-end MAY be '*' when unknown or the chunk is interruptible, and total MAY be '*' when the message length is not known in advance.

realtime

wire-format §7.1

The end-line consists of exactly seven '-' characters, the transaction identifier, and a continuation flag: '$' for final chunk of a message, '#' for abort, '+' for more chunks to follow. A CRLF preceding the end-line is not part of the body.

realtime