[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 03 04 05 RFC 4416

   Lemonade Working Group                                    J.K. Wong (Ed.)
   Internet Draft                                           Nortel Networks
   Document: draft-ietf-lemonade-goals-00.txt
   Category: Informational
   Expires: December 2003                                     June 21, 2003
         Goals for Internet Messaging to Support Diverse Service Environments
   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
      The list of current Internet-Drafts can be accessed at
      The list of Internet-Draft Shadow Directories can be accessed at
      The mission of LEMONADE -- Internet Messaging to support diverse service
      environments -- is to provide a set of enhancements and profiles to Internet
      email to facilitate operation on platforms with constrained resources, or
      communications links with high latency or limited bandwidth. The enhanced
      mail service must continue to support conventional environments seamlessly.
      The primary driver for this effort is, by making Internet mail protocols
      richer and more media and environment-savvy, to allow their use over the
      mobile Internet.
      Stressing the needs of wireless handheld devices, a discussion is given of
      what is required of Internet messaging protocols to enable the support of
      multimedia messaging on limited capability messaging clients in diverse
      service environments. Also included is a list of general principles to guide
      the design of the enhanced messaging protocols. Finally, some issues around
      providing seamless service between enhanced Internet email and the existing
      separate mobile messaging infrastructure are briefly listed.
      Discussion of this and related drafts are on the LEMONADE WG email list.  To
      subscribe, send the message "subscribe" to lemonade-request@ietf.org.  The
      public archive is in the directory at:
   Wong            Informational - Expires December 2003               1
                               LEMONADE Goals                   June 2003
   1. Introduction...............................................................4
   2. Messaging Terminology and Models (Client to Server only)...................6
     2.1. Messaging Transaction Models...........................................6
     2.2. Mobile Messaging Transactions..........................................6
      2.2.1. Submission..........................................................7
      2.2.2. Notification........................................................7
      2.2.3. Retrieval...........................................................7
   3. Profiles...................................................................8
     3.1. Existing Profiles......................................................8
      3.1.1. Voice Messaging (VPIMv2)............................................8
      3.1.2. Fax.................................................................8
     3.2. Desired Profiles.......................................................8
      3.2.1. TUI.................................................................8
      3.2.2. Multi-modal clients................................................10
      3.2.3. WUI................................................................10
   4. General Principles........................................................12
     4.1. Protocol Conservation.................................................12
      4.1.1. Reuse Existing Protocols...........................................12
      4.1.2. Maintain Existing Protocol Integrity...............................12
     4.2. Sensible Reception/Sending Context....................................12
      4.2.1. Reception Context..................................................12
      4.2.2. Sending Context....................................................12
     4.3. Internet Infrastructure Preservation..................................12
     4.4. Voice Requirements (Near real-time delivery)..........................13
     4.5. Fax Requirements (guaranteed delivery)................................13
     4.6. Video Requirements (scalable message size)............................13
   5. Security Considerations...................................................14
   6. Issues and Requirements: TUI..............................................15
     6.1. Requirements on the Message Retrieval protocol........................15
      6.1.1. Performance Issues.................................................15
      6.1.2. Functional Issues..................................................16
     6.2. Requirements on the Message Submission Protocol.......................17
      6.2.1. Forward without Download Support...................................17
      6.2.2. Quota by Context Enforcement.......................................18
      6.2.3. Future Delivery Support with Cancel................................18
      6.2.4. Support for Committed Message Delivery.............................18
     6.3. Requirements on Message Notification..................................19
      6.3.1. Additional Requirements on Message Notification....................19
   7. Issues and Requirements: WUI..............................................20
     7.1. Wireless Considerations on Email......................................20
      7.1.1. Transport Considerations...........................................20
      7.1.2. Handset-Resident Client Limitations................................20
      7.1.3. Wireless Bandwidth and Network Utilization Considerations..........20
      7.1.4. Content Display Considerations.....................................21
     7.2. Requirements to Enable Wireless Device Support........................22
      7.2.1. Transport Requirements.............................................22
      7.2.2. Enhanced Mobile Email Functionality................................22
      7.2.3. Client Requirements................................................23
      7.2.4. Bandwidth Requirements.............................................23
      7.2.5. Media Handling Requirements........................................23
   Wong            Informational - Expires December 2003               2
                               LEMONADE Goals                   June 2003
   8. Interoperation with Existing Mobile Messaging.............................25
     8.1. Addressing of mobile devices..........................................25
     8.2. Push model of Message Retrieval.......................................25
     8.3. Operator Issues.......................................................25
      8.3.1. Support for end-to-end delivery reports and read reports...........25
      8.3.2. Support for Selective Downloading..................................25
      8.3.3. Transactions and Operator Charging Units...........................25
      8.3.4. Network Authentication.............................................25
   9. Informative References....................................................26
   10. Acknowledgments..........................................................30
   11. Editor's Address.........................................................31
   12. Contributors's Addresses.................................................32
   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
      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 December 2003               3
                               LEMONADE Goals                   June 2003
   1. Introduction
      Historically, a number of separate electronic messaging systems originated
      and evolved independently for different messaging modes. E.g.
           o Internet email systems evolved to support LAN networked computers
              with messages consisting of rich text plus attachments.
           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 utilized modem data
              over the telephone network for transport.
           o Users of cellular phones can use SMS (Short Message Service) to send
              short text messages between their devices.
      In the recent past, IETF email standards have evolved to support
      additional/merged functionality:
           o With MIME, the Internet email transport was enhanced to carry any
              kind of digital data
           o Email protocols were extended and profiled by VPIM and iFAX so that
              properly enabled voice mail systems and fax machines could use the
              common email infrastructure to carry their messages over the Internet
              as an alternative to the telephone network.  These enhancements were
              such that the user’s experience of reliability, security and
              responsiveness were not diminished by transport over the Internet
      These successes in the use of Internet mail profiles to enable the common
      email infrastructure to support what were separate messaging universes have
      encouraged a new vision: 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, operating in diverse environments.
      The effort around--Internet Messaging to support diverse service
      environments--realizes this vision further by enabling Internet mail support
      for mobile devices and facilitating its interoperability with the existing
      mobile messaging universe.
      In the recent past, messaging standards for resource limited mobile devices
      have evolved:
           o In the cellular space, SMS was enhanced to EMS (Extended Message
              Service) allowing longer text messages, images and graphics. With an
              even richer feature set, Multimedia Messaging (MMS) was developed as
              a lightweight access mechanism for the transmission of pictures,
              audio, and motion pictures. MMS protocols are based in part on
              various messaging and web Internet standards as well as SMS. The
              cellular messaging universe is a separate special messaging
              infrastructure adapted to deliver appropriate functionality in a
              timely and effective manner in a special environment.
           o As well other mobile client types besides cellular phones are also
              proliferating. (e.g., wireless PDAs, tablet computers, etc.)
   Wong            Informational - Expires December 2003               4
                               LEMONADE Goals                   June 2003
      These resource limited mobile devices are less powerful both in processing
      power and display capabilities than conventional computers. They are also
      connected to the network by wireless links whose bandwidth is lower, latency
      is longer, and costs are higher than traditional wire-line links hence the
      stress on the need to support adaptation to a whole different service
      The purpose of this document is to discuss issues impeding the IETF email
      protocols from support of these mobile service environments. As a result of
      the discussion requirements are enumerated and in some cases possible
      approaches to solutions are suggested. It turns out that the enhancements
      required to support mobile clients also offer benefits for some terminals in
      conventional environments. In particular the requirements address the needs
      of the following diverse clients:
           o A wireless handheld device with an email client -- a Wireless User
              Interface (WUI) is dictated by the constraints of the wireless
              handheld operating environment
           o A Telephone-based audio client -- a Telephone User Interface(TUI),
              this is the user interface offered by a POTS set
             o This profile is a subset of the WUI and is useful in other contexts
           o A Multi-modal messaging client providing a coordinated messaging
              session across a graphical and audio terminal.  (PC with separate
              phone as speaker and microphone, wireless phone with simultaneous
              voice circuit and data channel).
             o This profile is a subset of the WUI and is useful in other contexts
      The rest of this document is structured as follows:
           o A brief survey of messaging profiles -
                                                   - both existing and yet to be
           o A list of principles to be used to guide the design of Internet
              Messaging for diverse service environments
           o Detailed requirements on Internet mail protocols to support TUIs and
           o Some issues relating to the interoperation of enhanced Internet mail
              and the existing mobile messaging services
   Wong            Informational - Expires December 2003               5
                               LEMONADE Goals                   June 2003
   2. Messaging Terminology and Models (Client to Server only)
      A client server model is prevalent in existing messaging architectures.
      The client, also known as a "user agent", presents messages to and accepts
      messages from the user.
      The server, also known as a "relay/server" or a "proxy-relay", provides
      storage and delivery of messages
   2.1. Messaging Transaction Models
      There are two basic transactional models.  In the "pull" model, the
      component rather than the data flow initiates the transaction.  E.g., a
      client may initiate a connection to a server and issue requests to the
      server to deliver incoming messages.  Conventional email clients, web-mail
      clients, and WAP-based mobile clients use the "pull" model.
      The "push" model differs in that the component initiating the transaction
      does so because of some data flow affecting it.  E.g., the arrival of a new
      message at the terminating server may cause a notification to be sent
      ("pushed") to a messaging client.
   2.2. Mobile Messaging Transactions
      The most common functions are: "submission", "notification", and
      "retrieval".  There may be other functions, such as "delivery reports",
      "read-reply reports", "forwarding", "view mailbox", "store message", etc.
      Each of these transactions can be implemented in either a pull or push
      model.  However, some transactions are more naturally suited to one model or
      The following figure is a depiction of a simple client-server model (no
      server to server interactions shown):
         (1) Message submission
         (2) Message notification
         (3) & (4) Message retrieval
           +-------+                 +------+                       +-------+
           |Mail   |-------(1)------>|      |-----------(2)-------->|Mail   |
           |Client |   Submit msg    |      |     Notification     /|Client |
           +-------+                 |      |                     / +--+----+
                                     |      |                    /     ^
                                     |      |<----------(3)-----+     /
                                     |Server|   Retrieval request    /
                                     |      |                       /
                                     |      |                      /
                                     |      |-----------(4)-------+
                                     |      |   Retrieval response
                                     |      |
                             - Simple Messaging Model
   Wong            Informational - Expires December 2003               6
                               LEMONADE Goals                   June 2003
   2.2.1. Submission
      "Submission" is the transaction between a client and a server by which the
      user of the former can sends a new message to another user.  Submission is a
      push from client to server.
   2.2.2. Notification
      "Notification" is the transaction by with the server notifies the client
      that it has received messages intended for that client. Notification is a
      push from server to client.
      All of the larger mobile messaging systems implement a push model for the
      notification because data is presented to the user without the user having
      to experience network/transport latencies, and without tying up network
      resources for polling when there is no new data.
      Conventional email differs in that it has not seen the need so far for a
      standardized notification protocol.
   2.2.3. Retrieval
      "Retrieval" is the transaction between a client and a server by which the
      client can obtain one or more messages from the server.  Retrieval can be
      push or pull.
      Implemented in some mobile systems as an option, there is the advantage of
      the user not necessarily being aware of transport or network latencies
      The pull model, implemented in most systems, mobile or conventional, has the
      advantage that the user can control what data is actually sent to and stored
      by the client.
   Wong            Informational - Expires December 2003               7
                               LEMONADE Goals                   June 2003
   3. Profiles
      Internet messaging can be support a variety of client and server types other
      than traditional email. 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 critical for a
      particular application is to define an Internet Mail profile for that
   3.1. Existing Profiles
      The following profiles are server-to-server profiles of SMTP and MIME.  They
      do not address client-to-server interactions.
   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.2. Desired Profiles
   3.2.1. TUI
      It is desirable to replace proprietary interfaces between telephone user
      interfaces and message stores with standards-based interfaces.  The
      proprietary interfaces were created to provide media-aware capabilities as
      well as provide the low-latency required of the interface.
      An example of a TUI client is a voice mail client. Since a POTS phone is a
      totally dumb terminal, the voice mail client functionality has to be
      provided by a user agent networked to the mail server. The main
      architectural difference between a conventional voice mail system and an
      Internet messaging system supporting a TUI profile is that the voice mail
      system uses a specialized message store and protocols.
   Wong            Informational - Expires December 2003               8
                               LEMONADE Goals                   June 2003
   Architecture of current voice mail systems implementing VPIMv2:
              |-------|     RFC-822/MIME          |               |
              |   |   |---------------------------|       MTA     |
              |   |   |     mail submission ->    |               | (E)SMTP
   Telephone--|TUI|TUA|                           |------|        |--to another
              |   |   |   Proprietary Protocol    |      |        |    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
      It is proposed that the Proprietary Protocol be replaced with an IETF
      standard protocol:
              |-------|     RFC-822/MIME          |               |
              |   |   |---------------------------|       MTA     |
              |   |   |   mail submission ->      |               | (E)SMTP
   Telephone--|TUI|TUA|                           |------|        |--to another
              |   |   |     IETF protocol         |      |        |    mail
              |   |   |---------------------------| MS   |        |    server
              |-------|    <- mail retrieval      |      |        |
              mail client                           email server
         |- voice mail system-|                   |--mail server--|
      Mail client consists of: TUI (Telephone User Interface) and
                               TUA (Telephone User Agent)
               Communication between TUI and TUA is proprietary
      Email server consists of: MS (Mail Store) and MTA (Message Transfer Agent)
               Communication between MS and MTA is proprietary
   Wong            Informational - Expires December 2003               9
                               LEMONADE Goals                   June 2003
   3.2.2. Multi-modal clients
      Multi-modal clients offer the potential of coordinated voice and data over
      different interfaces. Architecturally, the multi-modal client can be
      considered the union two user agent components--
                                                      one a TUI client, the other a
      simple GUI client. See next figure. The GUA helps maintain the text display
      while the TUA acts on behalf of the TUI functionality. This model is the
      norm with cellular devices supporting data access since these evolved
      historically from cell phones. Architecturally, there may also be situations
      where this model is appropriate. ( Maybe the client host processor power and
      radio channel bandwidth are insufficient to handle the voice processing
      needed for text recognition or text to speech or that presenting a two
      completely different modes of user interaction is desirable.)
   3.2.3. WUI
      The Wireless user interface is functionally equivalent to a conventional
      email client on a personal workstation, but is optimized for the limited
      memory, processing, latency, bandwidth, and relatively high bandwidth cost.
      As already alluded to above, in many cases (e.g. cellular devices), the
      mobile client is multi-modal one. So WUIs can be modeled as resource-and-
      link-limited multi-modal clients.
      These terminals require the use of protocols that minimize over-the-air
      transactions and reduce the amount of data that needs be transmitted over
      the air.  Such reduction in over-the-air transmission is a combination of
      more efficient protocol interaction and richer message presentation choices
      allowing a user to more intelligently select what should be downloaded and
      what should remain on the server.
      While not an explicit goal, it is desirable to provide equivalent
      functionality to the wireless MMS service as defined by 3GPP, 3GPP2, and the
   Wong            Informational - Expires December 2003              10
                               LEMONADE Goals                   June 2003
      Wireless User Interface(WUI)/Multi-modal Clients
          |wireless GUI client|                     email server
                         (E)SMTP (client-server)  |---------------|
              |-------|     RFC-822/MIME          |               |
              |   |   |---------------------------|               |
              |   |   |   mail submission ->      |               | (E)SMTP
             -|GUI|GUA|                           |               |--to another
            | |   |   | IETF standard protocol    |------------   |    mail
            | |   |   |----------------------------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-----|                      |---mail server----|
      Wireless GUI client consists of: GUI (Graphical User Interface)
                              And GUA (Graphical User Agent)
               Communication between UI and UA is proprietary
      TUI client consists of: TUI (Telephone User Interface) and
                               TUA (Telephone User Agent)
               Communication between TUI and TUA is proprietary
               Communication between GUA and TUA is proprietary
      Mail (email and voice mail) server consists of: MS (Mail Store)
                          and MTA (Message Transfer Agent)
               Communication between MS and MTA is proprietary
   Wong            Informational - Expires December 2003              11
                               LEMONADE Goals                   June 2003
   4. General Principles
      This is a list of principles to guide the design of extensions for Internet
      Messaging systems and protocols to support diverse endpoints.
   4.1. Protocol Conservation
   4.1.1. Reuse Existing Protocols
      To the extent feasible, the enhanced messaging framework SHOULD use existing
      protocols whenever possible.
   4.1.2. Maintain Existing Protocol Integrity
      In meeting requirement 4.1, the enhanced messaging framework MUST NOT
      redefine the semantics of an existing protocol.
      Extensions, based on capability declaration by the server, will be used to
      introduce new functionality where required.
      Said differently, we will not break existing protocols.
   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
      The infrastructure SHOULD change only where required for new functionality.
      Existing functionality MUST be preserved on the existing infrastructure,
      that is, all extensions must be backward compatible. There MUST be no flag
      days. Messages created in an enhanced messaging context MUST NOT require
      changes to existing mail clients.  However, there may be a loss in service
      in certain circumstances.
   Wong            Informational - Expires December 2003              12
                               LEMONADE Goals                   June 2003
      The enhanced messaging framework MUST be able to handle messages created in
      a non-enhanced messaging context, for example, a simple, [RFC 822] text
   4.4. Voice Requirements (Near real-time delivery)
      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 enhanced 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 enhanced
      Internet 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 potentially
      large!  The enhanced messaging framework MUST scale for very large messages.
      Streaming from the server to the client and vice-versa must be supported
   Wong            Informational - Expires December 2003              13
                               LEMONADE Goals                   June 2003
   5. Security Considerations
      Security will be a very important part of enhanced 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
   Wong            Informational - Expires December 2003              14
                               LEMONADE Goals                   June 2003
   6. Issues and Requirements: TUI
   6.1. Requirements on the Message Retrieval protocol
      IMAP is the Internet protocol for rich message retrieval and manipulation.
      The project will extend IMAP where necessary and will not create a new
   6.1.1. Performance Issues        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 protocol, or utilizing an companion streaming
      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)
      Alternatively, the client can use the proposed IMAP channel extension 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.        Avoid Base-64 Data Inflation
      Another important performance optimization is enabling the transport of data
      using more efficient native coding rather than the text-like "base 64"
      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.
   Wong            Informational - Expires December 2003              15
                               LEMONADE Goals                   June 2003
      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        Mailbox Summary Support
      The common TUI prompt, "you have two new voice messages, six unheard
      messages, and one new fax message" requires more information than is
      conveniently made available by current message retrieval protocols.
      The existing IMAP protocol’s mailbox status command does not include a count
      by message context. 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. 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 currently include
      information about the message type.  Without additional conventions to the
      status command, a client would have to download the header for each message
      to determine its type, a prohibitive cost where latency or bandwidth
      constraints exist.        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 does not support this directly. A straightforward solution is to define
      an extensible sort mechanism for sorting on arbitrary header contents.        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.
      Current mechanisms are limited to logging into each of set of mailboxes,
      checking status, logging out, and repeating until all sub-mailboxes are
   Wong            Informational - Expires December 2003              16
                               LEMONADE Goals                   June 2003        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 provides only a single standardized folder, the 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.
         CLID Restriction indication/preservation
      Many calling features are dependent upon collected caller-ID information.
      Trusted clients such as the TUI, and supporting in-network user agents such
      as web and WAP servers 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
      Further, when sending messages between servers within a network, a means to
      communicating trust such that the identity of the sender can be preserved
      for record-keeping and certain features while ensuring the identity is not
      disclosed to the recipient in inappropriate ways.
   GV 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.
      The existing standard does not preclude multiple accesses to a mailbox, but
      it does not explicitly require support of the 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 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
   Wong            Informational - Expires December 2003              17
                               LEMONADE Goals                   June 2003
      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
      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
      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.
      Voice mail systems' mailboxes commonly contain voice and fax messages.
      Sometimes, such systems also support Email messages (text, text with
      attachments, and multimedia messages) 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. Email messages) to consume all available quota so that messages of
      other type (e.g. voice or fax messages) cannot be further deposited to the
      This work effort should define a mechanism whereby a trusted client can
      declare the context of a message for the purpose of utilizing a protected
      quota.  This may be met in extensions to the SMTP-submit or LMTP protocols.
   6.2.3. Future Delivery Support with Cancel
      Traditionally messages sent with "future delivery" are held in the
      recipients client "outbox" or equivalent until the appointed submission
      time.  Thin clients used for WUI or TUI do not have such persistent storage
      or may be intermittently connected and must rely upon server-based outbox
      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 messages are sent when they are intended.
   6.2.4. Support for Committed Message Delivery
   Wong            Informational - Expires December 2003              18
                               LEMONADE Goals                   June 2003
      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".
      The standards community is working on an alternative to SMTP called Local
      Message Transport Protocol(LMTP). 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 based submission mechanism 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 subscriber’s 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
   6.3. Requirements on Message Notification
      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.
   6.3.1. Additional Requirements on Message Notification
      A format for message notifications for servers reporting status information
      to other servers (e.g. IMAP4  server to SMS or pager server) MUST be
      defined. The method for delivery of these notifications MUST also be
      The design for this MUST take into account the IAB specification of general
      guidelines for notification services(TBD).
   Wong            Informational - Expires December 2003              19
                               LEMONADE Goals                   June 2003
   7. Issues and Requirements: WUI
   7.1. Wireless Considerations on Email
   7.1.1. Transport Considerations
      Compared to a LAN/WAN configuration or even to a wire-line 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
      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        Low Bandwidth
      2G mobile networks enabled wireless data communications but only at very low
      bandwidths using circuit-switched data. 2.5G and 3G networks improve on
      this. However, existing email clients require very large (up to several MBs)
   Wong            Informational - Expires December 2003              20
                               LEMONADE Goals                   June 2003
      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.
         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.
         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        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.
         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.        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.
   Wong            Informational - Expires December 2003              21
                               LEMONADE Goals                   June 2003        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
   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        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
      The mobile email protocol MUST support the ability to forward a message
      without retrieving it.
      This requirement is identical to the TUI requirement that is described in
      section 6.2.1
   Wong            Informational - Expires December 2003              22
                               LEMONADE Goals                   June 2003        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
   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
      [], "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.        Device Capabilities Negotiation
      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.
         Adjusting Message Attachments for Handset Abilities
      To support 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
   Wong            Informational - Expires December 2003              23
                               LEMONADE Goals                   June 2003
      described in []. 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.        Handling Attachment Parts
      A desirable feature to have (but 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.
   Wong            Informational - Expires December 2003              24
                               LEMONADE Goals                   June 2003
   8. Interoperation with Existing Mobile Messaging
      LEMONADE’s charter includes the specification of how enhanced Internet
      Mail will interoperate with existing mobile messaging services (e.g. MMS) to
      deliver messages to mobile clients.
   8.1. Addressing of mobile devices
      E.164 addressing is prevalent in mobile messaging services to address
      handheld devices. Consideration should be given to supporting E.164
      addressing for mobile devices in addition to RFC822 addressing.
   8.2. Push model of Message Retrieval
      MMS provides a ‘‘push’’ option for message retrieval. The option hides network
      latencies and reduces the need for user-handheld interaction. If a level of
      support for mobiles comparable MMS is desired, this mode of operation should
      be considered.
   8.3. Operator Issues
   8.3.1. Support for end-to-end delivery reports and read reports
      Support for committed delivery is described in [6.2.4] but this is
   8.3.2. Support for Selective Downloading
      Especially important, if a push model of message retrieval is supported, is
      the need for selective downloading and SPAM control.
   8.3.3. Transactions and Operator Charging Units
      Mobile network providers often operate on a "pay for use" service model.
      This brings in requirements for clearly delineated service transactions that
      can be reported to billing systems, and for positive end-to-end
      acknowledgement of delivery or non-delivery of messages already mentioned
   8.3.4. Network Authentication
      Some mobile networks support network authentication as well as application
   Wong            Informational - Expires December 2003              25
                               LEMONADE Goals                   June 2003
   9. 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
      [RFC822] Crocker, D., "Standard for the format of ARPA Internet text
      messages", RFC 822 (obsolete), August 1982
      [RFC1891] Moore, K. "SMTP Service Extension for Delivery Status
      Notifications", RFC 1891, January 1996.
      [RFC1939] Myers, J., Rose, M. "Post Office Protocol - Version 3", RFC1939,
      May 1996 -
               - also STD:53
      [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
      [RFC2049] Freed, N. and Borenstein, N. "Multipurpose Internet Mail
      Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC2049,
      November 1996
      RFC2060, December 1996
      [RFC2086] Myers, J. "IMAP4 ACL extension" January 1997.
      [RFC2087] Myers, J. "IMAP4 QUOTA extension" January 1997.
      [RFC2221] Gahrns, M.  IMAP4 Login Referrals. October 1997.
      [RFC2298] R. Fajman, "An Extensible Message Format for Message Disposition
      Notifications", RFC 2298, March 1998.
      [RFC2421] Vaudreuil, G., Parsons, G. "Voice Profile for Internet Mail -
      version 2", RFC2421, September 1998
   Wong            Informational - Expires December 2003              26
                               LEMONADE Goals                   June 2003
      [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
      [RFC2476] Gellens, R. and Klensin J. "Message Submission", December 1998.
      [RFC2532] Masinter, L. and Wing, D., "Extended Facsimile Using Internet
      Mail", RFC 2532, March 1999
      [RFC2616] Fielding, Gettys, Berners-Lee, et. al., "Hypertext Transfer
      Protocol - HTTP 1.1", RFC 2616, June 1999.
      [RFC2821] Klensin, J., Editor " Simple Mail Transfer Protocol", RFC 2821,
      April 2001
      [RFC2822] Resnick, P., Editor "Internet Message Format", RFC 2822, April
      [RFC3458] Burger, E., Candell, E., Eliot, C., and Klyne, G., "Message
      Context for Internet Mail", January 2003.
      [RFC3459] Burger, E., "Critical Content Multi-purpose Internet Mail
      Extensions (MIME) Parameter", January 2003.
      [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
   Wong            Informational - Expires December 2003              27
                               LEMONADE Goals                   June 2003
      [CONNEG] Toyoda, K. and Crocker, D., "SMTP Service Extensions for Fax
      Content Negotiation", DRAFT-FAX-ESMTP-CONNEG-06.TXT, February 2003, work in
      [IVM] McRae, S. and Parsons, G., "Internet Voice Messaging",
      draft-ietf-vpim-ivm-04.txt, work in progress
      [LMTP] "LMTP Service Extension for Ignoring Recipient Quotas", 08/30/2001,
      <draft-murchison-lmtp-ignorequota-01.txt>, work in progress
      [MMS] Leuca, I. "Multimedia Messaging Service", Presentation to the VPIM WG,
      IETF53 Proceedings, April 11, 2002
      [SIPMWI] Mahy, R. "A Message Summary and Message Waiting Indication Event
      Package for the Session Initiation Protocol (SIP)", draft-ietf-sipping-mwi-
      [SNAP] Shapira, N. and Aloni, E. "Simple Notification and Alarm Protocol
      (SNAP)",<draft-shapira-snap-02.txt>, 12/20/2001, work in progress
      [UMISS] Vaudreuil, Greg "Messaging profile for telephone-based Messaging
      clients", <draft-vaudreuil-um-issues-00.txt>, February 2002
      [UMREQS] Burger, E, "Internet Unified Messaging Requirements", <draft-
      burger-um-reqts-00.txt>, February 2002
      [OMAMMS] Open Mobile Alliance (OMA) "Multimedia Messaging Service;
      Architectural Overview Version 1.1", OMA, 2002
      [OMAWAPPUSHO] Open Mobile Alliance (OMA) "Push Architectural Overview, WAP-
      250-PushArchOverview-20010703-a", OMA, 2001
      [OMAWAPPUSHA]Open Mobile Alliance (OMA) "Push Architectural Overview Push
      Access Protocol Specification, WAP-247-PAP-20010429-a", OMA, 2001
      [OMAPUSHPROX] Open Mobile Alliance (OMA) "Push Proxy Gateway Service
      Specification", WAP-249-PPGService-20010425.pdf, OMA, 2001
      [OMAMMSC] Open Mobile Alliance (OMA) "Multimedia Messaging Service; Client
      Transactions Version 1.1", OMA-MMS-v1_1, OMA, 2002
      [OMAMMSEP] Open Mobile Alliance (OMA) "Multimedia Messaging Service;
      Encapsulation Protocol Version 1.1", OMA-MMS-v1_1, OMA, 2002
      [OMAUAF] Open Mobile Alliance (OMA) "User Agent Profile, Version 1.1", OMA-
      UAPROF-v1_1, OMA, December 2002.
      [OMANOTIF] Open Mobile Alliance (OMA) "Email Notification Version 1.0", OMA,
      [3GPPMMS1] 3GPP TS 22.140 "Third Generation Partnership Project; Technical
      Specification Group Services and System Aspects; Service aspects; Functional
      description; Stage 1 Multimedia Messaging Service", 3GPP, 2001
   Wong            Informational - Expires December 2003              28
                               LEMONADE Goals                   June 2003
      [3GPPMMS2] 3GPP TS 23.140 "Third Generation Partnership Project; Technical
      Specification Group Terminals; Multimedia Messaging Service (MMS);
      Functional description; Stage 2", 3GPP, 2001
      [SMS] C.S0015-A: Short Message Service (SMS), December 1999, 3GPP2.
      [EMS] S.R0051-0 v1.0: "Enhanced Message Service (EMS) Stage 1 Description",
      3GPP2, July 2001.
      [CCITTQ700] CCITT White Book, Volume VI, Fascicle VI.7, Recommendations
      Q.700-Q.716: Specifications of Signalling System No. 7.
      [CCITTQ721] CCITT White Book, Volume VI, Fascicle VI.8, Recommendations
      Q.721-Q.766: Specifications of Signalling System No.7.
      [ITUE164] ITU-T Recommendations Series E: "E.164: The international public
      telecommunication numbering plan"; ITU, May 1997.
      [ITUQ763] ITU White Book, ITU-T Recommendation Q.763: Specifications of
      Signalling System Number 7.
      [ITUX25] ITU-T Recommendation Series X: X.25: "Interface between Data
      Terminal Equipment (DTE) and Data Circuit-terminating Equipment (DCE) for
      terminals operating in the packet mode and connected to public data networks
      by dedicated circuit", ITU, Oct 1996.
      [GRSS7] GR-246-CORE, Issue 1, December 1994: Specifications of Signalling
      System Number 7.
   Wong            Informational - Expires December 2003              29
                               LEMONADE Goals                   June 2003
   10. Acknowledgments
      Ari Erev and Noam Shapira contributed substantial requirements for IMAP to
      support a telephone-based (TUI) messaging client. Meir Mendelovich
      (Comverse) helped in merging the wireless requirements section. Benjamin
      Ellsworth (Openwave) contributed to mobile messaging architectures and
      This document is a revision of:
      Wong, J.K (Ed.) ‘‘Internet Unified Messaging Requirements to Support Diverse
      Clients’’, draft-wong-umcli-02.txt
      The current document contains contributions from:
           o draft-wong-umcli-00.txt
           o draft-stebrose-mmsarch-01.txt
           o draft-vaudreuil-um-issues-00.txt
           o draft-burger-um-reqts-00.txt
           o draft-shoshani-mobile-email-req-002.txt
   Wong            Informational - Expires December 2003              30
                               LEMONADE Goals                   June 2003
   11. Editor's Address
      Jin Kue Wong
      Nortel Networks
      P.O. Box 3511, Station C
      Ottawa, ON K1Y 4H7
      Phone: +1-613-763-2515
      Email: jkwong@nortelnetworks.com
   Wong            Informational - Expires December 2003              31
                               LEMONADE Goals                   June 2003
   12. Contributors's Addresses
      Eric Burger
      SnowShore Networks, Inc.
      285 Billerica Rd.
      Chelmsford, MA  01824-4120
      Phone: +1 978/367-8400
      Email: e.burger@ieee.org
      Yair Grosu
      29 Habarzel St.
      Tel-Aviv 69710
      Email: Yair.Grosu@comverse.com
      Glenn Parsons
      Nortel Networks
      P.O. Box 3511, Station C
      Ottawa, ON K1Y 4H7
      Phone: +1-613-763-7582
      Email: gparsons@nortelnetworks.com
      Milt Roselinsky
      Openwave Systems, Inc.
      530 E. Montecito St.
      Santa Barbara, CA 93103
      Phone: 805-884-6207
      Email: milt.roselinsky@openwave.com
      Dan Shoshani
      29 Habarzel St.
      Tel-Aviv 69710
      Email: Dan.Shoshani@comverse.com
      Alan K. Stebbens
      Openwave Systems, Inc.
      530 E. Montecito St.
      Santa Barbara, CA 93103
      Phone: 805-884-3162
      Email: alan.stebbens@openwave.com
      Gregory M. Vaudreuil
      Lucent Technologies
      7291 Williamson Rd.
      Dallas, TX  75214
      United States Phone/Fax: +1-214-823-9325
      Email: GregV@ieee.org
   Wong            Informational - Expires December 2003              32
                               LEMONADE Goals                   June 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
      The Internet Society currently provides funding for the RFC Editor function.
   Wong            Informational - Expires December 2003              33

Html markup produced by rfcmarkup 1.111, available from https://tools.ietf.org/tools/rfcmarkup/