RFC 3428
Session Initiation Protocol (SIP) Extension for Instant Messaging
Session Initiation Protocol (SIP) Extension for Instant Messaging 💖
okay bestie, RFC 3428 is literally the spec that teaches SIP how to send instant messages 📱✨ this is part 1 of 4, so grab your snacks 🍓
Here's the title block tea ☕. It's RFC 3428, from the Network Working Group, and it's a Standards Track doc dated December 2002 🎀. The authors are B. Campbell, Ed., J. Rosenberg (dynamicsoft), H. Schulzrinne (Columbia University), C. Huitema, and D. Gurle (Microsoft Corporation). The title block doesn't list anything it obsoletes or updates 💅
Status of this Memo 📜
ok so this doc is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions to make it better 🫶 for the standardization state and status, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🌈
Copyright Notice ©️
Copyright (C) The Internet Society (2002). All Rights Reserved. 🔒
Abstract 🦋
Instant Messaging (IM) is when messages get passed between users in near real-time ⚡ they're usually short, but they don't have to be. People use IMs in a conversational way, where messages go back and forth fast enough to keep a live chat going 💬
This doc proposes the MESSAGE method, which is an extension to the Session Initiation Protocol (SIP) that lets you transfer Instant Messages 🎀 because MESSAGE is a SIP extension, it inherits all of SIP's request routing and security features, so it's giving built-in glow-up 🔥 MESSAGE requests carry their content as MIME body parts. They do NOT start a SIP dialog themselves. Usually each Instant Message stands alone, kinda like old pager messages 📟 MESSAGE requests may be sent inside a dialog that some other SIP request started, though 👀
Terminology 📚
In this doc, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY" and "OPTIONAL" are to be read as described in BCP 14, RFC 2119 [6]. They tell you the requirement levels for compliant SIP implementations, so pay attention to them 🧚
Table of Contents 🗂️
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Scope of Applicability . . . . . . . . . . . . . . . . . . . 3
3. Overview of Operation . . . . . . . . . . . . . . . . . . . 4
4. UAC Processing . . . . . . . . . . . . . . . . . . . . . . . 5
5. Use of Instant Message URIs . . . . . . . . . . . . . . . . 6
6. Proxy Processing . . . . . . . . . . . . . . . . . . . . . . 6
7. UAS Processing . . . . . . . . . . . . . . . . . . . . . . . 7
8. Congestion Control . . . . . . . . . . . . . . . . . . . . . 8
9. Method Definition . . . . . . . . . . . . . . . . . . . . . 9
10. Example Messages . . . . . . . . . . . . . . . . . . . . . . 11
11. Security Considerations . . . . . . . . . . . . . . . . . . 13
11.1 Outbound authentication . . . . . . . . . . . . . . . . . . 13
11.2 SIPS URIs . . . . . . . . . . . . . . . . . . . . . . . . . 14
11.3 End-to-End Protection . . . . . . . . . . . . . . . . . . . 14
11.4 Replay Prevention . . . . . . . . . . . . . . . . . . . . . 14
11.5 Using message/cpim bodies . . . . . . . . . . . . . . . . . 15
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . 15
13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 15
15. Normative References . . . . . . . . . . . . . . . . . . . . 16
16. Informational References . . . . . . . . . . . . . . . . . . 16
17. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 17
18. Full Copyright Statement . . . . . . . . . . . . . . . . . . 181. Introduction ✨
Instant Messaging (IM) is the exchange of content between a group of participants in near real time 💬 the content is usually short text messages, though it doesn't have to be. The messages usually aren't stored, but that doesn't have to be true either. IM is different from email in everyday use because IMs usually bunch up into quick live conversations made of lots of little messages going back and forth 🦋
IM has been around inside intranets and IP networks for ages 🕰️ early examples include zephyr [11], the UNIX talk application, and IRC. More recently, IM has been paired with presence and buddy lists, so when a friend comes online you can know about it and choose to send them an IM 🫶 the protocols for all of this are proprietary, and that has seriously gotten in the way of interoperability 😤
Putting instant messaging, presence, and session-oriented communications together is seriously powerful 🔥 the Session Initiation Protocol (SIP) [1] has mechanisms that work for presence apps and session-oriented communication apps, but not for instant messages 👀
This doc proposes an extension method for SIP called the MESSAGE method 🎀 MESSAGE requests normally carry the instant message content in the request body 💌
RFC 2778 [3] and RFC 2779 [2] give a model and requirements for presence and instant messaging protocols 📋 implementations of the MESSAGE method SHALL support all the instant message requirements in RFC 2779 that are relevant to its scope of applicability. No skipping, bestie 💅
2. Scope of Applicability 🎯
This doc describes how to use the MESSAGE method to send instant messages, kinda like a two-way pager or an SMS-enabled handset 📟 there's no explicit association between messages. Each IM stands alone. Any sense of a "conversation" only exists in the client UI, or maybe in the user's own imagination 🙈 we compare this with a "session" model, which has an explicit conversation with a clear beginning and end. In SIP, an IM session would be a media session started with an INVITE transaction and ended with a BYE transaction 📞
Both models have value 💖 most modern IM clients offer both experiences. A user can send an IM to a contact, or invite one or more contacts to join a conversation. The pager model makes sense when someone wants to send a few short IMs to one recipient, or a small group of them. The session model makes sense for longer conversations, joining chat groups, or when a conversation needs to be linked to some other SIP-initiated session, etc. 🧁
This doc only covers the pager model 🙅♀️ we recognize the value of the session model too, but we don't define it here. A solution like that needs more work beyond this doc, and the SIMPLE work group plans to handle IM sessions in a separate document 📝
Someone might be tempted to fake a session of IMs by starting a dialog and then sending MESSAGE requests inside that dialog. That is NOT an adequate solution for IM sessions 😬 the reason is that it forces MESSAGE requests to follow the same network path as every other SIP request, even though MESSAGE requests arguably carry media rather than signaling. IM apps are usually high volume, and we expect IM volume in sessions to be even higher. That will likely cause congestion problems if it's sent over a transport without congestion control, and SIP has no clear mechanism to stop some hop from forwarding a MESSAGE request over UDP 🚧
Also, MESSAGE requests sent over an existing dialog must, by the nature of SIP, go to the same destination as any other request sent in that dialog. That blocks any separation between the IM endpoint and the signaling endpoint, and that's not an acceptable limitation for the session model of instant messaging 🙅♀️
The authors know there can be valid reasons to send MESSAGE requests inside a dialog 💭 for example, one participant in a voice session might want to send an IM to another participant and tie that IM to the session. But implementations SHOULD NOT create dialogs for the primary purpose of associating MESSAGE requests with one another 🛑
This statement doesn't stop you from using SIP to start a media session made of IMs, the same way you'd start any other session. Honestly, we expect the IM session solution to use that metaphor 🧚 just don't mix up a SIP dialog and a media session. They're different things, bestie 💅
3. Overview of Operation 🗺️
When one user wants to send an instant message to another, the sender builds and issues a SIP request using the new MESSAGE method from this doc 📨 the Request-URI of this request will normally be the "address of record" for the recipient. It might be a device address instead, if the client has current info about where the recipient is. For example, the client could be paired with a presence system that gives an up-to-date device contact for a given address of record 📍 the body of the request holds the message being delivered. That body can be any MIME type, including message/cpim [7] ✨
Here's why message/cpim is so cute 🥰 that format is expected to be supported by other IM protocols too, so endpoints using different IM protocols, as long as they support message/cpim bodies, should be able to swap messages without a gateway or other middleman changing the content. This helps enable end-to-end security between endpoints that use different IM protocols 🔐
The request might go through a bunch of SIP proxies, using different transports, before it reaches its destination 🛣️ each hop's destination is found using the address resolution rules in the Common Profile for Instant Messaging (CPIM) [8] and SIP specifications. Along the way, each proxy may rewrite the request URI based on the routing info it has 🔄
Provisional and final responses to the request go back to the sender, same as with any other SIP request 📬 usually a 200 OK response comes from the user agent of the request's final recipient. Just remember that this means the user agent accepted the message, not that the user has actually seen it 👀
MESSAGE requests do not establish dialogs. 🫶
4. UAC Processing ✨
Okay so, unless this doc says otherwise, MESSAGE requests and their responses get built using the rules in section 8.1 of the SIP spec [1] 📜
All UACs that 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 [7] 💌
MESSAGE requests don't start dialogs, so User Agents MUST NOT insert Contact header fields into them 🙅♀️
A UAC MAY associate a MESSAGE request with an existing dialog. If a MESSAGE request gets sent within a dialog, it is "associated" with any media session or sessions tied to that dialog 🦋
If the UAC gets a 200 OK for a MESSAGE, it may assume the message reached the final destination. But it MUST NOT assume the recipient has actually read the instant message 👀 If the UAC gets a 202 Accepted, the message made it to a gateway, a store-and-forward server, or some other service that might deliver it later. In that case the UAC MUST NOT assume the message reached the final destination. If you need confirmation of delivery for a message that got a 202 Accepted, that confirmation has to come through some other mechanism, which is beyond the scope of this spec 💅
Note that a downstream proxy could fork a MESSAGE request 🍴 When that happens, the forking proxy forwards one final response upstream, even though it may have received multiple final responses. The UAC has no way to tell whether a fork happened, so the UAC MUST NOT assume a given final response is the only UAS that received the request. For example, multiple branches of a fork could have returned 2xx responses. Even though the UAC only sees one of those, the request was in fact received by the second device too 😭
The UAC MAY add an Expires header field to limit how long the message content is valid ⏳ 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 was sent 🗓️
5. Use of Instant Message URIs ✨
An instant inbox can most generally be referenced by an Instant Message URI [8] in the form of im:user@domain 📬 IM URIs are abstract, and they'll eventually get translated into concrete, protocol-dependent URIs 🌸
If a UA is handed an IM URI as the address for an instant message, it SHOULD resolve it to a SIP URI and put the resulting URI in the Request-URI of the MESSAGE request before sending it 🎯 If the UA can't resolve the IM URI, it MAY put the IM URI in the Request-URI and hand off resolution to a downstream device, like a proxy or gateway 🤝 Doing this translation as early as possible lets SIP proxies, which might not know the im: namespace, route the requests normally 🛣️
MESSAGE requests also carry logical identifiers for the sender and the intended recipient, in the form of the From and To header fields. These identifiers SHOULD contain SIP (or SIPS) URIs, but MAY include IM URIs if the SIP URIs aren't known when the request is built 🧚
Record-Route and Route header fields MUST NOT contain IM URIs. Those header fields hold concrete SIP or SIPS URIs, following the rules of SIP [1] 🚫
6. Proxy Processing ✨
Proxies route MESSAGE requests according to the rules of SIP [1] 🗺️ Note that a MESSAGE request MAY fork, which lets the message get delivered to several possible terminals where the user might be 📱💻 A proxy that forks a MESSAGE request follows the normal SIP rules for forking a non-INVITE request. Even if the fork ends up with multiple successful deliveries, the forking proxy only forwards one final response upstream 💖
7. UAS Processing ✨
A UAS that receives a MESSAGE request processes it by following the rules of SIP [1] 🧠
A UAS receiving a MESSAGE request SHOULD respond with a final response right away. But the UAS isn't obligated to show the message to the user either before or after it responds with a 200 OK. So a 200 OK doesn't necessarily mean the user has read the message 👑
A 2xx response to a MESSAGE request MUST NOT contain a body 🙅♀️ A UAS MUST NOT insert a Contact header field into a 2xx response either 🚫
A UAS that is actually a message relay, which stores the message and forwards it later or forwards it into a non-SIP domain, SHOULD return a 202 (Accepted) [5] response. That tells the sender the message was accepted, but end-to-end delivery isn't guaranteed 📦
A 4xx or 5xx response means the message was not delivered successfully 😬 A 6xx response means it was delivered successfully, but refused 🙅♀️
A UAS that supports the MESSAGE method MUST be prepared to receive and render bodies of type "text/plain", and it may support receiving and rendering bodies of type "message/cpim" [7] 🎀
A MESSAGE request is said to be expired if its expiration time has passed. The expiration time is decided by looking at the Expires header field, if one is present. MESSAGE requests without an Expires header field never expire ♾️ If a MESSAGE request has an Expires header field and also a Date header field, the UAS SHOULD interpret the Expires header field value as a delta time from the Date header field value. If the request doesn't have a Date header field, the UAS SHOULD interpret the Expires header value as a delta time from the moment the UAS received the request ⏰
If the MESSAGE expires before the UAS can present it to the user, the UAS SHOULD handle the message based on local policy. That policy could mean the message gets deleted undisplayed, the message still gets displayed to the user, or some other policy kicks in 🤷♀️ If the message does get displayed, the UAS SHOULD clearly indicate to the user that the message has expired 🙈
If the UAS is acting as a message relay and can't deliver the message before it expires, it picks an action based on local policy. That action could be deleting the message undelivered, delivering it as is, logging the expired message, or any other local policy 📝
8. Congestion Control ✨
Existing IM services have a long history of very high-volume usage 📈 On top of that, MESSAGE requests are different from other kinds of SIP requests because they carry media, in the form of IMs, as their payload 💬 Conventional SIP payloads carry signaling information about media, but not the media itself. There's a real possibility that when a SIP infrastructure is shared between call signaling and instant messaging, the IM traffic will interfere with call signaling traffic 😱 Congestion control in general is something that should be handled at the SIP specification level rather than for an individual method. But since the traffic patterns for MESSAGE are likely to differ from most other methods, it makes sense to give MESSAGE some special consideration 🫶
Whenever possible, MESSAGE requests SHOULD be sent over transports that implement end-to-end congestion control, such as TCP or SCTP 🚦 However, SIP doesn't provide a mechanism to stop a downstream hop from sending a request over UDP. Even the requirement to use TCP for requests over a certain size can be overridden by the receiver. So using a congestion-controlled transport at the UAC isn't enough on its own 🙃
The size of MESSAGE requests outside of a media session MUST NOT exceed 1300 bytes, unless the UAC has positive knowledge that the message won't traverse a congestion-unsafe link at any hop, or that the message size is at least 200 bytes smaller than the lowest MTU value found en route to the UAS 📏 Larger payloads may be sent as part of a media session, or by using some type of content indirection 🌈
At the time of this writing, there's no mechanism for a UAC to gain that knowledge outside of trivial network architectures, or networks that are fully controlled by a single administrative domain. But if a mechanism for ensuring congestion control at each hop gets created in the future, MESSAGE clients can relax the size limit without needing a change to this specification. The authors expect that such a mechanism will be created in the near future 🔮
There have been discussions about basing the 1300 byte limit on the path MTU to the next hop SIP device. The SIP specification does exactly that, choosing a limit 200 bytes less than the path MTU, or 1300 bytes if the device doesn't know the path MTU. Transport decisions are made on a per-hop basis. However, the whole point of this limit is to make sure no upstream proxy chooses to send a MESSAGE request with large content over UDP. Except in trivial circumstances, a MESSAGE client is very unlikely to know the MTU for upstream devices beyond the next hop, so an MTU-based limit isn't very useful 🤔
A UAC MUST NOT initiate a new out-of-dialog MESSAGE transaction to a given URI if there's a previous out-of-dialog transaction still pending for the same URI 🛑 Similarly, A UAC SHOULD NOT initiate overlapping MESSAGE transactions inside a dialog, and it MUST NOT do so unless the route set for that dialog uses a congestion-controlled transport at every hop 🔒
The rule against overlappingMESSAGErequests gives us some degree of congestion-safe behavior. A request and its associated response each have to cross the full path between the UAC and the UAS. That time increases as networks get congested, so it's an adaptive mechanism that slows down the introduction of newMESSAGErequests to the same destination 🐢
It has been suggested that provisional responses shouldn't be allowed for pager-model MESSAGE requests. However, it isn't possible to require special treatment for MESSAGE, since many proxy servers won't be aware of the MESSAGE method. So MESSAGE requests get the same provisional response treatment as any other non-INVITE method, as described in the SIP specification 💜
9. Method Definition ✨
okay so this section is where the new method gets its official name tag 🦋. It defines MESSAGE, and the BNF is:
MESSAGEm = %x4D.45.53.53.41.47.45 ;MESSAGE in capsHeads up, bestie: like every other method, MESSAGE is case sensitive 💅 so message won't count.
Next, Tables 1 and 2 are basically the header field guest list. They extend Tables 2 and 3 of SIP [1] by adding one extra column that says which header fields can show up in MESSAGE requests and responses. It's giving organized spreadsheet 🌸
Header Field where proxy MESSAGE
__________________________________________
Accept R -
Accept 2xx -
Accept 415 m*
Accept-Encoding R -
Accept-Encoding 2xx -
Accept-Encoding 415 m*
Accept-Language R -
Accept-Language 2xx -
Accept-Language 415 m*
Alert-Info R -
Alert-Info 180 -
Allow R o
Allow 2xx o
Allow r o
Allow 405 m
Authentication-Info 2xx o
Authorization R o
Call-ID c r m
Call-Info ar o
Contact R -
Contact 1xx -
Contact 2xx -
Contact 3xx o
Contact 485 o
Content-Disposition o
Content-Encoding o
Content-Language o
Content-Length ar t
Content-Type *
CSeq c r m
Date a o
Error-Info 300-699 a o
Expires o
From c r m
In-Reply-To R o
Max-Forwards R amr m
Organization ar o
Table 1: Summary of header fields, A--O
Header Field where proxy MESSAGE
__________________________________________
Priority R ar o
Proxy-Authenticate 407 ar m
Proxy-Authenticate 401 ar o
Proxy-Authorization R dr o
Proxy-Require R ar o
Record-Route ar -
Reply-To o
Require ar c
Retry-After 404,413,480,486 o
500,503 o
600,603 o
Route R adr o
Server r o
Subject R o
Timestamp o
To c(1) r m
Unsupported 420 o
User-Agent o
Via R amr m
Via rc dr m
Warning r o
WWW-Authenticate 401 ar m
WWW-Authenticate 407 ar o
(1): copied with possible addition of tag
Table 2: Summary of header fields, P--ZLast bit of this section: a MESSAGE request MAY contain a body 🎀 and you use the normal MIME header fields to say what kind of content it is.
10. Example Messages 💌
Time for the fun part, a little message flow 🍓 Figure 1 shows an initial IM going from User 1 to User 2. They're both in the same domain, "domain", and it goes through one proxy.
| F1 MESSAGE | |
|--------------------> | F2 MESSAGE |
| | ----------------------->|
| | |
| | F3 200 OK |
| | <-----------------------|
| F4 200 OK | |
|<-------------------- | |
| | |
| | |
| | |
User 1 Proxy User 2
Figure 1: Example Message FlowMessage F1 looks like this, bestie 👀
MESSAGE sip:user2@domain.com SIP/2.0
Via: SIP/2.0/TCP user1pc.domain.com;branch=z9hG4bK776sgdkse
Max-Forwards: 70
From: sip:user1@domain.com;tag=49583
To: sip:user2@domain.com
Call-ID: asd88asd77a@1.2.3.4
CSeq: 1 MESSAGE
Content-Type: text/plain
Content-Length: 18
Watson, come here.So User1 sends that to the server for domain.com 📮 The proxy sees that it's the server for domain.com, then checks its database (filled up by registrations) for user2. It finds a binding from sip:user2@domain.com to sip:user2@user2pc.domain.com, so it forwards the request to user2 ✨ The resulting message, F2, looks like this:
MESSAGE sip:user2@domain.com SIP/2.0
Via: SIP/2.0/TCP proxy.domain.com;branch=z9hG4bK123dsghds
Via: SIP/2.0/TCP user1pc.domain.com;branch=z9hG4bK776sgdkse;
received=1.2.3.4
Max-Forwards: 69
From: sip:user1@domain.com;tag=49394
To: sip:user2@domain.com
Call-ID: asd88asd77a@1.2.3.4
CSeq: 1 MESSAGE
Content-Type: text/plain
Content-Length: 18
Watson, come here.User2 gets it, displays it, and generates a response, message F3, which gets sent back to the proxy 🫶
SIP/2.0 200 OK
Via: SIP/2.0/TCP proxy.domain.com;branch=z9hG4bK123dsghds;
received=192.0.2.1
Via: SIP/2.0/TCP user1pc.domain.com;;branch=z9hG4bK776sgdkse;
received=1.2.3.4
From: sip:user1@domain.com;tag=49394
To: sip:user2@domain.com;tag=ab8asdasd9
Call-ID: asd88asd77a@1.2.3.4
CSeq: 1 MESSAGE
Content-Length: 0Notice that most header fields just get reflected back in the response 🪞 The proxy gets this response, strips off the top Via, and forwards it to the address in the next Via, which is user1pc.domain.com. That makes message F4:
SIP/2.0 200 OK
Via: SIP/2.0/TCP user1pc.domain.com;branch=z9hG4bK776sgdkse;
received=1.2.3.4
From: sip:user1@domain.com;;tag=49394
To: sip:user2@domain.com;tag=ab8asdasd9
Call-ID: asd88asd77a@1.2.3.4
CSeq: 1 MESSAGE
Content-Length: 011. Security Considerations 🔐
Okay bestie, this is the serious part, so pay attention 😭 In normal usage, most SIP requests are used to set up and change communication sessions. The actual conversation happens in the media sessions, not in the SIP requests themselves. MESSAGE flips that assumption. MESSAGE requests normally carry the actual communication between participants as their payload. So MESSAGE requests need stronger security than most other SIP requests. In particular, UAs that support the MESSAGE request MUST implement end-to-end authentication, body integrity, and body confidentiality mechanisms. Non-negotiable, periodt 💀
11.1 Outbound Authentication
When local proxies are used to send outbound messages, proxy authentication, as specified in RFC 3261, is RECOMMENDED 🛡️ It's useful for verifying who the originator is, and for stopping spoofing and spamming at the originating network.
11.2 SIPS URIs
The SIPS URI mechanism [1] lets a UA say that every hop has to happen over a secure connection 🔒 That gives some level of integrity and privacy protection. BUT, and this is a big but, it requires users to trust that every proxy on the request path is well-behaved. In other words, they don't break the rules for routing SIPS URIs. Also, any unencrypted bodies are fully visible to the proxies 👁️
Plus, a forking proxy could deliver a MESSAGE request to extra endpoints without the UAC knowing about it 🍴 If only hop-by-hop protection is in place, users have to trust every proxy in the chain not to fork requests to unauthorized destinations.
11.3 End-to-End Protection
When the goal is to fix the concerns above, the MESSAGE bodies MUST be secured with S/MIME 🔏 If bodies specified in the future to be carried by the MESSAGE method have different ways of providing end-to-end security, their specification MUST describe that usage. SIP MESSAGE endpoints MUST support encryption (CMS EnvelopeData) and S/MIME signatures (CMS SignedData). Two requirements, zero exceptions ✨
The S/MIME algorithms are set by RFC 3369 [4]. The AES [10] algorithm should be preferred, since it's expected to suit the capabilities of many platforms. However, an IETF specification for this was still incomplete at the time of writing 🧩
11.4 Replay Prevention
To stop old SIP requests from being replayed 🔁 all signed MESSAGE requests and responses MUST contain a Date header field that's covered by the message signature. Any message with a date older than several minutes in the past, or more than several minutes in the future, SHOULD be answered with a 400 (Incorrect Date or Time) message. The exception: if such messages keep arriving from the same source, they MAY be discarded without sending a response. Obviously, this replay attack prevention mechanism does not work for devices without clocks 🕰️
Now, stale Date header fields can be totally normal. Imagine the MESSAGE request got stored in a store and forward server while the recipient was offline. When the recipient comes back, that server might forward the message then, so the final receipt happens some time after it was originally sent 📬
If a UAS gets a stale message that can be confirmed to have come from a known store and forward server (maybe over a TLS connection), it makes sense for it to accept the message normally 🫶 Also, if one or more stale messages show up shortly after an offline period, the UAS MAY accept the message, but SHOULD warn the user that the message might have been replayed. Stay alert, bestie 🚨
11.5. Using message/cpim Bodies ✨
okay so the message/cpim format [7] can get S/MIME protection for its metadata too, not just the message itself 🔐 bestie, that's a big deal. In most cases that metadata is basically a copy of stuff already in the SIP header fields, so it's a bit redundant 🙈 but it's still worth it, because protecting the metadata can follow the message across protocol boundaries. 🦋
Here's the iconic example: a signed message/cpim body can prove who sent the message using the message/cpim From header field. That still works even if the message gets routed through a gateway into another CPIM-compliant instant message service that has no idea what SIP header fields are. Main character energy, literally 💅
12. IANA Considerations 🎀
This specification registers the MESSAGE method in the http://www.iana.org/assignments/sip-parameters/Method registry, with the following info:
MESSAGE [RFC3428]13. Contributors 🌸
The following people made substantial contributions to this work 🫶
Bernard Aboba Microsoft
Steve Donovan dynamicsoft
Jonathan Lennox Columbia University
Dave Oran Cisco
Robert Sparks dynamicsoft
Dean Willis dynamicsoft14. Acknowledgments 🧚
The authors want to thank these people for supporting the idea of SIP for IM, supporting this work, and giving useful comments and insights. Iconic squad 👑
Jon Peterson NeuStar
Sean Olson Microsoft
Adam Roach dynamicsoft
Billy Biggs University of Waterloo
Stuart Barkley UUNet
Mauricio Arango SUN
Richard Shockey NeuStar
Jorgen Bjorker Hotsip
Henry Sinnreich MCI Worldcom
Ronald Akers Motorola
Torrey Searle Indigo Software
Rohan Mahy Cisco
Christian Groves Ericsson
Allison Mankin ISI
Tan Ya-Ching Siemens15. Normative References 📚
- [1] 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.
- [2] Day, M., Aggarwal, S. and J. Vincent, "Instant Messaging / Presence Protocol Requirements", RFC 2779, February 2000.
- [3] Day, M., Rosenberg, J. and H. Sugano, "A Model for Presence and Instant Messaging", RFC 2778, February 2000.
- [4] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3369, August 2002.
- [5] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
- [6] Bradner, S., "Keywords for Use in RFC's to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
16. Informational References 🦋
- [7] Atkins, D. and G. Klyne, "Common Presence and Instant Messaging Message Format", Work in Progress.
- [8] Crocker, D., Diacakis, A., Mazzoldi, F., Huitema, C., Klyne, G., Rose, M., Rosenberg, J., Sparks, R., Sugano, H. and J. Peterson, "Address Resolution for Instant Messaging and Presence", Work in Progress.
- [9] Rosenberg, J. and H. Schulzrinne, "SIP Caller Preferences and Callee Capabilities", Work in Progress.
- [10] Schaad, J. and R. Housley, "Use of the AES Encryption Algorithm and RSA-OAEP Key Transport in CMS", Work in Progress.
- [11] DellaFera, C., Eichin, M., French, R., Jedlinski, D., Kohl, J. and W. Sommerfeld, "The Zephyr notification service", in USENIX Winter Conference (Dallas, Texas), Feb. 1988.
17. Authors' Addresses 💌
Ben Campbell
dynamicsoft
5100 Tennyson Parkway
Suite 1200
Plano, TX 75024
EMail: bcampbell@dynamicsoft.com
Jonathan Rosenberg
dynamicsoft
72 Eagle Rock Avenue
First Floor
East Hanover, NJ 07936
EMail: jdrosen@dynamicsoft.com
Henning Schulzrinne
Columbia University
M/S 0401
1214 Amsterdam Ave.
New York, NY 10027-7003
EMail: schulzrinne@cs.columbia.edu
Christian Huitema
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052-6399
EMail: huitema@microsoft.com
David Gurle
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052-6399
EMail: dgurle@microsoft.com18. Full Copyright Statement ⭐
The legal text below is kept word-for-word, since it has to stay complete and unchanged.
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
Acknowledgement 💜
Funding for the RFC Editor function is currently provided by the Internet Society. 🌈
📦 where this page comes from
- ietf: rfc3428 2002-12
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms