In late 2002, the IETF faced an awkward problem: instant messaging had exploded — AIM, ICQ, MSN, Yahoo! Messenger — but every system was a walled garden running its own proprietary protocol. SIP was already winning the war for VoIP signaling, so a working group asked the obvious question: could SIP carry messages too? RFC 3428 is the answer, and it defines the MESSAGE method that still underpins SMS-over-IP, RCS, and most carrier-grade messaging today.

The core design decision: pager mode. The authors deliberately chose not to build a session-oriented chat protocol. A SIP MESSAGE request is a one-shot transaction — like a two-way pager. The message body (typically text/plain or message/cpim) rides inside the request itself, and the recipient's UA returns a 200 OK to acknowledge receipt. No INVITE, no dialog, no media negotiation. This kept the spec to fewer than 20 pages and let existing SIP proxies route IMs with zero changes.

Why pager mode and not sessions? Session-mode messaging (long-running chats with typing indicators, etc.) was deferred to MSRP (RFC 4975). The authors recognized that mobile and presence-driven IM patterns were inherently transactional — you send a line, it gets delivered, you're done. Forcing a SIP dialog for every "lol" would have been disastrous for battery life and proxy state.

The subtle bits worth knowing:

• No retransmission of message content at the application layer. SIP's transaction layer handles reliability via INVITE-style retransmits over UDP, or TCP's own guarantees. The spec explicitly forbids using MESSAGE for high-volume chatter precisely because of this — congestion control is weaker than a real session would provide.
• Size limit of 1300 bytes when sent over a non-congestion-controlled transport (i.e., UDP). This is the MTU-conscious ghost of 2002 networking, and it's why MMS-style attachments quickly punted to other mechanisms.
• The MESSAGE request can be sent inside or outside a dialog. Outside-dialog is the common case — you address by AOR (sip:[email protected]) and the registrar/proxy fabric routes it like an INVITE.
• No store-and-forward semantics. If the recipient is offline, the proxy returns an error. Voicemail-style "IM storage" was left to implementations, which is why every carrier built incompatible offline-message servers.

Why it matters in 2026. If you've used RCS (Rich Communication Services) on Android, every text message you sent rode RFC 3428. The GSMA's RCS Universal Profile uses SIP MESSAGE for short messages and MSRP for chat sessions, with the IMS (IP Multimedia Subsystem) core providing the proxy fabric. Every VoLTE phone has a SIP stack that speaks this method. When Apple finally added RCS support to iMessage in 2024, the underlying wire protocol was — quietly — RFC 3428 plus a pile of GSMA profiles on top.

The backstory. Dean Willis and the SIMPLE working group spent years fighting over whether IM should be a SIP extension or its own protocol (XMPP/Jabber being the alternative). The compromise was elegant: SIMPLE handled presence and messaging via SIP for the telecom world; XMPP won the consumer/enterprise side. Two decades later, both still coexist — XMPP in WhatsApp's roots and Zoom chat, SIP MESSAGE in every cellular network on Earth. Dmitry Gurle, one of the authors, came from Microsoft's MSN Messenger team, which tells you how seriously the IM-walled-garden crowd took this work.