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", <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., 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,
     <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
  
     [RFC3459] Burger, E., "Message Context for Internet Mail", January 2003.
  
     [SNAP] "Simple Notification and Alarm Protocol (SNAP)", 12/20/2001
     <draft-shapira-snap-02.txt>, 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