GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc4416

Network Working Group J. Wong, Ed. Request for Comments: 4416 Nortel Networks Category: Informational February 2006

  Goals for Internet Email to Support Diverse Service Environments

Status of This Memo

 This memo provides information for the Internet community.  It does
 not specify an Internet standard of any kind.  Distribution of this
 memo is unlimited.

Copyright Notice

 Copyright (C) The Internet Society (2006).

Abstract

 This document is a history capturing the background, motivation and
 thinking during the LEMONADE definition and design process.
 The LEMONADE Working Group -- Internet email to support diverse
 service environments -- is chartered to provide enhancements to
 Internet mail to facilitate its use by more diverse clients.  In
 particular, by clients on hosts not only operating in environments
 with high latency/bandwidth-limited unreliable links but also
 constrained to limited resources.  The enhanced mail must be
 backwards compatible with existing Internet mail.
 The primary motivation for this effort is -- by making Internet mail
 protocols richer and more adaptable to varied media and environments
 -- to allow mobile handheld devices tetherless access to Internet
 mail using only IETF mail protocols.
 The requirements for these devices drive a discussion of the possible
 protocol enhancements needed to 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, additional issues of providing
 seamless service between enhanced Internet mail and the existing
 separate mobile messaging infrastructure are briefly listed.

Wong Informational [Page 1] RFC 4416 LEMONADE Goals February 2006

Table of Contents

 1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
 2.  Conventions Used in This Document  . . . . . . . . . . . . . .  6
 3.  Messaging Terminology and Simple Model (Client-to-Server
     Aspect Only) . . . . . . . . . . . . . . . . . . . . . . . . .  6
   3.1.  Messaging Transaction Models . . . . . . . . . . . . . . .  6
   3.2.  Mobile Messaging Transactions  . . . . . . . . . . . . . .  7
     3.2.1.  Submission . . . . . . . . . . . . . . . . . . . . . .  7
     3.2.2.  Notification . . . . . . . . . . . . . . . . . . . . .  7
     3.2.3.  Retrieval  . . . . . . . . . . . . . . . . . . . . . .  8
 4.  Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
   4.1.  Existing Profiles  . . . . . . . . . . . . . . . . . . . .  8
     4.1.1.  Voice Messaging (VPIMv2) . . . . . . . . . . . . . . .  8
     4.1.2.  iFax . . . . . . . . . . . . . . . . . . . . . . . . .  9
     4.1.3.  Internet Voice Mail (IVM)  . . . . . . . . . . . . . .  9
   4.2.  Putative Client Profiles . . . . . . . . . . . . . . . . .  9
     4.2.1.  TUI  . . . . . . . . . . . . . . . . . . . . . . . . .  9
     4.2.2.  Multi-Modal Clients  . . . . . . . . . . . . . . . . . 11
     4.2.3.  WUI  . . . . . . . . . . . . . . . . . . . . . . . . . 11
 5.  General Principles . . . . . . . . . . . . . . . . . . . . . . 13
   5.1.  Protocol Conservation  . . . . . . . . . . . . . . . . . . 13
     5.1.1.  Reuse Existing Protocols . . . . . . . . . . . . . . . 13
     5.1.2.  Maintain Existing Protocol Integrity . . . . . . . . . 13
   5.2.  Sensible Reception/Sending Context . . . . . . . . . . . . 13
     5.2.1.  Reception Context  . . . . . . . . . . . . . . . . . . 13
     5.2.2.  Sending Context  . . . . . . . . . . . . . . . . . . . 13
   5.3.  Internet Infrastructure Preservation . . . . . . . . . . . 14
   5.4.  Voice Requirements (Near Real-Time Delivery) . . . . . . . 14
   5.5.  Fax Requirements (Guaranteed Delivery) . . . . . . . . . . 14
   5.6.  Video Requirements (Scalable Message Size) . . . . . . . . 14
 6.  Issues and Requirements: TUI Subset of WUI . . . . . . . . . . 14
   6.1.  Requirements on the Message Retrieval Protocol . . . . . . 14
     6.1.1.  Performance Issues . . . . . . . . . . . . . . . . . . 15
     6.1.2.  Functional Issues  . . . . . . . . . . . . . . . . . . 16
   6.2.  Requirements on the Message Submission Protocol  . . . . . 18
     6.2.1.  Forward without Download Support . . . . . . . . . . . 18
     6.2.2.  Quota by Context Enforcement . . . . . . . . . . . . . 19
     6.2.3.  Future Delivery Support with Cancel  . . . . . . . . . 19
     6.2.4.  Support for Committed Message Delivery . . . . . . . . 20
   6.3.  Requirements on Message Notification . . . . . . . . . . . 20
     6.3.1.  Additional Requirements on Message Notification  . . . 21
 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  . . . . . . . . . 22
     7.1.3.  Wireless Bandwidth and Network Utilization
             Considerations . . . . . . . . . . . . . . . . . . . . 22

Wong Informational [Page 2] RFC 4416 LEMONADE Goals February 2006

     7.1.4.  Content Display Considerations . . . . . . . . . . . . 23
   7.2.  Requirements to Enable Wireless Device Support . . . . . . 24
     7.2.1.  Transport Requirements . . . . . . . . . . . . . . . . 24
     7.2.2.  Enhanced Mobile Email Functionality  . . . . . . . . . 24
     7.2.3.  Client Requirements  . . . . . . . . . . . . . . . . . 25
     7.2.4.  Bandwidth Requirements . . . . . . . . . . . . . . . . 25
     7.2.5.  Media Handling Requirements  . . . . . . . . . . . . . 25
 8.  Interoperation with Existing Mobile Messaging  . . . . . . . . 27
   8.1.  Addressing of Mobile Devices . . . . . . . . . . . . . . . 27
   8.2.  Push Model of Message Retrieval  . . . . . . . . . . . . . 27
   8.3.  Message Notification . . . . . . . . . . . . . . . . . . . 27
   8.4.  Operator Issues  . . . . . . . . . . . . . . . . . . . . . 27
     8.4.1.  Support for End-to-End Delivery Reports and
             Message-Read Reports . . . . . . . . . . . . . . . . . 27
     8.4.2.  Support for Selective Downloading  . . . . . . . . . . 27
     8.4.3.  Transactions and Operator Charging Units . . . . . . . 27
     8.4.4.  Network Authentication . . . . . . . . . . . . . . . . 28
   8.5.  LEMONADE and MMS . . . . . . . . . . . . . . . . . . . . . 28
 9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 32
 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
   10.1. Normative References . . . . . . . . . . . . . . . . . . . 32
   10.2. Informative References . . . . . . . . . . . . . . . . . . 32
 Appendix A.  Contributors  . . . . . . . . . . . . . . . . . . . . 37
 Appendix B.  Acknowledgements  . . . . . . . . . . . . . . . . . . 38
 Appendix C.  IAB Note: Unified Notification Protocol
              Considerations  . . . . . . . . . . . . . . . . . . . 38

Wong Informational [Page 3] RFC 4416 LEMONADE Goals February 2006

1. Introduction

 Historically, a number of separate electronic messaging systems
 originated and evolved independently supporting different messaging
 modes.  For example:
 o  Internet mail systems ([4], [10], [25]) evolved to support
    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  SMS (Short Message Service) [58] enabled users to send short text
    messages between their cellular phones using the SS7 call control
    infrastructure ([60], [61], [63], [64], [65]) for transport.
 In the recent past, IETF mail standards have evolved to support
 additional/merged functionality:
 o  With MIME ([5], [6], [7], [8], [9], [28]), Internet mail transport
    was enhanced to carry any kind of digital data
 o  Internet mail protocols were extended and profiled by VPIM ([13],
    [14], [15], [34]) and iFAX ([16], [17], [18], [19], [20], [21],
    [23]) 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 was not diminished by transport over
    the Internet.
 These successes -- making Internet mail 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 ([46],[47]).
 The LEMONADE effort -- Internet email 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.

Wong Informational [Page 4] RFC 4416 LEMONADE Goals February 2006

 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) [59] allowing longer text messages, images, and graphics.
    With an even richer feature set, MMS (Multimedia Messaging
    Service) ([43], [52], [53], [56], [57]) 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 [24]) 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.
 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 and reliability are lower, latency is longer, and
 costs are higher than those of traditional wire-line links, hence the
 stress on the need to support adaptation to a whole different service
 environment.
 This document collects a number the issues impeding Internet mail
 protocols from directly supporting the mobile service environment.
 Considerations arising from these issues 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 other 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 mobile wireless handheld operating environment.
 o  Telephone-based voice client -- a Telephone User Interface (TUI),
    this is the user mode offered by a POTS set
    *  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).
    *  This is also a subset of the WUI and is useful in other
       contexts.

Wong Informational [Page 5] RFC 4416 LEMONADE Goals February 2006

 The rest of this document is structured as follows:
 o  A brief survey of messaging profiles - both existing and proposed.
 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.

2. Conventions Used in This Document

 This document refers generically to the sender of a message in the
 masculine (he/him/his) and to 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.
 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 [1].

3. Messaging Terminology and Simple Model (Client-to-Server Aspect

  Only)
 In the client-server model 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.
 For a definitive description of Internet mail architecture, see [42].

3.1. Messaging Transaction Models

 There are two basic transactional models.  In the "pull" model, the
 component, rather than the data flow, initiates the transaction.  For
 example, 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.  For
 example, the arrival of a new message at the terminating server may
 cause a notification to be sent ("pushed") to a messaging client.

Wong Informational [Page 6] RFC 4416 LEMONADE Goals February 2006

3.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 depicts a simple client-server model (no server-
 to-server interactions are 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

3.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.

3.2.2. Notification

 "Notification" is the transaction by which the server notifies the
 client that it has received messages intended for that client.
 Notification is a push from server to client.

Wong Informational [Page 7] RFC 4416 LEMONADE Goals February 2006

 All the larger mobile messaging systems implement a push model for
 the notification because data can be presented to the user without
 the user's experiencing network/transport latencies, and without
 tying up network resources for polling when there is no new data.
 Internet mail differs in that it has not yet seen the need for a
 standardized notification protocol.

3.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 that the user is not necessarily 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.

4. Profiles

 Internet messaging can be made to 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
 number of Internet mail profiles supporting specific application
 niches have been defined or proposed.

4.1. Existing Profiles

 The following are examples of server-to-server profiles of SMTP and
 MIME.  Except for IVM, they do not address client-to-server
 interactions.

4.1.1. Voice Messaging (VPIMv2)

 These profiles, RFC3801 [13] to RFC3803 [15], 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

Wong Informational [Page 8] RFC 4416 LEMONADE Goals February 2006

 Notification and Delivery Status Message ([12], [3]).  Voice media
 has also been added to multi-part message bodies.

4.1.2. iFax

 This set of profiles ([16], [17], [18], [19], [20], [21]) 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.

4.1.3. Internet Voice Mail (IVM) [34]

 This proposed mail enhancement (whose requirements are described in
 RFC 3773 [30]) targets support for the interchange of voice messaging
 between the diverse components (clients as well as servers) in
 systems supporting voice mail.

4.2. Putative Client Profiles

4.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 to provide the low-latency required by
 some messaging applications.
 An example of a TUI client is a voice mail client.  Because a POTS
 phone lacks any intelligence, 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.
 The following figure depicts the architecture of current voice mail
 systems implementing VPIMv2:

Wong Informational [Page 9] RFC 4416 LEMONADE Goals February 2006

                                                |-------------|
            |-------|     RFC-822/MIME          |             |
            |   |   |---------------------------|     MTA     |
            |   |   |     mail submission ->    |             |(E)SMTP
 Telephone--|TUI|TUA|                           |------|      |-----to
            |   |   |   Proprietary Protocol    |      |      |another
            |   |   |---------------------------| MS   |      | email
            |-------|   < - mail retrieval      |      |      | server
                                                |-------------|
            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
            |   |   |     IETF protocol         |      |      |another
            |   |   |---------------------------| MS   |      | mail
            |-------|    <- mail retrieval      |      |      | server
                                                |-------------|
            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 [Page 10] RFC 4416 LEMONADE Goals February 2006

4.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 the next figure.  The
 Graphical User Agent (GUA) helps maintain the text display while the
 Telephone User Agent (TUA) acts on behalf of the TUI functionality.
 This model is the norm with cellular devices supporting data access
 because historically they evolved 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 other
 situations where a multi-modal model is appropriate.  (For example, 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 -- the need to
 synchronize the component user agents making up a client -- is only
 addressed by LEMONADE to a limited extent in Section 6.3.

4.2.3. WUI

 The Wireless User Interface is functionally equivalent to a
 conventional email client on a personal workstation, but is optimized
 for clients on handheld tetherless devices.  Factors needing
 consideration include limited memory and processing power.  Limited
 bandwidth is also relatively high cost.  As already alluded to above,
 in many cases (e.g., cellular devices), the mobile client is
 multi-modal.  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 need
 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, whereby a user may more
 intelligently select what should be downloaded and what should remain
 on the server.
 Although not an explicit goal, providing equivalent or superior
 functionality to the wireless MMS service [43] (as defined by 3GPP,
 3GPP2, and the OMA) is desirable.

Wong Informational [Page 11] RFC 4416 LEMONADE Goals February 2006

 Proposed 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
          | |   |   | IETF standard protocol    |------------ |another
          | |   |   |----------------------------to MS below| | mail
          | |-------|    <- mail retrieval      |------------ | server
          |       |                             |             |
 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 [Page 12] RFC 4416 LEMONADE Goals February 2006

5. General Principles

 This is a list of principles to guide the design of extensions for
 Internet Messaging systems and protocols to support diverse
 endpoints.

5.1. Protocol Conservation

5.1.1. Reuse Existing Protocols

 To the extent feasible, the enhanced messaging framework SHOULD use
 existing protocols whenever possible.

5.1.2. Maintain Existing Protocol Integrity

 In meeting the requirement "Reuse Existing Protocols"
 (Section 5.1.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.

5.2. Sensible Reception/Sending Context

5.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.

5.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 text message, voice message, video message, etc.
 Again, this can only be complied with to the extent that the
 infrastructure and receiving client can provide such treatment.  In
 practice, this would imply that the message should be in the form
 desired by the sender up to delivery to the receiving client.

Wong Informational [Page 13] RFC 4416 LEMONADE Goals February 2006

5.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 to allow for the gradual introduction of the enhancements.
 Messages created in an enhanced messaging context MUST NOT require
 changes to existing mail clients.  However, there may be a
 degradation in functionality in certain circumstances.
 The enhanced messaging framework MUST be able to handle messages
 created in a non-enhanced messaging context; for example, a simple,
 RFC822 [2] text message.

5.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.

5.5. Fax Requirements (Guaranteed Delivery)

 Fax users have a particular expectation that is a challenge for
 enhanced Internet messaging.  A person who sends a fax expects the
 recipient to receive the fax upon successful transmission.  This
 clearly is not the case for Internet Mail.
 Addressing this need is not in the scope of LEMONADE.

5.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, in
 both directions, MUST be supported.

6. Issues and Requirements: TUI Subset of WUI

6.1. Requirements on the Message Retrieval Protocol

 IMAP [10] is the Internet protocol for rich message retrieval and
 manipulation.  The project MUST limit itself to extending IMAP where
 necessary and MUST not create a new protocol.

Wong Informational [Page 14] RFC 4416 LEMONADE Goals February 2006

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 a
 companion streaming protocol.
 The IMAP protocol itself does not provide streaming by 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.  Thus, it would not require the full download
 of contents.  This approach may require server-side development to
 support partial download efficiently (i.e., to avoid re-opening files
 and positioning to the requested location).
 Alternatively, the client can use the proposed IMAP channel extension
 [32] 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 Content-Transfer-Encoding Data Inflation

 Another important performance optimization is enabling the transport
 of data using more efficient native coding rather than text-like
 content-transfer encodings such as "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.  Downloading or appending large
 messages to the server already uses substantial bandwidth.

Wong Informational [Page 15] RFC 4416 LEMONADE Goals February 2006

 Possible Solutions:
 Where IMAP channel is appropriate, the external channel may be binary
 capable; that is, the external access may not require re-encoding.
 Mechanisms such as HTTP [24], FTP, or RTSP are available for this
 download.
 The IMAP binary extension standards proposal [31] extends the IMAP
 fetch command to retrieve data in the binary form.  This is
 especially useful for large attachments and other binary components.
 Binary in conjunction with a streaming client implementation may be
 an attractive alternative to the channel extension.

6.1.2. Functional Issues

6.1.2.1. Mailbox Summary Support

 The common TUI prompt, "you have two new voice messages, six unheard
 messages, and one new fax message", requires more information than is
 conveniently made available by current message retrieval protocols.
 The existing IMAP protocol's mailbox status command does not include
 a count by message context [26] [27].  A possible solution is for the
 mail server to 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
 predetermined 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. 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", Section 6.1.2.1.
 IMAP does not support this directly.  A straightforward solution is
 to define an extensible sort mechanism for sorting on arbitrary
 header contents.

Wong Informational [Page 16] RFC 4416 LEMONADE Goals February 2006

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.
 Current mechanisms are limited to logging into each of set of
 mailboxes, checking status, logging out, and repeating until all
 sub-mailboxes are processed.

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 predetermined mailboxes with specific behaviors (e.g.,
 Outbox, Sent Items, Deleted Items, Expired Items, Drafts).
 IMAP provides only a single standardized folder, the inbox.  This
 functionality does not require new protocol additions per se, but
 standardized usage and naming conventions are necessary for
 interoperability.  This functionality requires 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 on collected caller-ID
 information.  Clients -- such as the TUI and other service supporting
 user agents (e.g., WEB and WAP servers) -- may need trusted access to
 restricted caller-ID information for such purposes as callback.
 Untrusted clients must not be permitted to receive this information.
 A mechanism for establishing "trust" between appropriate clients and
 the server is required to restrict delivery of this information to
 the end-user only as allowed.
 Further, when messages are sent between servers within a network, a
 means of communicating trust is needed so that the identity of the
 sender can be preserved for record-keeping and certain features while
 ensuring that the identity is not disclosed to the recipient in an
 inappropriate way.

Wong Informational [Page 17] RFC 4416 LEMONADE Goals February 2006

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 voice mail for an
 incoming call to be serviced by the telephone answering application
 client at the same time the subscriber is logged into her mailbox.
 Further, new applications such as WEB and WAP access to voice mail
 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.  RFC2180 [29] describes a candidate set of
 conventions necessary to support this multiple-access technique.  It
 or some other method MUST be standardized as part of LEMONADE.

6.2. Requirements on the Message Submission Protocol [22]

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 URLs within a
 message before relaying the message to the final destination.  This
 approach is referred to as the pull approach because the message
 submission server must pull data from the IMAP server.
 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 that for message storage
 and retrieval (IMAP) because now message submission may be a side
 effect of message store commands.  This approach is referred to as
 the push approach because in this case the IMAP server pushes data to
 the message submission server.
 A detailed analysis of which of the two approaches is preferable as
 well as implementation details of both can be found in references
 [36], [37], [38], [39], [40], and [41].

Wong Informational [Page 18] RFC 4416 LEMONADE Goals February 2006

6.2.2. Quota by Context Enforcement

 It is common in a unified messaging system to offer separate quotas
 [11] 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.
 An obvious security issue needing consideration is the prevention of
 the deliberate misidentification of a message context with the
 intention of overflowing a subscriber's mailbox.  It is envisioned
 that the message submission protocol will require the authentication
 of trusted submission agents allowing only those so 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.
 Similar to the required 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.  Consumption of all quota by one type prevents the delivery of
 other types (e.g., voice or fax messages) to the mailbox.
 One possible approach is to 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[35] protocols.

6.2.3. Future Delivery Support with Cancel

 Traditionally messages sent with "future delivery" are held in the
 recipient's client "outbox" or its 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 SMTP are required for viewing and manipulating
 the outbound queue, for such purposes as canceling a future message.
 Server support for managing such a queue is required so that messages
 are sent when they are intended.

Wong Informational [Page 19] RFC 4416 LEMONADE Goals February 2006

 Some of the architectural issues here are the same as those in
 "Forward without Download Support" (Section 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 message 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.  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[35]).  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 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.
 However, the architectural issues raised by this approach are
 significant.  See "Forward without Download Support" (Section 6.2.1).

6.3. Requirements on Message Notification

 Clients keep local information about the IMAP store.  This
 information must be kept synchronized with the state of the store.
 For example, voice mail systems traditionally notify subscribers of
 certain events happening in their mailbox.  It is common to send an
 SMS or a pager notification for each message arrival event, message
 read event, mailbox full event, etc.

Wong Informational [Page 20] RFC 4416 LEMONADE Goals February 2006

 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 to provide a means of
 coordinating the client's different modal views of the state of the
 store.
 Email systems have traditionally polled to update this information.
 There may be advantages to an event-driven approach in some cases.
 The standards community is working on a standard for bulk
 server-to-client status notification.  An example of such work is the
 Simple Notification and Alarm Protocol (SNAP) [45], which defines the
 expected behavior of the message store for various events, many of
 them triggered by IMAP commands.

6.3.1. Additional Requirements on Message Notification

 A format for message notification 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 note: "Unified
 Notification Protocol Considerations" (Appendix C).

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 handoff, signal fading, or stepping
 beyond cell coverage.
 In addition, because the mobile handset is also used for other types
 of communications, there is a 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.

Wong Informational [Page 21] RFC 4416 LEMONADE Goals February 2006

 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 have only a rudimentary keyboard (a keypad) and a
       rudimentary pointing device (a text cursor).

7.1.3. Wireless Bandwidth and Network Utilization Considerations

7.1.3.1. 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
 files (up to several MBs) -- encountered in multi-media attachments
 such as presentations, images, voice, and video -- to be downloaded
 even though mobiles cannot 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 Sensitivity

 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 they do over a wire-line service.  Users are

Wong Informational [Page 22] RFC 4416 LEMONADE Goals February 2006

 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.  This is a consequence of handset
 limitations (Section 7.1.2), wireless media and bandwidth issues
 (Section 7.1.1 and Section 7.1.3.1), and price sensitivity
 (Section 7.1.3.2).

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 in order to be suitably displayed.

7.1.4.2. Supported Media Formats

 Wireless handsets can only display a limited set of media format
 types.  Although PC clients support a large variety of document types
 (and allow on-demand "codec"/player download), mobiles have very
 limited support.  (For example, 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), is not expected
 to be widespread in the near future.

7.1.4.3. Handset Type Variety

 As mentioned above, there are many handset types available in the
 market, and each has different display capabilities, screen
 characteristics, and processing capabilities.  The mobile email
 service should be able to support as many handset types as possible.

Wong Informational [Page 23] RFC 4416 LEMONADE Goals February 2006

7.1.4.4. Specific Attachment Display Scenarios

 Handsets are unsuitable for perusing entire lengthy documents or
 presentations.  Rather than go through the whole document, 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).
 Therefore, there is a need to enable users to download not the entire
 attachment but rather just a selected part of it.  For example, 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 or 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 recover (restore state) from
 interrupted connections quickly and easily.
 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 [Page 24] RFC 4416 LEMONADE Goals February 2006

 This requirement is identical to the TUI requirement described in
 "Forward Without Download Support" (Section 6.2.1).

7.2.2.2. Media Streaming

 The mobile email protocol MUST provide a solution that will enable
 media streaming to the wireless handset.
 This requirement is similar to the TUI requirement described in
 "Real-Time Playback" (Section 6.1.1.1).

7.2.3. Client Requirements

 IMAP4 clients are large because IMAP4 already consists of a complex
 set of functions (e.g., parsing of a broad variety of MIME formats).
 The mobile email client should be:
 o  Small in size
 o  Efficient in CPU consumption
 o  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 to support.  However, any such simplification MUST NOT
 limit interoperability with full IMAP servers.

7.2.4. Bandwidth Requirements

 The mobile email solution should minimize the amount of data
 transmitted over the air.  There are several ways of pursuing this
 goal that can be used in conjunction.
 One way is the use of content transcoding and media adaptation by the
 server before message retrieval in order to optimize the message 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
 "Avoid Content-Transfer-Encoding Data Inflation" (Section 6.1.1.2).

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.

Wong Informational [Page 25] RFC 4416 LEMONADE Goals February 2006

7.2.5.1. Device Capabilities Negotiation

 In order to support the different characteristics and capabilities of
 the various handset types available in the market correctly, 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[33]) 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 "Device Capabilities Negotiation"
 (Section 7.2.5.1).  For example, a device that cannot display GIF
 format, and can only display 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 transcoding, if any, 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[33]) may address this issue.

7.2.5.3. Handling Attachment Parts

 A desirable feature (but out of scope for the current LEMONADE
 charter) is to enable users the choice of retrieving parts of an
 attachment file, not just the entire attachment.  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 [Page 26] RFC 4416 LEMONADE Goals February 2006

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 [62] 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 [49] [50] [51]

 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 to that of MMS is
 desired, this mode of operation should be considered.

8.3. Message Notification [44] [55]

 Message notification was alluded to in "Requirements on Message
 Notification" (Section 6.3).  Internet mail has not so far
 standardized a server-to-client notification protocol although most
 existing wireless mail systems use notification to avoid needless
 polling.  Client-to-server notification is not within the LEMONADE
 charter.

8.4. Operator Issues

8.4.1. Support for End-to-End Delivery Reports and Message-Read Reports

 Support for committed delivery is described in Section 6.2.4, but
 this is different.

8.4.2. Support for Selective Downloading

 If a push model of message retrieval is supported, the need for
 selective downloading and SPAM control is especially important.

8.4.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

Wong Informational [Page 27] RFC 4416 LEMONADE Goals February 2006

 positive end-to-end acknowledgement of delivery or non-delivery of
 messages already mentioned in Section 8.4.1.  Note that billing is
 specifically outside the scope of the IETF.

8.4.4. Network Authentication

 Some mobile networks require network authentication as well as
 application authentication.

8.5. LEMONADE and MMS

 The 3GPP MMS Reference Architecture ([48] [54]) defines seven
 interfaces labelled MM1 to MM7, as below:

Wong Informational [Page 28] RFC 4416 LEMONADE Goals February 2006

                 3GPP MMS Reference Architecture (subset)
          |---------|                          |------------|
 wireless ||-------||                          |            |
  device  || MMS   ||                          |            |<- MM2 ->
          || USER  |---------------------------|            |---------
          || AGENT |<-         MM1           ->|            | to
          ||-------||                          |            | another
          |---------|                          |            | MMS
                                               |            | relay/
           |--------|                          |            | server
    e.g.,  |        |                          |            |
    Email, |EXTERNAL|                          |            |
    Fax, or| SERVER |--------------------------|            |
    UMS    |        |<-        MM3           ->|            |
           |--------|                          |            |
                                               |            |
           |---------|                         |            |
           |"FOREIGN"|                         |            |
           | MMS     |-------------------------|            |
           | relay/  |<-       MM4           ->|            |
           | server  |                         |            |
           |---------|                         |            |
                                               |    MMS     |
           |-------|                           |relay/server|
           |       |                           |            |
           |  HLR  |---------------------------|            |
           |       |<-         MM5           ->|            |
           |-------|                           |            |
                                               |            |
           |-------|                           |            |
           |  MMS  |                           |            |
           |  USER |---------------------------|            |
           |  DBs  |<-         MM6           ->|            |
           |-------|                           |            |
                                               |            |
           |-------|                           |            |
           |  MMS  |                           |            |
           |  VAS  |---------------------------|            |
           |  APPs |<-         MM7           ->|            |
           |-------|                           |------------|
     MMS - Multimedia Messaging Service
     UMS - Unified Messaging Service
     HLR - Home Location Register
     DB  - Data Base
     VAS - Value Added Service
     APP - Application

Wong Informational [Page 29] RFC 4416 LEMONADE Goals February 2006

 The LEMONADE profile provides an enhanced IMAP mail retrieval
 protocol suitable for use at interfaces MM1 and MM3.
 In addition, if the wireless device uses a LEMONADE-enhanced IMAP
 user agent, the enhanced IMAP protocol can be used to access Internet
 mail directly, as below.

Wong Informational [Page 30] RFC 4416 LEMONADE Goals February 2006

                 3GPP MMS Reference Architecture (subset)
          |---------|                          |------------|
 wireless ||-------||                          |            |
  device  || IMAP  ||                          |            |<- MM2 ->
          || USER  ||                          |            |---------
          || AGENT ||                          |            | to
          ||---^---||                          |            | another
          |----|---||                          |            | MMS
               | LEMONADE Enhanced IMAP and    |            | relay/
           |---V----|          SMTP            |            | server
    e.g.,  |        |                          |            |
    Email, |EXTERNAL|                          |            |
    Fax, or| SERVER |--------------------------|            |
    UMS    |        |<-        MM3           ->|            |
           |--------|                          |            |
                                               |            |
           |---------|                         |            |
           |"FOREIGN"|                         |            |
           | MMS     |-------------------------|            |
           | relay/  |<-       MM4           ->|            |
           | server  |                         |            |
           |---------|                         |            |
                                               |    MMS     |
           |-------|                           |relay/server|
           |       |                           |            |
           |  HLR  |---------------------------|            |
           |       |<-         MM5           ->|            |
           |-------|                           |            |
                                               |            |
           |-------|                           |            |
           |  MMS  |                           |            |
           |  USER |---------------------------|            |
           |  DBs  |<-         MM6           ->|            |
           |-------|                           |            |
                                               |            |
           |-------|                           |            |
           |  MMS  |                           |            |
           |  VAS  |---------------------------|            |
           |  APPs |<-         MM7           ->|            |
           |-------|                           |------------|
     MMS - Multimedia Messaging Service
     UMS - Unified Messaging Service
     HLR - Home Location Register
     DB  - Data Base
     VAS - Value Added Service
     APP - Application

Wong Informational [Page 31] RFC 4416 LEMONADE Goals February 2006

9. 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 to meet the (existing) expectations of users
 with respect to security and reliability.

10. References

