RFC 4416
Goals for Internet Messaging to Support Diverse Service Environments
Goals for Internet Email to Support Diverse Service Environments 💌
Okay bestie, this one is an RFC (a Request for Comments, basically the Internet's official rulebook drafts), and it's written by J. Wong, Ed. from Nortel Networks 🎀 It's dated February 2006, and it's marked as Informational, which means it's sharing background and ideas for the Internet community rather than setting a binding standard. It doesn't obsolete or update any other RFC, since its header doesn't list any. Its number is RFC 4416. Iconic. 💅
Status of This Memo 📋
Here's the legal-but-important bit 🤓 This memo is here to provide information for the Internet community. It is not an Internet standard of any kind. And distribution is totally unlimited, so share away 🦋
Copyright Notice ©️
The Internet Society owns the copyright here, and the year is 2006. Copyright (C) The Internet Society (2006).
Abstract ✨
Okay, so this document is basically a history 📜 It captures the background, the motivation, and the thinking that went into the LEMONADE definition and design process 🍋
The LEMONADE Working Group (which is "Internet email to support diverse service environments") got chartered to upgrade Internet mail so that more diverse clients can use it 💖 The big focus is on clients running on hosts that live in environments with high latency, limited bandwidth, and unreliable links, and that also have limited resources. The enhanced mail must stay backwards compatible with existing Internet mail, because nobody wants to break the good stuff we already have 🙈
The main motivation is that by making Internet mail protocols richer and more adaptable to all kinds of media and environments, mobile handheld devices can get tetherless access to Internet mail using only IETF mail protocols 📱🫶
The requirements for those devices kick off a discussion about which protocol enhancements would be needed to support multimedia messaging on limited-capability hosts in all these different service environments. A list of general principles to guide the design of the enhanced messaging protocols is documented too 🧚 And last but not least, the document briefly lists some extra issues around providing seamless service between enhanced Internet mail and the existing, separate mobile messaging infrastructure 🌈
Table of Contents 🗂️
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions Used in This Document . . . . . . . . . . . . . . 6
3. Messaging Terminology and Simple Model (Client-to-Server
Aspect Only) . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Messaging Transaction Models . . . . . . . . . . . . . . . 6
3.2. Mobile Messaging Transactions . . . . . . . . . . . . . . 7
3.2.1. Submission . . . . . . . . . . . . . . . . . . . . . . 7
3.2.2. Notification . . . . . . . . . . . . . . . . . . . . . 7
3.2.3. Retrieval . . . . . . . . . . . . . . . . . . . . . . 8
4. Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Existing Profiles . . . . . . . . . . . . . . . . . . . . 8
4.1.1. Voice Messaging (VPIMv2) . . . . . . . . . . . . . . . 8
4.1.2. iFax . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1.3. Internet Voice Mail (IVM) . . . . . . . . . . . . . . 9
4.2. Putative Client Profiles . . . . . . . . . . . . . . . . . 9
4.2.1. TUI . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.2.2. Multi-Modal Clients . . . . . . . . . . . . . . . . . 11
4.2.3. WUI . . . . . . . . . . . . . . . . . . . . . . . . . 11
5. General Principles . . . . . . . . . . . . . . . . . . . . . . 13
5.1. Protocol Conservation . . . . . . . . . . . . . . . . . . 13
5.1.1. Reuse Existing Protocols . . . . . . . . . . . . . . . 13
5.1.2. Maintain Existing Protocol Integrity . . . . . . . . . 13
5.2. Sensible Reception/Sending Context . . . . . . . . . . . . 13
5.2.1. Reception Context . . . . . . . . . . . . . . . . . . 13
5.2.2. Sending Context . . . . . . . . . . . . . . . . . . . 13
5.3. Internet Infrastructure Preservation . . . . . . . . . . . 14
5.4. Voice Requirements (Near Real-Time Delivery) . . . . . . . 14
5.5. Fax Requirements (Guaranteed Delivery) . . . . . . . . . . 14
5.6. Video Requirements (Scalable Message Size) . . . . . . . . 14
6. Issues and Requirements: TUI Subset of WUI . . . . . . . . . . 14
6.1. Requirements on the Message Retrieval Protocol . . . . . . 14
6.1.1. Performance Issues . . . . . . . . . . . . . . . . . . 15
6.1.2. Functional Issues . . . . . . . . . . . . . . . . . . 16
6.2. Requirements on the Message Submission Protocol . . . . . 18
6.2.1. Forward without Download Support . . . . . . . . . . . 18
6.2.2. Quota by Context Enforcement . . . . . . . . . . . . . 19
6.2.3. Future Delivery Support with Cancel . . . . . . . . . 19
6.2.4. Support for Committed Message Delivery . . . . . . . . 20
6.3. Requirements on Message Notification . . . . . . . . . . . 20
6.3.1. Additional Requirements on Message Notification . . . 21
7. Issues and Requirements: WUI Mobility Aspects . . . . . . . . 21
7.1. Wireless Considerations on Email . . . . . . . . . . . . . 21
7.1.1. Transport Considerations . . . . . . . . . . . . . . . 21
7.1.2. Handset-Resident Client Limitations . . . . . . . . . 22
7.1.3. Wireless Bandwidth and Network Utilization
Considerations . . . . . . . . . . . . . . . . . . . . 22
7.1.4. Content Display Considerations . . . . . . . . . . . . 23
7.2. Requirements to Enable Wireless Device Support . . . . . . 24
7.2.1. Transport Requirements . . . . . . . . . . . . . . . . 24
7.2.2. Enhanced Mobile Email Functionality . . . . . . . . . 24
7.2.3. Client Requirements . . . . . . . . . . . . . . . . . 25
7.2.4. Bandwidth Requirements . . . . . . . . . . . . . . . . 25
7.2.5. Media Handling Requirements . . . . . . . . . . . . . 25
8. Interoperation with Existing Mobile Messaging . . . . . . . . 27
8.1. Addressing of Mobile Devices . . . . . . . . . . . . . . . 27
8.2. Push Model of Message Retrieval . . . . . . . . . . . . . 27
8.3. Message Notification . . . . . . . . . . . . . . . . . . . 27
8.4. Operator Issues . . . . . . . . . . . . . . . . . . . . . 27
8.4.1. Support for End-to-End Delivery Reports and
Message-Read Reports . . . . . . . . . . . . . . . . . 27
8.4.2. Support for Selective Downloading . . . . . . . . . . 27
8.4.3. Transactions and Operator Charging Units . . . . . . . 27
8.4.4. Network Authentication . . . . . . . . . . . . . . . . 28
8.5. LEMONADE and MMS . . . . . . . . . . . . . . . . . . . . . 28
9. Security Considerations . . . . . . . . . . . . . . . . . . . 32
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
10.1. Normative References . . . . . . . . . . . . . . . . . . . 32
10.2. Informative References . . . . . . . . . . . . . . . . . . 32
Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 37
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 38
Appendix C. IAB Note: Unified Notification Protocol
Considerations . . . . . . . . . . . . . . . . . . . 381. Introduction ✨
Okay so, historically, a bunch of separate electronic messaging systems popped up and grew up on their own, each supporting different messaging modes. 💅 For example:
- Internet mail systems ([4], [10], [25]) leveled up to work with networked computers, with messages made of rich text plus attachments. 💌
- Voice mail systems used a client with a telephone-based or answering-machine style of interface. The telephone network carried the recorded voice messages. 📞
- Fax store-and-forward users talk to a fax machine through a modified telephone-based interface. Fax machines use the telephone network to transport fax data via modems. 📠
- SMS (Short Message Service) [58] let users send short text messages between their cell phones, using the SS7 call control infrastructure ([60], [61], [63], [64], [65]) for transport. 📱
In the recent past, IETF mail standards have been evolving to support additional and merged functionality. 🦋
- With MIME ([5], [6], [7], [8], [9], [28]), Internet mail transport got an upgrade and can now carry any kind of digital data. 🌈
- Internet mail protocols were extended and profiled by VPIM ([13], [14], [15], [34]) and iFAX ([16], [17], [18], [19], [20], [21], [23]). That meant voice mail systems and fax machines could use the common email infrastructure to carry their messages over the Internet, as an alternative to the telephone network. The enhancements were so good that the user's experience of reliability, security, and responsiveness did not get worse when the messages traveled over the Internet. 🔥
These wins, making Internet mail transport the common infrastructure behind what used to be separate messaging universes, have inspired a new vision. 🧚 The vision is a single infrastructure, mailbox, and set of protocols over the Internet, so a user can get, respond to, and manage all of their messages from a bunch of clients with different capabilities, running in all kinds of environments ([46],[47]). 👑
The LEMONADE effort (Internet email to support diverse service environments) makes this vision real by enabling Internet mail support for mobile devices. It also helps those devices work with the existing mobile messaging universe. 🍋✨
In the recent past, messaging standards for resource-limited mobile devices have evolved super fast: 🚀
- In the cellular space, SMS got upgraded to EMS (Extended Message Service) [59], which allows longer text messages, images, and graphics. Then, with an even richer feature set, MMS (Multimedia Messaging Service) ([43], [52], [53], [56], [57]) came along as a lightweight access mechanism for sending pictures, audio, and motion pictures. MMS protocols are based partly on Internet standards (both messaging and web [24]) as well as on SMS. The cellular messaging universe is its own separate infrastructure, adapted to deliver the right functionality in a timely and effective way to a special environment. 📲
- On top of that, the number of different mobile clients that need support keeps multiplying. (For example, besides cell phones there are wireless-enabled PDAs, tablet computers, etc.) 🤯
These resource-limited mobile devices are less powerful than conventional computers, both in processing speed and in display capabilities. They also connect to the network over wireless links, where the bandwidth and reliability are lower, the latency is longer, and the costs are higher than on traditional wire-line links. That's why it's so important to support adaptation to a whole different service environment. 🥺
This document collects a number of the issues that stop Internet mail protocols from directly supporting the mobile service environment. 🎀 It documents the considerations that come out of those issues, and in some cases it suggests possible approaches to solutions. Here's the plot twist: the enhancements made to support mobile clients also bring benefits to some terminals in other environments. 😭 In particular, the enhancements address the needs of these diverse clients:
- A wireless handheld device with an email client. The Wireless User Interface (WUI) mode of interaction is dictated by the constraints of the mobile wireless handheld operating environment. 📱
- Telephone-based voice client: a Telephone User Interface (TUI), which is the user mode offered by a POTS set. 📞
- This is a subset of the WUI and is useful in other contexts. 💜
- A multi-modal messaging client that provides a coordinated messaging session using display and audio modes at the same time. (For example, a system made of a PC with a phone, or a wireless phone with both a voice circuit and a data channel that need to coordinate.) 🎧
- This is also a subset of the WUI and is useful in other contexts. 🌸
The rest of this document is laid out like this: 🗺️
- A quick survey of messaging profiles, both existing and proposed.
- A list of principles to guide the design of Internet Messaging for diverse service environments.
- Detailed discussion of enhancements to Internet mail protocols to support WUIs.
- Some issues about how enhanced Internet mail and existing mobile messaging services interoperate.
2. Conventions Used in This Document 🎀
Quick note on pronouns: this document refers to the sender of a message as "he/him/his" and to the recipient as "she/her/hers." 🙈 This is just for convenience. It makes no assumption about the gender of any sender or recipient, so don't read into it! 💖
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119 [1]. 🔑
3. Messaging Terminology and Simple Model (Client-to-Server Aspect Only) 🧠
In the client-server model that's everywhere in existing messaging architectures, the client (also called a "user agent") presents messages to the user and accepts messages from the user. 💅 The server (also called a "relay/server" or a "proxy-relay") provides storage and delivery of messages. 📦
For a definitive description of Internet mail architecture, check out [42]. 📖
3.1. Messaging Transaction Models 🔄
There are two basic transactional models. ✨
In the "pull" model, the component initiates the transaction, not the data flow. For example, a client might start a connection to a server and then send requests asking the server to deliver incoming messages. Conventional email clients, web-mail clients, and WAP-based mobile clients all use the "pull" model. 🙌
The "push" model is different: the component that starts the transaction does so because some data flow is affecting it. For example, a new message arriving at the terminating server might trigger a notification that gets "pushed" to a messaging client. 🚀
3.2. Mobile Messaging Transactions 📲
The most common functions are "submission," "notification," and "retrieval." 💌 There may be other functions too, like "delivery reports," "read-reply reports," "forwarding," "view mailbox," "store message," etc. Each of these transactions can be done in either a pull or push model. Still, some transactions are more naturally suited to one model than the other. 🤔
Here's the simple client-server model. (No server-to-server interactions are shown.) 👀
(1) Message submission
(2) Message notification
(3) & (4) Message retrieval
+-------+ +------+ +-------+
|Mail |-------(1)------>| |-----------(2)-------->|Mail |
|Client | Submit msg | | Notification /|Client |
+-------+ | | / +--+----+
| | / ^
| |<----------(3)-----+ /
|Server| Retrieval request /
| | /
| | /
| |-----------(4)-------+
| | Retrieval response
| |
+------+
Simple Messaging Model3.2.1. Submission 💫
"Submission" is the transaction between a client and a server where the user of the client sends a new message to another user. 💌 Submission is a push from client to server. ⬆️
3.2.2. Notification 🔔
"Notification" is the transaction where the server tells the client that it has received messages meant for that client. 📬 Notification is a push from server to client. ⬇️
All the bigger mobile messaging systems use a push model for notification. That's because the data can be shown to the user without them having to sit through network or transport latencies, and without tying up network resources polling when there's no new data. 🙌
Internet mail is different, though. It hasn't yet seen the need for a standardized notification protocol. 🥲
3.2.3. Retrieval 📥
"Retrieval" is the transaction between a client and a server where the client gets one or more messages from the server. 💖 Retrieval can be push or pull. 🔁
Some mobile systems offer the push model as an option. Its advantage is that the user isn't necessarily aware of transport or network latencies. ✨
The pull model is used in most systems, mobile or conventional. Its advantage is that the user can control what data is actually sent to and stored by the client. 🎀
4. Profiles 🌈
Internet messaging can be made to support a whole bunch of client and server types beyond traditional email. 🦋 Clients can be adapted to host restrictions like limited processing power, message store, display window size, etc. Or clients can be adapted for different functionality, like voice mail, fax, etc. 📠 Servers may support optional mail features that allow better handling of different media (for example, voice mail, fax, video, etc.). A number of Internet mail profiles for specific application niches have been defined or proposed. 🧚
4.1. Existing Profiles 📚
The following are examples of server-to-server profiles of SMTP and MIME. Except for IVM, they don't address client-to-server interactions. 🙃
4.1.1. Voice Messaging (VPIMv2) 🎙️
These profiles, RFC3801 [13] to RFC3803 [15], enable the transport of voice messages using the Internet mail system. The main driver for this work was supporting IP transport for voice mail systems. 📞 Voice mail clients are used to a higher level of responsiveness and certainty about message delivery, so the functionality VPIMv2 adds includes Message Disposition Notification and Delivery Status Message ([12], [3]). Voice media has also been added to multi-part message bodies. 🔊
4.1.2. iFax 📠
This set of profiles ([16], [17], [18], [19], [20], [21]) enables the transport of fax using Internet mail protocols. This work defined the image/tiff MIME type. Fax clients also needed extensions to Message Delivery Notification. 🖨️
4.1.3. Internet Voice Mail (IVM) [34] 🎧
This proposed mail enhancement (whose requirements are described in RFC 3773 [30]) aims to support the interchange of voice messaging between the different components (clients and servers alike) in systems that support voice mail. 💜
4.2. Putative Client Profiles 🌸
4.2.1. TUI ✨
Okay so, it's desirable to swap out the proprietary protocols between telephone user interface clients and message stores for standards-based interfaces 💅. Those proprietary protocols were built to offer media-aware capabilities and the low latency that some messaging apps need 🎀.
A voice mail client is a classic example of a TUI client 📞. A plain old POTS phone has zero intelligence, so the voice mail client functionality has to live in a user agent that's networked to the mail server 🫶. The big architectural difference between a conventional voice mail system and an Internet messaging system that supports a TUI is that voice mail uses a specialized message store and specialized protocols 🙈.
Here's how current voice mail systems implementing VPIMv2 are laid out 🦋:
|-------------|
|-------| RFC-822/MIME | |
| | |---------------------------| MTA |
| | | mail submission -> | |(E)SMTP
Telephone--|TUI|TUA| |------| |-----to
| | | Proprietary Protocol | | |another
| | |---------------------------| MS | | email
|-------| < - mail retrieval | | | server
|-------------|
mail client email server
|----------------voice messaging system -------------|
Mail client consists of: TUI (Telephone User Interface) and
TUA (Telephone User Agent)
Communication between TUI and TUA is proprietary.
Email server consists of: MS (Mail Store) and
MTA (Message Transfer Agent)
Communication between MS and MTA is proprietary.It's proposed that the Proprietary Protocol gets replaced with an IETF standard protocol 🌈:
|-------------|
|-------| RFC-822/MIME | |
| | |---------------------------| MTA |
| | | mail submission -> | |(E)SMTP
Telephone--|TUI|TUA| |------| |-----to
| | | IETF protocol | | |another
| | |---------------------------| MS | | mail
|-------| <- mail retrieval | | | server
|-------------|
mail client email server
|- voice mail system-| |-mail server-|
Mail client consists of: TUI (Telephone User Interface) and
TUA (Telephone User Agent)
Communication between TUI and TUA is proprietary.
Email server consists of: MS (Mail Store) and
MTA (Message Transfer Agent)
Communication between MS and MTA is proprietary.4.2.2. Multi-Modal Clients 🌸
Multi-modal clients give you the glow-up of coordinated voice and data modes of interaction ✨. Architecturally, a multi-modal client can be thought of as the union of two user agent components: a TUI client and a simple GUI client. Check out the next figure 👀. The Graphical User Agent (GUA) keeps the text display going, while the Telephone User Agent (TUA) handles the TUI functionality on its behalf.
This model is the norm with cellular devices that support data access, because they historically evolved from cell phones that had a data channel added on 📱. Presenting multiple complementary modes of interaction means end-users get to pick the most convenient and natural working mode for whatever task they're doing 💖. There are other situations where a multi-modal model makes sense too. (For example, a telephone sales unit needs to offer a voice (telephone) mode and a conventional desktop PC mode at the same time, in an integrated way 📞💻.)
A major issue in designing multi-modal clients is the need to synchronize the component user agents that make up a client 😭. LEMONADE only addresses this to a limited extent, in Section 6.3 🥲.
4.2.3. WUI 🎀
The Wireless User Interface is functionally equivalent to a conventional email client on a personal workstation, but it's optimized for clients on handheld tetherless devices 📱. There are factors to think about here, like limited memory and processing power 🧠. Limited bandwidth is also relatively high cost 💸. As mentioned above, in many cases (for example, cellular devices) the mobile client is multi-modal 🦋. So WUIs can be modeled as resource-and-link-limited multi-modal clients 💜.
These terminals need protocols that minimize the number of over-the-air transactions and cut down on the total amount of data that has to go over the air 📡. That reduction comes from a mix of more efficient protocol interaction and richer message presentation choices, so a user can more intelligently pick what gets downloaded and what stays on the server 🧚. It's not an explicit goal, but providing equivalent or superior functionality to the wireless MMS service [43] (as defined by 3GPP, 3GPP2, and the OMA) is desirable 🍓.
Here's the proposed Wireless User Interface (WUI)/Multi-modal Clients layout 🌈:
|wireless GUI client| email server
(E)SMTP (client-server) |-------------|
|-------| RFC-822/MIME | |
| | |---------------------------| |
| | | mail submission -> | |(E)SMTP
-|GUI|GUA| | |-----to
| | | | IETF standard protocol |------------ |another
| | | |----------------------------to MS below| | mail
| |-------| <- mail retrieval |------------ | server
| | | |
Handheld | | | |
Device WUI | | MTA |
| | | |
| | | |
| |-------| RFC-822/MIME | |
| | | |---------------------------| |
| | | | mail submission -> | |
-|TUI|TUA| |------| |
| | | IETF standard protocol | | |
| | |---------------------------| MS | |
|-------| <- mail retrieval | | |
|-------------|
TUI client voice mail server
|----------------voice messaging system ----------------|
|------WUI-----| |---mail server---|
Wireless GUI client consists of: GUI (Graphical User Interface) and
GUA (Graphical User Agent)
Communication between UI and UA is proprietary.
TUI client consists of: TUI (Telephone User Interface) and
TUA (Telephone User Agent)
Communication between TUI and TUA is proprietary.
Communication between GUA and TUA is proprietary.
Mail (email and voice mail) server consists of:
MS (Mail Store) and
MTA (Message Transfer Agent)
Communication between MS and MTA is proprietary.5. General Principles 💅
Here's a list of principles to guide the design of extensions for Internet Messaging systems and protocols that support diverse endpoints 🌈. Think of these as the vibe check for everything that comes after 🫶.
5.1. Protocol Conservation 🦋
5.1.1. Reuse Existing Protocols
To the extent that it's feasible, the enhanced messaging framework SHOULD use existing protocols whenever possible 🔥.
5.1.2. Maintain Existing Protocol Integrity
Okay, so when meeting the requirement "Reuse Existing Protocols" (Section 5.1.1), the enhanced messaging framework MUST NOT redefine the semantics of an existing protocol 🙅♀️. Extensions, based on capability declaration by the server, will be used to introduce new functionality where required ✨.
Said differently, we will not break existing protocols 💖.
5.2. Sensible Reception/Sending Context 💜
5.2.1. Reception Context
When the user receives a message, that message SHOULD get the treatment the sender expected 📩. For example, if the sender thinks they're sending a voice message, voice message semantics should prevail, to the extent that the receiving client can support that treatment 🎧.
5.2.2. Sending Context
When the user sends a message, they SHOULD be able to specify the message context 🍓. That is, whether the network should treat the message as a text message, a voice message, a video message, and so on 🎬. Again, this can only be complied with to the extent that the infrastructure and receiving client can provide that treatment 🫠. In practice, this would imply that the message should stay in the form the sender wanted all the way up to delivery to the receiving client 💌.
5.3. Internet Infrastructure Preservation 🏰
The infrastructure SHOULD only change where that's required for new functionality 🛠️. Existing functionality MUST be preserved on the existing infrastructure. In other words, all extensions must be backward compatible so the enhancements can roll out gradually 🌱. Messages created in an enhanced messaging context MUST NOT require changes to existing mail clients 📬. However, there may be a degradation in functionality in certain circumstances 😬.
The enhanced messaging framework MUST be able to handle messages created in a non-enhanced messaging context, for example, a simple RFC822 [2] text message 💅.
5.4. Voice Requirements (Near Real-Time Delivery) 🎙️
On the retrieval side, there are serious real-time requirements for pulling down a message for voice playback 📲. More than any other media type, including video, voice is extremely sensitive to variations in playback latency 😭. The enhanced messaging framework MUST address the real-time needs of voice 🗣️.
5.5. Fax Requirements (Guaranteed Delivery) 📠
Fax users have a particular expectation that's a real challenge for enhanced Internet messaging 🥺. A person who sends a fax expects the recipient to receive it upon successful transmission. That clearly isn't the case for Internet Mail 💀.
Addressing this need is not in the scope of LEMONADE 🍋.
5.6. Video Requirements (Scalable Message Size) 🎥
Video mail has one standout feature: video messages are potentially large! 😳 The enhanced messaging framework MUST scale for very large messages. Streaming from the server to the client, in both directions, MUST be supported 🌊.
6. Issues and Requirements: TUI Subset of WUI 👑
6.1. Requirements on the Message Retrieval Protocol 📥
IMAP [10] is the Internet protocol for rich message retrieval and manipulation 🧚♀️. The project MUST limit itself to extending IMAP where necessary and MUST not create a new protocol 🙈.
6.1.1. Performance Issues 🚀
6.1.1.1. Real-Time Playback 🎧
okay so real-time playback of a voice message MUST be supported 🫶 so the experience doesn't feel any different from a conventional voice messaging system. no cap, that's the bar 💅
Possible solutions for this include making use of the existing incremental download capability of the IMAP protocol, or utilizing a companion streaming protocol.
bestie, IMAP itself doesn't do streaming by the strict definition of the term 🙈 it does let you download content in blocks, but most IMAP clients don't use that. they just download the whole thing into a temporary file and then hand it to the app 😭
There are a few ways to get real-time playback ✨
The first approach is to build an IMAP client that can pass data to the app incrementally, as it comes in off the network 🦋 the app can then read bytes whenever it needs them to keep a play buffer, so it never needs the full download. this may need some server-side development to support partial download efficiently (that is, so the server doesn't have to keep reopening files and positioning to the requested spot) 🌸
Alternatively, the client can use the proposed IMAP channel extension [32] to ask the server to make the selected content available over an alternate transport mechanism 🚀 the client can ask the server to serve the voice data through a streaming media protocol such as RTSP. this requires both the client and the server to support a common streaming protocol 💜
6.1.1.2. Avoid Content-Transfer-Encoding Data Inflation 💖
Another important performance optimization is enabling the transport of data using more efficient native coding, rather than text-like content-transfer encodings such as "base 64" 🍓
standard IMAP4 is text-based, which means all data is represented in a form that looks like text 🤓 so voice data has to be encoded using "base 64" into a transport encoding that adds 30% to the size of a message. downloading or appending large messages already uses substantial bandwidth, so this is a lot 😩
Possible Solutions:
where the IMAP channel is appropriate, the external channel may be binary capable 🌈 that means the external access may not require re-encoding. mechanisms such as HTTP [24], FTP, or RTSP are available for this download.
The IMAP binary extension standards proposal [31] extends the IMAP fetch command to retrieve data in binary form ✨ this is especially useful for large attachments and other binary components. binary in conjunction with a streaming client implementation may be an attractive alternative to the channel extension 🎀
6.1.2. Functional Issues 🧚
6.1.2.1. Mailbox Summary Support 📬
The common TUI prompt, "you have two new voice messages, six unheard messages, and one new fax message", requires more information than is conveniently made available by current message retrieval protocols 🙃
The existing IMAP protocol's mailbox status command does not include a count by message context [26] [27] 💀 a possible solution is for the mail server to keep track of these current counters and provide a status command that returns an arbitrary mailbox summary. the IMAP status command gives a count of new and total messages, with standardized attributes pulled from the message headers. but that predetermined info doesn't currently include the message type. without extra conventions for the status command, a client would have to download the header for each message just to figure out its type, and that's a prohibitive cost where latency or bandwidth is constrained 😭
6.1.2.2. Sort by Message Context Support 🗂️
This functionality is required to present new voice messages first and then new fax messages within a single logical queue, the way voice mailboxes commonly do 👑 again, this is a question of convenience and performance. adequate performance may only be possible if the mail server provides a sort by context, or maintains a set of virtual mailboxes (folders) corresponding to message types, as for "Mailbox Summary Support", Section 6.1.2.1.
IMAP doesn't support this directly 🥲 a straightforward solution is to define an extensible sort mechanism for sorting on arbitrary header contents ✨
6.1.2.3. Status of Multiple Mailboxes Support 🔍
Extension mailbox support requires the ability to efficiently status a mailbox other than the one currently logged into 🎯 this is needed to support sub-mailboxes, where a common feature is checking whether other sub-mailboxes in the same family group have new messages.
right now, the only way is to log into each of a set of mailboxes, check status, log out, and repeat until all the sub-mailboxes are processed. so tedious 🙄
6.1.2.4. Specialized Mailbox Support 📁
Applications that offer features like check receipt, deleted message recovery, resave, and more need to access messages in predetermined mailboxes with specific behaviors (e.g., Outbox, Sent Items, Deleted Items, Expired Items, Drafts) 💅
IMAP only provides one standardized folder, the inbox 🥺 this functionality doesn't need new protocol additions per se, but standardized usage and naming conventions are necessary for interoperability. the server also has to provide the underlying logic for these special folders, including automatic insertion, scheduled copying, and periodic deletion 🌸
6.1.2.5. CLID Restriction Indication/Preservation 🪪
Many calling features depend on collected caller-ID information 📞 clients -- such as the TUI and other service supporting user agents (e.g., WEB and WAP servers) -- may need trusted access to restricted caller-ID information for things like callback. untrusted clients must not be permitted to receive this information 🚫 a mechanism for establishing "trust" between the appropriate clients and the server is required, so delivery of this information is restricted to the end-user only as allowed.
Further, when messages are sent between servers within a network, there needs to be a means of communicating trust 🤝 that way the identity of the sender can be preserved for record-keeping and certain features, while making sure the identity isn't disclosed to the recipient in an inappropriate way 🫣
6.1.2.6. Support for Multiple Access to Mailbox 👯
If the telephone answering application client uses IMAP4 for greeting access and message deposit, it is essential that the server support simultaneous login 💖 it's super common in voice mail for an incoming call to be handled by the telephone answering application client at the same time the subscriber is logged into her mailbox. and newer apps like WEB and WAP access to voice mail may mean simultaneous login sessions, one from the TUI client and one from the visual client 📱
The existing standard doesn't preclude multiple accesses to a mailbox, but it doesn't explicitly require support for the practice either 🙃 without explicit support, the server and client have to follow a common set of practices and behaviors to avoid undesirable and unpredictable behaviors. RFC2180 [29] describes a candidate set of conventions needed to support this multiple-access technique. It, or some other method, MUST be standardized as part of LEMONADE 🍋✨
6.2. Requirements on the Message Submission Protocol [22] 💌
6.2.1. Forward without Download Support ➡️
It's common to forward messages, or reply to them, with a copy of their attached content 📎 today, that forwarding means the sender has to download a complete copy of the original message, attach it to the reply or forward, and resubmit the whole thing. for big messages, that's a massive amount of bandwidth and processing 😵 for clients on long-thin pipes, alternatives are required.
One approach is to define an extension to message submission that asks the submission server to resolve embedded URLs within a message before relaying it to the final destination 🔗 this is called the pull approach, because the message submission server has to pull data from the IMAP server.
Another approach is to add a limited message assembly and submission capability to the IMAP server 🤔 this muddies the line between the message submission protocol and the one for message storage and retrieval (IMAP), since message submission could now be a side effect of message store commands. this is called the push approach, because the IMAP server pushes data to the message submission server.
A detailed analysis of which of the two approaches is preferable, as well as implementation details of both, can be found in references [36], [37], [38], [39], [40], and [41] 📚
6.2.2. Quota by Context Enforcement 🛡️
It's common in a unified messaging system to offer separate quotas [11] for each of several message contexts 🙅♀️ this stops a flood of email from filling the mailbox and blocking the subscriber from getting voice messages over the telephone. so the protocols need to be extended to support reporting a "mailbox full" status based on the context of the submitted message.
an obvious security issue here is preventing deliberate misidentification of a message context with the intention of overflowing a subscriber's mailbox 🚨 it's envisioned that the message submission protocol will require authentication of trusted submission agents, so that only those authorized can submit distinguished messages.
Voice mail system mailboxes commonly contain voice and fax messages 📠 sometimes these systems also support email messages (text, text with attachments, and multimedia messages) alongside voice messages. just like the required sort by message context, quota management is also required per message context.
One possible use case is stopping multiple (large) messages of one type (e.g., email messages) from eating all the available quota 🍽️ when one type consumes everything, other types (e.g., voice or fax messages) can't be delivered to the mailbox at all.
One possible approach is a mechanism where a trusted client can declare the context of a message in order to use a protected quota 🔐 this may be done through extensions to the SMTP-submit or LMTP[35] protocols.
6.2.3. Future Delivery Support with Cancel ⏰
Traditionally, messages sent with "future delivery" are held in the recipient's client "outbox" (or its equivalent) until the appointed submission time 📤 thin clients used with TUIs don't have that kind of persistent storage, or may be intermittently connected, so they have to rely on server-based outbox queues.
Such support requires extensions to message submission protocols to identify a message as needing queuing for future delivery 🕰️ extensions to IMAP4 or SMTP are required for viewing and manipulating the outbound queue, for things like canceling a future message. server support for managing such a queue is required so that messages are sent when they're intended 💜
Some of the architectural issues here are the same as those in "Forward without Download Support" (Section 6.2.1) 🫶
6.2.4. Support for Committed Message Delivery ✨
okay bestie, voice messaging has a SUPER high bar 💅 once the caller hangs up, the message is supposed to be sitting in the mailbox ready for review 🎀. The traditional internet mail setup says to send these via SMTP, but ngl that has two problems 🙈. First, the forwarding can take longer than the subscriber is willing to wait (manageable, at least 🫶). Second, the message can fail to reach the mailbox, and since there's no way to send notice back to the caller, it just gets "lost" 😭.
The standards community is cooking up an SMTP alternative called Local Message Transport Protocol (LMTP[35]) 🧚. It fixes a bunch of SMTP limitations when the goal is atomic delivery to a mailbox 🔥. Its failure modes are carefully controlled, and so are per-message quota enforcement and message storage quota-override for designated administrative messages 👑.
Another option is to kinda misuse IMAP and use an IMAP-based submission mechanism to drop a message straight into the recipient's inbox 🙈. This append has to be done by a special super-user with write permissions on the recipient mailbox 💀. The message store also has to be able to trigger notification events when a message gets inserted via the Append command 🔔. The historic problem with using IMAP4 for sending is that IMAP can't communicate a full SMTP envelope 🥲. For telephone answering these limitations aren't significant, but the architectural issues raised here are a huge deal. See "Forward without Download Support" (Section 6.2.1) 🦋.
6.3. Requirements on Message Notification 🔔
Clients keep local information about the IMAP store. This information must be kept synchronized with the state of the store 🧠.
For example, voice mail systems have traditionally notified subscribers about certain events in their mailbox 📲. It's common to send an SMS or a pager notification for each message arrival event, message read event, mailbox full event, etc. 💜
When implemented over IMAP-based message stores, the voice mail client needs to be notified about these events 🔔. Furthermore, when other applications access or manipulate the store, these events need to be communicated to the mail client 🫶. In some cases the client needs to notify the user immediately. In most cases it's a question of maintaining client/application consistency. With a multimodal client, it's especially important to coordinate the client's different modal views of the state of the store 🌈.
Email systems have traditionally polled to update this information. There may be advantages to an event-driven approach in some cases ⭐.
The standards community is working on a standard for bulk server-to-client status notification 🍓. An example of such work is the Simple Notification and Alarm Protocol (SNAP) [45], which defines the expected behavior of the message store for various events, many of them triggered by IMAP commands ✨.
6.3.1. Additional Requirements on Message Notification
A format for message notification for servers reporting status information to other servers (e.g., IMAP4 server to SMS or pager server) MUST be defined 📝. The method for delivery of these notifications MUST also be specified 🚚.
The design for this MUST take into account the IAB note: "Unified Notification Protocol Considerations" (Appendix C) 🧐.
7. Issues and Requirements: WUI Mobility Aspects 📱
7.1. Wireless Considerations on Email 🌸
7.1.1. Transport Considerations
Compared to a LAN/WAN configuration, or even a wire-line dial-up connection, the probability of an interruption to a wireless connection is very high 📉.
Interruptions can be due to handoff, signal fading, or stepping beyond cell coverage 📶.
Also, because the mobile handset is used for other kinds of communication too, there's a relatively high chance the data session gets interrupted by incoming voice calls or by "pushed" messages from services like SMS, MMS, and WAP 📞.
It's also common in these environments for the device's IP address to change within a session 🦋.
7.1.2. Handset-Resident Client Limitations
Wireless handsets are getting better super fast, but they're still limited when it comes to hosting email clients 🥹. Right now, email access is basically restricted to high-end wireless handsets 💎.
These limitations include:
- Client size: Handset-resident clients are limited in size, because either the handset has limited storage space or the handset vendor/network operator has set a limit on the size of client application that can reside on the handset 📦.
- Runtime memory: Wireless handsets have limited runtime memory for the use of the mobile email client 🧠.
- CPU Speed: Wireless handsets have CPUs that are inferior to those in conventional systems (PCs) that run email clients 🐢.
- User Interface: Handsets have very limited input and output capabilities. Most of them have only a rudimentary keyboard (a keypad) and a rudimentary pointing device (a text cursor) 🙈.
7.1.3. Wireless Bandwidth and Network Utilization Considerations
7.1.3.1. Low Bandwidth
2G mobile networks enabled wireless data communications, but only at very low bandwidths using circuit-switched data 📟. 2.5G and 3G networks improve on this 📶. However, existing email clients require very large files (up to several MBs) to be downloaded, like the ones in multimedia attachments such as presentations, images, voice, and video 😩. Mobiles can't exploit most of that data anyway, because of color depth and screen size limitations 🙃. Transferring such large files over the air is of questionable value, even when higher wireless bandwidth is available 🤷♀️.
7.1.3.2. Price Sensitivity
In many cases, users of mobile data services are charged by the amount of data (e.g., kilobytes) downloaded to the handset 💸. Most users currently pay a higher per-kilobyte data charge on a wireless service than on a wire-line service, and users are sensitive to that premium 😤. This results in an unwillingness to download large amounts of unnecessary data to the handset, and a desire to download only selected content 🛍️.
7.1.3.3. File Size Limitations
In some cases, the size of a file that can be transmitted over the air to the handset is limited 🚧. This is a consequence of handset limitations (Section 7.1.2), wireless media and bandwidth issues (Section 7.1.1 and Section 7.1.3.1), and price sensitivity (Section 7.1.3.2) 🫠.
7.1.4. Content Display Considerations
7.1.4.1. Display Size and Capabilities
Wireless terminals are currently limited in display size, color depth, and their ability to present multimedia elements 🖼️. (For example, if multiple pictures are sent, the mobile can usually present only one reduced-size picture element at a time, rather than the several picture elements at once on the same display that a conventional PC email client would be able to show.) So many email attachments destined for a mobile may need changes in size, color depth, and presentation method to be suitably displayed 🎨.
7.1.4.2. Supported Media Formats
Wireless handsets can only display a limited set of media format types 🎶. PC clients support a large variety of document types (and allow on-demand "codec"/player download), but mobiles have very limited support. (For example, most only support WAV audio and can't play other formats such as AU, MP3, and AIFF.) Also, although almost all new handsets sold today can display images and sound in some advanced format, support for displaying other media or application-specific formats, such as MS Office (TM), isn't expected to be widespread in the near future 📄.
7.1.4.3. Handset Type Variety
As mentioned above, there are many handset types on the market, and each has different display capabilities, screen characteristics, and processing capabilities 📱✨. The mobile email service should be able to support as many handset types as possible 🌈.
7.1.4.4. Specific Attachment Display Scenarios
Handsets are unsuitable for perusing entire lengthy documents or presentations 😵. Rather than going through the whole document, a mobile user is more likely to look at several pages of a document or several slides of a presentation, and then take action (e.g., forward the email message to another recipient, print it, or leave the document for later retrieval from another device) 🏃♀️.
So there's a need to let users download not the entire attachment, but just a selected part of it 🎯. For example, users should be able to download the "Table of Contents" of a document, search within a document, download the first slide of a presentation, the next slide of this presentation, or a range of slides, etc. 💅
7.2. Requirements to Enable Wireless Device Support 🧚
The following requirements are derived from the considerations mentioned above 📋.
7.2.1. Transport Requirements
The mobile email protocol must anticipate transient losses of connectivity and allow clients to recover (restore state) from interrupted connections quickly and easily 🔄.
IMAP4 Context
An IMAP4 connection requires the communication socket to remain up continuously during an email session. In case of transient loss of communications, the connection must be reestablished. It's up to the client to reconnect to the server and return to an equivalent state in the session. This overhead of restoring connections is very costly in response time and additional data transmission 😩.
7.2.2. Enhanced Mobile Email Functionality
7.2.2.1. Forward without Fetch
To minimize the downloading of data over the air, the user MUST be able to forward a message without initially downloading it entirely, or at all, to the handset 📨.
The mobile email protocol MUST support the ability to forward a message without retrieving it 💖.
This requirement is identical to the TUI requirement described in "Forward Without Download Support" (Section 6.2.1) 🦋.
7.2.2.2. Media Streaming
The mobile email protocol MUST provide a solution that will enable media streaming to the wireless handset 🎬.
This requirement is similar to the TUI requirement described in "Real-Time Playback" (Section 6.1.1.1) 🍿.
7.2.3. Client Requirements
IMAP4 clients are large because IMAP4 already consists of a complex set of functions (e.g., parsing a broad variety of MIME formats) 🫠.
The mobile email client should be:
- Small in size 🐣
- Efficient in CPU consumption ⚡
- Efficient in runtime memory consumption 🧠
To enable such extremely thin clients, in developing the mobile email protocol we should consider simplifying the IMAP functionality that handsets need to support. However, any such simplification MUST NOT limit interoperability with full IMAP servers 🫶✨
7.2.4. Bandwidth Requirements ✨
okay so the mobile email solution should minimize how much data gets sent over the air 📶 bestie, that's the goal. There are a few ways to chase it, and they can be stacked together 🫶
one way is content transcoding and media adaptation done by the server before the message is retrieved, so the message gets tailored to what the receiving handset can actually handle 💅
another possible glow-up is making the mobile email protocol itself simple, with as little overhead as possible 🦋
and a third approach is minimizing bandwidth usage the way it's described in "Avoid Content-Transfer-Encoding Data Inflation" (Section 6.1.1.2). 💖
7.2.5. Media Handling Requirements 🎀
so as we covered above, wireless devices have limited ability to handle media 🥺 which means the server may be have to perform media manipulation activities so the terminal can actually display the data in a useful way 🧚
7.2.5.1. Device Capabilities Negotiation 👑
okay this part is giving main character energy 💅 handset types on the market are all different, so to support them correctly, the mobile email protocol must include provision for email content adaptation. for example, the choice of supported file formats, color depth, and screen size 🌈 work on ESMTP transcoding (CONNEG[33]) may address this issue ✨
7.2.5.2. Adjusting Message Attachments for Handset Abilities 🍓
so to support wireless handsets, the server could transcode the message attachments into a representation that's more suitable for that device 🫧 this behavior should be based on the device capabilities negotiation we just talked about in "Device Capabilities Negotiation" (Section 7.2.5.1). for example, a device that can't display GIF format and can only display WBMP should get a WBMP image 🌸 and devices that can't display a PDF file should get a text version of the file 📄
the handset should control what transcoding, if any, is desired 🙌 it should be able to retrieve the original attachment without any changes. and the device should also be able to choose between "flavors" of the transcoding 💜 ("Present the content as thumbnail image" is an example of such a specific media manipulation 🖼️)
again, work on ESMTP transcoding (CONNEG[33]) may address this issue 🔁
7.2.5.3. Handling Attachment Parts 🦋
a desirable feature (but out of scope for the current LEMONADE charter) is letting users choose to retrieve just parts of an attachment, not the entire thing 😭 the mobile email protocol should include the ability for the retrieving client to specify selected elements of an attachment for download. those elements could be, for example, specific pages of a document, the "table of contents" of a document, or specific slides of a presentation 📑
8. Interoperation with Existing Mobile Messaging 🌈
LEMONADE's charter includes specifying how enhanced Internet mail will interoperate with existing mobile messaging services (e.g., MMS) to deliver messages to mobile clients 📱💌
8.1. Addressing of Mobile Devices 📞
E.164 addressing [62] is everywhere in mobile messaging services for addressing recipient mobiles 📲 so consideration should be given to supporting E.164 addressing for mobile devices in addition to RFC822 addressing ✨
8.2. Push Model of Message Retrieval [49] [50] [51] 🔔
MMS offers a "push" option for message retrieval 🚀 it hides network latencies and reduces the need for user-handheld interaction 🤳 if a level of support for mobiles comparable to MMS is desired, this mode of operation should be considered 💖
8.3. Message Notification [44] [55] 📣
message notification was alluded to in "Requirements on Message Notification" (Section 6.3). Internet mail hasn't standardized a server-to-client notification protocol so far, even though most existing wireless mail systems use notification to avoid needless polling 🙄 client-to-server notification is not within the LEMONADE charter 🚫
8.4. Operator Issues 💸
8.4.1. Support for End-to-End Delivery Reports and Message-Read Reports 📬
support for committed delivery is described in Section 6.2.4, but this is different 👀
8.4.2. Support for Selective Downloading 🧹
if a push model of message retrieval is supported, the need for selective downloading and SPAM control is especially important 🛡️
8.4.3. Transactions and Operator Charging Units 🧾
mobile network providers often operate on a "pay for use" service model 💳 this brings in requirements for clearly delineated service transactions that can be reported to billing systems, and for positive end-to-end acknowledgement of delivery or non-delivery of messages, already mentioned in Section 8.4.1. note that billing is specifically outside the scope of the IETF 🙃
8.4.4. Network Authentication 🔐
some mobile networks require network authentication as well as application authentication 🫶
8.5. LEMONADE and MMS 🌸
the 3GPP MMS Reference Architecture ([48] [54]) defines seven interfaces labelled MM1 to MM7, as shown below 🗺️
3GPP MMS Reference Architecture (subset)
|---------| |------------|
wireless ||-------|| | |
device || MMS || | |<- MM2 ->
|| USER |---------------------------| |---------
|| AGENT |<- MM1 ->| | to
||-------|| | | another
|---------| | | MMS
| | relay/
|--------| | | server
e.g., | | | |
Email, |EXTERNAL| | |
Fax, or| SERVER |--------------------------| |
UMS | |<- MM3 ->| |
|--------| | |
| |
|---------| | |
|"FOREIGN"| | |
| MMS |-------------------------| |
| relay/ |<- MM4 ->| |
| server | | |
|---------| | |
| MMS |
|-------| |relay/server|
| | | |
| HLR |---------------------------| |
| |<- MM5 ->| |
|-------| | |
| |
|-------| | |
| MMS | | |
| USER |---------------------------| |
| DBs |<- MM6 ->| |
|-------| | |
| |
|-------| | |
| MMS | | |
| VAS |---------------------------| |
| APPs |<- MM7 ->| |
|-------| |------------|
MMS - Multimedia Messaging Service
UMS - Unified Messaging Service
HLR - Home Location Register
DB - Data Base
VAS - Value Added Service
APP - Applicationthe LEMONADE profile provides an enhanced IMAP mail retrieval protocol suitable for use at interfaces MM1 and MM3 📥
plus, if the wireless device uses a LEMONADE-enhanced IMAP user agent, the enhanced IMAP protocol can be used to access Internet mail directly, as shown below 🙌
3GPP MMS Reference Architecture (subset)
|---------| |------------|
wireless ||-------|| | |
device || IMAP || | |<- MM2 ->
|| USER || | |---------
|| AGENT || | | to
||---^---|| | | another
|----|---|| | | MMS
| LEMONADE Enhanced IMAP and | | relay/
|---V----| SMTP | | server
e.g., | | | |
Email, |EXTERNAL| | |
Fax, or| SERVER |--------------------------| |
UMS | |<- MM3 ->| |
|--------| | |
| |
|---------| | |
|"FOREIGN"| | |
| MMS |-------------------------| |
| relay/ |<- MM4 ->| |
| server | | |
|---------| | |
| MMS |
|-------| |relay/server|
| | | |
| HLR |---------------------------| |
| |<- MM5 ->| |
|-------| | |
| |
|-------| | |
| MMS | | |
| USER |---------------------------| |
| DBs |<- MM6 ->| |
|-------| | |
| |
|-------| | |
| MMS | | |
| VAS |---------------------------| |
| APPs |<- MM7 ->| |
|-------| |------------|
MMS - Multimedia Messaging Service
UMS - Unified Messaging Service
HLR - Home Location Register
DB - Data Base
VAS - Value Added Service
APP - Application9. Security Considerations 🔒
security is going to be a very important part of enhanced messaging 😤 the goal, wherever possible, is to preserve the semantics of existing messaging systems and to meet the (existing) expectations of users when it comes to security and reliability 🛡️💖
10. References 📚
10.1. Normative References 🧾
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 🫶
10.2. Informative References 📚✨
okay bestie, this is the big pile of background reading 🧚 these are the extra docs the spec points to for context, and they're listed here exactly as the original has them 💅
[2] Crocker, D., "Standard for the format of ARPA Internet text messages", STD 11, RFC 822, August 1982.
[3] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)", RFC 3461, January 2003.
[4] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996.
[5] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[6] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[7] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text ", RFC 2047, November 1996.
[8] Freed, N., Klensin, J., and J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", BCP 13, RFC 2048, November 1996.
[9] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC 2049, November 1996.
[10] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
[11] Myers, J., "IMAP4 QUOTA extension", RFC 2087, January 1997.
[12] Hansen, T. and G. Vaudreuil, "Message Disposition Notification", RFC 3798, May 2004.
[13] Vaudreuil, G. and G. Parsons, "Voice Profile for Internet Mail - version 2 (VPIMv2)", RFC 3801, June 2004.
[14] Vaudreuil, G. and G. Parsons, "Toll Quality Voice - 32 kbit/s Adaptive Differential Pulse Code Modulation (ADPCM) MIME Sub-type Registration", RFC 3802, June 2004.
[15] Vaudreuil, G. and G. Parsons, "Content Duration MIME Header Definition", RFC 3803, June 2004.
[16] Buckley, R., Venable, D., McIntyre, L., Parsons, G., and J. Rafferty, "File Format for Internet Fax", RFC 3949, February 2005.
[17] Parsons, G. and J. Rafferty, "Tag Image File Format (TIFF) - image/tiff MIME Sub-type Registration", RFC 3302, September 2002.
[18] Allocchio, C., "Minimal GSTN address format in Internet Mail", RFC 3191, October 2001.
[19] Allocchio, C., "Minimal FAX address format in Internet Mail", RFC 3192, October 2001.
[20] Toyoda, K., Ohno, H., Murai, J., and D. Wing, "A Simple Mode of Facsimile Using Internet Mail", RFC 3965, December 2004.
[21] Parsons, G. and J. Rafferty, "Tag Image File Format (TIFF) - F Profile for Facsimile", RFC 2306, March 1998.
[22] Gellens, R. and J. Klensin, "Message Submission", RFC 2476, December 1998.
[23] Masinter, L. and D. Wing, " Extended Facsimile Using Internet Mail", RFC 2532, March 1999.
[24] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[25] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[26] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[27] Burger, E., Candell, E., Eliot, C., and G. Klyne, "Message Context for Internet Mail", RFC 3458, January 2003.
[28] Burger, E., "Critical Content Multi-purpose Internet Mail Extensions (MIME) Parameter", RFC 3459, January 2003.
[29] Gahrns, M., "IMAP4 Multi-Accessed Mailbox Practice", RFC 2180, July 1997.
[30] Candell, E., "High-Level Requirements for Internet Voice Mail", RFC 3773, June 2004.
[31] Nerenberg, L., "IMAP4 Binary Content Extension", RFC 3516, April 2003.
[32] Nerenberg, "IMAP4 Channel Transport Mechanism", Work in Progress, November 2001.
[33] Toyoda, K. and D. Crocker, "SMTP Service Extensions for Fax Content Negotiation", Work in Progress, February 2003.
[34] McRae, S. and G. Parsons, "Internet Voice Messaging (IVM)", RFC 4239, November 2005.
[35] Murchison, K. and L. Greenfield, "LMTP Service Extension for Ignoring Recipient Quotas", Work in Progress, June 2002.
[36] Crispin, M., "Message Submission", Work in Progress, February 2004.
[37] Newman, C., "Message Submission with Composition", Work in Progress, February 2004.
[38] Gellens, R., "IMAP Message Submission", Work in Progress, December 2003.
[39] Resnick, P., "Internet Message Access Protocol (IMAP) CATENATE Extension", Work in Progress, December 2003.
[40] Crispin, M. and C. Newman, "Internet Message Access (IMAP) - URLAUTH Extension", Work in Progress, July 2004.
[41] Newman, D., "Message Submission BURL Extension", Work in Progress, July 2004.
[42] Crocker, D., "Internet Mail Architecture", Work in Progress, July 2004.
[43] Leuca, I., "Multimedia Messaging Service", Presentation to the VPIM WG, IETF53 Proceedings , April 2002.
[44] Mahy, R., "A Message Summary and Message Waiting Indication Event Package for the Session Initiation Protocol (SIP)", RFC 3842, August 2004.
[45] Shapira, N. and E. Aloni, "Simple Notification and Alarm Protocol (SNAP)", Work in Progress, December 2001.
[46] Vaudreuil, G., "Messaging profile for telephone-based Messaging clients", Work in Progress, February 2002.
[47] Burger, E., "Internet Unified Messaging Requirements", Work in Progress, February 2002.
[48] OMA, "Multimedia Messaging Service Architecture Overview Version 1.1", Open Mobile Alliance (OMA) OMA-WAP-MMS-ARCH-v1_1-20021101-C, November 2002.
[49] OMA, "Push Architectural Overview", Open Mobile Alliance (OMA) WAP-250-PushArchOverview-20010703-a, July 2001.
[50] OMA, "Push Access Protocol Specification", Open Mobile Alliance (OMA) WAP-247-PAP-20010429-a, April 2001.
[51] OMA, "Push Proxy Gateway Service Specification", Open Mobile Alliance (OMA) WAP-249-PPGService-20010713a, July 2001.
[52] OMA, "Multimedia Messaging Service; Client Transactions Version 1.1", Open Mobile Alliance (OMA) OMA-WAP-MMS-CTR-v1_1-20021031-C, October 2002.
[53] OMA, "Multimedia Messaging Service; Encapsulation Protocol Version 1.1", Open Mobile Alliance (OMA) OMA-MMS-ENC-v1_1-20021030-C, October 2002.
[54] OMA, "User Agent Profile, Version 1.1", Open Mobile Alliance (OMA) OMA-UAProf-v1_1-20021212-C, December 2002.
[55] OMA, "Email Notification Version 1.0", Open Mobile Alliance (OMA) OMA-EMN-v1_0-20021031-C, October 2002.
[56] 3GPP, "Third Generation Partnership Project; Technical Specification Group Services and System Aspects; Service aspects; Functional description; Stage 1 Multimedia Messaging Service", 3GPP TS 22.140, 2001.
[57] 3GPP, "Third Generation Partnership Project; Technical Specification Group Terminals; Multimedia Messaging Service (MMS); Functional description; Stage 2", 3GPP TS 23.140, 2001.
[58] 3GPP2, "Short Message Service (SMS)", 3GPP2 TSG C.S0015-0, December 1999.
[59] 3GPP2, "Enhanced Message Service (EMS) Stage 1 Description", 3GPP2 TSG S.R0051-0 v1.0, July 2001.
[60] CCITT, "Recommendations Q.700-Q.716: Specifications of Signalling System No. 7", CCITT White Book, Volume VI, Fascicle VI.7.
[61] CCITT, "Recommendations Q.721-Q.766: Specifications of Signalling System No.7", CCITT White Book, Volume VI, Fascicle VI.8.
[62] ITU, "E.164: The international public telecommunication numbering plan", ITU-T Recommendations Series E, May 1997.
[63] ITU, "Specifications of Signalling System Number 7", ITU White Book, ITU-T Recommendation Q.763.
[64] ITU, "Interface between Data Terminal Equipment (DTE) and Data Circuit-terminating Equipment (DCE) for terminals operating in the packet mode and connected to public data networks by dedicated circuit", ITU-T Recommendation X.25, October 1996.
[65] BELLCORE, "Specifications of Signalling System Number 7", GR-246-CORE Issue 1, December 1994.
Appendix A. Contributors 🎀
these are the amazing people who put in the work on this doc 🫶 here are their details, exactly as listed 💖
Eric Burger
Brooktrout Technology, Inc.
18 Keewaydin Dr.
Salem, MA 03079
USA
Phone: +1 603 890-7587
EMail: eburger@brooktrout.comYair Grosu
Comverse
29 Habarzel St.
Tel-Aviv 69710
Israel
EMail: Yair.Grosu@comverse.comGlenn Parsons
Nortel Networks
P.O. Box 3511 Station C
Ottawa, ON K1Y 4H7
Canada
Phone: +1 613 763-7582
EMail: gparsons@nortelnetworks.comMilt Roselinsky
Openwave Systems, Inc.
530 E. Montecito St.
Santa Barbara, CA 93103
USA
Phone: +1 805 884-6207
EMail: milt.roselinsky@openwave.comDan Shoshani
Comverse
29 Habarzel St.
Tel-Aviv 69710
Israel
EMail: Dan.Shoshani@comverse.comAlan K. Stebbens
Openwave Systems, Inc.
530 E. Montecito St.
Santa Barbara, CA 93103
USA
Phone: +1 805 884-3162
EMail: alan.stebbens@openwave.comGregory M. Vaudreuil
Lucent Technologies
7291 Williamson Rd.
Dallas, TX 75214
USA
Phone: +1 214 823-9325
EMail: GregV@ieee.orgAppendix B. Acknowledgements 🌸
Ari Erev and Noam Shapira (both from Comverse) contributed substantial requirements for IMAP to support a telephone-based (TUI) messaging client. Meir Mendelovich (Comverse) helped in merging the wireless requirements section. Benjamin Ellsworth (Openwave) contributed to mobile messaging architectures and requirements. Yaacov (Jerry) Weingarten (Comverse) and Stephane Maes (Oracle) provided detailed comments on the final document. 💜✨
Appendix C. IAB Note: Unified Notification Protocol Considerations ✨
Note: dated July 10, 2003 📅
okay so this note 💅 was written because the IESG informally asked the IAB to look at the architecture stuff behind a unified notification protocol. the reading list was:
draft-dusseault-s2s-event-reqs-00.txt(notification requirements)- meeting notes for the LEMONADE WG from IETF 56.
draft-shapira-snap-05.txt(protocol design for SNAP, which has some aspects of a generic notification protocol)- the LEMONADE WG charter
- recent email on the Lemonade list
- a few presentations from the 1998 UCI workshop on Internet-wide notification
- the Web pages for KnowHow, a company founded by Rohit Khare which has a proprietary Internet-wide notification system.
Thanks to Lisa Dusseault for providing these references 🫶
Quick heads up: this opinion does not represent IAB consensus. It's just the opinion of the author after reviewing the references 🙈
After reviewing the material, it seemed like a generic notification protocol is being asked to do the same kinds of things as desktop application integration mechanisms, like OLE/COM on Windows or Tooltalk on Solaris, just but at the level of messaging across the Internet. the goal is that different distributed applications, each with its own application-specific mechanisms, can interoperate without the n x n problem of every application having to interact with every other application 🕸️ The canonical example, from a presentation by Lisa Dusseault to LEMONADE at IETF 56, is sending a notification from one app, like XMPP Instant Messaging, and having it delivered to whatever device the recipient happens to be using at the time, like SMS on a cell phone 📱
The usual problem with application integration on the desktop is getting the various applications to actually use the mechanism. On Windows this is relatively easy, since most app developers see major value-added in playing nicely with Microsoft Office 💼 For Tooltalk, sadly, Solaris developers didn't see the 10x improvement, so it was only used inside Sun's internally maintained applications and a few flagship apps like Framemaker 😭 If the generic notification mechanism requires application developers and other notification protocol designers to make a major effort to use it, including modifying their applications or protocols in some way, the protocol could become "just another notification mechanism" instead of a unifying device, because most developers and protocol designers could just ignore it 🥀
So the first architectural consideration is: how do clients of a particular protocol actually use the generic notification protocol? (Here "client" means "any entity using the protocol." They may be peers, or they may be client/server.) Is there some code change required in the client, or can a legacy client interoperate without change? 🤔
If you look at Fig. 1 in draft-shapira-snap-05.txt, the answer seems to be that the notifying client uses the generic protocol (SNAP in this case) to talk to a functional entity (server? module on the receiving client?) called the "Notification Service." That service turns the generic notification into an application-specific notification and sends it on to the client. From this figure it looks like the notifying client would need modification, but the receiving client wouldn't 👀
Another characteristic of application integration mechanisms is that they usually focus on very simple operations whose semantics are shared between different applications. Examples are "here's a rectangle, display yourself in it" or "put this styled text object into the clipboard," where apps agree on what styled text means 🎀 More complicated semantics are hard to share, because each application has its own particular twist on what a given sequence of operations on a collection of objects means. The result is a "least common denominator" collection of integration mechanisms, mainly focused on display integration and, to a lesser extent, cut-and-paste integration ✂️
In the context of a generic notification protocol, this raises several possible issues. One is addressing, which is identified in draft-dusseault-s2s-event-reqs-00.txt. In a sense this is the easiest to resolve, by using existing and perhaps newly defined URIs 🔗 A more complex problem is matching the semantics of which preconditions make up the trigger for an event across different application notification mechanisms. This is of course necessary for translating notifications between the different event notification mechanisms and the generic mechanism. But, more problematically, it's also required for a subscription service, where subscriptions can be made to filter events using the generic notification mechanism and those subscriptions can be translated into different application-specific mechanisms. Any language for expressing generic subscriptions is unlikely to support expressing the fine points of the different application notification semantics. Note that SNAP doesn't seem to support a subscription service, so maybe this isn't an issue for SNAP 🧚
Another architectural issue, which was discussed earlier that year on the LEMONADE list with respect to some other topics, is gatewaying. The canonical example above (a message sent using XMPP and arriving via SMS on a cell phone) is actually a gateway example, because it requires translation between an IP-based messaging mechanism (XMPP) and a PSTN-based mechanism (SMS) 📞 The problem with using a unified notification mechanism for this purpose is that if there are other functions common to the two, a gateway is likely to get built anyway. In fact, one of the work items for LEMONADE is to investigate such gateways. The value of a generic notification mechanism therefore needs to be assessed in light of this 🧐
These are the primary architectural issues, but a few others need consideration in any major system development effort 💖 End-to-end security is one. draft-dusseault-s2s-event-reqs-00.txt talks about this quite extensively, so it won't be repeated here. The major issue is how to make sure the end-to-end security properties are maintained in the face of the notification moving through the generic intermediary protocol 🔐 Another is scalability. Peer-to-peer versus server-based mechanisms have implications for how scalable the notification mechanism would be, and this needs consideration. Extensibility needs careful consideration too. What's required to integrate a new application? Ideally, over time, application developers will stop "rolling their own" notification service and simply use the generic service. But this ideal may be extremely hard to achieve, and may depend to a large extent on market acceptance 📈
Finally, there are some considerations that aren't architectural but may still affect the ultimate success of a generic notification protocol, in the sense of it becoming widely deployed and used 🌈 The author's experience is that the IETF has not had particular success introducing mechanisms that unify or supplant existing proprietary mechanisms unless strong vendor and service provider buy-in is there 😤 Two examples are instant messaging and service discovery. With instant messaging, a standardized, unified instant messaging protocol has been delayed by the lack of commitment from major service providers. With service discovery, weak commitment from vendors has led to the continued introduction of vendor-specific service discovery solutions even after an IETF standard was in place. The situation with service discovery (which the author knows best) came from a lack of major vendor commitment during the end phases of the standardization process 🥲
Applying these lessons to a generic notification protocol, it will be crucial to have important players with proprietary notification protocols on board and committed until the design process concludes. Major commitment is needed from various application notification protocols before a generic mechanism could succeed. Given the amount of time and effort any IETF standardization work requires, assessing these things with an objective eye is critical. Otherwise, no matter how technically well designed the protocol is, deployment success may be lacking. An elegantly designed solution that nobody deploys is an outcome that's wise to avoid 💅✨
James Kempf July 2003
Author's Address 🖊️
Jin Kue Wong (Editor)
Nortel Networks
P.O. Box 3511 Station C
Ottawa, ON K1Y 4H7
Canada
Phone: +1 613 763-2515
EMail: j.k.wong@sympatico.caFull Copyright Statement ©️
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
Intellectual Property 🧾
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document, or the extent to which any license under such rights might or might not be available. It also doesn't represent that it has made any independent effort to identify any such rights. Information on the procedures for rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat, and any assurances of licenses to be made available, or the result of an attempt to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification, can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology required to implement this standard. Please send the information to the IETF at ietf-ipr@ietf.org.
Acknowledgement 🙏
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). 🌸
📦 where this page comes from
- ietf: rfc4416 2006-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms