Network Working Group J.K. Wong (Ed.), Nortel Networkss Internet Draft Document: draft-wong-umcli-02.txt Category: Informational Expires: September 2003 March 3, 2003 Internet Unified Messaging Requirements to Support Diverse Clients Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract The goal of Internet Unified Messaging is to provide, over the Internet, a single infrastructure, mailbox, and set of interfaces for a user to get, respond to, and manipulate all of his or her messages from a collection of clients with varying capabilities, no matter what the media or source is. Towards this goal, this document considers what is required of Internet messaging protocols to enable the support of Unified Messaging on limited capability messaging clients. Two examples of limited capability clients are those limited to having a telephone user interface (TUI) and those that can be supported by small hand-held wireless devices with simple displays such as cell phones with data features and wireless-enabled PDAs (WUI). Included in the discussion is also a list of general principles to guide the design of Unified Messaging protocols. Discussion of this and related drafts are on the UM list. To subscribe, send the message "subscribe um" to majordomo@snowshore.com. The public archive is at http://flyingfox.snowshore.com/um_archive/maillist.html. Wong et al Informational - Expires May 2003 1 UM Requirements March 2003 1. Introduction...........................................................5 2. Internet Mail and Messaging............................................7 2.1. Mail Server........................................................7 2.2. Message Format.....................................................7 2.3. Client Access......................................................7 3. Profiles...............................................................9 3.1. Existing Profiles..................................................9 3.1.1. Voice Messaging (VPIMv2)........................................9 3.1.2. Fax.............................................................9 3.1.3. GUI.............................................................9 3.2. Profile Issues....................................................10 3.2.1. TUI............................................................10 3.2.2. WUI............................................................11 4. General Principles....................................................14 4.1. Protocol Conservation.............................................14 4.1.1. Reuse Existing Protocols.......................................14 4.1.2. Maintain Existing Protocol Integrity...........................14 4.2. Sensible Reception/Sending Context................................14 4.2.1. Reception Context..............................................14 4.2.2. Sending Context................................................14 4.3. Internet Infrastructure Preservation..............................14 4.4. Voice Requirements (enhanced security and near real-time delivery) 15 4.5. Fax Requirements (guaranteed delivery)............................15 4.6. Video Requirements (scalable message size)........................15 5. Security Considerations...............................................16 6. Detailed Requirements and Issues: TUI.................................17 6.1. Requirements on the client access (message delivery, mail retrieval) protocol...............................................................17 6.1.1. Performance Issues.............................................17 6.1.2. Functional Issues..............................................18 6.2. Requirements on the message posting (mail submission) protocol....22 6.2.1. Forward without Download Support...............................22 6.2.2. Quota by Context Enforcement...................................22 6.2.3. Future Delivery Support........................................23 Wong Informational - Expires September 2003 2 UM Requirements March 2003 6.3. Requirements on the message arrival notification protocol.........23 7. Detailed Requirements and Issues: WUI.................................24 7.1. Wireless Considerations on Email..................................24 7.1.1. Transport Considerations.......................................24 7.1.2. Handset-Resident Client Limitations............................24 7.1.3. Wireless Bandwidth and Network Utilization Considerations......24 7.1.4. Content Display Considerations.................................25 7.2. Requirements to Enable Wireless Device Support....................26 7.2.1. Transport Requirements.........................................26 7.2.2. Enhanced Mobile Email Functionality............................26 7.2.3. Client Requirements............................................27 7.2.4. Bandwidth Requirements.........................................27 7.2.5. Media Handling Requirements....................................27 8. Informative References................................................29 9. Acknowledgments.......................................................32 10. Editor's Address.....................................................33 11. Contributor's Addresses..............................................34 Wong Informational - Expires September 2003 3 UM Requirements March 2003 Conventions used in this document This document refers generically to the sender of a message in the masculine (he/him/his) and the recipient of the message in the feminine (she/her/hers). This convention is purely for convenience and makes no assumption about the gender of a message sender or recipient. FORMATTING NOTE: Notes, such at this one, provide additional nonessential information that the reader may skip without missing anything essential. The primary purpose of these non-essential notes is to convey information about the rationale of this document, or to place this document in the proper historical or evolutionary context. Readers whose sole purpose is to construct a conformant implementation may skip such information. However, it may be of use to those who wish to understand why we made certain design choices. 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]. Wong Informational - Expires September 2003 4 UM Requirements March 2003 1. Introduction Historically, a number of separate electronic messaging systems originated and evolved independently for different messaging modes. E.g. o Voice mail systems utilized a client with a telephone-based or an answering machine style of user interface. The telephone network was used for transport of voice messages. o Fax store-and-forward users interface with a fax machine using a modified telephone based interface. Fax machines also utilized the telephone network for transport. o Users interact with e-mail systems using clients supporting a variety of computer based interfaces running from single command lines to full graphical user interfaces (GUIs). When e-mail systems began, they transported only text messages over the Internet. Nowadays it is not uncommon for individuals to have to separately contend with all of these systems possibly further complicated by having a number of accounts on each. IETF e-mail standards have evolved to support additional/merged functionality: o First e-mail transport was enhanced to carry any kind of digital data o E-mail transport was enhanced so that properly enabled voice mail systems and fax machines could use the e-mail infrastructure to carry their messages over the Internet as an alternative to the telephone network. These enhancements were such that the userÆs experience of reliability, security and responsiveness were not diminished by transport over the Internet o Fax messages could be delivered by the e-mail infrastructure to properly enabled e-mail clients for presentation. As well, properly enabled e-mail clients could generate and present voice messages to be received and delivered by the e-mail infrastructure These successes in supporting what were separate client types by the common e-mail infrastructure through the use of Internet mail profiles have encouraged the vision of Internet Unified Messaging. The goal of Internet Unified Messaging is to provide, over the Internet, a single infrastructure, mailbox, and set of interfaces for a user to get, respond to, and manipulate all of his or her messages from a collection of clients with varying capabilities, no matter what the media or source is. We would like to move closer to achieving this goal by evolving toward support for a greater variety of client types. The Internet is evolving toward the support of new devices less powerful than traditional computers as hosts for messaging clients (e.g., PDAs, cellular phones, tablet computers, etc.) These hosts are less powerful both in processing power and display capabilities. They may also be connected to the network by wireless links whose bandwidth is lower and latency longer than Wong Informational - Expires September 2003 5 UM Requirements March 2003 traditional wire-line links. The purpose of this document is to specify requirements on enhancing the IETF e-mail protocols to support these terminal types. In particular, requirements will be specified for: o A TUI (telephone based client with telephone user interface) o A WUI. We will refer to a client based on a cellular phone or wireless enabled PDA as having a wireless user interface (WUI). The rest of this document is structured as follows: o A brief survey of IETF e-mail standards and their evolution o A brief survey of messaging profiles û both existing and yet to be defined o A list of principles to be used to guide the design of Internet Unified Messaging o Detailed requirements on Internet mail protocols to support TUIs and WUIs. Wong Informational - Expires September 2003 6 UM Requirements March 2003 2. Internet Mail and Messaging This section reviews very briefly protocols supporting the existing architecture for Internet Mail. 2.1. Mail Server [RFC2821] specifies the most recent version (a result of the DRUMS WG) of SMTP, which is the transport protocol between messaging servers. This document includes a description of the extension model for the SMTP protocol. |------| |------| |email | (E)SMTP |email | |server|-------------------------------|server| | | | | |------| |------| (E)SMTP: (Extended) Simple Mail Transfer Protocol (server-server) 2.2. Message Format [RFC2822] gives the current message and header format. A series of five MIME RFCs [RFC2045 to RFC2049] extend the Internet mail system to allow the transport of general media beyond just restricted text including contents generated by other applications. It also allows messages to have multi-part bodies consisting of mixed media types. 2.3. Client Access Messaging clients retrieve messages from messaging servers using either the POP3 [RFC1939] or the IMAP4 [RFC2060] protocols. The POP3 protocol assumes simple message delivery functionality on the part of the mail server. IMAP4 requires that the server can act as a remote store of messages for a client. This is an important feature for diverse client support. The message store is in the form of multiple mailboxes that the client can manipulate. Neither protocol defines message posting, which is specified by SMTP (client-server). Web based clients use http [RFC2616] for message retrieval. Wong Informational - Expires September 2003 7 UM Requirements March 2003 |---------------| |-------| RFC-822/MIME | | | | |---------------------------| MTA | | | | mail submission -> | | (E)SMTP |UI |UA | |------| |--to another | | | IMAP4, POP3 or HTTP | | | email | | |---------------------------| MS | | server |-------| <- mail retrieval | | | |---------------| mail client email server Mail client consists of: UI (User Interface) and UA (User Agent) Communication between UI and UA is proprietary Email server consists of: MS (Mail Store) and MTA (Message Transfer Agent) Communication between MS and MTA is proprietary IMAP4 - Internet Message Access Protocol version 4 POP3 - Post Office Protocol version 3 HTTP - Hypertext Transport Protocol Wong Informational - Expires September 2003 8 UM Requirements March 2003 3. Profiles A variety of client and server types other than traditional email can be supported. The clients may be adapted for host restrictions such as limited processing power, message store, display window size, etc. Alternatively clients may be adapted for different functionality (e.g. voice mail, fax, etc.). Servers may support optional mail features that would allow better handling of different media ((e.g. voice mail, fax, video, etc.). A useful way to group features that would be important to support for a particular application is to define an Internet Mail profile for that application. 3.1. Existing Profiles 3.1.1. Voice Messaging (VPIMv2) These profiles [RFC2421 to RFC2424] enable the transport of voice messages using the Internet mail system. The main driver for this work was support of IP transport for voice mail systems. As voice mail clients are accustomed to a higher degree of responsiveness and certainty as to message delivery, the functionality added by VPIMv2 includes Message Disposition Notification and Delivery Status Message as well as the addition of voice media to multi-part message bodies. 3.1.2. Fax This set of profiles [RFC2301 to RFC2306] enables the transport of fax using Internet mail protocols. This work defined the image/tiff MIME type. Support for fax clients also required extensions to Message Delivery Notification. 3.1.3. GUI Conventional e-mail clients on computers are generally GUI based. Clients on todayÆs powerful systems can support a wide variety of multimedia. In particular they can handle both voice and fax messages as shown in [IVM] and [RFC2305] respectively. Wong Informational - Expires September 2003 9 UM Requirements March 2003 (E)SMTP (client-server) |---------------| |-------| RFC-822/MIME | | | | |---------------------------| MTA | | | | mail submission -> | | (E)SMTP |GUI|UA | |------| |--to another | | | IMAP4, POP3 or HTTP | | | email | | |---------------------------| MS | | server |-------| <- mail retrieval | | | |---------------| desktop mail client email server |--end user computer--| |---network support-----| Mail client consists of: GUI (Graphical User Interface) and UA (User Agent) Communication between GUI and UA is proprietary Email server consists of: MS (Mail Store) and MTA (Message Transfer Agent) Communication between MS and MTA is proprietary IMAP4 - Internet Message Access Protocol version 4 POP3 - Post Office Protocol version 3 HTTP - Hypertext Transport Protocol 3.2. Profile Issues 3.2.1. TUI Traditional voice messaging clients have telephone-based (TUI) clients. Since a POTS phone is a totally dumb terminal, almost all of the messaging client functionality has to be provided by a user agent hosted by a computer networked to the Internet mail server. The main architectural difference between a conventional voice mail system and a unified messaging system is that the voice messaging system uses a specialized message store which is in most cases co-located on the same host as the TUI user agents while a unified messaging system has to use the generic Internet mail message store. The problem then is to be able to, in real time, stream message objects from the message store to the user interface component. The client/UA communicates with the Internet Mail server through three protocols each of which might need enhancement: o Message delivery (mail retrieval) e.g. POP3 or IMAP4 o Message posting (mail submission) SMTP (client-server) o Message arrival notification Wong Informational - Expires September 2003 10 UM Requirements March 2003 Current voice mail system implementing VPIMv2: |---------------| |-------| RFC-822/MIME | | | | |---------------------------| MTA | | | | mail submission -> | | (E)SMTP Telephone--|TUI|TUA| |------| |--to another | | | Proprietary API | | | email | | |---------------------------| MS | | server |-------| <- mail retrieval | | | |---------------| 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 Proposed UM voice mail system replaces the Proprietary API with an IETF standard protocol: |---------------| |-------| RFC-822/MIME | | | | |---------------------------| MTA | | | | mail submission -> | | (E)SMTP Telephone--|TUI|TUA| |------| |--to another | | | IETF protocol | | | um | | |---------------------------| MS | | server |-------| <- mail retrieval | | | |---------------| mail client email server |-um voice system-| |---um 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 3.2.2. WUI Wireless-based (WUI) clients (e.g. wireless enabled PDAs, cell phones, etc.) can be considered in an analogous manner to the TUI above. However, the WUI offers the potential of simultaneous voice and data Wong Informational - Expires September 2003 11 UM Requirements March 2003 (with a limited screen size) interfaces that leads to a more complex architecture. Architecturally, the WUI client can be considered the union of the TUI client with a simple GUI client with two user agent components. See below. UA1 helps maintain the text display while UA2 acts on behalf of the TUI functionality. The existence of UA2 is predicated on the assumption that the client host processor power and radio channel bandwidth are insufficient to handle the voice processing needed for text recognition or text to speech. Otherwise the situation reverts to the GUI one. The situation is perhaps simpler: It is very unlikely that separate radios would be used for carriage of the voice-band and client access links below. In this case the overhead of funneling UA1Æs messages through UA2 would be minimized and at the same time UA2 can maintain the consistency of the client state shared between UA1 and UA2. If this is the case, the WUI profile reverts to the TUI situation affecting the same three protocols as before. The extended mail client access protocol has an opportunity to be the application level protocol to be used over the air to the wireless device. Other architectures have proposed the use of more wireless specific message formats and/or application level protocols. See for instance [MMS] (this presentation overviews the 3GPP approach to a Multimedia Messaging Service (MMS)). To handle Internet Mail, this service requires messages to be transformed from native formats into specialized formats and protocols. Wong Informational - Expires September 2003 12 UM Requirements March 2003 Proposed: |wireless GUI client| e-mail server (E)SMTP (client-server) |---------------| |-------| RFC-822/MIME | | | | |---------------------------| | | | | mail submission -> | | (E)SMTP -|GUI|GUA| | |--to another | | | | IETF standard protocol |------------ | um | | | |----------------------------to MS below| | server | |-------| <- mail retrieval |------------ | | | | | 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-----| |---UM 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 UM (e-mail and voice mail) server consists of: MS (Mail Store) and MTA (Message Transfer Agent) Communication between MS and MTA is proprietary Wong Informational - Expires September 2003 13 UM Requirements March 2003 4. General Principles This is a list of principles to guide the design of Unified Messaging systems and protocols. 4.1. Protocol Conservation 4.1.1. Reuse Existing Protocols To the extent feasible, the unified messaging framework SHOULD use existing protocols whenever possible. 4.1.2. Maintain Existing Protocol Integrity In meeting requirement 4.1, the unified messaging framework MUST NOT redefine the semantics of an existing protocol. Said differently, we will not break existing protocols. 4.2. Sensible Reception/Sending Context 4.2.1. Reception Context When the user receives a message, that message SHOULD receive the treatment expected by the sender. For example, if the sender believes he is sending a voice message, voice message semantics should prevail to the extent that the receiving client can support such treatment. 4.2.2. Sending Context When the user sends a message, he SHOULD be able to specify the message context. That is, whether the network should treat the message as an Internet Mail message, voice message, video message, etc. Again, this can only be complied with to the extent that the infrastructure and receiving client can provide such treatment. In practice, this would imply that the message should be in the form desired by the sender up to delivery to the receiving client. 4.3. Internet Infrastructure Preservation A major goal for the unified messaging framework is to not change any existing Internet infrastructure. For example, the behavior of mail transfer agents (MTAs) should not change. Likewise, the behavior of existing mail clients should not change. Messages created in a unified messaging context MUST NOT require changes to existing mail clients. However, there may be a loss in service in certain circumstances. Wong Informational - Expires September 2003 14 UM Requirements March 2003 The unified messaging framework MUST be able to handle messages created in a non-unified messaging context, for example, a simple, [RFC 822] text message. 4.4. Voice Requirements (enhanced security and near real- time delivery) The expectation of voice mail users are described in [IVM] and [RFC3458]. To summarize, voice mail users have heightened expectations of privacy, delivery confirmation, and addressing than Internet Mail users. On the retrieval side, there are significant real-time requirements for retrieving a message for voice playback. More than any other media type, including video, voice is extremely sensitive to variations in playback latency. The unified messaging framework MUST address the real-time needs of voice. 4.5. Fax Requirements (guaranteed delivery) Fax users have a particular expectation that is a challenge for unified messaging. When a person sends a fax, their expectation is the user has received the message upon successful transmission. This clearly is not the case for Internet Mail. OPEN ISSUE: How will we address this? OPEN ISSUE: Do we need to address this? 4.6. Video Requirements (scalable message size) Video mail has one outstanding feature: Video messages are large! The unified messaging framework MUST scale for very large messages. Wong Informational - Expires September 2003 15 UM Requirements March 2003 5. Security Considerations Security will be a very important part of unified messaging. In addition to the security issues present in Internet Mail, people have higher expectations for Voice and Fax messaging. The goal, wherever possible, is to preserve the semantics of existing messaging systems and meet the expectations of users with respect to security and reliability. Wong Informational - Expires September 2003 16 UM Requirements March 2003 6. Detailed Requirements and Issues: TUI 6.1. Requirements on the client access (message delivery, mail retrieval) protocol Since IMAP4 is the closest existing IETF protocol in functionality to what is desired, a detailed discussion in the IMAP context will be presented after a general statement of the requirement. 6.1.1. Performance Issues 6.1.1.1. Real-Time Playback The real-time playback of a voice message must be supported so that the user experience does not differ noticeably from that of a conventional voice messaging system. Possible solutions for this include making use of the existing incremental download capability of the IMAP client access protocol, or utilizing alternate streaming protocols. This not as difficult a protocol problem if the UA host is sufficiently powerful and the bandwidth between it and the server is sufficiently great. A simple complete download and buffering scheme may produce acceptable results. IMAP Context The IMAP protocol itself does not provide streaming in the strict definition of the term. It does provide for the incremental download of content in blocks. Most IMAP clients do not support this behavior and instead download the entire contents into a temporary file to be passed to the application. There are several approaches to achieve real-time playback. The first approach is to implement an IMAP client that can pass data incrementally to the application as it is received from the network. The application can then read bytes from the network as needed to maintain a play buffer and not require the full download of contents. This approach may require server-side development to efficiently support partial download. (Avoid re-opening file and seeking to requested pointer) Alternately, the proposed IMAP channel extension can be used by the client to request that the servers make the selected content available via an alternate transport mechanism. In this way a client can ask the server to make the voice data available to the client via a streaming media protocol such as RTSP. This requires support on the client and server of a common streaming protocol. Third, given sufficient bandwidth between client and back-end data store, an implementation may download the entire contents before playing without noticeable latency. Combined with client-side caching to avoid re- fetches, this strategy may work with existing message servers. Wong Informational - Expires September 2003 17 UM Requirements March 2003 It is clear that a choice be made common to the server and the client to provide this functionality. 6.1.1.2. Avoid Base-64 Data Inflation Another possible performance optimization is allowing for the transport of data using more efficient native coding rather than the text-like "base 64" encoding. IMAP context Standard IMAP4 uses a text-based data representation scheme where all data is represented in a form that looks like text, that is, voice data must be encoded using "base 64" into a transport encoding that adds 30% to the size of a message. When downloading or appending messages to the server, substantial additional bandwidth is utilized. Proposed Solutions: Where IMAP channel is appropriate, the external channel may be binary capable; that is; the external access may not require re-encoding. Such mechanisms as HTTP, FTP, or RTSP are available for this download. The IMAP binary extension standards proposal extends the IMAP fetch command to retrieve data in the 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 client access protocols. The existing IMAP protocolÆs mailbox status command does not include a count by message type (message context). A possible solution is have the mail server keep track of these current counters and provide a status command that returns an arbitrary mailbox summary. An alternate solution is one that involves refining the mail server mailbox semantics as to include by convention a number mailboxes (folders) corresponding to message types. IMAP Context IMAP does not provide a convenient command. The IMAP status command provides a count of new and total messages with standardized attributes extracted from the message headers. This pre-determined information does not include information about the message type. Without defined conventions to the status command, a client would have to download the Wong Informational - Expires September 2003 18 UM Requirements March 2003 header for each message to determine its type. (Are flags made available through the list command? Or do they need to be queried independently?) There are standards activities directed toward defining an extensible mechanism for sending arbitrary message summary data in the LIST command [reference] or the status counters extension [reference]. With proper MTA support for the necessary message-context attribute and support for reading the flags, a single command can extract enough data to count the messages in various categories. For adequate performance, the MTA must pre-parse the messages to extract the necessary information into an index for this request as messages are deposited. Without the standards, it is possible to use multiple virtual folders to achieve similar functionality. The "inbox" can be sub-divided into virtual unheard, new, unheard fax, and new fax message sub-folders. A folder status command issued against each sub-folder would yield the appropriate count. An MTA may implement these as truly separate folders or may present these as virtual folders to the client while storing the messages in a single inbox. 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 as 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. IMAP Context IMAP does not support this directly. A straightforward solution is to define an extensible sort mechanism for sorting on arbitrary header contents. An alternative is for the client to download the headers of all messages and perform a local sort. This works where mailboxes have fewer than a couple-dozen messages. A further alternative uses separate virtual folders to hold messages of different types and status, using the client to construct the expected user experience. 6.1.2.3. Quota by Message Context Support Voice mail systems' mailboxes commonly contain voice and fax messages. Sometimes, such systems also support E-mail messages (text, text with attachments) in addition to voice messages. Similarly to the requirement for sort by message context -- quota management is also required per message context. Wong Informational - Expires September 2003 19 UM Requirements March 2003 One possible use case is to prevent multiple (large) messages of one type (e.g. E-mail messages) to consume all available quota so that messages of other type (e.g. voice or fax messages) cannot be further deposited to the mailbox. IMAP Context Again IMAP does not support this directly. One solution is to define an extension to the QUOTA IMAP command to support multiple message contexts. (In addition, there is a parallel effort to enhance the SMTP SIZE extension for the same purpose). 6.1.2.4. Status of Multiple Mailboxes Support Extension mailbox support requires the ability to efficiently status a mailbox other than the one currently logged into. This facility is required to support sub-mailboxes, where a common feature is to check whether other sub-mailboxes in the same family group have new messages. IMAP Context Current mechanisms are limited to logging into each of set of mailboxes, checking status, logging out, and repeating until all sub-mailboxes are used. 6.1.2.5. Specialized Mailbox Support Applications that provide features such as check receipt, deleted message recovery, resave, and others require the ability to access messages in pre-determined mailboxes with specific behaviors. (E.g. Outbox, Sent Items, Delete Items, Expired items, Drafts) IMAP Context IMAP provides only a single standardized folder inbox. This functionality does not require new protocol per-se, but standardized usage and naming conventions necessary for interoperability. It required that the server provide the underlying logic to support these special folders including automatic insertion, scheduled copying, and periodic deletion. 6.1.2.6. CLID Restriction indication/preservation Many calling features are dependent upon collected caller-ID information. Trusted clients such as the TUI, WUI, and WAP may have access to restricted caller-ID information for such purposes as callback. Untrusted clients must not receive this information. A mechanism for communicating "trust" between the client and the server is required to deliver this information to the end-user when appropriate. IMAP Context Wong Informational - Expires September 2003 20 UM Requirements March 2003 Some IMAP 4 servers can be configured to recognize certain clients by IP address and apply necessary CLID restriction treatment such as hiding addresses where CLI restriction has been indicated in the message. For systems operating in a closed network, the system may rely upon serving only trusted clients that protect the identity of the sender based on per-message markings. This usage requires custom proxies to use for Internet-facing services such as downloads by PC thick-clients. 6.1.2.7. Greeting Access and Play Support Voice messaging systems store multiple audio greetings files per user to play upon answering the phone. This information is logically directory information, but the size, access patterns, and streaming requirements exceed the capabilities of more directory access protocols and underlying servers. IMAP Context Rather than create a new specialized store, it is common to store greetings as messages in a hidden or special folder. As such, it is natural to use the IMAP protocol for access and update of these greetings. This provides the ability to update the greeting easily using the IMAP command. Access to the greetings requires a form of super-user access to log into the called party mailbox and extract the greeting. Through conventions, a given server or set of servers identified by IP address or login password may be granted privileged access to the mailbox contents. 6.1.2.8. Support for Committed Message Delivery Voice messaging service has provided a high degree of reliability and performance for telephone answering messages. The expectation is that once the caller has hung-up, the messages is in the mailbox and available for review. Traditional Internet mail architecture suggests these messages should be sent to the mailbox via SMTP. This approach has two limitations. The first and most manageable is that the message forwarding may take more time than is tolerable by the subscriber. The second is that the message may fail to be delivered to the mailbox, and because there is no way to return notice to the caller, the message is "lost". IMAP Context The standards community is working on an alliterative to SMTP called Local Message Transport Protocol. This protocol addresses a number of limitations in SMTP when used to provide atomic delivery to a mailbox. The failure modes in this proposal are carefully controlled, as are issues of per-message quota enforcement and message storage quota- override for designated administrative messages. Wong Informational - Expires September 2003 21 UM Requirements March 2003 An alternative approach is to misuse the IMAP protocol slightly and use an IMAP append command to deposit a message directly into the subscriber's inbox. This append must be done by a special super-user with write permissions into the subscribers mailbox. Further, the message store must be able to trigger notification events upon insertion of a message into the mailbox via the Append command. The historic limitation on using IMAP4 for message sending involves the inability of IMAP to communicate a full SMTP envelope. For telephone answering, these limitations are not significant. 6.1.2.9. 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 provide support for simultaneous login. It is common in voicemail for an incoming call to be serviced by the telephone answering application client at the same time the subscribers is logged into their mailbox. Further, new applications such as WEB and WAP access to voicemail may entail simultaneous login sessions, one from the TUI client and one from the visual client. IMAP Context The standard does not preclude multiple accesses to a mailbox, but it does not explicitly support this practice. The lack of explicit support requires the server and client to adhere to a common set of practices and behaviors to avoid undesirable and unpredictable behaviors. RFC 2180 describes a candidate set of conventions necessary to support this multiple-access technique. It is not a standard. 6.2. Requirements on the message posting (mail submission) protocol 6.2.1. Forward without Download Support It is common to forward messages, or to reply to messages with a copy of the attached content. Today such forwarding requires the sender to download a complete copy of the original message, attach it to the reply or forward message, and resubmit the result. For large messages, this represents a substantial amount of bandwidth and processing. For clients connected via long-thin pipes, alternatives are required. One approach is to define an extension to message submission to request the submission server to resolve embedded URL's within a message before relaying the message to the final destination. 6.2.2. Quota by Context Enforcement Wong Informational - Expires September 2003 22 UM Requirements March 2003 It is common in a unified messaging system to offer separate quotas for each of several message contexts to avoid the condition where a flood of email fills the mailbox and prevents the subscriber from receiving voice messages via the telephone. It is necessary to extend the protocols to support the reporting of the "mailbox full" status based on the context of the submitted message. Clear security issues are involved to prevent the mis-identification of a message context for the purpose of intentionally filling a subscribers mailbox. It is envisioned that the message submission protocol will support authentication of trusted submission agents authorized to submit distinguished messages. 6.2.3. Future Delivery Support Traditionally messages sent with "future delivery" are held in the recipients client "outbox" or equivalent until the appointed submission time. Thin clients used for WEB or TUI do not have such persistent storage and must rely upon server-based outbox queues. Such support requires extensions to message submission protocols to identify a message as requiring queuing for future delivery. Extensions to IMAP4 or conventions are required to view and manipulate the outbound queue, for such purposes as canceling a future message. Server support for managing such a queue is required such that message are sent when they are intended. 6.3. Requirements on the message arrival notification protocol Voicemail systems traditionally notify subscribers on certain events happening in their mailbox. For example, it is common to send an SMS, or a pager notification for new message arrival, when messages have been read (and are not considered "new" anymore), mailbox full etc. When implemented over IMAP-based message stores, voice mail system need to be notified about these events. Furthermore, when other applications are accessing/manipulating the mailbox, it is desirable that a notification component (which is sometimes part of the voicemail application) gets notifications from the message store about these events, so that it can produce the desired user notification. The standards community is working on a standard for "Simple Notification and Alarm Protocol (SNAP)" that defines the expected behavior of the message store for various events, much of them triggered by IMAP commands. Wong Informational - Expires September 2003 23 UM Requirements March 2003 7. Detailed Requirements and Issues: WUI 7.1. Wireless Considerations on Email 7.1.1. Transport Considerations Compared to a LAN/WAN configuration or even to a wireline dial-up connection, the probability of interruption for a wireless data connection is very high. Interruptions can be due to hand-off, signal fading, or stepping beyond cell coverage. In addition, since the mobile handset is also used for other types of communications, there is relatively high probability that the data session will be interrupted either by incoming voice calls or by "pushed" messages from services such as SMS, MMS and WAP. It is also common in these environments that device IP address change within a session. 7.1.2. Handset-Resident Client Limitations Although the capabilities of wireless handsets are rapidly improving, the wireless handset remains limited in its capability to host email clients Currently, email access is restricted to only high-end wireless handsets. These limitations include: o 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. o Runtime memory Wireless handsets have limited runtime memory for the use of the mobile email client. o CPU Speed Wireless handsets have CPUs that are inferior to those in conventional systems (PCs) that run email clients. o User Interface Handsets have very limited input and output capabilities. Most of them do not have a keyboard or a pointing device. 7.1.3. Wireless Bandwidth and Network Utilization Considerations 7.1.3.1. Low Bandwidth Wong Informational - Expires September 2003 24 UM Requirements March 2003 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 e-mail clients require very large (up to several MBs) files -- encountered in multi-media attachments such as presentations, images and documents -- to be downloaded even though the device can not exploit most of the data (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 Awareness 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 experience a higher per-kilobyte data charge with a wireless service than over a wire-line service. Users are sensitive to the premium for wireless service. This results in an unwillingness to download large amounts of unnecessary data to the handset and the desire to be able to selectively download multimedia content. 7.1.3.3. File Size Limitations In some cases, the size of file -- that can be transmitted over the air to the handset -- is limited. 7.1.4. Content Display Considerations 7.1.4.1. Display Size and capabilities Wireless terminals are currently limited in their display size, color depth, and ability to present multimedia elements (i.e. if multiple pictures are sent, the mobile can usually present only one reduced-sized picture element at a time rather than the several picture elements at once in the same display that a conventional PC email client would be able to show). Therefore many email attachments destined for a mobile may require 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. While PC clients support a large variety of document types (and enable on-demand "codec"/player download), mobiles have very limited support. (e.g., most only support WAV audio and cannot play other formats such as AU, MP3 and AIFF.) Furthermore, 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) and Acrobat PDF documents is not expected to be widespread in the near future. Wong Informational - Expires September 2003 25 UM Requirements March 2003 7.1.4.3. Handset Type Variety As mentioned above, there are many handset types available in 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 unsuited for perusing entire lengthy documents or presentations. A mobile user is more likely to look at several pages of a document or several slides of a presentation and then take action accordingly (e.g., forward the email message to another recipient, print it, or leave the document for later retrieval from another device) rather than go through the whole document. Therefore, there is a need to enable users to download not the entire attachment but rather just a selected PART of it. (e.g., users SHOULD be able to download the ôTable of Contentsö of a document; to search within a document; to download the first slide of a presentation; the next slide of this presentation; 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 quickly and easily recover (restore state) from interrupted connections. 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 is 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. Wong Informational - Expires September 2003 26 UM Requirements March 2003 The mobile email protocol MUST support the ability to forward a message without retrieving it. This requirement is similar to the TUI requirement that is described in 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 that is described in 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 of a broad variety of MIME formats). The mobile email client SHOULD be: (1) Small in size (2) Efficient in CPU consumption (3) 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 support. 7.2.4. Bandwidth Requirements The mobile email solution SHOULD minimize the amount of data transmitted over the air. One way of pursuing this goal is the use of content transcoding and media adaptation by the server before message retrieval in order to optimize it for the capabilities of the receiving handset. Another way is the mobile email protocol itself MUST be made simple and contain as little overhead as possible. A third way to minimize the bandwidth usage is described in section 6.1.1.2, "Avoid Base-64 Data Inflation". 7.2.5. Media Handling Requirements As described above, wireless devices have limited ability to handle media. Therefore, the server may be have to perform media manipulation activities to enable the terminal to display the data usefully. 7.2.5.1. Device Capabilities Negotiation Wong Informational - Expires September 2003 27 UM Requirements March 2003 In order to correctly support the different characteristics and capabilities of the various handset types available in the market, 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] may address this issue. 7.2.5.2. Adjusting Message Attachments for Handset Abilities To support limited wireless handsets, the server could transcode the message attachments into a representation that is more suitable for that device. This behavior should be based on the device capabilities negotiation as described in 7.2.5.1. For example, a device that cannot display GIF format but only WBMP should get a WBMP image. Devices that cannot display a PDF file should get a text version of the file. The handset should control what or any transcoding is desired. It should be able to retrieve the original attachment without any changes. In addition, the device should 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] may address this issue. 7.2.5.3. Handling Attachment Parts A desirable feature to have (but probably out of scope for the current lemonade charter) is the following: To enable users to retrieve not only the entire attachment file but also parts of it, the mobile email protocol should include the ability for the retrieving client to specify selected elements of an attachment for download. Such elements can be, for example, specific pages of a document, the ôtable of contentsö of a document or specific slides of a presentation. Unfortunately, such an application-specific meta-Layer 7 enhancement is unlikely in the short term. Wong Informational - Expires September 2003 28 UM Requirements March 2003 8. Informative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 [RFC2532] Masinter, L. and Wing, D., "Extended Facsimile Using Internet Mail", RFC 2532, March 1999 [IVM] McRae, S. and Parsons, G., "Internet Voice Messaging", draft-ietf-vpim-ivm-04.txt, work in progress [RFC822] Crocker, D., "Standard for the format of ARPA Internet text messages", RFC 822 (obsolete), August 1982 [RFC3458] Burger, E., Candell, E., Eliot, C., and Klyne, G., "Message Context for Internet Mail", January 2003. [UMREQS] Burger, E, "Internet Unified Messaging Requirements", , February 2002 [UMISS] Vaudreuil, Greg "Messaging profile for telephone-based Messaging clients", , February 2002 [RFC2821] Klensin, J., Editor " Simple Mail Transfer Protocol", RFC 2821, April 2001 [RFC2822] Resnick, P., Editor "Internet Message Format", RFC 2822, April 2001. [RFC2045] Freed, N. and Borenstein, N. "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC2045, November 1996 [RFC2046] Freed, N. and Borenstein, N. "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC2046, November 1996 [RFC2047] Moore, K. "Multipurpose Internet Mail Extensions (MIME) Part Three: Message Header Extensions for Non-ASCII Text", RFC2047, November 1996 [RFC2048] Freed, N., Klensin, J., and Postel, J. "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", RFC2048, November 1996 [RFC2049] Freed, N. and Borenstein, N. "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC2049, November 1996 [RFC1939] Myers, J., Rose, M. "Post Office Protocol - Version 3", RFC1939, May 1996 - also STD:53 [RFC2060] Crispin, M. "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC2060, December 1996 Wong Informational - Expires September 2003 29 UM Requirements March 2003 [RFC2421] Vaudreuil, G., Parsons, G. "Voice Profile for Internet Mail - version 2", RFC2421, September 1998 [RFC2422] Vaudreuil, G., Parsons, G. "Toll Quality Voice - 32 kbit/s ADPCM MIME Sub-type Registration", RFC2422, September 1998 [RFC2423] Vaudreuil, G., Parsons, G. "VPIM Voice Message MIME Sub-type Registration", RFC2423, September 1998 [RFC2424] Vaudreuil, G., Parsons, G. "Content Duration MIME Header Definition", RFC2424, September 1998 [RFC2301] McIntyre, L., Zilles, S., Buckley, R., Venable, D., Parsons, G., Rafferty, J. "File Format for Internet Fax", RFC2301, March 1998 [RFC2302] Parsons, G., Rafferty, J. Zilles, S. "Tag Image File Format (TIFF) - image/tiff MIME Sub-type Registration", RFC2302, March 1998 [RFC2303] Allocchio, C. "Minimal PSTN address format in Internet Mail", RFC 2303, March 1998 [RFC2304] Allocchio, C. "Minimal FAX address format in Internet Mail", RFC2304, March 1998 [RFC2305] Toyoda, K., Ohno, H., Murai, J., Wing, D. "A Simple Mode of Facsimile Using Internet Mail", RFC2305, March 1998 [RFC2306] Parsons, G., Rafferty, J. "Tag Image File Format (TIFF) - F Profile for Facsimile", RFC2306, March 1998 [MMS] Leuca, I. "Multimedia Messaging Service", Presentation to the VPIM WG, IETF53 Proceedings, April 11, 2002 [BIN] "IMAP4 Binary Content Extension", 01/18/2002, , work in progress [CHAN] "IMAP4 Channel Transport Mechanism", 11/27/2001, , work in progress [LMTP] "LMTP Service Extension for Ignoring Recipient Quotas", 08/30/2001, , work in progress [RFC3459] Burger, E., "Message Context for Internet Mail", January 2003. [SNAP] "Simple Notification and Alarm Protocol (SNAP)", 12/20/2001 , work in progress [RFC 2476] Gellens, R. and Klensin J. "Message Submission", December 1998. (Status: PROPOSED STANDARD) Wong Informational - Expires September 2003 30 UM Requirements March 2003 [RFC 2033] Myers, J. "Local Mail Transfer Protocol" October 1996. (Status: INFORMATIONAL) [RFC 2086] Myers, J. "IMAP4 ACL extension" January 1997. (Status: PROPOSED STANDARD) [RFC 2087] Myers, J. "IMAP4 QUOTA extension" January 1997. (Status: PROPOSED STANDARD) [RFC 2221] Gahrns, M. IMAP4 Login Referrals. October 1997. (Status: PROPOSED STANDARD) [CONNEG] Toyoda, K. and Crocker, D., "SMTP Service Extensions for Fax Content Negotiation", DRAFT-FAX-ESMTP-CONNEG-06.TXT, February 2003, work in progress. Wong Informational - Expires September 2003 31 UM Requirements March 2003 9. Acknowledgments Ari Erev and Naom Shapira contributed substantial requirements for IMAP to support a telephone-based (TUI) messaging client. Meir Mendelovich helped in merging the wireless requirements section. Wong Informational - Expires September 2003 32 UM Requirements March 2003 10. Editor's Address Jin Kue Wong Nortel Networks P.O. Box 3511, Station C Ottawa, ON K1Y 4H7 Canada Phone: +1-613-763-2515 Email: jkwong@nortelnetworks.com Wong Informational - Expires September 2003 33 UM Requirements March 2003 11. Contributor's Addresses Eric Burger SnowShore Networks, Inc. 285 Billerica Rd. Chelmsford, MA 01824-4120 USA Phone: +1 978/367-8400 Email: e.burger@ieee.org Glenn Parsons Nortel Networks P.O. Box 3511, Station C Ottawa, ON K1Y 4H7 Canada Phone: +1-613-763-7582 Email: gparsons@nortelnetworks.com Gregory M. Vaudreuil Lucent Technologies 7291 Williamson Rd. Dallas, TX 75214 United States Phone/Fax: +1-972-733-2722 Email: GregV@ieee.org Dan Shoshani Comverse 29 Habarzel St. Tel-Aviv 69710 Israel Email: Dan.Shoshani@comverse.com Yair Grosu Comverse 29 Habarzel St. Tel-Aviv 69710 Israel Email: Yair.Grosu@comverse.com Wong Informational - Expires September 2003 34 UM Requirements March 2003 Full Copyright Statement Copyright (C) The Internet Society (2003). 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 The Internet Society currently provides funding for the RFC Editor function. Wong Informational - Expires September 2003 35