10.1. Normative References

 [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
      Levels", BCP 14, RFC 2119, March 1997.

10.2. Informative References

 [2]   Crocker, D., "Standard for the format of ARPA Internet text
       messages", STD 11, RFC 822, August 1982.
 [3]   Moore, K., "Simple Mail Transfer Protocol (SMTP) Service
       Extension for Delivery Status Notifications (DSNs)", RFC 3461,
       January 2003.
 [4]   Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD
       53, RFC 1939, May 1996.
 [5]   Freed, N. and N. Borenstein, "Multipurpose Internet Mail
       Extensions (MIME) Part One: Format of Internet Message Bodies",
       RFC 2045, November 1996.
 [6]   Freed, N. and N. Borenstein, "Multipurpose Internet Mail
       Extensions (MIME) Part Two: Media Types", RFC 2046, November
       1996.
 [7]   Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part
       Three: Message Header Extensions for Non-ASCII Text ", RFC
       2047, November 1996.
 [8]   Freed, N., Klensin, J., and J. Postel, "Multipurpose Internet
       Mail Extensions (MIME) Part Four: Registration Procedures", BCP
       13, RFC 2048, November 1996.
 [9]   Freed, N. and N. Borenstein, "Multipurpose Internet Mail
       Extensions (MIME) Part Five: Conformance Criteria and
       Examples", RFC 2049, November 1996.
 [10]  Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
       4rev1", RFC 3501, March 2003.

Wong Informational [Page 32] RFC 4416 LEMONADE Goals February 2006

 [11]  Myers, J., "IMAP4 QUOTA extension", RFC 2087, January 1997.
 [12]  Hansen, T. and G. Vaudreuil, "Message Disposition
       Notification", RFC 3798, May 2004.
 [13]  Vaudreuil, G. and G. Parsons, "Voice Profile for Internet Mail
       - version 2 (VPIMv2)", RFC 3801, June 2004.
 [14]  Vaudreuil, G. and G. Parsons, "Toll Quality Voice - 32 kbit/s
       Adaptive Differential Pulse Code Modulation (ADPCM) MIME Sub-
       type Registration", RFC 3802, June 2004.
 [15]  Vaudreuil, G. and G. Parsons, "Content Duration MIME Header
       Definition", RFC 3803, June 2004.
 [16]  Buckley, R., Venable, D., McIntyre, L., Parsons, G., and J.
       Rafferty, "File Format for Internet Fax", RFC 3949, February
       2005.
 [17]  Parsons, G. and J. Rafferty, "Tag Image File Format (TIFF) -
       image/tiff MIME Sub-type Registration", RFC 3302, September
       2002.
 [18]  Allocchio, C., "Minimal GSTN address format in Internet Mail",
       RFC 3191, October 2001.
 [19]  Allocchio, C., "Minimal FAX address format in Internet Mail",
       RFC 3192, October 2001.
 [20]  Toyoda, K., Ohno, H., Murai, J., and D. Wing, "A Simple Mode of
       Facsimile Using Internet Mail", RFC 3965, December 2004.
 [21]  Parsons, G. and J. Rafferty, "Tag Image File Format (TIFF) - F
       Profile for Facsimile", RFC 2306, March 1998.
 [22]  Gellens, R. and J. Klensin, "Message Submission", RFC 2476,
       December 1998.
 [23]  Masinter, L. and D. Wing, " Extended Facsimile Using Internet
       Mail", RFC 2532, March 1999.
 [24]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
       Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol --
       HTTP/1.1", RFC 2616, June 1999.
 [25]  Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April
       2001.

Wong Informational [Page 33] RFC 4416 LEMONADE Goals February 2006

 [26]  Resnick, P., "Internet Message Format", RFC 2822, April 2001.
 [27]  Burger, E., Candell, E., Eliot, C., and G. Klyne, "Message
       Context for Internet Mail", RFC 3458, January 2003.
 [28]  Burger, E., "Critical Content Multi-purpose Internet Mail
       Extensions (MIME) Parameter", RFC 3459, January 2003.
 [29]  Gahrns, M., "IMAP4 Multi-Accessed Mailbox Practice", RFC 2180,
       July 1997.
 [30]  Candell, E., "High-Level Requirements for Internet Voice Mail",
       RFC 3773, June 2004.
 [31]  Nerenberg, L., "IMAP4 Binary Content Extension", RFC 3516,
       April 2003.
 [32]  Nerenberg, "IMAP4 Channel Transport Mechanism", Work in
       Progress, November 2001.
 [33]  Toyoda, K. and D. Crocker, "SMTP Service Extensions for Fax
       Content Negotiation", Work in Progress, February 2003.
 [34]  McRae, S. and G. Parsons, "Internet Voice Messaging (IVM)", RFC
       4239, November 2005.
 [35]  Murchison, K. and L. Greenfield, "LMTP Service Extension for
       Ignoring Recipient Quotas", Work in Progress, June 2002.
 [36]  Crispin, M., "Message Submission", Work in Progress,
       February 2004.
 [37]  Newman, C., "Message Submission with Composition", Work in
       Progress, February 2004.
 [38]  Gellens, R., "IMAP Message Submission", Work in Progress,
       December 2003.
 [39]  Resnick, P., "Internet Message Access Protocol (IMAP) CATENATE
       Extension", Work in Progress, December 2003.
 [40]  Crispin, M. and C. Newman, "Internet Message Access (IMAP) -
       URLAUTH Extension", Work in Progress, July 2004.
 [41]  Newman, D., "Message Submission BURL Extension", Work in
       Progress, July 2004.

Wong Informational [Page 34] RFC 4416 LEMONADE Goals February 2006

 [42]  Crocker, D., "Internet Mail Architecture", Work in Progress,
       July 2004.
 [43]  Leuca, I., "Multimedia Messaging Service", Presentation to the
       VPIM WG, IETF53 Proceedings , April 2002.
 [44]  Mahy, R., "A Message Summary and Message Waiting Indication
       Event Package for the Session Initiation Protocol (SIP)", RFC
       3842, August 2004.
 [45]  Shapira, N. and E. Aloni, "Simple Notification and Alarm
       Protocol (SNAP)", Work in Progress, December 2001.
 [46]  Vaudreuil, G., "Messaging profile for telephone-based Messaging
       clients", Work in Progress, February 2002.
 [47]  Burger, E., "Internet Unified Messaging Requirements", Work in
       Progress, February 2002.
 [48]  OMA, "Multimedia Messaging Service Architecture Overview
       Version 1.1", Open Mobile Alliance (OMA) OMA-WAP-MMS-ARCH-v1_1-
       20021101-C, November 2002.
 [49]  OMA, "Push Architectural Overview", Open Mobile Alliance
       (OMA) WAP-250-PushArchOverview-20010703-a, July 2001.
 [50]  OMA, "Push Access Protocol Specification", Open Mobile Alliance
       (OMA) WAP-247-PAP-20010429-a, April 2001.
 [51]  OMA, "Push Proxy Gateway Service Specification", Open Mobile
       Alliance (OMA) WAP-249-PPGService-20010713a, July 2001.
 [52]  OMA, "Multimedia Messaging Service; Client Transactions Version
       1.1", Open Mobile Alliance
       (OMA) OMA-WAP-MMS-CTR-v1_1-20021031-C, October 2002.
 [53]  OMA, "Multimedia Messaging Service; Encapsulation Protocol
       Version 1.1", Open Mobile Alliance (OMA) OMA-MMS-ENC-v1_1-
       20021030-C, October 2002.
 [54]  OMA, "User Agent Profile, Version 1.1", Open Mobile Alliance
       (OMA) OMA-UAProf-v1_1-20021212-C, December 2002.
 [55]  OMA, "Email Notification Version 1.0", Open Mobile Alliance
       (OMA) OMA-EMN-v1_0-20021031-C, October 2002.

Wong Informational [Page 35] RFC 4416 LEMONADE Goals February 2006

 [56]  3GPP, "Third Generation Partnership Project; Technical
       Specification Group Services and System Aspects; Service
       aspects; Functional description; Stage 1 Multimedia Messaging
       Service", 3GPP TS 22.140, 2001.
 [57]  3GPP, "Third Generation Partnership Project; Technical
       Specification Group Terminals; Multimedia Messaging Service
       (MMS); Functional description; Stage 2", 3GPP TS 23.140, 2001.
 [58]  3GPP2, "Short Message Service (SMS)", 3GPP2 TSG C.S0015-0,
       December 1999.
 [59]  3GPP2, "Enhanced Message Service (EMS) Stage 1 Description",
       3GPP2 TSG S.R0051-0 v1.0,  July 2001.
 [60]  CCITT, "Recommendations Q.700-Q.716: Specifications of
       Signalling System No. 7", CCITT White Book, Volume VI,
       Fascicle VI.7.
 [61]  CCITT, "Recommendations Q.721-Q.766: Specifications of
       Signalling System No.7", CCITT White Book, Volume VI,
       Fascicle VI.8.
 [62]  ITU, "E.164: The international public telecommunication
       numbering plan", ITU-T Recommendations Series E, May 1997.
 [63]  ITU, "Specifications of Signalling System Number 7",  ITU White
       Book,  ITU-T Recommendation Q.763.
 [64]  ITU, "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-T Recommendation X.25, October 1996.
 [65]  BELLCORE, "Specifications of Signalling System Number 7", GR-
       246-CORE Issue 1, December 1994.

Wong Informational [Page 36] RFC 4416 LEMONADE Goals February 2006

Appendix A. Contributors

 Eric Burger
 Brooktrout Technology, Inc.
 18 Keewaydin Dr.
 Salem, MA  03079
 USA
 Phone: +1 603 890-7587
 EMail: eburger@brooktrout.com
 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
 USA
 Phone: +1 805 884-6207
 EMail: milt.roselinsky@openwave.com
 Dan Shoshani
 Comverse
 29 Habarzel St.
 Tel-Aviv 69710
 Israel
 EMail: Dan.Shoshani@comverse.com

Wong Informational [Page 37] RFC 4416 LEMONADE Goals February 2006

 Alan K. Stebbens
 Openwave Systems, Inc.
 530 E. Montecito St.
 Santa Barbara, CA 93103
 USA
 Phone: +1 805 884-3162
 EMail: alan.stebbens@openwave.com
 Gregory M. Vaudreuil
 Lucent Technologies
 7291 Williamson Rd.
 Dallas, TX 75214
 USA
 Phone: +1 214 823-9325
 EMail: GregV@ieee.org

Appendix B. Acknowledgements

 Ari Erev and Noam Shapira (both from Comverse) 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.
 Yaacov (Jerry) Weingarten (Comverse) and Stephane Maes (Oracle)
 provided detailed comments on the final document.

Appendix C. IAB Note: Unified Notification Protocol Considerations

 Note: dated July 10, 2003
 This note was formulated in response to an informal IESG request to
 look at the architectural issues surrounding a unified notification
 protocol.  The following materials were used as reference:
    * draft-dusseault-s2s-event-reqs-00.txt (notification
    requirements)
    * meeting notes for the LEMONADE WG from IETF 56.
    * draft-shapira-snap-05.txt (protocol design for SNAP which has
    some aspects of a generic notification protocol)
    * the LEMONADE WG charter
    * Recent email on the Lemonade list
    * A few presentations from the 1998 UCI workshop on Internet-wide
    notification

Wong Informational [Page 38] RFC 4416 LEMONADE Goals February 2006

  • The Web pages for KnowHow, a company founded by Rohit Khare

which has a proprietary Internet-wide notification system.

       Thanks to Lisa Dusseault for providing these references.
 Note that this opinion does not represent IAB concensus, it is just
 the opinion of the author after having reviewed the references.
 After the reviewing the material, it seemed that the same kinds of
 functionality are being asked from a generic notification protocol as
 are asked of desktop application integration mechanisms, like OLAY/
 COM on Windows or like Tooltalk was on Solaris, but at the level of
 messaging across the Internet.  The desire is that various
 distributed applications with different application specific
 mechanisms should be able to interoperate without having an n x n
 problem of having each application interact with each other
 application.  The cannonical example, which is in a presentation by
 Lisa Dusseault to LEMONADE from IETF 56, is sending a notification
 from one application, like XMPP Instant Messaging, and having it
 delivered on whatever device the recipient happened to be using at
 the time, like SMS on a cell phone.
 The usual problem with application intergration mechanisms on the
 desktop is how to get the various applications to actually use the
 mechanism.  For Windows, this is relatively easy, since most
 application developers see major value-added in their applications
 being able to play nicely with Microsoft Office.  For Tooltalk,
 unfortunatly, Solaris developers didn't see the 10x improvement, and
 so it was not used outside of Sun's internally maintained
 applications and a few flagship applications like Framemaker.  If the
 generic notification mechanism requires application developers and
 other notification protocol designers to make a major effort to
 utilize it, including modifying their applications or protocols in
 some way, the protocol could become "just another notification
 mechanism" rather than a unifying device, because most application
 developers and other protocol designers could ignore it.
 So the first architectural consideration is how do clients of a
 particular protocol (and the word "client" is used here to mean "any
 entity using the protocol", they may peers or they may be
 client/server) actually utilize the generic notification protocol?
 Is there some code change required in the client or can a legacy
 client interoperate without change?
 If you look at Fig. 1 in draft-shapira-snap-05.txt, the answer seems
 to be that the notifying client uses the generic protocol, SNAP in
 this case, to a functional entity (server? module on the receiving
 client?) called the "Notification Service" that processes the generic

Wong Informational [Page 39] RFC 4416 LEMONADE Goals February 2006

 notification into an application specific notification and sends that
 notification to the client.  From this figure it looks as if the
 notifying client would require modification but the receiving client
 wouldn't.
 Another characteristic of application integration mechansims is that
 they typically focus on very simple operations, the semantics of
 which are shared between different applications.  Examples are
 "here's a rectangle, display yourself in it" or "put this styled text
 object into the clipboard", and applications agree on what styled
 text means.  More complicated semantics are hard to share because
 each application has its own particular twist on the meaning of a
 particular sequence of operations on a collection of objects.  The
 result is a "least common denominator" collection of integration
 mechanisms, primarily focussed on display integration and, to a
 lesser extent, cut and paste integration.
 In the context of a generic notification protocol, this raises
 several possible issues.  One is addressing, which is identified
 draft-dusseault-s2s-event-reqs-00.txt, but in a sense this is the
 easiest to resolve, by using existing and perhaps newly defined URIs.
 A more complex problem is matching the semantics of what
 preconditions constitute the trigger for an event across different
 application notification mechanisms.  This is of course necessary for
 translating notifications between the different event notification
 mechanisms and the generic mechanism, but, more problematically, it
 is also required for a subscription service whereby subscriptions can
 be made to filter events using the generic notification mechanism and
 the subscriptions can be translated to different application specific
 mechanisms.  Any language for expressing generic subscriptions is
 unlikely to support expressing the fine points in the different
 application notification semantics.  Note that SNAP does not seem to
 support a subscription service so perhaps this isn't an issue for
 SNAP.
 Another architectural issue, which was discussed earlier this year on
 the LEMONADE list w.r.t. some other topics, is gatewaying.  The
 cannonical example above (message sent using XMPP and arriving via
 SMS on a cell phone) is actually a gateway example, because it would
 require translation between an IP-based messaging mechanism (XMPP) to
 a PSTN based mechanism (SMS).  The problem with using a unified
 notification mechanism for this purpose is that if there are other
 functions common between the two, it is likely that a gateway will be
 built anyway.  In fact, one of the work items for LEMONADE is to
 investigate such gateways.  The value of a generic notification
 mechanism therefore needs to be assessed in the light of this.

Wong Informational [Page 40] RFC 4416 LEMONADE Goals February 2006

 These are the primary architectural issues, but there are a few
 others that need consideration in any major system development
 effort.  End to end security is one,
 draft-dusseault-s2s-event-reqs-00.txt talks about this quite
 extensively, so it won't be repeated here.  The major issue is how to
 ensure that the end to end security properties are maintained in the
 face of movement of the notification through the generic intermediary
 protocol.  Another issue is scalability.  Peer to peer v.s. server
 based mechanisms have implications for how scalable the notification
 mechanism would be, and this needs consideration.  Extensibility
 needs careful consideration.  What is required to integrate a new
 application?  Ideally, with time, application developers will stop
 "rolling their own" notification service and simply use the generic
 service, but this ideal may be extremely hard to achieve, and may
 depend to a large extent on market acceptance.
 Finally, there are some considerations that aren't architectural but
 may impact the ultimate success of a generic notification protocol,
 in the sense that the protocol becomes widely deployed and used.  The
 author's experience is that IETF has not had particular success in
 introducing mechanisms that unify or supplant existing proprietary
 mechanisms unless strong vendor and service provider by-in is there.
 Two examples are instant messaging and service discovery.  With
 instant messaging, it seems that a standarized, unified instant
 messaging protocol has been delayed by the lack of committment from
 major service providers.  With service discovery, weak commitment
 from vendors has resulted in the continued introduction of vendor
 specific service discovery solutions even after an IETF standard is
 in place.  The situation with service discovery (with which the
 author is most familiar) resulted from a lack of major vendor
 committment during the end phases of the standarization process.
 Applying these lessions to a generic notification protocol, having
 important players with proprietary notification protocols on board
 and committed until the conclusion of the design process will be
 crucial.  Major committment is needed from various application
 notification protocols before a generic mechanism could succeed.
 Given the amount of time and effort required in any IETF
 standardization work, assessing these with an objective eye is
 critical, otherwise, regardless of how technically well designed the
 protocol is, deployment success may be lacking.  Having an elegently
 design solution that nobody deploys is an outcome that might be wise
 to avoid.
 James Kempf
 July 2003

Wong Informational [Page 41] RFC 4416 LEMONADE Goals February 2006

Author's Address

 Jin Kue Wong (Editor)
 Nortel Networks
 P.O. Box 3511 Station C
 Ottawa, ON  K1Y 4H7
 Canada
 Phone: +1 613 763-2515
 EMail: j.k.wong@sympatico.ca

Wong Informational [Page 42] RFC 4416 LEMONADE Goals February 2006

Full Copyright Statement

 Copyright (C) The Internet Society (2006).
 This document is subject to the rights, licenses and restrictions
 contained in BCP 78, and except as set forth therein, the authors
 retain all their rights.
 This document and the information contained herein are provided on an
 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
 ENGINEERING TASK FORCE DISCLAIM 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.

Intellectual Property

 The IETF takes no position regarding the validity or scope of any
 Intellectual Property Rights or other rights that might be claimed to
 pertain to the implementation or use of the technology described in
 this document or the extent to which any license under such rights
 might or might not be available; nor does it represent that it has
 made any independent effort to identify any such rights.  Information
 on the procedures with respect to rights in RFC documents can be
 found in BCP 78 and BCP 79.
 Copies of IPR disclosures made to the IETF Secretariat and any
 assurances of licenses to be made available, or the result of an
 attempt made to obtain a general license or permission for the use of
 such proprietary rights by implementers or users of this
 specification can be obtained from the IETF on-line IPR repository at
 http://www.ietf.org/ipr.
 The IETF invites any interested party to bring to its attention any
 copyrights, patents or patent applications, or other proprietary
 rights that may cover technology that may be required to implement
 this standard.  Please address the information to the IETF at
 ietf-ipr@ietf.org.

Acknowledgement

 Funding for the RFC Editor function is provided by the IETF
 Administrative Support Activity (IASA).

Wong Informational [Page 43]

/data/webs/external/dokuwiki/data/pages/rfc/rfc4416.txt · Last modified: 2006/02/27 23:38 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki