Network Working Group E. Burger, SnowShore Networks, Inc Internet Draft G. Parsons, Nortel Networks Document: draft-wong-umcli-01.txt G. Vaudreuil, Lucent Technologies Category: Informational J.K. Wong, Nortel Networks Expires: May 2003 November 2002 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 two new classes of limited capability messaging clients: 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 November 2002 1 Abstract............................................................3 2 Conventions used in this document...................................3 3 Introduction........................................................4 4 Internet Mail and Messaging.........................................6 4.1 Mail Server.......................................................6 4.2 Message Format....................................................6 4.3 Client Access.....................................................7 5 Profiles............................................................8 5.1 Existing Profiles.................................................8 5.1.1 Voice Messaging (VPIMv2)........................................8 5.1.2 Fax ............................................................8 5.1.3 GUI ............................................................8 5.2 Proposed Profiles................................................10 5.2.1 TUI ...........................................................10 5.2.2 WUI ...........................................................12 6 General Principles.................................................14 6.1 Protocol Conservation............................................14 6.1.1 Reuse Existing Protocols.......................................14 6.1.2 Maintain Existing Protocol Integrity...........................14 6.2 Sensible Reception/Sending Context...............................14 6.2.1 Reception Context..............................................14 6.2.2 Sending Context................................................14 6.3 Internet Infrastructure Preservation.............................15 6.4 Voice Requirements (enhanced security and near real-time delivery)15 6.5 Fax Requirements (guaranteed delivery)...........................15 6.6 Video Requirements (scalable message size).......................15 6.7 Security Considerations..........................................15 7 Detailed Requirements and Issues...................................16 7.1 TUI..............................................................16 7.1.1 Requirements on the client access (message delivery, mail retrieval) protocol 16 7.1.2 Requirements on the message posting (mail submission) protocol.21 7.1.3 Requirements on the message arrival notification protocol......22 7.2 WUI..............................................................22 8 Informative References.............................................23 9 Acknowledgments....................................................26 10 Authors's Addresses..............................................26 Wong et al Informational - Expires May 2003 2 UM Requirements November 2002 1 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 two new classes of limited capability messaging clients: 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. 2 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 et al Informational - Expires May 2003 3 UM Requirements November 2002 3 Introduction Historically, a number of separate electronic messaging systems originated and evolved independently for different messaging modes. E.g. . 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. . 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. . 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: . first e-mail transport was enhanced to carry any kind of digital data . 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 userCs experience of reliability, security and responsiveness were not diminished by transport over the Internet . 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 Wong et al Informational - Expires May 2003 4 UM Requirements November 2002 power and display capabilities. They may also be connected to the network by wireless links whose bandwidth is lower and latency longer than 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: . a TUI (telephone based client with telephone user interface) . 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: . a brief survey of IETF e-mail standards and their evolution . a brief survey of messaging profiles - both existing and yet to be defined . a list of principles to be used to guide the design of Internet Unified Messaging . detailed requirements on Internet mail protocols to support TUIs and WUIs. Wong et al Informational - Expires May 2003 5 UM Requirements November 2002 4 Internet Mail and Messaging This section reviews very briefly protocols supporting the existing architecture for Internet Mail. 4.1 Mail Server [RFC2821] specifies the most recent version (currently an IETF proposed standard that resulted from 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) 4.2 Message Format [RFC2822] gives the current message and header format (also a proposed standard). A series of five MIME RFCs [RFC2045 to RFC2049](draft standards except RFC2048 BCP) 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. Wong et al Informational - Expires May 2003 6 UM Requirements November 2002 4.3 Client Access Messaging clients retrieve messages from messaging servers using either the POP3 [RFC1939] (standard) or the IMAP4 [RFC2060] (proposed standard) protocols. The POP3 protocol assumes a 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 which the client can manipulate. Neither protocol defines message posting which is specified by SMTP (client- server). Web based clients use http for message retrieval. |---------------| |-------| 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 et al Informational - Expires May 2003 7 UM Requirements November 2002 5 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 a Internet Mail profile for that application. 5.1 Existing Profiles 5.1.1 Voice Messaging (VPIMv2) These profiles [RFC2421 to RFC2424] (proposed standards) 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. 5.1.2 Fax This set of profiles [RFC2301 to RFC2306] (proposed standards) 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. 5.1.3 GUI Conventional e-mail clients on computers are generally GUI based. Clients on todayCs 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 et al Informational - Expires May 2003 8 UM Requirements November 2002 (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 Wong et al Informational - Expires May 2003 9 UM Requirements November 2002 5.2 Proposed Profiles 5.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 extend the functionality of the message store but not clutter up its semantics in a way that minimizes the communication overhead between the message store and the user agent host. Besides, the optimization issue, there are also issues of security and reliability in this communication. The client/UA communicates with the Internet Mail server through three protocols each of which might need enhancement: . Message delivery (mail retrieval ) e.g. POP3 or IMAP4 . Message posting (mail submission) SMTP(client-server) . Message arrival notification Wong et al Informational - Expires May 2003 10 UM Requirements November 2002 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 Wong et al Informational - Expires May 2003 11 UM Requirements November 2002 5.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 (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 UA1Cs 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 et al Informational - Expires May 2003 12 UM Requirements November 2002 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 et al Informational - Expires May 2003 13 UM Requirements November 2002 6 General Principles This is a list of principles to guide the design of Unified Messaging systems and protocols. 6.1 Protocol Conservation 6.1.1 Reuse Existing Protocols To the extent feasible, the unified messaging framework SHOULD use existing protocols whenever possible. 6.1.2 Maintain Existing Protocol Integrity In meeting requirement 6.1, the unified messaging framework MUST NOT redefine the semantics of an existing protocol. Said differently, we will not break existing protocols. 6.2 Sensible Reception/Sending Context 6.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. 6.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. Wong et al Informational - Expires May 2003 14 UM Requirements November 2002 6.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. 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. 6.4 Voice Requirements (enhanced security and near real-time delivery) The expectation of voice mail users are described in [IVM] and [MSGCON]. 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. 6.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? 6.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. 6.7 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 et al Informational - Expires May 2003 15 UM Requirements November 2002 7 Detailed Requirements and Issues 7.1 TUI 7.1.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,. 7.1.1.1 Performance Issues 7.1.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 et al Informational - Expires May 2003 16 UM Requirements November 2002 It is clear that a choice be made common to the server and the client to provide this functionality. 7.1.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. 7.1.1.2 Functional Issues 7.1.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 protocolCs 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 which 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 et al Informational - Expires May 2003 17 UM Requirements November 2002 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 is currently standards activity directed toward defining an extensible mechanism for sending arbitrary message summary data in the LIST command. 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. 7.1.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. 7.1.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. 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 Wong et al Informational - Expires May 2003 18 UM Requirements November 2002 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). 7.1.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 submailboxes, where a common feature is to check whether other submailboxes 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 submailboxes are statused. 7.1.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. 7.1.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 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. Wong et al Informational - Expires May 2003 19 UM Requirements November 2002 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. 7.1.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. 7.1.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. 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 Wong et al Informational - Expires May 2003 20 UM Requirements November 2002 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. 7.1.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. 7.1.2 Requirements on the message posting (mail submission) protocol 7.1.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. 7.1.2.2 Quota by Context Enforcement It is common in a unified messaging system to offer separate quota's 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 Wong et al Informational - Expires May 2003 21 UM Requirements November 2002 mailbox. It is envisioned that the message submission protocol will support authentication of trusted submission agents authorized to submit distinguished messages. 7.1.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 cancelling a future message. Server support for managing such a queue is required such that message are sent when they are intended. 7.1.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. 7.2 WUI Clearly the TUI analysis applies. As to additional requirements this requires additional work. Wong et al Informational - Expires May 2003 22 UM Requirements November 2002 8 Informative References [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [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 [MSGCON] Burger, E., Candell, E., Eliot, C., and Klyne, G., "Message Context for Internet Mail", draft-ietf-vpim-hint-07.txt, June 2001 [UMREQS] Burger, E, "Internet Unified Messaging Requirements", <draft- burger-um-reqts-00.txt>, February 2002 [UMISS] Vaudreuil, Greg "Messaging profile for telephone-based Messaging clients", <draft-vaudreuil-um-issues-00.txt>, 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., 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 Wong et al Informational - Expires May 2003 23 UM Requirements November 2002 [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 [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, <draft-nerenberg-imap-binary-06.txt>, work in progress [CHAN] "IMAP4 Channel Transport Mechanism", 11/27/2001, <draft-nerenberg-imap-channel-01.txt>, work in progress [LMTP] "LMTP Service Extension for Ignoring Recipient Quotas", 08/30/2001, <draft-murchison-lmtp-ignorequota-01.txt>, work in progress [HINT] "Message Context for Internet Mail", 06/05/2001, <draft-ietf-vpim-hint-07.txt>, work in progress [SNAP] "Simple Notification and Alarm Protocol (SNAP)", 12/20/2001 Wong et al Informational - Expires May 2003 24 UM Requirements November 2002 <draft-shapira-snap-02.txt>, work in progress [RFC 2476] Gellens, . Klensin J. "Message Submission" R. December 1998. (Status: PROPOSED STANDARD) [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) Wong et al Informational - Expires May 2003 25 UM Requirements November 2002 9 Acknowledgments Ari Erev and Naom Shapira contributed substantial requirements for IMAP to support a telephone-based (TUI) messaging client. 10 Authors's Addresses Eric Burger SnowShore Networks, Inc. Chelmsford, MA USA Phone: +1 978/367-8403 Email: eburger@snowshore.com 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 Editor: 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 et al Informational - Expires May 2003 26 UM Requirements November 2002 Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement The Internet Society currently provides funding for the RFC Editor function. Wong et al Informational - Expires May 2003 27