[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [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-02.txt
   Category: Informational
   Expires: August 2004                                   February 15, 2004
   
   
         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 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 LEMONADE Working Group -- Internet Messaging to support diverse service
      environments -û is chartered to provide a new set of enhancements and
      profiles to Internet email. The enhancements are to facilitate email use on
      hosts not only operating in environments with high latency/limited
      bandwidth links but also constrained with limited resources. The enhanced
      email must continue also to seamlessly support the existing service.
   
      The primary motivation for this effort is -- by making Internet mail
      protocols richer and more adaptable to varied media and environments û to
      allow their use by handheld devices to access the Internet wirelessly.
   
      The requirements of these devices drive a discussion of the possible
      protocol enhancements needed to generally support multimedia messaging on
      limited capability hosts in diverse service environments. A list of general
      principles to guide the design of the enhanced messaging protocols is
      documented. Finally, some issues around providing seamless service between
      enhanced Internet email and the existing separate mobile messaging
      infrastructure are briefly listed. This document attempts to capture the
      background, motivation and thinking behind the Lemonade design process.
   
      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:
          ftp://ftp.ietf.org/ietf-mailing-lists/lemonade/
   
   
    Wong             Informational - Expires August 2004                1
   
                               LEMONADE Goals               February 2004
   
   1. Introduction..............................................................4
   2. Messaging Terminology and Models (Client to Server aspect 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. Useful Client 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 subset of WUI...............................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..................................18
      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............................19
     6.3. Requirements on Message Notification.................................19
      6.3.1. Additional Requirements on Message Notification...................20
   7. Issues and Requirements: WUI Mobility Aspects............................21
     7.1. Wireless Considerations on Email.....................................21
      7.1.1. Transport Considerations..........................................21
      7.1.2. Handset-Resident Client Limitations...............................21
      7.1.3. Wireless Bandwidth and Network Utilization Considerations.........21
      7.1.4. Content Display Considerations....................................22
     7.2. Requirements to Enable Wireless Device Support.......................23
      7.2.1. Transport Requirements............................................23
      7.2.2. Enhanced Mobile Email Functionality...............................23
      7.2.3. Client Requirements...............................................24
   
   
   
   
   
   
   
   Wong             Informational - Expires August 2004                2
   
                               LEMONADE Goals               February 2004
   
      7.2.4. Bandwidth Requirements............................................24
      7.2.5. Media Handling Requirements.......................................24
   8. Interoperation with Existing Mobile Messaging............................26
     8.1. Addressing of mobile devices.........................................26
     8.2. Push model of Message Retrieval......................................26
     8.3. Operator Issues......................................................26
      8.3.1. Support for end-to-end delivery reports and read reports..........26
      8.3.2. Support for Selective Downloading.................................26
      8.3.3. Transactions and Operator Charging Units..........................26
      8.3.4. Network Authentication............................................26
   9. Informative References...................................................27
   10. Acknowledgments.........................................................31
   11. Editor's Address........................................................32
   12. Contributors's Addresses................................................33
   
   
   
   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 August 2004                3
   
                               LEMONADE Goals               February 2004
   
   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 recorded voice messages.
           o Fax store-and-forward users interface with a fax machine using a
              modified telephone based interface.  Fax machines use the telephone
              network for transport of fax data via modems.
           o With cellular phones, SMS (Short Message Service) enabled users 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
              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 -- making Internet email transport the common
      infrastructure supporting what were separate messaging universes -- have
      encouraged a new vision: to provide, over the Internet, a single
      infrastructure, mailbox, and set of protocols 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 Lemonade effort -- 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, the evolution of messaging standards for resource
      limited mobile devices has been rapid:
   
           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
              Internet standards (both messaging and web) as well as SMS. The
              cellular messaging universe is a separate infrastructure adapted to
              deliver appropriate functionality in a timely and effective manner
              to a special environment.
   
   
   
   Wong             Informational - Expires August 2004                4
   
                               LEMONADE Goals               February 2004
   
           o As well, the number of different mobile clients that need to be
              supported keeps proliferating. (e.g. besides cellular phones there
              are wireless enabled PDAs, tablet computers, etc.)
   
      These resource limited mobile devices are less powerful both in processing
      speed 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 environment.
   
      The purpose of this document is to discuss issues impeding the IETF email
      protocols from support of the mobile service environment. As a result of
      the discussion considerations are documented and in some cases possible
      approaches to solutions are suggested. It turns out that the enhancements
      to support mobile clients also offer benefits for some terminals in
      different environments. In particular the enhancements address the needs of
      the following diverse clients:
   
           o A wireless handheld device with an email client -- a Wireless User
              Interface (WUI) mode of user interaction 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 mode offered by a POTS set
             o This is a subset of the WUI and is useful in other contexts
           o A Multi-modal messaging client providing a coordinated messaging
              session using display and audio modes simultaneously.  (e.g. a
              system consisting of a PC with a phone or a wireless phone with both
              a voice circuit and data channel requiring coordination).
             o This is also 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 desirable
           o A list of principles to be used to guide the design of Internet
              Messaging for diverse service environments
           o Detailed discussion on enhancements to Internet mail protocols to
              support WUIs.
           o Some issues relating to the interoperation of enhanced Internet mail
              and the existing mobile messaging services
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   Wong             Informational - Expires August 2004                5
   
                               LEMONADE Goals               February 2004
   
   2. Messaging Terminology and Models (Client to Server aspect 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 another.
   
      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 August 2004                6
   
                               LEMONADE Goals               February 2004
   
   
   
   
   
   
   2.2.1. Submission
   
      "Submission" is the transaction between a client and a server by which the
      user of the former 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, the push model has 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 August 2004                7
   
                               LEMONADE Goals               February 2004
   
   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.).  Grouping together features needed to
      support a particular application is to define an Internet Mail profile for
      that application.
   
   3.1. Existing Profiles
   
      The following profiles are examples of 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. Useful Client Profiles
   
   3.2.1. TUI
   
      It is desirable to replace proprietary protocols between telephone user
      interface clients and message stores with standards-based interfaces.  The
      proprietary protocols were created to provide media-aware capabilities as
      well as provide the low-latency required by some messaging applications.
   
      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 is that the voice mail system
      uses a specialized message store and protocols.
   
   
   
   
   
   
   Wong             Informational - Expires August 2004                8
   
                               LEMONADE Goals               February 2004
   
   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 August 2004                9
   
                               LEMONADE Goals               February 2004
   
   
   3.2.2. Multi-modal clients
   
      Multi-modal clients offer the advantage of coordinated voice and data modes
      of user interaction. 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 to which a data channel was
      added. The presentation of multiple complementary modes of interaction
      gives end users their choice of the most convenient and natural working
      mode for a particular task. There are situations where a multi-modal model
      is needed. (E.g., a telephone sales unit needs to provide a voice
      (telephone) mode and conventional desktop PC mode of interaction at the
      same time in an integrated manner.)
   
      A major issue in the design of multi-modal clients is the synchronization
      of the component user agents making up a client.
   
   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 the number of
      over-the-air transactions and reduce the amount of data that needs be
      transmitted over the air overall.  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 OMA.
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   Wong             Informational - Expires August 2004               10
   
                               LEMONADE Goals               February 2004
   
   
   
      Wireless User Interface(WUI)/Multi-modal Clients
   
   
   
   Proposed:
   
          |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 August 2004               11
   
                               LEMONADE Goals               February 2004
   
   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.14.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 August 2004               12
   
                               LEMONADE Goals               February 2004
   
   
      The enhanced messaging framework MUST be able to handle messages created in
      a non-enhanced messaging context, for example, a simple, [RFC 822] text
      message.
   
   
   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.
   
      This issue is not addressed in Lemonade.
   
   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 August 2004               13
   
                               LEMONADE Goals               February 2004
   
   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 (existing) expectations of users with respect to
      security and reliability.
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   Wong             Informational - Expires August 2004               14
   
                               LEMONADE Goals               February 2004
   
   6. Issues and Requirements: TUI subset of WUI
   
   
   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
      protocol.
   
   
   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 protocol, or utilizing an companion
      streaming protocol.
   
      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. (i.e. to avoid re-
      opening files and seeking to requested pointer)
   
      Alternatively, the client can use the proposed IMAP channel extension to
      request that the server make the selected content available via an alternate
      transport mechanism.  A client can then 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.
   
   6.1.1.2. 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"
      encoding.
   
      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 August 2004               15
   
                               LEMONADE Goals               February 2004
   
   
   
      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.        6.1.2.1. Mailbox Summary Support
   
      The common TUI prompt, "you have two new voice messages, six unheard
      messages, and one new fax message" requires more information than is
      conveniently made available by current message retrieval protocols.
   
      The existing IMAP protocolÆs mailbox status command does not include a
      count by message context. 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.
   
   6.1.2.2.        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 does not support this directly. A straightforward solution is to
      define an extensible sort mechanism for sorting on arbitrary header
      contents.
   
    6.1.2.3.        6.1.2.3. Status of Multiple Mailboxes Support
   
      Extension mailbox support requires the ability to efficiently status a
      mailbox other than the one currently logged into.  This 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.
   
   
   Wong             Informational - Expires August 2004               16
   
                               LEMONADE Goals               February 2004
   
      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.4. 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.
   
   
   6.1.2.5. CLID Restriction indication/preservation
   
      Many calling features are dependent upon collected caller-ID information.
      Trusted clients such as the TUI, and other service supporting 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 appropriate.
   
      Further, when sending messages between servers within a network, a means of
      communicating trust is needed 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.
   
   6.1.2.6. Support for Multiple Access to Mailbox
   
      If the telephone answering application client uses IMAP4 for greeting
       access and message deposit, it is essential that the server 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
   
   
   
   Wong             Informational - Expires August 2004               17
   
                               LEMONADE Goals               February 2004
   
   6.2.1. Forward without Download Support
   
      It is common to forward messages, or to reply to messages with a copy of
      their 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.
   
      Another approach is to add a limited message assembly and submission
      capability to the IMAP server. This approach muddies the distinction
      between the message submission protocol and the message store and retrieval
      one (IMAP) since now message submission may be a side effect of message
      store commands.
   
   
   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 message.
   
      Clear security issues are involved to prevent the misidentification 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 system 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 the prevention of multiple (large) messages of one
      type (e.g. email messages) from consuming all available quota so that
      messages of another type (e.g. voice or fax messages) cannot be further
      deposited to the mailbox.
   
      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 by extensions to the SMTP-submit or LMTP protocols.
   
   
   6.2.3. Future Delivery Support with Cancel
   
   
   
   Wong             Informational - Expires August 2004               18
   
                               LEMONADE Goals               February 2004
   
      Traditionally messages sent with "future delivery" are held in the
      recipients client "outbox" or equivalent until the appointed submission
      time.  Thin clients used with TUIs do not have such persistent storage or
      may be intermittently connected 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 messages are sent when they are
      intended.
   
      Some of the architectural issues here are the same as the ones for Forward
      without Download [ 6.2.1].
   
   
   6.2.4. 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.  The 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 that 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
      recipientÆs inbox.  This append must be done by a special super-user with
      write permissions into the recipient 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.3. Requirements on Message Notification
   
      Clients keep local information about the IMAP store. This information must
      be kept synchronized with the situation in the store.
   
      E.g. Voicemail systems traditionally notify subscribers of certain events
      happening in their mailbox. It is common to send an SMS, or a pager
   
   Wong             Informational - Expires August 2004               19
   
                               LEMONADE Goals               February 2004
   
      notification for each message arrival event, message read event, mailbox
      full event, etc.
   
      When implemented over IMAP-based message stores, the voice mail client
      needs to be notified about these events. Furthermore, when other
      applications access/manipulate the store, these events need to be
      communicated to the mail client. In some cases, the client needs to notify
      the user immediately. In most cases it is a question of maintaining
      client/application consistency. In the case of a multimodal client, it is
      especially important providing a means of coordinating the clientÆs
      different modal views of the state of the store.
   
      E-mail systems have traditionally polled to update this information. There
      may be advantages to an event based approach in some cases.
   
      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
      specified.
   
      The design for this MUST take into account the IAB general guidelines for
      notification services(TBD).
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   Wong             Informational - Expires August 2004               20
   
                               LEMONADE Goals               February 2004
   
   7. Issues and Requirements: WUI Mobility Aspects
   
   7.1. Wireless Considerations on Email
   
   7.1.1. Transport Considerations
   
      Compared to a LAN/WAN configuration or even to a wire-line dial-up
      connection, the probability of an interruption to a wireless 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 the deviceÆs 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 August 2004               21
   
                               LEMONADE Goals               February 2004
   
      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) files -- encountered in multi-media attachments such as presentations,
      images and documents -- to be downloaded even though mobiles 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 download only
      selected 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 allow 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.
   
   7.1.4.3. Handset Type Variety
   
   
   Wong             Informational - Expires August 2004               22
   
                               LEMONADE Goals               February 2004
   
      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.
   
      The mobile email protocol MUST support the ability to forward a message
      without retrieving it.
   
   Wong             Informational - Expires August 2004               23
   
                               LEMONADE Goals               February 2004
   
   
      This requirement is identical to the TUI requirement that is described in
      section 6.2.16.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.16.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 possible optimization is to make the mobile email protocol itself
      simple containing as little overhead as possible.
   
      A third approach is to minimize the bandwidth usage as described in section
      [6.1.1.26.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
   
       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.
   
   
   Wong             Informational - Expires August 2004               24
   
                               LEMONADE Goals               February 2004
   
      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 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.17.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 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 August 2004               25
   
                               LEMONADE Goals               February 2004
   
   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
      recipient mobiles. 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
      different.
   
   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.1].
   
   8.3.4. Network Authentication
   
      Some mobile networks support network authentication as well as application
      authentication.
   
   
   
   
   
   
   
   
   
   
   
   
   Wong             Informational - Expires August 2004               26
   
                               LEMONADE Goals               February 2004
   
   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 1996
   
      [RFC2049] Freed, N. and Borenstein, N. "Multipurpose Internet Mail
      Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC2049,
      November 1996
   
      [RFC2060] Crispin, M. "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1",
      RFC2060, December 1996
   
      [RFC2086] Myers, J. "IMAP4 ACL extension" January 1997.
      (Status: PROPOSED STANDARD)
   
      [RFC2087] Myers, J. "IMAP4 QUOTA extension" January 1997.
      (Status: PROPOSED STANDARD)
   
      [RFC2221] Gahrns, M.  IMAP4 Login Referrals. October 1997.
      (Status: PROPOSED STANDARD)
   
      [RFC2298] R. Fajman, "An Extensible Message Format for Message Disposition
      Notifications", RFC 2298, March 1998.
   
   
   Wong             Informational - Expires August 2004               27
   
                               LEMONADE Goals               February 2004
   
      [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
   
      [RFC2476] Gellens, R. and Klensin J. "Message Submission", December 1998.
      (Status: PROPOSED STANDARD)
   
      [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
      2001.
   
      [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
   
   
   Wong             Informational - Expires August 2004               28
   
                               LEMONADE Goals               February 2004
   
   
      [CHAN] "IMAP4 Channel Transport Mechanism", 11/27/2001,
      <draft-nerenberg-imap-channel-01.txt>, work in progress
   
      [CONNEG] Toyoda, K. and Crocker, D., "SMTP Service Extensions for Fax
      Content Negotiation", DRAFT-FAX-ESMTP-CONNEG-06.TXT, February 2003, work in
      progress.
   
      [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-
      01.txt
   
      [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, 2002
   
   Wong             Informational - Expires August 2004               29
   
                               LEMONADE Goals               February 2004
   
   
      [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
   
      [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 August 2004               30
   
                               LEMONADE Goals               February 2004
   
   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
      requirements.
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   Wong             Informational - Expires August 2004               31
   
                               LEMONADE Goals               February 2004
   
   11. 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 August 2004               32
   
                               LEMONADE Goals               February 2004
   
   12. Contributors'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
   
      Yair Grosu
      Comverse
      29 Habarzel St.
      Tel-Aviv 69710
      Israel
      Email: Yair.Grosu@comverse.com
   
      Glenn Parsons
      Nortel Networks
      P.O. Box 3511, Station C
      Ottawa, ON K1Y 4H7
      Canada
      Phone: +1-613-763-7582
      Email: gparsons@nortelnetworks.com
   
      Milt Roselinsky
      Openwave Systems, Inc.
      530 E. Montecito St.
      Santa Barbara, CA 93103
      Phone: 805-884-6207
      Email: milt.roselinsky@openwave.com
   
      Dan Shoshani
      Comverse
      29 Habarzel St.
      Tel-Aviv 69710
      Israel
      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 August 2004               33
   
                               LEMONADE Goals               February 2004
   
   Full Copyright Statement
   
      Copyright (C) The Internet Society (2004).  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
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   Wong             Informational - Expires August 2004               34
   

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